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.
