Re: [patch] Fix ICE on CONSTRUCTOR containing absolute addresses

2017-07-17 Thread Richard Biener
On Mon, Jul 17, 2017 at 12:48 PM, Eric Botcazou wrote: >> So this isn't about global >> >> void *x[] = { &((struct Y *)0x12)->foo } >> >> but for a local one where supposedly variable indexing is valid (don't >> we gimplify that)? > > Yes, it's local (it's OK if global

Re: [patch] Fix ICE on CONSTRUCTOR containing absolute addresses

2017-07-17 Thread Eric Botcazou
> So this isn't about global > > void *x[] = { &((struct Y *)0x12)->foo } > > but for a local one where supposedly variable indexing is valid (don't > we gimplify that)? Yes, it's local (it's OK if global because we do a full RTL expansion). Everything is valid, constant and passes

Re: [patch] Fix ICE on CONSTRUCTOR containing absolute addresses

2017-07-17 Thread Richard Biener
On Mon, Jul 17, 2017 at 10:51 AM, Eric Botcazou wrote: >> Apart from the MEM construction where I simply trust you this looks >> ok. Mind adding MEM_REF support for this case as well? > > Do you mean MEM_REF ? Is that possible? Yes. >> Btw,

Re: [patch] Fix ICE on CONSTRUCTOR containing absolute addresses

2017-07-17 Thread Eric Botcazou
> Apart from the MEM construction where I simply trust you this looks > ok. Mind adding MEM_REF support for this case as well? Do you mean MEM_REF ? Is that possible? > Btw, why's simply output_constant_def (TREE_OPERAND (target, 0), 1); > not correct? If you do

Re: [patch] Fix ICE on CONSTRUCTOR containing absolute addresses

2017-07-17 Thread Richard Biener
On Fri, Jul 7, 2017 at 1:08 PM, Eric Botcazou wrote: > Hi, > > this fixes the following ICE in decode_addr_const: > > +===GNAT BUG DETECTED==+ > | 8.0.0 20170704 (experimental) [trunk revision 249942] (x86_64-suse-linux) >