Hi,
this is a regression on the mainline introduced by my tree-ssa-alias.c change:
2013-04-17 Eric Botcazou
* tree-ssa-alias.c (nonoverlapping_component_refs_of_decl_p): New.
(decl_refs_may_alias_p): Add REF1 and REF2 parameters.
Use nonoverlapping_component_refs_of_de
On Tue, Oct 8, 2013 at 10:19 AM, Eric Botcazou wrote:
> Hi,
>
> this is a regression on the mainline introduced by my tree-ssa-alias.c change:
>
> 2013-04-17 Eric Botcazou
>
> * tree-ssa-alias.c (nonoverlapping_component_refs_of_decl_p): New.
> (decl_refs_may_alias_p): Add REF1
> Probably because the actual accesses may overlap if we choose to
> perform a bigger access.
Nope, simply because they share a byte.
> The same can happen if we for struct { char c1; char c2; } perform
> an HImode access in case the target doesn't support QImode accesses.
> Basically anytime we
On Tue, Oct 8, 2013 at 7:52 PM, Eric Botcazou wrote:
>> Probably because the actual accesses may overlap if we choose to
>> perform a bigger access.
>
> Nope, simply because they share a byte.
>
>> The same can happen if we for struct { char c1; char c2; } perform
>> an HImode access in case the t
> In my opinion the MEM_EXPR is "wrong", as it is supposed to be
> the tree equivalent of the memory access. At gimple level we
> handle accesses at bit-granularity so bit-accesses are fine.
> Not so at RTL level it seems.
>
> [this also shows we probably should lower bit-granular accesses
> at t
On Wed, Oct 9, 2013 at 1:36 PM, Eric Botcazou wrote:
>> In my opinion the MEM_EXPR is "wrong", as it is supposed to be
>> the tree equivalent of the memory access. At gimple level we
>> handle accesses at bit-granularity so bit-accesses are fine.
>> Not so at RTL level it seems.
>>
>> [this also
> Well, ok. Please adjust the comment
>
> + /* Different fields of the same record type cannot overlap, unless
> they +are both bitfields and we are at the RTL level. */
>
> to sth like
>
> ??? Bitfields can overlap at RTL level so punt if we end up at
> them.
>
> or s
