https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93270

Michael Matz <matz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at gcc dot gnu.org

--- Comment #5 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> And pasting from my ml analysis:
> 
> So clearly something is wrong:
> 
>  <component_ref 0x7ffff695d240
>     type <real_type 0x7ffff682d3f0 long double sizes-gimplified XF
>         size <integer_cst 0x7ffff680dd20 constant 128>
>         unit-size <integer_cst 0x7ffff680dd38 constant 16>
>         align:128 warn_if_not_align:0 symtab:0 alias-set 2
> canonical-type 0x7ffff682d3f0 precision:80
>         pointer_to_this <pointer_type 0x7ffff682d930>>
> 
> and thus GET_MODE_SIZE (XFmode) == 16.  The target cannot possibly
> just store 12 bytes here,
> it lies.  Why's XFmode not 12 bytes but with 8/16 byte alignment?
> Does the ABI say sizeof(long double) is 16?

Of course.  sizeof _must_ be a multiple of alignment, but it can contain
padding.  So the target is completely fine with stating that sizeof is 16,
but then only storing 12 bytes.  (That implies that there are 4 bytes of
padding).  The number of bits that are actually relevant for determining the
value of something is supposed to be in precision, though this use of precision
was never explicitly called out, so there might be cases where precision isn't
reliably usable for this purpose.

> That said, a mode-has-padding or whatever should be reflected in
> TYPE_SIZE & friends as well, inconsistencies
> there just make things worse.

No, I don't see any inconsistencies.

What of course needs to be said is that the original testcase simply is
invalid.  It stores .value and then reads from another union member, that's
not allowed.  (You can play these games if the other member would be a char
array, and GCC tries to allow you to do that also with other types, but as you
noticed this allowance has its limits).

So, I think, nothing needs fixing.  The quality of implementation could be
somewhat improved in one dimension by using precision instead of size, but
only at expense of lowering quality in another dimension (namely of not
removing
the memset).

Reply via email to