Hi!
On Fri, Jun 10, 2022 at 07:52:57PM +0530, Surya Kumari Jangala wrote:
> In check_new_reg_p, the nregs of a du chain is computed by obtaining the MODE
> of the first element in the chain, and then calling hard_regno_nregs() with
> the
> MODE. But the first element of the chain can be a DEBUG_INSN whose mode need
> not be the same as the rest of the elements in the du chain. This
> was resulting in fcompare-debug failure as check_new_reg_p was returning a
> different result with -g for the same candidate register. We can instead
> obtain
> nregs from the du chain itself.
Great, thanks for finding and fixing this! I cannot approve it, you'll
have to wait for someone who can. It looks fine to me, but that does
not mean so much in regrename.c :-)
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/pr105041.c
> @@ -0,0 +1,24 @@
> +/* { dg-do compile } */
Please delete this line, it is the default.
> +/* { dg-require-effective-target be } */
Is there a reason to not test this on LE? If not, please remove this
line as well.
> +/* { dg-options "-m32 -mdejagnu-cpu=power4 -O2 -fcompare-debug
> -fharden-compares -frename-registers" } */
Aha. You check for LE because you use -m32 in the test? Don't, then!
Instead, test with -m32 in your RUNTESTFLAGS, like
make check-gcc-c RUNTESTFLAGS="--target_board=unix'{-m64,-m32}'
powerpc.exp=pr105041.c"
or similar.
It's a good idea to add a comment a la
/* PR rtl-optimization/105041: This test failed with -m32. */
Thanks again for the patch!
Segher
