[Bug rtl-optimization/96337] New: GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337 Bug ID: 96337 Summary: GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4 Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aros at gmx dot com Target Milestone: --- All the pertinent details are on this page: https://www.phoronix.com/scan.php?page=article&item=gcc-10900k-compiler&num=4 Options used: -O2 CPU used: Intel Core i9 10900K I wonder what could have caused such a huge regression. Many Linux distros compile their code just for -march=x86-64 and could be affected by the bug.
[Bug rtl-optimization/96337] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337 --- Comment #2 from Artem S. Tashkinov --- Looks like even kernel performance is affected: https://lore.kernel.org/lkml/20200507224530.2993316-1-ja...@zx2c4.com/ That was surely not a change for the better.
[Bug ipa/96337] [10/11 Regression] GCC 10.2: twice as slow for -O2 -march=x86-64 vs. GCC 9.3/8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96337 --- Comment #12 from Artem S. Tashkinov --- Michael has admitted that might be a specific CPU relate regression: > Been running some more tests today: > - Tried on a i9-10980XE Cascade Lake and Cascade Lake Xeon systems and did > not reproduce... > - I went back to the i9-10900K and picked just a few of the tests where it > was impacted the hardest, but then surprisingly the results were similar that > run. Source: https://www.phoronix.com/forums/forum/software/programming-compilers/1196789-gcc-benchmarks-at-varying-optimization-levels-with-core-i9-10900k-show-an-unexpected-surprise?p=1197196#post1197196 The plot thickens.
[Bug gcov-profile/88608] New: error: corrupted profile info: profile data is not flow-consistent for unrar sources
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88608 Bug ID: 88608 Summary: error: corrupted profile info: profile data is not flow-consistent for unrar sources Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: aros at gmx dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 45289 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45289&action=edit Sources I'm trying to compile unrar sources ( https://rarlab.com/rar/unrarsrc-5.6.8.tar.gz ) using -flto and -fprofile-generate/use. Here's what I get: threadpool.cpp: In member function ‘ThreadPool::GetQueuedTask(ThreadPool::QueueEntry*)’: threadpool.cpp:213:1: error: corrupted profile info: profile data is not flow-consistent } ^ threadpool.cpp:213:1: error: corrupted profile info: number of executions for edge 7-11 thought to be -4 threadpool.cpp:213:1: error: corrupted profile info: number of executions for edge 7-8 thought to be 8272 threadpool.cpp: At top level: make: *** [makefile:132: threadpool.o] Error 1 make: *** Waiting for unfinished jobs unpack.cpp: In member function ‘Unpack::MakeDecodeTables(unsigned char*, DecodeTable*, unsigned int)’: unpack.cpp:354:1: error: corrupted profile info: profile data is not flow-consistent } ^ unpack.cpp:354:1: error: corrupted profile info: number of executions for edge 14-16 thought to be -9 unpack.cpp:354:1: error: corrupted profile info: number of executions for edge 14-15 thought to be 17391 unpack.cpp: At top level: make: *** [makefile:132: unpack.o] Error 1 Run make to see the errors. GCC: gcc-8.2.1-6.fc29.x86_64. CPU: Intel Core i5 2500. Linux: Fedora 29 64.
[Bug ipa/81146] Wine 2.10 cannot be compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81146 Artem S. Tashkinov changed: What|Removed |Added URL||https://bugs.winehq.org/sho ||w_bug.cgi?id=41712 Resolution|--- |INVALID Status|WAITING |RESOLVED
[Bug rtl-optimization/104663] New: A 50% C-Ray regression in GCC 12.0 for ADL at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104663 Bug ID: 104663 Summary: A 50% C-Ray regression in GCC 12.0 for ADL at -O2 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aros at gmx dot com Target Milestone: --- Check the first graph at https://www.phoronix.com/scan.php?page=article&item=gcc12-feb-alderlake&num=3
[Bug target/104663] [12 Regression] C-ray 1.1 performance is 50% worse at -O2 in GCC 12 than before on alderlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104663 --- Comment #3 from Artem S. Tashkinov --- Also -O3 is 50% faster which sounds unreasonable. -O2 with GCC12 is 75% slower than -O3 for GCC 11.
[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 Artem S. Tashkinov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Artem S. Tashkinov --- This is an issue with Wine. Closing as invalid.
[Bug c/105688] New: Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 Bug ID: 105688 Summary: Cannot build GCC 11.3 on Fedora 36 Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: aros at gmx dot com Target Milestone: --- When trying to make gcc-11.3.0.tar.xz: /bin/sh /tmp/gcc-11.3.0/libgcc/../mkinstalldirs 32 /tmp/OBJDIR/./gcc/xgcc -B/tmp/OBJDIR/./gcc/ -B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/ -isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem /opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking -O2 -g -O2 -pipe -mtune=generic -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o 32/libgcc_s.so.1.tmp -g -O2 -pipe -mtune=generic -m32 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc && rm -f 32/libgcc_s.so && if [ -f 32/libgcc_s.so.1 ]; then mv -f 32/libgcc_s.so.1 32/libgcc_s.so.1.backup; else true; fi && mv 32/libgcc_s.so.1.tmp 32/libgcc_s.so.1 && (echo "/* GNU ld script"; echo " Use the shared library, but some functions are only in"; echo " the static library. */"; echo "GROUP ( libgcc_s.so.1 -lgcc )" ) > 32/libgcc_s.so /usr/bin/ld: /tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/bin/ld) collect2: error: ld returned 1 exit status make[5]: *** [Makefile:995: libgcc_s.so] Error 1 I've no idea what to, please help.
[Bug c/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #1 from Artem S. Tashkinov --- In /tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs I replaced the built libstdc++.so.29 _three times_ with the system one (libstdc++.so.30) and it all worked. Still this looks like a serious bug which is worth resolving. Google doesn't find anything relevant, so people may get stuck.
[Bug c/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #2 from Artem S. Tashkinov --- This workaround of mine is not really good: after `make install` you end up with /opt/gcc/lib64/libstdc++.so.6.0.29 which is not GCC's but the system one (/usr/lib64/libstdc++.so.6.0.30.so).
[Bug c/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #4 from Artem S. Tashkinov --- (In reply to Andrew Pinski from comment #3) > How are you building gcc? > What configure options are being passed? > What make options are being passed? > Do you have any env variables set that might effect configure/make? > Are you building in the source directory or a different directory? #! /bin/sh WD=/tmp/OBJDIR GD=`pwd` export CFLAGS="-O2 -pipe -mtune=generic" export CXXFLAGS=$CFLAGS export LDFLAGS="-Wl,-O1" mkdir -p "$WD" && cd "$WD" && \ "$GD"/configure --disable-stage1-checking --with-system-zlib \ --enable-languages="c,c++,lto" --prefix=/opt/gcc \ --disable-sjlj-exceptions --enable-newlib-io-long-long \ --with-gcc-major-version-only --without-isl --enable-multilib nice make -j16
[Bug c/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #5 from Artem S. Tashkinov --- Using the official tar.xz file of course, without any changes/modifications/patches.
[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #10 from Artem S. Tashkinov ---
(In reply to Andrew Pinski from comment #8)
> Do you have the full log?
The full build log? I can generate one right away.
(In reply to Andrew Pinski from comment #9)
> Also can you provide the full output of "env" ?
# env
SHELL=/bin/bash
HOSTNAME=fedora
PWD=/root
LOGNAME=root
HOME=/root
LANG=en_US.UTF-8
XDG_CACHE_HOME=/var/tmp/xdgcache-root
TERM=xterm-256color
LESSOPEN=||/usr/bin/lesspipe.sh %s
USER=root
SHLVL=1
DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/
which_declare=declare -f
PATH=/root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/wine/bin
MAIL=/var/spool/mail/root
BASH_FUNC_which%%=() { ( alias;
eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias
--read-functions --show-tilde --show-dot $@
}
_=/usr/bin/env
[Bug c/105700] New: GCC miscompiles? wine when using -march=pentium-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 Bug ID: 105700 Summary: GCC miscompiles? wine when using -march=pentium-m Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: aros at gmx dot com Target Milestone: --- This is a bug and a call for help simultaneously. I've always built Wine this way: export CFLAGS="-O2 -pipe -m32 -march=pentium-m" export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu" ./configure --prefix=/opt/wine --disable-tests && make --disable-tests && make install-lib This worked until GCC 12.0. With GCC 12.0 and 12.1 the resulting code is somewhat broken and one of Wine processes always crashes on exit with a very cryptic message: [] Process 577885 (winedevice.exe) of user 1000 dumped core. Stack trace of thread 577888: #0 0xf7d51e7d n/a (n/a + 0x0) #1 0xf7d528f7 n/a (n/a + 0x0) ELF object binary architecture: Intel 80386 I've no idea what to do. Normally bugs like this require: > In general, all the information we need can be obtained by collecting the > command line below, as well as its output and the preprocessed file it > generates. However Wine is not a simple application or library. winedevice.exe doesn't run by itself, it's a Wine process which is linked to multiple Wine libraries. Anything can be responsible for the crash. Please advise.
[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 --- Comment #1 from Artem S. Tashkinov --- If I enable core dump gdb rejects the resulting core file as invalid.
[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 --- Comment #2 from Artem S. Tashkinov --- This bug doesn't require any extensive debugging. You just 1. wget https://dl.winehq.org/wine/source/7.x/wine-7.9.tar.xz 2. tar xf wine-7.9.tar.xz 3. cd wine-7.9 4. build using the instructions above 5. wine notepad.exe That will result in a crash a few seconds after you close notepad.exe. winedevice.exe is a background process which gets started automatically, so the crash will happen in background.
[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 --- Comment #4 from Artem S. Tashkinov --- (In reply to Alexander Monakov from comment #3) > It seems you're already getting some good advice on the Wine Bugzilla > (thanks for linking it in the URL field). > > There should be a note in dmesg when a process segfaults outside of a > debugger. If you run wine without gdb, and winedevice.exe crashes, is there > a corresponding message in dmesg? Just this: [] Process 577885 (winedevice.exe) of user 1000 dumped core. Stack trace of thread 577888: #0 0xf7d51e7d n/a (n/a + 0x0) #1 0xf7d528f7 n/a (n/a + 0x0) ELF object binary architecture: Intel 80386 > > Hopefully with the help of Wine folks you'll manage to attach GDB properly > to observe the crash, but one other thing you could do is bisect the > miscompiled binary: if you have two Wine installations, one broken (with > -march=pentium-m) and one working fine (without the flag), then you can take > half of binaries from one and half from another and see if it still crashes. > Depending on the outcome you know which half contains a broken binary. > Continuing this process, you can narrow it down to one file. That's a good but quite herculean in terms of effort idea. If nothing else works, I will try it.
[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 --- Comment #6 from Artem S. Tashkinov --- (In reply to Alexander Monakov from comment #5) > (In reply to Artem S. Tashkinov from comment #4) > > > There should be a note in dmesg when a process segfaults outside of a > > > debugger. If you run wine without gdb, and winedevice.exe crashes, is > > > there > > > a corresponding message in dmesg? > > > > Just this: > > > > [] Process 577885 (winedevice.exe) of user 1000 dumped core. > > Stack trace of thread 577888: > > #0 0xf7d51e7d n/a (n/a + 0x0) > > #1 0xf7d528f7 n/a (n/a + 0x0) > > ELF object binary architecture: Intel 80386 > > This is what systemd-coredump prints. Are you sure the kernel is not > printing a notification in dmesg? It may include useful information such as > register state and binary code around the failing instruction. On my system > it looks like this: > > a.out[13922]: segfault at 0 ip 08049000 sp ffdc8520 error 4 > in a.out[8048000+2000] > Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0f > 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > m In this particular instance the kernel prints nothing of value: [ 7682.461230] systemd-coredump[128529]: Failed to get EXE, ignoring: No such process [ 8005.303334] systemd-coredump[131255]: Failed to get EXE, ignoring: No such process [ 8124.914992] systemd-coredump[132216]: Failed to get EXE, ignoring: No such process [ 8613.546688] systemd-coredump[135946]: Failed to get EXE, ignoring: No such process [ 9218.691456] systemd-coredump[140679]: Failed to get EXE, ignoring: No such process [ 9279.782713] systemd-coredump[141225]: Failed to get EXE, ignoring: No such process [ 9359.481126] systemd-coredump[141902]: Failed to get EXE, ignoring: No such process [ 9408.191922] systemd-coredump[142363]: Failed to get EXE, ignoring: No such process [ 9801.422133] systemd-coredump[145346]: Failed to get EXE, ignoring: No such process Here's the complete extract from journalctl: May 23 07:45:49 localhost.localdomain systemd-coredump[156723]: Failed to get EXE, ignoring: No such process May 23 07:45:49 localhost.localdomain systemd[1]: Started systemd-coredump@9-156723-0.service - Process Core Dump (PID 156723/UID 0). May 23 07:45:49 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@9-156723-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? re> May 23 07:45:49 localhost.localdomain systemd-coredump[156728]: [🡕] Process 156619 (winedevice.exe) of user 1000 dumped core. Module /tmp/wine-7.9/dlls/nsi/nsi.dll.so with build-id cdee5115522275271a6c3afdaac59af31d6be234 Module /tmp/wine-7.9/dlls/dnsapi/dnsapi.dll.so with build-id 0368523c0af17dfa7d027637465e460e3ace701e Module /tmp/wine-7.9/dlls/iphlpapi/iphlpapi.dll.so with build-id e607d635f7424318d832a1d44b5e26510ccaf9a7 Module /tmp/wine-7.9/dlls/ndis.sys/ndis.sys.so with build-id 0d05b4cb7e772e5770011521172601d940b5d43a Module /tmp/wine-7.9/dlls/nsiproxy.sys/nsiproxy.sys.so with build-id 114ce9dc59a5aa105e1686fe3b56df8d64fb39da Module /tmp/wine-7.9/dlls/version/version.dll.so with build-id 32cabde11364952cf000f3eee053af0c7d3d0312 Module /tmp/wine-7.9/dlls/setupapi/setupapi.dll.so with build-id f27838d1c6e2a1fe986fb27a1d2113c57bc16e84 Module /tmp/wine-7.9/dlls/mountmgr.sys/mountmgr.sys.so with build-id 138b6e3f9453aa440b3e3c4797734ca926b5e22c Module /tmp/wine-7.9/dlls/rpcrt4/rpcrt4.dll.so with build-id eecb73f625a3f8fa03dfe2ccb214cbc4d6d92c69 Module /tmp/wine-7.9/dlls/hal/hal.dll.so with build-id cbb7820d15a23ecaa3011cbef54575ddaaed19bf Module /tmp/wine-7.9/dlls/ntoskrnl.exe/ntoskrnl.exe.so with build-id 0db2317ab04b0daa188636955c5ad15bebb27e7b Module /tmp/wine-7.9/dlls/ucrtbase/ucrtbase.dll.so with build-id 9baaee566d599d5be5e2753bcf15d535bf1866b7 Module /tmp/wine-7.9/dlls/sechost/sechost.dll.so with build-id a3920ccf60ea3b4f0ac0a495895a8879eff9e2a0 Module /tmp/wine-7.9/dlls/msvcrt/msvcrt.dll.so with build-id b764cb808b5bbc6b4b1ba531cd7a399aebaab1e3 Module /tmp/wine-7.9/dlls/advapi32/advapi32.dll.so with build-id d78e2fda45c11ec4f77572bc26a5f7033374b5c8 Module /tmp/wine-7.9/programs/winedevice/winedevice.exe.so with build-id eb5cc17648a9d2629b6668b23b570947bf12f145 Stack trace of thread 156622: #0 0xf7d0ee7d n/a (n/a + 0x0) #1 0xf7d0f8f7 n/a (n/a + 0x0) ELF object binary architecture: Intel 80386 May 23 07:45:49 localhost.localdomain systemd[1]: systemd-coredump@9-156723-0.service: Deactivated successfully. > > > That's a good but quite herculean in terms of effort idea. If nothing else > > works, I will try it. > > Each step reduces number of suspicious binaries by half, so only 7 steps for > 128
[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 --- Comment #8 from Artem S. Tashkinov --- (In reply to Richard Biener from comment #7) > It's only a guess but since GCC 12 we enable vectorization by default and > with wine and 32bit apps the stack might not be always aligned properly. So > I'd try > to use -fno-tree-vectorize as additional flag. pentium-m has SSE3 it seems > so > it might enable extra vectorization ontop of x86_64 -m32 (it depends how you > configure GCC what the arch default is for that) Building with `-O2 -pipe -m32 -fno-tree-vectorize -march=pentium-m` hasn't changed anything unfortunately.
[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 --- Comment #9 from Artem S. Tashkinov --- The crash is in ntdll.dll.so but that's a huge library: $ ls -la ntdll*so* -rwxr-xr-x. 1 root root 926240 May 23 09:42 ntdll.dll.so.o2 -rwxr-xr-x. 1 root root 950816 May 23 09:46 ntdll.dll.so.pentiumm ~25KB of extra binary code. Here's another tidbit: even there's no crash (i.e. GCC 12: -O2 -m32, GCC 11.3: -O2 -march=pentium-m -m32), there's still something wrong when exiting Wine applications: 00b0:err:virtual:virtual_setup_exception nested exception on signal stack in thread 00b0 addr 0xf7cc2e9b stack 0x7ff7f0e0 Is it worth attaching GCC's output and the preprocessed file it generates?
[Bug target/105700] GCC miscompiles? wine when using -march=pentium-m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105700 --- Comment #10 from Artem S. Tashkinov --- I'm not a programmer at all (not to mention that I know nothing about CPU instruction set, assembler, etc.), debugging GCC (!) and Wine (!) libraries is quite complicated for me, so I have a strong desire to give up on this bug report and close it as invalid. Anyone who wants to help can trivially use the instructions from comment #2 and have fun. It's all just too overwhelming for me.
[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #11 from Artem S. Tashkinov --- Created attachment 53020 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53020&action=edit gcc-11.3.0.build.log.xz
[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #14 from Artem S. Tashkinov --- Created attachment 53022 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53022&action=edit lddebug.tar.xz (In reply to Andrew Pinski from comment #13) > Can you run the following command: > > In /tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src directory and provide > the ldout.* files? >
[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #18 from Artem S. Tashkinov --- (In reply to Sam James from comment #17) > libtool recently got a new maintainer and had a new release (2.4.7). It's > possible 2.4.7 is related. Fedora 36 still features an old version: libtool-2.4.6-50.fc36.x86_64 Here's its changelog: https://src.fedoraproject.org/rpms/libtool/commits/f36
[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #19 from Artem S. Tashkinov --- I'm curious: Fedora 36 takes probably half an hour to be downloaded and installed in a VM/chroot/etc., so you could probably debug the issue in a few minutes ;-)
[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #25 from Artem S. Tashkinov --- (In reply to Jonathan Wakely from comment #22) > (In reply to Artem S. Tashkinov from comment #19) > > I'm curious: Fedora 36 takes probably half an hour to be downloaded and > > installed in a VM/chroot/etc., so you could probably debug the issue in a > > few minutes ;-) > > GCC 11.3 builds fine for me on F36. Can you please try with the script I posted in comment #4?
[Bug bootstrap/105688] Cannot build GCC 11.3 on Fedora 36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #28 from Artem S. Tashkinov --- (In reply to Jonathan Wakely from comment #27) > (In reply to Artem S. Tashkinov from comment #25) > > Can you please try with the script I posted in comment #4? > > That works fine on F35 and F36. I've just tried again, the result is the same. I have 100% standard Fedora 36 (sans a few custom environment variables defined - see below, nothing GCC related) with all the updates installed. The below commands are all run under the root user (not sudo, an actual login under root). # md5sum gcc-11.3.0.tar.xz 4ee3e8c4c99e7b3444eb79f00f5f7a7e gcc-11.3.0.tar.xz # ld --version GNU gold (version 2.37-27.fc36) 1.16 # gcc --version gcc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1) # ./build.sh ... skipped ... libtool: compile: /tmp/OBJDIR/./gcc/xgcc -shared-libgcc -B/tmp/OBJDIR/./gcc -nostdinc++ -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs -B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/ -isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem /opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking -m32 -I/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/include -I/tmp/gcc-11.3.0/libstdc++-v3/libsupc++ -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=compatibility.lo -g -O2 -pipe -mtune=generic -D_GNU_SOURCE -m32 -fcf-protection -mshstk -c /tmp/gcc-11.3.0/libstdc++-v3/src/c++98/compatibility.cc -o compatibility.o >/dev/null 2>&1 /bin/sh ../libtool --tag CXX --mode=link /tmp/OBJDIR/./gcc/xgcc -shared-libgcc -B/tmp/OBJDIR/./gcc -nostdinc++ -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs -B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/ -isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem /opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking -m32 -Wl,-O1 -Wl,-z,relro -Wl,--gc-sections -std=gnu++98 -fPIC -DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la '-m32' -o libstdc++.la -version-info 6:29:0 -Wl,--version-script=libstdc++-symbols.ver -lm -rpath /opt/gcc/lib/../lib compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-c++0x.lo compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la ../src/c++17/libc++17convenience.la ../src/c++20/libc++20convenience.la libtool: link: /tmp/OBJDIR/./gcc/xgcc -shared-libgcc -B/tmp/OBJDIR/./gcc -nostdinc++ -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs -B/opt/gcc/x86_64-pc-linux-gnu/bin/ -B/opt/gcc/x86_64-pc-linux-gnu/lib/ -isystem /opt/gcc/x86_64-pc-linux-gnu/include -isystem /opt/gcc/x86_64-pc-linux-gnu/sys-include -fno-checking -m32 -fPIC -DPIC -D_GLIBCXX_SHARED -shared -nostdlib /lib/../lib/crti.o /tmp/OBJDIR/./gcc/32/crtbeginS.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11convenience.a ../src/c++17/.libs/libc++17convenience.a ../src/c++20/.libs/libc++20convenience.a -Wl,--no-whole-archive -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src -L/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -lm -L/tmp/OBJDIR/./gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/tmp/OBJDIR/./gcc -lc -lgcc_s /tmp/OBJDIR/./gcc/32/crtendS.o /lib/../lib/crtn.o -m32 -Wl,-O1 -Wl,-z -Wl,relro -Wl,--gc-sections -m32 -Wl,--version-script=libstdc++-symbols.ver -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.29 /usr/bin/ld: /tmp/OBJDIR/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required by /usr/bin/ld) collect2: error: ld returned 1 exit status make[10]: *** [Makefile:732: libstdc++.la] Error 1 make[10]: Leaving directory '/tmp/OBJDIR/x86_64-pc-linux-gnu/32/libstdc++-v3/src' make[9]: *** [Makefile:765: all-recursive] Error 1 make[9]: Leaving directory '/tmp/OBJDIR/x86_64-pc-linux-gnu
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 Artem S. Tashkinov changed: What|Removed |Added Summary|Cannot build GCC 11.3 on|GCC 11.3 doesn't build with |Fedora 36 |the GNU gold linker ||(version 2.37-27.fc36) ||1.16: libstdc++.so.6: ||version `GLIBCXX_3.4.30' ||not found --- Comment #29 from Artem S. Tashkinov --- OK, it all works this way: make LD=ld.bfd GCC 11.3 build system is incompatible with the GNU gold linker. I've changed the bug report title to reflect this. Please, fix it for 11.4 or at least leave a note on your website.
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
--- Comment #30 from Artem S. Tashkinov ---
I'm not sure why certain headers file in the resulting build have changed:
diff -urN gcc/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h
gcc.123/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h
--- gcc/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h2022-07-05 18:10:45 UTC
+++ gcc.gold/lib/gcc/x86_64-pc-linux-gnu/11/include/omp.h 2022-05-22
10:48:25 UTC
@@ -46,8 +46,8 @@
typedef struct
{
- unsigned char _x[12]
-__attribute__((__aligned__(4)));
+ unsigned char _x[16]
+__attribute__((__aligned__(8)));
} omp_nest_lock_t;
#endif
diff -urN gcc/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h
gcc.123/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h
--- gcc/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h
2022-07-05 18:10:46 UTC
+++ gcc.gold/lib/gcc/x86_64-pc-linux-gnu/11/plugin/include/auto-host.h
2022-05-22 10:48:13 UTC
@@ -1662,7 +1662,7 @@
/* Define if your linker supports -z bndplt */
#ifndef USED_FOR_TARGET
-#define HAVE_LD_BNDPLT_SUPPORT 1
+/* #undef HAVE_LD_BNDPLT_SUPPORT */
#endif
@@ -1687,7 +1687,7 @@
/* Define to the level of your linker's compressed debug section support. */
#ifndef USED_FOR_TARGET
-#define HAVE_LD_COMPRESS_DEBUG 3
+#define HAVE_LD_COMPRESS_DEBUG 2
#endif
@@ -1765,7 +1765,7 @@
/* Define if your linker supports --push-state/--pop-state */
#ifndef USED_FOR_TARGET
-#define HAVE_LD_PUSHPOPSTATE_SUPPORT 1
+/* #undef HAVE_LD_PUSHPOPSTATE_SUPPORT */
#endif
@@ -2326,7 +2326,7 @@
/* Specify plugin linker */
#ifndef USED_FOR_TARGET
-#define PLUGIN_LD_SUFFIX "ld.bfd"
+#define PLUGIN_LD_SUFFIX "ld"
#endif
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #31 from Artem S. Tashkinov --- And one final tidbit, `make LD=ld.bfd install prefix=/tmp/GCC-11.3` fails: make[3]: Entering directory '/tmp/OBJDIR/libcc1' make[3]: Nothing to be done for 'install-exec-am'. /usr/bin/mkdir -p '/tmp/GCC-11.3/lib/../lib64' /bin/sh ./libtool --mode=install /usr/bin/install -c libcc1.la '/tmp/GCC-11.3/lib/../lib64' libtool: install: error: cannot install `libcc1.la' to a directory not ending in /opt/gcc/lib/../lib64 make[3]: *** [Makefile:496: install-cc1libLTLIBRARIES] Error 1 make[3]: Leaving directory '/tmp/OBJDIR/libcc1' make[2]: *** [Makefile:690: install-am] Error 2 make[2]: Leaving directory '/tmp/OBJDIR/libcc1' make[1]: *** [Makefile:15937: install-libcc1] Error 2 make[1]: Leaving directory '/tmp/OBJDIR' make: *** [Makefile:2483: install] Error 2
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #40 from Artem S. Tashkinov --- (In reply to Vincent Lefèvre from comment #39) > (In reply to Jonathan Wakely from comment #38) > > (In reply to Vincent Lefèvre from comment #35) > > > (I reported it in 2012, with Jonathan Nieder's patch to fix it, but after > > > 10 > > > years, there is still no reaction from the developers!) > > > > So don't use gold then. > > It is (was) installed by default on some machines. And users don't > necessarily know that it is the cause of failures when building other > software (like this GCC bug). Yes, it was installed by default for me - I've never changed it manually. Checking for available linkers (ld.bfd, ld.gold - at least here on Fedora) and choosing the right one sounds trivial, so I guess someone could write a patch. Should I open a new bug report about comment #31 or it's a known issue?
[Bug bootstrap/105688] GCC 11.3 doesn't build with the GNU gold linker (version 2.37-27.fc36) 1.16: libstdc++.so.6: version `GLIBCXX_3.4.30' not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688 --- Comment #42 from Artem S. Tashkinov --- (In reply to Jonathan Wakely from comment #41) > (In reply to Artem S. Tashkinov from comment #31) > > And one final tidbit, `make LD=ld.bfd install prefix=/tmp/GCC-11.3` fails: > > Is this supposed to work? > > Why aren't you using DESTDIR? I've checked Fedora's spec file and they do `make install prefix`, so that's what I tried. I've never figured out why some projects use DESTDIR and others prefix.
[Bug tree-optimization/109811] New: libxjl 0.7 is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811 Bug ID: 109811 Summary: libxjl 0.7 is a lot slower in GCC 13.1 vs Clang 16 Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aros at gmx dot com Target Milestone: --- Created attachment 55051 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55051&action=edit Graphs Check this: https://www.phoronix.com/review/gcc13-clang16-raptorlake/3
[Bug tree-optimization/109812] New: GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812 Bug ID: 109812 Summary: GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16 Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aros at gmx dot com Target Milestone: --- Check this: https://www.phoronix.com/review/gcc13-clang16-raptorlake/3
[Bug tree-optimization/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812 --- Comment #1 from Artem S. Tashkinov --- Created attachment 55052 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55052&action=edit Graphs
[Bug target/109811] libxjl 0.7 is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811 Artem S. Tashkinov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Artem S. Tashkinov --- According to the latest Phoronix test which can be easily downloaded, run and reproduced, GCC 13.1 loses to Clang by a wide margin, in certain workloads it's ~30% (!) slower and I just wanted to alert its developers to a widening gap in performance v Clang. I'm not a developer either, I'm simply no one. My previous bug reports for performance regressions and deficiencies weren't met with such ... words, so, I'm sorry I'm not in a mood of proving anything, so I'll just go ahead and close it as useless, annoying and maybe even outright invalid.
[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812 Artem S. Tashkinov changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #3 from Artem S. Tashkinov --- According to the latest Phoronix test which can be easily downloaded, run and reproduced, GCC 13.1 loses to Clang by a wide margin, in certain workloads it's ~30% (!) slower and I just wanted to alert its developers to a widening gap in performance v Clang. I'm not a developer either, I'm simply no one. My previous bug reports for performance regressions and deficiencies weren't met with such ... words, so, I'm sorry I'm not in a mood of proving anything, so I'll just go ahead and close it as useless, annoying and maybe even outright invalid.
[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812 Artem S. Tashkinov changed: What|Removed |Added Keywords||missed-optimization Status|RESOLVED|NEW Resolution|INVALID |---
[Bug target/109811] libjxl 0.7 is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811 --- Comment #17 from Artem S. Tashkinov --- Terrific results, thanks a ton! Maybe this bug report could be closed now?
[Bug middle-end/78405] OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78405 Artem S. Tashkinov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Artem S. Tashkinov --- Hopefully this has been fixed.
[Bug middle-end/79704] [meta-bug] Phoronix Test Suite compiler performance issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79704 Bug 79704 depends on bug 78405, which changed state. Bug 78405 Summary: OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC 6.2 than under Clang 3.9 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78405 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug rtl-optimization/113019] New: [NOT A BUG] Multi-architecture binaries for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
Bug ID: 113019
Summary: [NOT A BUG] Multi-architecture binaries for Linux
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aros at gmx dot com
Target Milestone: ---
I know nothing about how libraries/binaries function in Linux or any other OS
however,
Nowadays in Linux there's seemingly a demand [1] [2] for getting more
performance out of applications/libraries by compiling them for newer x86-64
targets, e.g. x86_64_v3 however that instantly excludes a large swathe of CPUs
including very recent Intel CPUs lacking AVX2.
I wonder if GCC is capable of compiling a single library/binary object which
contains distinct code paths for different x86-64 targets. That way you could
have a single binary [object] which has the best performance and compatibility
regardless of where it's run.
I can imagine libraries having offsets for its functions and you cannot have
two offsets for different architectures, but what about 1) having two distinct
functions for different uArchs, e.g. some_routine_x86-64() and
some_routine_x86-64-v3()? or 2) every function having the most basic
if (arch=this)
{run this}
else
{run that}.
At the beginning of it?
I apologize if nothing above makes any sense.
https://ubuntu.com/blog/optimising-ubuntu-performance-on-amd64-architecture
https://www.phoronix.com/news/Arch-Linux-ALHP-x86-64-v4
[Bug rtl-optimization/113019] [NOT A BUG] Multi-architecture binaries for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019 --- Comment #5 from Artem S. Tashkinov --- (In reply to ktkachov from comment #1) > GCC provides the Function Multiversioning feature that's supported on some > architectures: > https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html > > That seems to do what you want? This can only be achieved manually by rewriting everything, while I was thinking about something compiler-side which you can enabled as a compile option.
[Bug rtl-optimization/113235] New: SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang on AMD Zen 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235 Bug ID: 113235 Summary: SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang on AMD Zen 4 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aros at gmx dot com Target Milestone: --- According to Phoronix Test Suite SMHasher SHA3-256 is almost 40% slower when built with GCC 13.2/GCC git snapshort vs Clang: https://www.phoronix.com/review/gcc-clang-eoy2023/3 FormHash32 x86_64 AVX is also a lot slower.
[Bug rtl-optimization/113236] New: WebP benchmark is 20% slower vs. Clang on AMD Zen 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113236 Bug ID: 113236 Summary: WebP benchmark is 20% slower vs. Clang on AMD Zen 4 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: aros at gmx dot com Target Milestone: --- According to Phoronix Test Suite WebP 1.2.4 is 20% slower when built with GCC 13.2/GCC git snapshot vs Clang: https://www.phoronix.com/review/gcc-clang-eoy2023/4
[Bug target/113235] SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang on AMD Zen 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235 --- Comment #1 from Artem S. Tashkinov --- Also valid for MTL: https://www.phoronix.com/review/intel-meteorlake-gcc-clang/2
[Bug target/113236] WebP benchmark is 20% slower vs. Clang on AMD Zen 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113236 --- Comment #1 from Artem S. Tashkinov --- That's WebP image encode, Quality 100, highest compression. Also applies to MTL: https://www.phoronix.com/review/intel-meteorlake-gcc-clang/3
