Subregs and objects with holes (new patch)

Joseph S. Myers joseph@codesourcery.com
Fri Nov 24 14:07:00 GMT 2006


On Fri, 24 Nov 2006, Rask Ingemann Lambertsen wrote:

> On Thu, Nov 23, 2006 at 07:53:42PM +0000, Joseph S. Myers wrote:
> 
> > Bootstrapped with no regressions on i686-pc-linux-gnu.
> 
>    AFAIK, i686-pc-linux-gnu defaults to -m96bit-long-double. How did you
> test it with -m128bit-long-double?

There was no reduced testcase given with the patch introducing the special 
handling of objects with holes (neither added to the testsuite, nor given 
inline in the message) and so I couldn't test that.  I'd welcome the 
addition of a -m128bit-long-double testcase showing the original problem 
to the testsuite.

>    You're comparing apples to oranges. The size of a mode in registers is a
> number of hard registers while the size of a mode in memory is a number of
> bits. It can't come up with a better wording right now, though.

I'm comparing (number of registers * size of register), but "size of 
register" here is GCC's internal notion of the size (so the size of 
floating-point registers that can hold an XFmode value always matches the 
size of XFmode).  But I didn't find a good way to express the concept that 
certain kinds of padding matter and others don't.

>    Perhaps change the name of the macro to HARD_REGNO_NREGS_HAS_PADDING to
> make it clear, that it is closely tied to HARD_REGNO_NREGS_WITH_PADDING?

Even though it is a property of both the mode and the register number, it 
feels more like a property of the mode.  The tie is supposed to be clear 
from the macros being documented consecutively.  But if someone will 
approve the patch subject to (specified) different macro names and 
documentation text, please do.

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list