[Bug ipa/119292] code deduplication in case of throw (improvement)

2025-03-15 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119292 --- Comment #3 from Federico Kircheis --- (In reply to Andrew Pinski from comment #2) > . You where faster than me; but I cannot add this url to "See Also": https://developercommunity.visualstudio.com/t/code-deduplication-in-case-of-throw/1087

[Bug c++/119292] New: code deduplication in case of throw (improvement)

2025-03-14 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119292 Bug ID: 119292 Summary: code deduplication in case of throw (improvement) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug c++/116909] Does g++ define the behavior for an "array" manually created with a linker script?

2024-10-01 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116909 --- Comment #3 from Federico Kircheis --- Thank you for the fast response @Andrew Pinski , I'm sorry to have made a duplicate questino. This is what I've understood: 1) does g++ specify the behavior of the program in this case? The answer is

[Bug c++/116909] Does g++ define the behavior for an "array" manually created with a linker script?

2024-10-01 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116909 --- Comment #6 from Federico Kircheis --- Thank, I think this covers all my concern. Nevertheless I was still looking how to avoid the assembly, eventually to be sure to have a more portable piece of code (with less ifdefs) between compilers

[Bug c++/116909] New: Does g++ define the behavior for an "array" manually created with a linker script?

2024-09-30 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116909 Bug ID: 116909 Summary: Does g++ define the behavior for an "array" manually created with a linker script? Product: gcc Version: 15.0 Status: UNCONFIRMED Sever

[Bug c++/115670] auto placeholder for return type should change the linkage of the function if the type becomes local linkage too

2024-06-30 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115670 --- Comment #7 from Federico Kircheis --- I've made a similar report to clang (https://github.com/llvm/llvm-project/issues/97162) and they found another function that could be optimized out ~~~ auto foo7() { return 1; } ~~~ They made me also r

[Bug c++/115670] auto placeholder for return type should change the linkage of the function if the type becomes local linkage too

2024-06-27 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115670 --- Comment #4 from Federico Kircheis --- Sorry, I've posted the wrong link in the previous reply, this is the correct one https://godbolt.org/z/nhrM46ajs Also struct s2{ s i; //s is in anonymous namespace }; s2 foo6(){ return

[Bug c++/115670] auto placeholder for return type should change the linkage of the function if the type becomes local linkage too

2024-06-27 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115670 --- Comment #3 from Federico Kircheis --- I've collected the example mentioned here and in my original report https://godbolt.org/z/o4893zhPs struct { int i = 42; } const a; auto foo0(){ return a; } int foo1(decltype(a)&){

[Bug c++/115670] New: missed optimization - anonymous structures

2024-06-26 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115670 Bug ID: 115670 Summary: missed optimization - anonymous structures Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/113349] New: internal compiler error: in tsubst

2024-01-12 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113349 Bug ID: 113349 Summary: internal compiler error: in tsubst Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/112553] noexcept lambda does not generate call to terminate

2023-11-15 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112553 --- Comment #3 from Federico Kircheis --- I stand corrected, sorry for the report. Where can I find official information/documentation about the personality function used by gcc? The fact that clang and msvc handle this case differently made

[Bug c++/112553] New: noexcept lambda does not generate call to terminate

2023-11-15 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112553 Bug ID: 112553 Summary: noexcept lambda does not generate call to terminate Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Compo

[Bug c++/112546] -Wmaybe-uninitialized and -Wuninitialized does not detect usage of uninitilazed value in a lambda

2023-11-15 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112546 --- Comment #1 from Federico Kircheis --- I looked at some reports at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 It seems that most related issues rely on global variables or parameters, but in fact I found some other examples with loca

[Bug c++/112546] New: -Wmaybe-uninitialized and -Wuninitialized does not detect usage of uninitilazed value in a lambda

2023-11-15 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112546 Bug ID: 112546 Summary: -Wmaybe-uninitialized and -Wuninitialized does not detect usage of uninitilazed value in a lambda Product: gcc Version: 13.2.1 Status: UNCONFIRME

[Bug c++/112335] missed optimization on reset and assign unique_ptr

2023-11-03 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335 --- Comment #9 from Federico Kircheis --- Great, thank you for the clarifications, your redacted example makes now sense. > https://godbolt.org/z/WGPTesEb3 shows that bar3 is not the same as bar1, > because it runs an additional destructor if

[Bug c++/112335] missed optimization on reset and assign unique_ptr

2023-11-03 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335 --- Comment #7 from Federico Kircheis --- Thank you Jonathan, I've then misunderstood the example of Andrew, I thought he was trying to create a scenario where after reset the pointer is not nullptr. > Demo: https://godbolt.org/z/PWd96j4fz Tha

[Bug c++/112335] missed optimization on reset and assign unique_ptr

2023-11-02 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335 --- Comment #5 from Federico Kircheis --- Ok, the described case would be something like std::unique_ptr t; __thread bool tt; inline s::~s() { if (tt) return; tt = true; t.reset(new s); tt = false; } std::unique_ptr t2; bar(t,

[Bug c++/112335] missed optimization on reset and assign unique_ptr

2023-11-02 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335 --- Comment #3 from Federico Kircheis --- Or maybe I've misunderstood your comment. Do you have a specific scenario in mind where the two snippets would exhibit different behaviors?

[Bug c++/112335] missed optimization on reset and assign unique_ptr

2023-11-02 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335 --- Comment #2 from Federico Kircheis --- > Well s::~s could touch the reference std::unique_ptr (ps1). In both cases, s::~s is called only once. Also during the move-assignment no user-provided-code is involved (except the destruction of ps1,

[Bug c++/112335] New: missed optimization on reset and assign unique_ptr

2023-11-01 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112335 Bug ID: 112335 Summary: missed optimization on reset and assign unique_ptr Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug c++/111388] New: std:.get_if variant, unnecessary branch when outside of if statement

2023-09-12 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111388 Bug ID: 111388 Summary: std:.get_if variant, unnecessary branch when outside of if statement Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal

[Bug c++/101557] the value of '' is not usable in a constant expression

2023-04-16 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557 --- Comment #5 from Federico Kircheis --- Today I just found a possible workaround that involves macros and lambdas... struct node { const char* d; const node& left; }; #define LEAF(a) []()-> const node&{ constexpr static auto a =

[Bug c++/107264] New: -O1 disables -Wfree-nonheap-object on a map

2022-10-14 Thread federico at kircheis dot it via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107264 Bug ID: 107264 Summary: -O1 disables -Wfree-nonheap-object on a map Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c+