https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #25 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #22)
> (In reply to Martin Liška from comment #17)
> > For me tree optimized dump is correct, so likely a target issue.
>
> Yeah, I agree. I finally underst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #24 from Sergei Trofimovich ---
(In reply to Sergei Trofimovich from comment #23)
> cvise managed to shrink example down to the following:
For completeness assembly output difference is very clear now:
$ hppa2.0-unknown-linux-gnu-gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #23 from Sergei Trofimovich ---
cvise managed to shrink example down to the following:
"""
int b, c;
int a() __attribute__((noipa));
int a(int *d, int *f, int g) {
int e;
if (d == f)
e = 0;
else
e = 1;
switch (g) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #22 from Sergei Trofimovich ---
(In reply to Martin Liška from comment #17)
> For me tree optimized dump is correct, so likely a target issue.
Yeah, I agree. I finally understood why memory loads disappear (duh!).
> @Sergei: Is GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #21 from Sergei Trofimovich ---
(In reply to Eric Botcazou from comment #18)
> If the control flow goes through .L12:
>
> .L12:
> b .L3; return 0; (not interesting, fall through)
> ldi 1,%r28
>
> the return value w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #20 from Sergei Trofimovich ---
Created attachment 48828
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48828&action=edit
good.S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #19 from Sergei Trofimovich ---
Created attachment 48827
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48827&action=edit
bad.S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #16 from Sergei Trofimovich ---
If I looks at bad-bug.c.190t.dse3 I see 'self' and 'other' refer to the same
.MEM_10 memory location in 'basic block 5'. I think it should not, 'basic block
4' jumps into bb5 only when self != other. Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #15 from Sergei Trofimovich ---
Created attachment 48822
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48822&action=edit
bad-bug.c.190t.dse3
bad-bug.c.190t.dse3 previous tree phase for comparison.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #14 from Sergei Trofimovich ---
Created attachment 48821
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48821&action=edit
bad-bug.c.191t.cddce3
bad-bug.c.191t.cddce3 is the full file generated by -fdump-tree-all-all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #13 from Jeffrey A. Law ---
Hmm, there's a control dependency though in bb13:
[local count: 242478389]:
# result_21 = PHI <1(5), sign_17(6)>
switch (op_14(D)) [33.33%], case 0: [16.67%], case 1:
[50.00%], case 3: [50.00%],
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #12 from Jeffrey A. Law ---
The block in question goes away because it serves no purpose:
[local count: 242478389]:
_13 = *self_11(D);
_16 = *other_12(D);
sign_17 = _13 - _16;
if (sign_17 == 0)
goto ; [34.00%]
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #11 from Sergei Trofimovich ---
Looking at -fdump-tree-all:
$gcc/xgcc -B$gcc -lm -Wsign-compare -Wall -fno-PIE -no-pie
-fno-stack-protector -O2 -S bug_test.c -o bad-bug.S -fdump-tree-all
I see that stores are eliminated at 'bad-b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #10 from Sergei Trofimovich ---
Created attachment 48820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48820&action=edit
good-bug.S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #9 from Sergei Trofimovich ---
(In reply to Martin Liška from comment #7)
> There's ASM diff in between GCC 9 and 10 version:
>
> diff -u good.s bad.s
> --- good.s2020-07-01 15:04:58.315839436 +0200
> +++ bad.s 202
0-07-01 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #8 from Martin Liška ---
And first change happens in pr96015.c.299r.bbro which is likely a reason why a
jump table is partially copied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #7 from Martin Liška ---
There's ASM diff in between GCC 9 and 10 version:
diff -u good.s bad.s
--- good.s 2020-07-01 15:04:58.315839436 +0200
+++ bad.s 2020-07-01 15:04:30.684040487 +0200
@@ -30,7 +30,7 @@
.L15:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #6 from Sergei Trofimovich ---
Created attachment 48816
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48816&action=edit
bad-bug.S
bad-bug.S is miscompiled file generated by main gcc (not clear what is wrong
yet).
Generated as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #5 from Sergei Trofimovich ---
I ran the test in qemu-hppa (qemu user binary emulation) against Gentoo's
hppa2.0 root system as:
/usr/bin/qemu-hppa -L /usr/hppa2.0-unknown-linux-gnu/ "$@"
where /usr/hppa2.0-unknown-linux-gnu/ is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.2
Keywords|
23 matches
Mail list logo
