On Mon, Jan 13, 2014 at 11:37 AM, Eric Botcazou wrote:
>> Note that this now lets unaligned vector moves slip through as
>> their TYPE_ALIGN (TREE_TYPE (ref)) is properly reflecting this
>> fact, so is anything which dereferences a type with an aligned
>> attribute lowering its alignment.
>>
>> Wh
> Note that this now lets unaligned vector moves slip through as
> their TYPE_ALIGN (TREE_TYPE (ref)) is properly reflecting this
> fact, so is anything which dereferences a type with an aligned
> attribute lowering its alignment.
>
> Which of course raises the question what the function is
> supp
On Sat, Jan 11, 2014 at 12:42 AM, Eric Botcazou wrote:
> [Sorry for dropping the ball here]
>
>> I think that may_be_unaligned_p is just seriously out-dated ... shouldn't it
>> be sth like
>>
>> get_object_alignment_1 (ref, &align, &bitpos);
>> if step * BITS_PER_UNIT + bitpos is misaligned
>>
[Sorry for dropping the ball here]
> I think that may_be_unaligned_p is just seriously out-dated ... shouldn't it
> be sth like
>
> get_object_alignment_1 (ref, &align, &bitpos);
> if step * BITS_PER_UNIT + bitpos is misaligned
> ...
>
> or rather all this may_be_unaligned_p stuff should be
On Fri, Sep 13, 2013 at 4:56 PM, Eric Botcazou wrote:
> Hi,
>
> in Ada we can have misaligned array components in record types, that is to say
> object with BLKmode whose alignment is lower than that of their type. In this
> case IVOPTS can generate misaligned TARGET_MEM_REFs, which will lead to
Hi,
in Ada we can have misaligned array components in record types, that is to say
object with BLKmode whose alignment is lower than that of their type. In this
case IVOPTS can generate misaligned TARGET_MEM_REFs, which will lead to an
unaligned access on strict-alignment platforms.
Tested on
