]
|failure in ldlang.c:6868|Assertion failure in
|when compiling with -flto |ldlang.c:6868 when
||compiling with -flto
CC||law at redhat dot com
--- Comment #12 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #15 from Jeffrey A. Law ---
Comment on attachment 48288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48288
gcc10-pr94567.patch
I think that'll work. If it passes, consider it approved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #13 from Jeffrey A. Law ---
Sigh. That code is good in that it's rejecting matching the pattern for the
SImode sign bit that we can't implement. For some dumb reason I was thinking
it was changing how we split, but it's actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #11 from Jeffrey A. Law ---
Rather than extending that hack, I think just widening the mode when the sign
bit is being tested (c#5) is simpler and easier to understand. The bits you're
changing should be killed rather than extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #7 from Jeffrey A. Law ---
I think it's trying to use smaller modes because the encodings can be smaller.
In other cases it changes the mode to avoid partial register stalls. It's a
bit of a mess.
WRT the fragment you mentioned, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #5 from Jeffrey A. Law ---
I've pondered just killing that pattern, but I'm pretty sure there'll be
notable regressions. There was a clear regression we fixed in gcc-6 due to not
handling QImode operands in that pattern.
What I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #2 from Jeffrey A. Law ---
THanks Martin. I'm already well into this one :-)
I'm pretty sure the problem is testqi_ext_3 and the code we generate when
splitting it.
Consider (from my own slightly reduced testcase, but I'm sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94556
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799
Jeffrey A. Law changed:
What|Removed |Added
Priority|P1 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275
--- Comment #21 from Jeffrey A. Law ---
So we may be able to address this by setting "do_not_record" if we have
multiple sets in an insn, one of which is a reg->reg copy to a destination that
is mentioned in a REG_UNUSED note. We'd only need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275
--- Comment #20 from Jeffrey A. Law ---
90275, the gift that keeps giving. While the failure is similar, this feels
slightly different.
In this case we've got:
(insn 60 54 61 4 (parallel [
(set (reg:CC 100 cc)
||2020-03-30
CC||law at redhat dot com
Status|UNCONFIRMED |NEW
--- Comment #3 from Jeffrey A. Law ---
Confirmed. My tester tripped over this as well.
No special options are needed at configure time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91614
--- Comment #4 from Jeffrey A. Law ---
I think the ARM maintainers need to make a decision here.
Bernd, you might want to ping that last patch.
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91498
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94254
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94315
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #7 from Jeffrey A. Law ---
Fixed on the trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94283
--- Comment #5 from Jeffrey A. Law ---
*** Bug 94284 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94284
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94284
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94238
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94238
Jeffrey A. Law changed:
What|Removed |Added
CC||andrea.corallo at arm dot com
---
||law at redhat dot com
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Jeffrey A. Law ---
Same core issue as 94238, simplify_logical_relational_operation does not
validate that the chosen comparison code is valid for the comparison mode
CC||law at redhat dot com
--- Comment #2 from Jeffrey A. Law ---
Almost certainly the bug we were looking at earlier today Jakub.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955
Jeffrey A. Law changed:
What|Removed |Added
Target Milestone|10.0|11.0
--- Comment #10 from Jeffrey A.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94238
--- Comment #3 from Jeffrey A. Law ---
Got it. simplify-rtx does not validate that a comparison opcode it simplifies
to is valid for the mode.Fixing looks trivial. Unfortunately something
happened overnight that is causing regressions all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94238
--- Comment #2 from Jeffrey A. Law ---
Just getting started here. But at least CSE seems to be doing exactly what we
want.
We have this going into cse1:
(insn 15 14 16 4 (set (mem/c:SI (symbol_ref:DI ("c") [flags 0x2] ) [1 c+0 S4 A32])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jeffrey A. Law changed:
What|Removed |Added
Assignee|jamborm at gcc dot gnu.org |law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303
Jeffrey A. Law changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275
Jeffrey A. Law changed:
What|Removed |Added
Summary|[8/9/10 Regression] ICE: in |[8/9 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303
--- Comment #5 from Jeffrey A. Law ---
Umm, the issue was bisected to a sccvn change, so I'm not sure why is landing
on Vlad. Richi or someone familiar with SCCVN needs to take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601
--- Comment #27 from Jeffrey A. Law ---
So I just prototyped a bit of code that might help with this BZ.
This seems better suited for match.pd, except that match.pd doesn't seem to
want to handle BIT_FIELD_REF nodes. So I did the prototype in
||law at redhat dot com
||law at redhat dot com
--- Comment #10 from Jeffrey A. Law ---
Concur with Jakub on this. We don't even consider Fortran or Ada bugs as
release blockers and I'm pretty sure it's used more than D. Adjusting
accordingly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93996
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93996
--- Comment #10 from Jeffrey A. Law ---
So what seems to be happening here for the original test is we have something
like this just before split3:
(insn 14 13 28 2 (parallel [
(set (mem/v:SI (reg/f:DI 0 x0 [97]) [-1 S4 A32])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465
--- Comment #9 from Jeffrey A. Law ---
So from the uninit analyzer's standpoint the clobber isn't considered an
initialization (which makes sense). As a result the object really does appear
to be uninitialized.
struct function D.35879;
[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jeffrey A. Law changed:
What|Removed |Added
Assignee|law at redhat dot com |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94060
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94060
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: law at redhat dot com
Target Milestone: ---
gimple_or_expr_nonartificial_location will extract a location from the passed
in expr node. That's generally the wrong thing to do.
For gcc-11 that code should either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
--- Comment #9 from Jeffrey A. Law ---
Should be fixed on the trunk now. I'm going to be opening a distinct bug for
cleanup/removal of the code which extracts a (likely incorrect) location from
the expression -- I wasn't comfortable moving on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #12
||law at redhat dot com
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962
Jeffrey A. Law changed:
What|Removed |Added
Summary|[10 regression] bootstrap |bootstrap fails with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962
--- Comment #5 from Jeffrey A. Law ---
Absolutely.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93996
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #47 from Jeffrey A. Law ---
Martin, yea, your patch does prevent creation of the V_C_E. That in turn
allows maybe_a$live_7 to be directly used in the conditional which in turn
allows tree-ssa-uninit.c to realize the problematic path
|NEW
CC||law at redhat dot com
||law at redhat dot com
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91797
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91797
--- Comment #7 from Jeffrey A. Law ---
I didn't look at the history to see who marked it a P1. I did consider the
possibility that this was being kept open because the test failures, while
seemingly innocuous, were actually something much more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91797
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91799
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91890
--- Comment #7 from Jeffrey A. Law ---
Another tidbit. It looks like the sprintf warning will at times ignore the
passed in location. I'm not suggesting this is necessarily the right fix, but
if we make gimple-ssa-warn-restrict honor the
,
||law at redhat dot com
--- Comment #6 from Jeffrey A. Law ---
This really looks like a line mapping issue to me. I think Manu is totally
offbase.
At the time of the diagnostic we have 3 items in
context->classification_history. One for each of the igno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93823
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93707
Jeffrey A. Law changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93823
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93926
--- Comment #6 from Jeffrey A. Law ---
I wouldn't be surprised if the biggest need for permissiveness is for configure
tests :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
--- Comment #12 from Jeffrey A. Law ---
It would seem like C ought to be able to set the flag across the board. But
Richi would know best if this is going to run afoul of of the alias oracle
implementation & underlying gimple semantics.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92417
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #3
||law at redhat dot com
Resolution|--- |WORKSFORME
--- Comment #3 from Jeffrey A. Law ---
So I tried a variety of revisions from April 29, 2019, but was unable to
reproduce this problem. I also tried a subset of those revisions under
valgrind just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
--- Comment #12 from Jeffrey A. Law ---
Definitely an IVOPTS problem of some kind. It shouldn't be using some_enum
types for the induction variables. It's probably a one-line fix for whomever
knows the code. Bin?
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93923
--- Comment #6 from Jeffrey A. Law ---
ISTM that if the standard disallows, then we should as well. We could always
raise a DR if we think the standard ought to be updated to be more user
friendly in what it accepts.
I think I ran into maybe a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92342
--- Comment #14 from Jeffrey A. Law ---
That wouldn't be a big surprise Andrew.
My point is I think we could create some match.pd patterns to canonicalize the
form in gimple and it wouldn't matter nearly as much what combine did or didn't
do to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92539
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955
--- Comment #8 from Jeffrey A. Law ---
Just to be clear, it's not DOM or threading that introduces any out of bounds
accesses or overflows here.
So the testcase:
/* { dg-do compile } */
/* { dg-additional-options "-Wall -Werror" } */
void
||law at redhat dot com
--- Comment #11 from Jeffrey A. Law ---
Couldn't we just fix this kind of stuff in gimple?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92955
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #7
||law at redhat dot com
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93435
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 93564, which changed state.
Bug 93564 Summary: [10 Regression] 470.lbm regresses by 25% on znver2 with
-Ofast -march=native LTO and PGO since r10-6384-g2a07345c4f8dabc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
||law at redhat dot com
Resolution|--- |FIXED
--- Comment #4 from Jeffrey A. Law ---
Per c#3.
||law at redhat dot com
||law at redhat dot com
||law at redhat dot com
||law at redhat dot com
--- Comment #6 from Jeffrey A. Law ---
Only affecting EOL systems, moving to P4.
||law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
101 - 200 of 3054 matches
Mail list logo
