> I have noticed new failures after this commit (r244249).
> g++.dg/opt/call3.C fails at execution on armeb targets
> g++.dg/opt/call2.C fails at execution on aarch64_be
It turns out that there is already a big-endian adjustment a few lines above:
/* If the value has a record type and an in
> They pass before the patch (I only checked armeb).
I think that's not true for aarch64_be though, since the patch doesn't change
code generation for this target. But I'll fix that too.
--
Eric Botcazou
On 10 January 2017 at 11:26, Eric Botcazou wrote:
>> They pass before the patch (I only checked armeb).
>
> Thanks, I see what's going on, but can you post the configure line of armeb?
>
Sure, it is:
--target=armeb-none-linux-gnueabihf --with-float=hard --with-mode=arm
--with-cpu=cortex-a9 --with
> They pass before the patch (I only checked armeb).
Thanks, I see what's going on, but can you post the configure line of armeb?
--
Eric Botcazou
On 10 January 2017 at 09:58, Eric Botcazou wrote:
>> I have noticed new failures after this commit (r244249).
>> g++.dg/opt/call3.C fails at execution on armeb targets
>> g++.dg/opt/call2.C fails at execution on aarch64_be
>
> They are new testcases: can you find out whether they pass before the p
> I have noticed new failures after this commit (r244249).
> g++.dg/opt/call3.C fails at execution on armeb targets
> g++.dg/opt/call2.C fails at execution on aarch64_be
They are new testcases: can you find out whether they pass before the patch?
--
Eric Botcazou
On 9 January 2017 at 12:14, Richard Biener wrote:
> On Mon, Jan 9, 2017 at 11:43 AM, Eric Botcazou wrote:
>> Hi,
>>
>> this is a regression present on all active branches for big-endian targets
>> returning small aggregate types in registers under certain circumstances and
>> when optimization is
On Mon, Jan 9, 2017 at 11:43 AM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on all active branches for big-endian targets
> returning small aggregate types in registers under certain circumstances and
> when optimization is enabled: when the bitfield path of store_field is taken,
Hi,
this is a regression present on all active branches for big-endian targets
returning small aggregate types in registers under certain circumstances and
when optimization is enabled: when the bitfield path of store_field is taken,
the function ends up calling store_bit_field to store the val
