https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #15 from Jeffrey A. Law ---
Re: c#13. You were so close :-) Add "-msim" to your command line. THat's one
of the things the baseboards file does for you when you run things under
dejagnu on bfin-elf...
I've sent Aldy instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102436
--- Comment #5 from Jeffrey A. Law ---
Sounds reasonable (not backporting, but holding bug open for now). I'll
probably do some testing with it internally, so if you end up wanting to
revisit the backporting question, reach out I may have usefu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Jeffrey A. Law changed:
What|Removed |Added
Priority|P1 |P4
--- Comment #20 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96779
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987
Bug 19987 depends on bug 96779, which changed state.
Bug 96779 Summary: Failure to optimize comparison of negative version of self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96779
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103278
--- Comment #8 from Jeffrey A. Law ---
Adjusting the threshold didn't help the tests on the other targets. I'll have
to dig a little deeper into those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103388
Jeffrey A. Law changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103231
--- Comment #15 from Jeffrey A. Law ---
And a note, aarch64_be successfully built a linux kernel which had previously
been triggering the same crazy deep call chains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82090
--- Comment #6 from Jeffrey A. Law ---
I never explored the idea, but Bodik has a discussion of recording infeasible
paths in the CFG which would seem to address this issue. He was using the
concept in the context of coverage analysis -- the ide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103470
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95663
--- Comment #21 from Jeffrey A. Law ---
I don't think there's anything inherently wrong with treating 0 + small offset
similarly to 0 when it comes to -fdelete-null-pointer-checks. I suspect it'll
break some poorly written low level code, thoug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102152
--- Comment #3 from Jeffrey A. Law ---
We're just missing an update_stmt to ensure the operand cache is properly
updated. Testing in progress.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102152
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748
--- Comment #4 from Jeffrey A. Law ---
Bernd E. analyzed this in the thread referenced in c#1.
The test links staticly and we're pulling in the weak definition of
pthread_join.
I'm not sure why we're linking statically. Reverting to normal dy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102436
Bug ID: 102436
Summary: [11/12 Regression] Lost Load/Store Motion
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #17 from Jeffrey A. Law ---
Consider that pre-approved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102608
Bug ID: 102608
Summary: [12 regression] Recent change to VN causes bogus
Wuninitialized warnings & kernel build failures
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100748
--- Comment #6 from Jeffrey A. Law ---
Jon -- you might want to sync with the glibc folks. IIUC they're rolled
libpthread into libc in glibc-2.34 which may make this is a non-issue going
forward, which I can certainly live with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706
Bug ID: 102706
Summary: [12 regression] -O2 vectorization causes regression in
Warray-bounds-48.c on many targets
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102744
Bug ID: 102744
Summary: [12 regression] -O2 vectorization causes
Wzero-length-array-bounds-2.c to fail on arc-elf
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102752
Bug ID: 102752
Summary: [12 Regression] Recent change to ldist causing ICE on
msp430-elf, rl78-elf, and xstormy16-elf
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102752
--- Comment #1 from Jeffrey A. Law ---
gcc.dg/tree-ssa/pr45427.c shows the same issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102752
--- Comment #3 from Jeffrey A. Law ---
No worries. This is why we have testing systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102752
Jeffrey A. Law changed:
What|Removed |Added
Last reconfirmed||2021-10-14
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102756
Bug ID: 102756
Summary: [12 Regression] Vectorizer change creates poor code
for c-c++-common/torture/vector-compare-2.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102752
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102756
--- Comment #3 from Jeffrey A. Law ---
So if we consider the behavior as-expected and that this was just a case where
we crossed a heuristic border, I'd be comfortable closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102785
Bug ID: 102785
Summary: [12 Regression] {smul,umul}_highpart changes break
bfin-elf
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102785
--- Comment #2 from Jeffrey A. Law ---
Yea, it could well be a representational problem in the RTL. I didn't try to
debug it at all beyond reduction and noting that cse1 was where the two
compilers diverged in behavior.
I don't personally care
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950
Jeffrey A. Law changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844
--- Comment #23 from Jeffrey A. Law ---
Invalid is invalid. Full stop.
I'll have to put it under a debugger, but I would have expected the nocopy
block to turn into a forwarder -- why do we end up putting statements in here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Jeffrey A. Law changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #12 from Jeffrey A. Law ---
But insns 6, 7 and 8 aren't important here. We have a REG_EQUAL on insn 9
which indicates that (reg:DI 77) has the value 0xffc0. So I would
have expected combine to substitute that into the u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #13 from Jeffrey A. Law ---
Trying 7, 8, 9 -> 10:
7: r140:DI=0x1
8: r141:DI=r140:DI<<0x26
REG_DEAD r140:DI
REG_EQUAL 0x40
9: r139:DI=r141:DI-0x40
REG_DEAD r141:DI
REG_EQUAL 0x3fffc0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #15 from Jeffrey A. Law ---
THe hope is the shift 6 combines with the first shift you emit for
(set (reg:DI 137)
(and:DI (reg:DI 138)
(const_int 274877906880 [0x3fffc0])))
Conceptually this is similar to creating br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #17 from Jeffrey A. Law ---
Vineet: I don't know your priorities and such, but I've got a junior engineer
starting in a bit under two weeks and this would actually be a good issue for
them to tackle as part of learning about GCC. So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #20 from Jeffrey A. Law ---
Yea, I think so (3 shifts). Two for masking, one to put the bits in the right
position. Then we just have to figure out how to combine the initial shift
with the 3 for the masking and ultimately result w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53135
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704
Bug ID: 107704
Summary: [13 Regression] Testsuite regression after recent DCE
changes
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #24 from Jeffrey A. Law ---
Just a note. Raphael and I are going to poke at this from a different
direction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
--- Comment #25 from Jeffrey A. Law ---
To outline what we were thinking. Yes, it's possible that 4->3 combinations
aren't supported. I'd have to sit down with the combine sources to be sure.
So the alternate approach we came up with was to m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107455
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704
--- Comment #2 from Jeffrey A. Law ---
ACK. And as I mentioned, the RTL form looks like it ought to be caught by the
SH specific code to optimize T reg handling. I don't care enough about the SH
to try and debug a missed optimization though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103296
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100647
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107762
Bug ID: 107762
Summary: [13 Regression] Recent change causing regressions on
s390-linux-gnu
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104044
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91625
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87010
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83454
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81495
Jeffrey A. Law changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 57832, which changed state.
Bug 57832 Summary: compiling sha-256 code (xz 5.0.5) generates false warnings
when using -march=native on Atom CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
What|Remove
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67196
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Summa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 80548, which changed state.
Bug 80548 Summary: -Wmaybe-uninitialized false positive when an assignment is
added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 84078, which changed state.
Bug 84078 Summary: false positive for -Wmaybe-uninitialized with __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078
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 84078, which changed state.
Bug 84078 Summary: false positive for -Wmaybe-uninitialized with __asm__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 85301, which changed state.
Bug 85301 Summary: bitfield check causes maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85301
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88897
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Summa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
Jeffrey A. Law changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression] bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96629
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 101770, which changed state.
Bug 101770 Summary: -Wmaybe-uninitialized false alarm with only locals in GNU
diffutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770
What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #9 from Jeffrey A. Law ---
These warnings are certainly sensitive to all kinds of things, so it's possible
it's just gone latent. The only way to be sure would be to bisect all the work
between gcc-12 and the trunk and pour over the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548
--- Comment #11 from Jeffrey A. Law ---
Thanks! So the change in question improves the decisions in the predicate
analysis code, which can be best thought of as a filter for the false positives
that are still in the IL.
As I said in my previous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #5 from Jeffrey A. Law ---
Right. You also have to know the distance from the last probe (possibly an
implicit one) to the start of the alloca space before you can contemplate
eliding the probes in alloca space. There's a hook we c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585
--- Comment #7 from Jeffrey A. Law ---
Raphael and I are poking at this a bit. I can't convince myself that it's
actually safe to use GPR for the bit manipulation patterns.
For rv64 I'm pretty sure the b* instructions are operating on 64bit qu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108038
Bug ID: 108038
Summary: GCC generates poor code for select of consecutive
constants
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039
Bug ID: 108039
Summary: Unnecessary extension on riscv-64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108041
Bug ID: 108041
Summary: ivopts results in extra instruction in simple loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046
--- Comment #10 from Jeffrey A. Law ---
Yes. I should have changed the state on this BZ a few weeks back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95632
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106602
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108247
Bug ID: 108247
Summary: Missed opportunity to generate shNadd on risc-v
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
Bug ID: 108248
Summary: Some insns in the risc-v backend do not have mappings
to functional units
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
--- Comment #2 from Jeffrey A. Law ---
It can certainly get "unduly weird". Basically such instructions get put at
the end of the ready queue as soon as its input dependencies are satisfied. If
there's only a few such instructions, then the re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108247
--- Comment #2 from Jeffrey A. Law ---
We shouldn't use Zba just for the sake of using Zba; it needs to be profitable.
The folks doing the analysis behind this BZ are only looking at instruction
counts -- they're not really thinking about uarch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248
--- Comment #4 from Jeffrey A. Law ---
Yea, thinking about our uarch, we're going to need finer control as well.
There's a subset that ought to execute in any ALU, but there's another subset
that are bound to a specific ALU and are potentially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108253
Bug ID: 108253
Summary: [13 Regression] ICE in set_nonzero_bits
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105517
Bug ID: 105517
Summary: [13 Regression] Missing diagnostic after recent
optimizer improvements
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102844
--- Comment #27 from Jeffrey A. Law ---
We're not using the backward threader to replace DOM's threader yet. I've got
a TODO to push on Aldy's patch, but haven't been able to get to it over the
last couple weeks. It's an, umm, busy time for us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77311
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
101 - 200 of 1404 matches
Mail list logo
