https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067
--- Comment #6 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #5)
> I briefly looked at the other BZ last week, but didn't make much headway.
> The first thing that stood out was why are we threading around the loop. I
> thou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #7 from Aldy Hernandez ---
After chatting with Andrew about this, it seems the problem is we are starting
a path mid-loop and crossing a backedge. This causes us to use relations we
had on one iteration in another iteration.
[lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #6 from Aldy Hernandez ---
Please bear with me, as I'm coming up to speed, and my head hurts from all
these equivalences.
The problem seems to be what Jeff mentioned in comment #4.
We think _5 == _6, which makes the conditional in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103690
--- Comment #5 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #2)
> (gdb) p debug_gimple_stmt(stmt)
> _67 = _14 + _66;
>
>
> Before pre had:
> intD.9 * __trans_tmp_1D.2946;
>
> # RANGE [1, 9223372036854775807] NONZERO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103603
Aldy Hernandez changed:
What|Removed |Added
Target Milestone|11.3|---
--- Comment #1 from Aldy Hernandez
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103551
--- Comment #3 from Aldy Hernandez ---
Haven't looked, but things to look out for are the global ranges that the
strlen pass sets that may affect VRP decisions. Also, one of the calls to
ranger from within the strlen pass may have the wrong cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
--- Comment #14 from Aldy Hernandez ---
(In reply to hubicka from comment #13)
> > I've fixed the threading slowdown. Can someone verify and close this PR if
> > all
> > the slowdown has been accounted for? If not, then someone needs to explo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
--- Comment #7 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #6)
> The other is to introduce the solver into the predicate analysis pass which
> starts to touch on other ideas I've had. Namely that thread discovery and
> pred
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
--- Comment #12 from Aldy Hernandez ---
I've fixed the threading slowdown. Can someone verify and close this PR if all
the slowdown has been accounted for? If not, then someone needs to explore any
slowdown unrelated to the threader.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #6 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #4)
> Created attachment 51908 [details]
> untested patch
>
> Like this. It fixes the problem at least for -O2.
Richi responded that the current BB copier won't ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
--- Comment #5 from Aldy Hernandez ---
[from the POC patch]
It seems that every missed thread (due to inability of the threader,
or due to cost restraints) is a potential false positive for the
uninit code. Perhaps what we need is a way to iden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
--- Comment #4 from Aldy Hernandez ---
Created attachment 51913
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51913&action=edit
proof of concept to reduce uninit warnings with the path solver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100047
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
||aldyh at gcc dot gnu.org,
||amacleod at redhat dot com,
||rguenth at gcc dot gnu.org
--- Comment #5 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #1)
> The backwa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
--- Comment #3 from Aldy Hernandez ---
> && !(leapcnt == 0
>|| (prevcorr < corr
>? corr == prevcorr + 1
>: (corr == prevcorr
> || corr =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 61112, which changed state.
Bug 61112 Summary: Simple example triggers false-positive -Wmaybe-uninitialized
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112
What|Removed |Adde
|RESOLVED
CC||aldyh at gcc dot gnu.org
--- Comment #10 from Aldy Hernandez ---
the snippets in comment 1, 5, and 9 no longer warn on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #5 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #4)
> Created attachment 51908 [details]
> untested patch
>
> Like this. It fixes the problem at least for -O2.
For -O1 y'all are on your own because there are no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
--- Comment #5 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Aldy Hernandez from comment #3)
> > The warning on the above IL seems legit.
> >
> > x_5 is initialized from b$i_11 when b & 1 == 0, but the read f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #4 from Aldy Hernandez ---
Created attachment 51908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51908&action=edit
untested patch
Like this. It fixes the problem at least for -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 99756, which changed state.
Bug 99756 Summary: bogus -Wmaybe-uninitialized with a use conditional that's a
subset of a defining conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99756
What|Removed
||aldyh at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Aldy Hernandez ---
Fixed in trunk by one of the various improvements to the jump threader:
abulafia:~/bld/t/gcc$ ./cc1 a.c -O2 -Wall -quiet
abulafia:~/bld/t/gcc$ ./cc1 a.c -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
||2021-11-30
Status|UNCONFIRMED |NEW
CC||aldyh at gcc dot gnu.org
--- Comment #2 from Aldy Hernandez ---
Confirmed.
(gdb) p debug(insn)
(insn 26 61 62 2 (parallel [
(set (reg:DI 0 ax [orig:99 _2 ] [99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
--- Comment #10 from Aldy Hernandez ---
*** Bug 103461 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103461
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #30 from Aldy Hernandez ---
(In reply to Jan Hubicka from comment #28)
> Bit unrelated but shows that threader seems bit expensive on other builds
> too.
> Getting stats from cc1plus LTO-link with -flto-partition=one it seems that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Aldy Hernandez changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103486
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
--- Comment #10 from Aldy Hernandez ---
Created attachment 51896
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51896&action=edit
untested patch
The threading slowdown here is due to the ssa_global_cache temporary. It
doesn't look like s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
--- Comment #9 from Aldy Hernandez ---
There's definitely something in the threader, but I'm not sure it's the cause
of all the regression.
For the record, I've reproduced on ppc64le with a spec .cfg file having:
OPTIMIZE= -O2 -flto=100 -s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #2)
> So range-op.cc eventually wants to look at 'cfun' which of course is a
> non-go in IPA context.
>
> void
> operator_div::wi_fold (irange &r, tree type,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
--- Comment #7 from Aldy Hernandez ---
*** Bug 103388 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103359
--- Comment #8 from Aldy Hernandez ---
For the record, I'm using:
gcc version 11.2.1 20210728 (Red Hat 11.2.1-1) (GCC)
as a proxy for gcc11.
And I'm using the *.fre1 dump to see what evrp sees on entry.
Perhaps there's something going on he
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103359
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #21 from Aldy Hernandez ---
One last comment.
A smaller hammer than -fno-unsafe-math-optimizations may be
-fno-finite-math-only which allows for the problematic NAN behavior in
Perl_do_ncmp. Allowing for the inlining, but not mungi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #21 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #20)
> Your c#19 was a bit hard to follow. But you hit the key issue.
Ughh sorry. I'm running on fumes here :-).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #20 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #19)
> Ughh, I was nerd sniped. Couldn't let it go ;-).
>
> The problem is this construct in Perl_do_ncmp:
>
> if (lnv < rnv)
> return -1;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #19 from Aldy Hernandez ---
Ughh, I was nerd sniped. Couldn't let it go ;-).
The problem is this construct in Perl_do_ncmp:
if (lnv < rnv)
return -1;
if (lnv > rnv)
return 1;
if (lnv == rnv)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 103088, which changed state.
Bug 103088 Summary: [12 regression] 500.perlbench from spec 2017 fails since
r12-4698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #13 from Aldy Hernandez ---
(In reply to Tamar Christina from comment #11)
> Historically it has always only been for the test dataset with the problem
> Aldy encountered before with the signed zeros. See
> https://www.spec.org/cpu2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #7 from Aldy Hernandez ---
Could someone post the relevant configury bits used for the ppc64le case.
For example, I have:
OPTIMIZE= -O3 -m64 -mcpu=power9 -ffast-math -funroll-loops -fpeel-loops
-fvect-cost-model -mpopcntd -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #19 from Aldy Hernandez ---
This looks like a target or RTL problem.
The .optimized dumps between x86-64 and bfin-elf look the same for:
-O2 -fno-tree-vrp -fno-tree-vectorize -fno-thread-jumps -fno-ivopts
-fno-tree-pre -fdisable-tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2021-11-17
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #17 from Aldy Hernandez ---
The .s files on my cross versus the AWS instance or not even remotely the same:
--- j.s 2021-11-17 14:13:19.979883609 -0500
+++ j.s.bad 2021-11-17 14:13:12.083828127 -0500
@@ -5,79 +5,78 @@
.global _
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #16 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #15)
> Re: c#13. You were so close :-) Add "-msim" to your command line. THat's
> one of the things the baseboards file does for you when you run things under
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103088
--- Comment #4 from Aldy Hernandez ---
Is this still an issue with the latest trunk? There have been a few changes in
this space (phi ordering, loop header copying, etc).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #13 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #11)
> Aldy, I could also set up a cross toolchain, ready for debugging in an AWS
> instance if that would be helpful.
Ok, I give up.
I configured and installed t
CC||aldyh at gcc dot gnu.org
See Also|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?id=103226|
Ever confirmed|0 |1
Last reconfirmed||2021-11-17
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #12 from Aldy Hernandez ---
(In reply to Tamar Christina from comment #9)
> (In reply to Aldy Hernandez from comment #8)
> > (In reply to Tamar Christina from comment #7)
> > > Just a note, in our case the error seems to cause stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #8 from Aldy Hernandez ---
(In reply to Tamar Christina from comment #7)
> Just a note, in our case the error seems to cause stage2 build to fail.
Please file a PR for it and indicate the architecture. This PR is for a
pr80974.c re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #5 from Aldy Hernandez ---
FWIW, the *.ch2 dump on both x86-64 and bfin-elf are identical.
This is unlikely to help, but...
In *.ivopts we start seeing differences in the IL:
[local count: 60236916]:
e = 1;
+ ivtmp.29_7 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #4 from Aldy Hernandez ---
It's been a LONG time since I had to do a sim build, so please bear with me.
I have combined tree with gcc, binutils-gdb, dejagnu, newlib-cygwin:
~/src/combined/configure --target=bfin-elf --enable-langu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
--- Comment #6 from Aldy Hernandez ---
This looks like a class of problems we could easily get if we wanted. The
pattern is:
PREHEADER
|
|
V
HEADER --> LOOPEXIT
|
|
V
SUCC
| \
| \
DEAD \
| /
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
--- Comment #5 from Aldy Hernandez ---
*** Bug 103280 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103280
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #18 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #17)
> iftmp.2373_1515 is defined earlier as:
> iftmp.2373_1515 = code_1387(D) != 181 ? ctx_1386 : outer_ctx_1389;
> so the transformation by dom3? from
> if (ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103254
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103257
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
--- Comment #6 from Aldy Hernandez ---
Created attachment 51796
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51796&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
--- Comment #5 from Aldy Hernandez ---
(In reply to Richard Biener from comment #4)
> Sure. (OVF) in the IL are meaningless, we do try to prune them but it still
> happens that they appear.
Ughh, you've mentioned this before. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101941
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 103229, which changed state.
Bug 103229 Summary: gcc/gimple-range-cache.cc:654:10: runtime error: null
pointer passed as argument 1, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103229
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103231
--- Comment #8 from Aldy Hernandez ---
Created attachment 51789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51789&action=edit
similar problem on aarch64 kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103231
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103229
--- Comment #2 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #1)
> Untested, but if someone wants to test and commit, feel free.
Nevermind, I'll pass it through the gauntlet and commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103219
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2021-11-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103229
--- Comment #1 from Aldy Hernandez ---
Untested, but if someone wants to test and commit, feel free.
diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index a63e20e7e49..b347edeb474 100644
--- a/gcc/gimple-range-cache.cc
+++ b/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103222
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103222
--- Comment #3 from Aldy Hernandez ---
Created attachment 51783
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51783&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103222
Aldy Hernandez changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #2 from Aldy Hernandez
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
--- Comment #3 from Aldy Hernandez ---
That is, is the overflowed 0 allowed in the switch's case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
--- Comment #9 from Aldy Hernandez ---
Created attachment 51780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51780&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103207
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #11 from Aldy Hernandez ---
Created attachment 51778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51778&action=edit
preprocessed source to reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #10 from Aldy Hernandez ---
The guard seems to be removed by the vrp2 pass, not by jump threading.
a.ii.195t.vrp2:Folding predicate iftmp.2373_1515 != 0B to 1
For some bizarre reason, ranger thinks iftmp.2373_1515 is nonzero and re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #8 from Aldy Hernandez ---
Note that I've disabled all the thread full passes and the problem persists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #6 from Aldy Hernandez ---
Hmm, all these threads look correct. Following are my steps for verification.
In a stage2 compiler I do:
$ rm -f gimplify.o
$ make cc1 CXXFLAGS="-O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #4 from Aldy Hernandez ---
I can reproduce on a stage2 compiler. I've narrowed it down to:
-O2 -fdisable-tree-threadfull2 -fdisable-tree-threadfull1
-fdisable-tree-thread2 -fdisable-tree-thread1
-fdbg-cnt=registered_jump_thread:543
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
--- Comment #7 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #6)
> Not looking at this yet, but disabling jump threading from all passes (dom
> included) makes the problem go away:
>
> $ ./xgcc -B./ a.c -w -O2 -fno-thread-jum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103202
--- Comment #6 from Aldy Hernandez ---
Not looking at this yet, but disabling jump threading from all passes (dom
included) makes the problem go away:
$ ./xgcc -B./ a.c -w -O2 -fno-thread-jumps && ./a.out
element 1
element 2
element 3
...so *m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103192
--- Comment #3 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #1)
> Seems to have started with r12-4790-g4b3a325f07acebf47e82de227ce1d5ba62f5bcae
Huh. I wonder what happened. I never saw these regressions in my testing.
Will
401 - 500 of 1818 matches
Mail list logo
