[Bug c++/113746] [14 Regression] ICE: tree check: expected enumeral_type, have error_mark in tsubst_expr, at cp/pt.cc:21458 with missing typename

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113746

Filip Kastl  changed:

   What|Removed |Added

 CC||fkastl at suse dot cz

--- Comment #3 from Filip Kastl  ---
Why shouldn't this be a regression? I've just bisected it to
g:3e3d73ed5e85e7f467c366e9ad219d558ef9cb79.

Could someone please add the author of the commit to CCs and also remove the
"needs-bisection" keyword?

[Bug target/113847] [14 Regression] 10% slowdown of 462.libquantum on AMD Ryzen 7700X and Ryzen 7900X

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847

Filip Kastl  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||rguenth at gcc dot gnu.org

--- Comment #1 from Filip Kastl  ---
Bisected to g:724b64304ff5c8ac08a913509afd6fde38d7b767 (I did the bisection on
Ryzen 7900X)

[Bug modula2/113848] New: modula2 doesn't build with clang

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113848

Bug ID: 113848
   Summary: modula2 doesn't build with clang
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Building GCC using clang with modula2 language enabled raises this error.

m2/gm2-libs-boot/SArgs.c:93:90: error: arithmetic on a pointer to void
   93 |   ppc = static_cast ((void *) (((void *)
(UnixArgs_GetArgV ()))+(n*sizeof (SArgs_PtrToChar;
  | 
^

This started happening between

g:fbb569315a291d2d5b32ad0fdaf0c42da9f5e93b and
g:260a22de4fa3d4ad3bb0d3ef2cd45d7f03eb3160

The only commit touching ./gcc/m2/gm2-libs/Sargs.{def,mod} is

g:64b0130bb6702c67a13caefaae9facef23d6ac60

so I suppose that's the culprit commit.


The build is configured using
--disable-multilib --disable-libsanitizer --disable-bootstrap
--with-system-zlib --enable-languages=c,c++,fortran,go,jit,lto,rust,m2
--enable-host-shared

[Bug target/113847] New: [14 Regression] 10% slowdown of 462.libquantum on AMD Ryzen 7700X and Ryzen 7900X

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847

Bug ID: 113847
   Summary: [14 Regression] 10% slowdown of 462.libquantum on AMD
Ryzen 7700X and Ryzen 7900X
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization, needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

As seen here

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=956.210.0

between commits

g:d826596acb02edf4

and

g:23cd2961bd2ff635

there is about 10% slowdown of execution time of the 2006SPEC 462.libquantum
benchmark.

The test is run with -O2 and lto on an AMD Ryzen 7700X.

I also reproduced the slowdown on a AMD Ryzen 7900X machine. However I wasn't
able to reproduce the slowdown on an AMD EPYC machine - also Zen4
microarchitecture. So I suppose this slowdown occurs only on Zen4 Ryzen CPUs or
is maybe even more specific.

I'm not sure if we want to do anything about this. The same slowdown on the
same machine has already happened once, see pr112547. The benchmark results
eventually returned to the original values.

[Bug target/113832] New: [14 Regression] 6% exec time regression of 464.h264ref on aarch64

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832

Bug ID: 113832
   Summary: [14 Regression] 6% exec time regression of 464.h264ref
on aarch64
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: aarch64-gnu-linux
Target: aarch64-gnu-linux

As seen here

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=586.220.0

between commits

g:cc7aebff74d89675
g:314cbfe2980b32f5

there is a 6% slowdown of the 464.h264ref 2006 SPEC benchmark. Compiler options
are:

-Ofast -march=native -flto PGO

The CPU is Ampere Altra - Neoverse N1.

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

--- Comment #9 from Filip Kastl  ---
(In reply to Richard Biener from comment #8)
> Does this still happen after r14-8413-g578c7b91f418eb?

I think it doesn't happen anymore.

I can confirm that both on aarch64 and zen3, both the SPEC2006 and SPEC2017,
with -Ofast -march=native -mtune=native -flto perlbench compiles correctly now.

[Bug tree-optimization/112687] missed-optimization: switch statement does not simplify to it's expression

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112687

--- Comment #2 from Filip Kastl  ---
Created attachment 57222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57222=edit
WIP patch to fix the missed optimization, version 0

I'm working on a patch. The problem (as Richard stated in pr112645) is that the
testcase gets optimized into

switch (v & 3) {
default:
return 0;
case 1:
return 1;
case 2:
return 2;
case 3:
return 3;
}

so the information that there are only 4 possible values of the expression 'v &
3' is lost.

I add capability for switch conversion to recover from this. With my patch,
before processing the switch, switch conversion finds out if the default case
only corresponds to one possible value of the index expression. If so, it
creates a case for this value and marks default as unreachable.

With the patch applied, functions opt() and unopt() compile into the same
sequence of assembly instructions. I've attached the patch. Do you think this
is a good approach? I'll also appreciate any suggestions/comments for the
patch.

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

--- Comment #7 from Filip Kastl  ---
I just reproduced the same issue on an x86_64 zen3 machine. Running both
500.perlbench_r and 400.perlbench with options -Ofast -march=native
-mtune=native -g -flto=32 results in

*** Miscompare of checkspam.2500.5.25.11.150.1.1.1.1.out

That means this is probably not only an aarch64 issue.

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

Filip Kastl  changed:

   What|Removed |Added

 CC||fkastl at suse dot cz

--- Comment #6 from Filip Kastl  ---
I just reproduced the same issue on an x86_64 zen3 machine. Running both
500.perlbench_r and 400.perlbench with options -Ofast -march=native
-mtune=native -g -flto=32 results in

*** Miscompare of checkspam.2500.5.25.11.150.1.1.1.1.out

That means this is probably not only an aarch64 issue.

[Bug target/112804] ICE in aarch64 crosscompiler in plus_constant, at explow.cc:102 with -mabi=ilp32 and -finline-stringops

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804

Filip Kastl  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Filip Kastl  ---
Marking this as fixed.

[Bug target/113116] [14 Regression] ~11-17% exec time regression of 436.cactusADM on aarch64

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113116

--- Comment #3 from Filip Kastl  ---
(In reply to Tamar Christina from comment #2)
> Did you mean -Ofast native PGO? both linked runs are PGO.

Yes I did. I meant PGO and wrote LTO. My bad :).

[Bug target/113116] ~11-17% exec time regression of 436.cactusADM on aarch64

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113116

Filip Kastl  changed:

   What|Removed |Added

 Blocks||26163

--- Comment #1 from Filip Kastl  ---
The cpu is ampere altra


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug target/113116] New: ~11-17% exec time regression of 436.cactusADM on aarch64

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113116

Bug ID: 113116
   Summary: ~11-17% exec time regression of 436.cactusADM on
aarch64
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization, needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: aarch64-linux-gnu
Target: aarch64-linux-gnu

As seen on the graphs here

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=578.100.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=586.100.0

between commits
g:8e0568d8ac9dbfc8
g:5641787abeea0fdc

there is a slowdown of 436.cactusADM SPEC2006 benchmark, 11% for Ofast native
LTO PGO and 17% for Ofast native LTO.

This is on aarch64. I haven't seen similar slowdowns on other architectures.

[Bug target/113115] New: ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115

Bug ID: 113115
   Summary: ICE In extract_constrain_insn_cached recog.cc with
ppc64le-linux-gnu crosscompiler
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: ppc64le-linux-gnu

While compiling the GCC testcase gcc.target/powerpc/pr103627-3.c with the
ppc64le crosscompiler the with these options:

ppc64le-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr103627-3.c
-mno-power8-vector

the compiler runs into an ICE

/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr103627-3.c:
In function ‘main’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr103627-3.c:19:1:
error: insn does not satisfy its constraints:
   19 | }
  | ^
(insn 55 54 56 (set (reg:OO 32 0)
(mem/c:OO (plus:DI (reg/f:DI 9 9 [128])
(const_int 32 [0x20])) [2 c+32 S32 A256]))
"/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr103627-3.c":12:1
2172 {*movoo}
 (nil))
during RTL pass: shorten
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/powerpc/pr103627-3.c:19:1:
internal compiler error: in extract_constrain_insn_cached, at recog.cc:2725
0x654383 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/rtl-error.cc:108
0x6543a9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/rtl-error.cc:118
0x6538ee extract_constrain_insn_cached(rtx_insn*)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/recog.cc:2725
0x1352337 insn_default_length(rtx_insn*)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/config/rs6000/rs6000.md:15156
0x8eada2 shorten_branches(rtx_insn*)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/final.cc:1089
0x8eaddf rest_of_handle_shorten_branches
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/final.cc:4338
0x8eaddf execute
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/gcc/final.cc:4367
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


Compiler configuration:

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/ppc64le-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/ppc64le-linux-gnu/14.0.0/lto-wrapper
Target: ppc64le-linux-gnu
Configured with:
/home/worker/buildworker/tiber-gcc-trunk-ppc64le/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release
--prefix=/home/worker/cross --target=ppc64le-linux-gnu
--with-as=/usr/bin/powerpc64le-suse-linux-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231221 (experimental)
ec2ec24a4d4d1175f72641a95010c2312eb38ccd (GCC)

[Bug target/113114] New: ICE in try_promote_writeback aarch64-ldp-fusion.cc

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113114

Bug ID: 113114
   Summary: ICE in try_promote_writeback aarch64-ldp-fusion.cc
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: aarch64-linux-gnu

While compiling the GCC testcase gcc.c-torture/execute/pr59643.c using an
aarch64 crosscompiler with these options

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.c-torture/execute/pr59643.c
-mabi=ilp32 -O2

the compiler runs into an ICE

during RTL pass: ldp_fusion
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.c-torture/execute/pr59643.c:
In function ‘foo’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.c-torture/execute/pr59643.c:11:1:
internal compiler error: in try_promote_writeback, at
config/aarch64/aarch64-ldp-fusion.cc:2604
   11 | }
  | ^
0x789ba3 try_promote_writeback
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/config/aarch64/aarch64-ldp-fusion.cc:2604
0x789ba3 ldp_fusion_bb(rtl_ssa::bb_info*)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/config/aarch64/aarch64-ldp-fusion.cc:2635
0x11bc4a7 ldp_fusion()
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/config/aarch64/aarch64-ldp-fusion.cc:2655
0x11bc528 execute
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/config/aarch64/aarch64-ldp-fusion.cc:2705
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


Configuration of the compiler:

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with:
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release
--prefix=/home/worker/cross --target=aarch64-linux-gnu
--with-as=/usr/bin/aarch64-suse-linux-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231221 (experimental)
ec2ec24a4d4d1175f72641a95010c2312eb38ccd (GCC)

[Bug tree-optimization/113054] [14 regressions] ODR warnings when building new SCCP pass

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113054

--- Comment #9 from Filip Kastl  ---
Alright. I suppose this change wouldn't be appropriate in stage 3 nor stage 4,
so I'll wait for the next stage 1 and modify sccopy to use a class.

[Bug tree-optimization/113054] [14 regressions] ODR warnings when building new SCCP pass

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113054

--- Comment #7 from Filip Kastl  ---
Thanks for the fix! Will be careful not to trigger ODR with my future patches.

(In reply to Andrew Pinski from comment #2)
> Note I also don't like how dead_stmts is a static variable either but that
> would be for another change.

How should I get rid of the static variable? Maybe wrap the copy propagation
algorithm in a class as I wrapped the SCC finding algorithm?

[Bug tree-optimization/113069] gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field]

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113069

--- Comment #4 from Filip Kastl  ---
Its a statement I forgot to remove. Thanks for the fix!

[Bug tree-optimization/112678] [14 regression] Massive slowdown of compilation time with PGO since r14-5579-g20a3c74c347429

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678

Filip Kastl  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Filip Kastl  ---
Marking this as fixed.

[Bug tree-optimization/113018] New: ICE in gimple_convert, gimple-fold.cc during the SLP pass

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113018

Bug ID: 113018
   Summary: ICE in gimple_convert, gimple-fold.cc during the SLP
pass
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, needs-bisection
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: aarch64-gnu-linux

While compiling the GCC testsuite testcase gcc.target/aarch64/vect-fmax-fmin.c
with aarch64 crosscompiler:

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/aarch64/vect-fmax-fmin.c
-fno-tree-loop-vectorize -Ofast

An ICE occurs:

during GIMPLE pass: slp
In file included from
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/aarch64/vect-fmax-fmin.c:8:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/aarch64/vect-fmaxv-fminv.x:
In function ‘maxv_f32’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/aarch64/vect-fmaxv-fminv.x:5:7:
internal compiler error: Segmentation fault
5 | float maxv_f32 (pRF32 a)
  |   ^~~~
0xd938df crash_signal
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/toplev.cc:316
0xa7e033 gimple_convert(gimple_stmt_iterator*, bool, gsi_iterator_update,
unsigned int, tree_node*, tree_node*)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/gimple-fold.cc:9168
0x10274cf gimple_convert(gimple**, tree_node*, tree_node*)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/gimple-fold.h:183
0x10274cf vectorize_slp_instance_root_stmt(_slp_tree*, _slp_instance*)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/tree-vect-slp.cc:9401
0x10287aa vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/tree-vect-slp.cc:9639
0x102ac51 vect_slp_region
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/tree-vect-slp.cc:7770
0x102c19c vect_slp_bbs
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/tree-vect-slp.cc:7870
0x102c688 vect_slp_function(function*)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/tree-vect-slp.cc:7992
0x1033f59 execute
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/tree-vectorizer.cc:1531
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

My guess is that the segmentation fault is caused by SLP passing a null tree to
gimple_convert.

[Bug rtl-optimization/113017] New: ICE in delete_unmarked_insns, at dce.cc:653

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113017

Bug ID: 113017
   Summary: ICE in delete_unmarked_insns, at dce.cc:653
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, needs-bisection
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: aarch64-gnu-linux

While compiling the GCC testsuite testcase gfortran.dg/inline_matmul_9.f90 with
aarch64 crosscompiler:

aarch64-linux-gnu-gfortran
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/inline_matmul_9.f90
-fharden-control-flow-redundancy -ftrapping-math -Ofast -fnon-call-exceptions

the following ICE occurs:

during RTL pass: sched1
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/inline_matmul_9.f90:22:16:

   22 | end program main
  |^
internal compiler error: in delete_unmarked_insns, at dce.cc:653
0x7a8696 delete_unmarked_insns
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/dce.cc:653
0x19c75f2 fast_dce
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/dce.cc:1180
0x19c7784 rest_of_handle_fast_dce
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/dce.cc:1194
0x19c7784 run_fast_df_dce()
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/dce.cc:1242
0xa09448 df_lr_finalize
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/df-problems.cc:1065
0xa030cd df_analyze_problem(dataflow*, bitmap_head*, int*, int)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/df-core.cc:1190
0xa03163 df_analyze_1
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/df-core.cc:1235
0x1a8b5d8 sched_init()
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/haifa-sched.cc:7344
0x1a916fd haifa_sched_init()
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/haifa-sched.cc:7368
0xdf925c schedule_insns()
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/sched-rgn.cc:3524
0xdf986c schedule_insns()
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/sched-rgn.cc:3518
0xdf986c rest_of_handle_sched
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/sched-rgn.cc:3736
0xdf986c execute
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/sched-rgn.cc:3846
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Compiler configuration:

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/aarch64-linux-gnu-gfortran
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with:
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release
--prefix=/home/worker/cross --target=aarch64-linux-gnu
--with-as=/usr/bin/aarch64-suse-linux-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231213 (experimental)
c535360788e142a92e1d8b1db25bf4452e26f5fb (GCC)

[Bug rtl-optimization/113002] ICE in commit_one_edge_insertion, at cfgrtl.cc:2095 with new -finline-stringops

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113002

Filip Kastl  changed:

   What|Removed |Added

 CC||fkastl at suse dot cz

--- Comment #1 from Filip Kastl  ---
The same error also occurs while compiling gcc.dg/pr43300.c with
aarch64-linux-gnu-gcc:

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/pr43300.c
-finline-stringops -Oz

[Bug target/112916] [14 Regression] ~4-7% exec time regression of 433.milc on AMD Zen2

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112916

--- Comment #2 from Filip Kastl  ---
Sometimes there are gaps in the data our team gathers, unfortunately. One cause
can be that upstream GCC temporarily fails to build a benchmark. That shouldn't
matter in this case I think. The last gap for this benchmark was in September.

[Bug target/112914] [14 Regression] ~7-9% exec time regression of 436.cactusADM on AMD Zen2

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112914

--- Comment #1 from Filip Kastl  ---
The options are -O2 LTO

[Bug target/112915] [14 Regression] 4% exec time regression of 454.calculix on AMD Zen2

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112915

--- Comment #2 from Filip Kastl  ---
The options are -Ofast -march=native -mtune=native LTO and PGO

[Bug target/112916] New: [14 Regression] ~4-7% exec time regression of 433.milc on AMD Zen2

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112916

Bug ID: 112916
   Summary: [14 Regression] ~4-7% exec time regression of 433.milc
on AMD Zen2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Between commits

g:7758cb4b53e8a336

and

g:cff1fa6625d1273f

there's a slowdown of 433.milc 2006 SPEC. 7% regression seen on the graph here
(Zen2 machine):

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=288.70.0

The options are:
-Ofast -march=native -mtune=native LTO and PGO

I've also replicated this on another Zen2 machine and got 4% slowdown. I
haven't seen this slowdown on other architectures.

[Bug target/112915] [14 Regression] 4% exec time regression of 454.calculix on AMD Zen2

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112915

--- Comment #1 from Filip Kastl  ---
I checked again and its actually a 4% regression on both machines, my bad.

[Bug target/112915] New: [14 Regression] ~4-11% exec time regression of 454.calculix on AMD Zen2

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112915

Bug ID: 112915
   Summary: [14 Regression] ~4-11% exec time regression of
454.calculix on AMD Zen2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Between commits

g:cff1fa6625d1273f

and

g:8b9d0e8cf482287b

there's a slowdown of 454.calculix 2006 SPEC. 11% regression seen on the graph
here (Zen2 machine):

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=288.170.0

I've also replicated this on another Zen2 machine and got 4% slowdown. I
haven't seen this slowdown on other architectures.

[Bug target/112914] New: [14 Regression] ~7-9% exec time regression of 436.cactusADM on AMD Zen2

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112914

Bug ID: 112914
   Summary: [14 Regression] ~7-9% exec time regression of
436.cactusADM on AMD Zen2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Between commits

g:73e2bdbf9bed48b2

and

g:c6bb413eeb9d1341

there's a slowdown of 436.cactusADM 2006 SPEC. 9% regression seen on the graph
here (Zen2 machine):

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=292.100.0

I've also replicated this on another Zen2 machine and got 7% slowdown. I
haven't seen this slowdown on other architectures.

[Bug target/112879] New: [14 Regression] 4% exec time regression of 525.x264_r on AMD Zen4

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112879

Bug ID: 112879
   Summary: [14 Regression] 4% exec time regression of 525.x264_r
on AMD Zen4
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

There's a 4% slowdown of 525.x264_r on AMD Zen4 between commits

g:af7fa3135b6b046f

g:e85c596ae2d1e5f5

Here is a plot showing this regression:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=958.377.0

I've seen this regression on two different Zen4 machines but haven't observed
it on machines with different architecture.

[Bug target/112804] New: ICE in aarch64 crosscompiler in plus_constant, at explow.cc:102

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804

Bug ID: 112804
   Summary: ICE in aarch64 crosscompiler in plus_constant, at
explow.cc:102
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: aarch64-gnu-linux

Created attachment 56748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56748=edit
Log of found plus_constant ICEs

While compiling the gcc.dg/tree-ssa/pr111583-2.c testcase from GCC testsuite
using the aarch64 cross compiler with the following options:

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/tree-ssa/pr111583-2.c
-mabi=ilp32 -finline-stringops -ftrivial-auto-var-init=zero

the following ICE occurs:

during RTL pass: expand
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/tree-ssa/pr111583-2.c:
In function ‘m’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/tree-ssa/pr111583-2.c:18:25:
internal compiler error: in plus_constant, at explow.cc:102
   18 |   const unsigned short *n[65];
  | ^
0x73fa6c plus_constant(machine_mode, rtx_def*, poly_int<2u, long>, bool)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/explow.cc:102
0x89f52f try_store_by_multiple_pieces(rtx_def*, rtx_def*, unsigned int,
unsigned long, unsigned long, rtx_def*, char, unsigned int)
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/builtins.cc:4517
0x9d8870 clear_storage_hints(rtx_def*, rtx_def*, block_op_methods, unsigned
int, long, unsigned long, unsigned long, unsigned long, unsigned int)
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/expr.cc:3888
0x8a619b expand_builtin_memset_args
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/builtins.cc:4674
0xac23f7 expand_DEFERRED_INIT
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/internal-fn.cc:3357
0x8c6a37 expand_call_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/cfgexpand.cc:2738
0x8c6a37 expand_gimple_stmt_1
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/cfgexpand.cc:3881
0x8c6a37 expand_gimple_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/cfgexpand.cc:4045
0x8cbac7 expand_gimple_basic_block
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/cfgexpand.cc:6101
0x8cd7be execute
   
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/gcc/cfgexpand.cc:6836
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


The same bug (the same stacktrace) occurs on these testcases:

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/aarch64/mops_4.c
-mabi=ilp32 -finline-stringops

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/pr34457-1.c
-mabi=ilp32 -finline-stringops

aarch64-linux-gnu-gfortran
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/pr49308.f90
-finline-stringops -mabi=ilp32

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/ubsan/bounds-4b.c
-finline-stringops -mabi=ilp32 -Os

aarch64-linux-gnu-gfortran
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/analyzer/deferred_character_25.f90
-mabi=ilp32 -finline-stringops


ICE in plus_constant (similar, but different stacktrace) also occurs here:

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/aarch64/test_frame_5.c
-mabi=ilp32 -ftrivial-auto-var-init=pattern -finline-stringops

aarch64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.target/aarch64/stack-check-prologue-15.c
-ftrivial-auto-var-init=pattern -mabi=ilp32 -finline-stringops

aarch64-linux-gnu-g++
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/g++.dg/vect/pr84362.cc
-ftrivial-auto-var-init=pattern -mabi=ilp32 -finline-stringops


There are many more testcases that currently produce an ICE in plus_constant.
I'm attaching a full log of the ICEs.


Configuration of the compiler:

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with:
/home/worker/buildworker/tiber-gcc-trunk-aarch64/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib 

[Bug target/112778] New: [14 Regression] ICE in ppc64-linux-gnu crosscompiler in store_by_pieces, at expr.cc:1820

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112778

Bug ID: 112778
   Summary: [14 Regression] ICE in ppc64-linux-gnu crosscompiler
in store_by_pieces, at expr.cc:1820
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: ppc64-linux-gnu

Compiling the gcc.dg/strlenopt-5.c GCC testsuite testcase with ppc64-linux-gnu
as target like this:

ppc64-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/strlenopt-5.c
-finline-stringops

results in and ICE:

during RTL pass: expand
../src/gcc/testsuite/gcc.dg/strlenopt-5.c: In function ‘main’:
../src/gcc/testsuite/gcc.dg/strlenopt-5.c:35:3: internal compiler error: in
store_by_pieces, at expr.cc:1820
   35 |   memset (buf, 'v', 3);
  |   ^~~~
0x644072 store_by_pieces(rtx_def*, unsigned long, rtx_def* (*)(void*, void*,
long, fixed_size_mode), void*, unsigned int, bool, memop_ret)
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/expr.cc:1820
0x7a1197 try_store_by_multiple_pieces(rtx_def*, rtx_def*, unsigned int,
unsigned long, unsigned long, rtx_def*, char, unsigned int)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/builtins.cc:4456
0x7a7f63 expand_builtin_memset_args
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/builtins.cc:4661
0x7aa174 expand_builtin_memset(tree_node*, rtx_def*, machine_mode)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/builtins.cc:4279
0x7aa174 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/builtins.cc:7834
0x8cbd08 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/expr.cc:12304
0x7c8366 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/expr.h:313
0x7c8366 expand_call_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/cfgexpand.cc:2832
0x7c8366 expand_gimple_stmt_1
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/cfgexpand.cc:3881
0x7c8366 expand_gimple_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/cfgexpand.cc:4045
0x7ccd07 expand_gimple_basic_block
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/cfgexpand.cc:6101
0x7ce9fe execute
   
/home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/cfgexpand.cc:6836
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


The same error (even the same stacktrace) also occurs with

ppc64-linux-gnu-gfortran
/home/worker/llvm/src/flang/test/Lower/HLFIR/function-return.f90
-finline-stringops

ppc64-linux-gnu-gfortran
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/implied_do_io_4.f90
-Os -finline-stringops

ppc64-linux-gnu-gfortran
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/gomp/defaultmap-5.f90
-finline-stringops

ppc64-linux-gnu-gfortran
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/verify_2.f90
-finline-stringops


Compiler configuration:

Using built-in specs.
COLLECT_GCC=/home/worker/cross/bin/ppc64-linux-gnu-gfortran
COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/ppc64-linux-gnu/14.0.0/lto-wrapper
Target: ppc64-linux-gnu
Configured with: /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release
--prefix=/home/worker/cross --target=ppc64-linux-gnu
--with-as=/usr/bin/powerpc64-suse-linux-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231130 (experimental)
31d8cf17ca4537e35bc7507ff1d9dfce077c0c68 (GCC)

[Bug target/112762] New: Cannot build crosscompilers for some uclinux targets

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112762

Bug ID: 112762
   Summary: Cannot build crosscompilers for some uclinux targets
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: *-uclinux

While building the current upstream GCC configured with --target=bfin-uclinux,
--target=c6x-uclinux, --target=lm32-uclinux or --target=moxie-uclinux, the
build fails. The respective errors look almost the same. I list them at the end
of this report.


Configuration of the GCC I'm building:
../src/configure --prefix=/home/fkastl/gcc/inst --enable-languages=c,c++
--enable-checking --disable-bootstrap --disable-multilib --enable-obsolete
--target= OR bfin-uclinux OR c6x-uclinux OR lm32-uclinux OR moxie-uclinux}

Configuration of system GCC:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go
--enable-offload-targets=hsa,nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
--enable-gnu-indirect-function --program-suffix=-7 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 7.5.0 (SUSE Linux)


List of the respective error messages:

bfin-uclinux

g++  -fno-PIE -c   -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-fno-PIE -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include 
-I../../src/gcc/../libcpp/include -I../../src/gcc/../libcody 
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o bfin.o -MT bfin.o -MMD
-MP -MF ./.deps/bfin.TPo ../../src/gcc/config/bfin/bfin.cc
In file included from ../../src/gcc/config/bfin/bfin.cc:28:0:
../../src/gcc/rtl.h:66:26: warning: ‘rtx_def::code’ is too small to hold all
values of ‘enum rtx_code’
 #define RTX_CODE_BITSIZE 8
  ^
../../src/gcc/rtl.h:318:33: note: in expansion of macro ‘RTX_CODE_BITSIZE’
   ENUM_BITFIELD(rtx_code) code: RTX_CODE_BITSIZE;
 ^~~~
In file included from ./tm.h:31:0,
 from ../../src/gcc/backend.h:28,
 from ../../src/gcc/config/bfin/bfin.cc:26:
../../src/gcc/config/linux.h:221:45: error:
‘linux_fortify_source_default_level’ was not declared in this scope
 #define TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL linux_fortify_source_default_level
 ^
../../src/gcc/config/linux.h:221:45: note: in definition of macro
‘TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL’
 #define TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL linux_fortify_source_default_level
 ^~
../../src/gcc/config/bfin/bfin.cc:5885:29: note: in expansion of macro
‘TARGET_INITIALIZER’
 struct gcc_target targetm = TARGET_INITIALIZER;
 ^~
../../src/gcc/config/linux.h:221:45: note: suggested alternative:
‘default_fortify_source_default_level’
 #define TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL linux_fortify_source_default_level
 ^
../../src/gcc/config/linux.h:221:45: note: in definition of macro
‘TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL’
 #define TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL linux_fortify_source_default_level
 ^~
../../src/gcc/config/bfin/bfin.cc:5885:29: note: in expansion of macro
‘TARGET_INITIALIZER’
 struct gcc_target targetm = TARGET_INITIALIZER;
 ^~
make[1]: *** [Makefile:2531: bfin.o] Error 1
make[1]: Leaving directory '/home/fkastl/gcc/build/gcc'
make: *** [Makefile:4650: all-gcc] Error 2

[Bug middle-end/112697] [14 Regression] 30-40% exec time regression of 433.milc on zen2

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697

--- Comment #1 from Filip Kastl  ---
Around the same time there was also a 6% slowdown with
-Ofast -march=native -g and PGO
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=299.70.0

and an 11% slowdown with
-O2 -g -flto=128 and PGO
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=685.70.0

[Bug middle-end/112697] New: [14 Regression] 30-40% exec time regression of 433.milc on zen2

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697

Bug ID: 112697
   Summary: [14 Regression] 30-40% exec time regression of
433.milc on zen2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization, needs-bisection
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Between commits

g:0c305f3dec9a992dd775a3b9607b7b1e8c051859
g:7f974c5fd4f59a9d8dd20c49a0e2909cb290f4b4

there's a 30-40% slowdown of the 433.milc 2006SPEC benchmark as seen here:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=292.70.0

It's 40% here and I also measured the slowdown on another zen2 machine where
the difference was 30%.

Compile options:

-g -O2 -flto=128

[Bug tree-optimization/112678] New: Massive slowdown of compilation time with PGO

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678

Bug ID: 112678
   Summary: Massive slowdown of compilation time with PGO
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---

Between g:37183018134049a7 and g:af7fa3135b6b046f there is a big increase of
compilation time when compiling with profile guided optimization. Happens on
both O2 and Ofast with lto both disabled or enabled on x86_64 machines and
aarch64 machine. 

Some plots that show this:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=474.110.8 (380%
slowdown)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=589.337.8 (700%
slowdown)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=286.407.8 (660%
slowdown)

All plots show compilation times of SPEC benchmarks.

[Bug target/112677] New: ASAN reports stack-buffer-overflow in tree-vect-loop.cc vect_is_simple_use when compiling with -mavx512

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112677

Bug ID: 112677
   Summary: ASAN reports stack-buffer-overflow in
tree-vect-loop.cc vect_is_simple_use when compiling
with -mavx512
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Created attachment 56670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56670=edit
A list of testcases triggering this error

On many testcases from the GCC testsuite an ASAN-instrumented GCC reports
stack-buffer-overflow error in vect_is_simple_use at tree-vect-loop.cc:13584
file. All of the errors happen when compiling with some kind of -mavx512 option
or with -march=skylake-avx512.

I'm attaching a list of testcases that trigger this error.

Compiler configured with:

--enable-languages=default,jit,lto,go,d --enable-host-shared
--enable-checking=release --disable-multilib --with-build-config=bootstrap-asan


One example of a testcase where this error occurs is g++.dg/opt/pr112374.C.
Running

gcc src/gcc/testsuite/g++.dg/opt/pr112374.C  -O2 -march=skylake-avx512

results in

==46365==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7f41ef71c6f8 at pc 0x0562f3ab bp 0x7ffee76484d0 sp 0x7ffee76484c8
WRITE of size 8 at 0x7f41ef71c6f8 thread T0
#0 0x562f3aa in vect_is_simple_use(tree_node*, vec_info*, vect_def_type*,
tree_node**, _stmt_vec_info**, gimple**)
/home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-stmts.cc:13584
#1 0x2c708ad in vectorizable_reduction(_loop_vec_info*, _stmt_vec_info*,
_slp_tree*, _slp_instance*, vec*)
/home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:7632
#2 0x2c971b5 in vect_analyze_loop_operations
/home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:2149
#3 0x2c971b5 in vect_analyze_loop_2
/home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:3011
#4 0x2c9dc43 in vect_analyze_loop_1
/home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:3450
#5 0x2ca037e in vect_analyze_loop(loop*, vec_info_shared*)
/home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:3604
#6 0x2d9f495 in try_vectorize_loop_1
/home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vectorizer.cc:1066
#7 0x2da0cd9 in execute
/home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vectorizer.cc:1298
#8 0x1f4a262 in execute_one_pass(opt_pass*)
/home/worker/buildworker/tiber-gcc-asan/build/gcc/passes.cc:2641
#9 0x1f4bb8c in execute_pass_list_1
/home/worker/buildworker/tiber-gcc-asan/build/gcc/passes.cc:2750
#10 0x1f4bbb2 in execute_pass_list_1
/home/worker/buildworker/tiber-gcc-asan/build/gcc/passes.cc:2751
#11 0x1f4bbb2 in execute_pass_list_1
/home/worker/buildworker/tiber-gcc-asan/build/gcc/passes.cc:2751
#12 0x1f4bc25 in execute_pass_list(function*, opt_pass*)
/home/worker/buildworker/tiber-gcc-asan/build/gcc/passes.cc:2761
#13 0x130a814 in cgraph_node::expand()
/home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:1841
#14 0x130a814 in cgraph_node::expand()
/home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:1794
#15 0x131004d in expand_all_functions
/home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:2024
#16 0x131004d in symbol_table::compile()
/home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:2398
#17 0x131004d in symbol_table::compile()
/home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:2309
#18 0x1316999 in symbol_table::finalize_compilation_unit()
/home/worker/buildworker/tiber-gcc-asan/build/gcc/cgraphunit.cc:2583
#19 0x23492cf in compile_file
/home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:473
#20 0x7e26dd in do_compile
/home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:2129
#21 0x7e26dd in toplev::main(int, char**)
/home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:2285
#22 0x7ed873 in main
/home/worker/buildworker/tiber-gcc-asan/build/gcc/main.cc:39
#23 0x7f41f10281af in __libc_start_call_main (/lib64/libc.so.6+0x281af)
(BuildId: bbeee08e5f56966e641c4f3ba4ea1da9d730d0ab)
#24 0x7f41f1028278 in __libc_start_main@@GLIBC_2.34
(/lib64/libc.so.6+0x28278) (BuildId: bbeee08e5f56966e641c4f3ba4ea1da9d730d0ab)
#25 0x7ef1d4 in _start ../sysdeps/x86_64/start.S:115

Address 0x7f41ef71c6f8 is located in stack of thread T0 at offset 1784 in frame
#0 0x2c6e69f in vectorizable_reduction(_loop_vec_info*, _stmt_vec_info*,
_slp_tree*, _slp_instance*, vec*)
/home/worker/buildworker/tiber-gcc-asan/build/gcc/tree-vect-loop.cc:7385

  This frame has 145 object(s):
[48, 50) ''
[64, 66) ''
[80, 84) 'dt' (line 7631)

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 112547, which changed state.

Bug 112547 Summary: 9% exec time regression of 462.libquantum SPEC on AMD zen4 
CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

[Bug target/112547] 9% exec time regression of 462.libquantum SPEC on AMD zen4 CPU

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547

Filip Kastl  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #9 from Filip Kastl  ---
Setting status to RESOLVED WORKSFORME

[Bug middle-end/112668] New: ICE in bitintlower0 while compiling bitint-42.c

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112668

Bug ID: 112668
   Summary: ICE in bitintlower0 while compiling bitint-42.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Compiling the bitint-42.c file from testsuite:

gcc -fnon-call-exceptions src/gcc/testsuite/gcc.dg/torture/bitint-42.c

results in:

during GIMPLE pass: bitintlower0   
/home/fkastl/gcc/src/gcc/testsuite/gcc.dg/torture/bitint-42.c: In function
‘main’:   
/home/fkastl/gcc/src/gcc/testsuite/gcc.dg/torture/bitint-42.c:50:1: internal
compiler error: Segmentation fault   
   50 | main ()   
  | ^~~~   
0x100d5bf crash_signal   
../../src/gcc/toplev.cc:316
0x10d607e add_phi_arg(gphi*, tree_node*, edge_def*, unsigned int)   
../../src/gcc/tree-phinodes.cc:358
0x1e22438 prepare_data_in_out   
../../src/gcc/gimple-lower-bitint.cc:1036
0x1e323c6 handle_load   
../../src/gcc/gimple-lower-bitint.cc:1695
0x1e323c6 handle_stmt   
../../src/gcc/gimple-lower-bitint.cc:1876
0x1e33bc4 lower_mergeable_stmt   
../../src/gcc/gimple-lower-bitint.cc:2406
0x1e3811d lower_stmt   
../../src/gcc/gimple-lower-bitint.cc:5216
0x1e39dbd gimple_lower_bitint   
../../src/gcc/gimple-lower-bitint.cc:6296
Please submit a full bug report, with preprocessed source.   
Please include the complete backtrace with any bug report.   
See  for instructions.

Compiler configuration (nothing non-standard):

Target: x86_64-pc-linux-gnu   
Configured with: ../src/configure --enable-checking --disable-bootstrap
--disable-libsanitizer : (reconfigured) ../src/configure --enable-checking
--disable-bootstrap --disable-libsanitizer : (reconfigured) ../src/configure
--enable-checking --disable-bootstrap --disable-libsanitizer
--enable-languages=c,c++,fortran,lto,objc --no-create --no-recursion   
Thread model: posix   
Supported LTO compression algorithms: zlib zstd   
gcc version 14.0.0 20231122 (experimental) (GCC)

[Bug target/112547] 9% exec time regression of 462.libquantum SPEC on AMD zen4 CPU

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547

--- Comment #8 from Filip Kastl  ---
I've just ran the test on another zen4 machine. Between the originally
mentioned commits g:53010f6ff6dfbf7b and g:1a55724f7870719d there was only 1%
slowdown on this other machine. I guess this means that the 9% slowdown is
specific to the machine where we measure the data I sent.

Since there seems to be no reason why there should be a general zen4 slowdown
between the two commits and if there are no objections, I'll mark this bug as
RESOLVED WORKSFORME.

[Bug target/112547] 9% exec time regression of 462.libquantum SPEC on AMD zen4 CPU

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547

--- Comment #5 from Filip Kastl  ---
Compile options are:
-O2 -g -flto=128

Configure options of GCC are:
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release

[Bug other/112549] New: 9% exec time regression of 436.cactusADM on Aarch64

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112549

Bug ID: 112549
   Summary: 9% exec time regression of 436.cactusADM on Aarch64
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: aarch64
Target: aarch64

As seen here:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=575.100.0

there's about 9% slowdown between

g:ada871cfadd3f496 (2023-11-04 08:31)

and

g:fd1596f9962569af (2023-11-14 01:27)

when running spec2006 436.cactusADM compiled with -Ofast. The test was run on
an Aarch64 machine (-march=armv8.2-a+crypto+fp16+rcpc+dotprod+ssbs).

[Bug target/112548] New: 5% exec time regression in 429.mcf on AMD zen4 CPU

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548

Bug ID: 112548
   Summary: 5% exec time regression in 429.mcf on AMD zen4 CPU
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

As seen here:

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=991.60.0

between commits

g:4ea36076d66eea0f (2023-11-02 02:54)

and

g:c3847ca0571e5ace (2023-11-03 03:35)

there's about 5% slowdown.

The test is compiled with -Ofast -march=native -mtune=native lto and pgo. It is
run on an amd zen4 machine.

[Bug target/112547] New: 9% exec time regression of 462.libquantum SPEC on AMD zen4 CPU

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547

Bug ID: 112547
   Summary: 9% exec time regression of 462.libquantum SPEC on AMD
zen4 CPU
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

As seen here

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=956.210.0

between commits

g:53010f6ff6dfbf7b (2023-11-05 02:42)

and

g:1a55724f7870719d (2023-11-06 02:27)

there is about 9% slowdown of execution time of the 2006SPEC 462.libquantum.

The test is run with -O2 and lto on an amd zen4 machine.

[Bug tree-optimization/110302] libquantum regression on zen3 with LTO and PGO

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110302

Filip Kastl  changed:

   What|Removed |Added

 CC||fkastl at suse dot cz

--- Comment #1 from Filip Kastl  ---
Seems like the regression was resolved. From commit g:95b712928b479f7a on, the
test is back to its original values.

[Bug target/112336] New: ICE in gen_reg_rtx emit-rtl.cc:1208 while compiling "unsigned _BitInt(1) Foo;" with -fsanitize=address

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112336

Bug ID: 112336
   Summary: ICE in gen_reg_rtx emit-rtl.cc:1208 while compiling
"unsigned _BitInt(1) Foo;" with -fsanitize=address
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Compiling a file with a single line (a reduced ext-int.c from llvm testsuite):

--- ice.c ---
unsigned _BitInt(1) GlobSize1;
---

with -fsanitize=address:

gcc -fsanitize=address ice.c

results in an ICE:

ice.c:1:1: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1208
1 | unsigned _BitInt(1) GlobSize1;
  | ^~~~
0x77249b gen_reg_rtx(machine_mode)
../../src/gcc/emit-rtl.cc:1208
0xe94b89 maybe_legitimize_operand
../../src/gcc/optabs.cc:8044
0xe94b89 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
../../src/gcc/optabs.cc:8199
0xe90ee9 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../src/gcc/optabs.cc:8218
0xe99c0c expand_binop_directly
../../src/gcc/optabs.cc:1457
0xe97b29 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
../../src/gcc/optabs.cc:1544
0xbde1c0 expand_and(machine_mode, rtx_def*, rtx_def*, rtx_def*)
../../src/gcc/expmed.cc:5483
0xbf8544 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.cc:11005
0xc01fce expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../src/gcc/expr.h:310
0xc01fce expand_expr_addr_expr_1
../../src/gcc/expr.cc:8728
0xc02639 expand_expr_addr_expr
../../src/gcc/expr.cc:8849
0xbf7894 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../src/gcc/expr.cc:12163
0x1370de3 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../src/gcc/expr.h:310
0x1370de3 output_constant
../../src/gcc/varasm.cc:5261
0x136fee8 output_constructor_regular_field
../../src/gcc/varasm.cc:5612
0x136fee8 output_constructor
../../src/gcc/varasm.cc:5878
0x136fee8 output_constructor_regular_field
../../src/gcc/varasm.cc:5612
0x136fee8 output_constructor
../../src/gcc/varasm.cc:5878
0x1371df5 assemble_variable_contents
../../src/gcc/varasm.cc:2231
0x1376f8d assemble_variable(tree_node*, int, int, int)
../../src/gcc/varasm.cc:2410

[Bug target/112334] New: ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334

Bug ID: 112334
   Summary: ICE in gen_untyped_return arm.md:9197 while compiling
harden-cfr-bret.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: arm-linux-gnueabi

Compiling the harden-cfr-bret-never.c  file from testsuite

arm-linux-gnueabi-gcc testsuite/c-c++-common/torture/harden-cfr-bret-never.c
-mflip-thumb

results in an ICE

during RTL pass: expand
In file included from
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/c-c++-common/torture/harden-cfr-bret-never.c:8:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/c-c++-common/torture/harden-cfr-bret.c:
In function ‘g’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/c-c++-common/torture/harden-cfr-bret.c:11:3:
internal compiler error: Segmentation fault
   11 |   __builtin_return ();
  |   ^
0xc7585f crash_signal
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/toplev.cc:315
0x132d068 gen_untyped_return(rtx_def*, rtx_def*)
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/config/arm/arm.md:9197
0xfa6e85 target_gen_untyped_return
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/config/arm/arm.md:9140
0x7c6053 expand_builtin_return
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/builtins.cc:1805
0x7d7acc expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/builtins.cc:7550
0x8f673d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/expr.cc:11932
0x7f41e6 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/expr.h:310
0x7f41e6 expand_call_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/cfgexpand.cc:2831
0x7f41e6 expand_gimple_stmt_1
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/cfgexpand.cc:3880
0x7f41e6 expand_gimple_stmt
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/cfgexpand.cc:4044
0x7f8e07 expand_gimple_basic_block
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/cfgexpand.cc:6100
0x7fab0e execute
   
/home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/cfgexpand.cc:6835

[Bug target/111772] ICE on gfortran.dg/transpose_conjg_1.f90 in regrename.cc

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111772

Filip Kastl  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Filip Kastl  ---
Ran on my machine again. Confirmed that the bug no longer occurs. Marking as
fixed.

[Bug middle-end/111875] With -Og ubsan check inserted even though __builtin_assume_aligned guarantees no UB

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111875

--- Comment #1 from Filip Kastl  ---
I found out that this is caused by the copy_prop pass. With -Og, an instance of
copy_prop runs after the fold_builtins pass but before the sanopt pass. The
fold_builtins pass changes the statement p_2 = __builtin_assume_aligned(p_1, 4)
to p_2 = p_1; and changes the alignment of p_2 to 32 bits. However the
alignment of p_1 remains 8 bits so when copy_prop propagates all occurences of
p_2 to instead be occurences of p_1, the information about alignment is lost.
When the sanopt pass runs, it decides that casting p to (int *) possibly
creates UB.

I see a few possible solutions:
- Stop copy prop from propagating through assignments where the alignments
differ
- Modify copy prop to use the alignment information of the lhs ssa name when
propagating through similar assignment statements
- Modify fold_builtins to copy propagate in similar cases
- Modify fold_builtins to also set alignment of the rhs ssa name when removing
__builtin_assume_aligned in similar cases

[Bug middle-end/111875] New: With -Og ubsan check inserted even though __builtin_assume_aligned guarantees no UB

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111875

Bug ID: 111875
   Summary: With -Og ubsan check inserted even though
__builtin_assume_aligned guarantees no UB
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Running

gcc -S -Og -fno-sanitize=null -fsanitize=alignment
gcc/testsuite/c-c++-common/ubsan/align-5.c

produces code with an alignment undefined behavior check.

This is how the testcase looks like:

/* { dg-do compile } */
/* { dg-options "-fno-sanitize=null -fsanitize=alignment -O2" } */
/* Check that when optimizing if we know the alignment is right
   and we are not doing -fsanitize=null instrumentation we don't
   instrument the alignment check.  */

__attribute__((noinline, noclone)) int 
foo (char *p) 
{
  p = (char *) __builtin_assume_aligned (p, __alignof__(int));
  int *q = (int *) p;
  return *q; 
}

/* { dg-final { scan-assembler-not "__ubsan_handle" } } */

Because of __builtin_assume_aligned, the compiler should assume that p will
always have the correct alignment to be cast to int *.

The compiler produces this (with -Og):

.file   "align-5.c"
.text
.globl  foo 
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16 
movq%rdi, %rbx
testb   $3, %dil
jne .L4 
.L2:
movl(%rbx), %eax
popq%rbx
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.L4:
.cfi_restore_state
movq%rdi, %rsi
movl$.Lubsan_data0, %edi
call__ubsan_handle_type_mismatch_v1
jmp .L2 
.cfi_endproc
.LFE0:
.size   foo, .-foo
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "align-5.c"
.data
.align 32
.type   .Lubsan_data0, @object
.size   .Lubsan_data0, 32
.Lubsan_data0:
.quad   .LC0
.long   12  
.long   10  
.quad   .Lubsan_type0
.byte   2   
.byte   0   
.zero   6   
.align 2
.type   .Lubsan_type0, @object
.size   .Lubsan_type0, 10
.Lubsan_type0:
.value  -1  
.value  0
.string "'int'"
.ident  "GCC: (GNU) 14.0.0 20231012 (experimental)"
.section.note.GNU-stack,"",@progbits

With -O2 the compiler behaves correctly and produces this:

.file   "align-5.c"
.text
.p2align 4
.globl  foo 
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movl(%rdi), %eax
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 14.0.0 20231012 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug rtl-optimization/111772] New: ICE on gfortran.dg/transpose_conjg_1.f90 in regrename.cc

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111772

Bug ID: 111772
   Summary: ICE on gfortran.dg/transpose_conjg_1.f90 in
regrename.cc
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Running

gfortran src/gcc/testsuite/gfortran.dg/transpose_conjg_1.f90 -fno-tree-ter
-funroll-loops -flive-range-shrinkage --param=max-combine-insns=2
-frounding-math -mavx512bw -O1 -fharden-conditional-branches

fails with

/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/transpose_conjg_1.f90:37:17:

   37 |  END program main
  | ^
Error: insn does not satisfy its constraints:
(insn 1129 257 258 20 (set (reg:SF 57 xmm21 [761])
(const_double:SF 0.0 [0x0.0p+0]))
"/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/transpose_conjg_1.f90":26:56
discrim 11 160 {*movsf_internal}
 (expr_list:REG_EQUAL (const_double:SF 0.0 [0x0.0p+0])
(nil)))
during RTL pass: rnreg
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/transpose_conjg_1.f90:37:17:
internal compiler error: in extract_constrain_insn, at recog.cc:2692
0x7e05f2 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.cc:108
0x7e0618 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.cc:118
0x7dec5f extract_constrain_insn(rtx_insn*)
../../src/gcc/recog.cc:2692
0xfb64fc build_def_use
../../src/gcc/regrename.cc:1700
0xfb64fc regrename_analyze(bitmap_head*, bool)
../../src/gcc/regrename.cc:772
0xfb7539 regrename_optimize
../../src/gcc/regrename.cc:1983
0xfb7539 execute
../../src/gcc/regrename.cc:2022

gfortran -v output:

Using built-in specs.
COLLECT_GCC=../build/gcc/gfortran
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure --disable-multilib --disable-libsanitizer
--enable-languages=c,c++,fortran --enable-checking --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231011 (experimental) (GCC)

[Bug other/111692] New: ICE in output_constant at varasm:cc:5267 during RTL "final" pass

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111692

Bug ID: 111692
   Summary: ICE in output_constant at varasm:cc:5267 during RTL
"final" pass
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: jamborm at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Running gcc on a test from the testsuite with -Os and -frounding-math:

gcc src/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c -Os
-frounding-math

results in an ICE

during RTL pass: final
../src/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c: In
function ‘avx512f_test’:
../src/gcc/testsuite/gcc.target/x86_64/abi/avx512f/test_passing_structs.c:65:1:
internal compiler error: in output_constant, at varasm.cc:5267
   65 | }
  | ^
0x867e58 output_constant
../../src/gcc/varasm.cc:5267
0x1317655 output_constructor_regular_field
../../src/gcc/varasm.cc:5610
0x1317655 output_constructor
../../src/gcc/varasm.cc:5876
0x1317655 output_constructor_regular_field
../../src/gcc/varasm.cc:5610
0x1317655 output_constructor
../../src/gcc/varasm.cc:5876
0x13190e5 assemble_constant_contents
../../src/gcc/varasm.cc:3621
0x131a3f8 output_constant_def_contents
../../src/gcc/varasm.cc:3666
0x131a67c mark_constants_in_pattern
../../src/gcc/varasm.cc:4241
0x131ef07 mark_constants
../../src/gcc/varasm.cc:4273
0x131ef07 mark_constant_pool
../../src/gcc/varasm.cc:4289
0x131ef07 output_constant_pool
../../src/gcc/varasm.cc:4504
0x131ef07 assemble_start_function(tree_node*, char const*)
../../src/gcc/varasm.cc:1876
0xbfdaa1 rest_of_handle_final
../../src/gcc/final.cc:4236
0xbfdaa1 execute
../../src/gcc/final.cc:4318

This assert fails:

5265  
5266 case REAL_TYPE:
5267   gcc_assert (size == thissize);
5268   if (TREE_CODE (exp) != REAL_CST)
5269 error ("initializer for floating value is not a floating
constant");

[Bug target/111616] On Zen2 7% 519.lbm_r regression between g:1d17d58c284fa8c3 (2023-09-14 02:39) and g:c8e9a75085f9725c (2023-09-18 13:09)

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111616

Filip Kastl  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Filip Kastl  ---
I'm not sure which commit fixed the slowdown but it is now gone. 519.lbm_r
performance is back to where it was at g:1d17d58c284fa8c3.

Marking as fixed.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 111616, which changed state.

Bug 111616 Summary: On Zen2 7% 519.lbm_r regression between g:1d17d58c284fa8c3 
(2023-09-14 02:39) and g:c8e9a75085f9725c (2023-09-18 13:09)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111616

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/111637] New: ICE while building gcc.dg/bitint-8.c with -fsanitize=signed-integer-overflow

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111637

Bug ID: 111637
   Summary: ICE while building gcc.dg/bitint-8.c with
-fsanitize=signed-integer-overflow
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: jakub at gcc dot gnu.org, jamborm at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Compiling the bitint-8.c testsuite file with optimizations enabled and
-fsanitize=signed-integer-overflow results in an ICE

gcc $GCC_SRC_DIR/gcc/testsuite/gcc.dg/bitint-8.c -O1
-fsanitize=signed-integer-overflow

during GIMPLE pass: bitintlower
bitint-8.c: In function ‘foo’:
bitint-8.c:7:1: internal compiler error: in lower_bound, at value-range.h:1078
7 | foo (void)
  | ^~~
0x8c59fe irange::lower_bound(unsigned int) const
../../src/gcc/value-range.h:1078
0x8c59fe range_to_prec
../../src/gcc/gimple-lower-bitint.cc:1945
0x1cd0645 lower_addsub_overflow
../../src/gcc/gimple-lower-bitint.cc:3768
0x1cd27f3 lower_call
../../src/gcc/gimple-lower-bitint.cc:4469
0x1cd9a4a lower_stmt
../../src/gcc/gimple-lower-bitint.cc:4673
0x1cda8cd gimple_lower_bitint
../../src/gcc/gimple-lower-bitint.cc:5765

[Bug target/111616] New: On Zen2 7% 519.lbm_r regression between g:1d17d58c284fa8c3 (2023-09-14 02:39) and g:c8e9a75085f9725c (2023-09-18 13:09)

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111616

Bug ID: 111616
   Summary: On Zen2 7% 519.lbm_r regression between
g:1d17d58c284fa8c3 (2023-09-14 02:39) and
g:c8e9a75085f9725c (2023-09-18 13:09)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: mjambor at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

On x86_64 AMD Zen2 machine with Ofast LTO PGO march=native mtune=native between
commits g:1d17d58c284fa8c3 (2023-09-14 02:39) and g:c8e9a75085f9725c
(2023-09-18 13:09) there is a 519.lbm_r 7% execution time regression.

Here is a plot of recent measurements:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=286.477.0

I confirmed this on another Zen2 machine. This time I measured 9% slowdown.

[Bug target/111370] New: On Aarch64 4% 511.povray_r regression between g:6cd85273071b5f13 (2023-08-23 00:17) and g:e1f096a3cc96c719 (2023-08-25 22:34)

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111370

Bug ID: 111370
   Summary: On Aarch64 4% 511.povray_r regression between
g:6cd85273071b5f13 (2023-08-23 00:17) and
g:e1f096a3cc96c719 (2023-08-25 22:34)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: mjambor at suse dot cz, tamar.christina at arm dot com
  Target Milestone: ---
  Host: aarch64-gnu-linux
Target: aarch64-gnu-linux

On an Altra Aarch64 (-march=armv8.2-a+crypto+fp16+rcpc+dotprod+ssbs) machine
with -O2 -flto generic march between commits g:6cd85273071b5f13 (2023-08-23
00:17) and g:e1f096a3cc96c719 (2023-08-25 22:34) there is a 4% execution time
regression.

Here is a plot of recent runs:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=581.467.0

[Bug middle-end/111369] New: ICE in handle_cast, gimple-lower-bitint.cc:1486 with -Os

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111369

Bug ID: 111369
   Summary: ICE in handle_cast, gimple-lower-bitint.cc:1486 with
-Os
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: jakub at redhat dot com, mjambor at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

Compiling gcc/testsuite/gcc.dg/torture/bitint-42.c with -Os produces this
error:

../gcc/gcc/testsuite/gcc.dg/torture/bitint-42.c: In function ‘main’:
../gcc/gcc/testsuite/gcc.dg/torture/bitint-42.c:50:1: internal compiler error:
in handle_cast, at gimple-lower-bitint.cc:1486
   50 | main ()
  | ^~~~
0x8cfc31 handle_cast
../../gcc/gcc/gimple-lower-bitint.cc:1486
0x1daafe8 handle_operand
../../gcc/gcc/gimple-lower-bitint.cc:791
0x1db31f0 lower_mergeable_stmt
../../gcc/gcc/gimple-lower-bitint.cc:2386
0x1db4c5d lower_stmt
../../gcc/gcc/gimple-lower-bitint.cc:4687
0x1db68fd gimple_lower_bitint
../../gcc/gcc/gimple-lower-bitint.cc:5767
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

An assert fails at the line 1486:

1478   else if (TREE_CODE (lhs_type) == BITINT_TYPE
1479&& bitint_precision_kind (lhs_type) >= bitint_prec_large
1480&& INTEGRAL_TYPE_P (rhs_type))
1481 {
1482   /* Add support for 3 or more limbs filled in from normal integral
1483  type if this assert fails.  If no target chooses limb mode
smaller
1484  than half of largest supported normal integral type, this will
not
1485  be needed.  */
1486   gcc_assert (TYPE_PRECISION (rhs_type) <= 2 * limb_prec);
1487   tree r1 = NULL_TREE, r2 = NULL_TREE, rext = NULL_TREE;
1488   if (m_first)   
1489 {

[Bug fortran/111291] New: ASAN error: heap-use-after-free gcc/fortran/parse.cc:359 in decode_statement

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291

Bug ID: 111291
   Summary: ASAN error: heap-use-after-free
gcc/fortran/parse.cc:359 in decode_statement
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: mjambor at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

With an ASAN-instrumented GCC

configure --enable-languages=default,jit,lto,go,d --enable-host-shared
--enable-checking=release --disable-multilib --with-build-config=bootstrap-asan

running

make check-fortran RUNTESTFLAGS="dg.exp=unexpected_interface.f90 -v"

produces

==6474==ERROR: AddressSanitizer: heap-use-after-free on address 0x51302ab8
at pc 0x00ad968d bp 0x7ffd08212000 sp 0x7ffd08211ff8
READ of size 8 at 0x51302ab8 thread T0
#0 0xad968c in decode_statement
/home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:359
#1 0xae3df4 in next_free
/home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:1592
#2 0xae3df4 in next_statement
/home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:1824
#3 0xae832f in parse_interface
/home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:3991
#4 0xae832f in parse_spec
/home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:4350
#5 0xaef85c in parse_progunit
/home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:6576
#6 0xaf12cc in gfc_parse_file()
/home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:7162
#7 0xbec011 in gfc_be_parse_file
/home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/f95-lang.cc:229
#8 0x1fd637f in compile_file
/home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:444
#9 0x7a7df3 in do_compile
/home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:2126
#10 0x7a7df3 in toplev::main(int, char**)
/home/worker/buildworker/tiber-gcc-asan/build/gcc/toplev.cc:2282
#11 0x7b2e23 in main
/home/worker/buildworker/tiber-gcc-asan/build/gcc/main.cc:39
#12 0x7fd42da281ef in __libc_start_call_main (/lib64/libc.so.6+0x281ef)
(BuildId: 80328d345e2dd1be1b7a59ab1f54d94f4b916dac)
#13 0x7fd42da282b8 in __libc_start_main@GLIBC_2.2.5
(/lib64/libc.so.6+0x282b8) (BuildId: 80328d345e2dd1be1b7a59ab1f54d94f4b916dac)
#14 0x7b45e4 in _start ../sysdeps/x86_64/start.S:115

0x51302ab8 is located 120 bytes inside of 336-byte region
[0x51302a40,0x51302b90)
freed by thread T0 here:
#0 0x865ec8 in __interceptor_free
/home/worker/buildworker/tiber-gcc-asan/build/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0xbb6103 in gfc_free_symbol(gfc_symbol*&)
/home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/symbol.cc:3105

previously allocated by thread T0 here:
#0 0x866bd7 in __interceptor_calloc
/home/worker/buildworker/tiber-gcc-asan/build/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x57ef974 in xcalloc
/home/worker/buildworker/tiber-gcc-asan/build/libiberty/xmalloc.c:164

SUMMARY: AddressSanitizer: heap-use-after-free
/home/worker/buildworker/tiber-gcc-asan/build/gcc/fortran/parse.cc:359 in
decode_statement
Shadow bytes around the buggy address:
  0x51302800: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x51302880: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x51302900: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x51302980: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
  0x51302a00: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
=>0x51302a80: fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd
  0x51302b00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x51302b80: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x51302c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x51302c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x51302d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==6474==ABORTING

[Bug target/111236] New: ICE in in extract_insn, at recog.cc:2791 on s390x with -Og -march=z13

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111236

Bug ID: 111236
   Summary: ICE in in extract_insn, at recog.cc:2791 on s390x with
-Og -march=z13
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-linux
Target: s390x-linux-gnu

With a cross compiler (revision 85ad41a494e) configured with:

/home/worker/buildworker/tiber-gcc-trunk-s390x/build/configure
--enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap
--disable-libsanitizer --disable-multilib --enable-checking=release
--prefix=/home/worker/cross --target=s390x-linux-gnu
--with-as=/usr/bin/s390x-suse-linux-as

On the GCC testcase gcc/testsuite/gcc.dg/analyzer/torture/pr59037.c

Running it with:

~/cross/bin/s390x-linux-gnu-gcc
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/pr59037.c
-Og -march=z13

Results in:

In file included from
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/pr59037.c:1:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/../../../c-c++-common/pr59037.c:
In function ‘main’:
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/../../../c-c++-common/pr59037.c:12:1:
error: unrecognizable insn:
   12 | }
  | ^
(insn 9 8 10 2 (set (reg:SI 60 [ _4 ])
(vec_select:SI (reg/v:V4SI 62 [ x ])
(parallel [
(const_int 4 [0x4])
])))
"/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/../../../c-c++-common/pr59037.c":11:11
-1
 (nil))
during RTL pass: vregs
/home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/analyzer/torture/../../../c-c++-common/pr59037.c:12:1:
internal compiler error: in extract_insn, at recog.cc:2791
0x626590 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/rtl-error.cc:108
0x6265ac _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/rtl-error.cc:116
0x6259e2 extract_insn(rtx_insn*)
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/recog.cc:2791
0x8d5f30 instantiate_virtual_regs_in_insn
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:1610
0x8d5f30 instantiate_virtual_regs
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:1983
0x8d5f30 execute
   
/home/worker/buildworker/tiber-gcc-trunk-s390x/build/gcc/function.cc:2030

[Bug middle-end/110973] 9% 444.namd regression between g:c2a447d840476dbd (2023-08-03 18:47) and g:73da34a538ddc2ad (2023-08-09 20:17)

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110973

--- Comment #8 from Filip Kastl  ---
(In reply to Filip Kastl from comment #7)
> Not all measurements are back to pre-regression. The Ofast zen3 generic
> score that Martin mentioned
> (https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=466.120.0) is
> still higher than before.

There's also these two:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=789.120.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=300.120.0

And these benchmarks haven't run yet since the commit that Richard thinks fixes
the regression:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=785.120.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=790.120.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=288.120.0

[Bug middle-end/110973] 9% 444.namd regression between g:c2a447d840476dbd (2023-08-03 18:47) and g:73da34a538ddc2ad (2023-08-09 20:17)

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110973

--- Comment #7 from Filip Kastl  ---
Not all measurements are back to pre-regression. The Ofast zen3 generic score
that Martin mentioned
(https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=466.120.0) is still
higher than before.

[Bug middle-end/110973] 9% 444.namd regression between g:c2a447d840476dbd (2023-08-03 18:47) and g:73da34a538ddc2ad (2023-08-09 20:17)

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110973

--- Comment #4 from Filip Kastl  ---
(In reply to Martin Jambor from comment #3)
> There was also a 7.7% regression on zen3 with generic march (these
> measurements are without LTO):
> 
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=466.120.0

I think this slowdown is caused by the r14-3078-gd9f3ea61fe36e2 commit that
Richard mentioned. I measured it on another zen3 machine and got ~7% slowdown.

[Bug middle-end/111152] ~7-9% performance regression on 510.parest_r SPEC 2017 benchmark

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52

Filip Kastl  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Filip Kastl  ---
Marking as duplicate.

*** This bug has been marked as a duplicate of bug 111064 ***

[Bug target/111064] 5-10% regression of parest on icelake between g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a (Aug 15 2023) and g:9ade70bb86c8744f4416a48bb69cf4705f00905a (Aug 16)

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111064

Filip Kastl  changed:

   What|Removed |Added

 CC||fkastl at suse dot cz

--- Comment #5 from Filip Kastl  ---
*** Bug 52 has been marked as a duplicate of this bug. ***

[Bug middle-end/111152] ~7-9% performance regression on 510.parest_r SPEC 2017 benchmark

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52

--- Comment #3 from Filip Kastl  ---
Ah, sorry. Didn't notice I'm making a duplicate.

The Zen3 regression isn't that big and could just be noise.

[Bug middle-end/111152] New: ~7-9% performance regression on 510.parest_r SPEC 2017 benchmark

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52

Bug ID: 52
   Summary: ~7-9% performance regression on 510.parest_r SPEC 2017
benchmark
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: needs-bisection
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: mjambor at suse dot cz
  Target Milestone: ---

There is a performance regression of about 7-9% on the 510.parest_r SPEC 2017
benchmark.

Between g:d073e2d75d9ed492 and g:9ade70bb86c8744f

Intel Xeon Gold 5315Y, all with -Ofast native, some with lto and/or pgo
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=801.457.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=796.457.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=792.457.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=797.457.0

With Zen3 -O2 generic lto pgo the regression is less noticeable (only 4%)
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=694.457.0

[Bug gcov-profile/110988] New: ICE when building 523.xalancbmk_r with pgo and lto

[fkastl at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110988

Bug ID: 110988
   Summary: ICE when building 523.xalancbmk_r with pgo and lto
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

On x86_64 Zen3-based CPU (and probably others) building 523.xalancbmk_r fails
with an ICE in the final build step.

We have bisected this to 2e93b92c1ec5fbbbe10765c6e059c3c90d564245 (Fix profile
update after cancelled loop distribution).

The backtrace is

during GIMPLE pass: vect
./xalanc/PlatformSupport/XalanArrayAllocator.hpp: In member function
'createEntry':
./xalanc/PlatformSupport/XalanArrayAllocator.hpp:174:9: internal compiler
error: in apply_scale, at profile-count.h:1180
  174 | createEntry(
  | ^ 
0x97fd4f profile_count::apply_scale(profile_count, profile_count) const 
../../gcc/gcc/profile-count.h:1180
0xe921fc fold_loop_internal_call(gimple*, tree_node*)
../../gcc/gcc/tree-cfg.cc:7738
0x1124a02 execute
../../gcc/gcc/tree-vectorizer.cc:1328
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [/tmp/ccHpVuHE.mk:26: /tmp/cc6fS858.ltrans8.ltrans.o] Error 1
make[1]: *** Waiting for unfinished jobs