https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107130
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=107130
--- Comment #5 from Aldy Hernandez ---
Created attachment 53656
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53656&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107130
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107052
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107170
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=107170
--- Comment #1 from Aldy Hernandez ---
Created attachment 53672
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53672&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107170
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172
--- Comment #3 from Aldy Hernandez ---
(In reply to Martin Liška from comment #2)
> Started with r13-1268-g8c99e307b20c502e.
Disabling DOM with -fno-tree-dominator-opts still causes the crash, so it's not
this patch that caused the problem. Fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195
--- Comment #4 from Aldy Hernandez ---
*** Bug 107194 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107194
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195
--- Comment #6 from Aldy Hernandez ---
Created attachment 53687
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53687&action=edit
untested patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107195
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107286
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107293
--- Comment #2 from Aldy Hernandez ---
Created attachment 53717
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53717&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107293
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
--- Comment #1 from Aldy Hernandez ---
I can't reproduce on gcc135.fsffrance.org with default parameters on a
bootstrap.
Is there a way to reproduce this on said machine? Or could you provide a .i
file that could be used with a cross?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
--- Comment #4 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #3)
> We are failing while trying to fold:
>
> c_92 = __builtin_copysignf128 (0.0, c_80(D));
>
> The problem is that c_92 is TFtype but 0.0 is _Float128. TFtype h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
--- Comment #6 from Aldy Hernandez ---
Created attachment 53718
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53718&action=edit
preprocessed testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107299
--- Comment #7 from Aldy Hernandez ---
It looks like the 0.0 with the wrong type is there quite early in the pipeline.
At least by einline (after SSA and CFG have been built) we have:
(gdb) p debug(gs)
c_92 = __builtin_copysignf128 (0.0, c_80(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312
--- Comment #3 from Aldy Hernandez ---
Created attachment 53730
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53730&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107312
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342
--- Comment #2 from Aldy Hernandez ---
Created attachment 53749
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53749&action=edit
untested patch
I'm sure somebody smarter could handle other shift amounts that are not powers
of 2, but this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107342
Aldy Hernandez changed:
What|Removed |Added
Attachment #53749|0 |1
is obsolete|
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=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=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 #11 from Aldy Hernandez ---
The testcase for PR104067 shows an example where the dominance matters,
irregardless of if we reset relations at the backedge point. There we have a
path that looks like 9->3->5->...:
[local count: 106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
--- Comment #12 from Aldy Hernandez ---
Created attachment 52240
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52240&action=edit
proposed untested patch
This is a proposed patch that fixes both PRs. Perhaps we can tweak the
dominance ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
Aldy Hernandez changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
Aldy Hernandez changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24021
--- Comment #8 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #7)
> Very cool. ANd no, I'm not enough of an expert on the FP side to shepherd
> that though. I would expect it to be exceptionally tricky on the solver
> side.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
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&action=edit
untested improvement to ranger cache
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
Aldy Hernandez changed:
What|Removed |Added
Depends on||103058
--- Comment #18 from Aldy Herna
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
--- 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 questi
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 m_MergeSorts.fppi
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 #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]:
[l
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 integer(k
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
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 #15 from Aldy Hernandez ---
Created attachment 51740
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51740&action=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=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
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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|Remo
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://lnt.opensuse.or
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
> corresponding
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=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 (two
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 pl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
Component|middle-end |testsuite
--- Comment #7 from Aldy Her
--- Comment #17 from Aldy Hernandez ---
(In reply to rguent...@suse.de from comment #15)
> On Mon, 8 Nov 2021, aldyh at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102997
> >
> > --- Comment #13 from Aldy Hernandez ---
> > Since DOM is the
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 wh
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=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 -fdisable-tree-t
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=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=102906
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #16 from Aldy Hernandez ---
> $3 = void
> (gdb) n
> 326 max = wi::to_wide (vr.max ());
> (gdb) p range_type
> $4 = VR_RANGE
> (gdb) p debug_tree(vr.min())
>
> constant 1>
> $5 = void
> (gdb) p debug_tree(vr.max())
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
--- Comment #17 from Aldy Hernandez ---
(In reply to Martin Sebor from comment #15)
> accurate than with ranger. I also didn't realize that debug_ranger() didn't
> show me the same ranges I get from a call range_of_expr(). Live and learn I
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
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=102906
--- Comment #16 from Aldy Hernandez ---
(In reply to rguent...@suse.de from comment #15)
> On Wed, 10 Nov 2021, aldyh at gcc dot gnu.org wrote:
> > @@ -60,6 +63,24 @@ should_duplicate_loop_header_p (basic_block header, class
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #19 from Aldy Hernandez ---
Created attachment 51757
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51757&action=edit
proposed patch in testing
Patch depends on some shuffling in the path solver to make way for non-threader
cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892
Aldy Hernandez changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102892
--- Comment #6 from Aldy Hernandez ---
(In reply to Martin Liška from comment #5)
> Fixed on master with r12-4790-g4b3a325f07acebf4.
Wadayaknow...I fixed it and didn't even know it :)
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
--- Comment #6 from Aldy Hernandez ---
(In reply to Martin Sebor from comment #5)
> Great! With the strlen conversion to ranger
> (g:6b8b959675a3e14cfdd2145bd62e4260eb193765) the test now fails on x86_64 as
> well:
I didn't see any regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161
--- Comment #8 from Aldy Hernandez ---
https://en.cppreference.com/w/cpp/language/eval_order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102906
--- Comment #21 from Aldy Hernandez ---
Should be fixed. Can someone verify the object size on arm is as expected?
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
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=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=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=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 #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 #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 #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=103207
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
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=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
Status|NEW |RESOLVED
Resolution|---
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=103222
Aldy Hernandez changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #2 from Aldy Hernandez
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
Resolution|--- |FIXED
Status|NEW
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=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 #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=102906
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Aldy Hernandez changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
1301 - 1400 of 1818 matches
Mail list logo
