[Bug c/111808] [C23] constexpr with excess precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111808 Laurent Rineau changed: What|Removed |Added CC||Laurent.Rineau__gcc@normale ||sup.org --- Comment #4 from Laurent Rineau --- Maybe `constexpr` evaluation of floating point expressions could be computed using MPFR, instead of using the local hardware.
[Bug c++/96862] -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 --- Comment #4 from Laurent Rineau --- At the compiler level, I do not think the bug is related to `-std=c++2a`. That flags was there only to trigger the bug from the recent versions of libstdc++ since: commit e6c76f0d3327bf00c96f5a63961c1d5ab77512db Author: Patrick Palka Date: Wed Aug 19 09:12:55 2020 -0400
[Bug libstdc++/96862] New: -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96862 Bug ID: 96862 Summary: -frounding-math -std=c++2a error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: Laurent.Rineau__gcc at normalesup dot org Target Milestone: --- Commit e6c76f0d3327bf00c96f5a63961c1d5ab77512db introduced a compilation error with `-frounding-math -std=c++2a`: it seems that, with `-frounding-math` a floating-point expression cannot be constexpr. # cat test.cpp #include # g++ --version g++ (GCC) 11.0.0 20200828 (experimental) Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # g++ -std=c++2a -frounding-math test.cpp In file included from /usr/local/include/c++/11.0.0/bits/range_access.h:40, from /usr/local/include/c++/11.0.0/string:54, from test.cpp:1: /usr/local/include/c++/11.0.0/bits/max_size_type.h:708:35: error: '(1.29e+2 * 6.9314718055994529e-1)' is not a constant expression 708 | = static_cast(digits * numbers::ln2 / numbers::ln10); |~~~^~ /usr/local/include/c++/11.0.0/bits/max_size_type.h:734:50: error: '(8.8722839111672997e+1 / 2.3025850929940459e+0)' is not a constant expression 734 | = static_cast(digits * numbers::ln2 / numbers::ln10); |~~^~~
[Bug c++/94141] c++20 rewritten operator== recursive call mixing friend and external operators for template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94141 --- Comment #4 from Laurent Rineau --- (In reply to Marc Glisse from comment #3) > It seems that this is as currently specified in C++20, but that some people > are going to try and change the rules to avoid breaking code like this. Do you have reference to the discussion on the subject?
[Bug c++/66944] ICE on static thread_local member in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944 --- Comment #9 from Laurent Rineau --- I still get the compilation error with gcc version 9.1.1.
[Bug c++/66944] ICE on static thread_local member in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66944 Laurent Rineau changed: What|Removed |Added CC||Laurent.Rineau__gcc@normale ||sup.org --- Comment #3 from Laurent Rineau --- I got hit by this bug today. Do you know a workaround?
[Bug c++/77948] Option processing of -std=c++11 -std=gnu++11 doesn't reset ext_numeric_literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77948 Laurent Rineau changed: What|Removed |Added CC||Laurent.Rineau__gcc@normale ||sup.org --- Comment #1 from Laurent Rineau --- *** Bug 78146 has been marked as a duplicate of this bug. ***
[Bug driver/78146] "-std=c++11 -std=gnu++11" is different from "-std=gnu++11" alone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78146 Laurent Rineau changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Laurent Rineau --- Indeed. *** This bug has been marked as a duplicate of bug 77948 ***
[Bug driver/78146] "-std=c++11 -std=gnu++11" is different from "-std=gnu++11" alone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78146 Laurent Rineau changed: What|Removed |Added Component|other |driver --- Comment #1 from Laurent Rineau --- That is probably a "driver" bug.
[Bug other/78146] New: "-std=c++11 -std=gnu++11" is different from "-std=gnu++11" alone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78146 Bug ID: 78146 Summary: "-std=c++11 -std=gnu++11" is different from "-std=gnu++11" alone Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: Laurent.Rineau__gcc at normalesup dot org Target Milestone: --- Let say I have this file with one line: auto v = 1.Q; That file does compile with `g++ -std=gnu++11 -c test.cpp`, but not with `g++ -std=c++11 -std=gnu++11 -c test.cpp` (when `-std=` is used twice): g++ -std=c++11 -std=gnu++11 -c test.cpp test.cpp:1:10: error: unable to find numeric literal operator ‘operator""Q’ auto v = 1.Q; ^~~ test.cpp:1:10: note: use -std=gnu++11 or -fext-numeric-literals to enable more built-in suffixes Compilation exited abnormally with code 1 at Fri Oct 28 13:47:10 Should not the last `-std=` supersede completely any previous occurrence? I use gcc from Fedora 24: gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)
[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904 Laurent Rineau Laurent.Rineau__gcc at normalesup dot org changed: What|Removed |Added CC||Laurent.Rineau__gcc@normale ||sup.org --- Comment #5 from Laurent Rineau Laurent.Rineau__gcc at normalesup dot org --- With the following gcc version: gcc (GCC) 4.8.2 20131017 (Red Hat 4.8.2-1) I have a similar result: $ gcc -c -Wstrict-overflow -O2 v.i v.i: In function ‘wait_reading_process_output’: v.i:14:6: warning: assuming signed overflow does not occur when simplifying conditional to constant [-Wstrict-overflow] if (nfds 0) ^ That diagnostic seems right, according to the documentation of -Wstrict-overflow.
[Bug tree-optimization/52904] -Wstrict-overflow false alarm with bounded loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904 --- Comment #7 from Laurent Rineau Laurent.Rineau__gcc at normalesup dot org --- In the test case, nfds cannot overflow, because of two reasons: - nfds is only incremented from 0, and -fstrict-overflow allows gcc to suppose it will not overflow, - the number of iterations of the loop cannot allow nfds to overflow, even without -fstrict-overflow. Gcc warns that the test (nfds 0) is useless, because of -fstrict-overflow. The developer has two solutions: - remove that test, - or compile with -fno-strict-overflow.
