https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #6)
> It's late and I need to catch some zzzs. But as I hinted in my prior update,
> I think we may chasing something latent. I would recommend looking very
> closely at r204497, which my bisecting implicated as the failing commit for
> a severely hacked up test.
>
> Reverting r204497 by hand on the trunk results in the original testcase
> working properly. I'm too tired to really analyze, but I think it's worth a
> looksie.
I never said r207605 was the buggy change, after all, as only the EPILOGUE_USES
definition itself makes the code misbehave, it is clear it only triggers a
latent issue. For any case we need to find out what is actually miscompiled in
the testcase and from that why.
I've tried this morning following hack on top of r207605:
--- sched-deps.c.xx 2014-08-11 12:05:39.000000000 +0200
+++ sched-deps.c 2014-08-12 09:51:48.540485357 +0200
@@ -3034,6 +3034,14 @@ sched_analyze_insn (struct deps_desc *de
|| (NONJUMP_INSN_P (insn) && control_flow_insn_p (insn)))
reg_pending_barrier = MOVE_BARRIER;
+ if (!DEBUG_INSN_P (insn) && reload_completed && getenv ("SKIPB") && getenv
("SKIPE"))
+ {
+ static int cntskip;
+ ++cntskip;
+ if (cntskip > atoi (getenv ("SKIPB")) && cntskip < atoi (getenv
("SKIPE")))
+ reg_pending_barrier = TRUE_BARRIER;
+ }
+
if (sched_pressure != SCHED_PRESSURE_NONE)
{
setup_insn_reg_uses (deps, insn);
and it seems that with:
./cc1 -m31 -O2 -march=z196 -mtune=z10 sha.c -o sha1.s -quiet -nostdinc;
SKIPB=6261 SKIPE=6263 ./cc1 -m31 -O2 -march=z196 -mtune=z10 sha.c -o sha2.s
-quiet -nostdinc
sha1.s is expectedly miscompiled, while sha2.s gives the correct result and
differs just in a single true barrier during sched2, i.e. no changes in split2
dump, and just small amount of changes in the sched2 dump.
