||law at redhat dot com
Resolution|--- |FIXED
--- Comment #14 from Jeffrey A. Law ---
The trunk no longer generates masking with andl for this testcase. I didn't
try to track it down any further than that.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #4 from Jeffrey A. Law ---
Compare-elimination does the right thing and eliminates the redundant test on
the trunk. Given the age of the BZ I didn't track it down any further than
that.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #3 from Jeffrey A. Law ---
Fixed on the trunk. Not sure when and given the age of the BZ I didn't bisect
to find out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31914
Bug 31914 depends on bug 30997, which changed state.
Bug 30997 Summary: FRE does not simplify comparisons in COND_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30997
What|Removed |Added
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #5 from Jeffrey A. Law ---
Fixed. We generate a single comparison rather than two.
Not sure when. Given the age, I didn't try to bisect.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #3 from Jeffrey A. Law ---
No redundant extension on the trunk. Given the age of this BZ I did not try to
track it down to a particular change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19986
Bug 19986 depends on bug 25529, which changed state.
Bug 25529 Summary: (unsigned * 2)/2 is not changed into unsigned &0x7FFF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25529
What|Removed |Added
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #4 from Jeffrey A. Law ---
Fixed. Presumably by Naveen's patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
Bug 19721 depends on bug 19790, which changed state.
Bug 19790 Summary: equality not noticed when signedness differs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19790
What|Removed |Added
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #7 from Jeffrey A. Law ---
The original issue reported by Kazu has been fixed. We no longer have to
increment a temporary holding i - 1 to retrieve i for second statement in the
loop
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #5 from Jeffrey A. Law ---
RTL forwprop handles this. I didn't dig into precise when it was fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83362
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83298
Jeffrey A. Law changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83362
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81889
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32623
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||law at redhat dot com
Resolution|--- |WONTFIX
--- Comment #13 from Jeffrey A. Law ---
This is almost certainly a buggy host compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79509
Jeffrey A. Law changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80645
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #2 from Jeffrey A. Law ---
Fixed on the trunk a while ago.
||law at redhat dot com
--- Comment #5 from Jeffrey A. Law ---
Given likely MPX deprecation -> P4.
||law at redhat dot com
--- Comment #4 from Jeffrey A. Law ---
MPX/CHKP. Lowering to P4 given likely deprecation
||law at redhat dot com
--- Comment #9 from Jeffrey A. Law ---
I'm expecting we'll deprecate MPX. Lowering to P4.
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61428
Jeffrey A. Law changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83312
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #10 from Jeffrey A. Law ---
Per c#9.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #4 from Jeffrey A. Law ---
Fixed months ago with Martin's change on the trunk.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #2 from Jeffrey A. Law ---
This was fixed by introducing the EVRP analysis module and using it within DOM
and will no longer give the false positive with gcc-8.
In VRP1 the key statement
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #13 from Jeffrey A. Law ---
Fixed by Vlad commit on the trunk.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #15 from Jeffrey A. Law ---
Fixed by Vlad's change on the trunk. Hopefully for good this time :-)
Assignee|msebor at gcc dot gnu.org |law at redhat dot com
Summary|False positive from |Improve (or eliminate)
|-Wstringop-overflow on |diagnostics related to loop
|simple std::vector code |distribution
--- Comment #12 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641
--- Comment #7 from Jeffrey A. Law ---
So based my findings around c#5 we can classify this as a false positive. GCC
has enough information lying around to prove the problematical memset can never
be reached, but fails to do so.
Martin's patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83298
--- Comment #3 from Jeffrey A. Law ---
I see what's going on here. I'm a bit concerned there's a deeper issue. Some
planned gcc-9 work would take care of this, but I was hoping to avoid those
changes in the gcc-8 cycle. Investigating the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #15 from Jeffrey A. Law ---
Yea, I just looked and it's somewhat painful to do because of how threading
works. We walk statements forward and stop when we hit the limit. But DCE
analysis is easier to formulate as a backwards walk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83298
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82646
--- Comment #3 from Jeffrey A. Law ---
Sorry. I shouldn't have closed this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82103
--- Comment #6 from Jeffrey A. Law ---
It should. It may not though because one the n != 0 test is removed, the
resulting range of N is probably VR_VARYING rather than ~[0,0] at the call to
memset.
The former signifies we know nothing about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81876
--- Comment #4 from Jeffrey A. Law ---
Richi.
I do worry about cases where we exploit strict-overflow semantics. It'd be
nice to be able to warn about them, but I certainly agree that stability is a
problem. With instability, messaging to and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
Jeffrey A. Law changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
--- Comment #12 from Jeffrey A. Law ---
In general we can't know if we're going to have a single argument PHI after
threading. If the block has multiple preds that thread to the same final
destination, then we create a single copy and vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80038
--- Comment #37 from Jeffrey A. Law ---
There are no plans to backport any additional Cilk+ changes/fixes to the
release branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
--- Comment #5 from Jeffrey A. Law ---
It really depends on the growth necessary to expose the thread. I haven't
tried to evaluate that -- clearly if the code growth is unacceptable then
threading is the wrong answer.
In general we should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82076
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2
||law at redhat dot com
Resolution|--- |INVALID
--- Comment #1 from Jeffrey A. Law ---
This test looks bogus to me.
"g" boils down to:
g (struct S * p, int n)
{
long unsigned int _1;
char[5] * _2;
;; basic block 2, loop dept
||law at redhat dot com
Resolution|--- |INVALID
--- Comment #4 from Jeffrey A. Law ---
IMHO the warning is correct here. The code clearly does very bad things when
frame is zero. In that case we pass -1 to the memset #define. Which
ultimately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83239
--- Comment #5 from Jeffrey A. Law ---
This (and pr80641) all feel closely related. Transforming into a trap early
means we're not likely to get these reports which would be unfortunate because
they often point to a failing of the optimizer.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81876
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82123
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
,
||law at redhat dot com
--- Comment #3 from Jeffrey A. Law ---
So this really doesn't have anything to do with locking, mutexes or anything
like that. It's really just a matter of the CFG having a shape that is
problematical for the old jump threader.
To thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69224
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82286
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81165
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80907
Jeffrey A. Law changed:
What|Removed |Added
Summary|[6/7/8 Regression] False|[6/7 Regression] False
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78496
Jeffrey A. Law changed:
What|Removed |Added
Summary|[7/8 Regression] Missed |[7 Regression] Missed
||law at redhat dot com
||law at redhat dot com
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69811
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80198
--- Comment #10 from Jeffrey A. Law ---
Yea. The code that was recording NAME = NAME conditional equivalences was
largely disabled back in August. They'll only be recorded now if one name is
cheaper to compute than the other.
So if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #36 from Jeffrey A. Law ---
Just a couple notes. I'm not currently looking at this, but this is probably
the best bug to track thoughts around how to try and capture secondary effects
of jump threading without re-running all of DOM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81807
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #4
||2017-11-21
CC||law at redhat dot com
Summary|Spurious -Wclobbered|[6/7/8 Regression] Spurious
|warning generated by gcc|-Wclobbered warning
|4.9.0 for |generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82889
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732
--- Comment #7 from Jeffrey A. Law ---
Given that both DOM and strlen are already dom walker based, getting better
range information in them is going to be easy. The former is actually part of
the motivation behind the refactoring work.
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82732
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82788
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82823
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||law at redhat dot com
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
Ever confirmed|0 |1
--- Comment #1 from Jeffrey A. Law ---
Haha. I had just pulled the fix for this out of our internal tree and was
working to get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82788
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82788
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674
--- Comment #7 from Jeffrey A. Law ---
Cool. I've got systems here that are primed for testing, so if you could pass
the patch along I can do spins fairly easily.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674
--- Comment #5 from Jeffrey A. Law ---
True that 64k may be interesting because of pagesize considerations. But I'm
not sure how to make it work reliably on ppc because I'm not aware of another
scratch register we can use if we have that large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674
--- Comment #3 from Jeffrey A. Law ---
So while fixing the expander that allocates dynamic space is easy. Fixing the
other cases is harder, particularly since we need another scratch.
Given it's always been expected that the probing internval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82674
--- Comment #2 from Jeffrey A. Law ---
Right, but it's the expander to allocate dynamic space that's creating the
bogus RTL. It's a trivial fix that I just need to run through some testing.
||2017-10-23
CC||law at redhat dot com
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
Ever confirmed|0 |1
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #3 from Jeffrey A. Law ---
Fixed by Martin's patch on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82358
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82358
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79768
--- Comment #8 from Jeffrey A. Law ---
Understood on your hardware limitations.
You could certainly do bisection work on the compile farm.
Again, thanks for your work on cleaning up some of this old stuff.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 79768, which changed state.
Bug 79768 Summary: `-Wmaybe-uninitialized' false positive with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79768
What|Removed |Added
||2017-10-01
CC||law at redhat dot com
Resolution|WORKSFORME |---
Ever confirmed|0 |1
--- Comment #6 from Jeffrey A. Law ---
Eric. Thanks for the BZ maintenance. It's definitely
||2017-09-30
CC||law at redhat dot com
Blocks||19794
Ever confirmed|0 |1
--- Comment #1 from Jeffrey A. Law ---
So I see a couple things here.
In DOM we do catch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81613
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82192
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64910
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82052
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82052
--- Comment #3 from Jeffrey A. Law ---
What an interesting little bug. A patch is in testing.
The reason it's so hard to trigger is you need a very specific and presumably
unusual set of circumstances to trigger the bug.
Enter object1 into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82052
--- Comment #2 from Jeffrey A. Law ---
Thanks. The abort is a sanity check to ensure that when we are unwinding the
avail expression hash table that every entry we want to restore to a previous
state is actually in the hash table.
A failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #44
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Target Milestone: ---
DOM fails to simplify the 3rd conditional in the test 20030922-2.c. This is by
current design and the test is xfailed.
This is a regression relative to gcc-7 and earlier.
So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81741
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #4 from Jeffrey A. Law ---
Fixed, not really sure when though:
int main() ()
{
struct obj * obj;
int _1;
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70879
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
Bug 19794 depends on bug 70879, which changed state.
Bug 70879 Summary: Missed jump threading opportunity with multiple != conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70879
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81596
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81741
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #4
801 - 900 of 3054 matches
Mail list logo
