[Bug preprocessor/105444] New: Support for disabling all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105444 Bug ID: 105444 Summary: Support for disabling all warnings Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: eyalroz1 at gmx dot com Target Milestone: --- At the moment, GCC supports: #pragma GCC diagnostic ignored "-Wwarning-name-here" to disable a specific kind of warning. This is nice and useful. However, sometimes one wants to disable many kinds of warnings, perhaps even warnings the author of the code was not aware of whose existence. It stands to reason that there should be something like: #pragma GCC diagnostic ignored all which would ignore all errors.
[Bug target/105435] Wtautological-constant-compare warning in trunk build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105435
--- Comment #2 from David Binderman ---
A reduction of the original code produces this:
void arm_cpu_builtins() {
if (0 ? 0 ? 4 : 2 : 0)
;
}
The best parse of this I can think of is:
void arm_cpu_builtins() {
if (0 ? (0 ? 4 : 2) : 0)
;
}
[Bug c++/105443] New: [modules] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105443 Bug ID: 105443 Summary: [modules] Internal compiler error Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: john at johnmaddock dot co.uk Target Milestone: --- Created attachment 52913 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52913=edit zip file containing test case. The attached pre-processed source generates: In module imported at ../../module/sf.cxx:24:1: boost.math.constants: note: unable to represent further imported source locations ../../module/sf.cxx:21:8: internal compiler error: in write_location, at cp/module.cc:15609 21 | export module boost.math.special_functions; |^~ libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. Found while experimenting with modules and Boost.Math.
[Bug libstdc++/105441] [12/13 Regression] The floating point overload of from_chars ignores 'P' for hex format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105441
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Last reconfirmed||2022-04-30
Target Milestone|--- |12.0
Known to fail||12.0, 13.0
Summary|The floating point overload |[12/13 Regression] The
|of from_chars ignores 'P' |floating point overload of
|for hex format |from_chars ignores 'P' for
||hex format
--- Comment #3 from Patrick Palka ---
Thanks for reporting and analyzing this!
(In reply to 康桓瑋 from comment #2)
> floating_from_chars.cc#L667
>
> // Parse the written exponent.
> int written_exponent = 0;
> if (first != last && *first == 'p')
> {
> // Tentatively consume the 'p' and try to parse a decimal number.
> const char* const fallback_first = first;
>
> it seems like it should be
>
> if (first != last && std::tolower((unsigned char)*first) == 'p')
I'm not sure we can use tolower here because it's locale dependent and charconv
isn't. So we should just test for 'p' and 'P' directly. And we should
probably replace the existing use of tolower in find_end_of_float.
I wonder why the SO user is seeing this bug with GCC 11.2? The new hexfloat
parser (r12-6645-gcc3bf3404e4b1c) is GCC 12 only.
[Bug libstdc++/105441] The floating point overload of from_chars ignores 'P' for hex format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105441
--- Comment #2 from 康桓瑋 ---
floating_from_chars.cc#L667
// Parse the written exponent.
int written_exponent = 0;
if (first != last && *first == 'p')
{
// Tentatively consume the 'p' and try to parse a decimal number.
const char* const fallback_first = first;
it seems like it should be
if (first != last && std::tolower((unsigned char)*first) == 'p')
[Bug libstdc++/105441] The floating point overload of from_chars ignores 'P' for hex format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105441
--- Comment #1 from 康桓瑋 ---
floating_from_chars.cc#L667
// Parse the written exponent.
int written_exponent = 0;
if (first != last && *first == 'p')
{
// Tentatively consume the 'p' and try to parse a decimal number.
const char* const fallback_first = first;
it seems like it should be
if (first != last && std::tolower((unsigned char)*first) == 'p')
[Bug c++/105442] New: [modules] exporting a class with an inline virtual destructor causes linker errors (duplicate symbols)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105442
Bug ID: 105442
Summary: [modules] exporting a class with an inline virtual
destructor causes linker errors (duplicate symbols)
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: john at johnmaddock dot co.uk
Target Milestone: ---
Found while experimenting with modules for Boost.Math, consider a module which
exports an exception type:
module;
#include
export module virtual_destructor_test;
export class evaluation_error : public std::runtime_error
{
public:
evaluation_error(const std::string& s) : std::runtime_error(s) {}
inline ~evaluation_error() {}
};
And a trivial program which uses it:
#include
import virtual_destructor_test;
int main()
{
evaluation_error eval(std::string("test me"));
}
Then I see:
D:/compilers/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
D:\compilers\msys64\tmp\cch2gAHF.o:virtual_test.c:(.text+0x0): multiple
definition of `evaluation_error::~evaluation_error()';
D:\compilers\msys64\tmp\cc35c6Fy.o:virtual.cxx:(.text$_ZN16evaluation_errorD1Ev[_ZN16evaluation_errorD1Ev]+0x0):
first defined here
D:/compilers/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
D:\compilers\msys64\tmp\cch2gAHF.o:virtual_test.c:(.text+0x2e): multiple
definition of `evaluation_error::~evaluation_error()';
D:\compilers\msys64\tmp\cc35c6Fy.o:virtual.cxx:(.text$_ZN16evaluation_errorD0Ev[_ZN16evaluation_errorD0Ev]+0x0):
first defined here
D:/compilers/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
D:\compilers\msys64\tmp\cch2gAHF.o:virtual_test.c:(.rdata+0x50): multiple
definition of `vtable for evaluation_error';
D:\compilers\msys64\tmp\cc35c6Fy.o:virtual.cxx:(.rdata$_ZTV16evaluation_error[_ZTV16evaluation_error]+0x0):
first defined here
The issue occurs if:
* No destructor is declared.
* The destructor is = default;
* The destructor is inline.
It does NOT occur if the destructor is declared non-inline.
Looks like the compiler should assume that vtables are always in the module?
[Bug libstdc++/105441] New: The floating point overload of from_chars ignores 'P' for hex format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105441 Bug ID: 105441 Summary: The floating point overload of from_chars ignores 'P' for hex format Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- >From StackOverflow https://stackoverflow.com/questions/72068948/is-stdfrom-chars-supposed-to-handle-uppercase-hexadecimal-exponents/72069971#72069971 testsuite: https://godbolt.org/z/ad1es7eE6
[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88580 Patrick Palka changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=59716 | CC||lts-rudolph at gmx dot de --- Comment #8 from Patrick Palka --- *** Bug 59716 has been marked as a duplicate of this bug. ***
[Bug c++/59716] variadic template multiple parameter pack expansion fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|10.4|12.0 Resolution|--- |DUPLICATE Summary|[10/11 Regression] variadic |variadic template multiple |template multiple parameter |parameter pack expansion |pack expansion fails|fails See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=88580 | --- Comment #10 from Patrick Palka --- So I guess we should consider this a dup of the non-regression PR88580 which is fixed for GCC 12. *** This bug has been marked as a duplicate of bug 88580 ***
[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105436 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Marek Polacek --- Thanks. I'll take care of it.
[Bug c/100545] ICE with -g: in gen_typedef_die with mode attribute and aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100545 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0aa277bf0b4b794314ab3f11bab438d17b57465d commit r13-57-g0aa277bf0b4b794314ab3f11bab438d17b57465d Author: Jason Merrill Date: Fri Apr 15 16:27:05 2022 -0400 c-family: attribute ((aligned, mode)) [PR100545] The problem here was that handle_mode_attribute clobbered the changes of any previous attribute, only copying type qualifiers to the new type. And common_handle_aligned_attribute had previously set up the typedef, so when we later called set_underlying_type it saw DECL_ORIGINAL_TYPE set and just returned, even though handle_mode_attribute had messed up the TREE_TYPE. So, let's fix handle_mode_attribute to copy attributes, alignment, and typedefness to the new type. PR c/100545 gcc/c-family/ChangeLog: * c-attribs.cc (handle_mode_attribute): Copy attributes, aligned, and typedef. * c-common.cc (set_underlying_type): Add assert. gcc/testsuite/ChangeLog: * c-c++-common/attr-mode-1.c: New test. * c-c++-common/attr-mode-2.c: New test.
[Bug libstdc++/105440] New: c++20: std::string's destructor not a constant expression when it should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105440
Bug ID: 105440
Summary: c++20: std::string's destructor not a constant
expression when it should
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: janpmoeller at gmx dot de
Target Milestone: ---
The following valid c++20 program fails to compile on both gcc and clang when
compiled with libstdc++:
//
#include
#include
constexpr auto foo(char c){
std::array a{std::string{"foo"} + c};
return true;
}
static_assert(foo('a'));
//
The emitted error is:
//
:9:18: error: non-constant condition for static assertion
9 | static_assert(foo('a'));
| ~~~^
In file included from
/opt/compiler-explorer/gcc-trunk-20220430/include/c++/13.0.0/string:53,
from :1:
:9:18: in 'constexpr' expansion of 'foo(97)'
:7:1: in 'constexpr' expansion of '(&
a)->std::array, 1>::~array()'
/opt/compiler-explorer/gcc-trunk-20220430/include/c++/13.0.0/array:99:12: in
'constexpr' expansion of
'->std::__cxx11::basic_string::~basic_string()'
/opt/compiler-explorer/gcc-trunk-20220430/include/c++/13.0.0/bits/basic_string.h:795:19:
in 'constexpr' expansion of
'((std::__cxx11::basic_string*)this)->std::__cxx11::basic_string::_M_dispose()'
/opt/compiler-explorer/gcc-trunk-20220430/include/c++/13.0.0/bits/basic_string.h:275:26:
error: '((& a) == )' is not a constant expression
275 | { return _M_data() == _M_local_data(); }
|~~^~
Compiler returned: 1
//
The same program compiles with libc++, and on msvc. Also see the following
godbolt link for comparison:
https://godbolt.org/z/zfn1Pr7P1
[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105432 Iain Sandoe changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #8 from Iain Sandoe --- *** Bug 105439 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/105439] [13 Regression] ICE: in set_range_info_raw, at tree-ssanames.cc:356 at -O2 with __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105439 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||iains at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Iain Sandoe --- dup *** This bug has been marked as a duplicate of bug 105432 ***
[Bug tree-optimization/105432] [13 regression] bootstrap build error in mpfr in stage2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105432 Iain Sandoe changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #7 from Iain Sandoe --- *** Bug 105434 has been marked as a duplicate of this bug. ***
[Bug bootstrap/105434] Compiler ICE when build GCC 13 cross compiler with GCC 13 native compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105434 Iain Sandoe changed: What|Removed |Added Resolution|--- |DUPLICATE CC||iains at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Iain Sandoe --- dup *** This bug has been marked as a duplicate of bug 105432 ***
[Bug tree-optimization/105439] New: [13 Regression] ICE: in set_range_info_raw, at tree-ssanames.cc:356 at -O2 with __builtin_unreachable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105439 Bug ID: 105439 Summary: [13 Regression] ICE: in set_range_info_raw, at tree-ssanames.cc:356 at -O2 with __builtin_unreachable() Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: build, ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 52912 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52912=edit reduced testcase This actually breaks build when compiling the mpfr: during GIMPLE pass: vrp /repo/gcc-trunk/mpfr/src/atan.c: In function 'mpfr_atan': /repo/gcc-trunk/mpfr/src/atan.c:286:1: internal compiler error: in set_range_info_raw, at tree-ssanames.cc:356 286 | mpfr_atan (mpfr_ptr atan, mpfr_srcptr x, mpfr_rnd_t rnd_mode) | ^ $ xgcc -v Using built-in specs. COLLECT_GCC=/repo/build-gcc-trunk-amd64/./prev-gcc/xgcc Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-56-20220430001627-g66d1e440e14-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220430 (experimental) (GCC) Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 testcase.c during GIMPLE pass: vrp testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in set_range_info_raw, at tree-ssanames.cc:356 4 | foo (void) | ^~~ 0x840cde set_range_info_raw(tree_node*, value_range_kind, generic_wide_int > const&, generic_wide_int > const&) /repo/gcc-trunk/gcc/tree-ssanames.cc:356 0x164af15 set_range_info /repo/gcc-trunk/gcc/tree-ssanames.cc:414 0x164af15 set_range_info(tree_node*, int_range<1u> const&) /repo/gcc-trunk/gcc/tree-ssanames.cc:424 0x16be605 vrp_asserts::remove_range_assertions() /repo/gcc-trunk/gcc/tree-vrp.cc:3754 0x16c8015 execute_vrp /repo/gcc-trunk/gcc/tree-vrp.cc:4245 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-35-20220429111024-g44b09adb9ba-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-35-20220429111024-g44b09adb9ba-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220429 (experimental) (GCC)
[Bug c++/105438] Incorrect array-bounds warning with array size carried over from a previous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438 --- Comment #1 from Bernie Innocenti --- Reproducible in Godbolt with any 11.x release as well as trunk: https://godbolt.org/z/zWb55P8G7
[Bug c++/105438] New: Incorrect array-bounds warning with array size carried over from a previous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105438
Bug ID: 105438
Summary: Incorrect array-bounds warning with array size carried
over from a previous template instantiation
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernie at codewiz dot org
Target Milestone: ---
Minified testcase (almost every line is necessary to reproduce):
```
/* g++ -Warray-bounds -O2 repro.cc */
int longer[7] = {};
int shorter[2] = {};
int out[10] = {};
template
void configure(const int()[N], const int nrows = N)
{
if (nrows <= 10)
{
for (int i = 0; i < nrows; i++)
{
out[i] = in[i];
}
}
}
int main()
{
configure(longer);
configure(shorter);
}
```
Output:
```
$ g++ -Warray-bounds -O2 repro.cc
repro.cc: In function 'int main()':
repro.cc:13:24: warning: array subscript 'const int [7][0]' is partly outside
array bounds of 'int [2]' [-Warray-bounds]
13 | out[i] = in[i];
| ~~^
repro.cc:3:5: note: while referencing 'shorter'
3 | int shorter[2] = {};
| ^~~
repro.cc:13:24: warning: array subscript 'const int [7][0]' is partly outside
array bounds of 'int [2]' [-Warray-bounds]
13 | out[i] = in[i];
| ~~^
repro.cc:3:5: note: while referencing 'shorter'
3 | int shorter[2] = {};
| ^~~
```
Static analysis appears to be using the length of the longer array for the call
using the shorter array.
The warning disappears by:
* commenting out the first call to configure() suppresses the warning
* swapping the two calls to configure()
* commenting out if statement also eliminates the warning
* making longer and shorter the same size
* using N as loop counter instead of nrows
[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105436 --- Comment #4 from Jakub Jelinek --- Marek, I think you're right. I meant to follow what is done for C++98 CPP_RSHIFT with CPP_GREATER_EQ, but here actually CPP_RSHIFT isn't special in C++98.
