[Bug middle-end/96988] New: Bad/missing warnings when returning a temporary from an inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96988
Bug ID: 96988
Summary: Bad/missing warnings when returning a temporary from
an inlined function
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
Minimal testcase:
// compile with: gcc -O2 -Wall bug.cpp
static int * foo()
{
int a = 42;
int * b = &a;
return b;
}
int bar()
{
return *foo();
}
Result: A misleading warning in wrong function.
: In function 'bar':
:10:12: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
10 | return *foo();
|^~
Expected result: I get a good warning (but the misleading one too) if the buggy
function is not inline, static, or a C++ template.
: In function 'foo':
:5:12: warning: function returns address of local variable
[-Wreturn-local-addr]
5 | return b;
|^
:3:9: note: declared here
3 | int a = 42;
| ^
More realistic example:
// compile with: g++ -O3 -Wall bug.cpp
template
const T& max(const T& a) { return a; }
template
const T& max(const T& a, Args... args)
{
// whoops, this creates temporaries with insufficient lifetime if the
arguments aren't same type
const T& b = max(args...);
if (a < b) return b;
else return a;
}
int victim()
{
return max(1, 2u);
}
(I'm not sure what component this belongs to; please recategorize if wrong.)
[Bug c++/96988] Bad/missing warnings when returning a temporary from an inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96988
--- Comment #2 from Alfred Agrell ---
Poked this thing a bit more, and discovered that there's no need for inlining,
you can reproduce it just as well with an extra {}.
And if you copy the function a few times, the warnings start pointing to wrong
source location. Is that just another facet of this issue, or is it a separate
bug?
$ gcc -O2 -Wall bug.c
int foo1() { int * b; { int a = 1; b = &a; } return *b; }
int foo2() { int * b; { int a = 2; b = &a; } return *b; }
int foo3() { int * b; { int a = 3; b = &a; } return *b; }
int foo4() { int * b; { int a = 4; b = &a; } return *b; }
int foo5() { int * b; { int a = 5; b = &a; } return *b; }
: In function 'foo1':
:1:54: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
1 | int foo1() { int * b; { int a = 1; b = &a; } return *b; }
| ^~
: In function 'foo2':
:1:29: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
1 | int foo1() { int * b; { int a = 1; b = &a; } return *b; }
| ^
: In function 'foo3':
:1:29: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
: In function 'foo4':
:1:29: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
: In function 'foo5':
:1:29: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
[Bug c++/80521] Wrong line reported in error for missing template argument in friend class declaration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80521
Alfred Agrell changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #1 from Alfred Agrell ---
Ran into this one myself, reproduces on 6.3.0-12ubuntu2 and 8.0.0 20170427
Godbolt. Minimized testcase:
template
class foo {
int a;
int b; // error here
void c() {}
/* template */ friend class bar; // error should be here
};
template class bar {
foo baz;
};
template class bar;
Expected output:
: In instantiation of 'class foo':
:13:11: required from here
:9:40: error: template argument required for 'class bar'
/* template */ friend class bar; // error should be here
^
Actual output:
: In instantiation of 'class foo':
:13:11: required from here
:5:6: error: template argument required for 'class bar'
int b; // error here
^
Clang output:
:12:28: error: redefinition of 'bar' as different kind of symbol
template class bar {
^
:9:40: note: previous definition is here
/* template */ friend class bar; // error should be here
^
[Bug c++/80264] New: g++ ignores register assignments in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80264
Bug ID: 80264
Summary: g++ ignores register assignments in template functions
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
Created attachment 41092
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41092&action=edit
Testcase
Input (also attached):
template
void foo1()
{
register int bar asm("NOT-A-REGISTER");
}
template void foo1<0>();
template
void foo2()
{
register int edi asm("edi") = 42;
asm volatile("" :: "r"(edi));
}
template void foo2<0>();
void foo3()
{
register int edi asm("edi") = 42;
asm volatile("" :: "r"(edi));
}
Command line:
g++ -S template-inline-asm.cpp -o-
(the flags don't affect this issue)
Expected output:
First function: error: invalid register name for 'bar'
Second: movl $42, %edi (or equivalent)
Third: movl $42, %edi
Actual output:
First one: Compiler silently emits a blank function (other than an unused
variable warning)
Second: movl $42, %ebx (%eax on -O1 or higher)
Third: As expected
Tested versions:
g++ 7.0.1 20170330 x86_64-linux-gnu (Godbolt)
g++ 6.2.0-5ubuntu12 x86_64-linux-gnu (Lubuntu 16.10)
g++ 4.4.7-1ubuntu2 x86_64-linux-gnu (Godbolt)
clang++ 3.8.1-12ubuntu1 (acts as expected)
7.0.1 config:
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-7-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20170330/configure --prefix /root/staging
--build=x86_64-linux-gnu --disable-multilibs --disable-bootstrap
--enable-clocale=gnu --enable-languages=c,c++ --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --with-pkgversion=GCC-Explorer-Build
Thread model: posix
gcc version 7.0.1 20170330 (experimental) (GCC-Explorer-Build)
COLLECT_GCC_OPTIONS='-g' '-o'
'/tmp/compiler-explorer-compiler117230-57-19womo8.vtf1hmpldi/output.s'
'-masm=intel' '-S' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/opt/compiler-explorer/gcc-trunk-20170330/bin/../libexec/gcc/x86_64-linux-gnu/7.0.1/cc1plus
-quiet -v -imultiarch x86_64-linux-gnu -iprefix
/opt/compiler-explorer/gcc-trunk-20170330/bin/../lib/gcc/x86_64-linux-gnu/7.0.1/
-D_GNU_SOURCE -quiet -dumpbase example.cpp -masm=intel -mtune=generic
-march=x86-64 -auxbase-strip
/tmp/compiler-explorer-compiler117230-57-19womo8.vtf1hmpldi/output.s -g
-version -o
/tmp/compiler-explorer-compiler117230-57-19womo8.vtf1hmpldi/output.s
GNU C++14 (GCC-Explorer-Build) version 7.0.1 20170330 (experimental)
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
[Bug c++/97221] New: Returning an array unexpectedly favors const overload in return value's constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97221
Bug ID: 97221
Summary: Returning an array unexpectedly favors const overload
in return value's constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct string {
const char * m;
template string(const char (&str)[N]) { m = "CONST"; }
template string(char (&str)[N]) { m = "MUT"; }
};
string foo()
{
char bar[8];
return bar;
}
With Clang 10.0.1 -O2 -std=c++11, this returns "MUT".
With GCC 10.2 -O2 -std=c++98, this returns "MUT".
With GCC 7.5 -O2 -std=c++11, this returns "MUT".
With GCC 10.2 -O2 -std=c++11, this returns "CONST".
This one should give same result for every configuration, or at least throw a
warning from -Wc++11-compat, right?
Compiler Explorer: https://godbolt.org/z/r3Yo64
(Context: I encountered this when trying to make my string class distinguish
between string literals and char arrays/pointers, and call sizeof instead of
strlen for the former.)
[Bug c++/91212] [8/9/10/11 Regression] const ignored for ctor arguments within return since r8-2493-g4ce8c5dea53d8073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91212 Alfred Agrell changed: What|Removed |Added CC||blubban at gmail dot com --- Comment #10 from Alfred Agrell --- *** Bug 97221 has been marked as a duplicate of this bug. ***
[Bug c++/97221] Returning an array unexpectedly favors const overload in return value's constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97221 Alfred Agrell changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Alfred Agrell --- Ah, indeed it is. I should've checked gcc-trunk on CE, I keep forgetting it exists. Thanks, and sorry for the noise. *** This bug has been marked as a duplicate of bug 91212 ***
[Bug other/97280] New: Documentation typo - 'roudnevenl'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97280 Bug ID: 97280 Summary: Documentation typo - 'roudnevenl' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: blubban at gmail dot com Target Milestone: --- https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html "Outside strict ISO C mode [...], the functions [...] roundeven, roundevenf, roudnevenl, scalbf [...]" Should be roundevenl. It's a documentation bug only, GCC itself implements the expected name.
[Bug c++/106541] New: Missing -Wuninitialized on self initialization if external code is called earlier in the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106541
Bug ID: 106541
Summary: Missing -Wuninitialized on self initialization if
external code is called earlier in the function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct my_class {
int data[4];
};
void fn1();
void fn2()
{
my_class local = local;
}
void fn3()
{
fn1();
my_class local = local;
}
Compile with g++ -Wall.
Expected: Two warnings. Or maybe zero, if this is not considered a use.
Actual: Former complains, latter does not. That extra function call should not
affect the warning count.
https://godbolt.org/z/vhdnq1Ec1
[Bug c++/107151] New: Specializing a concepted template can emit bogus assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107151
Bug ID: 107151
Summary: Specializing a concepted template can emit bogus
assembly
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
template
void fun(T);
template <>
void fun(char c)
{
std::puts("foo()");
}
template
void fun(I i)
{
std::puts("foo()");
}
int main()
{
fun(' ');
}
Compile with -std=c++20.
Result:
/tmp/cctfBAWi.s: Assembler messages:
/tmp/cctfBAWi.s:63: Error: symbol `_Z3funIcEvT_' is already defined
/tmp/cctfBAWi.s: Error: .size expression for _Z3funIcEvT_ does not evaluate to
a constant
Expected: Prints foo(), or at least a less cryptic error. With -O2, GCC
only emits one _Z3funIcEvT_, but the resulting program prints
foo().
https://godbolt.org/z/axvdbK1Eh
Clang and MSVC have similar bugs:
https://github.com/llvm/llvm-project/issues/58142
https://developercommunity.visualstudio.com/t/Template-explicit-specializationconcept/10012835
[Bug c++/103825] New: [12 Regression] ICE on switch on enum class in bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825
Bug ID: 103825
Summary: [12 Regression] ICE on switch on enum class in
bitfield
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
enum class Type { Pawn };
struct Piece {
Type type : 4;
};
void foo() {
switch (Piece().type)
case Type::Pawn:;
}
The above causes an ICE on GCC 12.0.0 20211222, no compile flags needed. It
compiles without warnings on GCC 11, Clang, and MSVC.
Compiler Explorer: https://godbolt.org/z/GdG6ovEzz
: In function 'void foo()':
:5:6: error: type precision mismatch in switch statement
5 | void foo() {
| ^~~
switch (retval.0) , case 0: >
:5:6: internal compiler error: 'verify_gimple' failed
0x2115089 internal_error(char const*, ...)
???:0
0x11603ed verify_gimple_in_seq(gimple*)
???:0
0xdda0d1 gimplify_body(tree_node*, bool)
???:0
0xdda397 gimplify_function_tree(tree_node*)
???:0
0xbe6a57 cgraph_node::analyze()
???:0
0xbeaf6d symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug web/103877] New: libstdc++ docs give a bad recommendation for printing C++ defines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103877 Bug ID: 103877 Summary: libstdc++ docs give a bad recommendation for printing C++ defines Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: blubban at gmail dot com Target Milestone: --- https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.predefined > You can also run g++ -E -dM - < /dev/null" to display a > list of predefined macros for any particular installation. Issue 1: The unmatched quote. Issue 2: g++ -E defaults to C mode, where _GNU_SOURCE is, in fact, not defined. The correct command is g++ -E -dM -xc++ - < /dev/null
[Bug libstdc++/103911] New: std::from_chars shouldn't call isdigit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103911
Bug ID: 103911
Summary: std::from_chars shouldn't call isdigit
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
In header , function __from_chars_alnum calls std::isdigit().
In addition to looking weird ("everyone" knows ctype is locale dependent and
charconv is not), this can cause trouble in a handful of rare cases.
If another thread concurrently calls setlocale, that's a race condition;
additionally, if the locale contains digits other than '0'..'9', from_chars can
return wrong answer. (For example, some versions of Windows libc think 0xB2,
0xB3 and 0xB9 are the digits ²³¹ in the "us" locale.)
GCC will, by default, replace isdigit with c>='0' && c<='9'; to reproduce the
above, use -fno-builtin or Clang.
(Bonus issue: A comment on that function says it applies to bases 11 to 26.
Shouldn't that be 11 to 36?)
[Bug c++/102120] New: expected tree that contains 'decl common' structure, have 'identifier_node' in dump_aggr_type, at cp/error.c:786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102120
Bug ID: 102120
Summary: expected tree that contains 'decl common' structure,
have 'identifier_node' in dump_aggr_type, at
cp/error.c:786
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
Input:
union U {
int value;
constexpr ~U() noexcept { }
};
constexpr int z() {
U* array = new U[5];
int result = array[3].value;
delete[] array;
return result;
}
constexpr int zz = z();
Compile with -std=c++20.
Expected output (I get this if I remove the union's dtor, or change the array
to a single object):
:13:21: in 'constexpr' expansion of 'z()'
:13:22: error: the content of uninitialized storage is not usable in a
constant expression
13 | constexpr int zz = z();
| ^
:7:23: note: allocated here
7 | U* array = new U[5];
| ^
Actual output on GCC 11.2:
'
:13: confused by earlier errors, bailing out
Yes, those two lines are the entirety of its output.
GCC trunk is slightly better, but still asks for a bug report:
'
:13:21: in 'constexpr' expansion of 'z()'
tree check: expected tree that contains 'decl common' structure, have
'identifier_node' in dump_aggr_type, at cp/error.c:786
13 | constexpr int zz = z();
| ^
0x1f30289 internal_error(char const*, ...)
???:0
0x6bb645 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
???:0
0x1f4c781 pp_format(pretty_printer*, text_info*)
???:0
0x1f2eeb5 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
???:0
0x1f2fde9 error(char const*, ...)
???:0
0xae3d0a store_init_value(tree_node*, tree_node*, vec**, int)
???:0
0x89b0c9 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x9d09a5 c_parse_file()
???:0
0xb55af2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Compiler Explorer: https://godbolt.org/z/WETs8jbMG
Posted by user konstantinua00 on the Compiler Explorer Discord, who may or may
not have found it via someone else.
[Bug c++/102198] New: Unused and nonsensical template instantiations used for return type inference end up in the output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102198
Bug ID: 102198
Summary: Unused and nonsensical template instantiations used
for return type inference end up in the output
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
Input:
template
int* a() { return x; }
template
auto b() { return a; }
template
auto c() -> int* (*)()
{
static int x1;
return b<&x1>();
}
int main(int argc, char** argv)
{
if constexpr (false)
{
static int x2;
b<&x2>();
}
c();
c();
}
Compile with -O0.
Expected output: Compiles and links successfully.
Actual output, as of 7.2 through 11.2: Assembly output contains four
instantiations of a(), using template arguments c::x1, c::x1,
main::x2, and c::x1 (or whatever _ZZ1cIXT_EEPFPivEvE2x1 is
supposed to be, c++filt doesn't like it). There's no storage assigned for the
latter two, so they instantiations throw linker errors.
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc2i7eNg.o: in function `_Z1aIXadL_ZZ1cIXT_EEPFPivEvE2x1EEES1_v':
:2: undefined reference to `_ZZ1cIXT_EEPFPivEvE2x1'
/opt/compiler-explorer/gcc-11.2.0/bin/../lib/gcc/x86_64-linux-gnu/11.2.0/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc2i7eNg.o: in function `int* a<&(main::x2)>()':
:2: undefined reference to `main::x2'
collect2: error: ld returned 1 exit status
Actual output, as of current trunk:
: In instantiation of 'auto b() [with int* x = (& x1)]':
:5:6: required from here
:5:6: internal compiler error: in discriminator_for_local_entity, at
cp/mangle.c:1965
5 | auto b() { return a; }
| ^
0x1f31a39 internal_error(char const*, ...)
???:0
0x79e1c7 fancy_abort(char const*, int, char const*)
???:0
0x8fe32b mangle_decl(tree_node*)
???:0
0x148f6b2 decl_assembler_name(tree_node*)
???:0
0x14c15d0 assign_assembler_name_if_needed(tree_node*)
???:0
0xc38855 cgraph_node::analyze()
???:0
0xc3cfdd symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
The issues go away if I change main to if constexpr (true) or remove the
template from c(), if I put x1 and x2 in global scope, if I append -> int*
(*)() to b(), or if I enable -O1 or higher. Only the template variant gives
ICE, if constexpr (false) gives the same bad output in trunk as in 11.2
(after removing or neutralizing c()).
I don't know how many different issues this is, but they all look like
different facets of the same root cause (either the extra a() instantiations
should be discarded after determining b's return type, or they shouldn't be
created at all), so I'm filing one bug for them all.
Compiler Explorer: https://godbolt.org/z/89794xb8v
[Bug c++/107913] New: Bogus unused variable warning if used in if constexpr false in lambda with default capture by ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107913
Bug ID: 107913
Summary: Bogus unused variable warning if used in if constexpr
false in lambda with default capture by ref
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
template
int b()
{
constexpr int c = 123;
constexpr int d = 456;
return [&](){
if constexpr (a)
return c;
else
return d;
}();
}
int g() { return b(); }
int h() { return b(); }
Compile with -Wall.
Expected result: No warnings.
Actual result:
: In instantiation of 'int b() [with bool a = true]':
:15:25: required from here
:5:19: warning: variable 'd' set but not used
[-Wunused-but-set-variable]
5 | constexpr int d = 456;
| ^
: In instantiation of 'int b() [with bool a = false]':
:16:26: required from here
:4:19: warning: variable 'c' set but not used
[-Wunused-but-set-variable]
4 | constexpr int c = 123;
| ^
The warning is very fragile, and goes away if (pick one or more)
- either variable is changed to not constexpr (oddly enough, both warnings
disappear if either variable is not constexpr)
- either variable is changed to static
- the if is changed to not constexpr
- the lambda is removed
- the variables are captured explicitly
- the lambda's default capture is by-value
(The bug does reproduce if the template is removed and changed to if constexpr
(true), but I feel the current form better demonstrates that the warning is
inappropriate.)
https://godbolt.org/z/T9nnzjj91
[Bug c++/105595] New: Coroutines can trigger -Wsubobject-linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105595
Bug ID: 105595
Summary: Coroutines can trigger -Wsubobject-linkage
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
To reproduce:
- Create a minimal coroutine promise
- Create a coroutine where any local's type has no linkage (for example a
lambda)
- #include the above from another, differently named, file
Result:
/app/not_example.cpp:25:1: warning: 'foo()::_Z3foov.Frame' has a field
'foo()::_Z3foov.Frame::anon_ns_1_2' whose type uses the anonymous namespace
[-Wsubobject-linkage]
/app/not_example.cpp:25:1: warning: 'foo()::_Z3foov.Frame' has a field
'foo()::_Z3foov.Frame::inner_class_1_2' whose type has no linkage
[-Wsubobject-linkage]
/app/not_example.cpp:25:1: warning: 'foo()::_Z3foov.Frame' has a field
'foo()::_Z3foov.Frame::a_lambda_1_2' whose type has no linkage
[-Wsubobject-linkage]
Expected:
No warning, because the coroutine frame's type shouldn't have linkage either.
Sticking anonymous types inside each other is harmless.
Full testcase:
# 2 "/app/not_example.cpp" 1
#include
class async {
public:
class promise_type {
public:
async get_return_object() { return {}; }
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() {}
};
};
namespace {
class anon_ns_t {};
}
async foo()
{
anon_ns_t anon_ns;
class inner_class_t {} inner_class;
auto a_lambda = [](){};
co_await std::suspend_never{};
}
Compile with -std=c++20.
Compiler Explorer: https://godbolt.org/z/efz6dfoWq
[Bug c++/103871] [11/12/13 Regression] co_await causes build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871
Alfred Agrell changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #15 from Alfred Agrell ---
Just ran into this (and/or bug 98056). Still exists as of trunk-20220522.
Minimized to https://godbolt.org/z/qhWWzKe4M
#include
#include
class my_coro {
public:
my_coro();
class promise_type {
public:
my_coro get_return_object();
std::suspend_never initial_suspend();
std::suspend_never final_suspend() noexcept;
void unhandled_exception();
};
};
std::suspend_never inner(std::initializer_list);
my_coro doesnt_work()
{
co_await inner({ 1,2,3 });
}
[Bug c++/105804] New: List-initialized argument in await expression is doubly freed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105804
Bug ID: 105804
Summary: List-initialized argument in await expression is
doubly freed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
struct my_params {
std::unique_ptr ptr; // or any other object with nontrivial dtor
};
static std::suspend_never take_params(my_params params)
{
return {};
}
struct coro_t {
struct promise_type {
coro_t get_return_object() { return {}; }
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() noexcept {}
};
};
static coro_t my_coro()
{
co_await take_params({ std::make_unique(5) });
}
int main()
{
my_coro();
}
Expected output: Same as /bin/true
Actual: free(): double free detected in tcache 2
https://godbolt.org/z/8f9d3TzYo
Probably same root cause as bug 98056 and/or bug 103871, but since the symptoms
are way different (it's a wrong-code, not just rejects-valid), I think it
warrants a separate report.
[Bug sanitizer/101758] New: Inconsistent optimizations with UBSan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101758
Bug ID: 101758
Summary: Inconsistent optimizations with UBSan
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Input:
gcc -fsanitize=undefined -O2 -fno-strict-aliasing -Wall
float b(unsigned a) { return *(float*)&a; }
float c(unsigned a) { return *(float*)&a; }
float d(unsigned a) { return *(float*)&a; }
Output:
b:
mov DWORD PTR [rsp-4], edi
movss xmm0, DWORD PTR [rsp-4]
ret
c:
movdxmm0, edi
ret
d:
movdxmm0, edi
ret
or, on ARM
b:
sub sp, sp, #8
str r0, [sp, #4]
vldr.32 s0, [sp, #4]
add sp, sp, #8
bx lr
c:
sub sp, sp, #8
vmovs0, r0
add sp, sp, #8
bx lr
d:
sub sp, sp, #8
vmovs0, r0
add sp, sp, #8
bx lr
Expected output:
Same assembly for all three. And maybe don't set up an unused stack frame on
ARM (it's correctly optimized out without UBSan).
Compiler Explorer: https://godbolt.org/z/Tfs5qazqM
(Found it while trying to determine if that function is a strict aliasing
violation (it is), and whether it can be fixed with memcpy or a union (both
work).)
[Bug c++/114167] New: Capturing a auto..., then unpacking it in a lambda taking Ts..., confuses GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114167
Bug ID: 114167
Summary: Capturing a auto..., then unpacking it in a lambda
taking Ts..., confuses GCC
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
void a(int, int) {}
template
void b()
{
[](auto... ch){
[ch...](Ts... newvals) {
(a(ch, newvals), ...);
}(3,4);
}(1,2);
}
void c()
{
b();
}
No flags needed. (Needs -std=c++17, but that's the default.)
Expected: Should compile.
Actual:
: In instantiation of 'a():: [with auto:1
= {int, int}]':
:8:6: required from 'void a() [with Ts = {int, int}]'
:13:15: required from here
:6:19: error: 'newvals#0' is not captured
6 | ((ch, newvals), ...);
| ^~~
:5:9: note: the lambda has no capture-default
5 | [ch...](Ts... newvals) {
| ^~~~
6 | ((ch, newvals), ...);
| ~
7 | }(3,4);
| ~
:5:19: note: 'int newvals#0' declared here
5 | [ch...](Ts... newvals) {
| ~~^~~
Compiler returned: 1
I'm not 100% sure if that is valid C++, but Clang accepts it, and the error
message somehow manages to ask to capture newvals before it's declared.
https://godbolt.org/z/G8Kh9rvYc
[Bug target/107337] -march docs for nocona are missing CX16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107337 Alfred Agrell changed: What|Removed |Added CC||blubban at gmail dot com --- Comment #3 from Alfred Agrell --- This bug still exists. In addition to nocona, it also affects bonnell, sierraforest, grandridge, clearwaterforest, alderlake, arrowlake, arrowlake-s, pantherlake, and amdfam10 aka barcelona.
[Bug c++/116584] New: Type/value mismatch confuses error recovery
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116584
Bug ID: 116584
Summary: Type/value mismatch confuses error recovery
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
template struct foo;
void* bar()
{
return (decltype(foo<5>)*)5;
}
No flags needed.
Result:
: In function 'void* bar()':
:5:31: error: type/value mismatch at argument 1 in template parameter
list for 'template struct foo'
5 | return (decltype(foo<5>)*)5;
| ^
:5:31: note: expected a type, got '5'
:5:17: error: expected primary-expression before 'decltype'
5 | return (decltype(foo<5>)*)5;
| ^~~~
:5:17: error: expected ')' before 'decltype'
5 | return (decltype(foo<5>)*)5;
|~^~~~
| )
Compiler returned: 1
Expected: Just the first error, the last one looks like it's telling me to
write return ();
Diagnostics are even funnier if colored - in the last one, the first letter of
decltype is red, while the ecltype is green. https://godbolt.org/z/7bcazrPsY
[Bug c++/105804] coroutines: List-initialized argument in await expression is doubly freed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105804 Alfred Agrell changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Alfred Agrell --- Looks like this one was fixed at some point. Probably by commit r13-6702-gea4dd8f512979db247c54d6b41377bb73699bcd7, as reported in bug 103871. Good job, GCC team.
[Bug c++/115318] New: decltype(lambda) with some templates causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115318
Bug ID: 115318
Summary: decltype(lambda) with some templates causes ICE
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
template struct S {};
template
void foo()
{
using foo_t = decltype([](){});
[]() { S{}; }();
}
void bar() { foo(); }
-std=c++20
: In instantiation of 'foo<>():: [with int k = 6]':
:7:36: required from 'void foo() [with int i = 4]'
7 | []() { S{}; }();
| ~~~^~
:10:17: required from here
10 | void bar() { foo(); }
| ~~~^~
:6:28: internal compiler error: in tsubst, at cp/pt.cc:16401
6 | using foo_t = decltype([](){});
|^~
0x202ef4c internal_error(char const*, ...)
???:0
0x778915 fancy_abort(char const*, int, char const*)
???:0
0x938dd0 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x943a11 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x939200 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x93c437 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x931a0f instantiate_decl(tree_node*, bool, bool)
???:0
0x831fb7 maybe_instantiate_decl(tree_node*)
???:0
0x8332f7 mark_used(tree_node*, int)
???:0
0x7a20a3 build_op_call(tree_node*, vec**, int)
???:0
0x9602fe finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x931a0f instantiate_decl(tree_node*, bool, bool)
???:0
0x94d2e3 instantiate_pending_templates(int)
???:0
0x835608 c_parse_final_cleanups()
???:0
0xa0c508 c_common_parse_file()
???:0
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.
Compiler returned: 1
If you make the first lambda a template ( decltype([](){}) ), you'll get a
internal compiler error: Segmentation fault instead. Probably the same root
cause.
Online reproducer: https://godbolt.org/z/EfxPxKWhd
I tried searching for duplicates, but every open issue I could find in bug
#107430 is a mess, I can't determine if it's the same.
[Bug c++/115319] New: ICE when mutating a captured parameter in an explicit-this lambda if a capture is not trivially copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115319
Bug ID: 115319
Summary: ICE when mutating a captured parameter in an
explicit-this lambda if a capture is not trivially
copyable
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct S
{
S() {}
S(const S&) {}
};
void a()
{
[i=0, x=S{}](this auto self) -> void
{
i++;
}();
}
-std=c++23 (optional, it throws a c++23-extensions warning and the same ICE
without it)
: In lambda function:
:11:9: internal compiler error: in gimplify_compound_lval, at
gimplify.cc:3576
11 | i++;
| ^
0x202ef4c internal_error(char const*, ...)
???:0
0x778915 fancy_abort(char const*, int, char const*)
???:0
0xc4c739 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc55a00 gimplify_self_mod_expr(tree_node**, gimple**, gimple**, bool,
tree_node*)
???:0
0xc4cf52 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc4e8c4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc4ca8d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc4e8ae gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xc50e8e gimplify_body(tree_node*, bool)
???:0
0xc51250 gimplify_function_tree(tree_node*)
???:0
0xaba647 cgraph_node::analyze()
???:0
0xabd9b1 symbol_table::finalize_compilation_unit()
???:0
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.
Compiler returned: 1
Online reproducer: https://godbolt.org/z/Go6YdPTME
It seems that the explicit this makes by-value captures mutable, so I think
this is an ice-on-valid, but that is a pretty odd-sounding rule, so I'm not
entirely sure.
(one of my friends just discovered that posting GCC ICEs where I see them gets
them reduced and reported. Said friend claims to encounter like billions of
ICEs every day, so I may end up submitting a lot of ICEs and other gcc bugs in
the near future. I'll make sure to reduce every testcase, validate that it is a
bug, and try to find existing reports, of course)
[Bug c++/115331] New: [15 regression] ICE-on-invalid passing a typoed lambda to a list-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115331
Bug ID: 115331
Summary: [15 regression] ICE-on-invalid passing a typoed lambda
to a list-initializer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct has_ctor
{
has_ctor(auto arg) {}
};
void aaa()
{
has_ctor{[]<(){}}; // typo intentional
}
-std=c++20
: In function 'void aaa()':
:8:17: error: expected identifier before '(' token
8 | has_ctor{[]<(){}};
| ^
:8:19: error: expected '>' before '{' token
8 | has_ctor{[]<(){}};
| ^
: In instantiation of 'has_ctor::has_ctor(auto:1) [with auto:1 =
aaa()::]':
:3:5: required from here
3 | has_ctor(auto arg) {}
| ^~~~
:3:5: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'error_mark' in decl_template_parm_check, at
cp/cp-tree.h:5138
0x269996c internal_error(char const*, ...)
???:0
0x96eb0f tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
???:0
0xba20c6 mangle_decl(tree_node*)
???:0
0x16c5fc5 decl_assembler_name(tree_node*)
???:0
0x16eea01 assign_assembler_name_if_needed(tree_node*)
???:0
0xe8c11d cgraph_node::analyze()
???:0
0xe8f6d1 symbol_table::finalize_compilation_unit()
???:0
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.
Compiler returned: 1
Online reproducer: https://godbolt.org/z/K1hjEsaf5
The ICE does not reproduce on 14.1, it's trunk only (tested on
Compiler-Explorer-Build-gcc-cbf2ed4b309d54039d74be5d730299012e7681b3-binutils-2.42,
15.0.0 20240603).
[Bug c++/115364] New: ICE-on-invalid when calling non-const template member on const object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115364
Bug ID: 115364
Summary: ICE-on-invalid when calling non-const template member
on const object
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct foo
{
template void not_const() {}
};
void fn(const foo& obj) { obj.not_const<5>(); }
No flags needed.
: In member function 'void foo::fn() const':
:4:41: error: cannot convert 'const foo*' to 'foo*'
4 | void fn() const { this->not_const<5>(); }
| ~~^~
:4:41: internal compiler error: tree check: expected function_decl,
have template_decl in get_fndecl_argument_location, at cp/call.cc:8354
0x26aa1ac internal_error(char const*, ...)
???:0
0x96fd9e tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0xa7d15f complain_about_bad_argument(unsigned int, tree_node*, tree_node*,
tree_node*, int)
???:0
0xa8c20a build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xce8267 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xc6a70a c_parse_file()
???:0
0xdbfcf9 c_common_parse_file()
???:0
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.
Compiler returned: 1
Online reproducer: https://godbolt.org/z/86noE3935
I would've expected something as simple as this to have been tested and fixed
long ago, but apparently not. Probably because it's just a tree check; from
what I've heard, they don't exist in versioned releases of GCC.
[Bug libstdc++/112564] New: std::format(std::thread::id) is incorrectly left-aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112564 Bug ID: 112564 Summary: std::format(std::thread::id) is incorrectly left-aligned Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: blubban at gmail dot com Target Milestone: --- https://godbolt.org/z/zra9GddY3 N4964 [thread.thread.id]/12 "If the align option is omitted it defaults to >." Both MSVC and libc++ right-align thread::id here as mandated by that paragraph, but libstdc++ is left-aligning. I am not sure how duration should be aligned by default but either libstdc++ or libc++ are buggy here. Found by https://github.com/StephanTLavavej
[Bug c++/105667] [C++20] lambas in template argument sometimes causes an ICE (seg fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105667
Alfred Agrell changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #8 from Alfred Agrell ---
I ran into something similar. My reduced testcase is
struct class1
{
virtual void a_function() = 0;
};
template() {}>
class class2 {};
template
struct class3 : public class1 {
void a_function()
{
class2<> x;
}
};
struct class4 : public class3 {
class4() {}
};
https://godbolt.org/z/GKo5oWe8j
[Bug c++/110565] New: Incomplete note on why initializing int& with int is ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110565
Bug ID: 110565
Summary: Incomplete note on why initializing int& with int is
ill-formed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct X {
X(int&);
X(X&&) = delete; // the issue reproduces without this line, but the error
is clearer with it
};
template
void f() {
new X(0);
}
Expected output:
: In function 'void f()':
:8:12: error: no matching function for call to 'X::X(int)'
8 | new X(0);
|^
:2:5: note: candidate: 'X::X(int&)' (near match)
2 | X(int&);
| ^
:2:5: note: conversion of argument 1 would be ill-formed:
:8:11: error: cannot bind non-const lvalue reference of type 'int&' to
an rvalue of type 'int'
Actual output:
: In function 'void f()':
:8:12: error: no matching function for call to 'X::X(int)'
8 | new X(0);
|^
:2:5: note: candidate: 'X::X(int&)' (near match)
2 | X(int&);
| ^
:2:5: note: conversion of argument 1 would be ill-formed:
The template and new-expression are necessary; the error is proper without
them.
https://godbolt.org/z/c1Er5nsjd
[Bug tree-optimization/115423] New: Inlined strcmp optimizes poorly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115423
Bug ID: 115423
Summary: Inlined strcmp optimizes poorly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
bool g(const char* c) {
return __builtin_strcmp(c, ".") == 0 ||
__builtin_strcmp(c, "..") == 0;
}
bool h(const char* c) {
return (c[0] == '.' && c[1] == '\0') ||
(c[0] == '.' && c[1] == '.' && c[2] == '\0');
}
Compile with -O2.
Expected result: Same output from both.
Actual: The former results in a mess that, among other inefficiencies, loads
c[0] twice.
Online reproducer: https://godbolt.org/z/E4vEshvcM
(I don't know if this is an RTL or tree optimizer issue, I just guessed. Feel
free to move it if it's wrong.)
[Bug tree-optimization/115423] Inlined strcmp optimizes poorly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115423
--- Comment #3 from Alfred Agrell ---
strcmp (c, "ABCDEFGHabcdefgh") || strcmp (c, "ABCDEFGHfoobar") can safely be
optimized to 1, you're thinking of strcmp(c, "ABCDEFGHabcdefgh")==0 ||
strcmp(c, "ABCDEFGHfoobar")==0.
Optimizing to multi-byte reads would be a wrong-code. If strcmp(c, "1234567")
does an eight-byte read, it'll segfault if c is {'e',0} four bytes before an
unmapped page.
Even if limiting it to aligned reads (can't segfault without crossing a page),
it'll annoy Valgrind.
(Large reads would be safe if lhs is char[8] and not char*, or if strlen is
checked before doing those reads, but both of those feel unlikely to me.)
[Bug c++/115318] decltype(lambda) from an template function inside a templated lambda causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115318
--- Comment #2 from Alfred Agrell ---
struct a { int c; };
template
struct ddd {
int f()
{
using a2 = decltype([](int a::*)->a{}(&a::c));
return [](int a2::*){ return 2; }(&a::c);
}
};
int xs() { return ddd().f(); }
-std=c++20 again
-> :8:16: sorry, unimplemented: mangling offset_ref
https://godbolt.org/z/4M3ToqqPW
Adding a to the first lambda changes the error to the same ICE as this
issue (https://godbolt.org/z/Pq9T16GvP), so I'm about 98% sure it's the same
root cause.
[Bug rtl-optimization/117393] New: Consider inlining memcmp(a, b, small constant)==0 on -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117393
Bug ID: 117393
Summary: Consider inlining memcmp(a, b, small constant)==0 on
-Os
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
int square(char* a, char* b) {
return !__builtin_memcmp(a, b, 4);
}
-Os
Expected:
square(char*, char*):
mov eax, DWORD PTR [rsi]
cmp DWORD PTR [rdi], eax
seteal
movzx eax, al
ret
Actual:
square(char*, char*):
pushrax
mov edx, 4
callmemcmp
pop rdx
testeax, eax
seteal
movzx eax, al
ret
It is inlined for sizes 0 and 1, but I'd expect 2, 4, 8 and 16 to be inlined as
well.
https://godbolt.org/z/7WEzWT6se
[Bug libstdc++/116903] c++ regex accepts } and ] as a literal character.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116903
Alfred Agrell changed:
What|Removed |Added
CC||blubban at gmail dot com
--- Comment #3 from Alfred Agrell ---
https://262.ecma-international.org/#prod-SyntaxCharacter says
SyntaxCharacter :: one of
^ $ \ . * + ? ( ) [ ] { } |
PatternCharacter ::
SourceCharacter but not SyntaxCharacter
so I believe that regex is, in fact, invalid, and browsers accepting it is some
kind of compatibility extension.
But I agree it's complicated. Does the C++ spec ever say which version of
ECMA-262 those regexes should match?
[Bug tree-optimization/118316] New: Missed optimization: while (len > 1) len -= 2;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118316
Bug ID: 118316
Summary: Missed optimization: while (len > 1) len -= 2;
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
unsigned foo(char* buf, unsigned len)
{
while (len > 1)
len -= 2;
if (len)
*buf = 42;
return len;
}
unsigned bar(char* buf, unsigned len)
{
len %= 2;
if (len)
*buf = 42;
return len;
}
-O2
Result:
foo(char*, unsigned int):
mov eax, esi
and eax, 1
cmp esi, 1
cmovbe eax, esi
testeax, eax
je .L1
mov BYTE PTR [rdi], 42
.L1:
ret
bar(char*, unsigned int):
mov eax, esi
and eax, 1
je .L9
mov BYTE PTR [rdi], 42
.L9:
ret
Expected: Same for both
Reduced from an implementation of to_chars(int) using a two-chars-at-the-time
char[200] lookup table.
All three major compilers get confused by that code.
https://godbolt.org/z/1W1hroc67
[Bug c++/118073] New: Bad diagnostic: 'nontype_argument_pack' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118073
Bug ID: 118073
Summary: Bad diagnostic: 'nontype_argument_pack' not supported
by dump_expr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
template
struct index_sequence {};
void foo()
{
index_sequence<5> bar = index_sequence<1>();
}
No flags needed.
Expected:
: In function 'void foo()':
:6:29: error: conversion from 'index_sequence<1>' to non-scalar type
'index_sequence<5>' requested
6 | index_sequence<5> bar = index_sequence<1>();
| ^~~
Actual:
: In function 'void foo()':
:6:29: error: conversion from 'index_sequence<'nontype_argument_pack'
not supported by dump_expr>' to non-scalar type
'index_sequence<'nontype_argument_pack' not supported by dump_expr>' requested
6 | index_sequence<5> bar = index_sequence<1>();
| ^~~
GCC gives the expected error in gcc 4.4 through 7.x (older untested, Godbolt
coverage is spotty below 4.5); gives a slightly different error in 8.x and 9.x,
and gives this output in 10.x through 14.x and trunk-20241216.
https://godbolt.org/z/ohK3M69s7
[Bug libstdc++/119469] New: iter_rvalue_reference_t is wrong for function types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119469
Bug ID: 119469
Summary: iter_rvalue_reference_t is wrong for function types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
bool a1() { return std::is_same_v,
int(&)(int)>; }
bool a2() { return std::is_same_v,
int(&&)(int)>; }
bool a3() { return std::is_same_v,
int(int)>; }
bool a4() { return std::is_same_v,
int(*)(int)>; }
template
using alt_iter_rvalue_reference_t =
decltype(std::ranges::iter_move(std::declval()));
bool b1() { return std::is_same_v,
int(&)(int)>; }
bool b2() { return std::is_same_v,
int(&&)(int)>; }
bool b3() { return std::is_same_v,
int(int)>; }
bool b4() { return std::is_same_v,
int(*)(int)>; }
Expected: Since the spec defines iter_rvalue_reference_t as
decltype(std::ranges::iter_move(std::declval())), the two sets of functions
should be identical (according to Clang and the MSVC STL head maintainer, the
correct answer is a1/b1)
Actual: a2 and b1 are true (it's a4/b4 on MSVC, due to a compiler bug)
https://godbolt.org/z/bTGbKr3ee
[Bug libstdc++/119505] New: : Undefined backreferences should match empty string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119505
Bug ID: 119505
Summary: : Undefined backreferences should match empty
string
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
int main()
{
std::string s{"a"};
std::regex r{"(b)?\\1"};
std::smatch m;
bool result = std::regex_search(s, m, r);
printf("search=%d\n", result);
}
Expected: Return true, because the capture group fails to match and is skipped,
and the backreference then matches the empty string, per
https://262.ecma-international.org/5.1/#sec-15.10.2.9 5.3.
Actual: Returns false.
https://godbolt.org/z/5v8Yjqnd6
libc++ has the same bug. https://github.com/llvm/llvm-project/issues/133360
[Bug libstdc++/119506] New: : \cA matches wrong byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119506
Bug ID: 119506
Summary: : \cA matches wrong byte
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
int main()
{
std::regex r{"\\cA"};
std::cmatch m;
bool result1 = std::regex_search("\x01", m, r);
printf("search=%d\n", result1);
bool result2 = std::regex_search("A", m, r);
printf("search=%d\n", result2);
try {
std::regex r2{"\\c+"};
puts("valid");
} catch (const std::exception&) {
puts("invalid");
}
}
Expected: True, false, invalid.
Actual: False, true, valid. libstdc++-v3/include/bits/regex_scanner.tcc line
351 just takes the character after \c as a literal.
https://godbolt.org/z/h7M76dej5
[Bug libstdc++/119708] New: : \00 should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119708
Bug ID: 119708
Summary: : \00 should be rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
int main() {
try {
std::regex r{"\\00"};
puts("valid");
} catch (const std::exception& e) {
printf("not valid: %s\n", e.what());
}
try {
std::regex r{"\\01"};
puts("valid");
} catch (const std::exception& e) {
printf("not valid: %s\n", e.what());
}
}
Expected: Reject them. 00 and 01 do not match DecimalIntegerLiteral in the JS
spec, and lookahead can't be a digit either.
Actual: Both are valid. (Can't find what they're actually parsed as, though.)
https://godbolt.org/z/heM1o1aGe
libc++ has the same bug. https://github.com/llvm/llvm-project/issues/135048
[Bug libstdc++/119708] : \00 should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119708 --- Comment #2 from Alfred Agrell --- No, bug 84110 looks unrelated to me. That bug refers to actual 0x00 bytes in the input regex. This bug is about how the regex parser treats backslashes.
[Bug libstdc++/119708] : \00 should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119708 --- Comment #4 from Alfred Agrell --- No, that's not relevant to this bug either (though it is relevant to bug 109993). This bug is about ECMAScript flavor regex, not the POSIX ones.
[Bug libstdc++/119813] New: std::is_invocable thinks void can be passed to ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119813
Bug ID: 119813
Summary: std::is_invocable thinks void can be passed to ...
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
void a(...);
bool b()
{
return std::is_invocable_v;
}
template
bool c()
{
return requires { a(std::declval()); };
}
bool d() { return c(); }
or, somewhat shorter:
#include
static_assert(!std::is_invocable_v);
Expected: Both b and d should be false. declval() is illegal, so so the
expression INVOKE(declval(), declval()...) is not well-formed
when treated as an unevaluated operand.
Actual: b is true, d is false.
https://godbolt.org/z/3KK63MYxY
[Bug c++/119814] New: requires-clauses think void can be passed to ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119814
Bug ID: 119814
Summary: requires-clauses think void can be passed to ...
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
void a(...);
template
bool b()
{
return requires { v(v(1)); };
}
bool c() { return b(); }
Expected: False. a(1) is void, and cannot be passed to a(), even if it's hidden
behind a template parameter.
Actual: True.
https://godbolt.org/z/rvv4aWj15
See also bug 119813, though I suspect the actual root causes are different.
[Bug c++/119814] requires-clauses think void can be passed to ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119814 Alfred Agrell changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/135694 --- Comment #3 from Alfred Agrell --- That Clang repro looks pretty similar to the one I reported yesterday. Don't know if it's the same one, but definitely a relative, at least. https://github.com/llvm/llvm-project/issues/135694 (I have no real-world usecase for this stuff, I just shoved nonsense into compilers out of boredom.)
[Bug c++/118917] New: 'class declared private here' points to definition instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118917
Bug ID: 118917
Summary: 'class declared private here' points to definition
instead
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
class a {
private:
class b;
};
class a::b {};
void c(a::b&) {}
Expected:
: In function 'void c(a::b&)':
:6:11: error: 'class a::b' is private within this context
6 | void c(a::b&) {}
| ^
:3:11: note: declared private here
3 | class b;
| ^
Actual:
: In function 'void c(a::b&)':
:6:11: error: 'class a::b' is private within this context
6 | void c(a::b&) {}
| ^
:5:10: note: declared private here
5 | class a::b {};
| ^
That's the definition, not the declaration; it's not where the class is made
private.
If you remove line 5, it correctly points to the declaration on line 3.
[Bug sanitizer/118972] New: Missing ubsan complaint for double->int cast overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118972
Bug ID: 118972
Summary: Missing ubsan complaint for double->int cast overflow
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
int main()
{
double max = __DBL_MAX__;
__builtin_printf("%x\n", (int)(double)max);
__builtin_printf("%x\n", (int)(double)__DBL_MAX__);
}
-O0 -fsanitize=undefined -Wall -Wextra
Expected: Two UBSan complaints or compiler warnings. Or, if GCC defines some
particular semantics for overflowing double->int casts, at least return the
same number for both.
Actual:
8000
7fff
Clang's UBSan complains about both, as expected (then returns different
numbers, but that's fine, it's UB). https://godbolt.org/z/8rK7co19s
[Bug rtl-optimization/118947] New: Missed optimization: GCC forgets stack buffer contents across function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118947
Bug ID: 118947
Summary: Missed optimization: GCC forgets stack buffer contents
across function call
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
void* aaa();
void* bbb()
{
void* ret = aaa();
char buf[32] = {};
__builtin_memcpy(ret, buf, 32);
return ret;
}
void* ccc()
{
char buf[32] = {};
void* ret = aaa();
__builtin_memcpy(ret, buf, 32);
return ret;
}
-O3
Expected: Same for both.
Actual:
bbb():
sub rsp, 40
callaaa()
pxorxmm0, xmm0
movups XMMWORD PTR [rax], xmm0
movups XMMWORD PTR [rax+16], xmm0
add rsp, 40
ret
ccc():
sub rsp, 40
pxorxmm0, xmm0
movaps XMMWORD PTR [rsp], xmm0
movaps XMMWORD PTR [rsp+16], xmm0
callaaa()
movdqa xmm0, XMMWORD PTR [rsp]
movups XMMWORD PTR [rax], xmm0
movdqa xmm0, XMMWORD PTR [rsp+16]
movups XMMWORD PTR [rax+16], xmm0
add rsp, 40
ret
https://godbolt.org/z/oTrTxEKc1
(Former isn't fully optimized either, it reserves stack space for buf despite
all accesses being optimized out. Looks like a different issue to me, so I
filed bug 118946.)
[Bug rtl-optimization/118946] New: Missed optimization: GCC reserves stack space for optimized-out variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118946
Bug ID: 118946
Summary: Missed optimization: GCC reserves stack space for
optimized-out variable
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
void* aaa();
void* bbb()
{
void* ret = aaa();
char buf[65536*16];
__builtin_memset(buf, 0, 32);
__builtin_memcpy(ret, buf, 32);
return ret;
}
-O3
Expected:
bbb():
sub rsp, 8
callaaa()
pxorxmm0, xmm0
movups XMMWORD PTR [rax], xmm0
movups XMMWORD PTR [rax+16], xmm0
add rsp, 8
ret
Actual:
bbb():
sub rsp, 1048584
callaaa()
pxorxmm0, xmm0
movups XMMWORD PTR [rax], xmm0
movups XMMWORD PTR [rax+16], xmm0
add rsp, 1048584
ret
https://godbolt.org/z/aMvY5Pz8M
[Bug libstdc++/120212] New: : Optional empty repetitions should not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120212
Bug ID: 120212
Summary: : Optional empty repetitions should not match
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
int main() {
try {
std::string s{"b"};
std::regex r{"(a*)*"};
std::smatch m;
bool result = std::regex_search(s, m, r);
printf("regex_search: %d\n", result);
for (unsigned i = 0; i < m.size(); ++i) {
printf("m[%d]", i);
if (m[i].matched) {
printf(".str(): \"%s\"\n", m[i].str().c_str());
} else {
puts(".matched: false");
}
}
} catch (const std::exception& e) {
printf("Exception: %s\n", e.what());
}
}
Expected: "" and false, per
https://262.ecma-international.org/5.1/#sec-15.10.2.5 note 4.
Actual: "" and "".
https://godbolt.org/z/s7ejf7GKv
Also present in libc++ and ms-stl
https://github.com/llvm/llvm-project/issues/133314
https://github.com/microsoft/STL/issues/5490
[Bug libstdc++/120330] New: regex: [\B] should be legal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120330
Bug ID: 120330
Summary: regex: [\B] should be legal
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
int main()
{
std::regex("[\\B]");
}
Expected: Successfully construct the object; \B means nothing in [], and should
be an identity escape like \Z.
Actual:
terminate called after throwing an instance of 'std::regex_error'
what(): Unexpected character within '[...]' in regular expression
https://godbolt.org/z/z8EWWY8hP
libc++ throws the same error, but for a different reason - it doesn't implement
https://cplusplus.github.io/LWG/issue2584 at all, it throws the same error for
[\Z]. https://github.com/llvm/llvm-project/issues/99976
[Bug c++/120755] New: Catching reference to array also catches thrown pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120755
Bug ID: 120755
Summary: Catching reference to array also catches thrown
pointers
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
int main()
{
int* var = nullptr;
try { throw var; }
catch (int(&)[8]) { return 1; }
catch (...) { return 0; }
}
Expected: Return 0, and/or throw a compile error or warning about array
references being uncatchable (they decay to pointers if thrown).
Actual: Returns 1, despite nobody throwing a reference to size-8 array.
https://godbolt.org/z/xnaa6r4T6
[Bug c++/120754] New: Segfault when trying to print error about catching function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120754
Bug ID: 120754
Summary: Segfault when trying to print error about catching
function type
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
template
void fn()
{
try {}
catch (T) {}
}
int main() { fn(); }
Expected: Print a proper error, something like the 'error: variable 'v' has
function type' I get if the variable is named in the catch block.
Actual: Just says 'confused by earlier errors, bailing out' despite not
printing any earlier errors.
(Oddly enough, Clang and MSVC are fine with that input, both with and without
variable name. I think they're wrong.)
With Godbolt's GCC-assertions edition https://godbolt.org/z/16fcYxT7e,
: In instantiation of 'void fn() [with T = int(int)]':
:7:26: required from here
7 | int main() { fn(); }
| ^~
Segmentation fault
5 | catch (T) {}
|^
0x31c6425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x31dd3f6 internal_error(char const*, ...)
???:0
0x3200bd3 pretty_printer::format(text_info&)
???:0
0x31c60af diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x31c6425 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x31dca66 error(char const*, ...)
???:0
0x1299534 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x128c1cd instantiate_decl(tree_node*, bool, bool)
???:0
0x12c67cb instantiate_pending_templates(int)
???:0
0x114b710 c_parse_final_cleanups()
???:0
0x13c40d8 c_common_parse_file()
???:0
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.
[Bug c++/120754] [12/13/14/15/16 Regression] Segfault when trying to print error about catching function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120754 --- Comment #2 from Alfred Agrell --- Per the linked Clang bug, this isn't ice-on-invalid - it's ice-on-valid (though implausible, of course). And if the variable is named, it's a rejects-valid. https://eel.is/c++draft/except#handle-2 > A handler of type "array of T" or function type T is adjusted to be of type > "pointer to T". I don't know if this still counts as a regression, so I can't update the keywords.
