https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122009
Filip Kastl changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121993
--- Comment #4 from Filip Kastl ---
My command-line arguments for SPEC are:
runcpu -c fk-O2-generic-lto -l -n 1 -I -i test --rebuild -T peak
So the difference between our command-line arguments look to be:
- I'm doing -i (--size) test instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121993
--- Comment #2 from Filip Kastl ---
Created attachment 62431
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62431&action=edit
spec config file to reproduce the slowdown with
(In reply to cuilili from comment #1)
> I don't have znver2 mach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121999
--- Comment #6 from Filip Kastl ---
(In reply to Richard Biener from comment #5)
> hoping for a non-FDO testcase from fuzzers/rebuilders ;)
Alright. I'll be on the lookout for that :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121999
--- Comment #3 from Filip Kastl ---
Created attachment 62419
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62419&action=edit
spec config file to reproduce the ICE with
Yeah, I meant a full FDO run. -fprofile-generate and -fprofile use.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121999
Bug ID: 121999
Summary: [16 Regression] 453.povray build ICEs since
r16-3945-gc30f58c3f7ec25
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: ice-on-va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121999
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121994
Filip Kastl changed:
What|Removed |Added
Summary|[16 Regression] 15% |[16 Regression] 15%
|sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121994
Bug ID: 121994
Summary: [16 Regression] 15% slowdown of 538.imagick_r on AMD
Zen2 since r16-3396-g9823624395a946
Product: gcc
Version: 16.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121994
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121993
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121993
Bug ID: 121993
Summary: [16 Regression] 20-30% slowdown of 470.lbm on AMD Zen3
and 5-8% slowdown of 519.lbm_r on Zen2 since
r16-3485-gae689f89fb4059
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121991
Bug ID: 121991
Summary: [16 Regression] 15% slowdown of 436.cactusADM and 7%
slowdown of 410.bwaves on Aarch64
Product: gcc
Version: 16.0
Status: UNCONFIRMED
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119927
Filip Kastl changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 119927, which changed state.
Bug 119927 Summary: 5% slowdown of 415.gamess on Intel Ice Lake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119927
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #22 from Filip Kastl ---
Hmm, but the patch makes a few testsuite tests fail. So that would have to be
sorted out.
+FAIL: gcc.dg/optimize-bswapdi-3.c scan-tree-dump-times bswap "64 bit bswap
implementation found at" 3
+FAIL: gcc.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121770
Bug ID: 121770
Summary: [16 Regression] 5% slowdown of 503.bwaves_r on Aarch64
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: missed-optimization, needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #21 from Filip Kastl ---
Created attachment 62292
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62292&action=edit
Patch removing stabilization "hacks" from sort_operands_by_rank()
So I gave this some more time.
I confirmed t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121703
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121703
Bug ID: 121703
Summary: [16 Regression] ubsan: load of value 32695, which is
not a valid value for type 'internal_fn' in
tree-vectorizer.h
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121522
Filip Kastl changed:
What|Removed |Added
Assignee|pheeck at gcc dot gnu.org |unassigned at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121622
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121622
Bug ID: 121622
Summary: [16 Regression] 4-8% slowdown (2% regression against
GCC 15) of xalancbmk (both 2006 and 2017) an Aarch64
Product: gcc
Version: 16.0
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121522
--- Comment #4 from Filip Kastl ---
> just reference each other.
I mean that they reference each other or a single other value -- .MEM_42.
That's why the pass replaces uses of these PHIs with uses of .MEM_42.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121522
--- Comment #3 from Filip Kastl ---
>From the transformations that sccopy1 does, this one causes the problem:
;; Function main (main, funcdef_no=3, decl_uid=2989, cgraph_uid=5,
symbol_order=4)
+Replacing SCC of size 3
int main ()
{
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 121332, which changed state.
Bug 121332 Summary: [16 Regression] 8-16% slowdown of 519.lbm_r on AMD Zen 2
since r16-2601-ge8a51144c02e1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121332
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121332
Filip Kastl changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121522
Filip Kastl changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pheeck at gcc dot
gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121332
--- Comment #1 from Filip Kastl ---
Hm, the benchmark is fast again. So perhaps we should close this bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121447
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121447
Bug ID: 121447
Summary: [16 Regression] ~20% slowdown of 470.lbm since
r16-1644-gaba3b9d3a48a07 on AMD Zen5
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121440
Filip Kastl changed:
What|Removed |Added
Summary|[16 Regression] 50% |50% slowdown of 519.lbm_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121441
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121441
Bug ID: 121441
Summary: [16 Regression] 5% slowdown of 519.lbm_r on aarch64
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: missed-optimization, needs-bisection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121440
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121440
Bug ID: 121440
Summary: [16 Regression] 50% slowdown of 519.lbm_r on Zen5
since r16-2727-g09f0768b55b96c (the fix for pr120941)
Product: gcc
Version: 16.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #43 from Filip Kastl ---
(In reply to H.J. Lu from comment #42)
> Created attachment 62020 [details]
> A new patch
>
> Here is a patch not to limit non all 0s/1s vector loads in the same loop.
> Please try it.
This patch also helps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121332
Bug ID: 121332
Summary: [16 Regression] 8-16% slowdown of 519.lbm_r on AMD Zen
2 since r16-2601-ge8a51144c02e1c
Product: gcc
Version: 16.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #34 from Filip Kastl ---
(In reply to H.J. Lu from comment #33)
> Created attachment 61995 [details]
> An updated patch
>
> Please try this.
The updated patch helps! We go from 233s to 163s. So the patch reverts the
slowdown. I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #30 from Filip Kastl ---
(In reply to H.J. Lu from comment #29)
> Created attachment 61973 [details]
> A new patch
>
> Please try this.
Sadly, this patch doesn't help. Actually, lbm gets compiled into the same
binary with and with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #28 from Filip Kastl ---
Created attachment 61965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61965&action=edit
testcase 2 (reduced lbm, where the spill can be seen)
Ok, I think I have confirmed that there is a spill going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121155
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121155
Bug ID: 121155
Summary: [16 Regression] 4-6% slowdown of 444.namd since
r16-2193-g363b29a9cfbb47
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: misse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #27 from Filip Kastl ---
If I find the spilling, I'll try to produce a testcase where it can be seen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #25 from Filip Kastl ---
(In reply to H.J. Lu from comment #24)
> Why is it bad for znver2?
Oh, I thought we are trying to figure that out. Spilling because of register
pressure, as richi suggested in comment 3, is the best guess w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #23 from Filip Kastl ---
testcase.c
enum { ST, SB, ET, EB, WT, WB }
LBM_initializeGrid() {
double *grid;
grid[ST] = grid[SB] = grid[ET] = grid[EB] =
grid[WT] = grid[WB] = 1.0 / 36.0;
}
Compile with -Ofa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #21 from Filip Kastl ---
Oh, ok. I misunderstood.
Well, you have SPEC CPU 2017, right? Then setting
OPTIMIZE= -Ofast -march=znver2 -mtune=znver2 -g -flto -fdump-rtl-all
should work.
Perhaps you'll also need
COPTIMIZE = -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #19 from Filip Kastl ---
Well, if you want to reproduce the lbm slowdown, you need a Zen2 or Zen5
machine. I'm not sure how I would produce a testcase that would also uncover
the slowdown on other microarchitectures, sorry. If I un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
Filip Kastl changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #17 from Filip Kastl ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121037
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121037
Bug ID: 121037
Summary: [16 Regression] 4-6% slowdown of 482.sphinx3 since
r16-2088-ge9079e4f43d135
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #16 from Filip Kastl ---
Ok, I'll try to extract a smaller testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #13 from Filip Kastl ---
(In reply to Filip Kastl from comment #12)
> As I've commented in pr120957, I've also bisected 9% Zen3 -Ofast
> -march=native slowdown to this commit. That slowdown can also be solved by
> applying the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #12 from Filip Kastl ---
As I've commented in pr120957, I've also bisected 9% Zen3 -Ofast -march=native
slowdown to this commit. That slowdown can also be solved by applying the
patch hjl has provided.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120957
Filip Kastl changed:
What|Removed |Added
Summary|[16 Regression] 6-9%|[16 Regression] 6% slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #11 from Filip Kastl ---
(In reply to H.J. Lu from comment #9)
> Created attachment 61803 [details]
> A patch
>
> Please try this.
Tried applying this on top of r16-1644-gaba3b9d3a48a07.
With r16-1644-gaba3b9d3a48a07 ... 224s
With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120984
Bug ID: 120984
Summary: [16 Regression] Bunch of 'insufficient space for an
object of type...' errors during ubsan bootstrap
Product: gcc
Version: 16.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120957
--- Comment #3 from Filip Kastl ---
I've bisected this on Zen2. It is possible that this is actually two different
slowdowns and only the Zen2 slowdown is caused by r16-1647. I'll bisect on
Zen3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
Filip Kastl changed:
What|Removed |Added
Summary|[16 Regression] 24-40% |[16 Regression] 24-40%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
--- Comment #7 from Filip Kastl ---
>(In reply to Filip Kastl from comment #0)
> there was a 40% exec time slowdown (on another machine I measured only 24%)
> of 527.cam4_r SPEC 2017 benchmark when run with -Ofast -march=native -flto
and this s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120943
--- Comment #3 from Filip Kastl ---
(In reply to H.J. Lu from comment #1)
> Please try:
>
> https://patchwork.sourceware.org/project/gcc/list/?series=48886
Yes, if I apply this patch, the slowdown goes away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120957
--- Comment #1 from Filip Kastl ---
The slowdown is also present on 410.bwaves from 2006 SPEC
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=467.40.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=301.40.0
again, both on Zen2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120959
Bug ID: 120959
Summary: [16 Regression] 9% slowdown of 549.fotonik3d_r on Zen5
since r16-1645-g309dbcea2cabb3
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120957
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120957
Bug ID: 120957
Summary: [16 Regression] 6-9% slowdown of 503.bwaves_r on
Zen{2,3} since r16-1647-gc06979ff957485
Product: gcc
Version: 16.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120956
Filip Kastl changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120956
Bug ID: 120956
Summary: [16 Regression] 6% slowdown of 503.bwaves_r since
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
Filip Kastl changed:
What|Removed |Added
Summary|[16 Regression] 10-40% |[16 Regression] 10-40%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120943
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120943
Bug ID: 120943
Summary: [16 Regression] 5% slowdown of 527.cam4_r on Zen{4,5}
since r16-1643-gd073bb6cfc219d
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
Filip Kastl changed:
What|Removed |Added
Summary|[16 Regression] 20-40% |[16 Regression] 10-40%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120941
Bug ID: 120941
Summary: [16 Regression] 20-40% slowdown of 519.lbm_r on Zen2
since r16-1644-gaba3b9d3a48a07
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #17 from Filip Kastl ---
(In reply to Andrew Pinski from comment #15)
> So it looks like (a * b) are closer in value to (vnb12 * 1.2e+1 - c) than
> (vnb12 * 1.2e+1) is to (a * b - c) .
Btw, for the purpose of me trying to get better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #14 from Filip Kastl ---
If I do -fdump-tree-optimized, I see these two differences in function inl1100:
A has higher numerical error (3.09998e+02)| B has ok numerical error
(3.12012e+02)
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120866
--- Comment #3 from Filip Kastl ---
(In reply to Sam James from comment #1)
> Huh, it's really a trunk regression? I can't yet think of which change
> would've done this.
It seems to be. I've just tested this with trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120866
Filip Kastl changed:
What|Removed |Added
Summary|[16 Regression] pdp11-aout |[16 Regression] pdp11-aout,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120866
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120866
Bug ID: 120866
Summary: [16 Regression] pdp11-aout crosscompiler fails to
build
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: build
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #13 from Filip Kastl ---
My theory is that the "miscompiled" functions are actually two: inl1100 and
inl1120. If I compile these two functions with r16-1549 and the rest of
innerf.f with r16-1550, I get the same gromacs output as wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #12 from Filip Kastl ---
gfortran -std=legacy -c -o innerf.o -Ofast -g -march=native -mtune=native
innerf.f
these are the compile options, btw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #11 from Filip Kastl ---
So the file that is getting "miscompiled" is innerf.f.
I found out by compiling this gromacs source file with r16-1550 GCC and all the
other source files with r16-1549 GCC and then linking that together.
I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 113833, which changed state.
Bug 113833 Summary: 435.gromacs fails verification on with -Ofast
-march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833
Filip Kastl changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #10 from Filip Kastl ---
> Given the nature of the change that caused this (trimming integral ranges
> bounds to match the bitmasks) its probable that a smaller range had some
> other pass make a different decision.
Yeah, I also t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #9 from Filip Kastl ---
Ok, I'll try to find out from which file (maybe even from which function) the
numerical error originates (thanks for the tips, Sam). It will take some time
though since all of the Zen4/5 machines I have avail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
Filip Kastl changed:
What|Removed |Added
Keywords|wrong-code |
--- Comment #6 from Filip Kastl ---
Rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120752
--- Comment #2 from Filip Kastl ---
Created attachment 61680
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61680&action=edit
perf report -n output before Honza's commit
(In reply to Jan Hubicka from comment #1)
> if you happen to have bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120752
--- Comment #3 from Filip Kastl ---
Created attachment 61681
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61681&action=edit
perf report -n output after Honza's commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
--- Comment #3 from Filip Kastl ---
(In reply to Andrew Macleod from comment #2)
> Does it still fail with the fix for PR 120701?
Sadly, the fix for pr120701 doesn't help. I can still replicate this on
r16-1594-gb03e0d69b37f6e and on current t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120752
Bug ID: 120752
Summary: 5% slowdown of 525.x264_r since
r16-1346-gb0d50cbb42ab2c
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120752
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120751
Bug ID: 120751
Summary: [16 Regression] 10-15% slowdown of 454.calculix on
Zen4 and Zen5 since r16-1001-g0291f53f8d2343
Product: gcc
Version: 16.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120751
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
Bug ID: 120747
Summary: [16 Regression] 435.gromacs miscompares since
r16-1550-g9244ea4bf55638
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: wrong-c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120749
Bug ID: 120749
Summary: [16 Regression] 5% slowdown of 548.exchange2_r on
Aarch64
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: missed-optimization,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120749
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120733
--- Comment #2 from Filip Kastl ---
Btw, 500.perlbench and 435.gromacs SPEC CPU benchmarks currently cannot be
built because of this (at least for some combinations of compiler flags).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120221
--- Comment #7 from Filip Kastl ---
So this isn't specific for switches. Rather, this is some kind of forward
propagation of a shift that we don't currently do, right?
1 - 100 of 427 matches
Mail list logo
