||law at redhat dot com
Resolution|--- |DUPLICATE
--- Comment #2 from Jeffrey A. Law ---
Almost certainly a DUP.
*** This bug has been marked as a duplicate of bug 84264 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264
--- Comment #4 from Jeffrey A. Law ---
*** Bug 84499 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
--- Comment #11 from Jeffrey A. Law ---
Just to record some thoughts.
The implementation of the "clobbered by longjmp" warning essentially looks at
the objects that are live at the setjmp point. In theory we can do better when
we're dealing
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #14 from Jeffrey A. Law ---
Fixed by Richard's patch on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84408
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #8 from Jeffrey A. Law ---
Fixed by Richard's commit on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57218
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
Jeffrey A. Law changed:
What|Removed |Added
Target Milestone|6.5 |9.0
--- Comment #38 from Jeffrey A.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #4 from Jeffrey A. Law ---
Fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32306
--- Comment #37 from Jeffrey A. Law ---
Another thought for dealing with this BZ: Use the infrastructure Alex built to
identify blocks that are in effect forwarders (ie, they need not be copied for
jump threading). Use that knowledge to thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965
Jeffrey A. Law changed:
What|Removed |Added
CC||andrey.y.guskov at intel dot
com
---
||law at redhat dot com
Resolution|--- |DUPLICATE
--- Comment #8 from Jeffrey A. Law ---
DUP.
*** This bug has been marked as a duplicate of bug 82965 ***
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #7 from Jeffrey A. Law ---
WRT c#5. The final consensus was that we can't reliably support the views
within GCC unless the target ports are audited for insns which emit no code,
but which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84342
Jeffrey A. Law changed:
What|Removed |Added
Summary|[8 Regression] Location |Location views breaks cross
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79242
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #12 from Jeffrey A. Law ---
Fixed by Yury's testsuite fixes on the trunk.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #2 from Jeffrey A. Law ---
Should be fixed by r257631.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81611
--- Comment #23 from Jeffrey A. Law ---
No, the DOM change is only a partial fix. I've largely approved the auto-inc
change. I recommend the additional tests in c#19 be pulled into a distinct BZ
and the gcc8 regression marker removed once the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83776
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84047
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84051
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84053
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Target
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #12 from Jeffrey A. Law ---
Should be fixed on the trunk now.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #2 from Jeffrey A. Law ---
Should be fixed by Alex's change on the trunk.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #15 from Jeffrey A. Law ---
Fixed by Richard's change on the trunk.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #5 from Jeffrey A. Law ---
I've added a marker for this BZ to Alex's change that fixed things.
Tamar -- the thing to look for are cases where a pattern emits no code, but
claims a nonzero
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83760
Jeffrey A. Law changed:
What|Removed |Added
Summary|[8 Regression] [SH] ICE in |[7/8 Regression] [SH] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78459
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83760
--- Comment #3 from Jeffrey A. Law ---
*** Bug 78459 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80863
Jeffrey A. Law changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83760
Jeffrey A. Law changed:
What|Removed |Added
CC||glaubitz at physik dot
fu-berlin.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83760
Jeffrey A. Law changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83785
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2018-02-12
CC||law at redhat dot com
Ever confirmed|0 |1
--- Comment #4 from Jeffrey A. Law ---
We would need the cpp output to thoroughly analyze this. You can get the cpp
output using "-save-
||law at redhat dot com
Resolution|--- |WONTFIX
--- Comment #3 from Jeffrey A. Law ---
Agree with Steve on this. It's a bug in the host compiler. We're not fixing
bugs in gcc-4.4 anymore.
Given what we know about this class of problems, -fno
||2018-02-12
CC||law at redhat dot com
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78459
--- Comment #8 from Jeffrey A. Law ---
More likely this is an RTX_FRAME_RELATED_P insn in a delay slot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83785
--- Comment #3 from Jeffrey A. Law ---
Almost certainly a problem with frame related insns in delay slots. While in
the past some ports have handled this in their define_delay descriptions. I
really wonder if it belongs in generic bits created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83785
--- Comment #2 from Jeffrey A. Law ---
So this goes latent with the branch probability updates from Jan 19. It is
independent of the CSE issue I'm looking at. It could well be related to delay
slot branching and CFIs. r256887 should
||2018-02-12
CC||law at redhat dot com
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78459
--- Comment #7 from Jeffrey A. Law ---
So I've got a patch for the h8 instance of this problem. I'll have to see if I
can reproduce the various SH instances and backtest my patch against them.
The situation we were running into was generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78459
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70831
Jeffrey A. Law changed:
What|Removed |Added
Priority|P2 |P4
--- Comment #15 from Jeffrey A. Law
||law at redhat dot com
Summary|ICE in simplify_subreg, at |[7/8 Regression] ICE in
|simplify-rtx.c:6029 |simplify_subreg, at
||simplify-rtx.c:6029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71361
--- Comment #9 from Jeffrey A. Law ---
Leslie, you'd need to bisect. Probably something from Bin in the summer of
2017. Not something we're likely to backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393
--- Comment #14 from Jeffrey A. Law ---
I suspect we could likely show a similar codesize and performance regression on
other targets. ppc & arm come to mind. aarch64 as well, but it wouldn't be a
regression there since it didn't exist when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393
--- Comment #12 from Jeffrey A. Law ---
One more tidbit here. I noted that we got "reasonably" close to having enough
state in the combiner to attack this in c#7. The problem is there's a REG
object that we really need to be a CONST_INT.
It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84128
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #3 from Jeffrey A. Law ---
Fixed by Vlad's patch on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84064
--- Comment #6 from Jeffrey A. Law ---
WRT c#3, yea, that code is totally broken and probably has been since the day
it was introduced. The good news is its fixable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84064
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84128
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82666
--- Comment #5 from Jeffrey A. Law ---
Aldy,
It's less about whether or not there is a cmov (I get one with and without
PRE), but more about what part of the loop we're using the cmov for.
Consider what we get in the .optimized dump at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81010
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #5 from Jeffrey A. Law ---
Fixed by Vlad's patch on the trunk.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #19 from Jeffrey A. Law ---
Fixed by Bin's change on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467
--- Comment #23 from Jeffrey A. Law ---
I've got no objection Joseph. But I think you need to make your case to Richi
and Jakub -- I doubt they're on CC for this BZ :-)
||2018-01-29
CC||law at redhat dot com
Blocks||24639, 19794
Ever confirmed|0 |1
--- Comment #1 from Jeffrey A. Law ---
Thanks Samuel. This isn't fixed on the trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84064
--- Comment #2 from Jeffrey A. Law ---
I wasn't ever happy with the discrepancy between the computation of TO_ALLOCATE
in the layout code and ALLOCATE within ix86_expand_prologue. It seemed ripe to
fall into this kind of problem. sigh.
If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2018-01-24
CC||law at redhat dot com
Ever confirmed|0 |1
--- Comment #5 from Jeffrey A. Law ---
In the reduced testcase we have:
;; basic block 3, loop depth 1, count 10737436510031 (estimated locally
||law at redhat dot com
Resolution|--- |DUPLICATE
--- Comment #2 from Jeffrey A. Law ---
Almost certainly a duplicate.
*** This bug has been marked as a duplicate of bug 83055 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83055
Jeffrey A. Law changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994
--- Comment #3 from Jeffrey A. Law ---
I think the problem here is that we don't force the register saves to happen
prior to probing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #16 from Jeffrey A. Law ---
Well, my understanding of how other compilers have handled bitfields would
indicate that deferring optimization of them until later is advisable.
Essentially they pretended bitfields had word precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83883
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
Jeffrey A. Law changed:
What|Removed |Added
Target Milestone|8.0 |9.0
--- Comment #18 from Jeffrey A.
,
||law at redhat dot com
--- Comment #14 from Jeffrey A. Law ---
I wonder if this could be addressed with a more reasonable address computation
reassociation.
_14 = index.6_13 * 8; <- here
_16 = x_15(D) + _14;
_17 = *_16;
_20 = _14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #13 from Jeffrey A. Law ---
I realize the warnings are happening in VRP1. EVRP and VRP1 use different
styles of analysis and it can be the case that one is better suited for
cleaning things up than the other.
But I really should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #11 from Jeffrey A. Law ---
What do the dumps look like? In particular evrp & vrp1?
||2018-01-17
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
Ever confirmed|0 |1
--- Comment #7 from Jeffrey A. Law ---
Thanks David!
Idiot moment on my end. There's two functions and DSE is happening in each.
It happens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83883
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405
Jeffrey A. Law changed:
What|Removed |Added
Target Milestone|8.0 |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972
--- Comment #13 from Jeffrey A. Law ---
Folks where unhappy with various aspects of that patch. Bernd left Red Hat
shortly thereafter and the patch hasn't been updated since his departure.
||law at redhat dot com
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #5 from Jeffrey A. Law ---
Fixed by Martin's patch on the trunk.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #4 from Jeffrey A. Law ---
Fixed by Nathan's patch on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82682
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||law at redhat dot com
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=72785
Resolution|--- |INVALID
--- Comment #10 from Jeffrey A. Law ---
So look
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #7 from Jeffrey A. Law ---
Fixed by Bin's change on the trunk.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #9 from Jeffrey A. Law ---
Fixed by Martin's patch on the trunk.
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #8 from Jeffrey A. Law ---
Fixed on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
--- Comment #21 from Jeffrey A. Law ---
I'm pretty sure the testcase from c#16 is a different underlying issue and an
DUP of an existing BZ. Note the ASMs. Jump threading is (overly) conservative
when it encounters an ASM on the path and
||2018-01-08
CC||law at redhat dot com
Summary|[7/8 Regression] Changes in |[7 Regression] Changes in
|ivopts caused perf |ivopts caused perf
|regression on x86 |regression
||law at redhat dot com
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83438
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81308
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83721
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81308
Jeffrey A. Law changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #7
||law at redhat dot com
Resolution|--- |DUPLICATE
--- Comment #2 from Jeffrey A. Law ---
Yes, a dup of 81308 which I've got prototype patches to fix.
*** This bug has been marked as a duplicate of bug 81308 ***
at gcc dot gnu.org |law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81308
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #29 from Jeffrey A. Law ---
This was fixed except for the pr56812 failures which are being tracked via
pr81038.
601 - 700 of 3054 matches
Mail list logo
