http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56799
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56900
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56900
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
--- Comment #1 from Jeffrey A. Law law at redhat dot com 2013-04-30 19:20:19
UTC ---
It looks like range_fits_type_p may not be handling overflows correctly.
Investigating.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
--- Comment #2 from Jeffrey A. Law law at redhat dot com 2013-05-01 05:13:38
UTC ---
__attribute__ ((noinline))
foo(short unsigned int *p1, short unsigned int *p2)
{
short unsigned int x1, x4;
int x2, x3, x5, x6;
unsigned int x7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57144
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57144
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57144
--- Comment #3 from Jeffrey A. Law law at redhat dot com 2013-05-03 16:37:34
UTC ---
I've checked in a patch to the trunk which should fix this problem. If you
could verify on ia64 it would be greatly appreciated.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
--- Comment #4 from Jeffrey A. Law law at redhat dot com 2013-05-07 04:25:27
UTC ---
Yea, 254.gap is definitely overflowing signed types. I've got changes to make
the warnings and -fno-strict-overflow work that I'll put through their paces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40761
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53126
--- Comment #5 from Jeffrey A. Law law at redhat dot com 2012-05-02 20:15:23
UTC ---
This code should generally follow the logic from gcc.c. We may not need to
support all the environment variables that gcc.c handles. But for those we do
need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53252
Bug #: 53252
Summary: Missed shrink wrapping opportunity
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53253
Bug #: 53253
Summary: Missed opportunity to inline memcmp
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53254
Bug #: 53254
Summary: Missed opportunity to aggregate consecutive stores
into single larger store
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57144
Bug 57144 depends on bug 57124, which changed state.
Bug 57124 Summary: 254.gap@spec2000 got miscompare after r198413
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57124
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57660
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57660
--- Comment #2 from Jeffrey A. Law law at redhat dot com ---
We've got two choices here.
First is to somehow make the number of replacements we look for be conditional
on the target. For targets with an appropriate branch cost (such as m68K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57660
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57805
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57810
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57806
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57790
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57809
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57803
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57782
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57801
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57802
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57804
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58206
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #10 from Jeffrey A. Law law at redhat dot com ---
Zhengong's testcase fails for me, so I'll work with that first.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #11 from Jeffrey A. Law law at redhat dot com ---
I've found a minor error in the tree-ssa-threadedge.c changes. I can easily
see how it affects Zhengong's testcase and I can speculate how it might be
triggering the ia64 failure.
I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #16 from Jeffrey A. Law law at redhat dot com ---
Jan's patch papers over the problem of incorrect initialization of found. I
expect to be able to run through the formalities necessary to install the fix
tonight.
Reverting until I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58342
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #17 from Jeffrey A. Law law at redhat dot com ---
*** Bug 58342 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #18 from Jeffrey A. Law law at redhat dot com ---
I'm seeing ia64 fail with an insn does not match constraints failure when the
stage2 compiler builds the stage2 C++ runtime. And that's *with* the fix I
checked in last night
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58343
--- Comment #2 from Jeffrey A. Law law at redhat dot com ---
Zhendong,
Thanks for the testcase. What's happening here is the code to allow threading
through a simple forwarder block exposes an opportunity to build a
significantly deeper jump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58343
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58373
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
--- Comment #7 from Jeffrey A. Law law at redhat dot com ---
202296 doesn't change anything WRT sequencing of operations; it merely allows
the threader to dive a bit deeper into the CFG to determine a final target for
a jump threading opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
--- Comment #8 from Jeffrey A. Law law at redhat dot com ---
This looks like slightly different variant of 58343 where we thread through a
loop header when we really didn't want to.
I haven't tracked it through to the ICE, but from looking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
--- Comment #11 from Jeffrey A. Law law at redhat dot com ---
Fixed on trunk.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58342
Bug 58342 depends on bug 58340, which changed state.
Bug 58340 Summary: [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler
error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #23 from Jeffrey A. Law law at redhat dot com ---
Obviously in a bootstrap comparison failure we have a situation where the
compiler has mis-compiled itself or something similar. Ultimately I need to be
able to reproduce the failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
--- Comment #21 from Jeffrey A. Law law at redhat dot com ---
Andreas,
ia64 is bootstrapping fine for me. I did one immediately before installing the
patch to fix this PR and just did another one (r202530 of the trunk on
ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #10 from Jeffrey A. Law law at redhat dot com ---
Looks like make_range_step is getting miscompiled. Still trying to figure out
how/why.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #11 from Jeffrey A. Law law at redhat dot com ---
I know what's happening here. It's obscure and quite nasty.
We have a jump threading opportunity which requires threading through a joiner
block. The jump thread leaving one edge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #18 from Jeffrey A. Law law at redhat dot com ---
I'll also note that the plan for the isolated paths that exhibit undefined
behaviour is to have them trap/abort at the statement which triggers the
undefined behaviour.
The original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #14 from Jeffrey A. Law law at redhat dot com ---
It's the action of executing the code with undefined behaviour which is the
trigger. ie, if you don't execute the code, then it has no effect on the
defined/undefined state
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #16 from Jeffrey A. Law law at redhat dot com ---
The optimization came out of building additional warnings for GCC. It's safe
to assume that there'll be an option to enable a warning that the compiler was
able to identify and isolate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
--- Comment #20 from Jeffrey A. Law law at redhat dot com ---
I think an option to eliminate the path entire like the first iteration of the
change did could be easily added later. In fact it would be fairly easy to
add.
Basically we'd arrange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||kazu at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
--- Comment #6 from Jeffrey A. Law law at redhat dot com ---
Reduced testcase:
static __inline__ __attribute__((always_inline))
__attribute__((no_instrument_function)) int test_bit(int nr, const unsigned
long* addr)
{
return (*((volatile unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58401
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58400
--- Comment #7 from Jeffrey A. Law law at redhat dot com ---
*** Bug 58401 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55860
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58431
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58340
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58342
Bug 58342 depends on bug 58340, which changed state.
Bug 58340 Summary: [4.9 regression] gcc/cp/pt.c:7064:1: internal compiler
error: in propagate_threaded_block_debug_into, at tree-ssa-threadedge.c:623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418
--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
*** Bug 58431 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58431
--- Comment #2 from Jeffrey A. Law law at redhat dot com ---
Jakub,
That doesn't make *any* sense. r202489 simply *avoids* doing any jump
threading in certain cases. If that change is indeed the trigger, then the
root cause is going
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35455
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||segher at kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39766
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
Bug 19794 depends on bug 23622, which changed state.
Bug 23622 Summary: Dom jump threading at -O1 confuses branch prediction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23622
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23622
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55860
--- Comment #3 from Jeffrey A. Law law at redhat dot com ---
The other issue here is the loop header which looks like:
bb4:
# iii_16 = PHI iii_12(8), 0(3)
# jkl_17 = PHI jkl_4(8), 0(3)
L1:
if (m_8(D) iii_16)
goto bb 5;
else
goto bb 6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55860
--- Comment #4 from Jeffrey A. Law law at redhat dot com ---
BTW, I did look at walking up the CFG to discover edge equivalences we could
add to our tables. We don't have access to the path through the dominator tree
that we've followed, so I had
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
--- Comment #2 from Jeffrey A. Law law at redhat dot com ---
James. Look in the .ldist dump. In particular look at that memset call.
We're writing off the end of the structure. Now to walk backwards and figure
out why :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
--- Comment #4 from Jeffrey A. Law law at redhat dot com ---
Andrew. Yes it does. I've never looked at the ldist code, but the dump seems
a bit strange:
Analyzing # of iterations of loop 3
exit condition [1, + , 1](no_overflow) != 96
bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||pthaugen at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
Bug 58553 depends on bug 58554, which changed state.
Bug 58554 Summary: [4.9 Regression] Revision 202619 causes runtime failure in
CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554
What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
Bug 58553 depends on bug 58554, which changed state.
Bug 58554 Summary: [4.9 Regression] Revision 202619 causes runtime failure in
CPU2006 benchmark 445.gobmk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554
What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58554
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
--- Comment #8 from Jeffrey A. Law law at redhat dot com ---
Yes, threading is rotating the loop in interesting ways -- I was going to
look at that independently of the correctness issue.
One of the things I've noticed as I've been laying down
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553
--- Comment #12 from Jeffrey A. Law law at redhat dot com ---
Re: Not creating loops with multiple entries, no doubt that's bad.
It would be nice however, to expose loop nesting. ie, prior to threading it
looks like one bug fugly loop. A bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
--- Comment #32 from Jeffrey A. Law law at redhat dot com ---
No, we don't have that information available in any reasonable form. That's
one of the things I need to investigate.
One of the possibilities is to flip things on their side a bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22401
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #6 from Jeffrey A. Law law at redhat dot com ---
It's late and I need to catch some zzzs. But as I hinted in my prior update, I
think we may chasing something latent. I would recommend looking very closely
at r204497, which my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #8 from Jeffrey A. Law law at redhat dot com ---
More eyes never hurt :-) This pair is going to bed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #16 from Jeffrey A. Law law at redhat dot com ---
In reference to c#12. I think the ivopts changes are just setting up the
situation that is mis-handled later. I'd gotten as far as seeing the +128
increment moving in the scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #14 from Jeffrey A. Law law at redhat dot com ---
This feels like the kind of situation where I've always wanted a pass to be
able to say something like I've done some set of transformations, schedule
the appropriate cleanup passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302
Jeffrey A. Law law at redhat dot com changed:
What|Removed |Added
CC||law at redhat dot
501 - 600 of 3054 matches
Mail list logo