Created attachment 43767 [details] Minimal test case reduced by delta This is a completely impossible bug which is nevertheless observed when using i686-w64-mingw32-c++ from Debian Buster (gcc version 7.2-win32 20180123): the compiler produces different (and wrong) object code/assembly when using -O2 depending on whether *both* of "-Wnonnull -Woverloaded-virtual" options are used or not (i.e. the same code is produced if none of them is given, if only -Wnonnull is used or if only -Woverloaded-virtual is used, but the generated code changes if both of them are used at once). Moreover, the generated code may even change depending on the name of the input file on the command line: the attached test case was produced by delta program and was originally called tmp1/16795.cpp and running i686-w64-mingw32-g++ -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 tmp1/16795.cpp produced correct code (i.e. the same as without the warning options), while simply moving it to the current directory and running i686-w64-mingw32-g++ -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 16795.cpp produces wrong code. To reproduce the problem, the same test script as used with delta can be used: #!/bin/sh i686-w64-mingw32-g++ -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 $1 -o warn.o 2>/dev/null & pid1=$! i686-w64-mingw32-g++ -c -std=c++17 -O2 $1 -o nowarn.o 2>/dev/null & pid2=$! if ! wait $pid1 || ! wait $pid2 ; then exit 1 fi if [ $(wc -c < warn.o) -eq $(wc -c < nowarn.o) ]; then exit 2 fi exit 0 (also attached). Running it on 16795.cpp shows that, without the warning options, compiler generates the (expected, as everything is optimized out) trivial body of test_main: xor %eax, %eax ret while with the warning options it generates the following nonsensical instructions: lock addl $0x1,0x4c ret Also notice that this is really the minimal test case, removing any lines, even clearly unused ones such as declarations of never called functions, makes the problem disappear. For the same reason, this file can be only compiled, not linked: adding definitions of various functions used in it makes the problem disappear as well. However the original program, before the reduction, can, of course, be linked, and running it after compiling this file with and without the warning options produces different results at run-time. Please see this thread for more context: https://gcc.gnu.org/ml/gcc-help/2018-03/msg00077.html
Created attachment 43768 [details] Test script used with delta, also useful for testing
This looks like a GC / memory corruption issue to me. Can you check whether using -fchecking uncovers anything? I expect the issue will be impossible to reproduce for us, can you nevertheless please reproduce the output of i686-w64-mingw32-g++ -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 -v 16795.cpp ? That is, if you append '-v'?
(In reply to Richard Biener from comment #2) > This looks like a GC / memory corruption issue to me. Can you check whether > using -fchecking uncovers anything? Using -fchecking doesn't change anything, using -fchecking=2 makes the bug disappear. > I expect the issue will be impossible to reproduce for us, If you can install Debian Buster (current testing), it should be reproducible. At the very least, I've tested this on 2 completely different machines and the behaviour was exactly the same. > can you nevertheless please reproduce the output of > > i686-w64-mingw32-g++ -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 -v > 16795.cpp > > ? That is, if you append '-v'? Sure: % i686-w64-mingw32-g++ -c -std=c++17 -O2 -Wnonnull -Woverloaded-virtual -v 16795.cpp -o warn.o Using built-in specs. COLLECT_GCC=i686-w64-mingw32-g++ Target: i686-w64-mingw32 Configured with: ../../src/configure --build=i686-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/i386-linux-gnu' --libexecdir='/usr/lib/i386-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers=/usr/i686-w64-mingw32/include --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --with-plugin-ld --enable-threads=win32 --program-suffix=-win32 --program-prefix=i686-w64-mingw32- --target=i686-w64-mingw32 --with-as=/usr/bin/i686-w64-mingw32-as --with-ld=/usr/bin/i686-w64-mingw32-ld --enable-libatomic --enable-libstdcxx-filesystem-ts=yes Thread model: win32 gcc version 7.2-win32 20180123 (GCC) COLLECT_GCC_OPTIONS='-c' '-std=c++1z' '-O2' '-Wnonnull' '-Woverloaded-virtual' '-v' '-o' 'warn.o' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /usr/lib/gcc/i686-w64-mingw32/7.2-win32/cc1plus -quiet -v -U_REENTRANT 16795.cpp -quiet -dumpbase 16795.cpp -mtune=generic -march=pentiumpro -auxbase-strip warn.o -O2 -Wnonnull -Woverloaded-virtual -std=c++1z -version -o /tmp/ccmscJ4Y.s GNU C++14 (GCC) version 7.2-win32 20180123 (i686-w64-mingw32) compiled by GNU C version 7.2.0, GMP version 6.1.2, MPFR version 4.0.1-rc1, MPC version 1.1.0, isl version isl-0.18-GMP warning: MPFR header version 4.0.1-rc1 differs from library version 4.0.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/lib/gcc/i686-w64-mingw32/7.2-win32/../../../../i686-w64-mingw32/sys-include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-w64-mingw32/7.2-win32/include/c++ /usr/lib/gcc/i686-w64-mingw32/7.2-win32/include/c++/i686-w64-mingw32 /usr/lib/gcc/i686-w64-mingw32/7.2-win32/include/c++/backward /usr/lib/gcc/i686-w64-mingw32/7.2-win32/include /usr/lib/gcc/i686-w64-mingw32/7.2-win32/include-fixed /usr/lib/gcc/i686-w64-mingw32/7.2-win32/../../../../i686-w64-mingw32/include End of search list. GNU C++14 (GCC) version 7.2-win32 20180123 (i686-w64-mingw32) compiled by GNU C version 7.2.0, GMP version 6.1.2, MPFR version 4.0.1-rc1, MPC version 1.1.0, isl version isl-0.18-GMP warning: MPFR header version 4.0.1-rc1 differs from library version 4.0.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 9c828bbeabdb83d01b583e6b48da537a 16795.cpp: In function ‘unsigned int _get_output_format()’: 16795.cpp:316:25: warning: ‘unsigned int _get_output_format()’ redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] extern "C" unsigned int _get_output_format(void) {return 1;} ^~~~~~~~~~~~~~~~~~ COLLECT_GCC_OPTIONS='-c' '-std=c++1z' '-O2' '-Wnonnull' '-Woverloaded-virtual' '-v' '-o' 'warn.o' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /usr/bin/i686-w64-mingw32-as -v -o warn.o /tmp/ccmscJ4Y.s GNU assembler version 2.29.1 (i686-w64-mingw32) using BFD version (GNU Binutils) 2.29.1 COMPILER_PATH=/usr/lib/gcc/i686-w64-mingw32/7.2-win32/:/usr/lib/gcc/i686-w64-mingw32/7.2-win32/:/usr/lib/gcc/i686-w64-mingw32/:/usr/lib/gcc/i686-w64-mingw32/7.2-win32/:/usr/lib/gcc/i686-w64-mingw32/:/usr/lib/gcc/i686-w64-mingw32/7.2-win32/../../../../i686-w64-mingw32/bin/ LIBRARY_PATH=/usr/lib/gcc/i686-w64-mingw32/7.2-win32/:/usr/lib/gcc/i686-w64-mingw32/7.2-win32/../../../../i686-w64-mingw32/lib/../lib/:/usr/lib/gcc/i686-w64-mingw32/7.2-win32/../../../../i686-w64-mingw32/lib/ COLLECT_GCC_OPTIONS='-c' '-std=c++1z' '-O2' '-Wnonnull' '-Woverloaded-virtual' '-v' '-o' 'warn.o' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro'
I can't reproduce this with: gcc version 7.2.0 20170814 (Fedora MinGW 7.2.0-1.fc26) (GCC) I get one warning: $ i686-w64-mingw32-g++ -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 16795.cpp 16795.cpp: In function 'unsigned int _get_output_format()': 16795.cpp:316:25: warning: 'unsigned int _get_output_format()' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] extern "C" unsigned int _get_output_format(void) {return 1;} ^~~~~~~~~~~~~~~~~~ But no different code depending on the warning options used.
On Tue, 27 Mar 2018, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 > > --- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> --- > I can't reproduce this with: > gcc version 7.2.0 20170814 (Fedora MinGW 7.2.0-1.fc26) (GCC) > > I get one warning: > > $ i686-w64-mingw32-g++ -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 > 16795.cpp > 16795.cpp: In function 'unsigned int _get_output_format()': > 16795.cpp:316:25: warning: 'unsigned int _get_output_format()' redeclared > without dllimport attribute: previous dllimport ignored [-Wattributes] > extern "C" unsigned int _get_output_format(void) {return 1;} > ^~~~~~~~~~~~~~~~~~ > > But no different code depending on the warning options used. It was whether the file was in a subdirectory or in the cwd, not whether the warnings were used.
(In reply to Jonathan Wakely from comment #4) > I can't reproduce this with: > gcc version 7.2.0 20170814 (Fedora MinGW 7.2.0-1.fc26) (GCC) Thanks for testing! So this would seem to indicate that the problem is in the Debian build of the (cross)compiler only, but looking at the Debian-specific patches at https://anonscm.debian.org/cgit/collab-maint/gcc-mingw-w64.git/tree/debian/patches/ I don't see anything that could be even remotely related to this problem, so I still have no idea how is this possible. > I get one warning: > > $ i686-w64-mingw32-g++ -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 > 16795.cpp > 16795.cpp: In function 'unsigned int _get_output_format()': > 16795.cpp:316:25: warning: 'unsigned int _get_output_format()' redeclared > without dllimport attribute: previous dllimport ignored [-Wattributes] > extern "C" unsigned int _get_output_format(void) {return 1;} > ^~~~~~~~~~~~~~~~~~ Yes, I get this warning too, but it's harmless (IMO it's a bug in MinGW-w64 headers, but it's a completely unrelated problem). > But no different code depending on the warning options used. To answer the comment #5 too: I do get different output (both with the initial, real, program, and this test case) just depending on whether the warnings options are used or not. The subdirectory part is a twist on top of that: if I move the file to a subdirectory, then it compiles correctly even when using the warning options. But the real problem is that just adding the warning options to the command line changes the generated code (and breaks it).
(In reply to rguenther@suse.de from comment #5) > It was whether the file was in a subdirectory or in the cwd, not > whether the warnings were used. Both: https://gcc.gnu.org/ml/gcc-help/2018-03/msg00077.html
Vadim, can you please check if the issue is reproducible on preprocessed (-E) input as well, and if so, attach the preprocessed testcase so people can try to repro it without downloading Debian's MinGW headers? Thanks.
Another data point: I can also reproduce the problem with the native (i.e. Linux) g++ 7.3 (Debian 7.3.0-12), although it looks slightly differently there: all 3 of the following commands produce different object files: g++-7 -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 foo.cpp g++-7 -c -std=c++17 -Wnonnull -Woverloaded-virtual -O2 tmp/foo.cpp g++-7 -c -std=c++17 -O2 foo.cpp i.e. moving the file to a subdirectory doesn't mitigate the problem (I probably should have avoided mentioning this in the first place to avoid confusing the matters, sorry). I'm running delta right now to produce a minimized test case for the native compiler, but I am not sure if it's really going to help... The tentative conclusion is that it's not a gcc bug, but a Debian bug, and as it doesn't affect only the cross-compiler, it must be due to one of the Debian-specific patches to gcc itself (thanks to Stephen Kitt, Debian mingw-w64 maintainer, for pointing this out). Unfortunately their list (see https://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-7/debian/patches/ ) is much longer than the list of patches to mingw-w64 and it's not really obvious which one could be to blame...
Created attachment 43770 [details] Compressed preprocessed test case
(In reply to Alexander Monakov from comment #8) > Vadim, can you please check if the issue is reproducible on preprocessed > (-E) input as well, Yes, it is. I've actually started with the preprocessed input initially, but it was so big (~90kLoC) that delta didn't make much progress with it after running for ~2 days, which is why I finally didn't use it. And preprocessing the current test case still results in a ~55kLoC file, so I've had to compress it to attach it here. > and if so, attach the preprocessed testcase so people > can try to repro it without downloading Debian's MinGW headers? Sure, done now. Thanks again for looking at this!
I can reproduce it with downloaded Debian's cc1plus, and for me -Wnonnull alone is sufficient to cause diverging codegen. It diverges very early, in the frontend: diff of .tu dumps starts with: --- a/1/16795.cpp.001t.tu +++ b/2/16795.cpp.001t.tu @@ -110354,336 +110354,337 @@ @56158 bind_expr type: @27 body: @59125 @56159 cond_expr type: @27 op 0: @5106 op 1: @59126 op 2: @59127 -@56160 cleanup_point_expr type: @27 op 0: @59128 -@56161 convert_expr type: @27 op 0: @59129 -@56162 call_expr type: @109 fn : @59130 0 : @59131 - 1 : @59132 -@56163 expr_stmt type: @27 line: 732 expr: @59133 -@56164 cleanup_point_expr type: @109 op 0: @59134 +@56160 cond_expr type: @27 op 0: @5106 op 1: @59128 + op 2: @59129 +@56161 convert_expr type: @27 op 0: @59130 +@56162 call_expr type: @109 fn : @59131 0 : @59132 + 1 : @59133 +@56163 expr_stmt type: @27 line: 732 expr: @59134 +@56164 cleanup_point_expr type: @109 op 0: @59135 and .original diff has the following hunk: @@ -17695,8 +17695,11 @@ return <retval> = __out; <<cleanup_point <<< Unknown tree: expr_stmt lmi_test::record_error () >>>>>; } - <<cleanup_point <<< Unknown tree: expr_stmt + if (0) + { + <<cleanup_point <<< Unknown tree: expr_stmt lmi_test::record_error () >>>>>; + } } (in the diffs, plus-lines correspond to -Wnonnull added to command line)
> (in the diffs, plus-lines correspond to -Wnonnull added to command line) No, sorry, it was the other way around. Here's the reverse diff with more context: if (0) { <<cleanup_point <<< Unknown tree: expr_stmt lmi_test::record_error () >>>>>; } - if (0) - { - <<cleanup_point <<< Unknown tree: expr_stmt + <<cleanup_point <<< Unknown tree: expr_stmt lmi_test::record_error () >>>>>; - } } It corresponds to if(!(!std::signbit(bourn_cast<To>( From(0))))) { lmi_test::record_error(); }; if(!(std::signbit(bourn_cast<To>(-From(0))))) { lmi_test::record_error(); }; in template instantiation test_floating_conversions<double, float>. Essentially, with -Wnonnull the second condition seems to be folded to truth value.
Created attachment 43772 [details] valgrind output (ok)
Created attachment 43773 [details] valgrind output (not ok)
(In reply to Alexander Monakov from comment #13) > It corresponds to > > if(!(!std::signbit(bourn_cast<To>( From(0))))) { > lmi_test::record_error(); }; > if(!(std::signbit(bourn_cast<To>(-From(0))))) { > lmi_test::record_error(); }; > > in template instantiation test_floating_conversions<double, float>. > Essentially, with -Wnonnull the second condition seems to be folded to truth > value. This is reassuring because this pinpoints the problem I had had originally: the unit test failed because the signbit() check didn't pass. I thought this wasn't relevant as the difference in the generated code (i.e. "lock addl $0x1,0x4c" instead of "xor %eax, %eax") didn't seem to be related to it, but apparently it still is. And I can also confirm that -Wnonnull is sufficient for the output to change with the final test case. It wasn't for the original program, but apparently delta simplified things enough for -Woverloaded-virtual to become unnecessary at some point (would it be important to find when? If so, I could try doing this...).
Here is what I did over here: # debootstrap --arch amd64 sid /srv/chroot/sid-amd64 http://httpredir.debian.org/debian # mount -t proc proc /srv/chroot/sid-amd64/proc # chroot /srv/chroot/sid-amd64 apt install g++-mingw-w64-i686 Then (https://wiki.debian.org/AutomaticDebugPackages): # apt install g++-mingw-w64-i686-dbgsym And eventually ran valgrind on both: # valgrind --trace-children=yes i686-w64-mingw32-g++ -c -std=c++17 -O2 -Wnonnull -Woverloaded-virtual -v tmp1/16795.cpp -o warn.o >& /tmp/ok # valgrind --trace-children=yes i686-w64-mingw32-g++ -c -std=c++17 -O2 -Wnonnull -Woverloaded-virtual -v 16795.cpp -o warn.o >& /tmp/notok The valgrind output seems rather different, so I suspect the issue is indeed an invalid read/write which should be somewhere in the diff of ok vs notok.
The first diff seems to be here: +Use of uninitialised value of size 8 + at 0x98CBD7: sparseset_bit_p (sparseset.h:147) + by 0x98CBD7: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1226) + by 0x97189E: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1806) + by 0x98D231: ira_create_allocno_live_ranges() (ira-lives.c:1564) + by 0x97345C: ira_build() (ira-build.c:3422) + by 0x96ACCB: ira (ira.c:5308) + by 0x96ACCB: (anonymous namespace)::pass_ira::execute(function*) (ira.c:5619) + by 0xA30676: execute_one_pass(opt_pass*) (passes.c:2465) + by 0xA30E80: execute_pass_list_1(opt_pass*) (passes.c:2554) + by 0xA30E92: execute_pass_list_1(opt_pass*) (passes.c:2555) + by 0xA30ED4: execute_pass_list(function*, opt_pass*) (passes.c:2565) + by 0x7ABC51: cgraph_node::expand() (cgraphunit.c:2042) + by 0x7ACFF8: expand_all_functions (cgraphunit.c:2178) + by 0x7ACFF8: symbol_table::compile() [clone .part.50] (cgraphunit.c:2536) + by 0x7AECE6: compile (cgraphunit.c:2629) + by 0x7AECE6: symbol_table::finalize_compilation_unit() (cgraphunit.c:2626)
(In reply to Mathieu Malaterre from comment #18) > The first diff seems to be here: > > +Use of uninitialised value of size 8 > + at 0x98CBD7: sparseset_bit_p (sparseset.h:147) > + by 0x98CBD7: process_bb_node_lives(ira_loop_tree_node*) > (ira-lives.c:1226) > + by 0x97189E: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void > (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1806) > + by 0x98D231: ira_create_allocno_live_ranges() (ira-lives.c:1564) > + by 0x97345C: ira_build() (ira-build.c:3422) > + by 0x96ACCB: ira (ira.c:5308) > + by 0x96ACCB: (anonymous namespace)::pass_ira::execute(function*) > (ira.c:5619) > + by 0xA30676: execute_one_pass(opt_pass*) (passes.c:2465) > + by 0xA30E80: execute_pass_list_1(opt_pass*) (passes.c:2554) > + by 0xA30E92: execute_pass_list_1(opt_pass*) (passes.c:2555) > + by 0xA30ED4: execute_pass_list(function*, opt_pass*) (passes.c:2565) > + by 0x7ABC51: cgraph_node::expand() (cgraphunit.c:2042) > + by 0x7ACFF8: expand_all_functions (cgraphunit.c:2178) > + by 0x7ACFF8: symbol_table::compile() [clone .part.50] (cgraphunit.c:2536) > + by 0x7AECE6: compile (cgraphunit.c:2629) > + by 0x7AECE6: symbol_table::finalize_compilation_unit() > (cgraphunit.c:2626) This should be fine, please take a look here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78454
(In reply to Martin Liška from comment #19) > (In reply to Mathieu Malaterre from comment #18) > > The first diff seems to be here: > > > > +Use of uninitialised value of size 8 > > + at 0x98CBD7: sparseset_bit_p (sparseset.h:147) > > + by 0x98CBD7: process_bb_node_lives(ira_loop_tree_node*) > > (ira-lives.c:1226) > > + by 0x97189E: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void > > (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1806) > > + by 0x98D231: ira_create_allocno_live_ranges() (ira-lives.c:1564) > > + by 0x97345C: ira_build() (ira-build.c:3422) > > + by 0x96ACCB: ira (ira.c:5308) > > + by 0x96ACCB: (anonymous namespace)::pass_ira::execute(function*) > > (ira.c:5619) > > + by 0xA30676: execute_one_pass(opt_pass*) (passes.c:2465) > > + by 0xA30E80: execute_pass_list_1(opt_pass*) (passes.c:2554) > > + by 0xA30E92: execute_pass_list_1(opt_pass*) (passes.c:2555) > > + by 0xA30ED4: execute_pass_list(function*, opt_pass*) (passes.c:2565) > > + by 0x7ABC51: cgraph_node::expand() (cgraphunit.c:2042) > > + by 0x7ACFF8: expand_all_functions (cgraphunit.c:2178) > > + by 0x7ACFF8: symbol_table::compile() [clone .part.50] (cgraphunit.c:2536) > > + by 0x7AECE6: compile (cgraphunit.c:2629) > > + by 0x7AECE6: symbol_table::finalize_compilation_unit() > > (cgraphunit.c:2626) > > This should be fine, please take a look here: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78454 Ooops :( Sorry false alarm. So I meant to say "This must be somewhere before [insert block quote]".
Created attachment 43774 [details] Reduced test case showing the problem with native g++ 7.3
Created attachment 43775 [details] Compressed preprocessed test case for native Linux gcc 7.3
Just to confirm that this is not specific to MinGW-w64, I've attached the test case (and a preprocessed version of it) allowing to reproduce the same problem with Linux x86_64 version of g++ 7.3 (7.3.0-12 from Debian/Sid). Unlike the other test case, this one really requires both -Wnonnull and -Woverloaded-virtual to be specified to see the problem, so the commands to use are (I also switched to assembly because I figured this was simpler to compare than disassembling object files, but this is not significant): % g++-7 -S -std=c++17 -O2 gcc-7.3-x86_64-linux.cpp -o nowarn.s % g++-7 -S -std=c++17 -O2 gcc-7.3-x86_64-linux.cpp -Wnonnull -Woverloaded-virtual -o warn.s % diff -u nowarn.s warn.s|head --- nowarn.s 2018-03-27 17:11:31.841485730 +0000 +++ warn.s 2018-03-27 17:11:41.961553404 +0000 @@ -616,17 +616,15 @@ .LEHB19: call _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l@PLT .LEHE19: -.L89: - lock addl $1, _ZN8lmi_test4test20test_tools_successesE(%rip) popq %rbx .cfi_remember_state ("head" is used because there are plenty of other insignificant differences due to the labels renumbering later). Please let me know if I can do anything else.
> Please let me know if I can do anything else. Can you please attach full diff? Am I correct that your native compiler is on x86_64? Please attach output of --verbose.
(In reply to Martin Liška from comment #24) > > Please let me know if I can do anything else. > > Can you please attach full diff? Sorry, diff between what and what? > Am I correct that your native compiler is on x86_64? Yes. > Please attach output of --verbose. Here it is: % g++-7 --verbose -S -std=c++17 -O2 -Wnonnull -Woverloaded-virtual gcc-7.3-x86_64-linux.cpp -o warn.s Using built-in specs. COLLECT_GCC=g++-7 OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 7.3.0-12' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.3.0 (Debian 7.3.0-12) COLLECT_GCC_OPTIONS='-v' '-S' '-std=c++1z' '-O2' '-Wnonnull' '-Woverloaded-virtual' '-o' 'warn.s' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/7/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE 14881.cpp -quiet -dumpbase 14881.cpp -mtune=generic -march=x86-64 -auxbase-strip warn.s -O2 -Wnonnull -Woverloaded-virtual -std=c++1z -version -o warn.s GNU C++14 (Debian 7.3.0-12) version 7.3.0 (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/7" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/7 /usr/include/x86_64-linux-gnu/c++/7 /usr/include/c++/7/backward /usr/lib/gcc/x86_64-linux-gnu/7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++14 (Debian 7.3.0-12) version 7.3.0 (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 6054b92b0b90c9db1f26de9c9b53361c COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-S' '-std=c++1z' '-O2' '-Wnonnull' '-Woverloaded-virtual' '-o' 'warn.s' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
complete output of: diff -u nowarn.s warn.s
Created attachment 43777 [details] Diff between assembly generated with and without the warning options
(In reply to Martin Liška from comment #26) > complete output of: > diff -u nowarn.s warn.s Attached, but most of it is just noise from the label renumbering due to the extra label being created, as previously mentioned.
Thanks. I can't reproduce that on my openSUSE package nor on my build gcc-7-branch. However I downloaded Debian binary and I can confirm that. I'm bisecting now...
(In reply to Martin Liška from comment #29) > Thanks. I can't reproduce that on my openSUSE package nor on my build > gcc-7-branch. However I downloaded Debian binary and I can confirm that. > I'm bisecting now... ... reducing :)
Created attachment 43781 [details] Partially reduced test-case I've got 120KB partially reduced test-case. Any further reduction is not much possible. I'm able to reproduce that with -O1 -Woverloaded-virtual. It's super-weird issue, any ggc parameters adjustments do not make any change. I would recommend to create Debian-specific issue and somebody will need to investigate which patch is responsible for that.
(In reply to Martin Liška from comment #31) > Created attachment 43781 [details] > Partially reduced test-case > > I've got 120KB partially reduced test-case. Any further reduction is not > much possible. I'm able to reproduce that with -O1 -Woverloaded-virtual. > It's super-weird issue, any ggc parameters adjustments do not make any > change. > I would recommend to create Debian-specific issue and somebody will need to > investigate which patch is responsible for that. Thanks Martin! I've created https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894302 for it now, pointing to this bug and your test case.