[Bug c++/115417] New: Destructor is noexcept even though the class has a throwing destructor subobject in an anonymous union

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115417 Bug ID: 115417 Summary: Destructor is noexcept even though the class has a throwing destructor subobject in an anonymous union Product: gcc Version: 15.0 Status:

[Bug tree-optimization/115147] exp2 with integer arguments could be translated into ldexp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115147 --- Comment #1 from Jan Schultke --- I did some quick low-quality benchmarks. It doesn't seem to make any kind of difference for libc++ and clang: https://quick-bench.com/q/aq1mZ1sKTWHzdmZf5D7BO2yJ1Yo (or for libstdc++ and clang) For GCC and

[Bug tree-optimization/115147] New: exp2 with integer arguments could be translated into ldexp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115147 Bug ID: 115147 Summary: exp2 with integer arguments could be translated into ldexp Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug c++/115085] Variable unqualified-id is falsely treated as rvalue when appearing in braced-init-list

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085 --- Comment #4 from Jan Schultke --- https://github.com/cplusplus/CWG/issues/536

[Bug c++/115085] Variable unqualified-id is falsely treated as rvalue when appearing in braced-init-list

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085 --- Comment #1 from Jan Schultke --- Another user suggested that this is caused by falsely performing temporary materialization. This would make a an xvalue, which would also make the reference binding fail.

[Bug c++/115085] New: Variable unqualified-id is falsely treated as rvalue when appearing in braced-init-list

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115085 Bug ID: 115085 Summary: Variable unqualified-id is falsely treated as rvalue when appearing in braced-init-list Product: gcc Version: 15.0 Status: UNCONFIRMED

[Bug c++/55004] [meta-bug] constexpr issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 114219, which changed state. Bug 114219 Summary: [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes

[Bug c++/114219] [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 Jan Schultke changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/114219] [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 --- Comment #4 from Jan Schultke --- I don't see how lvalue-to-rvalue conversion would be bypassed here. https://eel.is/c++draft/conv.lval#:conversion,lvalue-to-rvalue has no special provision for empty classes.

[Bug c++/114219] [11/12/13/14 Regression] [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 --- Comment #2 from Jan Schultke --- Corresponding LLVM bug: https://github.com/llvm/llvm-project/issues/83712

[Bug c++/114219] New: [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114219 Bug ID: 114219 Summary: [expr.const] lvalue-to-rvalue conversion is not diagnosed to disqualify constant expressions for empty classes Product: gcc Version:

[Bug middle-end/114086] Boolean switches could have a lot better codegen, possibly utilizing bit-vectors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086 --- Comment #5 from Jan Schultke --- Well, it's not quite equivalent to either of the bit-shifts we've posted. To account for shifting more than the operand size, it would be: bool foo (int x) { return x > 6 ? 0 : ((85 >> x) & 1); } This

[Bug middle-end/114086] Boolean switches could have a lot better codegen, possibly utilizing bit-vectors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086 --- Comment #2 from Jan Schultke --- Yeah right, the actual optimal output (which clang finds) is: > test_switch(E): > test edi, -7 > sete al > ret Testing with -7 also makes sure that the 8-bit and greater are all zero.

[Bug middle-end/114086] New: Boolean switches could have a lot better codegen, possibly utilizing bit-vectors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086 Bug ID: 114086 Summary: Boolean switches could have a lot better codegen, possibly utilizing bit-vectors Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c++/114006] New: False positive diagnostic -Wpedantic for zero-size arrays, most vexing parse

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114006 Bug ID: 114006 Summary: False positive diagnostic -Wpedantic for zero-size arrays, most vexing parse Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug middle-end/113988] during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988 --- Comment #2 from Jan Schultke --- Oh yeah, I should have noted that this only happens for AVX-512 targets. Changing -march=znver4 to -march=znver3 stops the ICE.

[Bug c++/113988] New: during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988 Bug ID: 113988 Summary: during GIMPLE pass: bitintlower: internal compiler error: in lower_stmt, at gimple-lower-bitint.cc:5470 Product: gcc Version: 14.0 Status:

[Bug c++/113982] New: Poor codegen for 64-bit add with carry widening functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113982 Bug ID: 113982 Summary: Poor codegen for 64-bit add with carry widening functions Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug c++/113914] New: GCC accepts user-defined integer-literal that does not fit in any type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113914 Bug ID: 113914 Summary: GCC accepts user-defined integer-literal that does not fit in any type Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug c++/113821] New: Missed optimization for final classes: expensive check for result of dynamic cast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113821 Bug ID: 113821 Summary: Missed optimization for final classes: expensive check for result of dynamic cast Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c++/113745] New: Poor diagnostics quality for resize() without a default-constructible type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113745 Bug ID: 113745 Summary: Poor diagnostics quality for resize() without a default-constructible type Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug c++/113581] Ignoring GCC unroll loop annotation for loops with increment in condition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113581 --- Comment #1 from Jan Schultke --- Oh, I probably should have mentioned this: This only happens when times_three is a function template.

[Bug c++/113581] New: Ignoring GCC unroll loop annotation for loops with increment in condition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113581 Bug ID: 113581 Summary: Ignoring GCC unroll loop annotation for loops with increment in condition Product: gcc Version: 14.0 Status: UNCONFIRMED Severity:

[Bug c++/113565] __builtin_clz(0) is undefined behavior, but not detected in constant expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565 --- Comment #5 from Jan Schultke --- You can reproduce this as follows: > static_assert(__builtin_clz(0u) == 32); > > unsigned x = 0; > > int main() { > return __builtin_clz(x); > } For base x86_64, GCC emits:

[Bug c++/113565] __builtin_clz(0) is undefined behavior, but not detected in constant expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565 --- Comment #4 from Jan Schultke --- I would expect an error here because things that are undefined behavior are generally supposed to fail in constant expressions. I don't see a good reason why builtins should be exempt from that rule. The

[Bug c++/113565] New: __builtin_clz(0) is undefined behavior, but not detected in constant expressions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565 Bug ID: 113565 Summary: __builtin_clz(0) is undefined behavior, but not detected in constant expressions Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c++/113564] New: ICE internal compiler error when calling a concept as a function in a template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113564 Bug ID: 113564 Summary: ICE internal compiler error when calling a concept as a function in a template Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c++/113543] New: Poor codegen for bit-counting functions (countl_zero, countl_one, countr_zero, countr_one)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113543 Bug ID: 113543 Summary: Poor codegen for bit-counting functions (countl_zero, countl_one, countr_zero, countr_one) Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386 --- Comment #7 from Jan Schultke --- I've noticed that too by now. What confuses me is that both libc++ and MSVC STL implement it as if it was a DR, so transparent comparisons work even outside C++23 mode. Is it just a collective mistake, or

[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386 --- Comment #5 from Jan Schultke --- My bad again, it's a defect report, so cppreference is fine.

[Bug libstdc++/113386] [C++23] std::pair comparison operators should be transparent, but are not in libstdc++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386 --- Comment #4 from Jan Schultke --- My bad. https://en.cppreference.com/w/cpp/utility/pair/operator_cmp currently shows > template< class T1, class T2, class U1, class U2 > > bool operator==( const std::pair& lhs, const std::pair& rhs ); >

[Bug libstdc++/113386] std::pair comparison operators should be transparent, but are not in libstdc++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386 --- Comment #1 from Jan Schultke --- https://godbolt.org/z/9x9n4bGKK

[Bug libstdc++/113386] New: std::pair comparison operators should be transparent, but are not in libstdc++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386 Bug ID: 113386 Summary: std::pair comparison operators should be transparent, but are not in libstdc++ Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c++/113274] Memoization in template parameters is overly aggressive; false memoization for const pointers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113274 --- Comment #2 from Jan Schultke --- OOPS, I've messed up the repro. It should be true in the partial specialization. https://godbolt.org/z/11dW3cTfc

[Bug c++/113274] Memoization in template parameters is overly aggressive; false memoization for const pointers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113274 --- Comment #1 from Jan Schultke --- Original problem and more discussion: https://stackoverflow.com/q/4976/5740428

[Bug c++/113274] New: Memoization in template parameters is overly aggressive; false memoization for const pointers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113274 Bug ID: 113274 Summary: Memoization in template parameters is overly aggressive; false memoization for const pointers Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c++/113242] New: g++ rejects-valid template argument of class type containing an lvalue reference

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113242 Bug ID: 113242 Summary: g++ rejects-valid template argument of class type containing an lvalue reference Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c++/111662] Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111662 --- Comment #2 from Jan Schultke --- Bug was originally discovered here: https://stackoverflow.com/questions/77214665/problem-creating-template-function-alias-with-const-value-template-arguments/77215223#77215223

[Bug c++/111662] Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111662 --- Comment #1 from Jan Schultke --- See https://godbolt.org/z/Kaf7jETaY

[Bug c++/111662] New: Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111662 Bug ID: 111662 Summary: Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types Product: gcc Version: 14.0

[Bug c++/111277] New: braced-init-list allowed in a template-argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111277 Bug ID: 111277 Summary: braced-init-list allowed in a template-argument Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/57905] braced-init-list allowed in default template-argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57905 Jan Schultke changed: What|Removed |Added CC||janschultke at googlemail dot com ---

[Bug c++/111174] New: G++ allows re-declaring function parameters as functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74 Bug ID: 74 Summary: G++ allows re-declaring function parameters as functions Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug c++/111173] G++ allows constinit functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73 --- Comment #2 from Jan Schultke --- I think the problem is that GCC treats "constinit" exactly like "const" for the purpose of diagnostics. In https://eel.is/c++draft/dcl.fct#11, it is said that const applied to functions is ignored. GCC

[Bug c++/111173] New: G++ allows constinit functions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73 Bug ID: 73 Summary: G++ allows constinit functions Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/111079] New: Failing to reject a defaulted/deleted local function definition if it is a friend of a local class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111079 Bug ID: 111079 Summary: Failing to reject a defaulted/deleted local function definition if it is a friend of a local class Product: gcc Version: 14.0 Status:

[Bug libstdc++/110945] std::basic_string::assign dramatically slower than other means of copying memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945 --- Comment #8 from Jan Schultke --- (In reply to Jonathan Wakely from comment #4) > Please provide the testcase in a usable form, not just a link to an external > site (which uses its own custom benchmark macros). This is requested at >

[Bug libstdc++/110945] std::basic_string::assign dramatically slower than other means of copying memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945 --- Comment #3 from Jan Schultke --- When increasing the input size to 8 MiB, the results become more similar to what clang delivers for 1 MiB too: https://quick-bench.com/q/DFHYW6eZq-FAif8xuLkBOPwzYWA

[Bug libstdc++/110945] std::basic_string::assign dramatically slower than other means of copying memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945 --- Comment #2 from Jan Schultke --- Also it looks like GCC doesn't emit memcpy or memmove in either of the first benchmarks. Those statements refer to the corresponding clang output, actually. What's consistent for both compilers is that

[Bug libstdc++/110945] std::basic_string::assign dramatically slower than other means of copying memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945 Jan Schultke changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from

[Bug libstdc++/110945] New: std::basic_string::assign dramatically slower than other means of copying memory

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110945 Bug ID: 110945 Summary: std::basic_string::assign dramatically slower than other means of copying memory Product: gcc Version: 12.2.0 Status: UNCONFIRMED

[Bug c++/110912] False assumption that constructors cannot alias any of their parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110912 --- Comment #2 from Jan Schultke --- (In reply to Jiang An from comment #1) > The restriction agains aliasing was intended, see > https://cplusplus.github.io/CWG/issues/2271.html. > > The status quo seems to be that in the body of `A::A(int

[Bug c++/110925] New: Unnecessary dynamic initialization in trivial cases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110925 Bug ID: 110925 Summary: Unnecessary dynamic initialization in trivial cases Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/110916] New: [12/13/14 Regression] Architecture-dependent missed optimizations for double swapping

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110916 Bug ID: 110916 Summary: [12/13/14 Regression] Architecture-dependent missed optimizations for double swapping Product: gcc Version: 14.0 Status: UNCONFIRMED

[Bug c++/110912] New: False assumption that constructors cannot alias any of their parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110912 Bug ID: 110912 Summary: False assumption that constructors cannot alias any of their parameters Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: