https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118353
--- Comment #4 from Filip Kastl ---
Huh. Then either
a) We spend a lot of time in the jump table finding algorithm. That would mean
that there are large switch statements in GCC code specific for those
architectures. Btw, those switch statem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #36 from Filip Kastl ---
(In reply to Mark Wielaard from comment #35)
> Shall we close this bug or keep it open for implementing greedy switch
> clustering for jump tables as suggested in comment #29 ?
I think that it would be bette
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118353
Bug ID: 118353
Summary: Implement greedy algorithm for switch jump table
cluster finding
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118250
--- Comment #3 from Filip Kastl ---
With the modification I plan for Stage 1 the DP alg will be as powerful as the
greedy alg here.
By LLVM code being better I suppose you mean this lower bound check:
cmp eax, 1
jle .L4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #30 from Filip Kastl ---
(In reply to Mark Wielaard from comment #28)
> I haven't tried yet, but do you mean something like the following?
> - /* Note: l + 1 is the number of cases of the switch. */
> - if (l + 1 > (unsigned) para
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #24 from Filip Kastl ---
Thanks for the preprocessed file!
I've looked at -ftime-report to see if the extra time was spent in switch
lowering and found out it is not! Apparently the change in behavior of switch
lowering has an effe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #20 from Filip Kastl ---
Hm, I don't see any memory leak. And if this was about memory leak in the
switch lowering pass I guess the issue would pop up on other architectures too
and someone would notice that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118125
Bug ID: 118125
Summary: [15 Regression] 7-16% slowdown of 510.parest_r on
x86-64(-v3) since r15-6110-g92e0e0f8177530
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118123
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118123
Bug ID: 118123
Summary: [15 Regression] Some vms crosscompilers don't build
since r15-5823-g4ed189854eae2d
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #19 from Filip Kastl ---
(In reply to Andreas Schwab from comment #17)
> r15-6120-g56946c801a7cf3 is causing out-of-memory when compiling
> insn-attrtab.cc in a cross riscv64 build on 32-bit x86.
>
> https://build.opensuse.org/packa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
Filip Kastl changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118059
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118059
Bug ID: 118059
Summary: [15 Regression] ubsan instrumented gcc: valid value
for type 'expr_t' in gcc/fortran/trans-expr.cc
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
--- Comment #23 from Filip Kastl ---
(In reply to Sam James from comment #22)
> Are we keeping this one open for the improvement mentioned in
> https://inbox.sourceware.org/gcc-patches/z1gdhpphod-5m...@fkdesktop.suse.cz/?
I wanted to close this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117352
Filip Kastl changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #154 from Filip Kastl ---
> I suggest you file a new bugreport for the regression.
Ok, it is now pr117922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117922
Bug ID: 117922
Summary: [15 Regression] 1000% compilation time slow down on
the testcase from pr26854
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
Filip Kastl changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #152
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117919
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=117830
Filip Kastl changed:
What|Removed |Added
Summary|[15 Regression] |[15 Regression]
|Miscom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117830
--- Comment #2 from Filip Kastl ---
I just re-checked and it definitely *is* on current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117830
--- Comment #1 from Filip Kastl ---
Actually, let me recheck that this really still happens on current trunk. I may
have made a mistake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117830
Bug ID: 117830
Summary: [14 Regression] Miscompilation of 464.h264ref at -O2
-march=generic
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: needs-bise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117352
--- Comment #4 from Filip Kastl ---
It took me longer than I expected but I've submitted the patch.
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668911.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56504
Filip Kastl changed:
What|Removed |Added
Resolution|--- |FIXED
Last reconfirmed|2013-03-04 00:00:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117576
Bug ID: 117576
Summary: -mveclibabi=aocl: Support vectorized array functions
and maybe also sincos
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: mis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117576
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56504
Filip Kastl changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117562
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117562
Bug ID: 117562
Summary: [15 Regression] 40% slowdown of 482.sphinx3 on Zen4,
Zen5 since r15-5120-g9a62c149589103
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117352
Filip Kastl changed:
What|Removed |Added
CC||pheeck at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115805
--- Comment #3 from Filip Kastl ---
I've just tried this on some older commits but still didn't find a commit
without this behavior so I don't have evidence that this is a regression. The
oldest commit I know where this behavior is present is
r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117428
Filip Kastl changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117270
Bug ID: 117270
Summary: [15 Regression] 9% exec time slowdown of 538.imagick_r
on aarch64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116759
Filip Kastl changed:
What|Removed |Added
Summary|[15 Regression] 5% exec |[15 Regression] ~2.5% exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117123
--- Comment #10 from Filip Kastl ---
I've looked at the pre-details dumps for runs with and without sccopy1 (I'm
compiling the reduced testcase with -Os). Even when I adjust for different SSA
name versions, there are many differences in the dum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117123
--- Comment #9 from Filip Kastl ---
Btw, here is a reduced testcase:
-
struct Potato {
bool isMashed;
};
void dont_be_here();
int patatino_a;
void patatino() {
if (patatino_a && patatino_a % 2 == 0 && patatino_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
--- Comment #12 from Filip Kastl ---
(In reply to Andi Kleen from comment #9)
> Yes I guess we should keep better switches at -O1 because machine generated
> code may have lot of switches.
>
> I don't think we need perfect clustering? Perhaps t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117123
--- Comment #7 from Filip Kastl ---
It is not in a loop. I guess I'll double-check that there aren't any
differences which I didn't notice. There is one here:
57 # spud$size_22 = PHI <10(4), a_24(D)(2), a_24(D)(3)>
44 # spud$size_55 = PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117123
--- Comment #5 from Filip Kastl ---
PRE is the pass that should be able to optimize most of the code in the
testcase away. It doesn't remove the code if sccopy1 has run. I looked at
gimple dumps before PRE for compiler runs with sccopy1 and wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117123
Filip Kastl changed:
What|Removed |Added
Last reconfirmed||2024-10-16
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116758
Filip Kastl changed:
What|Removed |Added
Summary|[15 Regression] 25-40% |[15 Regression] 25-40%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
--- Comment #8 from Filip Kastl ---
I've looked into analyze_switch_statement(), find_bit_tests() and
find_jump_tables() and did some perf-ing. Some observations:
1) I don't think that the code in SNIPPET 1 is responsible for the slowness.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116998
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116998
Bug ID: 116998
Summary: [15 Regression] 5% slowdown of 400.perlbench on AMD
Zen3/4 since r15-3986-g3e1bd6470e4deb
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116985
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116985
Bug ID: 116985
Summary: [15 Regression] ICE in vectorizer with
--param=vect-partial-vector-usage=2 -mavx512vbmi2
since r15-2097-gdb3c8c9726d0ba
Product: gcc
Vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116948
--- Comment #5 from Filip Kastl ---
We run the ubsan bootstrap roughly every week. We also have a simple script
that searches the logs for errors. It looks like this
find gcc/testsuite -name "*.log" | xargs cat | ...
here we pipe output thro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116878
--- Comment #2 from Filip Kastl ---
Yeah, sorry about that. I just pushed the patch that Andrew linked. That
should fix this. I'll close this PR if no one objects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116616
--- Comment #5 from Filip Kastl ---
The patch I pushed to trunk should fix this issue. I will wait a bit and then
close this PR.
Btw, as a follow-up to this, one could modify some RTL pass to pattern match
(var ^ (var - 1)) > (var - 1) to some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116936
--- Comment #2 from Filip Kastl ---
To replicate this bug, you can do for example
gcc -x c++-header ./gcc/testsuite/g++.dg/header.C
or
gcc -x c-header ./gcc/testsuite/gcc.dg/header.c
There are many more GCC testsuite testcases that produce t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116936
--- Comment #1 from Filip Kastl ---
This is the configuration of the UBSAN-instrumented GCC:
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/worker/buildworker/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116936
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116936
Bug ID: 116936
Summary: [UBSAN] gcc/diagnostic.cc: null pointer passed as
argument
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115966
Filip Kastl changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 115966, which changed state.
Bug 115966 Summary: [15 Regression] Miscompilation of 403.gcc with -Ofast
-march=native on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115966
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116309
Filip Kastl changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 112916, which changed state.
Bug 112916 Summary: [14/15 Regression] ~4-7% exec time regression of 433.milc
on AMD Zen2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112916
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 113832, which changed state.
Bug 113832 Summary: [14/15 Regression] 6% exec time regression of 464.h264ref
on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
What|Removed |A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
Filip Kastl changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 115856, which changed state.
Bug 115856 Summary: [15 Regression] 7% slowdown of 433.milc on Zen3 since
r15-1735-ge62ea4fb8ffcab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115856
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112916
Filip Kastl changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 112549, which changed state.
Bug 112549 Summary: [14/15 Regression] 9% exec time regression of 436.cactusADM
on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112549
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112549
Filip Kastl changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115856
Filip Kastl changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111875
Filip Kastl changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
Bug 82738 depends on bug 111875, which changed state.
Bug 111875 Summary: With -Og ubsan check inserted even though
__builtin_assume_aligned guarantees no UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111875
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078
--- Comment #6 from Filip Kastl ---
Or maybe one binary has some expensive instructions which the other one
doesn't. I didn't notice anything like that while looking through the perf
results but I'm still learning to use perf effectively.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078
--- Comment #5 from Filip Kastl ---
I've double checked that the slowdown really happens on this commit. It realy
does. I've also double checked that the resulting binary is different. I've
seen this slowdown on 2 separate Zen 2 machines.
I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078
Filip Kastl changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Keywor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116076
--- Comment #4 from Filip Kastl ---
Should I leave this bug open or close it, then? What do you think, Richard?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116076
Filip Kastl changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116761
Filip Kastl changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116760
Filip Kastl changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116309
--- Comment #1 from Filip Kastl ---
This ICE no longer occurs. If no one objects, I'll close this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115966
--- Comment #5 from Filip Kastl ---
This miscompilation no longer happens. If no one objects, I'll close this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116790
--- Comment #3 from Filip Kastl ---
(In reply to Richard Biener from comment #2)
> I will eventually have a look. LNT indeed only has zen3 regressing in this
> unusal config (-O2 -flto + PGO), but maybe Zen3 is the only machine testing
> this c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847
--- Comment #9 from Filip Kastl ---
If you look at the graph, it looks like the slowdown went away.
Should I close this PR?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832
--- Comment #8 from Filip Kastl ---
If you look at the graph, you can see that the slowdown went away (well, it
returned a few times but currently the benchmark is fast).
If no one objects, I'll close this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112916
--- Comment #5 from Filip Kastl ---
I've looked at the graph again and it is true that the graph is very noisy.
If no one objects, I'm going to close this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112549
--- Comment #5 from Filip Kastl ---
The slowdown I reported originally disappeared. If you look at the graph, you
can see that the benchmark currently runs slower than on g:ada871cfadd3f496 but
it's now unclear where the slowdown occured (it was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116790
Filip Kastl changed:
What|Removed |Added
Summary|[15 Regression] 6% slowdown |[15 Regression] 6% slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115856
--- Comment #2 from Filip Kastl ---
Looks like the slowdown went away. If no one objects, I'll close this PR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111875
--- Comment #4 from Filip Kastl ---
Ok, I see. There's not much point in optimizing everything on -Og -fsanitize
and it can also lead to sanitizer checks not working properly.
If no one objects, I'll mark this as RESOLVED INVALID.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116790
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116790
Bug ID: 116790
Summary: [15 Regression] 6% slowdown of 454.calculix on AMD Zen
3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116763
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116763
Bug ID: 116763
Summary: 14-19% slowdown of 436.cactusADM on aarch64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization, needs-bisection
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116761
--- Comment #1 from Filip Kastl ---
This graph plots results of -march=x86_64v3 -Ofast -flto.
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=1119.230.0
A spike can be seen in this graph too so maybe this is a general x86_64
slowdown? H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116761
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116761
Bug ID: 116761
Summary: [15 Regression] 4-6% slowdown of 465.tonto on AMD
Zen3/4
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116760
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116760
Bug ID: 116760
Summary: [15 Regression] 6-11% slowdown of 416.gamess on AMD
Zen3 and Zen4
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116759
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116759
Bug ID: 116759
Summary: [15 Regression] 5% exec time slowdown of 538.imagick_r
on aarch64
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: needs-bisect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116758
--- Comment #1 from Filip Kastl ---
Btw I looked and didn't see any execution time speedups of wrf that would
balance out these regressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116758
Filip Kastl changed:
What|Removed |Added
Target Milestone|--- |15.0
1 - 100 of 215 matches
Mail list logo
