On Fri, Oct 10, 2014 at 10:38 AM, Eric Botcazou wrote:
>> I can't see how this can work with LTO. We need a middle-end way
>> to represent the alias relation of those types. At least I can't see how
>> your simple patch covers all cases here?
>
> It covers what I think is the most prominent case
> I can't see how this can work with LTO. We need a middle-end way
> to represent the alias relation of those types. At least I can't see how
> your simple patch covers all cases here?
It covers what I think is the most prominent case (unconstrained array types),
the other cases are far less an
On Tue, Oct 7, 2014 at 10:04 AM, Eric Botcazou wrote:
>> Testcase? I think it would be better to handle this in the canonical type
>> merging code in lto.c - or how does it end up working without LTO? That is,
>> what does the Ada frontend do to make sure get_alias_set handles this
>> correctly?
> Testcase? I think it would be better to handle this in the canonical type
> merging code in lto.c - or how does it end up working without LTO? That is,
> what does the Ada frontend do to make sure get_alias_set handles this
> correctly?
It manages the alias sets, see gcc-interface/utils.c:rela
On Mon, Oct 6, 2014 at 12:16 PM, Eric Botcazou wrote:
> Hi,
>
> this is a regression from GCC 4.8.x: gnat1 (uintp.adb:UI_Lt) is miscompiled
> during a LTO boostrap when Init_Operand is inlined into it. A store is
> wrongly deleted by GIMPLE DSE because of a missed aliasing relationship
> between
Hi,
this is a regression from GCC 4.8.x: gnat1 (uintp.adb:UI_Lt) is miscompiled
during a LTO boostrap when Init_Operand is inlined into it. A store is
wrongly deleted by GIMPLE DSE because of a missed aliasing relationship
between 2 array types with TYPE_NONALIASED_COMPONENT set, one being a d
