On Tue, 27 Mar 2018 16:48:39 +0200 Mathieu Malaterre <malat@xxxxxxxxxx> wrote: MM> Using a mixed stretch with g++-mingw-w64-i686/sid here is what I see: Hi Mathieu and thanks for testing this! MM> $ i686-w64-mingw32-g++ -c -std=c++17 -O2 -Wnonnull -Woverloaded-virtual -v 16795.cpp -o warn.o [...] This is indeed exactly the same thing as I see too, including the warning and everything (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091#c3). MM> COLLECT_GCC_OPTIONS='-c' '-std=c++1z' '-O2' '-Wnonnull' MM> '-Woverloaded-virtual' '-v' '-o' 'warn.o' '-shared-libgcc' MM> '-mtune=generic' '-march=pentiumpro' MM> /usr/bin/i686-w64-mingw32-as -v -o warn.o /tmp/cc9O6U4l.s MM> GNU assembler version 2.28 (i686-w64-mingw32) using BFD version (GNU MM> Binutils) 2.28 MM> 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/ MM> 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/ MM> COLLECT_GCC_OPTIONS='-c' '-std=c++1z' '-O2' '-Wnonnull' MM> '-Woverloaded-virtual' '-v' '-o' 'warn.o' '-shared-libgcc' MM> '-mtune=generic' '-march=pentiumpro' MM> MM> And then: MM> MM> $ objdump -d warn.o | grep -A 2 test_main MM> 000001a0 <__Z9test_mainiPPc>: MM> 1a0: 31 c0 xor %eax,%eax MM> 1a2: c3 ret But here it gives: % objdump -d warn.o | grep -A 2 test_main 000001a0 <__Z9test_mainiPPc>: 1a0: f0 83 05 4c 00 00 00 lock addl $0x1,0x4c 1a7: 01 MM> So I suspect the difference is rather in binutils, mine is still: MM> MM> GNU assembler version 2.28 (i686-w64-mingw32) using BFD version (GNU MM> Binutils) 2.28 It's true that I'm using 2.29.1 (from Buster), but I'm not sure if this can explain the problem because I also see the wrong instruction in the assembly file (16795.s) if I add -save-temps to the compiler command line. And binutils doesn't affect this, does it? The only other thing that might differ that I can think of seems to be completely unrelated, but, just in case it still matters: is your system a normal Linux installation or, like mine, a chroot inside one? Because I've tested this, from the beginning, in a Buster chroot on a Stretch system (on 2 different physical machines) and in a Sid chroot on a Jessie system (on yet another machine). I'm using chroot to isolate the tests, but could it be that gcc somehow misbehaves inside a chroot? Again, I realize that there is no good reason whatsoever for this to be the case, but after seeing so many impossible things already, it wouldn't even seem that surprising to me. For the record, I'm creating my chroots using commands like this: # debootstrap --arch amd64 sid /srv/chroot/sid-amd64 http://httpredir.debian.org/debian # mount -t proc proc /srv/chroot/sid-amd64/proc # mount -t devpts devpts /src/chroot/sid-amd64/dev/pts # chroot /srv/chroot/sid-amd64 apt install g++-mingw-w64-i686 I guess I'll need to update one of my real Stretch systems to Buster and try redoing the test outside of chroot -- unless you're using a chroot as well and so this is not the source of the problem? Thanks again, VZ
Attachment:
pgpZQQi6Vsx1f.pgp
Description: PGP signature
