[Bug c++/90992] New: -Wnoexcept produce false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90992
Bug ID: 90992
Summary: -Wnoexcept produce false positive
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adrien.hamelin+gcc at gmail dot com
Target Milestone: ---
Created attachment 46516
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46516&action=edit
Minimal case to reproduce, compile with "g++ -Wnoexcept gcc_bug.cpp"
We seem to have found a bug in g++, it generates a false warning that a
constructor could be noexcept when it has a member that is not.
See the attached file for a minimal test case, compiled with "g++ -Wnoexcept
gcc_bug.cpp", it generates:
/usr/include/c++/9/ext/new_allocator.h: In instantiation of ‘void
__gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
Automatic; _Args = {int}; _Tp = Automatic]’:
/usr/include/c++/9/bits/alloc_traits.h:482:2: required from ‘static void
std::allocator_traits
>::construct(std::allocator_traits >::allocator_type&,
_Up*, _Args&& ...) [with _Up = Automatic; _Args = {int}; _Tp = Automatic;
std::allocator_traits >::allocator_type =
std::allocator]’
/usr/include/c++/9/bits/vector.tcc:115:30: required from ‘void
std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {int}; _Tp =
Automatic; _Alloc = std::allocator]’
gcc_bug.cpp:25:25: required from here
gcc_bug.cpp:16:5: warning: but ‘Automatic::Automatic(size_t)’ does not throw;
perhaps it should be declared ‘noexcept’ [-Wnoexcept]
16 | Automatic(size_t bla) : Bla(bla) {};
| ^
gcc_bug.cpp:14:7: warning: but ‘Automatic::~Automatic()’ does not throw;
perhaps it should be declared ‘noexcept’ [-Wnoexcept]
14 | class Automatic {
| ^
In our case (in a more complex code base), the warning happens on the
automatically generated move constructor, which is not noexcept as it should
but still generates that warning. In our case also just declaring the move
constructor as default seems to hide the warning, though it doesn't in the
minimal test case I provide.
[Bug c++/61597] New: Unexpected behavior at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597 Bug ID: 61597 Summary: Unexpected behavior at runtime Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: adrien.hamelin+gcc at gmail dot com When compiling the code visible at the link at the bottom, the compiler eat it fine and produce an executable, but it doesn't work. The problem is in the std::iota function present in the main. For the second parameter, "begin + size", the operator+ is effectively called and works as expected, but the result parameter given to the function is "begin" unmodified (checked with gdb in without optimizations). The code compiles and runs fine with Visual 13 and Clang 3.4.2. It also runs fine if i use a "std::vector" instead of my "Memory::Array", or if i use "std::next(begin, size)". I tried to remove all unnecessary code to show the bug. The option given to gcc are shown in the link, but it also doesn't work with no optimizations. I had the bug on Mingw64 with gcc4.9 on Windows 7 64, and also on the website. http://coliru.stacked-crooked.com/a/d6fde84b59d4526a
[Bug c++/61597] Unexpected behavior at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597 --- Comment #2 from Adrien Hamelin --- Created attachment 33000 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33000&action=edit Preprocessed file compressed in 7z I compressed the file to match the 1000KB criteria, but this is the preprocessed file.
[Bug c++/61597] Unexpected behavior at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597 --- Comment #5 from Adrien Hamelin --- It's a type i created to be able to store data that does not fit in ram, with some streaming with the hard drive. But i removed most of it to simplify the problem search for you, even if i did not think of everything.
[Bug c++/61597] Unexpected behavior at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597 --- Comment #6 from Adrien Hamelin --- I also wanted to say, my code may be not optimal or may be done in an easier way or else (and if you have comments on it i'm ok with that), but what i think what is the most important here is that it seems to trigger a bug from gcc. Thus i wanted to report it to inform you of it, because it may be more critical in other people codes. I'm sorry that i was not able to pinpoint the (supposed) bug more precisely.
[Bug c++/61597] Unexpected behavior at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597 Adrien Hamelin changed: What|Removed |Added Attachment #33000|0 |1 is obsolete|| --- Comment #8 from Adrien Hamelin --- Created attachment 33002 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33002&action=edit Preprocessed file Effectively the problem can be showed with much less code lines. I just did a custom iterator to show the problem (and removed my own array). The problem comes from line 45. If the function takes a copy, it does not work but if it takes a reference and do the copy inside (as shown line 52) it does work. Once again it works fine with Visual 2013. The new code : http://coliru.stacked-crooked.com/a/e33afe532e7f1e55
[Bug c++/61597] Unexpected behavior at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597 Adrien Hamelin changed: What|Removed |Added Attachment #33002|0 |1 is obsolete|| --- Comment #9 from Adrien Hamelin --- Created attachment 33003 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33003&action=edit Preprocessed file Sorry to do such mutliple post, this one should be the last, i removed the custom iterator - it has nothing to do with the bug. So same as before, the function line 10 does not work when it takes a copy parameter, and the function line 17 does work when it takes the parameter as reference. The new code: http://coliru.stacked-crooked.com/a/9a724fdda9ef1d06
[Bug c++/61597] Unexpected behavior at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597 --- Comment #13 from Adrien Hamelin --- I'm sorry that i made you lose your time :-( I thought that kind of code would trigger a warning though.
