[Bug other/81146] Wine 2.10 cannot be compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81146 --- Comment #1 from Artem S. Tashkinov --- When running with `make -j4` that's what I see first: gcc -o widl client.o expr.o hash.o header.o proxy.o register.o server.o typegen.o typelib.o \ typetree.o utils.o widl.o write_msft.o parser.tab.o parser.yy.o ../../libs/port/libwine_port.a \ ../../libs/wpp/libwpp.a -m32 -Wl,-O1 -Wl,--hash-style=gnu -flto /tmp/ccmagxOP.ltrans8.ltrans.o: In function `spawn': :(.text+0x1029): undefined reference to `_spawnvp' collect2: error: ld returned 1 exit status Makefile:235: recipe for target 'winebuild' failed make[1]: *** [winebuild] Error 1 make[1]: Leaving directory '/tmp/wine-2.10/tools/winebuild' Makefile:20130: recipe for target 'tools/winebuild' failed make: *** [tools/winebuild] Error 2 make[1]: Leaving directory '/tmp/wine-2.10/tools/winedump' /tmp/ccjKNKbe.ltrans17.ltrans.o: In function `main': :(.text.startup+0x47a): undefined reference to `wpp_add_include_path' :(.text.startup+0x4b9): undefined reference to `wpp_add_cmdline_define' :(.text.startup+0x652): undefined reference to `wpp_add_include_path' :(.text.startup+0x7a5): undefined reference to `wpp_set_debug' :(.text.startup+0x890): undefined reference to `wpp_add_define' :(.text.startup+0x8a4): undefined reference to `wpp_add_define' :(.text.startup+0x976): undefined reference to `wpp_parse' :(.text.startup+0xc34): undefined reference to `wpp_add_define' :(.text.startup+0xd13): undefined reference to `wpp_parse' /tmp/ccjKNKbe.ltrans0.ltrans.o: In function `parser_parse': :(.text+0x15fc): undefined reference to `wpp_find_include' :(.text+0x4d60): undefined reference to `wpp_parse' :(.text+0x4ead): undefined reference to `wpp_find_include' collect2: error: ld returned 1 exit status Makefile:324: recipe for target 'widl' failed make[1]: *** [widl] Error 1 make[1]: Leaving directory '/tmp/wine-2.10/tools/widl' Makefile:20109: recipe for target 'tools/widl' failed make: *** [tools/widl] Error 2
[Bug other/81146] New: Wine 2.10 cannot be compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81146 Bug ID: 81146 Summary: Wine 2.10 cannot be compiled with -flto Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Target Milestone: --- I'm trying to compile Wine 2.10 with GCC 6.3.1 for the i686 target and I cannot: ... skipped ... gcc -c -o sfnt2fon.o sfnt2fon.c -I. -I../../include -I/usr/include/freetype2 -I/usr/include/libpng16 \ -D__WINESRC__ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body \ -Wignored-qualifiers -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits \ -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op \ -fno-omit-frame-pointer -O2 -march=pentium-m -m32 -pipe -flto -D__i386__ gcc -o sfnt2fon sfnt2fon.o ../../libs/port/libwine_port.a -lfreetype -m32 -Wl,-O1 -Wl,--hash-style=gnu -flto /tmp/ccgeEnUu.ltrans0.ltrans.o: In function `main': :(.text.startup+0x2c1): undefined reference to `wine_cp_get_table' :(.text.startup+0x2e3): undefined reference to `wine_cp_get_table' collect2: error: ld returned 1 exit status Makefile:179: recipe for target 'sfnt2fon' failed make[1]: *** [sfnt2fon] Error 1 make[1]: Leaving directory '/tmp/wine-2.10/tools/sfnt2fon' Makefile:20099: recipe for target 'tools/sfnt2fon' failed make: *** [tools/sfnt2fon] Error 2 These two commands were used before running ./configure && make export CFLAGS="-O2 -march=pentium-m -m32 -pipe -flto" export LDFLAGS="-m32 -Wl,-O1 -Wl,--hash-style=gnu -flto" Of course I might be doing something wrong. In that case I'm sorry. Without -flto everything works fine.
[Bug rtl-optimization/78911] [5/6 Regression] Infinite loop at -O2/O3 optimization levels while trying to compile server.c from Wine-2.0-rc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911 --- Comment #15 from Artem S. Tashkinov --- Strangely, this bug is still reproducible with GCC 6.3.1 and Wine 2.10.
[Bug middle-end/78911] Infinite loop while trying to compile server.c from Wine-2.0-rc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911 --- Comment #1 from Artem S. Tashkinov --- Update: various -march variants have no effect. -O3 : still hangs -Os : compiles
[Bug c/78911] New: Infinite loop while trying to compile server.c from Wine-2.0-rc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78911 Bug ID: 78911 Summary: Infinite loop while trying to compile server.c from Wine-2.0-rc2 Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Target Milestone: --- Created attachment 40408 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40408=edit Sources gcc -c -o server.o server.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall \ -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla \ -Wwrite-strings -Wpointer-arith -Wlogical-op -fno-omit-frame-pointer -O2 -march=pentium-m -m32 -pipe -D__i386__ gcc --version gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2) gcc -c -o server.o server.c -I. -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall \ > -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body > -Wignored-qualifiers \ > -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits > -Wunused-but-set-parameter -Wvla \ > -Wwrite-strings -Wpointer-arith -Wlogical-op -fno-omit-frame-pointer -O2 > -march=pentium-m -m32 -pipe -D__i386__ -v -save-temps gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. COLLECT_GCC=gcc Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) COLLECT_GCC_OPTIONS='-c' '-o' 'server.o' '-I' '.' '-I' '../../include' '-D' '__WINESRC__' '-D' '_NTSYSTEM_' '-D' '_REENTRANT' '-fPIC' '-Wall' '-pipe' '-fno-strict-aliasing' '-Wdeclaration-after-statement' '-Wempty-body' '-Wignored-qualifiers' '-Wshift-overflow=2' '-Wstrict-prototypes' '-Wtype-limits' '-Wunused-but-set-parameter' '-Wvla' '-Wwrite-strings' '-Wpointer-arith' '-Wlogical-op' '-fno-omit-frame-pointer' '-O2' '-march=pentium-m' '-m32' '-pipe' '-D' '__i386__' '-v' '-save-temps' /usr/libexec/gcc/x86_64-redhat-linux/6.2.1/cc1 -E -quiet -v -I . -I ../../include -imultilib 32 -D __WINESRC__ -D _NTSYSTEM_ -D _REENTRANT -D __i386__ server.c -march=pentium-m -m32 -Wall -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -fPIC -fno-strict-aliasing -fno-omit-frame-pointer -O2 -fpch-preprocess -o server.i ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/6.2.1/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/6.2.1/../../../../x86_64-redhat-linux/include" #include "..." search starts here: #include <...> search starts here: . ../../include /usr/lib/gcc/x86_64-redhat-linux/6.2.1/include /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-c' '-o' 'server.o' '-I' '.' '-I' '../../include' '-D' '__WINESRC__' '-D' '_NTSYSTEM_' '-D' '_REENTRANT' '-fPIC' '-Wall' '-pipe' '-fno-strict-aliasing' '-Wdeclaration-after-statement' '-Wempty-body' '-Wignored-qualifiers' '-Wshift-overflow=2' '-Wstrict-prototypes' '-Wtype-limits' '-Wunused-but-set-parameter' '-Wvla' '-Wwrite-strings' '-Wpointer-arith' '-Wlogical-op' '-fno-omit-frame-pointer' '-O2' '-march=pentium-m' '-m32' '-pipe' '-D' '__i386__' '-v' '-save-temps' /usr/libexec/gcc/x86_64-redhat-linux/6.2.1/cc1 -fpreprocessed server.i -quiet -dumpbase server.c -march=pentium-m -m32 -auxbase-strip server.o -O2 -Wall -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers -Wshift-overflow=2 -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith -Wlogical-op -version -fPIC -fno-strict-aliasing -fno-omit-frame-pointer -o server.s GNU C11 (GCC) version 6.2.1 20160916 (Red Hat 6.2.1-2) (x86_64-redhat-linux) compiled by GNU C version 6.2.1 20160916 (Red Hat 6.2.1-2), GMP version 6.1.1, MPFR version 3.1.4, MPC version 1.0.2, isl version 0.14 or 0.13 warning: MPFR header version 3.1.4 differs from library version 3.1.5. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C11 (GCC) vers
[Bug middle-end/78406] Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78406 --- Comment #2 from Artem S. Tashkinov --- (In reply to Markus Trippelsdorf from comment #1) > Artem, please don't open a new bug for every phoronix benchmark where gcc > appears to be slower than clang. > > First of all there are existing bug report for many of the issues. > And secondly phoronix is famous for its bogus benchmark numbers, > so please take them with a big grain of salt. I'm terribly sorry. Still there are no obvious duplicates for any of the recently reported bugs. I don't pay attention when one compiler is 10%, give or take, faster than another. However this recent test shows some major differences so I was worried that maybe GCC 6.2.0 is falling behind.
[Bug c/78406] New: Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78406 Bug ID: 78406 Summary: Crafty v23.4 is 20% slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Target Milestone: --- http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=4 GCC 6.2.0 - 95 seconds Clang 3.9.0 - 78 seconds GCC options: -lstdc++ -lm CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)
[Bug c/78405] New: 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 Bug ID: 78405 Summary: OpenSSL v1.0.1g RSA 4096 test is 20% slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Target Milestone: --- http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=4 GCC 6.2.0 - 243 Clang 3.9.0 - 289 GCC options: -m64 -O3 -lssl -lcrypto -ldl CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)
[Bug c++/78404] New: SciMark v2.0 Sparse Matrix Multiply test is 20% slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78404 Bug ID: 78404 Summary: SciMark v2.0 Sparse Matrix Multiply test is 20% slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Target Milestone: --- As per http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=2 GCC 6.2.0 - 1835 Clang 3.9.0 - 2204 g++ options: -O3 -march=native CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)
[Bug c++/78403] New: SciMark v2.0 Jacobi Successive Over-Relaxation test is 30% slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78403 Bug ID: 78403 Summary: SciMark v2.0 Jacobi Successive Over-Relaxation test is 30% slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Target Milestone: --- As per http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=2 GCC 6.2.0 - 875 Clang 3.9.0 - 1162 g++ options: -O3 -march=native CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)
[Bug c++/78402] New: SciMark v2.0 Dense LU Matrix Factorization test runs more than 2 times slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78402 Bug ID: 78402 Summary: SciMark v2.0 Dense LU Matrix Factorization test runs more than 2 times slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Target Milestone: --- As per http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=2 GCC 6.2.0 - 1834 Clang 3.9.0 - 4165 g++ options: -O3 -march=native CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)
[Bug c++/78401] New: SciMark v2.0 Composite test runs 1,5 times slower under GCC 6.2 than under Clang 3.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78401 Bug ID: 78401 Summary: SciMark v2.0 Composite test runs 1,5 times slower under GCC 6.2 than under Clang 3.9 Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Target Milestone: --- As per http://www.phoronix.com/scan.php?page=article=gcc-clang-kblclear=2 GCC 6.2.0 - 1057 Clang 3.9.0 - 1603 g++ options: -O3 -march=native CPU: Kaby Lake 7200U (the same CPU core as Sandy Bridge)
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #46 from Artem S. Tashkinov --- (In reply to PeteVine from comment #44) > In case I was a little unclear, the board freezes, not the binary. Looks like GCC optimizes the output so much, the board cannot cope with such a perfect code. ;-) Jokes aside, I tend to believe that it's either a bug in the kernel or board components.
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 Artem S. Tashkinov changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |---
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #31 from Artem S. Tashkinov --- (In reply to Andreas Schwab from comment #30) > /daten/aranym/gcc/gcc-20160811/Build/gcc/testsuite/g++/../../libgcov. > a(_gcov_time_profiler.o): In function `__gcov_time_profiler_atomic': > /daten/aranym/gcc/gcc-20160811/Build/m68k-linux/libgcc/../../../libgcc/ > libgcov-profiler.c:352: undefined reference to `__atomic_fetch_add_8' > collect2: error: ld returned 1 exit status > compiler exited with status 1 > FAIL: g++.dg/other/pr55650.C -std=gnu++98 (test for excess errors) -march=i686 (or higher) should help but it certainly warrants some attention.
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #29 from Artem S. Tashkinov --- (In reply to Martin Liška from comment #28) > Fixed on trunk. Thanks! Will GCC 6.1.1 include these patches?
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #26 from Artem S. Tashkinov --- (In reply to Martin Liška from comment #24) > > Wonderful! What are the chances of this patch being merged with GCC 4.9.x? > > Any, because 4.9 was closed last week and there's not going to be any > release. > If you are interested, I can back-port patches to both 5 and 6 branches? Only if it's relatively straightforward and fast for you. Since you're such a prolific bug solver, the project will benefit a lot more if you keep on solving new unresolved bugs, instead of backporting them. So, suit yourself. And thank you very much!
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #23 from Artem S. Tashkinov --- (In reply to Martin Liška from comment #22) > Sure, as Nathan suggested, we'll select the proper default value according > to -pthread argument. Wonderful! What are the chances of this patch being merged with GCC 4.9.x?
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #21 from Artem S. Tashkinov --- (In reply to Martin Liška from comment #20) > > Do I understand the patch correctly that it requires > > "-fprofile-update=atomic" option in order to eliminate this bug? > > Exactly, I hope I'll be able to merge the whole patchset (5) to mainline > soon. What's the rationale behind this decision? This looks a bit counter intuitive and counter productive. People just enable profiling and don't think twice about extra requirements it might ensue.
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #19 from Artem S. Tashkinov --- (In reply to Martin Liška from comment #18) > Ok, problem is that various value profilers are not updated atomically, > fixed in: > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00600.html Thank you! Do I understand the patch correctly that it requires "-fprofile-update=atomic" option in order to eliminate this bug?
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #16 from Artem S. Tashkinov --- Created attachment 39059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39059=edit unrarsrc-5.4.4 + profile data
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #15 from Artem S. Tashkinov --- (In reply to Martin Liška from comment #13) > Ok, I'll try to reproduce, but I would need: > > 1) echo ""> /tmp/ff.c && gcc -march=native /tmp/ff.c -c -v Done. > 2) please upload somewhere a sample rar archive which you use for training > run https://bit.ly/2az6QHV > 3) command line passed to ./unrar binary (are you using multiple threads?) > > Then it should be hopefully reproducible. ./unrar t -inul /tmp/Rar.testarchive5.rar ./unrar t -inul /tmp/Rar.testarchive.rar Just these two commands. Nothing else. Here are GCC 6.1.0 results: blake2s.cpp: In function ‘void blake2s_update(blake2s_state*, const byte*, size_t)’: blake2s.cpp:138:40: error: corrupted value profile: value profile counter (11420699 out of 11426898) inconsistent with basic-block count (11501625) memcpy( S->buf + left, in, fill ); // Fill buffer ^ blake2s.cpp:162:49: error: corrupted value profile: value profile counter (11501951 out of 11566282) inconsistent with basic-block count (11518351) memcpy( S->buf + left, in, (size_t)inlen ); ^ make: *** [blake2s.o] Error 1 make: *** Waiting for unfinished jobs
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #14 from Artem S. Tashkinov --- Created attachment 39058 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39058=edit gcc -march=native /tmp/ff.c -c -v
[Bug gcov-profile/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #12 from Artem S. Tashkinov --- (In reply to Martin Liška from comment #11) > I've just verified that GCC 5.3.1 and GCC 6.1.1 and latest trunk work fine > (x86_64-linux-gnu). I built the binary and unrar a rar archive. > > Can you please re-try that? Comment 7.
[Bug middle-end/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #9 from Artem S. Tashkinov --- Tow more errors for the same sources: threadpool.cpp: In member function ‘bool 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 -23 threadpool.cpp:213:1: error: corrupted profile info: number of executions for edge 7-8 thought to be 93128 makefile:110: recipe for target 'threadpool.o' failed unpack.cpp: In member function ‘bool Unpack::ReadTables(BitInput&, UnpackBlockHeader&, UnpackBlockTables&)’: unpack.cpp:350:1: error: corrupted profile info: profile data is not flow-consistent } ^ unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 7-66 thought to be 12 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 7-5 thought to be -12 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 14-15 thought to be -19 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 14-16 thought to be 10447 unpack.cpp:350:1: error: corrupted profile info: number of iterations for basic block 15 thought to be -19 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 15-24 thought to be -19 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 41-42 thought to be 184976 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 41-26 thought to be -38846 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 44-46 thought to be 1905937 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 44-45 thought to be -2633 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 55-57 thought to be 2567166 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 55-56 thought to be -2937 unpack.cpp: In member function ‘void Unpack::UnpackDecode(UnpackThreadData&)’: unpack.cpp:350:1: error: corrupted profile info: profile data is not flow-consistent unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 15-59 thought to be 22934224 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 15-16 thought to be -22914989 unpack.cpp:350:1: error: corrupted profile info: number of iterations for basic block 16 thought to be -22888703 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 16-17 thought to be 26397 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 16-18 thought to be -22915100 unpack.cpp:350:1: error: corrupted profile info: number of iterations for basic block 18 thought to be -22890122 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 18-20 thought to be -22890122 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 36-37 thought to be 28405926 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 36-45 thought to be -867648 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 55-56 thought to be 6025631 unpack.cpp:350:1: error: corrupted profile info: number of executions for edge 55-11 thought to be -6475 makefile:110: recipe for target 'unpack.o' failed
[Bug middle-end/58306] Broken profiling for unrar sources: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 Artem S. Tashkinov changed: What|Removed |Added Summary|error: corrupted value |Broken profiling for unrar |profile: value profile |sources: error: corrupted |counter (X out of Y)|value profile: value |inconsistent with |profile counter (X out of |basic-block count |Y) inconsistent with ||basic-block count --- Comment #8 from Artem S. Tashkinov --- Should I reproduce this bug in GCC 6.x as well or at least someone will take a look at it?
[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 Artem S. Tashkinov changed: What|Removed |Added Host||x86_64 i686 Version|5.0 |5.3.1 Known to fail||4.7.3, 4.8.5, 4.9.4, 5.2.1, ||5.3.1 Severity|normal |major
[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #7 from Artem S. Tashkinov --- Affects GCC 5.3.1 as well.
[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564 --- Comment #15 from Artem S. Tashkinov --- Is this the same bug? https://www.phoronix.com/scan.php?page=article=ubuntu-1604-compilers=2 In Dense LU Matrix Factorization GCC 5.3.1/6.0 is more than 2 times slower than Clang. G++ options: -O3 -march=native CPU: Xeon E3-1280 v5
[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69004 Artem S. Tashkinov changed: What|Removed |Added CC||t.artem at mailcity dot com --- Comment #3 from Artem S. Tashkinov --- (In reply to Richard Earnshaw from comment #2) > To make progress on this we're going to need a test-case. > > I think it should be sufficient if you can provide: > > - The profile data > - Preprocessed source for the file that crashes during profile annotation. > > It may be possible to do some reduction on the source file, but it still > needs to show the same error (that probably means the whole function that's > causing the fault will need to be left intact). Well, great, bug 58306 has been there for two years already with zero feedback from developers.
[Bug rtl-optimization/68128] A huge regression in Parboil v2.5 OpenMP CUTCP test (2.5 times lower performance)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68128 --- Comment #2 from Artem S. Tashkinov --- (In reply to Richard Biener from comment #1) > Not very much information (compile flags?) CPU: Intel Xeon E5-2687W v3 ( http://ark.intel.com/products/81909/Intel-Xeon-Processor-E5-2687W-v3-25M-Cache-3_10-GHz ) GCC Flags: (CXX) g++ options: -lm -lpthread -lgomp -ffast-math -fopenmp Something tells me some other GCC flags were used but the benchmarker hasn't yet replied to my question.
[Bug rtl-optimization/68128] New: A huge regression in Parboil v2.5 OpenMP CUTCP test (2.5 times lower performance)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68128 Bug ID: 68128 Summary: A huge regression in Parboil v2.5 OpenMP CUTCP test (2.5 times lower performance) Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Target Milestone: --- According to Phoronix, http://www.phoronix.com/scan.php?page=article=fedora-2023-bench=4 , for Parboil v2.5 OpenMP CUTCP test GCC in Fedora 22/23 produces the code which runs 2.5 times slower than the code produced by Fedora 20. Fedora 20: GCC 4.8.2 (good performance) Fedora 21: GCC 4.9.1 (good performance) Fedora 22: GCC 5.1.1 with patches (huge regression) Fedora 23: GCC 5.1.1 with even more patches (huge regression)
[Bug preprocessor/66322] New: Linus Torvalds: -Wswitch-bool produces dubious warnings, fails to notice really bad things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66322
Bug ID: 66322
Summary: Linus Torvalds: -Wswitch-bool produces dubious
warnings, fails to notice really bad things
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: t.artem at mailcity dot com
Target Milestone: ---
From: https://lkml.org/lkml/2015/5/27/941
Btw, I'd actually like to see (possibly optionally) a warning for enum
types there too. Exactly because *type* based warnings very much make
sense, regardless of number of cases.
For example, try this:
#include stdbool.h
#include stdio.h
enum a { one, two };
int t(bool b, enum a e)
{
switch (b) {
case true:
printf(No arguments\n);
/* fallthrough */
case false:
printf(\n);
}
switch (e) {
case 0:
printf(one);
break;
case two:
printf(two);
break;
}
return 0;
}
and I'd argue that gcc-5.1 warns about TOTALLY THE WRONG THING.
It does that *stupid* warning:
warning: switch condition has boolean value [-Wswitch-bool]
which is just idiotic and wrong.
The case statements are clearly boolean, there is absolutely nothing
wrong with that switch, and a compiler that warns about it is just
being f*cking moronic.
In contrast, that second switch() statement with the case 0: is
actually something that might well be worth warning for. I'd argue
that the code would clearly be more legible if it used case one:
instead.
So the new warning in gcc-5 seems to be just stupid. In general,
warnings that encourage you to write bad code are stupid. The above
switch (boolean) {
case true:
is *good* code, while the gcc documentation suggests that you should
cast it to int in order to avoid the warning, but anybody who
actually thinks that
switch ((int)boolean) {
switch 1:
is better, clearly has absolutely zero taste and is just objectively wrong.
Really. A warning where the very *documentation* tells you to do
stupid things is stupid.
[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #5 from Artem S. Tashkinov t.artem at mailcity dot com --- Created attachment 35355 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35355action=edit Sources and Makefile (run make to reproduce) GCC 5.0.1 RC2 is also affected: g++ -O3 -march=native -Wno-attributes -fno-tree-vectorize -fprofile-use -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DRAR_SMP -DUNRAR -c hash.cpp blake2s.cpp: In function ‘void blake2s_update(blake2s_state*, const byte*, size_t)’: blake2s.cpp:138:40: error: corrupted value profile: value profile counter (10976192 out of 10966245) inconsistent with basic-block count (10996457) memcpy( S-buf + left, in, fill ); // Fill buffer ^ blake2s.cpp:162:49: error: corrupted value profile: value profile counter (10915050 out of 10973342) inconsistent with basic-block count (10932972) memcpy( S-buf + left, in, (size_t)inlen ); ^ make: *** [blake2s.o] Error 1 make: *** Waiting for unfinished jobs
[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #3 from Artem S. Tashkinov t.artem at mailcity dot com --- This bug affects GCC 4.5.4 as well. I guess the bug is no longer relevant since both these GCC releases are deprecated and unsupported.
[Bug middle-end/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #4 from Artem S. Tashkinov t.artem at mailcity dot com --- Created attachment 34783 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34783action=edit Sources and Makefile (run make to reproduce) This bug affects GCC 4.9.2 too! (I'm on i686): blake2s.cpp: In function ‘void blake2s_update(blake2s_state*, const byte*, size_t)’: blake2s.cpp:138:40: error: corrupted value profile: value profile counter (11286702 out of 11276532) inconsistent with basic-block count (9452310) memcpy( S-buf + left, in, fill ); // Fill buffer ^ blake2s.cpp:162:49: error: corrupted value profile: value profile counter (11504160 out of 11557346) inconsistent with basic-block count (11155414) memcpy( S-buf + left, in, (size_t)inlen ); ^ make: *** [blake2s.o] Error 1
[Bug c++/58306] New: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 Bug ID: 58306 Summary: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Created attachment 30744 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30744action=edit Sources + profile info blake2s.cpp: In function ‘void blake2s_update(blake2s_state*, const byte*, size_t)’: blake2s.cpp:133:40: error: corrupted value profile: value profile counter (11354724 out of 11329053) inconsistent with basic-block count (9600416) blake2s.cpp:157:49: error: corrupted value profile: value profile counter (11204032 out of 11277067) inconsistent with basic-block count (10940610) make: *** [blake2s.o] Error 1 make: *** Waiting for unfinished jobs CPU: Intel Core i5 2500 GCC: 4.7.3 ARC: i686 Makefile is included (just run make to see the error).
[Bug c++/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #2 from Artem S. Tashkinov t.artem at mailcity dot com --- (In reply to Paolo Carlini from comment #1) Doesn't look like a C++ front-end issue. Surely, but I had to choose something not knowing what to choose.
[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 --- Comment #9 from Artem S. Tashkinov t.artem at mailcity dot com 2012-11-13 15:06:25 UTC --- (In reply to comment #8) The attached proof of concept patch attempts to just restore the 4.6 and earlier behavior by allowing in all comparisons. Of course perhaps it might be possible it needs better tuning than that, I meant it just as a start for discussions. The results look terrific, I hope this patch will be merged ASAP.
[Bug tree-optimization/54135] New: Dhrystone 2 test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54135 Bug #: 54135 Summary: Dhrystone 2 test performance has seriously decreased in recent GCC releases Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: t.ar...@mailcity.com According to Phoronix Test Suite 4, Dhrystone 2 test from BYTE Unix Benchmark has become significantly slower in recent GCC releases. GCC 4.4.6 ~ 28 000 000 marks GCC 4.7.1 ~ 23 000 000 marks I.e. ~ 22% slower. Presumably the following GCC flags were used: -O2 -march=native Hardware platform: x86-64, Intel Core i7 3960X Benchmark sources: http://www.tux.org/~mayer/linux/bmark.html Test results: http://openbenchmarking.org/prospect/1207296-SU-ARCHLINUX98/eeca68961a90e60898a774766ed28402c20eea75
[Bug tree-optimization/54073] New: SciMark Monte Carlo test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 Bug #: 54073 Summary: SciMark Monte Carlo test performance has seriously decreased in recent GCC releases Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: t.ar...@mailcity.com Created attachment 27860 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27860 Sci Mark Monte Carlo test On an Intel Core i7 CPU (see the attached screenshot): GCC 4.2.x - 380 GCC 4.7.x - 265 i.e. 44% slower. SciMark 2.0 sources can be fetched here: http://math.nist.gov/scimark2/download_c.html
[Bug tree-optimization/54073] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 --- Comment #1 from Artem S. Tashkinov t.artem at mailcity dot com 2012-07-23 15:43:50 UTC --- The results are obtained from here: http://openbenchmarking.org/result/1207077-SU-GCCPERFOR59 Benchmarking of GCC 4.2 through GCC 4.8 when building the compiler the same and setting CFLAGS/CXXFLAGS of -O3 and -march=native prior to test installation and execution. Benchmarking for a future article on Phoronix.com by Michael Larabel. Testing on an Intel Core i7 and AMD Opteron 2384 when using the 64-bit (x86_64 target) build of Ubuntu Linux. The CPU is: Nehalem microarchitecture, Clarksfield (45 nm), Intel® Core™ i7-720QM Processor (6M Cache, 1.60 GHz) http://ark.intel.com/products/43122/Intel-Core-i7-720QM-Processor-%286M-Cache-1_60-GHz%29
[Bug lto/47916] New: Using -flto leads to halved performance of unrar unarchiver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47916 Summary: Using -flto leads to halved performance of unrar unarchiver Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: t.ar...@mailcity.com Created attachment 23483 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23483 unrar sources Using the last released GCC snapshot (gcc-4.6-20110226) and the following compilation flags performance halves. GCC flags used: CXXFLAGS=-O2 -march=i686 -mtune=generic [-flto|] LDFLAGS=[-flto|] Execution times: With -flto: time ./unrar t -inul testarchive.rar real0m33.496s user0m33.171s sys 0m0.140s Without -flto: time ./unrar t -inul testarchive.rar real0m16.326s user0m16.242s sys 0m0.067s ___ This bug will probably attract zero attention from GCC developers but since -flto is not meant to behave such badly I'm posting it. You can produce a rar archive using Rar for Linux (http://rarlabs.com/download.htm): rar a -m5 -mdG -r -s archive.name.rar file1 file2 file3 ... etc.
[Bug lto/47916] Using -flto leads to halved performance of unrar unarchiver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47916 Artem S. Tashkinov t.artem at mailcity dot com changed: What|Removed |Added Keywords||lto, missed-optimization Target||i686-pc-linux-gnu Host||i686-pc-linux-gnu --- Comment #1 from Artem S. Tashkinov t.artem at mailcity dot com 2011-02-27 19:37:02 UTC --- I'm not sure about missed-optimization keyword, so feel free to remove it if it doesn't fit this bug. GCC 4.5.2 produces the similar results, so it's not a regression.
[Bug lto/47916] Using -flto leads to halved performance of unrar unarchiver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47916 Artem S. Tashkinov t.artem at mailcity dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #3 from Artem S. Tashkinov t.artem at mailcity dot com 2011-02-27 20:57:51 UTC --- My bad! export LDFLAGS=-O2 -march=i686 -mtune=generic -flto has solved the problem. However the performance gain from -flto is still negative (0.5%) :)
[Bug lto/47916] Using -flto leads to halved performance of unrar unarchiver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47916 --- Comment #5 from Artem S. Tashkinov t.artem at mailcity dot com 2011-02-27 21:06:04 UTC --- Thanks for the explanation! I'm not sure if it's worth opening a new bug report, but GCC crashes when I try to use -fprofile-generate/-fprofile-use together with -flto: g++ -o unrar -O3 -march=core2 -fomit-frame-pointer -fprofile-use -flto rar.o strlist.o strfn.o pathfn.o savepos.o smallfn.o global.o file.o filefn.o filcreat.o archive.o arcread.o unicode.o system.o isnt.o crypt.o crc.o rawread.o encname.o resource.o match.o timefn.o rdwrfn.o consio.o options.o ulinks.o errhnd.o rarvm.o rijndael.o getbits.o sha1.o extinfo.o extract.o volume.o list.o find.o unpack.o cmddata.o filestr.o recvol.o rs.o scantree.o In file included from :43:0: unpack.cpp: In member function ‘Unpack29’: unpack.cpp:202:6: internal compiler error: in duplicate_loop_to_header_edge, at cfgloopmanip.c:1115 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. At first I built unrar using: CXXFLAGS=LDFLAGS=-O3 -march=core2 -fomit-frame-pointer -fprofile-generate -flto then I made a testrun of unrar, then erased object files, then tried to compile it again using: CXXFLAGS=LDFLAGS=-O3 -march=core2 -fomit-frame-pointer -fprofile-use -flto
[Bug lto/47916] Using -flto leads to halved performance of unrar unarchiver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47916 --- Comment #7 from Artem S. Tashkinov t.artem at mailcity dot com 2011-02-27 23:26:52 UTC --- That should work. The error is a sanity check that profile information is sane. I don't get you :( It seems like you say two opposite things.
[Bug target/40454] [4.4 regression] zlib is about 20% slower when compiled with GCC 4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454 --- Comment #17 from Artem S. Tashkinov t.artem at mailcity dot com 2011-01-31 21:46:29 UTC --- At least on i686 platform the difference is marginal (GCC flags: -O2 -march=pentium-m -fomit-frame-pointer, Intel Core Gen 2 CPU): GCC 3.4.6 real0m15.859s user0m15.662s sys 0m0.177s GCC 4.5.2 real0m16.147s user0m15.939s sys 0m0.187s I'm compressing a 400MB TAR archive containing miscellaneous binaries and documentation. So the issue is m68060 specific.
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 --- Comment #85 from Artem S. Tashkinov t.artem at mailcity dot com 2011-01-18 21:02:43 UTC --- Am I the only one who thinks this bug should be nominated as the first priority GCC 4.6.0 bug? I don't really care if the fix would be backported to 4.5.x or 4.4.x releases, but at least it would be better to have it fixed for GCC 4.6.0.
