On 8 December 2015 at 19:48, Eric Botcazou wrote:
>> I think that is ok if the testing passes.
>
> Thanks. It did on the 3 architectures so I have applied the patch.
>
Thanks, I confirm it also fixes the regressions I noticed on ARM.
Christophe.
> --
> Eric Botcazou
> I think that is ok if the testing passes.
Thanks. It did on the 3 architectures so I have applied the patch.
--
Eric Botcazou
On 12/08/2015 11:50 AM, Eric Botcazou wrote:
I'm going to test it on x86-64, SPARC64 and Aarch64.
PR middle-end/68291
PR middle-end/68292
* cfgexpand.c (set_rtl): Always accept mode mismatch for SSA names
with BLKmode promoted mode based on RESULT_DECLs.
I thi
> Yes you are right. the PASS->FAIL and "PASS disappears" are consequences
> of the new failures above.
OK. The issue is that we used to create a REG:BLK for RESULT_DECL, but now we
get to hard_function_value as originally, which rightfully adjusts it to SI:
val
= targetm.calls.function_va
On 8 December 2015 at 10:46, Eric Botcazou wrote:
>> Since you committed this (r231372), I've noticed several regressions
>> on ARM and AArch64.
>> You can have a look at
>> http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/231372/
>> report-build-info.html for more details.
>
>
> Since you committed this (r231372), I've noticed several regressions
> on ARM and AArch64.
> You can have a look at
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/231372/
> report-build-info.html for more details.
I presume it's:
Fail appears [ => FAIL]:
On 7 December 2015 at 10:35, Eric Botcazou wrote:
> Hi,
>
> it's a couple of regressions in the C testsuite present on SPARC 64-bit and
> coming from the new coalescing code which fails to handle vector types with
> BLKmode that are returned in multiple registers. The code assigns a BLKmode
> REG
On December 7, 2015 5:42:02 PM GMT+01:00, Eric Botcazou
wrote:
>> Ok. Although thinking about your comment in the PR about not making
>such
>> vectors gimple registers I wonder what the effects of that would be.
>
>First of all it's a bit painful to do because is_gimple_reg_type is
>defined
>inl
> Ok. Although thinking about your comment in the PR about not making such
> vectors gimple registers I wonder what the effects of that would be.
First of all it's a bit painful to do because is_gimple_reg_type is defined
inline in gimple-expr.h and adding TYPE_MODE in there causes a compilation
On 12/07/2015 10:35 AM, Eric Botcazou wrote:
As discussed with Alexandre in the audit trail, the attached minimal fix just
prevents the problematic BLKmode REG from being generated, which appears to be
sufficient to restore the nominal operating mode.
PR middle-end/68291
PR mi
Hi,
it's a couple of regressions in the C testsuite present on SPARC 64-bit and
coming from the new coalescing code which fails to handle vector types with
BLKmode that are returned in multiple registers. The code assigns a BLKmode
REG to the RESULT_DECL of the function in expand_function_star
11 matches
Mail list logo