[Bug c/26542] bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*'
--- Comment #4 from vz-gcc at zeitlins dot org 2006-07-24 17:02 ---
I'd like to (probably uselessly but still) argue for reopening this bug and
removing this warning. The interpretation of the standard text is open to
questions: IMHO an "A *" pointer is a pointer to void, too, as any pointer in C
is, implicitely, pointer to void. But most importantly I think this warning is
absolutely useless and the only way to get rid of it is ugly (you need an
explicit cast to "void *").
But, again, the most important argument against this warning is that it's 100%
useless. Conversion of any pointer to "void *" is well defined and unambiguous
(even in presence of multiple inheritance) and there is just no situation
whatsoever in which this warning can indicate a real problem. Please consider
suppressing it, thanks in advance!
--
vz-gcc at zeitlins dot org changed:
What|Removed |Added
CC| |vz-gcc at zeitlins dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26542
[Bug c++/35080] __thread generators a.out that creates segmentation fault
--- Comment #1 from vz-gcc at zeitlins dot org 2008-09-06 21:27 --- I found this bug while searching for __thread-related problems and FWIW I can't reproduce this on a very similar system with g++ 4.1.2 from Debian stable so maybe this can be closed as fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35080
[Bug c++/37402] New: Incorrect access to static __thread variables inside static member functions
First of all, sorry in advance for submitting a bug with no way to reproduce it
but I unfortunately already spent several hours on this and I simply can't
manage to make this fail in a simple example. In spite of this it seems like
this could be a compiler problem and not something in my code so I'd like to
report it and let you decide whether it's worth looking into.
Anyhow, the problem is that the compiler seems to do something strange with the
code which looks like this:
class UTF8String {
private:
// we use this cache to speed up some common operations on UTF-8 strings
struct CacheElement {
const UTF8String *str; // the key of the cache
int posInChars, posInBytes, len;
};
struct Cache { CacheElement cached[8]; int lastUsed; };
static Cache& GetCache() { static Cache s_cache; return s_cache; }
// find or allocate one of GetCache().cached elements for this object
CacheElement *GetCacheElement() const { ... }
public:
size_t length() const {
CacheElement * const c = GetCacheElement();
if ( cache->len == npos )
cache->len = ... compute ...;
return cache->len;
}
};
Everything works perfectly fine with -O0 and with -O2 in simple examples.
However as soon as the code becomes a bit more complicated, sometimes
GetCacheElement() in length() returns bogus values, i.e. pointers to the
elements which are not in cached array at all (according to its printout, using
a special function in the program as gdb seems to be very confused by __thread
variables). I suspected a bug in my GetCacheElement(), of course, but it's
pretty trivial (linear search in the array basically...) and seems to be
correct and, moreover, everything works fine as long as -O2 is not used _or_
the Cache variable is made class static and accessed directly instead of in the
above way.
The real code can be found at
http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/include/wx/string.h?revision=55501&view=markup
but needs to be modified by disabling workaround found near comment containing
"g++ 4.1.2" string to see the problem. Basically it's enough to do "configure
&& make && cd tests && make && ./test" to see that it works with -O0 (or with
the workaround) and fails in mysterious ways with -O2. Sorry once again for not
being able to provide a simpler test case.
And all this happens on an amd64 Debian stable machine with (Debian) g++ 4.1.2
in single threaded test code.
--
Summary: Incorrect access to static __thread variables inside
static member functions
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37402
[Bug target/37402] Incorrect access to static __thread variables inside static member functions
--- Comment #2 from vz-gcc at zeitlins dot org 2008-09-06 22:41 --- Andrew, thanks for your reply! And yes, I realize this but unfortunately it really seems specific to something that optimizer does and maybe something it does at the whole unit level and not locally as even extracting parts of wxString implementation in a separate file isn't enough to reproduce it. So the only test case I have is wxWidgets itself (the svn trunk version). Again, I realize it's huge and impractical but unfortunately I simply don't have any more time (nor ideas to be honest) to try to reproduce this in a small example. I leave it to you to close this then... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37402
[Bug c++/94867] New: New (since gcc 8) false positive with -Wnull-dereference in very simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94867
Bug ID: 94867
Summary: New (since gcc 8) false positive with
-Wnull-dereference in very simple code
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Consider:
% cat -n gcc-null-deref.cpp
1 #include
2
3 void test()
4 {
5 std::vector p;
6 p.push_back(1);
7 std::vector q(p.size());
8 q[0] = p[0];
9 }
% g++-9 -O2 -c gcc-null-deref.cpp -Wnull-dereference
gcc-null-deref.cpp: In function ‘void test()’:
gcc-null-deref.cpp:8:10: warning: potential null pointer dereference
[-Wnull-dereference]
8 | q[0] = p[0];
This is with gcc version 9.3.0 (Debian 9.3.0-11). It doesn't happen with g++-8
but does still happen with the latest version available in Debian which is gcc
version 10.0.1 20200418 (experimental) [master revision
27c171775ab:4c277008be0:c5bac7d127f288fd2f8a1f15c3f30da5903141c6] (Debian
10-20200418-1)
FWIW it looks like -Wnull-dereference really doesn't like push_back() for
whatever reason. Even initializing the vector with fixed size doesn't help to
make the warning go away -- however doing this _and_ removing push_back() does
help.
[Bug c++/94867] [9 Regression] New (since gcc 8) false positive with -Wnull-dereference in very simple code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94867 --- Comment #4 from Vadim Zeitlin --- (In reply to Martin Liška from comment #3) > It's gone since r10-3311-gff6686d2e5f797d6. This commit is included in releases/gcc-10.1.0 tag, but I still see the warning with the provided example when using g++ 10.1 with -O, as mentioned in comment #2, even though I indeed don't see it with -O2 any longer.
[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 #17 from Vadim Zeitlin --- I've just subscribed to this bug because we see bug slow downs in our project when switching from 8.3 to 10.2 (89% slower in an important use case, 30% slowdown more or less across the board), without any other changes. We don't have any simple test showing this (yet), but there is definitely something very wrong here and I don't think it should be closed. FWIW in our case using -O3 doesn't help (it does make the code marginally faster, but improvement of <0.01% is not worth 10% higher build time).
[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 #19 from Vadim Zeitlin --- (In reply to Jan Hubicka from comment #18) > We need a reproducer to fix bugs. Yes, of course, I understand this. I just didn't have time to make one yet, we've literally discovered the issue only today (well, maybe yesterday, depending on the time zone). > So if you have actual testcase that > slow down, it would be great to open separate bug report for that. OK, will do, but, at least superficially, our situation seems very similar to this one, so I thought it would be better to keep this one going. But, again, I'll open the new one as soon as I can make a test case for it, if this is your preference.
[Bug c++/32205] New: "defined but not used" warning given or not depending on other errors
Consider the following code:
% cat unused.cpp
static int GetFoo() { return 17; }
static int foo = GetFoo();
void bar()
{
}
This compiles without warnings:
% g++ -Wall -c unused.cpp
%
However if any error is introduced, like e.g. removing the closing brace of the
bar() function, then we get both the (expected) error message and (less
expected) warning:
% g++ -Wall -c unused.cpp
unused.cpp: In function 'void bar()':
unused.cpp:6: error: expected `}' at end of input
unused.cpp: At global scope:
unused.cpp:3: warning: 'foo' defined but not used
I don't know if the warning should or not be given (actually I'm glad to not
have it in my code as my equivalent of GetFoo() has side effects) but it seems
strange that the fact whether it's given or not depends on whether there are
any other errors in the code.
I realize this is not very important (hence the choice of severity) but I
wanted to let you know about it in case this indicates some more serious
problem with issuing this warning. Please feel free to ignore this bug report
if it doesn't.
Thanks!
--
Summary: "defined but not used" warning given or not depending on
other errors
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32205
[Bug c++/69777] Give a warning when virtual function is devirtualized into a __cxa_pure_virtual call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69777
--- Comment #4 from Vadim Zeitlin ---
Sorry, I've somehow forgot to provide the example, but here it is in its most
minimal form:
namespace {
struct AnonB {
virtual bool foo() const = 0;
virtual ~AnonB() {}
};
}
struct RealB {
virtual bool foo() const = 0;
virtual ~RealB() {}
};
AnonB* create()
{
struct D : RealB {
virtual bool foo() const { return true; }
};
return reinterpret_cast(new D);
}
int main() {
return create()->foo(); // please ignore the memory leak here
}
Compiling this without optimizations "works", while with -O2 or -O3 the program
terminates due to a pure virtual function call and the code looks just like
this:
(gdb) disassemble
Dump of assembler code for function main():
=> 0x00400670 <+0>: movedi,0x8
0x00400675 <+5>: subrsp,0x8
0x00400679 <+9>: call 0x400660 <_Znwm@plt>
0x0040067e <+14>:movQWORD PTR [rax],0x4008b0
0x00400685 <+21>:movrdi,rax
0x00400688 <+24>:call 0x400650 <__cxa_pure_virtual@plt>
End of assembler dump.
Again, I understand that the program invokes undefined behaviour and the
compiler is perfectly in its right to do what it does. But in practice casts
such as above are always required when using COM with its QueryInterface() and
it would be nice if the compiler could warn about this devirtualization because
it can never be intentional, AFAICS.
Also notice that giving the namespace a name (and replacing AnonB with
NS::AnonB) also prevents the devirtualization from happening.
Finally, I've tested this with (the originally reported) 4.9, 5.5, 6.4 and 7.2
and the behaviour is almost the same for all of them, but 7.2 does give this
warning
puredevirt.cpp: In function ‘int main()’:
puredevirt.cpp:24:25: warning: ‘’ is used uninitialized in this
function [-Wuninitialized]
return create()->foo();
~^~
I guess this already partially addresses my request because at least there is a
warning, but its wording is not especially clear. Looking at the disassembly
(gdb) disassemble
Dump of assembler code for function main:
=> 0x4600 <+0>: subrsp,0x8
0x4604 <+4>: movedi,0x8
0x4609 <+9>: call 0x45e0 <_Znwm@plt>
0x460e <+14>:call 0x45d0 <__cxa_pure_virtual@plt>
End of assembler dump.
it becomes clear that it's the object on which foo() is called which is not
initialized (i.e. it doesn't even bother loading its address before calling
__cxa_pure_virtual, which makes sense), but it's not really obvious from just
the error message.
[Bug c++/87120] New: gcc incorrectly accepts uniform-initializing bool values from double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87120
Bug ID: 87120
Summary: gcc incorrectly accepts uniform-initializing bool
values from double
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
gcc 8.2.0 incorrectly (AFAICS) compiles the following program:
% cat -n init.cpp
1 double foo() { return 17.0; }
2
3 int main()
4 {
5 bool b{foo()};
6 return b;
7 }
% g++ -std=c++17 -Wall init.cpp
% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-4'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--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 8.2.0 (Debian 8.2.0-4)
Compare this with clang:
% clang++-7 -std=c++17 -Wall init.cpp && ./a.out
init.cpp:5:12: error: type 'double' cannot be narrowed to 'bool' in initializer
list [-Wc++11-narrowing]
bool b{foo()};
^
init.cpp:5:12: note: insert an explicit cast to silence this issue
bool b{foo()};
^
static_cast( )
1 error generated.
or MSVS 2017.7:
% cl /W4 init.cpp
init.cpp
init.cpp(5): error C2397: conversion from 'double' to 'bool' requires a
narrowing conversion
[Bug c++/87120] gcc incorrectly accepts uniform-initializing bool values from double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87120 --- Comment #2 from Vadim Zeitlin --- Thanks and sorry for a duplicate! In my defence -- and just in case there is some problem that could be fixed here -- Bugzilla search seems to be broken: I had searched for "double narrow bool" (without quotes) and even just "narrow bool" before opening the bug, but it hadn't found anything and definitely not the bug 65043.
[Bug c++/85091] New: Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 Bug ID: 85091 Summary: Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vz-gcc at zeitlins dot org Target Milestone: --- Created attachment 43767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43767&action=edit 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
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #1 from Vadim Zeitlin --- Created attachment 43768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43768&action=edit Test script used with delta, also useful for testing
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #3 from Vadim Zeitlin ---
(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'
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #6 from Vadim Zeitlin ---
(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).
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #9 from Vadim Zeitlin --- 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...
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #10 from Vadim Zeitlin --- Created attachment 43770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43770&action=edit Compressed preprocessed test case
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #11 from Vadim Zeitlin --- (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!
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #16 from Vadim Zeitlin ---
(In reply to Alexander Monakov from comment #13)
> It corresponds to
>
> if(!(!std::signbit(bourn_cast( From(0) {
> lmi_test::record_error(); };
> if(!(std::signbit(bourn_cast(-From(0) {
> lmi_test::record_error(); };
>
> in template instantiation test_floating_conversions.
> 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...).
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #21 from Vadim Zeitlin --- Created attachment 43774 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43774&action=edit Reduced test case showing the problem with native g++ 7.3
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #22 from Vadim Zeitlin --- Created attachment 43775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43775&action=edit Compressed preprocessed test case for native Linux gcc 7.3
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091
--- Comment #23 from Vadim Zeitlin ---
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.s2018-03-27 17:11:31.841485730 +
+++ warn.s 2018-03-27 17:11:41.961553404 +
@@ -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.
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #25 from Vadim Zeitlin --- (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'
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #27 from Vadim Zeitlin --- Created attachment 43777 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43777&action=edit Diff between assembly generated with and without the warning options
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #28 from Vadim Zeitlin --- (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.
[Bug c++/85091] Compiler generates different code depending on whether -Wnonnull -Woverloaded-virtual given or not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85091 --- Comment #32 from Vadim Zeitlin --- (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.
[Bug c++/85155] New: Suboptimal error messages when using noexcept(false) on defaulted dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85155
Bug ID: 85155
Summary: Suboptimal error messages when using noexcept(false)
on defaulted dtor
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Consider the following test program:
% cat -n dtor_def_noexcept.cpp
1 struct B {
2 virtual ~B() noexcept(false) = default;
3 };
4
5 struct D : B {
6 virtual ~D() { throw 17; }
7 };
8
9 int main()
10 {
11 try {
12 D d;
13 return 1;
14 } catch (int n) {
15 return n;
16 }
17
18 return 0;
19 }
Compiling it with g++ 8 (gcc version 8.0.1 20180321 (experimental) [trunk
revision 258712] (Debian 8-20180321-1)) results in the following not really
obvious to interpret errors:
% g++-8 -std=c++17 -Wall dtor_def_noexcept.cpp
dtor_def_noexcept.cpp:6:13: error: non-deleted function ‘virtual D::~D()’
virtual ~D() { throw 17; }
^
dtor_def_noexcept.cpp:2:13: error: overriding deleted function ‘virtual
B::~B()’
virtual ~B() noexcept(false) = default;
^
dtor_def_noexcept.cpp: In destructor ‘virtual D::~D()’:
dtor_def_noexcept.cpp:6:18: error: use of deleted function ‘B::~B()’
virtual ~D() { throw 17; }
^
dtor_def_noexcept.cpp:2:13: note: ‘virtual B::~B() noexcept (false)’ is
implicitly deleted because its exception-specification does not match the
implicit exception-specification ‘noexcept’
virtual ~B() noexcept(false) = default;
^
dtor_def_noexcept.cpp:6:26: warning: throw will always call terminate()
[-Wterminate]
virtual ~D() { throw 17; }
^~
dtor_def_noexcept.cpp:6:26: note: in C++11 destructors default to noexcept
dtor_def_noexcept.cpp: In function ‘int main()’:
dtor_def_noexcept.cpp:12:11: error: use of deleted function ‘D::D()’
D d;
^
dtor_def_noexcept.cpp:5:8: note: ‘D::D()’ is implicitly deleted because the
default definition would be ill-formed:
struct D : B {
^
dtor_def_noexcept.cpp:5:8: error: use of deleted function ‘virtual B::~B()’
All of this is correct, of course, but compare it with the error message given
by clang:
% clang-7 -std=c++17 -Wall dtor_def_noexcept.cpp
dtor_def_noexcept.cpp:2:13: error: exception specification of explicitly
defaulted destructor does not match the calculated one
virtual ~B() noexcept(false) = default;
^
1 error generated.
which seems much more clear. It would be nice if gcc error messages could be
improved to emphasize the important one, i.e. that noexcept(false) doesn't
match "= default".
[Bug c++/88012] New: Expected -Wnarrowing not given inside template class method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88012
Bug ID: 88012
Summary: Expected -Wnarrowing not given inside template class
method
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Using Debian 8.2.0-9 the following code compiles without any errors or
warnings:
% cat -n narrowing.cpp
1 using Number = unsigned int;
2
3 template
4 struct S {
5 S() {
6 const Number x = {-1}; (void)x;
7 }
8 };
9
10 int main() {
11 S<1> s;
12 // const Number y = {-1}; (void)y;
13 }
% g++-8 -Wall -c narrowing.cpp
% # i.e. no diagnostic output
Uncommenting the line 12 results in the expected error:
% g++-8 -Wall -c narrowing.cpp
narrowing.cpp: In function ‘int main()’:
narrowing.cpp:12:25: error: narrowing conversion of ‘-1’ from ‘int’ to ‘Number’
{aka ‘unsigned int’} inside { } [-Wnarrowing]
const Number y = {-1}; (void)y;
^
AFAICS the same error should be given for the same code inside S ctor but
somehow the narrowing conversion is not detected there.
Sorry in advance if I'm missing something, but I couldn't find any reason for
this code to be accepted, so reporting it here because it looks like a bug to
me.
FWIW both clang 7 and MSVS 15.7 do report the expected error (and the former
even does it twice for some reason...).
[Bug libstdc++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 Vadim Zeitlin changed: What|Removed |Added CC||vz-gcc at zeitlins dot org --- Comment #3 from Vadim Zeitlin --- BTW, this is unrelated to using grouping in the regex, searching for something as simple as "A.*B" also crashes for input longer than ~27KiB on Linux amd64 with g++ 8.2.0. This makes std::regex simply unusable.
[Bug libstdc++/86164] std::regex crashes when matching long lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 --- Comment #5 from Vadim Zeitlin --- I obviously meant that it makes it unusable in my use case when I can't guarantee that the input is bounded by this (smallish) size.
[Bug libstdc++/88034] New: std::ws doesn't set failbit when the stream is already at EOF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88034
Bug ID: 88034
Summary: std::ws doesn't set failbit when the stream is already
at EOF
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Consider the following test program:
% cat -n stream_ws.cpp
1 #include
2 #include
3
4 int main()
5 {
6 std::istringstream is("123");
7
8 std::cout << "eof/fail/bad bit values: "
9 << is.eofbit << ", "
10 << is.failbit << ", "
11 << is.badbit << "\n";
12
13 std::cout << "Initial state: " << is.rdstate() << "\n";
14
15 int n = -1;
16 is >> n;
17 std::cout << "After reading \"" << n << "\": " << is.rdstate() <<
"\n";
18
19 is >> std::ws;
20 std::cout << "After ws: " << is.rdstate() << "\n";
21 }
With g++ 8.2.0 (Debian 8.2.0-9) the output is:
eof/fail/bad bit values: 2, 4, 1
Initial state: 0
After reading "123": 2
After ws: 2
I.e. calling ws() for the stream which is already at EOF does _not_ set the
failbit at line 19. When the same program is compiled with MSVS 15.9, the
output is:
eof/fail/bad bit values: 1, 2, 4
Initial state: 0
After reading "123": 1
After ws: 3
i.e. it does turn failbit on.
I had originally thought that MSVS behaviour was wrong, but Microsoft engineer
Billy Robert O'Neal III has convincingly explained that it is correct in this
reply to
https://developercommunity.visualstudio.com/content/problem/382896/regression-stdws-incorrectly-sets-failbit-when-the.html
In case this URL is not accessible without Microsoft account, let me quote his
reply here:
--- start quoted reply ---
The current std::ws behavior is correct, and the old behavior was incorrect. If
you look at N4762 (the current C++ working paper) [istream.manip]/2 it says
that ws:
1. Behaves as an unformatted input function.
2. If it stops because it encounters the end, sets eofbit but not failbit.
In particular, the unformatted input function processing happens before
anything about this specific unformatted input operation is applied. The
unformatted input rules are described in [istream.unformatted]/1, starting
with:
> Each unformatted input function begins execution by constructing an object of
> class sentry with the default argument noskipws (second) argument true
The behavior of constructing a sentry is described in [istream::sentry]/2,
which begins with:
> Effects: If is.good() is false, calls is.setstate(failbit)
This ordering is more directly supported by ws' specific wording in
[istream.manip]/2 which says (emphasis mine):
> *After constructing a sentry object* extracts characters as long as the next
> available character c is whitespace or until there are no more characters in
> the sequence.
--- end quoted reply ---
So it looks like ws() is indeed supposed to set failbit here and it's a bug in
libstdc++ that it doesn't. Note that if the stream were not already at EOF
(e.g. if there were a trailing space after "123" in the line 6 of the example
above), then failbit should not, and is not, correctly, being set by both
libstdc++ and MSVS.
[Bug pch/69745] New: Too big precompiled headers seem to result in a silent compilation failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69745 Bug ID: 69745 Summary: Too big precompiled headers seem to result in a silent compilation failure Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: vz-gcc at zeitlins dot org Target Milestone: --- This problem had been previously reported in https://gcc.gnu.org/ml/gcc-help/2011-12/msg00019.html and also http://stackoverflow.com/q/21008274/15275 and we've just run into it again: creating a precompiled header somehow "succeeds" while creating a 0 byte .gch file and the subsequent compilation using it _silently_ fails, i.e. the compiler exits with 1 without any error messages, not even when called with "-v" option. This was observed using the MinGW-w64 version of gcc (see the full specs below), but from the URLs given above it doesn't seem to be MinGW-specific, so I'm reporting it here. Target: i686-w64-mingw32 Configured with: ../../../src/gcc-4.9.1/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw491/i686-491-win32-sjlj-rt_v3-rev3/mingw32 --with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ --enable-shared --enable-static --enable-targets=all --enable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i686 --with-arch-64=nocona --with-tune-32=generic --with-tune-64=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-cloog=/c/mingw491/prerequisites/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='i686-win32-sjlj-rev3, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw491/i686-491-win32-sjlj-rt_v3-rev3/mingw32/opt/include -I/c/mingw491/prerequisites/i686-zlib-static/include -I/c/mingw491/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw491/i686-491-win32-sjlj-rt_v3-rev3/mingw32/opt/include -I/c/mingw491/prerequisites/i686-zlib-static/include -I/c/mingw491/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw491/i686-491-win32-sjlj-rt_v3-rev3/mingw32/opt/lib -L/c/mingw491/prerequisites/i686-zlib-static/lib -L/c/mingw491/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware' Thread model: win32 gcc version 4.9.1 (i686-win32-sjlj-rev3, Built by MinGW-W64 project)
[Bug c++/69777] New: Give a warning when virtual function is devirtualized into a __cxa_pure_virtual call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69777 Bug ID: 69777 Summary: Give a warning when virtual function is devirtualized into a __cxa_pure_virtual call Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vz-gcc at zeitlins dot org Target Milestone: --- For the reasons of compatibility with old compilers which don't define some Windows COM interfaces in their headers, we define these interfaces ourselves, e.g. here: https://github.com/wxWidgets/wxWidgets/blob/WX_3_0_2/src/msw/textentry.cpp#L92 It seems that g++ 4.9.1 is smart enough to deduce that no classes deriving from a class declared in an anonymous namespace can exist outside of the current translation unit and so all IAutoCompleteDropDown pointers can only point to objects of the base IAutoCompleteDropDown type itself and then it proceeds with devirtualizing the calls to its methods to just directly call __cxa_pure_virtual() (i.e. instead of the usual indirect call I just see "call __cxa_pure_virtual" in the x86 disassembly). This is technically correct, of course, and rather impressive, but as the generated code will always crash during run-time, couldn't g++ give a warning when devirtualizing a function into a pure virtual call? This would have helped me a lot when tracking down this crash (which was not totally obvious because the stack was shifted on entry into __cxa_pure_virtual() as the calling code temporarily changed esp register value). I have a small (but still ~50 lines of code) example that can be used to reproduce this behaviour, please let me know if you'd like me to attach it.
[Bug c++/81906] New: Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906
Bug ID: 81906
Summary: Calls to rint() wrongly optimized away starting in g++
6
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Here is a test case:
-- >8 --
#include
#include
#include
int main()
{
printf("--- Test built with gcc %d.%d.%d ---\n",
__GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ );
auto const x = -2.5;
printf("Default round mode : rint(%g)=%g\n", x, std::rint(x));
fesetround(FE_DOWNWARD);
printf("Downward round mode: rint(%g)=%g\n", x, std::rint(x));
return 0;
}
-- >8 --
% g++-7 -O1 -Wall -std=c++11 rint.cpp && ./a.out
--- Test built with gcc 7.1.0 ---
Default round mode : rint(-2.5)=-2
Downward round mode: rint(-2.5)=-2
Replacing -O1 with -O0 yields the expected -3 in the last line, but with -O1
(and -O2 etc), the second call to rint() is completely eliminated as can be
seen by examining the generated assembly.
The same bug is also present in 6.4.0 but not in 5.4.1 nor previous versions,
so it looks like rint() has somehow become marked as pure in gcc 6.
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #3 from Vadim Zeitlin --- (In reply to Andrew Pinski from comment #1) > You want -frounding-math OK, thanks, this does indeed solve my immediate problem. However is it really normal that the compiler behaviour silently (!) changes like this, in backwards incompatible way between versions? I didn't remember seeing this change mentioned in gcc 6 release notes and I just reread them again and can't find it anywhere. I think changes silently breaking existing working (and standard conforming) code should be at the very least prominently documented (and, of course, ideally completely avoided IMO, but this ship has probably already sailed).
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #5 from Vadim Zeitlin --- Yes, I did find this documentation myself in the meanwhile and I agree that you're formally correct, just as gcc developers are formally correct in the long discussion at #34678 (which I really wouldn't want to reopen), but this is not very helpful in practice because this information is completely undiscoverable, i.e. you can only find it if you already know what you're looking for (or enjoy reading compiler optimization options documentation as a hobby, of course). Perhaps you could consider this as a QoI issue, but it would be really great if gcc could give a warning if the code tries to use fesetround() without -frounding-math being on.
[Bug c++/81906] [7/8 Regression] Calls to rint() wrongly optimized away starting in g++ 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 --- Comment #7 from Vadim Zeitlin --- (In reply to Andrew Pinski from comment #6) > https://gcc.gnu.org/wiki/FloatingPointMath Yes, I've seen this, thanks. But do you think it's easily discoverable? I admit I had even seen this page (and knew about -frounding-math option) before running into this problem after an upgrade to gcc 6 and it still wasn't obvious to me that the problem was due to this. You might just think that I'm abnormally clueless, but it seems to me that most people wouldn't be able to realize the source of the problem immediately. So a warning from the compiler would be really helpful IMO.
[Bug libstdc++/78851] New: Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851 Bug ID: 78851 Summary: Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11 Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: vz-gcc at zeitlins dot org Target Milestone: --- It looks like the `long double pow(long double, int)` overload in `` was disabled because of the [DR 550](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3286.html#550) to the C++11 standard which proposed removing these overloads. However [this answer](http://stackoverflow.com/a/5627278/15275) by Howard Hinnant, who submitted the DR in the first place, indicates that these overloads were kept in the final version of the standard and so, AFAICS, shouldn't be disabled for C++11 in the header. One reason for enabling them would be (presumably, I didn't measure it, but #11706 wouldn't have been done without it, I think) to improve performance but another one, which is actually the one that led me to open this bug, is to avoid gratuitous inconsistencies between C++03 and C++11. See also #70299.
[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #2 from Vadim Zeitlin ---
Sorry if I misunderstood but what exactly am I misinterpreting? Looking at the
code (and comment) at
https://github.com/gcc-mirror/gcc/blob/6514c52372bb36e555843b0419d71cf55eda0409/libstdc++-v3/include/c_global/cmath#L395
I thought that this check was supposed to be temporary and could be removed now
that the DR 550 has been resolved without requiring these functions to be
removed. If this is supposed to be the permanent solution then at least the
comment and the defect marker should be removed, shouldn't it?
However it seems to me that it would be better to remove the check. Not because
some code doesn't currently compile, but because the generated code with
-std=c++11 is different (certainly) and suboptimal (probably) than with
-std=c++98. E.g. if you compile and run this program
-- >8 --
#include
#include
void f(long double x) {
int n = -10;
printf("%.40Lf\n", std::pow(x, n));
}
int main() {
f(10.0L);
}
-- >8 --
with gcc version 6.2.0 (i686-win32-sjlj-rev1, Built by MinGW-W64 project),
it will output 0.0100018377930496 in C++98 mode but
0.0100397031165002 in C++11.
Moreover, looking at the generated assembly, in C++98 the result is computed
directly with a few multiplication and a single inverse operation, which seems
to be consistent with __builtin_powil() being used. However in C++11 mode there
is a call to _powl() instead.
Wouldn't it be better to continue to use __builtin_powil() even in C++11? If
not, this should be just closed, of course, but I'd appreciate it if you could
please explain why. TIA!
[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851
--- Comment #4 from Vadim Zeitlin ---
Thanks for the explanation! I didn't realize the template function below was
smart enough to select __builtin_powil() automatically, this is quite
impressive (although it doesn't happen in my particular case...). Also, I
thought the comment was temporary because of the question in it: "What should
the return type of pow(float,int) be?", which seemed to require an answer
("double"), but maybe it's just a figure of style I didn't understand.
In practice, I definitely do not want to use -ffast-math (if anything, I'd
rather use -fexcess-precision=standard but it's, unfortunately, not available
for C++). And I can't change my (well, MinGW-w64's) libm. So, again, in this
particular case, if I understand you correctly, it seems like I simply will
have to live with the (very small, admittedly) loss of precision after
migrating the existing code base from C++98 to C++11, right?
And, to finish, yes, I did see the calculation being inlined when using
-fwhole-program or -flto (although the "assembly" output of the latter is a bit
more difficult to examine) and it happened even in much less trivial examples
and I was duly impressed by it (no kidding). However it still doesn't (and
can't) happen in my real code which is a bit more complicated.
[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851 --- Comment #6 from Vadim Zeitlin --- > One might complain that it only does this transformation when the second > argument is a constant, not for casts of integer variables to long double. Yes, in the light of new information, this is what this bug is really about: due to disabling the old overloads selecting __builtin_powil() explicitly, the results are now (i.e. with C++11) different when an integer constant and an integer variable containing the same value are used, whereas they were the same before. IMHO this is a regression, albeit a minor one, but I can understand if you decide it's not worth doing anything about it -- please just close this bug in this case. Thanks again for your explanations!
[Bug c++/79490] New: ICE when compiling CATCH unit testing framework header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79490
Bug ID: 79490
Summary: ICE when compiling CATCH unit testing framework header
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
I can't provide a self-contained example showing the problem, unfortunately, it
involves a (huge) header implementing the rather popular CATCH unit testing
framework which is available at
https://github.com/philsquared/Catch/releases/download/v1.7.1/catch.hpp
If you do get this header, the problem is easily reproducible however:
% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --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 --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170205 (Debian 6.3.0-6)
% cat -n tst.cpp
1 #define CATCH_CONFIG_MAIN
2 #include
3
4 TEST_CASE("Foo")
5 {
6 }
% g++-6 -c -fsyntax-only -Wall -I. tst.cpp
tst.cpp:6:1: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The problem is, in fact, somewhere inside catch.hpp itself as it can also be
reproduced with just "g++-6 -c -fsyntax-only -Wall -x c++ -DCATCH_CONFIG_MAIN
catch.hpp", but this also gives an unrelated "#pragma system_header ignored"
warnings and doesn't give any extra information anyhow (it just points to the
end of the file).
Again, sorry for the lack of a SSCCE but I failed to find it by trying to
compile various parts of catch.hpp separately. Hopefully this report might
still be useful even in its current state.
[Bug c++/79490] ICE when compiling CATCH unit testing framework header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79490 --- Comment #4 from Vadim Zeitlin --- I thought it would be simpler to use the URL I provided to download the real header rather than downloading and uncompressing the attachment (it had to be compressed due to its size), but, sure, here it is if it can be useful.
[Bug c++/79490] ICE when compiling CATCH unit testing framework header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79490 --- Comment #5 from Vadim Zeitlin --- (In reply to Jonathan Wakely from comment #2) > I can only reproduce this with -fsyntax-only, not when compiling. Oops, you're right, really sorry about not realizing this. I was actually testing warning generation (or not), so was using -fsyntax-only all this time and didn't even think to check without it, but the problem indeed disappears if I remove it. Sorry again, but it's the first time ever I see an ICE appearing only with -fsyntax-only, so I didn't even think about this possibility.
[Bug c++/79490] ICE when compiling CATCH unit testing framework header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79490 --- Comment #3 from Vadim Zeitlin --- Created attachment 40727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40727&action=edit Compressed preprocessed source of a trivial example
[Bug preprocessor/33305] We should warn about empty macro arguments
--- Comment #8 from vz-gcc at zeitlins dot org 2010-03-17 20:05 ---
Sorry for a late follow up but I've just discovered that this change broke
compilation of code using wxWidgets library with "-pedantic-errors -std=c++98"
switches because wxWidgets uses constructions such as (simplified):
#define wxEMPTY_PARAMETER_VALUE /* Fake macro parameter value */
/*
This will be __declspec(dllexport) for some compilers, __attribute__
((visibility("default"))) for other ones and empty in non-shared library build
*/
#define wxEXPORT ...
#define wxDECLARE_SOMETHING(expdecl, name) class expdecl name
#define wxDECLARE_EXPORTED_SOMETHING(name) wxDECLARE_SOMETHING(wxEXPORT, name)
And now, with g++ 4.4.3 from Debian Unstable, this results in "empty macro
arguments are undefined in ISO C90 and ISO C++98" warning/error when wxEXPORT
is empty.
Admittedly, the error may be correct (although to be honest I am not even 100%
sure it is even after rereading 16.3 and 16.3.1 of C++98 several times), but
this use is common and often occurs in other code. Even Boost defines
BOOST_PP_EMPTY in its boost/preprocessor/facilities/empty.hpp and I definitely
saw this many times in other code as well so at the very least there is a
widespread belief in C++ community that such usage is valid.
So ideally I'd like to see gcc behave more leniently when a macro which
expands to an empty value is passed to another macro as argument (as opposed
to directly omitting a macro argument). Failing that, it'd be nice to have a
specific option to turn this behaviour off. Because right now the only choice
seems to be to either disable -pedantic (which would be a really unfortunate
consequence of the change making gcc stricter) or use -std=c++0x which is more
acceptable but still not always desirable.
TIA!
--
vz-gcc at zeitlins dot org changed:
What|Removed |Added
CC| |vz-gcc at zeitlins dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33305
[Bug c++/43601] New: Enormous increase in DLL object files size in 4.5
Hello,
This is not necessarily a bug but I don't know about any other place to
discuss this so I'm reporting it here -- please let me know if I should post
somewhere else.
Anyhow, there seems to be a big problem with building shared C++ libraries
using the typical
class __attribute(dllexport) SomePublicClass
{
public:
... a lot of inline functions without dllexport ...
... and also a lot of non-inline functions ...
};
pattern, wxWidgets being one particular example (but AFAIK there is really
nothing special about wxWidgets here). I've described the problem in details
in http://thread.gmane.org/gmane.comp.gnu.mingw.user/32435 but, basically,
the size of object files produced by mingw32 4.5 has been multiplied by 10
compared to mingw32 4.4 making linking them extremely time consuming and
plainly impossible on machines with modest amounts of RAM.
This seems to be due to the following change in gcc itself (and not
mingw32): http://gcc.gnu.org/viewcvs?view=revision&revision=147799 and I'd
like to know if there is any way to undo its effect. For example, the reply
from Cesar Strauss in the thread above suggested using -fhide-inline-functions
option for this. IMHO ideal would be to revert to the old behaviour at
least until some better approach can be found but any solution would be
nicer than nothing.
Thanks in advance,
VZ
--
Summary: Enormous increase in DLL object files size in 4.5
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
GCC host triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #2 from vz-gcc at zeitlins dot org 2010-03-31 22:04 --- I'm sorry but is this really all you have to say about this? Granted, VS does follow the same rule but the size of object files produced by it was twice less than that of object files produced by gcc _before_ this change and it would seem to me that keeping the size of object files reasonable should have higher precedence than implementing the same behaviour that the Microsoft compiler implements. I don't know how does VS manage to avoid this exponential growth of object files but it demonstrably does while gcc does not. Once again, it's a serious problem for many developers that the size of object files is now 500MB instead of 50MB. Linking a module from 500MB of object files requires a lot of RAM and takes a long time. And, to top it all, the change resulting in this regression (because from the point of view of any gcc user this is how it will look) doesn't bring any tangible benefits -- compatibility with VS notwithstanding. While generating inline methods in DLL might be desirable (although the patch also only speaks about ARM ABI so it doesn't seem like this is really _required_ under x86/x64), it seems strange to completely disregard practical consequences of this lofty idea. Please reconsider your decision, IMO at least an option restoring the old behaviour (with a prominent mention in release notes/changelog) is badly needed. P.S. Personally, I'd also love to understand why exactly was this change considered so desirable at all. But this is just out of my personal curiosity. What really matters is that plenty of people will be simply unable to compile projects which they had no trouble compiling with gcc 4.4. This will result in massive amounts of pain all around. -- vz-gcc at zeitlins dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #5 from vz-gcc at zeitlins dot org 2010-03-31 22:25 --- (In reply to comment #3) > And if the linker is taking a lot of memory, then it is a bug in the linker. > The linker should not take much more memory for functions which are linked > once. Let's admit this. How does it help us in practice? I'm not aware of any plans to optimize the linker to deal with this situation better so the fact remains that the users who could build wxWidgets before won't be able to build it any more. How should we, as its developers, deal with it? Advise them to contribute to binutils development? Somehow I am not sure if this is going to work really well. And I won't even mention that we still have .5GB of object files for each build (and you may need to have several and this is not negligible even nowadays if you use a 80GB SSD). So while the ideal solution might be to avoid the generation of duplicate copies of the functions in all object files or making the linker smarter the fact is that in practice we have a big uncalled for and unwanted regression. With the only justification (for non-ARM platforms) that "it really makes sense". IMNSHO it doesn't make sense to break working builds of many thousands of projects. If you think it does, please explain how should we deal with the inevitable complaints about it when people start switching to gcc 4.5. I frankly have absolutely no idea. I won't insist any more but for one last time: Please, please, please try to view the situation from a gcc user and not gcc developer point of view. Just imagine that you try a new minor release of the compiler and suddenly the build takes much longer or maybe doesn't complete at all because linker runs out of memory. What are you going to do and how are you going to deal with it? And this is not a whimsical scenario but will likely apply to the *majority* of non-trivial C++ projects as many of them use some class library with a lot of inline function inside dllexported classes, be it wxWidgets, Qt or whatever else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #7 from vz-gcc at zeitlins dot org 2010-03-31 22:36 --- (In reply to comment #6) > My view this is a bug in how wxWidgets uses (abuses) dllexport and wanting not > to export inline functions also. Andrew, could you please provide a reasonable alternative to what we do? Also, once again, I'm only aware of this problem because of a bug report of a wxWidgets user but I really don't think there is anything specific to wx here. To the best of my knowledge absolutely nobody is masochistic enough to export every non-inline function in a class separately, all C++ projects supporting Win32 DLL I ever saw used dllexport declaration with the class itself. So, once again, if this is our bug, would you be so kind as to propose a solution? I'm sure many other C++ library developers would be interested in hearing it as well. TIA! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #9 from vz-gcc at zeitlins dot org 2010-04-03 17:15 --- Just to bring some more hard numbers into this discussion, I've installed both 4.4 and 4.5 (in addition to 3.4.5 which I'll use as a kind of baseline) on my own machine (4/8 physical/logical CPUs, 8GB of RAM, Windows 7 64 bits). The results of building the (main) part of wxWidgets with default configure options excluding some third party libraries (jpeg/tiff/regex): - With 3.4.5 (mingw-vista special r3): % time make -sj8 wxcore make -sj8 wxcore 30.29s user 51.71s system 46% cpu 2:55.61 total % du -sh lib 24M lib % du -sSh . 29M . - With 4.4.0 (GCC): % time make -sj8 wxcore make -sj8 wxcore 24.50s user 43.66s system 46% cpu 2:27.97 total % du -sh lib 29M lib % du -sSh . 90M . - With 4.5.0 20100311 (experimental) (GCC): % time make -sj8 wxcore make -sj8 wxcore 33.25s user 57.26s system 6% cpu 23:26.19 total % du -sh lib 80M lib % du -sSh . 554M . - Summary of the sizes of the DLL: % du -h */lib/wxmsw291u_core_gcc_custom.dll 9.2Mwx-mswudll-gcc3.4/lib/wxmsw291u_core_gcc_custom.dll 12M wx-mswudll-gcc4.4/lib/wxmsw291u_core_gcc_custom.dll 47M wx-mswudll-gcc4.5/lib/wxmsw291u_core_gcc_custom.dll The numbers are quite clear and this is without debug information! Notice the drastic reduction in the CPU usage for 4.5: most of the time is clearly spent writing the files (and it's an Intel G2 SSD, things would probably be even worse with a slower disk) and not compiling at all. And while the increase in the size of the object files (they are mostly what makes for "du -sSh" output) is less than what was reported before, the size of the DLLs themselves increased as well (the previous tester couldn't report this as he didn't even manage to link them, of course). And while the compilation time change alone (10 times slower!) makes 4.5 unusable IMO, the change in library sizes is pretty horrible too (almost 4 times larger). I don't know who should handle it but I don't understand how can anybody not see that it is a real problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #11 from vz-gcc at zeitlins dot org 2010-04-03 17:46 --- (In reply to comment #10) > >And while the compilation time change alone > > How did you configure 4.5? Did you use --enable-checking=release ? If not > then the compile time numbers are not comparable at all. Ok, maybe this is the reason then? Because I have, in the version downloaded from http://sourceforge.net/projects/mingw/files/MinGW%20Proposed/gcc-4.5.0_20100311-2/gcc-core-4.5.0_20100311-2-mingw32-bin.tar.lzma/download, the following: % /dev/mingw/4.5.0/bin/gcc -v Using built-in specs. COLLECT_GCC=c:\dev\mingw\4.5.0\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/dev/mingw/4.5.0/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.5.0_20100311/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.0 20100311 (experimental) (GCC) i.e. --enable-checking=release is not there. But can this affect the object file and DLL sizes too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
--- Comment #12 from vz-gcc at zeitlins dot org 2010-04-03 18:17 --- Actually I don't think --enable-checking=release changes anything. I've just tried Cesar Strauss's suggestion to not use __attribute__((dllexport)) in the code at all but use --enable-auto-import linker option. And miraculously this solves all the problems: % ..configure with LDFLAGS=-Wl,--enable-auto-import ... % time make -sj8 wxcore make -sj8 wxcore 18.02s user 34.75s system 34% cpu 2:34.81 total % du -sh lib 26M lib % du -sSh . 24M . % du -h lib/wxmsw291u_core_gcc_custom.dll 8.7Mlib/wxmsw291u_core_gcc_custom.dll To summarize: the compilation time is the same as with 4.4 (7s difference is roughly the same as measurement precision anyhow) and the library size is even smaller than with 3.4.5. So it seems that dllexport attribute should simply never be used with 4.5. I was opposed to using --enable-auto-import initially because it exports too much (there are plenty of symbols which shouldn't be exported in the DLL export table now) but its advantages are such that we're clearly going to do it with 4.5. I still wish somebody could explain me why can auto import work so efficiently but dllexport had to be made unusable like this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
[Bug c++/65974] New: Bogus deprecated-declarations warnings for inline definitions of deprecated virtual methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65974
Bug ID: 65974
Summary: Bogus deprecated-declarations warnings for inline
definitions of deprecated virtual methods
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Consider the following example:
% cat -n deprdecl.cpp
1 struct S {
2 void bar();
3
4 __attribute__((deprecated("use bar() instead.")))
5 virtual void foo();
6 };
7
8 inline void S::foo() { bar(); }
9
10 int main()
11 {
12 return 0;
13 }
% g++-5 -c -Wall deprdecl.cpp
deprdecl.cpp:13:1: warning: 'virtual void S::foo()' is deprecated: use
bar() instead. [-Wdeprecated-declarations]
}
^
deprdecl.cpp:8:13: note: declared here
inline void S::foo() { bar(); }
^
I believe this warning shouldn't appear when the deprecated method is just
being defined and not used. Notice that it indeed does not appear if the method
is either not virtual (i.e. remove "virtual" in line 5) or is defined inline
(i.e. move the body from line 8 to line 5). Nor does it appear with 4.9.
Also notice that the warning location is always the last line of the last
function in the file and has nothing to do with the function it complains
about.
This warning may look like not a big deal, but when compiling my real code it
occurs many thousands times making it impossible to use deprecated attribute
with g++ 5.1.
Compiler information:
% g++-5 -v
Using built-in specs.
COLLECT_GCC=g++-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.1.1-2'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --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=c++11 --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.1.1 (Debian 5.1.1-2)
[Bug c++/20345] Warning on forward declaration of class with __dllexport__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20345
Vadim Zeitlin changed:
What|Removed |Added
CC||vz-gcc at zeitlins dot org
--- Comment #3 from Vadim Zeitlin ---
Surprisingly, after all these years I've realized just now that this bug has
never been actually fixed. The patch that was applied fixes the warnings in the
following code:
struct __attribute__((visibility("default"))) S;
struct __attribute__((visibility("default"))) S { };
but it did nothing for this case:
struct __attribute__((visibility("default"))) S { };
struct __attribute__((visibility("default"))) S;
All versions of g++ I have (4.[6789] and 5.2) still give a warning in this
case, e.g. with 5.2.1 and the code above in the file visibility.cpp:
% g++ -Wall -fvisibility=hidden -c visibility.cpp
visibility.cpp:2:47: warning: type attributes ignored after type is already
defined [-Wattributes]
struct __attribute__((visibility("default"))) S;
^
And, of course, while nobody is going to write code like above manually
intentionally, it's pretty common to encounter it in more complicated cases
when various headers forward declare various classes and can be included in
more or less any order. So in practice using visibility attributes in forward
declarations still remains impossible (without getting flooded with warnings,
that is), although it would be very nice for projects adding visibility support
(yes, in 2015, better late than never...) to the existing code which happily
compiles without any warnings using MSVC.
IMO gcc should verify that the class is either not fully declared with a
different visibility instead of just checking that it's not fully declared at
all.
[Bug c++/61214] [4.9/4.10 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214 Vadim Zeitlin changed: What|Removed |Added CC||vz-gcc at zeitlins dot org --- Comment #4 from Vadim Zeitlin --- I'd be grateful for any workaround suggestions in the meanwhile. We have one patch at http://trac.wxwidgets.org/ticket/16359 but it is rather ugly, so it would be great if someone could propose something better. TIA! BTW, -O3 is not necessary to see the bug, compiling the test case with just -O (or -O1, -O2, ...) is enough, it only links without any optimizations at all.
[Bug c/63402] New: ICE when using log10l() with -m96bit-long-double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63402
Bug ID: 63402
Summary: ICE when using log10l() with -m96bit-long-double
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Created attachment 33603
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33603&action=edit
Preprocessed source corresponding to the code provoking the error
% gcc -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-15'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-15)
% cat tmp.c
#include
void func()
{
log10l(0);
}
% gcc -m96bit-long-double -c tmp.c
tmp.c: In function 'func':
tmp.c:6:1: error: unable to generate reloads for:
}
^
(insn 6 5 7 2 (set (mem:XF (pre_modify:DI (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0]))) [0 S12 A32])
(reg:XF 83)) tmp.c:5 122 {*pushxf}
(expr_list:REG_DEAD (reg:XF 83)
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
tmp.c:6:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3362
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/cckAwyLN.out file, please attach this to
your bugreport.
4.8.3 compiles the same code without any problems.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #63 from Vadim Zeitlin 2011-04-21 14:04:37 UTC --- (In reply to comment #61) > (In reply to comment #59) > > > I review the patch, and found that we can add "-fno-keep-inline-dllexport" > > to > > the compiler option, and then, the compiler and linker stage works well. But > > the wxWidgets release mono dll's size is so large.(about 17M) > > In newer versions of GCC there is also a lot more debug info and Dwarf-2 > exception table data that didn't used to be there. FWIW wxWidgets hardly uses exceptions (it has only two try/catch blocks that basically rethrow an exception thrown by user code but the library doesn't throw any exceptions itself). It does/can be configured to use the standard containers which do use exceptions however.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #29 from Vadim Zeitlin 2010-09-26 22:09:16 UTC --- Thanks Cesar for your analysis, I was doing the same thing but you beat me to it. Anyhow, I can confirm your results, i.e. that the increase in size is first and foremost due to the inflation of the total number of sections (which is multiplied roughly by 10) as well as the changes to the .eh_frame and .drectve sections sizes. I compared the object files for 4.4, 4.5 and 4.5 when using auto-export, i.e. not using "__attribute__((dllexport))" on exported classes declarations. The typical results (the exact numbers are, of course, different for each object file but the trend is the same) are: 4.4 4.5 4.5-autoexp -- file size151K 1.2M 87K # sections371 314585 .text size 1688817264 24856 .eh_frame40046442416 .drectve 8620 113232 0 The difference in number of sections seems to correspond to the fact that 4.5 now generates one section per method of any exported class used by the object file instead of just one section per class as in 4.4. Please let me know if I can provide any other information.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #31 from Vadim Zeitlin 2010-09-27 22:42:55 UTC --- (In reply to comment #30) > Sorry, but I do not completely agree with this assessment. If you run > > objdump -h | c++filt > > you will see that 4.4 still generates one section per method, not per class > (the name of the method is reveled by c++filt). This is somewhat off topic but unfortunately (MinGW) c++filt doesn't work for me, e.g.: % echo '.text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv'|/mingw/bin/c++filt.exe .text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv I don't know what could be wrong with it but, anyhow, you're right, of course, and I was wrong (I managed to look at the classes whose methods were not used by the object file I was checking...), sorry for misinformation and thanks for correcting it! > In my view, the difference is only that 4.5 emits a section for every inline > method of every dllexported class in sight. 4.4 only emitted those which the > code actually needed. Yes, exactly. > Why there is one section for each emitted inline method? Excellent question which I'm unfortunately totally unable to answer.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #35 from Vadim Zeitlin 2010-10-14 15:24:57 UTC --- (In reply to comment #34) > (In reply to comment #33) > > Because of this issue, I have been using GCC4.4.x, but do not want to > > upgrade > > to 4.5.x. > > Why this issue can not been confirmed? > > The way I read it, this is not a bug as Microsoft Visual Studio acts the same > way (when their precompiled headers are not included). This reply either demonstrates complete misunderstanding of the issue or is deliberate misinformation. To set the record straight, Microsoft Visual Studio absolutely doesn't act the same way and doesn't generate neither object files nor DLLs of this ridiculous size, whether precompiled headers are used or not. Besides, the issue does arise when precompiled headers _are_ used with gcc. Continuing to justify what is clearly and uncontroversially a bad regression in gcc by "compatibility with MSVC" which never suffered from this problem and refusing to even acknowledge the issue, let alone revert the breakage, does no good whatsoever neither to the gcc project nor to its image.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #37 from Vadim Zeitlin 2010-10-14 15:42:59 UTC --- Created attachment 22037 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22037 appbase.cpp file from wxWidgets compiled with g++ 4.4
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #38 from Vadim Zeitlin 2010-10-14 15:44:23 UTC --- Created attachment 22038 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22038 appbase.cpp file from wxWidgets compiled with g++ 4.5
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Vadim Zeitlin changed: What|Removed |Added Attachment #22037|0 |1 is obsolete|| --- Comment #39 from Vadim Zeitlin 2010-10-14 15:45:41 UTC --- Created attachment 22039 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22039 appbase.cpp file from wxWidgets compiled with g++ 4.4 Replaces previous file which was uncompressed, sorry for the double post.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #40 from Vadim Zeitlin 2010-10-14 15:47:36 UTC --- (In reply to comment #36) > could Vadim and/or Cesar please add > some of the object files we've been discussing as attachments to this bug > report, so that we can all take a close look at why gcc's files are so much > bigger? I attached 4.4 and 4.5 versions and can also add 3.4 one as well as MSVC9 build of the same file, please let me know if this could be useful. Thanks!
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #42 from Vadim Zeitlin 2010-10-14 16:01:20 UTC --- Created attachment 22040 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22040 appbase.cpp file from wxWidgets compiled with g++ 3.4
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #43 from Vadim Zeitlin 2010-10-14 16:01:55 UTC --- Created attachment 22041 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22041 appbase.cpp file from wxWidgets compiled with MSVC 9 (a.k.a. 2008)
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Vadim Zeitlin changed: What|Removed |Added Attachment #22041|0 |1 is obsolete|| --- Comment #44 from Vadim Zeitlin 2010-10-14 16:05:02 UTC --- Created attachment 22042 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22042 appbase.cpp file from wxWidgets compiled with MSVC 9 (a.k.a. 2008) Oops, sorry for another double post, I accidentally took a non-DLL version of the file the first time, this one is the right one.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #45 from Vadim Zeitlin 2010-10-14
16:12:00 UTC ---
Here are the files.
Notice that about half of the size of the MSVC object file is taken by debug
information ("/Zi" option was used when compiling it) while all gcc versions
contain no debug information at all. More details about the file contents can
be obtained using dumpbin Microsoft utility which I'd be glad to run for you if
you don't have it. Here is just an overview for now:
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file build/msw/vc_mswudll/base/appbase.obj
File Type: COFF OBJECT
Summary
4 .CRT$XCU
29 .bss
3E9 .data
345D0 .debug$S
50 .debug$T
68D2 .drectve
E67 .rdata
8BC .rdata$r
178 .sxdata
8A34 .text
13D3 .text$x
18 .text$yc
14 .text$yd
14B4 .xdata$x
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #46 from Vadim Zeitlin 2010-10-14 17:09:05 UTC --- Another data point after having a closer look at .drectve section in all of the files: as previously noticed, 4.4 generates "-export" directives for 180 symbols while 4.5 generates them for 2724 symbols. MSVC however records "/EXPORT" directives for 526 symbols when using PCH and 3764 symbols when not using PCH. In the latter case the size of the object file also inflates to 3.1MB (with all sections growing, not just the ".drectve" one). So while it's difficult to compare the sets of symbols because of the different name mangling schemes used, it does seem that MSVC generates these directives for all of the class members used, as 4.5 does and unlike 4.4. However many classes included in 4.5 don't appear at all in the MSVC file when using PCH resulting in much more reasonable object file sizes. It still remains that the size of the DLL produced by MSVC is very small compared to gcc. E.g. the wxbase DLL is 1.9MB with MSVC and 6.5MB with gcc 4.4 while the entire wxcore DLL is just 3.9MB with MSVC and 11.6MB with gcc 4.4, without even mentioning 4.5 numbers. This is without using any "fancy" optimizations (i.e. "/LG" and/or "/LTCG" MSVC options). And the size of the DLL does _not_ depend on whether PCH was used or not (although the compilation speed and disk consumption of the object files definitely do, by a factor of more than 10 for both of them). So maybe the new 4.5 behaviour is indeed more MSVC-like. But MSVC seems to avoid generating ~80% of the stuff gcc creates when using PCH and its linker still creates reasonably sized files in reasonable time even when the object files contain a lot of redundant sections. But using MSVC strategy for gcc currently is simply disastrous and I still don't understand why shouldn't the change of r147799 be reverted now and be reapplied later when PCH handling is improved and/or the linker is capable of dealing with it. If this is not a regression I honestly don't know what counts as one.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #48 from Vadim Zeitlin 2010-10-14 17:29:46 UTC --- (In reply to comment #47) > One should note that GCC's implementation of PCH is way different from > MSVC's. > So comparing with PCH is not the correct thing to do really. I understand this in theory but in practice nobody uses MSVC without PCH (and I guess by now most people use PCH with gcc as well but this doesn't change anything here, of course, as after this change gcc is unusable, with or without PCH). Anyhow, notice that MSVC still manages to produce correctly-sized DLLs even without using PCH. And in any case while comparing with MSVC may be interesting, surely the most urgent goal is to fix gcc to actually work and not to make it more similar to MSVC at the price of breaking it completely? I just can't wrap my head around your arguments, everything you say may be correct (except comment 6) but how do you deduce from it that the current situation is fine and don't even want to acknowledge this change for a bug and regression that it is is beyond me.
[Bug c++/26329] New: confusing error message for ambiguous namespaces declarations
If there is an ambiguity with the namespace resolution, the 3.4/4.0 compiler
error message is very unclear while it was much better in 3.3 (and even 2.95):
% cat ns.cpp
namespace NsOut { namespace NsIn { struct Foo { }; } }
namespace NsIn { struct Foo { }; }
using namespace NsOut;
void foo(NsIn::Foo *);
% g++-3.3 -fsyntax-only -c ns.cpp
ns.cpp:7: error: use of `NsIn' is ambiguous
ns.cpp:3: error: first declared as `NsIn' here
ns.cpp:1: error: also declared as `NsOut::NsIn' here
ns.cpp:7: error: syntax error before `::' token
[ok so far]
% g++-3.4 -fsyntax-only -c ns.cpp
ns.cpp:7: error: `NsIn' has not been declared
ns.cpp:7: error: variable or field `foo' declared void
ns.cpp:7: error: `Foo' was not declared in this scope
ns.cpp:7: error: expected primary-expression before ')' token
[why "has not been declared"?]
% g++-4.0 -fsyntax-only -c ns.cpp
ns.cpp:7: error: 'NsIn' has not been declared
ns.cpp:7: error: variable or field 'foo' declared void
ns.cpp:7: error: 'Foo' was not declared in this scope
ns.cpp:7: error: expected primary-expression before ')' token
[same again]
The same problem occurs with a namespace alias, i.e. if you replace the line 3
of ns.cpp with "namespace NsIn = NsOut::NsIn;". While it's quite clear in this
example, it took a lot of time to find what the problem was in the real
program.
Tested with
gcc version 3.3.6 (Debian 1:3.3.6-10)
gcc version 3.4.5 (Debian 3.4.5-1)
gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
--
Summary: confusing error message for ambiguous namespaces
declarations
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26329
[Bug regression/26355] New: defining static members of specialized template classes doesn't work
I'm not 100% sure if this is a compiler bug or a bug in my code but I think
that what I'm trying to do should be valid according to 14.7.5/4 of the C++
Standard. Please consider the following example:
% cat stsp.cpp
enum V { V1, V2, V3 };
template struct Data { static int Value; };
int Data::Value;
extern int GetIt() { return Data::Value; }
Compiling this with g++ 4.0 or 4.1 doesn't work:
% g++-4.0 -c -Wall stsp.cpp
stsp.cpp:5: error: too few template-parameter-lists
% g++-4.1 -c -Wall stsp.cpp
stsp.cpp:5: error: too few template-parameter-lists
While it works with all the previous versions (down to 2.95!).
g++4 does accept the explicit specialization of the static member if you
prepend "template <>" to "Data::Value" line which, IMHO, wrong too. But it
doesn't define the symbol in the object file in this case.
If this is really not allowed then it would be nice to make the error message
more clear.
--
Summary: defining static members of specialized template classes
doesn't work
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vz-gcc at zeitlins dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26355
[Bug regression/26355] defining static members of specialized template classes doesn't work
--- Comment #3 from vz-gcc at zeitlins dot org 2006-02-18 22:47 ---
First, thanks a lot Andrew for your lightning fast reply, this is really
amazing -- and incredibly helpful!
Second, really sorry, rereading the explicit specialization section once again
I see that I was indeed wrong and that "template <>" is really needed.
Third, unfortunately PR 11930 does not help with my test case:
% cat -n stsp.cpp
1 enum V { V1, V2, V3 };
2
3 template struct Data { static int Value; };
4
5 template struct Data;
6
7 template <> int Data::Value;
8
9 int main() { return Data::Value; }
% g++-4.0 -o stsp -Wall stsp.cpp
/tmp/ccywXRfg.o: In function `main':stsp.cpp:(.text+0x1d): undefined reference
to `Data<(V)0>::Value'
collect2: ld returned 1 exit status
It looks like the compiler interprets the line 7 as declaration and not
definition? If I add an initializer (i.e. change the line to end with "Value =
17" or "Value(17)") then it works just fine. Unfortunately in the real code the
static member is a class and, worse, a class with only default ctor so I can't
use "Value()" (which would be parsed as a function declaration) to force
recognizing it such.
Sorry in advance if I'm missing something again but it doesn't seem normal that
no definition is emitted for the example above, does it?
Thanks again for your help!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26355
[Bug regression/26355] defining static members of specialized template classes doesn't work
--- Comment #5 from vz-gcc at zeitlins dot org 2006-02-19 16:50 ---
In reply to comment 4: I do realize that adding an initializer fixes the
problem. But what to do if the static member is an object of a class which only
has a default ctor? E.g.
enum V { V1, V2, V3 };
struct Int { Int() : x(0) { } int x; };
template struct Data { static Int Value; };
template struct Data;
template <> Int Data::Value;
int main() { return Data::Value.x; }
How to fix this example to link?
Note that the above (with or without the explicit instantiation) is just fine
for Intel and Comeau compilers (and g++ < 4 of course) but not g++ 4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26355
[Bug preprocessor/28810] gcc -MD -MP doesn't add phony rule for source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28810 Vadim Zeitlin changed: What|Removed |Added CC||vz-gcc at zeitlins dot org --- Comment #4 from Vadim Zeitlin --- I don't understand the rationale of comment:1. When a source file is renamed (and not removed), it makes perfect sense to still have the object file in a makefile. E.g. I'm using a build system which generates GNUmakefiles with rules of the form libname_file.o: subdir/file.cpp $(CXX) -MD -MP ... -o $@ $< and if file.cpp is moved to subdir2/file.cpp, the build gets broken because the existing libname_file.d has a dependency on subdir/file.cpp but no dummy rule for this file. It's obviously not going to solve my problem now, but I think it would be great to remove the existing exception from -MP or, perhaps, add some new -MPP switch.
[Bug c++/71867] New: Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867
Bug ID: 71867
Summary: Optimizer generates code dereferencing a null pointer
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
First of all, I'd like to say that I'm reporting this bug because it looks like
a rather bad problem in gcc to me, but I don't have any simple example
reproducing it because I couldn't produce one even in spite of spending some
time on this, so please feel free to close if you're not interested in
debugging this.
The problem in question is that, according to the original bug report (see
http://trac.wxwidgets.org/ticket/17483), code generated by gcc -O2 for this
method (omitting parts of the class, you can see the full version at
https://github.com/wxWidgets/wxWidgets/blob/v3.1.0/include/wx/rtti.h#L86):
class wxClassInfo {
public:
...
bool IsKindOf(const wxClassInfo *info) const
{
return info != 0 &&
( info == this ||
( m_baseInfo1 && m_baseInfo1->IsKindOf(info) ) ||
( m_baseInfo2 && m_baseInfo2->IsKindOf(info) ) );
}
private:
const wxClassInfo *m_baseInfo1;
const wxClassInfo *m_baseInfo2;
};
generates the code which crashes during run-time because
m_baseInfo1->IsKindOf() call is done even when m_baseInfo1 is null. The crash
doesn't happen with -O0 or even with an attribute optimize("O0") applied to
just this function.
Unfortunately, extracting this class and compiling just it with -O2 doesn't
show the problem, there must be something else triggering it and making the
optimizer assume that the pointers can never be null (which is true for almost
all classes, but not for the root class of the hierarchy, which is constructed
with null base class info pointer). And, again, I tried, but I couldn't find
what it was.
Rewriting the expression as a sequence of statements, as done in
https://github.com/wxWidgets/wxWidgets/commit/aa3acfdd15eff1519a41b48a2babe4cba75660f9,
fixes the bug, so from my point of view this particular problem is solved, but,
again, I find it rather worrying if the optimizer can miscompile quite
straightforward code like above, so I still wanted to report it. If you'd like
to look at it, please get any version of wxWidgets prior to the commit above
(e.g. 3.1.0 release) and build it under Windows. Of course, please let me know
if you need any more information -- other than a simple reproducible test case
which I, unfortunately, just can't make.
Thanks in advance!
[Bug tree-optimization/71867] Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867 --- Comment #2 from Vadim Zeitlin --- I'll try to add the preprocessed code a bit later, but, FWIW, I can already say that there is no macro trickery whatsoever in this code itself.
[Bug c/26542] bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*'
--- Comment #7 from vz-gcc at zeitlins dot org 2006-12-08 11:07 --- Just for my personal education, could you please tell which target(s) pass "char *" differently from "void *" in this context? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26542
[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #23 from Vadim Zeitlin --- (In reply to Eric Botcazou from comment #22) > Thanks for reporting the problem. Thanks a lot for fixing it so quickly! And I've also appreciated the explanation in the commit message, it's nice to understand what the problem really was, even if it's fixed now.
[Bug c++/99234] New: Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234
Bug ID: 99234
Summary: Regression: wrong result for 1.0/3.0 when
-fno-omit-frame-pointer -frounding-math used together
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
Please see the following test case minimized by cvise:
-- >8 --
// When compiled with
//
// g++ -Wall -O2 -fno-omit-frame-pointer -frounding-math test.cpp
//
// using x86_64-w64-mingw32-g++ version 10-win32 20210110 (GCC) from Debian
// g++-mingw-w64-x86-64-win32 10.2.1-6+24.1 package or gcc version 10.2.0
// (Rev6, Built by MSYS2 project) this test case computes a wrong result for
// the second division below.
#include
#include
#include
#include
double numeric_io_cast(const std::string& from)
{
char* rendptr;
double value = std::strtod(from.c_str(), &rendptr);
if('\0' != *rendptr)
throw std::logic_error("");
return value;
}
double numeric_io_cast(char const* from)
{
return numeric_io_cast(std::string(from));
}
int main(int, char* [])
{
std::printf("1.0 / 3.0 = %f\n", 1.0 / 3.0); // => 1.0 / 3.0 = 0.33
try {
numeric_io_cast("");
numeric_io_cast("1e");
} catch(std::logic_error const&) {
}
std::printf("1.0 / 3.0 = %f\n", 1.0 / 3.0); // => 1.0 / 3.0 = 0.00
return 0;
}
-- >8 --
The comments in the code indicate the output produced when using MinGW gcc
10.2. The same code worked fine with different versions of gcc 8 and also works
when using native Linux gcc 10.2.1. It always works fine for 32 bit compiler
(which produces completely different code).
Also, just in case it can be helpful (even though I'm afraid it isn't...), it
the problem disappears when using the 10.x compilers mentioned above if either
of the following is true:
1. You use -O0 or -O3 (but it gives the same results with -O1 and -O2).
2. You don't use -fno-omit-frame-pointer.
3. You don't use -frounding-math.
4. You use 2.0, 4.0 or 8.0 instead of 3.0 (but it fails similarly with 5.0, 7.0
etc).
5. You use something other than std::logic_error (or a class derived from it
such as std::invalid_argument), i.e. throwing a simple class, even deriving
from std::exception, makes the problem disappear.
6. You remove the (clearly unnecessary!) numeric_io_cast() overload taking
char* and rely on implicit conversion doing the same thing.
Looking at the generated code the problem seems relatively clear: the compiler
assumes the xmm register containing the result is preserved when it's
clobbered. But I have no idea where to start looking in gcc to find why does it
assume this and how to fix this.
I'd also like to note that IMO it's a pretty bad bug because it silently
results in completely wrong behaviour in the code which worked perfectly well
before and, of course, it took quite some time before we actually found what
was going on and why did the tests suddenly start failing in "impossible" ways
after upgrading to MinGW 10.
[Bug target/99234] Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #2 from Vadim Zeitlin --- Created attachment 50250 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50250&action=edit Compressed output of the preprocessor (-E)
[Bug target/99234] Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #3 from Vadim Zeitlin --- Created attachment 50251 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50251&action=edit File created by -fdump-tree-optimized
[Bug target/99234] Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #4 from Vadim Zeitlin --- Created attachment 50252 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50252&action=edit Assembly output (-S)
[Bug target/99234] Regression: wrong result for 1.0/3.0 when -fno-omit-frame-pointer -frounding-math used together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #5 from Vadim Zeitlin --- > Works fine on x86_64-linux. Yes, I mentioned this :-/ > Can you attach preprocessed source (most developers don't have access to > Windows) If you can install MinGW cross-compiler and Wine, you don't need Windows to reproduce this, but here is the (compressed, as it's unfortunately quite big after the standard headers expansion) preprocessed output. > and -fdump-tree-optimized dump Also attached. > and assembly you get? Attached too. The register I mentioned in the original message is xmm6. Thanks for looking at this!
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 Vadim Zeitlin changed: What|Removed |Added CC||vz-gcc at zeitlins dot org --- Comment #8 from Vadim Zeitlin --- For the record: with gcc 11 this bug now affects the existing code using pragmas to locally suppress -Wsuggest-override, i.e. the warning is not suppressed any longer, even though it used to work in all versions since gcc 5, so not only this bug is still present, but it got worse in the latest version.
[Bug c++/106434] New: Spurious -Wnull-dereference when using std::unique_copy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106434
Bug ID: 106434
Summary: Spurious -Wnull-dereference when using
std::unique_copy()
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
The following simple example shows the problem with g++ 12, which didn't exist
with the previous versions:
% g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 12.1.0-7'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--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 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-aYRw0H/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-aYRw0H/gcc-12-12.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Debian 12.1.0-7)
% cat unique_copy.cpp
#include
#include
#include
#include
std::vector const& parms();
int main() {
std::vector all;
for(auto const& i : parms()) {
all.push_back(i);
}
std::vector unique;
std::insert_iterator iin(unique, unique.begin()); // EXCHANGE THESE LINES
std::sort(all.begin(), all.end());// TO SUPPRESS THE
WARNING
std::unique_copy(all.begin(), all.end(), iin);
}
% g++ -std=c++20 -c -O2 -Wnull-dereference unique_copy.cpp
In file included from /usr/include/c++/12/string:53,
from /usr/include/c++/12/bits/locale_classes.h:40,
from /usr/include/c++/12/bits/ios_base.h:41,
from /usr/include/c++/12/streambuf:41,
from /usr/include/c++/12/bits/streambuf_iterator.h:35,
from /usr/include/c++/12/iterator:66,
from unique_copy.cpp:2:
In constructor ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_Alloc_hider::_Alloc_hider(std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::pointer, _Alloc&&) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(const std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>&) [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator ’ at /usr/include/c++/12/bits/basic_string.h:540:9,
inlined from ‘constexpr decltype (::new(void*(0)) _Tp)
std::construct_at(_Tp*, _Args&& ...) [with _Tp = __cxx11::basic_string;
_Args = {const __cxx11::basic_string, allocator
>&}]’ at /usr/include/c++/12/bits/stl_construct.h:97:14,
inlined from ‘static constexpr void
std::allocator_traits >::construct(allocator_type&,
_Up*, _Args&& ...) [with _Up = std::__cxx11::basic_string; _Args = {const
std::__cxx11::basic_string, std::allocator
>&}; _Tp = std::__cxx11::basic_string]’ at
/usr/include/c++/12/bits/alloc_traits.h:518:21,
inlined from ‘constexpr std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::insert(const_iterator, const value_type&) [with _Tp =
std::__cxx11::basic_string; _Alloc =
std::allocator >]’ at
/usr/include/c++/12/bits/vector.tcc:145:30,
inlined from ‘constexpr std::insert_iterator<_Container>&
std::insert_iterator<_Container>::operator=(const typename
_Container::value_type&) [with _Container =
std::vector >]’ at
/usr/include/c++/12/bits/stl_iterator.h:964:26,
inlined from ‘constexpr _OutputIterator
std::__unique_copy(_ForwardIterator, _ForwardIterator, _OutputIterator,
_BinaryPredicate, forward_iterator_tag, output_iterator_tag) [with
_ForwardIterator = __gnu_cxx::__normal_iterator<__cxx11::basic_string*,
vector<__cxx11::basic_string > >; _OutputIterator =
inser
[Bug libstdc++/106664] std::valarray::resize(0): spurious -Walloc-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106664 --- Comment #2 from Vadim Zeitlin --- FWIW I think it's a rather useful warning as allocating 0 bytes is rarely intentional, i.e. I haven't seen any false positive occurrences of this warning in my own code. And in valarray case, it indicates a small but real problem too: empty valarray shouldn't allocate memory at all, not allocate 0 bytes. And AFAICS it would be pretty trivial to fix the warning in valarray code (but I have never contributed to libstdc++ so I don't know how to do it and don't volunteer to do it neither).
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578
--- Comment #10 from Vadim Zeitlin ---
There definitely was a change in behaviour in gcc 11 because I had to make this
change
https://github.com/wxWidgets/wxWidgets/commit/95c98a0b5ff71caca6654327bf341719c6587766
to avoid getting warnings with it that we didn't get with the previous
versions.
The idea there is that we define some macros whose expansion contains
declarations of overridden virtual functions, which inevitably results in
-Wsuggest-override when used in user classes using or not using "override" for
their other functions, so we have to disable this warning locally.
wxWARNING_SUPPRESS_MISSING_OVERRIDE, which expands to
_Pragma("GCC diagnostic push")
_Pragma("GCC diagnostic ignored \"-Wsuggest-override\"")
worked for this until gcc 11 but not with it.
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 --- Comment #12 from Vadim Zeitlin --- Thanks for looking at this! I'm happy to hear that the problem is fixed in 11.2, but I'm probably not going to change our code anyhow, especially as we're going to finally drop support for C++98 very soon and so will be able to just use "override" unconditionally anyhow. I.e. from my point of view there is no real problem any more, I just replied here to give more information about the problem in case it could be useful.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #13 from Vadim Zeitlin --- (In reply to Jonathan Wakely from comment #11) > (In reply to Jonathan Wakely from comment #8) > > Is this still an issue in 2022? > > > > Using a mingw-w64 cross-compiler and running under Wine I get: > > > > CLOCK_REALTIME: 0,100 > > CLOCK_MONOTONIC: 0,100 > > > > Is that just because I'm using Wine not real Windows? > > I still want an answer to this question though. FWIW I can confirm that running the program above compiled with gcc-mingw-w64 12.2.0-14+25.2 from Debian 12 under Windows 10.0.19044.3803 produces exactly the same output.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #16 from Vadim Zeitlin ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jonathan Wakely from comment #14)
> > Or maybe the testcase makes invalid assumptions and isn't really measuring
> > what it thinks it's measuring?
>
> e.g. maybe clock_getres says 100ns even though the clocks aren't really that
> precise.
No, the clock is not precise. The original test case
int main() {
for (unsigned long long size = 1; size < 1000; size *= 10) {
auto start = std::chrono::high_resolution_clock::now();
std::vector v(size, 42);
auto end = std::chrono::high_resolution_clock::now();
auto elapsed = end - start;
std::cout << size << ": " << elapsed.count() << '\n';
}
}
outputs the following under Linux
% ./a.out
1: 436
10: 114
100: 80
1000: 1019
1: 9499
10: 104850
100: 686436
and this under Windows:
% ./a.exe
1: 1000
10: 0
100: 0
1000: 1000
1: 9000
10: 69000
100: 523000
