[Bug c++/92579] New: compiler rejects list initialization of character array member from string literal in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92579
Bug ID: 92579
Summary: compiler rejects list initialization of character
array member from string literal in return statement
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
The following code will reproduce the issue (seems to affect all versions of
gcc that support C++11):
struct blub
{
char a[5];
};
blub f()
{
return {"asdf"}; // error: could not convert '{"asdf"}' from
'' to 'blub'
// return {{'a', 's', 'd', 'f', '\0'}}; // OK
// return blub {"asdf"}; // OK
}
[Bug c++/101463] New: Using a constexpr variable template specialization as default argument for non-type template parameter of reference type leads gcc to reject function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101463
Bug ID: 101463
Summary: Using a constexpr variable template specialization as
default argument for non-type template parameter of
reference type leads gcc to reject function call
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
The following code will reproduce the issue:
extern const int a;
template
constexpr const int& blub = a;
template >
void f() {}
int main()
{
f(); // error: no matching function for call to
'f()'
f>(); // ok
}
Note: gcc will accept the function call when the exact same template argument
is explicitly specified instead.
godbolt link: https://godbolt.org/z/jd3EGWEfo
[Bug c++/114275] New: using std::thread within a templated function in a module fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275
Bug ID: 114275
Summary: using std::thread within a templated function in a
module fails to compile
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
The following example will reproduce the issue:
// A.ixx
module;
#include
export module A;
export void fun(auto&&)
{
std::thread([]{}).join();
}
// main.cpp
import A;
int main()
{
fun(42);
}
build with
g++ -std=c++23 -fmodules-ts -c -x c++ A.ixx
g++ -std=c++23 -fmodules-ts main.cpp A.o
results in
‘
/usr/include/c++/13/tuple:491: confused by earlier errors, bailing out
[Bug c++/114298] New: std::lazy_split_view constructor is currently not explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114298 Bug ID: 114298 Summary: std::lazy_split_view constructor is currently not explicit Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michael.kenzel at gmail dot com Target Milestone: --- [range.lazy.split.view][1] specifies the following constructor constexpr explicit lazy_split_view(V base, Pattern pattern); However, libstdc++ seems to currently be missing the explicit: https://github.com/gcc-mirror/gcc/blob/993c6de642ffeb2867edbe80ff2a72c0a2eb604e/libstdc%2B%2B-v3/include/std/ranges#L3589-L3592 [1]: https://eel.is/c++draft/range.lazy.split.view
[Bug libstdc++/114298] std::lazy_split_view constructor is currently not explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114298 --- Comment #1 from Michael Kenzel --- I just learned that this was apparently only added in C++23 (P2711 [1]), so I was likely a bit too quick to open this issue… [1]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2711r1.html
[Bug c++/115351] New: [14 regression] pointless movs when passing by value on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115351
Bug ID: 115351
Summary: [14 regression] pointless movs when passing by value
on x86-64
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
When passing structs of certain shape by value on x86-64 (seems to be specific
to this target), gcc 14 emits (fails to optimize away?) a number of redundant
moves:
struct complex
{
double real;
double imag;
};
complex blub(complex z)
{
return {
z.real * z.real - z.imag * z.imag,
2 * z.real * z.imag
};
}
on gcc 13 with -O3 results in
blub(complex):
movapd xmm3, xmm1
movapd xmm2, xmm0
mulsd xmm3, xmm1
addsd xmm2, xmm2
mulsd xmm0, xmm0
mulsd xmm1, xmm2
subsd xmm0, xmm3
ret
gcc 14 and later with -O3 emit
blub(complex):
movqrax, xmm1
movqrdx, xmm0
xchgrdx, rax
movqxmm2, rax
movqxmm1, rdx
movapd xmm0, xmm2
movapd xmm3, xmm1
mulsd xmm3, xmm1
mulsd xmm0, xmm2
addsd xmm2, xmm2
mulsd xmm1, xmm2
subsd xmm0, xmm3
ret
godbolt: https://godbolt.org/z/hzEfs3ob4
[Bug c++/112631] New: gcc rejects block-scope declaration of function in a module unit even if the function is attached to the global module fragment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112631
Bug ID: 112631
Summary: gcc rejects block-scope declaration of function in a
module unit even if the function is attached to the
global module fragment
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
repro: https://godbolt.org/z/h5f798eEY
export module bla;
extern "C++" inline void fun()
{
void oops(); // error: block-scope extern declaration 'void
oops()' not permitted in module purview
}
fun is not attached to a named module due to being declared with a linkage
specification (https://eel.is/c++draft/module.unit#7.2). thus,
[dcl.meaning.general]/3.5 (https://eel.is/c++draft/dcl.meaning.general#3.5)
should not apply.
[Bug c++/112820] New: vtable not emitted correctly from module when compiling with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112820
Bug ID: 112820
Summary: vtable not emitted correctly from module when
compiling with -g
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
When compiling a class with virtual member functions declared in a module
interface unit and defined in a module implementation unit with -g, the vtable
seems to not get emitted correctly, resulting in linker errors.
example:
// io.ixx
export module io;
export struct error
{
virtual const char* what() const noexcept;
};
// io-impl.cpp
module io;
const char* error::what() const noexcept
{
return "bla";
}
// main.cpp
import io;
int main()
{
error{};
}
compile with
g++ -std=c++23 -fmodules-ts -g -c -x c++ io.ixx
g++ -std=c++23 -fmodules-ts -g -c -x c++ io-impl.cpp
g++ -std=c++23 -fmodules-ts -g -c -x c++ main.cpp
g++ main.o io.o io-impl.o
produces
main.o: in function `error@io::error()':
main.cpp:3:(.text._ZNW2io5errorC2Ev[_ZNW2io5errorC5Ev]+0x8): undefined
reference to `vtable for error@io'
main.cpp:3:(.text._ZNW2io5errorC2Ev[_ZNW2io5errorC5Ev]+0xc): undefined
reference to `vtable for error@io'
Removing the -g from the first two commands resolves the problem, so this seems
to be tied to debugging information somehow. While the vtable will only be
emitted into io-impl.o, interestingly, it is apparently necessary to remove -g
from both the io-impo.o and the io.o commands for the vtable to be emitted.
[Bug c++/112899] New: odr-using constexpr static data member of class exported from module results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112899
Bug ID: 112899
Summary: odr-using constexpr static data member of class
exported from module results in linker error
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
The following example will reproduce the issue:
// A.ixx
export module A;
export struct A
{
static constexpr int blub = -1;
};
// main.cpp
import A;
int main()
{
const int& x = A::blub;
}
compile with
g++ -std=c++23 -fmodules-ts -c -x c++ A.ixx
g++ -std=c++23 -fmodules-ts main.cpp A.o
results in
main.cpp:(.text+0x4): undefined reference to `A@A::blub'
[Bug c++/113153] New: suboptimal error message when using reserved identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113153
Bug ID: 113153
Summary: suboptimal error message when using reserved
identifier
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
When using a keyword as the name of an enum, gcc will issue a diagnostic about
the enum being "unnamed". This can be very confusing:
enum class register { rax, rcx, rdx, rbx };
compiled with -std=c++23 produces
error: unnamed scoped enum is not allowed
1 | enum class register {};
|^~~~
warning: elaborated-type-specifier for a scoped enum must not use the 'class'
keyword
1 | enum class register {};
| ^
| -
error: expected identifier before 'register'
1 | enum class register {};
|^~~~
error: expected unqualified-id before '{' token
1 | enum class register {};
| ^
https://godbolt.org/z/s1ocevaWe
[Bug c++/113580] New: -Wunused-parameter in template imported from module causes segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113580
Bug ID: 113580
Summary: -Wunused-parameter in template imported from module
causes segmentation fault
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
The following example will reproduce the issue:
// A.ixx
export module A;
export void fun(auto&& x) {}
// main.cpp
import A;
int main()
{
fun(42);
}
g++ -std=c++23 -fmodules-ts -c -x c++ A.ixx
g++ -std=c++23 -Wunused-parameter -fmodules-ts main.cpp A.o
results in
Segmentation fault
0x7ff37686550f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7ff37697e159 __strlen_avx2
../sysdeps/x86_64/multiarch/strlen-avx2.S:76
0x7ff3768506c9 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7ff376850784 __libc_start_main_impl
../csu/libc-start.c:360
[Bug c++/115626] New: relax -Wsign-conversion when initializing from a literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115626 Bug ID: 115626 Summary: relax -Wsign-conversion when initializing from a literal Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michael.kenzel at gmail dot com Target Milestone: --- Initializing an unsigned integer like unsigned int mask = -1; or unsigned int mask = ~0; is common practice, guaranteed to produce the desired value, and arguably the idiomatic way to initialize a bitmask to all bits set. Alternatives like explicitly providing the unsigned value unsigned long mask = 0xUL; are error prone, not generic, not portable as they cannot account for the varying width of types across target platforms, and may not work reliably for types for which no literal suffixes exist (e.g.: extended integer types). Mixing signed and unsigned arithmetic is a prolific source of bugs. Thus, enabling -Wsign-conversion is generally a good idea. However, doing so can lead to copious amounts of false positives in code that is heavy on the use of bitmasks. Quieting these warnings by means of explicit casts reduces readability. The likelihood that an unsigned integer being initialized from a literal -1 or ~0 constitutes a bug is small, while legitimate and perfectly safe uses of such constructs are ubiquitous. I would like to propose relaxing -Wsign-conversion to not warn upon initialization of an unsigned integer from a literal -1 or ~0 expression, or any unary - or ~ expression with literal operands and a signed value that does not exceed the range of the corresponding signed type, i.e., has a corresponding unsigned value with the same untruncated bit pattern. Maybe even consider allowing any constant expression with such a value. If changing the behavior of -Wsign-conversion is deemed not an option, maybe introducing something like a -Wnonliteral-sign-conversion or -Wnonconstant-sign-conversion option to explicitly opt into the warning only for cases that cannot be classified as most-likely harmless at compile time would be?
[Bug c++/116872] New: gcc accepts unnormalized identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872 Bug ID: 116872 Summary: gcc accepts unnormalized identifiers Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michael.kenzel at gmail dot com Target Milestone: --- According to [lex.name]/1, a program that contains an identifier that's not in Unicode Normalization Form C is ill-formed. gcc does not seem to correctly diagnose this issue. For example, the following code is accepted without error or warning: int \u00B5; // this should be ill-formed, MICRO SIGN cannot appear in NFC
[Bug c++/116872] gcc accepts unnormalized identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872 --- Comment #4 from Michael Kenzel --- Quoting [lex.name]/1 (https://eel.is/c++draft/lex.name#1.sentence-2): The program is ill-formed if an identifier does not conform to Normalization Form C as specified in the Unicode Standard. According to UAX TR#15 (https://unicode.org/reports/tr15/#Norm_Forms), Normalization Form C is formed by Canonical Decomposition followed by Canonical Composition. According to UnicodeData.txt (https://www.unicode.org/Public/reconstructed/1.0.1/UnicodeData.txt) U+00B5 (MICRO SIGN) decomposes to U+03BC (GREEK SMALL LETTER MU). And U+03BC does not recompose to anything else. So unless I'm missing anything, U+00B5 should not be allowed in an identifier.
[Bug c++/116872] gcc accepts unnormalized identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116872 --- Comment #7 from Michael Kenzel --- Oh. Looks like I was looking at the wrong table… Sorry about that 😅
[Bug c++/102194] Incorrect explicit instantiation of constexpr variable accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102194 Michael Kenzel changed: What|Removed |Added CC||michael.kenzel at gmail dot com --- Comment #1 from Michael Kenzel --- I've just stumbled upon this bug as well: template constexpr int c = N; template int c<42>; // should be an error https://godbolt.org/z/jxojs64GK
