Using -Wall and -Woverloaded-virtual together changes the behaviour of the code

Vadim Zeitlin vz-gcc@zeitlins.org
Tue Mar 27 15:12:00 GMT 2018


On Tue, 27 Mar 2018 16:48:39 +0200 Mathieu Malaterre <malat@debian.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-help/attachments/20180327/c34cc7ab/attachment.sig>


More information about the Gcc-help mailing list