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 because we do a full RTL ex
> 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 initializer_
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, why's simply output_constant_def (TREE_OPERAND (targe
> 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 that, you get a symbol in the c
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)
> GCC error:|
> | in deco
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)
GCC error:|
| in decode_addr_const, at varasm.c:2880
stemming from a CONSTRUCTOR conta