[pph] Merge from trunk rev

[pph] Merge from trunk rev

[Diego Novillo]

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.

Now, this happens during WPA, so I'm suspecting some bad values
being streamed.

Richi, I think it's better if we ICE than if we silently cut
these values short.


Diego.

Re: [pph] Merge from trunk rev

[Richard Guenther]

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.