https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #27 from Aldy Hernandez ---
(In reply to Richard Biener from comment #20)
> (In reply to hubicka from comment #19)
> > The testcase would be
> >
> > void test ()
> > {
> > int i;
> > if (test())
> > i=0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103120
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103120
--- Comment #5 from Aldy Hernandez ---
This is an ordering issue in the path solver, and it's not even relation
related! How interesting.
./xgcc -B./ a.c -O2 -fdisable-tree-ethread -fdisable-tree-thread1
-fdisable-tree-thread2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #8 from Aldy Hernandez ---
This may be related to the discussion in PR102997, particularly comment 16.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #18 from Aldy Hernandez ---
> If I read it correctly, for a path that enters the loop and later leaves
> it (where threading is desirable since we skip the whole loop) the logic
> above will still return true (after finishing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
Aldy Hernandez changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
Component|middle-end |testsuite
--- Comment #7 from Aldy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #13 from Aldy Hernandez ---
Since DOM is the only threading pass that keeps more or less accurate
profiling data, here's a very wild guess.
The pre-loop DOM threading pass does not thread some paths because of
the restrictions in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #12 from Aldy Hernandez ---
It's been mentioned that this SPEC test has irreconcilable differences between
the train and peak runs, and cannot be reasonably compared. Is the slowdown
reported between two runs of compatible runs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #11 from Aldy Hernandez ---
>From what I gather, this is only reproducible with PGO. If so, it may be worth
nothing that Jeff has mentioned that the backward threader probably does not do
a very good job with keeping profile counts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #5 from Aldy Hernandez ---
(In reply to Christophe Lyon from comment #4)
> If I'm not mistaken, if you click on "REGRESSED" for that specific line,
> you'll see that only ssa-dom-thread-7.c actually regressed with the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #26 from Aldy Hernandez ---
(In reply to Jan Hubicka from comment #25)
> LNT sees new regresion on WRF build times (around 6%) at Nov 3
>
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=287.548.8
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 103061, which changed state.
Bug 103061 Summary: [12 Regression] 527.cam4_r miscompiled with -O2
-march=znver1 since r12-4790-g4b3a325f07acebf4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101240
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #15 from Aldy Hernandez ---
Created attachment 51740
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51740=edit
untested patch
This should do it. Martin, can you verify this fixes it on your end?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
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=103061
--- Comment #13 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #12)
> I dont understand why? isnt m.10_120 killed in bb20? whats the basis
> for threading that? I dont see it
Huh. The last thing we do in the solver is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #9 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Aldy Hernandez from comment #5)
> > > That is, is signed overflow undefined in overflow?
> >
> > Errr, "is signed overflow undefined for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #7 from Aldy Hernandez ---
Simplified version without the noise:
[local count: 56063504182]:
_134 = M.10_120 + 1;
if (_71 <= _134)
goto ; [11.00%]
else
goto ; [89.00%]
...
...
[local count: 49896518755]:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #5 from Aldy Hernandez ---
> That is, is signed overflow undefined in overflow?
Errr, "is signed overflow undefined for integer(kind=4)?"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103061
--- Comment #4 from Aldy Hernandez ---
(In reply to Martin Liška from comment #1)
> The following file is miscompiled:
>
> gfortran -c -o m_MergeSorts.fppized.o -I. -Iinclude -Inetcdf/include -O2
> -march=native -g -std=legacy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #22 from Aldy Hernandez ---
(In reply to Martin Liška from comment #21)
> > For the record, I hate the SPEC build system :).
>
> Then you're the first one! No, just kidding, it's cumbersome, and feel free
> to contact me with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #20 from Aldy Hernandez ---
With attachment 51726 and current trunk, the present damage is 22% for the
ltrans105 unit, which AFAICT, is the worst offender. This is much better than
the original 44%, but still not ideal.
After some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
Aldy Hernandez changed:
What|Removed |Added
Depends on||103058
--- Comment #18 from Aldy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103062
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #11 from Aldy Hernandez ---
Created attachment 51726
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51726=edit
untested improvement to ranger cache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #9 from Aldy Hernandez ---
(In reply to Richard Biener from comment #8)
> The 'tree VRP threader' instances are now gone (well, obviously..). There's
> now
>
> backwards jump threading : 15.98 ( 13%)
> TOTAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
--- Comment #9 from Aldy Hernandez ---
(In reply to Martin Liška from comment #8)
> Started with Aldy's commit
> r12-4526-gd8edfadfc7a9795b65177a50ce44fd348858e844.
Hmmm, this commit disables problematic threads we've agreed are detrimental to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
--- Comment #3 from Aldy Hernandez ---
*** Bug 102895 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102895
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #1 from Aldy Hernandez ---
Is this still an issue with the new jump threader?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102981
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
--- Comment #6 from Aldy Hernandez ---
Can this be re-checked now that the forward threader has been dropped post-VRP?
BTW, please CC me on any compile-time hogs related to the threader, especially
if it's not SPEC related, as I've yet to hunt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2021-10-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
--- Comment #9 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Aldy Hernandez from comment #6)
> > Created attachment 51654 [details]
> > proposed patch
> >
> > Does this fix the problem on aarch64?
>
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
Aldy Hernandez changed:
What|Removed |Added
Attachment #51654|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102857
--- Comment #6 from Aldy Hernandez ---
Created attachment 51654
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51654=edit
proposed patch
Does this fix the problem on aarch64?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102895
--- Comment #2 from Aldy Hernandez ---
(In reply to Richard Biener from comment #1)
> There's identical IL before the vrp2 pass (the one after strlen) but on the
> GCC 11 branch vrp2 eliminates the call to foo while on trunk it does not.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892
--- Comment #1 from Aldy Hernandez ---
Maybe a duplicate of PR102879?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #20 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Andrew Pinski from comment #15)
> > We totally missed the jump threading of 3->5->7 path and the 4->5->8 path.
>
> FAIL: path through PHI in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #19 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #16)
> (In reply to Andrew Pinski from comment #15)
> > We totally missed the jump threading of 3->5->7 path and the 4->5->8 path.
>
> FAIL: path through PHI in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
--- Comment #18 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #9)
> So in uninit1 we have:
> if (_6691 != 0)
> goto ; [5.50%]
> else
> goto ; [94.50%]
>
>[local count: 17344687]:
> goto ; [100.00%]
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102879
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102861
--- Comment #6 from Aldy Hernandez ---
> > Is there something else we could do?
>
> Look what exactly is missing and restore that - testcases are written
> from real-world code that we expect to optimize, adjusting them to
> hide the fact that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102861
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> Yeah, I think these kind of testsuite changes are no good.
The loop threading restrictions disallow a couple jump threads (rotating the
loop and crossing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102861
--- Comment #1 from Aldy Hernandez ---
Similarly to 102860.
The referenced patch reduces the amount of threaded paths, not increase them.
This actually looks like another pass hiccuping because it was expecting a
threaded path that is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102860
--- Comment #1 from Aldy Hernandez ---
The referenced patch reduces the amount of threaded paths, not increase them.
This actually looks like another pass hiccuping because it was expecting a
threaded path that is no longer there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844
--- Comment #16 from Aldy Hernandez ---
(In reply to Richard Biener from comment #13)
> Aldyh might also have stumbled over code avoiding to thread across a SSA
> definition.
>
> Ah - I guess the block is recorded as "forwarder" (block with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102852
--- Comment #4 from Aldy Hernandez ---
(In reply to Martin Liška from comment #3)
> Thanks for the fix, it's really gone now.
Heh. Actually the bug is still latent, but I'm testing a fix ;-).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814
Bug 102814 depends on bug 102852, which changed state.
Bug 102852 Summary: [12 Regression] Compile time hog since
r12-4421-g0bd68793921ecf3b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102852
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814
Aldy Hernandez changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102852
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102852
Aldy Hernandez changed:
What|Removed |Added
CC||jbg...@lug-owl.de
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814
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=102814
--- Comment #1 from Aldy Hernandez ---
(In reply to Dmitry G. Dyachenko from comment #0)
> r12-4256 FAST
> r12- SLOW
>
> g++ -fpreprocessed -std=c++98 -O2 --param
> max-jump-thread-duplication-stmts=NNN -c x.ii
Well, you are basically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809
--- Comment #3 from Aldy Hernandez ---
(In reply to Martin Liška from comment #2)
> > Does this fix the problem?
>
> Yes, it helps! Thank you for the patch.
Thanks for all your help here, and sorry for all the noise. Getting the jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809
--- Comment #1 from Aldy Hernandez ---
There's a pending patch in this area that restricts loop threading:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581894.html
Does this fix the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102751
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102736
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703
--- Comment #9 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #8)
> On Wed, Oct 13, 2021, 11:37 pinskia at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102736
--- Comment #5 from Aldy Hernandez ---
Created attachment 51598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51598=edit
proposed patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102736
--- Comment #4 from Aldy Hernandez ---
Here are some debugging tips for when I'm not around ;-).
When the jump threader is suspected, I find it useful to do some bisecting to
find the actual jump thread that is causing the problem. Note that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102736
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703
--- Comment #6 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #4)
> There is a missed optimization at the gimple level for sure.
>
>
> if (d_11 > 1)
> goto ; [59.00%]
> else
> goto ; [41.00%]
>
>[local count:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703
--- Comment #3 from Aldy Hernandez ---
This seems to be some limitation of the RTL optimizers in the presence of more
aggressive jump threading.
Neither the old backward threader nor the old VRP threader could find any
threading possibilities:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102681
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
--- Comment #4 from Aldy Hernandez ---
For the calls-aarch64.ii testcase, there's some additional information in the
upstream thread. Quoted here for convenience:
There's some missing context.
The only way to get to BB101->BB102 is through:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
--- Comment #3 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #2)
> Created attachment 51562 [details]
> similar problem on aarch64 bootstrap
$ ./cc1plus calls-aarch64.ii -O2 -quiet -Wall
In function ‘void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
--- Comment #2 from Aldy Hernandez ---
Created attachment 51562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51562=edit
similar problem on aarch64 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
--- Comment #1 from Aldy Hernandez ---
$ ./cc1 team.i -O2 -quiet -Wall
/home/aldyh/src/gcc/libgomp/team.c: In function ‘gomp_team_start’:
/home/aldyh/src/gcc/libgomp/team.c:315:34: warning: ‘start_data’ may be used
uninitialized in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
Bug ID: 102631
Summary: -Wmaybe-uninitialized cannot see through a series of
PHIs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622
--- Comment #8 from Aldy Hernandez ---
(In reply to H.J. Lu from comment #6)
> (In reply to Aldy Hernandez from comment #4)
> > Can you try with -fno-thread-jumps to make sure its really the threader at
> > play?
>
> -fno-thread-jumps fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622
--- Comment #7 from Aldy Hernandez ---
(In reply to H.J. Lu from comment #6)
> (In reply to Aldy Hernandez from comment #4)
> > Can you try with -fno-thread-jumps to make sure its really the threader at
> > play?
>
> -fno-thread-jumps fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102622
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605
--- Comment #2 from Aldy Hernandez ---
(In reply to Richard Biener from comment #1)
> You need
>
> if (p_2(D) == _Literal (char *) [2])
>
> and of course you need to provide the
>
> char global[10];
>
> declaration. And then we still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102605
Bug ID: 102605
Summary: address instruction from -fdump-tree-*-gimple doesn't
work with -fgimple
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560
--- Comment #6 from Aldy Hernandez ---
(In reply to Richard Biener from comment #5)
> + int_range<2> invalid_range (build_int_cst (size_type_node, 0),
> + build_int_cst (size_type_node, max_size),
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560
--- Comment #4 from Aldy Hernandez ---
Created attachment 51540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51540=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98703
--- Comment #4 from Aldy Hernandez ---
I can't remember what Andrew's plan was for complex numbers, possibly for next
release when we handle floats. We have somewhat of a kludge to know that the
result of REALPART_EXPR and IMAGPART_EXPR are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560
--- Comment #3 from Aldy Hernandez ---
Probably needs GTY markers, and possibly putting it invalid_range in file
scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560
--- Comment #2 from Aldy Hernandez ---
Going up the backtrace we see:
(gdb)
#3 0x01b43aff in irange::intersect (this=0x7fffc8e0,
other=0x3c7aa40 )
at /home/aldyh/src/gcc/gcc/value-range.cc:1514
(gdb)
#4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102560
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
Aldy Hernandez changed:
What|Removed |Added
Attachment #51534|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
Aldy Hernandez changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102561
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102563
--- Comment #1 from Aldy Hernandez ---
Created attachment 51534
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51534=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542
Aldy Hernandez changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546
--- Comment #6 from Aldy Hernandez ---
(In reply to Richard Biener from comment #4)
> I think it's similar to in the other PR, with old EVRP when visiting BB 8
BTW, which is this other PR, so I may see if my work for this PR fixes that
one?
501 - 600 of 740 matches
Mail list logo
