Hi all,
> > Now that 'make check' has had enough time to run, I can see several
> > regressions in the configurations where GCC still builds.
> > For more details:
> > http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/230087/report-build-info.html
> >
>
> This also causes failures for AArch64 -mcpu=cortex-a57 targets. This
> testcase:
>
> void
> foo (unsigned char *out, const unsigned char *in, int a)
> {
> for (int i = 0; i < a; i++)
> {
> out[0] = in[2];
> out[1] = in[1];
> out[2] = in[0];
> in += 3;
> out += 3;
> }
> }
>
> Fails as so:
>
> foo.c: In function 'void foo(unsigned char*, const unsigned char*, int)':
> foo.c:12:1: internal compiler error: in scan_rtx_reg, at regrename.c:1074
> }
> ^
>
> 0xbe00f8 scan_rtx_reg
> ..../gcc/regrename.c:1073
> 0xbe0ad5 scan_rtx
> ..../gcc/regrename.c:1401
> 0xbe1038 record_out_operands
> ..../gcc/regrename.c:1554
> 0xbe1f50 build_def_use
> ..../gcc/regrename.c:1802
> 0xbe1f50 regrename_analyze(bitmap_head*)
> ..../gcc/regrename.c:726
> 0xf7a0c7 func_fma_steering::execute_fma_steering()
> ..../gcc/config/aarch64/cortex-a57-fma-steering.c:1026
> 0xf7a9c1 pass_fma_steering::execute(function*)
> ..../gcc/config/aarch64/cortex-a57-fma-steering.c:1063
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> When compiled with:
>
> <gcc-aarch64> -O3 -mcpu=cortex-a57 foo.c
>
> Thanks,
> James 0xbe1f50 build_def_use
> ..../gcc/regrename.c:1802
> 0xbe1f50 regrename_analyze(bitmap_head*)
> ..../gcc/regrename.c:726
> 0xf7a0c7 func_fma_steering::execute_fma_steering()
> ..../gcc/config/aarch64/cortex-a57-fma-steering.c:1026
> 0xf7a9c1 pass_fma_steering::execute(function*)
> ..../gcc/config/aarch64/cortex-a57-fma-steering.c:1063
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> When compiled with:
>
> <gcc-aarch64> -O3 -mcpu=cortex-a57 foo.c
Thanks for the test case.
It appears that I managed to run only those tests that didn't expose
the assertion error and there is at least one more port i.e. powerpc64
showing similar ICEs when -funroll-loops and/or -fpeel-loops are used
that enables the regrename pass.
In both AArch64 and ARM cases I found the same insufficient checks
when chains are tied and it seems that this is the root cause behind
all failures.
With the attached patch I built arm-none-linux-gnueabi without failures,
checked a number of cases shown on Christophe's page, the above
test case, and it would appear that the problem is solved.
The reason behind the failures is that the terminated_this_insn had
a different number of consecutive registers (and mode) to the input
operand in a move currently being considered for tying. In the fix,
I allow tying only if there is matching number of NREGS.
Bernd, do you think that this check would be sufficient and safe?
I'm not sure what would be better: check the mode, nregs plus perhaps
consider tying only if nregs == 1.
Regards,
Robert
gcc/
* regname.c (scan_rtx_reg): Check the matching number of consecutive
registers when tying chains.
---
gcc/regrename.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/regrename.c b/gcc/regrename.c
index d727dd9..0b8f032 100644
--- a/gcc/regrename.c
+++ b/gcc/regrename.c
@@ -1068,7 +1068,9 @@ scan_rtx_reg (rtx_insn *insn, rtx *loc, enum reg_class
cl, enum scan_actions act
&& GET_CODE (pat) == SET
&& GET_CODE (SET_DEST (pat)) == REG
&& GET_CODE (SET_SRC (pat)) == REG
- && terminated_this_insn)
+ && terminated_this_insn
+ && terminated_this_insn->nregs
+ == REG_NREGS (recog_data.operand[1]))
{
gcc_assert (terminated_this_insn->regno
== REGNO (recog_data.operand[1]));
--
2.4.5
