This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: g++ pointer tracking question
- From: law at redhat dot com
- To: Steve Ellcey <sje at cup dot hp dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 16 May 2002 10:52:23 -0600
- Subject: Re: g++ pointer tracking question
- Reply-to: law at redhat dot com
In message <200205152056.NAA27988@hpsje.cup.hp.com>, Steve Ellcey writes:
> I am looking at a problem here in our HP-UX IPF GCC compiler and I think
> it is due to a bug in the shared code that could affect all platforms.
> I am hoping someone could help me understand this and see if I am on the
> right track.
>
> Here is part of a C++ program:
>
> struct A {
> A(int arg) : ix(arg) {}
> int ix;
> int foo(int arg) { return arg + ix; }
> };
> int func(int A::*p1)
> {
> A obj(2);
> return ((&obj)->*p1);
> }
>
> Now, when I look at the RTL generated on HP-UX IPF in 64 bit mode with
> -O1 (should be the similar to Linux IPF and probably others) I see:
>
> (insn 4 2 5 (set (reg/v/f:DI 341)
> (reg:DI 112 in0)) -1 (nil)
> (nil))
>
> Now, I think the '/f' on register 341 means that frame_related is set
> which is what is used to say that REG_POINTER is true. I.e. we are
> claiming that 341 contains a pointer to memory. In fact in0 and
> register 341 actually just contain the offset of ix within the structure
> A. I think passing an offset (and not an address) as the argument is
> the right thing to do but then we shouldn't be setting REG_POINTER to
> TRUE, should we? Can somone tell me if I passing an offset is in fact
> right? If so should REG_POINTER for reg 341 be set to TRUE?
>
> I have no idea how to fix this but I would at least like to be sure
> I understand the problem. I can submit a GNAT if that would help and
> I can continue to look into what to do but I am at a loss for how to
> proceed right now.
I would agree -- setting REG_POINTER on an offset within a structure
is a bad thing to do. In fact, it can result in incorrect code on
the PA (we use REG_POINTER to distinguish between things like base
and unscaled index when generating ldbx instructions -- getting them
reversed can result in a segfault due to the way implicit space
register selection works on the PA).
jeff