This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [pph] Merge from trunk rev
- From: Richard Guenther <rguenther at suse dot de>
- To: Diego Novillo <dnovillo at google dot com>
- Cc: gcc at gcc dot gnu dot org, Lawrence Crowl <crowl at google dot com>
- Date: Wed, 20 Apr 2011 10:38:18 +0200 (CEST)
- Subject: Re: [pph] Merge from trunk rev
- References: <20110419184627.GA29084@google.com>
On Tue, 19 Apr 2011, Diego Novillo wrote:
> This merge brings the branch up to rev 172662.
>
> There are some LTO failures which are ICEs induced by a new
> assertion I added in bp_pack_value. We discussed this in
> http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01115.html.
>
> The failure happens when we try to pack DECL_OFFSET_ALIGN. We
> only try to pack 8 bits, but in the case of
> testsuite/gcc.c-torture/execute/20010904-1.c, DECL_OFFSET_ALIGN
> is a very large 64 bit quantity:
>
> typedef struct x { int a; int b; } __attribute__((aligned(32))) X;
>
> #define DECL_OFFSET_ALIGN(NODE) \
> (((unsigned HOST_WIDE_INT)1) << FIELD_DECL_CHECK (NODE)->decl_common.off_align)
>
> Whether correctly or incorrectly, for field 'a',
> decl_common.off_align is 0xff. So, DECL_OFFSET_ALIGN is 1 << 0xff
> this triggers the assert I added.
I suppose it's a middle-end issue that for offset zero we note
an "infinite" amount of always zero low-order bits. We're lucky
(again) that DECL_OFFSET_ALIGN is streamed last. I think we should
fix this by not streaming using the macros that derive sth from
the actual values but by streaming the values themselves
(decl_common.off_align in this case).
> Now, this happens during WPA, so I'm suspecting some bad values
> being streamed.
I think they are not bad values, we just store something bogus.
> Richi, I think it's better if we ICE than if we silently cut
> these values short.
Sure, even better if we stream something useful ;)
Richard.