* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
@ 2014-08-05 14:58 ` jakub at gcc dot gnu.org
2014-08-05 15:02 ` jakub at gcc dot gnu.org
` (21 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-05 14:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.9.2
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In *.sched1 I see no significant insn changes in between r207604 (works) and
r207605 (aborts), just r14 is mentioned live on entry of various bbs.
The testcase fails at r207605 also with -O2 -m31 -march=z196 -mtune=z10
-mno-lra.
Richard or Andreas, can you please have a look?
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
2014-08-05 14:58 ` [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c jakub at gcc dot gnu.org
@ 2014-08-05 15:02 ` jakub at gcc dot gnu.org
2014-08-11 14:02 ` jakub at gcc dot gnu.org
` (20 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-05 15:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
-fno-shrink-wrap doesn't help.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
2014-08-05 14:58 ` [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c jakub at gcc dot gnu.org
2014-08-05 15:02 ` jakub at gcc dot gnu.org
@ 2014-08-11 14:02 ` jakub at gcc dot gnu.org
2014-08-11 16:47 ` jakub at gcc dot gnu.org
` (19 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-11 14:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, when I replace the if+abort with a printout of all the 8 c.h[] values and
take a poll of the results from:
./cc1.208700 -m31 -O0 sha.c -o sha0.s -quiet -nostdinc
./cc1.207604 -nostdinc -quiet -O2 -m31 -march=z196 -mtune=z10 sha.c -o sha1.s
./cc1.207605 -nostdinc -quiet -O2 -m31 -march=z196 -mtune=z10 sha.c -o sha2.s
./cc1.207604 -nostdinc -quiet -O2 -mno-lra -m31 -march=z196 -mtune=z10 sha.c -o
sha3.s
./cc1.207605 -nostdinc -quiet -O2 -m31 -march=z196 -mno-lra -mtune=z10 sha.c -o
sha4.s
/usr/src/gcc/objz/gcc/cc1 -nostdinc -quiet -O2 -m31 -march=z196 -mtune=z10
sha.c -o sha5.s
/usr/src/gcc/objz/gcc/cc1 -nostdinc -quiet -O2 -m31 -march=z196 -mtune=z10
sha.c -o sha6.s -mno-lra
where /usr/src/gcc/objz/gcc/cc1 is trunk from around Aug 5th, I get different
results from the testcase, and also if I remove the last line or two lines from
the loop in the function. But which function have different result from the
-O0 results depends on how many lines are removed.
With no lines removed (G for results matching -O0, B for different result):
GGBGBBB
With the last line removed the results are GBGBBGB.
With the last two lines removed GBGBBGG, when 3 or more lines from the loop are
removed, all results are the same (i.e. all Gs).
As I believe the testcase doesn't have undefined behavior with any of the loop
lines removed, this shows that perhaps the shrink wrapping case just changed
things big enough that some RA or later issue either started appearing, or went
away.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-08-11 14:02 ` jakub at gcc dot gnu.org
@ 2014-08-11 16:47 ` jakub at gcc dot gnu.org
2014-08-12 4:07 ` law at redhat dot com
` (18 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-11 16:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've applied on top of r207604 just the
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/s390/s390.h?r1=207605&r2=207604&pathrev=207605
change and the testcase was miscompiled too, so the bug is just triggered by
different RA decisions from having reg 14 live on the epilogue.
The miscompilation goes away with -fno-schedule-insns2, but also with
-fno-schedule-insns -fschedule-insns2, but as I said earlier, appart from
different live in/out lr in/out (including r14 there) *.sched1 dump doesn't
contain any real insn changes.
Note only -mtune=z10 is miscompiled, other tuning options are ok.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2014-08-11 16:47 ` jakub at gcc dot gnu.org
@ 2014-08-12 4:07 ` law at redhat dot com
2014-08-12 6:52 ` amker at gcc dot gnu.org
` (17 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: law at redhat dot com @ 2014-08-12 4:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com
--- Comment #5 from Jeffrey A. Law <law at redhat dot com> ---
While r207605 may be the trigger for the failure for this test. I can twiddle
the test so that it fails with 207604 and 207605. I'm starting to wonder if
207605 just tripped something latent.
I'm still looking, but we may have been totally barking up the wrong tree
focusing on 207605.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2014-08-12 4:07 ` law at redhat dot com
@ 2014-08-12 6:52 ` amker at gcc dot gnu.org
2014-08-12 6:53 ` law at redhat dot com
` (16 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: amker at gcc dot gnu.org @ 2014-08-12 6:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
amker at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amker at gcc dot gnu.org
--- Comment #7 from amker at gcc dot gnu.org ---
Oh, it's my commit, I will have a look if you are ok with that.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2014-08-12 6:52 ` amker at gcc dot gnu.org
@ 2014-08-12 6:53 ` law at redhat dot com
2014-08-12 8:17 ` jakub at gcc dot gnu.org
` (15 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: law at redhat dot com @ 2014-08-12 6:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
More eyes never hurt :-) This pair is going to bed.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2014-08-12 6:53 ` law at redhat dot com
@ 2014-08-12 8:17 ` jakub at gcc dot gnu.org
2014-08-12 8:55 ` jakub at gcc dot gnu.org
` (14 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-12 8:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2014-08-12 8:17 ` jakub at gcc dot gnu.org
@ 2014-08-12 8:55 ` jakub at gcc dot gnu.org
2014-08-12 9:57 ` jakub at gcc dot gnu.org
` (13 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-12 8:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And with:
--- sched-deps.c (revision 207605)
+++ sched-deps.c (working copy)
@@ -3034,6 +3034,21 @@ 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 (!DEBUG_INSN_P (insn) && reload_completed && getenv ("FLUSHB") && getenv
("FLUSHE"))
+ {
+ static int cntskip;
+ ++cntskip;
+ if (cntskip > atoi (getenv ("FLUSHB")) && cntskip < atoi (getenv
("FLUSHE")))
+ flush_pending_lists (deps, insn, true, true);
+ }
+
if (sched_pressure != SCHED_PRESSURE_NONE)
{
setup_insn_reg_uses (deps, insn);
again, on top of r207605, and -O2 -m31 -march=z196 -mtune=z10, I get no
miscompilation with
FLUSHB=6261 FLUSHE=6263 ./cc1 -m31 -O2 -march=z196 -mtune=z10 sha.c -o sha3.s
-quiet -nostdinc
diff -up -U8 sha1.s sha3.s
--- sha1.s 2014-08-12 10:40:14.813740998 +0200
+++ sha3.s 2014-08-12 10:46:58.425686712 +0200
@@ -6246,38 +6246,38 @@ sha512_block_data_order:
lm %r2,%r3,312(%r15)
x %r11,152(%r15)
or %r5,%r8
l %r8,276(%r15)
n %r9,216(%r15)
srl %r4,7
n %r11,184(%r15)
al %r3,252(%r8)
- ahi %r8,128
- alc %r2,120(%r8)
+ alc %r2,248(%r8)
+ x %r0,1104(%r15)
xr %r11,%r9
st %r11,1072(%r15)
- xr %r1,%r5
n %r7,188(%r15)
- x %r0,1104(%r15)
- st %r8,276(%r15)
+ xr %r1,%r5
stm %r2,%r3,120(%r15)
st %r0,1084(%r15)
l %r3,116(%r15)
sll %r3,25
lr %r6,%r3
l %r3,224(%r15)
xr %r3,%r10
st %r3,1068(%r15)
l %r3,156(%r15)
l %r2,232(%r15)
xr %r2,%r12
st %r2,1088(%r15)
- lm %r10,%r11,120(%r15)
n %r3,220(%r15)
+ ahi %r8,128
+ lm %r10,%r11,120(%r15)
+ st %r8,276(%r15)
al %r11,164(%r15)
alc %r10,160(%r15)
xr %r7,%r3
st %r7,1076(%r15)
lr %r3,%r11
or %r6,%r4
lm %r4,%r5,304(%r15)
al %r3,1068(%r15)
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2014-08-12 8:55 ` jakub at gcc dot gnu.org
@ 2014-08-12 9:57 ` jakub at gcc dot gnu.org
2014-08-12 10:38 ` amker at gcc dot gnu.org
` (12 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-12 9:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-08-12
Ever confirmed|0 |1
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And the bug in that is that in sha1.s (the miscompiled one) sched2 wrongly
scheduled ahi %r8,128 which clobbers %cc in between a %cc producer and %cc
consumer. If I manually fix that up as follows:
--- sha1.s 2014-08-12 08:39:50.694224146 -0400
+++ sha4.s 2014-08-12 09:38:58.914224146 -0400
@@ -6251,8 +6251,8 @@ sha512_block_data_order:
srl %r4,7
n %r11,184(%r15)
al %r3,252(%r8)
+ alc %r2,248(%r8)
ahi %r8,128
- alc %r2,120(%r8)
xr %r11,%r9
st %r11,1072(%r15)
xr %r1,%r5
then the testcase succeeds.
In *.split2 we have:
(insn 11376 7193 11377 5 (parallel [
(set (reg:CCL1 33 %cc)
(compare:CCL1 (plus:SI (reg:SI 3 %r3 [orig:2900 D.1817+4 ]
[2900])
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ]
[65])
(const_int 252 [0xfc])) [2 MEM[base: _25,
offset: 248B]+4 S4 A32]))
(reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])))
(set (reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])
(plus:SI (reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
(const_int 252 [0xfc])) [2 MEM[base: _25, offset:
248B]+4 S4 A32])))
]) 329 {*addsi3_carry1_cc}
(nil))
(insn 11377 11376 7194 5 (parallel [
(set (reg:SI 2 %r2 [ D.1817 ])
(plus:SI (plus:SI (ltu:SI (reg:CCL1 33 %cc)
(const_int 0 [0]))
(reg:SI 2 %r2 [ D.1817 ]))
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
(const_int 248 [0xf8])) [2 MEM[base: _25, offset:
248B]+0 S4 A64])))
(clobber (reg:CC 33 %cc))
]) 407 {*addsi3_alc}
(expr_list:REG_DEAD (reg:CCL1 33 %cc)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil))))
...
(insn 2799 7206 7208 5 (parallel [
(set (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
(plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
(const_int 128 [0x80])))
(clobber (reg:CC 33 %cc))
]) 327 {*addsi3}
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)))
In *.sched2 dump this is (+ is from normal r207605 compilation, - from
FLUSHB=6261 FLUSHE=6263 (i.e. - is working one, + is miscompiled one):
+(insn:TI 11376 2759 2799 5 (parallel [
(set (reg:CCL1 33 %cc)
(compare:CCL1 (plus:SI (reg:SI 3 %r3 [orig:2900 D.1817+4 ]
[2900])
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ]
[65])
(const_int 252 [0xfc])) [2 MEM[base: _25,
offset: 248B]+4 S4 A32]))
(reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])))
(set (reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])
(plus:SI (reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
(const_int 252 [0xfc])) [2 MEM[base: _25, offset:
248B]+4 S4 A32])))
]) 329 {*addsi3_carry1_cc}
(nil))
-(insn:TI 11377 11376 2773 5 (parallel [
+(insn:TI 2799 11376 11377 5 (parallel [
+ (set (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
+ (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
+ (const_int 128 [0x80])))
+ (clobber (reg:CC 33 %cc))
+ ]) 327 {*addsi3}
+ (expr_list:REG_UNUSED (reg:CC 33 %cc)
+ (nil)))
+(insn:TI 11377 2799 2763 5 (parallel [
(set (reg:SI 2 %r2 [ D.1817 ])
(plus:SI (plus:SI (ltu:SI (reg:CCL1 33 %cc)
(const_int 0 [0]))
(reg:SI 2 %r2 [ D.1817 ]))
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
- (const_int 248 [0xf8])) [2 MEM[base: _25, offset:
248B]+0 S4 A64])))
+ (const_int 120 [0x78])) [2 MEM[base: _25, offset:
248B]+0 S4 A64])))
(clobber (reg:CC 33 %cc))
]) 407 {*addsi3_alc}
(expr_list:REG_DEAD (reg:CCL1 33 %cc)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil))))
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2014-08-12 9:57 ` jakub at gcc dot gnu.org
@ 2014-08-12 10:38 ` amker at gcc dot gnu.org
2014-08-12 11:06 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: amker at gcc dot gnu.org @ 2014-08-12 10:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #12 from amker at gcc dot gnu.org ---
Hi,
I can reproduce the exact mis-scheduled instruction issue as in Jakub's comment
with/without the ivopt patch (204497). Turns out gcc chooses candidate like
{&K512, 128}_loop with the patch while candidate {&K512[16], 128}_loop without
the patch. This is caused by candidate cost change. As far as I can see, both
candidate are good for the iv use and shouldn't generate wrong code either.
The interesting thing is, mis-scheduled instruction is the only code difference
(apart from some offset difference as base of candidates are different) caused
by ivopt patch. Normally middle-end patch should have larger impact on
generated code if there is. I will have a look why different iv candidate can
result in one instruction mis-scheduled. Maybe it's useful for investigation.
Anyway, I think 204497 is generally fine in this case.
Thanks,
bin
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2014-08-12 10:38 ` amker at gcc dot gnu.org
@ 2014-08-12 11:06 ` jakub at gcc dot gnu.org
2014-08-12 11:47 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-12 11:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Just verified the trunk and it is the same thing there, also sched2 generating:
al %r3,252(%r8)
ahi %r8,128
alc %r2,120(%r8)
where the first insn is cc setter, second cc clobber and third cc user and
clobber, so the r8=r8+128 insn should not have been scheduled in between those
two. It seems scheduler has some code to adjust the address (248 -> 120) based
on the r8 adjustment, otherwise it would be wrong to move it even because of r8
register, perhaps if we take that path we don't fully check other side effects
(cc clobber in this case). s390 AFAIK doesn't have addition which doesn't
clobber flags, unlike many other architectures.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2014-08-12 11:06 ` jakub at gcc dot gnu.org
@ 2014-08-12 11:47 ` jakub at gcc dot gnu.org
2014-08-12 12:17 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-12 11:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bernds at gcc dot gnu.org
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems that is the http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00155.html
minipass, supposedly when it sees that it could break a reg dependency (on r8
in this case), it just ignores the fact that it can have other side effects.
parse_add_or_inc uses single_set which will return the increment SET even if
there are extra clobbers. Giving up would make the minipass useless on many
architectures, so I think we just need to make sure that we ignore the reg
dependency only on the address register (r8 here), but not for the clobbered
regs.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2014-08-12 11:47 ` jakub at gcc dot gnu.org
@ 2014-08-12 12:17 ` jakub at gcc dot gnu.org
2014-08-12 14:30 ` law at redhat dot com
` (8 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-12 12:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, what about this completely untested fix? Unfortunately the scheduler
change has been committed with no testcases. I guess I'll do a
bootstrap/regtest with some printout where this patch changes things and where
we consider it at all.
--- gcc/sched-deps.c.jj 2014-08-06 10:34:13.000000000 +0200
+++ gcc/sched-deps.c 2014-08-12 14:12:06.625193731 +0200
@@ -4751,6 +4751,24 @@ find_inc (struct mem_inc_info *mii, bool
"inc conflicts with store failure.\n");
goto next;
}
+
+ /* The inc instruction could have clobbers, make sure those
+ registers are not used in mem insn. */
+ FOR_EACH_INSN_DEF (def, mii->inc_insn)
+ if (!reg_overlap_mentioned_p (DF_REF_REG (def), mii->mem_reg0))
+ {
+ df_ref use;
+ FOR_EACH_INSN_USE (use, mii->mem_insn)
+ if (reg_overlap_mentioned_p (DF_REF_REG (def),
+ DF_REF_REG (use)))
+ {
+ if (sched_verbose >= 5)
+ fprintf (sched_dump,
+ "inc clobber used in store failure.\n");
+ goto next;
+ }
+ }
+
newaddr = mii->inc_input;
if (mii->mem_index != NULL_RTX)
newaddr = gen_rtx_PLUS (GET_MODE (newaddr), newaddr,
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2014-08-12 12:17 ` jakub at gcc dot gnu.org
@ 2014-08-12 14:30 ` law at redhat dot com
2014-08-12 21:25 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: law at redhat dot com @ 2014-08-12 14:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #16 from Jeffrey A. Law <law at redhat dot com> ---
In reference to c#12. I think the ivopts changes are just setting up the
situation that is mis-handled later. I'd gotten as far as seeing the +128
increment moving in the scheduler, but hadn't looked to see if it was valid.
Anyway, so yes I think the ivopts stuff is fine.
I should have realized I was chasing something of that nature when the
bisection settled on the ivopts code as the trigger.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2014-08-12 14:30 ` law at redhat dot com
@ 2014-08-12 21:25 ` jakub at gcc dot gnu.org
2014-08-12 22:04 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-12 21:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue Aug 12 21:24:40 2014
New Revision: 213887
URL: https://gcc.gnu.org/viewcvs?rev=213887&root=gcc&view=rev
Log:
PR target/62025
* sched-deps.c (find_inc): Check if inc_insn doesn't clobber
any registers that are used in mem_insn.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2014-08-12 21:25 ` jakub at gcc dot gnu.org
@ 2014-08-12 22:04 ` jakub at gcc dot gnu.org
2014-08-13 4:22 ` amker.cheng at gmail dot com
` (5 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-12 22:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Tue Aug 12 22:03:37 2014
New Revision: 213888
URL: https://gcc.gnu.org/viewcvs?rev=213888&root=gcc&view=rev
Log:
PR target/62025
* sched-deps.c (find_inc): Check if inc_insn doesn't clobber
any registers that are used in mem_insn.
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/sched-deps.c
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (16 preceding siblings ...)
2014-08-12 22:04 ` jakub at gcc dot gnu.org
@ 2014-08-13 4:22 ` amker.cheng at gmail dot com
2014-08-13 16:25 ` [Bug target/62025] [4.9/5 " jakub at gcc dot gnu.org
` (4 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: amker.cheng at gmail dot com @ 2014-08-13 4:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
bin.cheng <amker.cheng at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amker.cheng at gmail dot com
--- Comment #19 from bin.cheng <amker.cheng at gmail dot com> ---
(In reply to Jeffrey A. Law from comment #16)
> In reference to c#12. I think the ivopts changes are just setting up the
> situation that is mis-handled later. I'd gotten as far as seeing the +128
> increment moving in the scheduler, but hadn't looked to see if it was valid.
>
> Anyway, so yes I think the ivopts stuff is fine.
>
> I should have realized I was chasing something of that nature when the
> bisection settled on the ivopts code as the trigger.
Yes, The scheduling behavior is triggered by specific offset in this case. It
changes below insn sequence:
11405: ......
11406: {%r2:SI=ltu(%cc:CCL1,0)+%r2:SI+[%r8:SI+0xf8];clobber %cc:CC;}
......
2803: {%r8:SI=%r8:SI+0x80;clobber %cc:CC;}
REG_UNUSED %cc:CC
into:
11405: ......
2803: {%r8:SI=%r8:SI+0x80;clobber %cc:CC;}
REG_UNUSED %cc:CC
11406: {%r2:SI=ltu(%cc:CCL1,0)+%r2:SI+[%r8:SI+0x78];clobber %cc:CC;}
by changing the offset in insn 11406.
The problem is why minipass in
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00155.html would do this
transformation. According to the description, it is to change
rn++
rm=[rn]
into
rm=[rn+4]
rn++
Here it is exactly the opposite tranformation and introducing more dependency.
Thanks.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/5 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (17 preceding siblings ...)
2014-08-13 4:22 ` amker.cheng at gmail dot com
@ 2014-08-13 16:25 ` jakub at gcc dot gnu.org
2014-08-13 16:27 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-13 16:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 33314
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33314&action=edit
pr62025.c
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/5 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (18 preceding siblings ...)
2014-08-13 16:25 ` [Bug target/62025] [4.9/5 " jakub at gcc dot gnu.org
@ 2014-08-13 16:27 ` jakub at gcc dot gnu.org
2014-09-01 11:16 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-08-13 16:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 33315
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33315&action=edit
pr62025-2.c
Possible testcase for the testsuite. Except this one only used to be
miscompiled with trunk and not 4.9 branch, and unfortunately also needs
-march=z900 at least, so we'd need effective-target for 64-bit s390-*-*.
Perhaps not worth adding this into the testsuite.
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/5 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (19 preceding siblings ...)
2014-08-13 16:27 ` jakub at gcc dot gnu.org
@ 2014-09-01 11:16 ` jakub at gcc dot gnu.org
2014-09-01 11:50 ` jakub at gcc dot gnu.org
2014-10-14 14:01 ` jakub at gcc dot gnu.org
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-09-01 11:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon Sep 1 11:15:41 2014
New Revision: 214786
URL: https://gcc.gnu.org/viewcvs?rev=214786&root=gcc&view=rev
Log:
PR target/62025
* sched-deps.c (add_or_update_dep_1): If ask_dependency_caches
returned DEP_PRESENT, make sure to set DEP_MULTIPLE on present_dep.
(find_inc): Revert 2014-08-13 change.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/5 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (20 preceding siblings ...)
2014-09-01 11:16 ` jakub at gcc dot gnu.org
@ 2014-09-01 11:50 ` jakub at gcc dot gnu.org
2014-10-14 14:01 ` jakub at gcc dot gnu.org
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-09-01 11:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon Sep 1 11:49:36 2014
New Revision: 214790
URL: https://gcc.gnu.org/viewcvs?rev=214790&root=gcc&view=rev
Log:
PR target/62025
* sched-deps.c (add_or_update_dep_1): If ask_dependency_caches
returned DEP_PRESENT, make sure to set DEP_MULTIPLE on present_dep.
(find_inc): Revert 2014-08-12 change.
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/sched-deps.c
^ permalink raw reply [flat|nested] 23+ messages in thread* [Bug target/62025] [4.9/5 Regression] Miscompilation of openssl sha512.c
[not found] <bug-62025-4@http.gcc.gnu.org/bugzilla/>
` (21 preceding siblings ...)
2014-09-01 11:50 ` jakub at gcc dot gnu.org
@ 2014-10-14 14:01 ` jakub at gcc dot gnu.org
22 siblings, 0 replies; 23+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-10-14 14:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Should be fixed for 4.9.2+.
^ permalink raw reply [flat|nested] 23+ messages in thread