https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #15 from Erik Schnetter ---
When I try to rebuild GCC 10.3 or 10.2, they end up having the same problem.
Also, when I enable bootstrapping, bootstrapping fails with differences in many
files. Given that this used to work on a previou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #13 from Erik Schnetter ---
The failing GCC 11.1.0 is built by Apple Clang 12.0.5 via Spack. Looking at
debug output, I see that Spack inserts a "-march=skylake" command line option.
(I was not aware of this before.) It does so by cr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #12 from Erik Schnetter ---
Yes, GCC 10.3 (built via MacPorts) still works. The sample program reports a
Skylake CPU with both compilers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #5 from Erik Schnetter ---
This is my hardware configuration:
$ sysctl -a | grep machdep.cpu
machdep.cpu.address_bits.physical: 39
machdep.cpu.address_bits.virtual: 48
machdep.cpu.arch_perf.events: 0
machdep.cpu.arch_perf.events_num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
--- Comment #1 from Erik Schnetter ---
Forgot to add: When I explicitly use "-march=skylake", everything works as
expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100347
Bug ID: 100347
Summary: GCC 11 does not recognize skylake; translates
"march=native" to "x86_64"
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99912
--- Comment #11 from Erik Schnetter ---
The number of active local variables is likely much larger than the number of
registers, and I expect there to be a lot of spilling. I hope that the compiler
is clever about changing the order in which expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102
--- Comment #6 from Erik Schnetter ---
I looked for the string "GCC" in the user header files, but could not find any
place where things would differ between GCC 10.2 and 10.3. I assume there could
be a difference in GCC-provided header files (t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102
--- Comment #1 from Erik Schnetter ---
Created attachment 50605
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50605&action=edit
Compressed preprocessed source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102
Bug ID: 100102
Summary: ICE in tsubst, at cp/pt.c:15310
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99912
--- Comment #5 from Erik Schnetter ---
As you suggested, the problem is probably not caused by register spills, but by
stores into a struct that are not optimized away. In this case, the respective
struct elements are unused in the code.
I trace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99912
--- Comment #4 from Erik Schnetter ---
I build with the compiler options
/Users/eschnett/src/CarpetX/Cactus/view-compilers/bin/g++ -fopenmp -Wall -pipe
-g -march=skylake -std=gnu++17 -O3 -fcx-limited-range -fexcess-precision=fast
-fno-math-errn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99912
--- Comment #2 from Erik Schnetter ---
I did not describe the scale of the issue. There are more than just a few
inefficient or unnecessary operations:
The loop kernel (a single basic block) extends from address 0x1240 to 0xbf27 in
the attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99912
--- Comment #1 from Erik Schnetter ---
Created attachment 50508
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50508&action=edit
Compressed disassembled object file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99912
Bug ID: 99912
Summary: Unnecessary / inefficient spilling of AVX2 ymm
registers
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priori
15 matches
Mail list logo
