[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Bug 94042 depends on bug 94148, which changed state.

Bug 94148 Summary: The DF framework uses bb->aux, which is for passes only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94148

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #50 from Martin Liška  ---
commit r10-7160-g5c7e6d4bdf879b437b43037e10453275acabf521
Author: Segher Boessenkool 
Date:   Thu Mar 12 07:12:50 2020 +

df: Don't abuse bb->aux (PR94148, PR94042)

The df dataflow solvers use the aux field in the basic_block struct,
although that is reserved for any use by passes.  And not only that,
it is required that you set all such fields to NULL before calling
the solvers, or you quietly get wrong results.

This changes the solvers to use a local array for last_change_age
instead, just like it already had a local array for last_visit_age.

PR rtl-optimization/94148
PR rtl-optimization/94042
* df-core.c (BB_LAST_CHANGE_AGE): Delete.
(df_worklist_propagate_forward): New parameter last_change_age, use
that instead of bb->aux.
(df_worklist_propagate_backward): Ditto.
(df_worklist_dataflow_doublequeue): Use a local array
last_change_age.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

Segher Boessenkool  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #49 from Segher Boessenkool  ---
Fixed.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

Segher Boessenkool  changed:

   What|Removed |Added

 Target|powerpc64-suse-linux|powerpc*
   Host|powerpc64-suse-linux|
  Build|powerpc64-suse-linux|

--- Comment #48 from Segher Boessenkool  ---
Solved on trunk

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #47 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #46)
> Thank you very much for that new testcase!  I wish I had it before :-)

Do you mean /tmp/reduced.ii ? Note that it's already mentioned in c#14.

> 
> Yesterday I found the problem.  It is in separate shrink-wrapping.  The
> fix is probably simple; hang on :-)

Great to hear that! Nice cooperation.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #46 from Segher Boessenkool  ---
Thank you very much for that new testcase!  I wish I had it before :-)

Yesterday I found the problem.  It is in separate shrink-wrapping.  The
fix is probably simple; hang on :-)

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #45 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #44)
> So, with the reversion, can this be closed as FIXED?

I bet no. There's probably an underlying shrink-wrapping issue and Segher is
investigating that.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #44 from Jakub Jelinek  ---
So, with the reversion, can this be closed as FIXED?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #43 from Martin Liška  ---
(In reply to Martin Liška from comment #41)
> Ok, the way how we build our compiler is to use:
> ./configure --with-cpu=default32
> 
> that should also lead to the ICE. I'm checking that.

So this one crashes for stage3 compiler as well:

$ ./gcc/xgcc -Bgcc /tmp/reduced.ii 
/tmp/reduced.ii: In substitution of ‘template, class> struct
__enable_if [with bool  = true;  = _Tp]’:
/tmp/reduced.ii:5:24:   required from here
/tmp/reduced.ii:5:24: internal compiler error: Segmentation fault
5 | struct __enable_if
  |^~
0x10cbb63f crash_signal
../../gcc/toplev.c:328
0x1041f45c contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:3391
...
$ cat stage_current
stage3
$ file ./gcc/xgcc
./gcc/xgcc: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, with unknown
capability 0x4100 = 0x11676e75, with unknown capability 0x1 = 0x90401,
not stripped

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #42 from Segher Boessenkool  ---
Okay, I see your dumps are 64-bit as well.  But mine are very different, huh.
Still, it crashes in pretty much the same way.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #41 from Martin Liška  ---
Ok, the way how we build our compiler is to use:
./configure --with-cpu=default32

that should also lead to the ICE. I'm checking that.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #40 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #36)
> > > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > > but that builds stage2 as 64-bit?
> > 
> > Hm, that's possible. But the stage2 should not crash right?
> 
> It doesn't work, of course (mixed 32-bit and 64-bit thing).
> 
> And I need a 32-bit stage2 in any case, to have a compiler that miscompiles
> pt.c:tsubst_template_arg, to figure out why it thinks it as allowed to use
> GPR0 somewhere it obviously is live.

Ok, I've just run the build on gcc110 machine and you take a look at
/tmp/build.log. You are right that, using CC="gcc -m32" will cause that stage1
compiler is a cross from powerpc to powerpc64.
The miscompiled compiler is stage2:

$ file ./xgcc
./xgcc: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not
stripped

and it ICEs on a simple test-case:

$ ./xgcc -B. /tmp/reduced.ii
/tmp/reduced.ii: In substitution of ‘template, class> struct
__enable_if [with bool  = true;  = _Tp]’:
/tmp/reduced.ii:5:24:   required from here
/tmp/reduced.ii:5:24: internal compiler error: Segmentation fault
5 | struct __enable_if
  |^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ cat /tmp/reduced.ii
  template
  struct __enable_if
  { };
template
struct __enable_if
{ typedef _Tp __type; };

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #39 from Vladimir Makarov  ---
I've reverted the patch in trouble:

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=5dc1390b41db5c1765e25fd21dad1a930a015aac

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #38 from Segher Boessenkool  ---
Then, how did you do that?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #37 from Segher Boessenkool  ---
Oh wait.  I am dumb I guess?  You did those dumps with a stage1 compiler?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #36 from Segher Boessenkool  ---
> > I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> > but that builds stage2 as 64-bit?
> 
> Hm, that's possible. But the stage2 should not crash right?

It doesn't work, of course (mixed 32-bit and 64-bit thing).

And I need a 32-bit stage2 in any case, to have a compiler that miscompiles
pt.c:tsubst_template_arg, to figure out why it thinks it as allowed to use
GPR0 somewhere it obviously is live.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #35 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #33)
> (In reply to Martin Liška from comment #31)
> > (In reply to Segher Boessenkool from comment #30)
> > > I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> > > toolchain).
> > > Martin, you have a working recipe?
> > 
> > Go to gcc110 machine and do:
> > $ CC="gcc -m32" CXX="g++ -m32" ../configure --enable-languages=c,c++
> > --disable-lto
> > $ CC="gcc -m32" CXX="g++ -m32" make -j64 STAGE1_CFLAGS="-O2 -g"
> 
> I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
> but that builds stage2 as 64-bit?

Hm, that's possible. But the stage2 should not crash right?

> 
> Is that stage1 flags the secret sauce?

No that's not the secret sauce.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #34 from Segher Boessenkool  ---
(In reply to Vladimir Makarov from comment #29)
> Sorry for all the troubles with my latest patch and thank you for fair
> criticism.  I've decided to revert the patch as soon as git starts working. 
> I'll work to find a better solution after this.

Thanks!  Btw, on powerpc64-linux your patch changed the allocation order
of the non-volatile registers, which is a big regression (we need bigger
stack frames that way).

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #33 from Segher Boessenkool  ---
(In reply to Martin Liška from comment #31)
> (In reply to Segher Boessenkool from comment #30)
> > I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> > toolchain).
> > Martin, you have a working recipe?
> 
> Go to gcc110 machine and do:
> $ CC="gcc -m32" CXX="g++ -m32" ../configure --enable-languages=c,c++
> --disable-lto
> $ CC="gcc -m32" CXX="g++ -m32" make -j64 STAGE1_CFLAGS="-O2 -g"

I did that (with /usr/bin/gcc etc. though, won't work at all otherwise),
but that builds stage2 as 64-bit?

Is that stage1 flags the secret sauce?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #32 from Segher Boessenkool  ---
Sigh.  No, this is *not* a target bug (or we certainly do not know it is),
please stop marking it that.

It seems to be a bug in shrink-wrapping, but the dump does not show enough
information (only contradictory info :-/ ), and I cannot yet reproduce the
problem.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #31 from Martin Liška  ---
(In reply to Segher Boessenkool from comment #30)
> I cannot reproduce the problem, btw (I cannot build a 32-bit hosted
> toolchain).
> Martin, you have a working recipe?

Go to gcc110 machine and do:
$ CC="gcc -m32" CXX="g++ -m32" ../configure --enable-languages=c,c++
--disable-lto
$ CC="gcc -m32" CXX="g++ -m32" make -j64 STAGE1_CFLAGS="-O2 -g"

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #30 from Segher Boessenkool  ---
I cannot reproduce the problem, btw (I cannot build a 32-bit hosted toolchain).
Martin, you have a working recipe?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #29 from Vladimir Makarov  ---
Sorry for all the troubles with my latest patch and thank you for fair
criticism.  I've decided to revert the patch as soon as git starts working. 
I'll work to find a better solution after this.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[glaubitz at physik dot fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #36 from John Paul Adrian Glaubitz  ---
The m68k bootstrap also recently got broken (PR/94059). Currently testing
whether this is also a result of this change
(r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9).

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #35 from Andrew Pinski  ---
(In reply to Martin Liška from comment #15)
> Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9.

This change goes against what HONOR_REG_ALLOC_ORDER is documented on doing (I
Mean the false case of HONOR_REG_ALLOC_ORDER):
Normally, IRA tries to estimate the costs for saving a register in the
prologue and restoring it in the epilogue.  This discourages it from
using call-saved registers.  If a machine wants to ensure that IRA
allocates registers in the order given by REG_ALLOC_ORDER even if some
call-saved registers appear earlier than call-used ones, then define this
macro as a C expression to nonzero. Default is 0.

Since r8 is still a caller-saved register, HONOR_REG_ALLOC_ORDER should not
make a difference here.
The order for rs6000 is:
   MAYBE_R2_AVAILABLE   \
   9, 10, 8, 7, 6, 5, 4,\
   3, EARLY_R12 11, 0,  \

Still that should apply here rather than register number based.  Really doing
cost based on register # seems incorrect anyways.  These are all caller-saved
registers IIRC.

r0 is special in rs6000 where it sometimes cannot show up; e.g. base+reg base
cannot be r0.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #34 from Segher Boessenkool  ---
Yeah, 16 (or really 12-ish, not all are available) I call "tiny" :-)

It is very surprising (and not pleasantly so) that this overrides
REG_ALLOC_ORDER.  We allocate GPR0 last (of the volatile GPRs), on
purpose.  Other volatile registers we also do not do in order at all,
and this has been heavily tuned over the years.  And for non-GPRs it
is even more wild, like CRs are 0 7 5 6 1 (and yes, this matters).

We don't want HONOR_REG_ALLOC_ORDER, it is way *too* strict, but all
else being equal, we probably(*) want our order to be followed, as it
was before.


(*) I didn't actually benchmark things yet!

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #33 from Vladimir Makarov  ---
(In reply to Segher Boessenkool from comment #32)
> So it sounds like this helps for targets with tiny register sets?

I guess it helps for any target but of course more for ones with smaller
register sets. I'd call 16 reg file (x86-64, 32-bit arm) is small. Tiny one for
me would be for i386.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #32 from Segher Boessenkool  ---
So it sounds like this helps for targets with tiny register sets?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[vmakarov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #31 from Vladimir Makarov  ---
(In reply to Segher Boessenkool from comment #30)
> r10-6919 isn't good for Power, btw.  Why would it *ever* be a good idea?

This heuristic avoid creating small gaps in hard reg file which prevent
assignments for multi-reg pseudos.

It decreases average SPEC2000 code size and improves performance at least for
Intel i7-9700K (0.5% for SPECINT2000 and about 1% for SPECFP2000).  It also
solves some recent arm testsuite failures (expected use of callee-clobbered
hard regs for multi-regs pseudos).

I understand the frustration.  Sorry for creating it.  Unfortunately in RA
heuristic patches there is no a perfect solution.  Somebody will always be
upset.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #30 from Segher Boessenkool  ---
r10-6919 isn't good for Power, btw.  Why would it *ever* be a good idea?

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

Segher Boessenkool  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #29 from Segher Boessenkool  ---
I found the problem.

We have

===
/* Implement TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS.  */
void
rs6000_disqualify_components (sbitmap components, edge e,
  sbitmap edge_components, bool /*is_prologue*/)
{
  /* Our LR pro/epilogue code moves LR via R0, so R0 had better not be
 live where we want to place that code.  */
  if (bitmap_bit_p (edge_components, 0)
  && bitmap_bit_p (DF_LIVE_IN (e->dest), 0))
{
  if (dump_file)
fprintf (dump_file, "Disqualifying LR because GPR0 is live "
 "on entry to bb %d\n", e->dest->index);
  bitmap_clear_bit (components, 0);
}
}
===

But looks at LIVE_IN for the epilogue as well, which is wrong (should be
LIVE_OUT then, epilogue is placed at the end of the BB).

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #28 from Martin Liška  ---
Created attachment 47990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47990&action=edit
Attempt to self-contained test-case

There's a PRE that needs to be triggered for error_mark_node and I was unable
to force it to do..

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #27 from Martin Liška  ---
@Segher: Any of -fno-shrink-wrap-separate, -fno-shrink-wrap removes the
problem.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #26 from Martin Liška  ---
Created attachment 47985
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47985&action=edit
RTL dump files for the function - good

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #25 from Martin Liška  ---
Created attachment 47984
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47984&action=edit
RTL dump files for the function - bad

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #24 from Andrew Pinski  ---
(In reply to Martin Liška from comment #23)
> (In reply to Andrew Pinski from comment #20)
> > The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
> > being copied into r8 and then copied back into r3 (return value), but not r0
> > is used and that r0 is used for mtlr (moving back the return address).
> 
> This is the correct explanation, thanks Adrew.
> 
> In good version
>│0x104c9128 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+104> bl 
> 0x1049f300 <._Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0>
> 
> sets return value to $r3, which is then returned ($r8 = $r3, $r3 = $r8):
> (gdb) p   /x $r3
> $60 = 0x3fffaf3814d0
> 
> while in bad version we return value of:
>│0x104c9134 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+116> mtlr   
> r0
> (gdb) p   /x $r3
> $31 = 0x104c92a4
> 
> which is the return address (can be seen in back-trace).

Note I bet after LRA, there is a move between r0 and r3 after the call to
_Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 but it gets removed as r0 is
clobbered by the load.  So we need to understand why LRA/IRA assigns the
r_5/_34/_21 as r0 and then what also decides to use r0 for load/storing the LR.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #23 from Martin Liška  ---
(In reply to Andrew Pinski from comment #20)
> The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
> being copied into r8 and then copied back into r3 (return value), but not r0
> is used and that r0 is used for mtlr (moving back the return address).

This is the correct explanation, thanks Adrew.

In good version
   │0x104c9128 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+104> bl 
0x1049f300 <._Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0>

sets return value to $r3, which is then returned ($r8 = $r3, $r3 = $r8):
(gdb) p /x $r3
$60 = 0x3fffaf3814d0

while in bad version we return value of:
   │0x104c9134 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+116> mtlrr0
(gdb) p /x $r3
$31 = 0x104c92a4

which is the return address (can be seen in back-trace).

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #22 from Martin Liška  ---
> 
> good code stores:
> 0x104c9124 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+100> std
> r0,144(r1)
> (gdb) p   /x $r0
> $38 = 0x104c9294
> 
> but the wrong one into a different memory address:
> (gdb) p   /x $r0
> $28 = 0x104c92a4
> 

No this is correct, it's return value and it corresponds to backtraces:

#0  0x104c90c4 in ._Z19tsubst_template_argP9tree_nodeS0_iS0_ ()
#1  0x104c9294 in ._Z20tsubst_template_argsP9tree_nodeS0_iS0_ ()
#2  0x1049a3dc in ._ZL25get_partial_spec_bindingsP9tree_nodeS0_S0_ ()

vs.

#0  0x104c90c4 in ._Z19tsubst_template_argP9tree_nodeS0_iS0_ ()
#1  0x104c92a4 in ._Z20tsubst_template_argsP9tree_nodeS0_iS0_ ()
#2  0x1049a3dc in ._ZL25get_partial_spec_bindingsP9tree_nodeS0_S0_ ()

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #21 from Martin Liška  ---
(In reply to Andrew Pinski from comment #20)
> The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
> being copied into r8 and then copied back into r3 (return value), but not r0
> is used and that r0 is used for mtlr (moving back the return address).

Yes, I can confirm the $r0 is screwed. The value is equal in good/bad binary at
the beginning of the function:

(gdb) p /x $r0
$37 = 0x1049a3dc

good code stores:
0x104c9124 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+100> std
r0,144(r1)
(gdb) p /x $r0
$38 = 0x104c9294

but the wrong one into a different memory address:
(gdb) p /x $r0
$28 = 0x104c92a4

So yes, $r0 is used first here in bad version here:
   │0x104c90f4 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+52>  ld 
r0,0(r9)

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #20 from Andrew Pinski  ---
The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was
being copied into r8 and then copied back into r3 (return value), but not r0 is
used and that r0 is used for mtlr (moving back the return address).

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #19 from Martin Liška  ---
Ok, using the following patch:

diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def
index 232b192..7e45e46 100644
--- a/gcc/dbgcnt.def
+++ b/gcc/dbgcnt.def
@@ -173,6 +173,7 @@ DEBUG_COUNTER (if_conversion_tree)
 DEBUG_COUNTER (ipa_sra_params)
 DEBUG_COUNTER (ipa_sra_retvalues)
 DEBUG_COUNTER (ira_move)
+DEBUG_COUNTER (irahonor)
 DEBUG_COUNTER (ivopts_loop)
 DEBUG_COUNTER (local_alloc_for_sched)
 DEBUG_COUNTER (match)
diff --git a/gcc/ira-color.c b/gcc/ira-color.c
index a2bf108..908c717 100644
--- a/gcc/ira-color.c
+++ b/gcc/ira-color.c
@@ -35,6 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "ira-int.h"
 #include "reload.h"
 #include "cfgloop.h"
+#include "dbgcnt.h"

 typedef struct allocno_hard_regs *allocno_hard_regs_t;

@@ -1925,8 +1926,9 @@ assign_hard_reg (ira_allocno_t a, bool retry_p)
}
   if (min_cost > cost)
min_cost = cost;
+  bool honor = dbg_cnt(irahonor);
   if (min_full_cost > full_cost
- || (!HONOR_REG_ALLOC_ORDER && min_full_cost == full_cost
+ || (honor && !HONOR_REG_ALLOC_ORDER && min_full_cost == full_cost
  && best_hard_regno > hard_regno))
{
  min_full_cost = full_cost;

First bad: -fdbg-cnt=irahonor:788382
Last good: -fdbg-cnt=irahonor:788381

The change is only in function tsubst_template_arg:
diff -u /tmp/good.s /tmp/bad.s -U9
--- /tmp/good.s 2020-03-06 09:33:27.548791681 +0100
+++ /tmp/bad.s  2020-03-06 09:48:46.504419609 +0100
@@ -1,38 +1,37 @@
 mr. r7,r3
 beq 0x104c91x0 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+>
 lhz r8,0(r7)
 addis   r9,r2,-128
 addir9,r9,29456
 rldicr  r8,r8,2,61
 lwzxr9,r9,r8
 cmpwi   r9,2
 beq 0x104c91x0 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+>
 andi.   r9,r5,2
 addis   r9,r2,13
 addir9,r9,3152
-ld  r8,0(r9)
+stdur1,-128(r1)
+ld  r0,0(r9)
 bne 0x104c9160 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+160>
-std r31,-8(r1)
+std r31,120(r1)
 nop
 addir31,r2,22820
-cmpld   r7,r8
-stdur1,-128(r1)
+cmpld   r7,r0
 lwa r9,0(r31)
 addir10,r9,1
 stw r10,0(r31)
 beq 0x104c914x <._Z19tsubst_template_argP9tree_nodeS0_iS0_+>
 mflrr0
 li  r7,1
 std r0,144(r1)
 bl  0x1049f300 <._Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0>
 ld  r0,144(r1)
 lwz r9,0(r31)
-mr  r8,r3
 mtlrr0
 addir9,r9,-1
 extsw   r9,r9
-addir1,r1,128
 stw r9,0(r31)
-mr  r3,r8
-ld  r31,-8(r1)
+ld  r31,120(r1)
+mr  r3,r0
+addir1,r1,128
 blr

Optimized dump of the problematic function:

tsubst_template_arg (union tree_node * t, union tree_node * args,
tsubst_flags_t complain, union tree_node * in_decl)
{
  union tree_node * r;
  short unsigned int _1;
  int _2;
  tree_code_class _3;
  union tree_node * pretmp_14;
  int _15;
  int c_inhibit_evaluation_warnings.2997_16;
  int _17;
  int pretmp_18;
  union tree_node * _19;
  union tree_node * _21;
  int prephitmp_27;
  int _30;
  union tree_node * _34;

   [local count: 1073741823]:
  if (t_6(D) == 0B)
goto ; [30.00%]
  else
goto ; [70.00%]

   [local count: 751619280]:
  _1 = t_6(D)->base.code;
  _2 = (int) _1;
  _3 = tree_code_type[_2];
  if (_3 == 2)
goto ; [20.24%]
  else
goto ; [79.76%]

   [local count: 152127741]:
  r_12 = tsubst (t_6(D), args_9(D), complain_8(D), in_decl_10(D)); [tail call]
  goto ; [100.00%]

   [local count: 599491539]:
  _15 = complain_8(D) & 2;
  pretmp_14 = global_trees[0];
  if (_15 == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 299745769]:
  c_inhibit_evaluation_warnings.2997_16 = c_inhibit_evaluation_warnings;
  _17 = c_inhibit_evaluation_warnings.2997_16 + 1;
  c_inhibit_evaluation_warnings = _17;
  if (t_6(D) == pretmp_14)
goto ; [30.95%]
  else
goto ; [69.05%]

   [local count: 299745769]:
  # _21 = PHI <_34(10), pretmp_14(6)>
  # prephitmp_27 = PHI <_30(10), c_inhibit_evaluation_warnings.2997_16(6)>
  c_inhibit_evaluation_warnings = prephitmp_27;

   [local count: 1073741824]:
  # r_5 = PHI 
  return r_5;

   [local count: 299745770]:
  if (t_6(D) == pretmp_14)
goto ; [30.95%]
  else
goto ; [69.05%]

   [local count: 206974454]:
  _34 = _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 (t_6(D), args_9(D),
complain_8(D), in_decl_10(D), 1);
  pretmp_18 = c_inhibit_evaluation_warnings;
  _30 = pretmp_18 + -1;
  goto ; [100.00%]

   [local count: 206974454]:
  _19 = _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 (t_6(D), args_9(D),
complain_8(D), in_decl_10(D), 1); [tail call]
  goto ; [100.00%]

}

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #18 from Martin Liška  ---
I'll try to make part of the condition:

+ || (!HONOR_REG_ALLOC_ORDER && min_full_cost == full_cost
+ && best_hard_regno > hard_regno))

to be controllable by debug counter.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #17 from Martin Liška  ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Martin Liška from comment #15)
> > Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9.
> 
> This should just change the costs of the register usage.  Which means it
> might be a latent bug before this patch.

Yep. The miscompiled file is really cp/pt.c. The issue with the revision is
that the assembly of pt.o is completely different as a lower register is
preferred.

[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042

--- Comment #16 from Andrew Pinski  ---
(In reply to Martin Liška from comment #15)
> Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9.

This should just change the costs of the register usage.  Which means it might
be a latent bug before this patch.