[Bug libstdc++/114354] std::shared_ptr constructor constraints are checked too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114354 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #1 from Jiang An --- The constraints were transformed from preconditions by LWG2874 (https://cplusplus.github.io/LWG/issue2874). So perhaps the actually issue is not having implemented LWG2874, and I think the constraints need to be implemented for C++17. The wording change in LWG2874 seems to be on the top of P0414R2 + P0497R0. I'm not sure what the "backported form of LWG2874" exactly is. Perhaps it's simply "This constructor shall not participate in overload resolution unless the expression delete p is well-formed and Y* is convertible to T*." (not considering whether T or Y is an array type)?
[Bug c/114361] New: ICE with c23 when creating mutually nested and compatible types with statement expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361
Bug ID: 114361
Summary: ICE with c23 when creating mutually nested and
compatible types with statement expressions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
This fails in verify_type (goes away with -fchecking=0):
void f()
{
typedef struct foo bar;
typedef __typeof( ({ (struct foo { bar *x; }){ }; }) ) wuz;
struct foo { wuz *x; };
}
https://godbolt.org/z/q7n5xbsc1
[Bug c++/114362] New: wrong error message "too many arguments" with overloaded function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114362
Bug ID: 114362
Summary: wrong error message "too many arguments" with
overloaded function
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
% cat test.cpp
#include
void f ();
void f (int);
void g ()
{
std::tie (f) = 0;
}
% g++ test.cpp
test.cpp: In function 'void g()':
test.cpp:8:12: error: too many arguments to function 'constexpr
std::tuple<_Elements& ...> std::tie(_Elements& ...) [with _Elements = {}]'
[...]
This only happens when f is overloaded. When I comment out either of the two
declarations of f, I get only "error: no match for 'operator='" as expected.
[Bug tree-optimization/114363] New: inconsistent optimization of pow(x,2)+pow(y,2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114363 Bug ID: 114363 Summary: inconsistent optimization of pow(x,2)+pow(y,2) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vincenzo.innocente at cern dot ch Target Milestone: --- while pow(x,2) is optimized in x*x (float x) in pow(x,2)+pow(y,2) x and y are first promoted to double which I find inconsistent see https://godbolt.org/z/rYfoaxr89
[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527 Deepthi H changed: What|Removed |Added CC||deepadeepthi98 at gmail dot com --- Comment #3 from Deepthi H --- I have been investigating this issue further. Hence checking the source code and debugging the gcc sources. However, I wasn't able to find where the COLLECT_GCC_OPTION has been set to 128kb I couldn't find it being set in gcc. Can you please let us know how can we increase the limit of collect options?
[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527 --- Comment #4 from Deepthi H --- I have been investigating this issue further. Hence checking the source code and debugging the gcc sources. However, I wasn't able to find where the COLLECT_GCC_OPTION has been set to 128kb I couldn't find it being set in gcc. Can you please let us know how can we increase the limit of collect options?
[Bug libstdc++/114354] std::shared_ptr constructor constraints are checked too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114354 --- Comment #2 from Jonathan Wakely --- Ah yes, thanks. It looks like I converted them to constraints for array support with g:a2e0054e1d169984ec64d64145b71a88a9628537 but only for the pointer conversions, I missed the delete expression.
[Bug libstdc++/114359] std::binomial_distribution hangs in infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-03-16 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug libstdc++/114359] std::binomial_distribution hangs in infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359 --- Comment #3 from Jonathan Wakely --- This seems to fix it: --- a/libstdc++-v3/include/bits/random.tcc +++ b/libstdc++-v3/include/bits/random.tcc @@ -1503,7 +1503,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION // sqrt(pi / 2) const double __spi_2 = 1.2533141373155002512078826424055226L; _M_s1 = std::sqrt(__np * __1p) * (1 + _M_d1 / (4 * __np)); - _M_s2 = std::sqrt(__np * __1p) * (1 + _M_d2 / (4 * _M_t * __1p)); + _M_s2 = std::sqrt(__np * __1p) * (1 + _M_d2 / (4 * (_M_t * __1p))); _M_c = 2 * _M_d1 / __np; _M_a1 = std::exp(_M_c) * _M_s1 * __spi_2; const double __a12 = _M_a1 + _M_s2 * __spi_2;
[Bug libstdc++/114147] [11/12/13 Regression] tuple allocator-extended constructor requires non-explicit default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8a0a24b9a097452c576d5f409fe7efbafd6aef6b commit r13-8457-g8a0a24b9a097452c576d5f409fe7efbafd6aef6b Author: Jonathan Wakely Date: Fri Mar 1 11:16:58 2024 + libstdc++: Add missing std::tuple constructor [PR114147] I caused a regression with commit r10-908 by adding a constraint to the non-explicit allocator-extended default constructor, but seemingly forgot to add an explicit overload with the corresponding constraint. libstdc++-v3/ChangeLog: PR libstdc++/114147 * include/std/tuple (tuple::tuple(allocator_arg_t, const Alloc&)): Add missing overload of allocator-extended default constructor. (tuple::tuple(allocator_arg_t, const Alloc&)): Likewise. * testsuite/20_util/tuple/cons/114147.cc: New test. (cherry picked from commit 0a545ac7000501844670add0b3560ebdbcb123c6)
[Bug c++/107500] Useless atexit entry for ~constant_init in eh_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|12.4|13.0 Resolution|--- |FIXED --- Comment #26 from Jonathan Wakely --- I'm not planning to backport this.
[Bug c++/107500] [12 Regression] Useless atexit entry for ~constant_init in eh_globals.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500 Jonathan Wakely changed: What|Removed |Added Known to work||12.1.0 Target Milestone|13.0|12.4 Resolution|FIXED |--- Known to fail||12.2.0 Summary|Useless atexit entry for|[12 Regression] Useless |~constant_init in |atexit entry for |eh_globals.cc |~constant_init in ||eh_globals.cc Status|RESOLVED|ASSIGNED --- Comment #27 from Jonathan Wakely --- Strike that - this was a regression in 12.2 compared to 12.1 (bit wasn't previously marked as such) so should be backported.
[Bug c++/114357] Add a way to not call deconstructors for non-auto decls, like clang's no_destroy attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-16 Status|UNCONFIRMED |NEW --- Comment #8 from Jonathan Wakely --- e.g. PR 107500 where a bare metal system wastes space for a no-op destructor. It would be a lot simpler if we could just mark immortal objects as [[no_destroy]] and not have to dance around what the standard allows (or not) about lifetimes and triviality for objects with static storage duration. It would also be better to not rely on DCE being able to figure out what we're trying to do with unions and empty destructors. There are valid use cases in a kernel or language runtime for ensuring that some objects do not end their lifetime while other code is still running.
[Bug tree-optimization/114363] inconsistent optimization of pow(x,2)+pow(y,2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114363 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #1 from Harald van Dijk --- This is, I believe, correct. Before C++11, calling std::pow with float and int arguments, it returned a float. As of C++11, it returns a double. If the result of pow(x,2) is immediately converted to float, then it is a valid optimisation to convert it to x*x: that is guaranteed to produce the exact same result. But if it isn't, then converting to x*x loses accuracy and alters the result. You can call std::powf instead of std::pow to avoid the promotion to double.
[Bug c++/112631] 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 --- Comment #1 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:ead3075406ece9daaad65a01ae539150aee43f5a commit r14-9501-gead3075406ece9daaad65a01ae539150aee43f5a Author: Nathaniel Shead Date: Tue Mar 12 23:24:27 2024 +1100 c++: Check module attachment instead of just purview when necessary [PR112631] Block-scope declarations of functions or extern values are not allowed when attached to a named module. Similarly, class member functions are not inline if attached to a named module. However, in both these cases we currently only check if the declaration is within the module purview; it is possible for such a declaration to occur within the module purview but not be attached to a named module (e.g. in an 'extern "C++"' block). This patch makes the required adjustments. PR c++/112631 gcc/cp/ChangeLog: * cp-tree.h (named_module_attach_p): New function. * decl.cc (start_decl): Check for attachment not purview. (grokmethod): Likewise. gcc/testsuite/ChangeLog: * g++.dg/modules/block-decl-1_a.C: New test. * g++.dg/modules/block-decl-1_b.C: New test. * g++.dg/modules/block-decl-2.C: New test. Signed-off-by: Nathaniel Shead
[Bug tree-optimization/114363] inconsistent optimization of pow(x,2)+pow(y,2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114363 Xi Ruoyao changed: What|Removed |Added Resolution|--- |INVALID CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Xi Ruoyao --- (In reply to Harald van Dijk from comment #1) > This is, I believe, correct. Before C++11, calling std::pow with float and > int arguments, it returned a float. As of C++11, it returns a double. > > If the result of pow(x,2) is immediately converted to float, then it is a > valid optimisation to convert it to x*x: that is guaranteed to produce the > exact same result. But if it isn't, then converting to x*x loses accuracy > and alters the result. Thus invalid. > You can call std::powf instead of std::pow to avoid the promotion to double. Or add -std=c++98.
[Bug tree-optimization/114363] inconsistent optimization of pow(x,2)+pow(y,2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114363 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Or use pow(x,2.0f)+pow(y,2.0f). Anyway, see https://eel.is/c++draft/c.math#cmath.syn-3
[Bug tree-optimization/114329] ICE: verify_gimple failed: 'bit_field_ref' of non-mode-precision operand with bitfield _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114329 --- Comment #2 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3e8323e873c5af5047507d6b2cfbd12706820ee2 commit r14-9502-g3e8323e873c5af5047507d6b2cfbd12706820ee2 Author: Jakub Jelinek Date: Sat Mar 16 15:15:29 2024 +0100 bitint: Fix up stores to large/huge _BitInt bitfields [PR114329] The verifier requires BIT_FIELD_REFs with INTEGRAL_TYPE_P first operand to have mode precision. In most cases for the large/huge _BitInt bitfield stores the code uses bitfield representatives, which are typically arrays of chars, but if the bitfield starts at byte boundary on big endian, the code uses as nlhs in lower_mergeable_store COMPONENT_REF of the bitfield FIELD_DECL instead, which is fine for the limb accesses, but when used for the most significant limb can result in invalid BIT_FIELD_REF because the first operand then has BITINT_TYPE and usually VOIDmode. The following patch adds a helper method for the 4 creatikons of BIT_FIELD_REF which when needed adds a VIEW_CONVERT_EXPR. 2024-03-16 Jakub Jelinek PR tree-optimization/114329 * gimple-lower-bitint.cc (struct bitint_large_huge): Declare build_bit_field_ref method. (bitint_large_huge::build_bit_field_ref): New method. (bitint_large_huge::lower_mergeable_stmt): Use it. * gcc.dg/bitint-101.c: New test.
[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #25 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:218d17496122abe1fd831bd003f129310b32ca83
commit r14-9503-g218d17496122abe1fd831bd003f129310b32ca83
Author: Jakub Jelinek
Date: Sat Mar 16 15:16:33 2024 +0100
i386: Fix setup of incoming varargs for (...) functions which return large
aggregates [PR114175]
The c23-stdarg-6.c testcase I've added recently apparently works fine with
-O0 but aborts with -O1 and higher on x86_64-linux.
The problem is in setup of incoming varargs.
Like function.cc before r14-9249 even ix86_setup_incoming_varargs assumes
that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and there
is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
If the setup_incoming_varargs hook is called from the
if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (fndecl))
&& fnargs.is_empty ())
{
struct assign_parm_data_one data = {};
assign_parms_setup_varargs (&all, &data, false);
}
spot, i.e. where there is no hidden return argument passed, arg.type
is always NULL, while when it is called in the
if (cfun->stdarg && !DECL_CHAIN (parm))
assign_parms_setup_varargs (&all, &data, false);
spot, even when it is TYPE_NO_NAMED_ARGS_STDARG_P arg.type will be
non-NULL.
The tree-stdarg.cc pass in f in c23-stdarg-6.cc at -O1 or higher determines
that va_arg is used on integral types at most twice (loads 2 words),
and because ix86_setup_incoming_varargs doesn't advance, the code saves
just the %rdi and %rsi registers to the save area. But that isn't correct,
it should save %rsi and %rdx because %rdi is the hidden return argument.
With -O0 tree-stdarg.cc doesn't attempt to optimize and we save all the
registers, so it works fine in that case.
Now, I think we'll need the same fix also on
aarch64, alpha, arc, csky, ia64, loongarch, mips, mmix, nios2, riscv,
visium
which have pretty much the similarly looking snippet in their hooks
changed by the r13-3549 commit.
Then arm, epiphany, fr30, frv, ft32, m32r, mcore, nds32, rs6000, sh
have different changes but most likely need something similar too.
I don't have access to most of those, could test aarch64 and rs6000 I
guess.
2024-03-16 Jakub Jelinek
PR target/114175
* config/i386/i386.cc (ix86_setup_incoming_varargs): Only skip
ix86_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
* gcc.dg/c23-stdarg-7.c: New test.
* gcc.dg/c23-stdarg-8.c: New test.
[Bug tree-optimization/114329] ICE: verify_gimple failed: 'bit_field_ref' of non-mode-precision operand with bitfield _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114329 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Should be fixed now.
[Bug tree-optimization/114363] inconsistent optimization of pow(x,2)+pow(y,2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114363 --- Comment #4 from vincenzo Innocente --- Thanks Harald, I missed the point that float z = pow(double(x),2) and float z = x*x would indeed produce exactly the same result, while in all other cases of course not.
[Bug c/114364] New: Untranslatable string 'in intervening code'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114364 Bug ID: 114364 Summary: Untranslatable string 'in intervening code' Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- >From c-family/c-omp.cc: > error_at (LOCATION_OR (eloc, loc), > "variable %qD used %s is bound " > "in intervening code", bad, context); As a translator, I have no chance of translating 'in intervening code'. Sentence fragments must not be embedded using %s, as other natural languages differ structurally.
[Bug c/114364] Untranslatable string 'in intervening code'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114364 --- Comment #1 from Roland Illig --- Oops, I misinterpreted the code, as 'in intervening code' is indeed translatable, but 'as loop variable' isn't, so the bug report is still valid.
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-16 --- Comment #8 from Iain Sandoe --- according to information from the Apple OSS folks, the Kernel.framework is/was (never) intended to be used as a regular framework. [This was news to me, FWIW, and it does seem a somewhat odd situation, since it's wrapped up in all the necessary machinery which makes it look like it should work]. anyway What we want from this test is that a suitable framework is found in /System/Library/Frameworks when the user has also given a local framework path (-F.). What we want to avoid is the test regressing because of incidental SDK changes (like unguarded Apple Black usage) - so we have picked the kernel framework and a suitable low-complexity header. At present, I am thinking that IOkit/IOReturn.h might be a suitable substitute - but that needs to be checked across the range of OS versions supported.
[Bug c/114364] Untranslatable string 'in intervening code'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114364 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2024-03-16 --- Comment #2 from Jakub Jelinek --- Created attachment 57716 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57716&action=edit gcc14-pr1164364.patch Untested fix.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #18 from David Binderman --- (In reply to David Binderman from comment #17) > I tried out gcc-13.2 and got the following results: > > foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2 > --param=max-inline-insns-auto=23 bug998.c && valgrind -q ./a.out > checksum = 77A231E6 > foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2 > --param=max-inline-insns-auto=24 bug998.c && valgrind -q ./a.out > checksum = 130B5204 > foundBugs $ > > so it is something that has been going wrong since before gcc-13.2. Similarly with 13.1: foundBugs $ ~/gcc/results.13.1.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=23 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results.13.1.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=24 bug998.c && valgrind -q ./a.out checksum = 130B5204 foundBugs $
[Bug tree-optimization/114365] New: ICE: verify_ssa failed: definition in block 4 does not dominate use in block 5 at -O with _BitInt() shift in a bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114365 Bug ID: 114365 Summary: ICE: verify_ssa failed: definition in block 4 does not dominate use in block 5 at -O with _BitInt() shift in a bitfield Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57717 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57717&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c testcase.c: In function 'foo': testcase.c:7:1: error: definition in block 4 does not dominate use in block 5 7 | foo(int a) | ^~~ for SSA_NAME: _33 in statement: _36 = _33 << 33; during GIMPLE pass: bitintlower testcase.c:7:1: internal compiler error: verify_ssa failed 0x177d34f verify_ssa(bool, bool) /repo/gcc-trunk/gcc/tree-ssa.cc:1203 0x13ceab5 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2095 0x13cef1e execute_todo /repo/gcc-trunk/gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9503-20240316151633-g218d1749612-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9503-20240316151633-g218d1749612-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240316 (experimental) (GCC)
[Bug c/114366] New: computed labels do not reflect true values of instruction pointer ranges when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114366
Bug ID: 114366
Summary: computed labels do not reflect true values of
instruction pointer ranges when function is inlined
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: godmar at gmail dot com
Target Milestone: ---
Created attachment 57718
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57718&action=edit
using labels as values example
Hi, we recently got tripped up by the following:
```c
#include
void *beginPtr, *endPtr;
int x;
static void smallfunction(void)
{
beginPtr = &&begin;
endPtr = &&end;
begin:
x++;
end:
}
int
main()
{
smallfunction();
assert(beginPtr < endPtr);
}
```
When compiled with `-O0`, this program completes successfully. When compiled
with `-O2`, this program fails its assertion because the following assembly
code is produced:
```
.L2:
.L3:
leaq.L2(%rip), %rdx
leaq.L3(%rip), %rax
addl$1, x(%rip)
```
which IMO should be something like:
```
.L2:
leaq.L2(%rip), %rdx
leaq.L3(%rip), %rax
addl$1, x(%rip)
.L3:
```
I understand that using labels as values is a GCC extension, and I have read
the comment in the documentation [1] that warns that &&foo might have a
different value if a function is inlined. (Adding the noinline attribute fixes
the problem at the cost of some performance.) Also note that "different
values" is not the same as not being computed correctly.
We encountered this problem building an exception handler.
I will note that gcc will not inline the function if the computed values are
actually used in a goto statement; when trying to force it to inline it, it
throws an error.
Is this a bug, or undocumented behavior? Perhaps the documentation should be
clarified.
[1] https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
[Bug c/114366] computed labels do not reflect true values of instruction pointer ranges when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114366 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Using labels as values can only be used with computed gotos. This is documented that way too.
[Bug c/114366] computed labels do not reflect true values of instruction pointer ranges when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114366 --- Comment #2 from Andrew Pinski --- To use these values, you need to be able to jump to one. This is done with the computed goto statement6
[Bug middle-end/26187] computed goto code does not produce jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26187 Andrew Pinski changed: What|Removed |Added CC||rakdver at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- *** Bug 31727 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/31727] Functions with non-local gotos are considered not to have side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31727 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 26187 ***
[Bug c/114366] computed labels do not reflect true values of instruction pointer ranges when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114366 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||godmar at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 114366 has been marked as a duplicate of this bug. ***
[Bug c++/55468] Label value to incorrect destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55468 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||martin.girard5 at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 55468 has been marked as a duplicate of this bug. ***
[Bug c/55749] gcc 4.7.1 removes labels mistakenly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55749 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #5 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||blue_3too at hotmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 55749 has been marked as a duplicate of this bug. ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||sergstesh at yahoo dot com --- Comment #5 from Andrew Pinski --- *** Bug 40115 has been marked as a duplicate of this bug. ***
[Bug c/40115] -O2 and higher causes wrong label address calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #7 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||grantrwittmann at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 112870 has been marked as a duplicate of this bug. ***
[Bug c/112870] incorrect jmp when using goto on a function, causing infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112870 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 44298 ***
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96956 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #3 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||thomas.lynch@reasoningtechn ||ology.com --- Comment #7 from Andrew Pinski --- *** Bug 96956 has been marked as a duplicate of this bug. ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||dhowells at redhat dot com --- Comment #8 from Andrew Pinski --- *** Bug 77329 has been marked as a duplicate of this bug. ***
[Bug c/77329] gcc doesn't always correctly calculate label addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77329 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 44298 ***
[Bug rtl-optimization/77951] Incorrect placement of label which does not affect execution flow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77951 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #9 from Andrew Pinski --- *** Bug 77951 has been marked as a duplicate of this bug. ***
[Bug modula2/114296] ICE when attempting to create a constant set with a variable element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114296 --- Comment #1 from Gaius Mulley --- Created attachment 57719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57719&action=edit Proposed fix Here is the proposed fix. It corrects the virtual token creation for the aggregate constant and also corrects tokens for constructor components.
[Bug c/54529] dead code elimination deletes code adressed by referenced labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54529 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||Wasserthal at nefkom dot net --- Comment #10 from Andrew Pinski --- *** Bug 54529 has been marked as a duplicate of this bug. ***
[Bug c/19969] Labels broken when passed into inline assembly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19969 --- Comment #3 from Andrew Pinski --- Note starting with GCC 4.5, gcc adds asm goto which can be used to do what is needed to be done here.
[Bug middle-end/29305] local label-as-value being placed before function prolog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29305 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #12 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||jeremy at goop dot org --- Comment #11 from Andrew Pinski --- *** Bug 29305 has been marked as a duplicate of this bug. ***
[Bug middle-end/28581] Illegal loading the address of a label with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #14 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Andrew Pinski changed: What|Removed |Added CC||inaoka.kazuhiro at renesas dot com --- Comment #12 from Andrew Pinski --- *** Bug 28581 has been marked as a duplicate of this bug. ***
[Bug c++/114362] wrong error message "too many arguments" with overloaded function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114362 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 104343 ***
[Bug c++/104343] improved error message for passing overloaded function to variadic(templated)-argument function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104343 Andrew Pinski changed: What|Removed |Added CC||f.heckenb...@fh-soft.de --- Comment #6 from Andrew Pinski --- *** Bug 114362 has been marked as a duplicate of this bug. ***
[Bug c++/99242] [modules] ICE in lookup_mark, at cp/tree.c:2403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99242
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #3 from Patrick Palka ---
A curious reduction:
$ cat 99241_a.H
bool __is_constant_evaluated();
$ cat 99241_b.H
bool __is_constant_evaluated();
$ cat 99241_c.H
bool __is_constant_evaluated();
$ cat 99241_d.C
bool __is_constant_evaluated();
import "99241_a.ii";
void f() { __is_constant_evaluated(); }
import "99241_b.ii";
import "99241_c.ii";
void g() { __is_constant_evaluated(); }
$ g++ -fmodules-ts 99241_*
99241_d.ii: In function ‘void g()’:
99241_d.ii:6:12: internal compiler error: in lookup_mark, at cp/tree.cc:2474
6 | void g() { __is_constant_evaluated(); }
|^~~
[Bug c++/99241] [modules] ICE in install_entity, at cp/module.cc:7584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99241 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #9 from Patrick Palka --- Reduced (needs -fno-module-lazy): $ cat 99241_a.H void terminate(); $ cat 99241_b.H void terminate(); $ cat 99241_c.C import "99242_a.H"; void terminate(); import "99242_b.H"; $ g++ -fmodules-ts -fno-module-lazy 99241_* 99242_c.H:3:20: internal compiler error: in install_entity, at cp/module.cc:7649 3 | import "99242_b.H"; |^ 0x77821f trees_in::install_entity(tree_node*)
[Bug c++/99242] [modules] ICE in lookup_mark, at cp/tree.c:2403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99242
--- Comment #4 from Patrick Palka ---
A curious reduction:
$ cat 99242_a.H
bool __is_constant_evaluated();
$ cat 99242_b.H
bool __is_constant_evaluated();
$ cat 99242_c.H
bool __is_constant_evaluated();
$ cat 99242_d.C
bool __is_constant_evaluated();
import "99242_a.H";
void f() { __is_constant_evaluated(); }
import "99242_b.H";
import "99242_c.H";
void g() { __is_constant_evaluated(); }
$ g++ -fmodules-ts 99241_*
99242_d.C: In function ‘void g()’:
99242_d.C:6:12: internal compiler error: in lookup_mark, at cp/tree.cc:2474
6 | void g() { __is_constant_evaluated(); }
|^~~
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #19 from David Binderman --- gcc 12.3 seems to get it right: foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=23 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=24 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=30 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O3 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $
[Bug debug/44712] Debug info for partially inlined functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44712 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-03-16 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- .
[Bug c++/43127] Inconsistent and odd constructor calls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43127 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- First note C++17+ changed the rules so using C++17 allows this to compile, guaranteed copy elision (https://en.cppreference.com/w/cpp/language/copy_elision) so no copy is required or even tried. Second, the code is in fact invalid C++98/03/11/14 . To make it valid C++11/14, you can use the rvalue reference instead for the constructor: auto_ptr(auto_ptr&& source) For valid C++98, you could add a constructor which takes a const reference which allows binding a temporary to it: auto_ptr(const auto_ptr& source)
[Bug target/46247] bug with loading constant to neon quad register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46247 --- Comment #2 from Andrew Pinski --- The code looks correct in GCC 4.5.4 and above.
[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527 --- Comment #5 from Sergei Trofimovich --- (In reply to Deepthi H from comment #4) > I have been investigating this issue further. Hence checking the source code > and debugging the gcc sources. However, I wasn't able to find where the > COLLECT_GCC_OPTION has been set to 128kb > > I couldn't find it being set in gcc. Can you please let us know how can we > increase the limit of collect options? The 128K limit against a single environment variable is a linux kernel limitation set by this define in include/uapi/linux/binfmts.h: #define MAX_ARG_STRLEN (PAGE_SIZE * 32) https://trofi.github.io/posts/299-maximum-argument-count-on-linux-and-in-gcc.html has more words on that.
[Bug target/51122] ICE in change_address_1, at emit-rtl.c:2001
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51122 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #2 from Andrew Pinski --- Fixed for GCC 5+ (Maybe even for GCC 4.9). LRA is always enabled in GCC 5+ (r5-6635-gc896d4b449d797)
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Pinski --- The noipa attribute is used for this now. In this case, adding noipa to foobar, removes the noreturn detection of foobar and there is no code difference with/without foobar defined in there. __attribute__ ((noipa)) extern void foobar(void *);
[Bug preprocessor/56306] -m32 does not support all includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56306 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Debian and Ubuntu solves this using the mutli-arch (which GCC has support for a few years now). But this is a distro issue rather than a GCC issue.
[Bug target/56603] Different _MM_HINT_TX values from ICC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56603 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- The intrinsics guide: https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#text=_mm_prefetch&ig_expand=5152,5153 _MM_HINT_T0 // 3, move data using the T0 hint. The PREFETCHT0 instruction will be generated. _MM_HINT_T1 // 2, move data using the T1 hint. The PREFETCHT1 instruction will be generated. _MM_HINT_T2 // 1, move data using the T2 hint. The PREFETCHT2 instruction will be generated. So GCC is correct here.
[Bug preprocessor/53212] cpp consumes comment after pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53212 --- Comment #1 from Andrew Pinski --- Hmm, clang has the same behavior here ... I don't know if it is the right one though.
[Bug preprocessor/53212] cpp consumes comment after pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53212 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-03-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- ICC/EDG on the other hand includes the comment. So confirmed.
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #12 from Andrew Pinski --- Invalid as mentioned, stack size increases slightly with tsan enabled which causes the needed increase in stack size overall.
[Bug libstdc++/114367] New: std::vector constexpr initialization doesn't start lifetime of array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114367
Bug ID: 114367
Summary: std::vector constexpr initialization doesn't
start lifetime of array members
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: teodor_spaeren at riseup dot net
Target Milestone: ---
#include
consteval int foo(){
std::vectorseen(26);
return 0;
}
int main(){
return foo();
}
This is the code. If you compile this with g++, it compiles fine, but with
clang it gives a warning about object lifetimes.
lel.cpp:7:12: error: call to consteval function 'foo' is not a constant
expression
return foo();
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/stl_bvector.h:649:15:
note: assignment to object outside its lifetime is not allowed in a constant
expression
__p[__i] = 0ul;
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/stl_bvector.h:1317:31:
note: in call to '&seen->_M_allocate(1)'
_Bit_pointer __q = this->_M_allocate(__n);
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/stl_bvector.h:768:2:
note: in call to '&seen->_M_initialize(26)'
_M_initialize(__n);
^
/usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/stl_bvector.h:755:9:
note: in call to 'vector(26, false, allocator_type())'
: vector(__n, false, __a)
^
lel.cpp:3:22: note: in call to 'vector(26, allocator_type())'
std::vectorseen(26);
^
lel.cpp:7:12: note: in call to 'foo()'
return foo();
^
1 error generated.
When compiling with
https://github.com/gcc-mirror/gcc/blob/releases/gcc-13/libstdc%2B%2B-v3/include/bits/stl_bvector.h#L676-L685
In the code it seems it never constructs the array, but starts accessing the
members directly. I don't know if this is affected by
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html or not.
I've submitted a bug report to clang also.
[Bug libstdc++/114367] std::vector constexpr initialization doesn't start lifetime of array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114367
--- Comment #1 from Andrew Pinski ---
Hmm:
_Bit_pointer __p = _Bit_alloc_traits::allocate(_M_impl, _S_nword(__n));
#if __cpp_lib_is_constant_evaluated
if (std::is_constant_evaluated())
{
__n = _S_nword(__n);
for (size_t __i = 0; __i < __n; ++__i)
__p[__i] = 0ul;
}
#endif
Maybe I misunderstand how this should work.
[Bug libstdc++/114367] std::vector constexpr initialization doesn't start lifetime of array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114367
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-03-16
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Hmm:
>
> _Bit_pointer __p = _Bit_alloc_traits::allocate(_M_impl,
> _S_nword(__n));
> #if __cpp_lib_is_constant_evaluated
> if (std::is_constant_evaluated())
> {
> __n = _S_nword(__n);
> for (size_t __i = 0; __i < __n; ++__i)
> __p[__i] = 0ul;
> }
> #endif
>
> Maybe I misunderstand how this should work.
Oh yes see https://github.com/llvm/llvm-project/issues/46391
So yes this is a GCC bug with the above.
[Bug c++/109268] Guard variable still provided for static constinit variable with an empty destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109268
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-03-16
Status|UNCONFIRMED |NEW
--- Comment #3 from Andrew Pinski ---
I have a patch which fixes PR 19661 except it does not fix this one fully.
I will also note LLVM also still does the guard variable here too even with the
removal of the __cxa_atexit call.
We need another way to remove the empty code between
__cxa_guard_acquire/__cxa_guard_release .
[local count: 354334800]:
_2 = __cxa_guard_acquire (&_ZGVZ1fvE4data);
if (_2 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 116930483]:
# DEBUG this => &data
# DEBUG INLINE_ENTRY __ct
data ={v} {CLOBBER(bob)};
# DEBUG this => NULL
__cxa_guard_release (&_ZGVZ1fvE4data);
[local count: 1073741824]:
[Bug tree-optimization/19661] unnecessary atexit calls emitted for static objects with empty destructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #17 from Fangrui Song ---
(In reply to Andrew Pinski from comment #16)
> So what is interesting is the way LLVM implements this as an IPO pass as how
> I described in comment #8, 6 years after I wrote that. Well they used
> "empty" rather than const . Note using it as an IPO pass I think is not
> wrong just having a specialized pass here where this is the same as DCE so
> just have DCE handle it instead seems better; plus with the availability of
> having pure/const flags with LTO and not having to load in the function
> seems much better really.
Yes, LLVM recognizes __cxa_atexit as a library function and removes it in
GlobalOpt (part of IPO) since 2011
(https://github.com/llvm/llvm-project/commit/ee6bc70d2f1c2434ca9ca8092216bdeab322c7e5),
likely because
GlobalOpt is already doing global variable optimizations (e.g. removal if dead,
constant folding). Technically __cxa_atexit removal can be moved elsewhere.
There are two GlobalOpt passes in the optimization pipeline (see -mllvm
-print-changed=cdiff output), one before the inliner and one after.
SROA
...
GlobalOpt
...
buildInlinerPipeline
...
GlobalOpt
For empty functions like `~constant_init() {}`, SROA deletes unneeded IR
instructions (spill of the "this" pointer) and actually makes the IR function
empty. Then GlobalOpt removes __cxa_atexit call sites.
For `static void empty() {} ~constant_init() { empty(); }`, the inliner removes
the `empty()` and makes the IR function empty. Then GlobalOpt removes
__cxa_atexit call sites.
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Known to work||10.4.0, 10.5.0, 11.4.0, ||12.1.0
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104142 Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed in GCC 10.4.0 by the patch which fixed PR 104142.
[Bug c++/59994] [meta-bug] thread_local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994 Bug 59994 depends on bug 78940, which changed state. Bug 78940 Summary: [missed optimization] Useless guard variable in thread_local defaulted constructor https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/84411] Missed optimization: static guard variable generated for empty virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84411 Andrew Pinski changed: What|Removed |Added Depends on||19661 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-16 Ever confirmed|0 |1 CC||pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- This depends on PR 19661. But then we still need to remove: [local count: 1073741824]: _1 = __atomic_load_1 (&_ZGVZ8get_basevE1d, 2); if (_1 == 0) goto ; [33.00%] else goto ; [67.00%] [local count: 956811341]: goto ; [100.00%] [local count: 354334800]: _2 = __cxa_guard_acquire (&_ZGVZ8get_basevE1d); if (_2 != 0) goto ; [33.00%] else goto ; [67.00%] [local count: 116930483]: __cxa_guard_release (&_ZGVZ8get_basevE1d); Note clang/LLVM does not remove the use of the guard here either, even though it does remove the __cxa_atexit. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19661 [Bug 19661] unnecessary atexit calls emitted for static objects with empty destructors
[Bug c++/109268] Guard variable still provided for static constinit variable with an empty destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109268
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-03-16
Status|UNCONFIRMED |NEW
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #3 from Andrew Pinski ---
I have a patch which fixes PR 19661 except it does not fix this one fully.
I will also note LLVM also still does the guard variable here too even with the
removal of the __cxa_atexit call.
We need another way to remove the empty code between
__cxa_guard_acquire/__cxa_guard_release .
[local count: 354334800]:
_2 = __cxa_guard_acquire (&_ZGVZ1fvE4data);
if (_2 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 116930483]:
# DEBUG this => &data
# DEBUG INLINE_ENTRY __ct
data ={v} {CLOBBER(bob)};
# DEBUG this => NULL
__cxa_guard_release (&_ZGVZ1fvE4data);
[local count: 1073741824]:
--- Comment #4 from Andrew Pinski ---
Dup in the end.
*** This bug has been marked as a duplicate of bug 84411 ***
[Bug c++/84411] Missed optimization: static guard variable generated for empty virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84411 Andrew Pinski changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 109268 has been marked as a duplicate of this bug. ***
[Bug c++/36587] Feature: add warning for constructor call with discarded return.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |7.0 Status|UNCONFIRMED |RESOLVED --- Comment #14 from Andrew Pinski --- C++17 adds nodiscard attribute which can be placed on class/struct types, functions, constructors and others and then you get a warning if you ignore the value. In the case of struct/class types and constructors that will warn when a temporary value is ignored. Exactly in the case you were asking for a warning. Which was added to GCC by r7-377-gb632761d2c6a65 (and fixes afterwards). So closing as fixed.
[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794 Bug 19794 depends on bug 68548, which changed state. Bug 68548 Summary: bogus "may be used uninitialized" (predicate analysis) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68548 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/68548] bogus "may be used uninitialized" (predicate analysis)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68548 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Keywords||missed-optimization Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed on the trunk. A jump threading improvement fixed it.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 68548, which changed state. Bug 68548 Summary: bogus "may be used uninitialized" (predicate analysis) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68548 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.4
[Bug c++/79561] Missed optimization: useless guards for zero-initialized POD statics with =default default ctor at function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79561 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Yes it is a dup of bug 78940 and was fixed for GCC 10.4.0. *** This bug has been marked as a duplicate of bug 78940 ***
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Andrew Pinski changed: What|Removed |Added CC||marc.mutz at hotmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 79561 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/53273] test-cases suffer from cross-function optimizations with no way to mark limits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53273 --- Comment #8 from Hans-Peter Nilsson --- There it is! I *knew* I had a PR entered for this, and was a bit surprised when the ipa attribute was introduced, that this PR wasn't cross-referenced. Then again I guess most people don't check in bugzilla for possible entries when they fix something, and this one maybe hasn't got any good terms to look for. (In reply to Andrew Pinski from comment #7) > The noipa attribute is used for this now. It sure is and spot on.
[Bug c++/83730] Unnecessary generation of guard variables with -fno-threadsafe-statics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83730 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from Andrew Pinski --- Dup, and fixed already. *** This bug has been marked as a duplicate of bug 78940 ***
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 Andrew Pinski changed: What|Removed |Added CC||klaus.doldinger64@googlemai ||l.com --- Comment #7 from Andrew Pinski --- *** Bug 83730 has been marked as a duplicate of this bug. ***
[Bug c++/53785] coalescing multiple static instances in function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53785 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|tree-optimization |c++ Last reconfirmed||2024-03-17 Ever confirmed|0 |1 Keywords||ABI --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug c++/53785] coalescing multiple static instances in function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53785 Andrew Pinski changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 87692 has been marked as a duplicate of this bug. ***
[Bug c++/87692] Reuse guard variable for multiple initializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87692 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 53785 ***
[Bug middle-end/87831] Guard variable is not eliminated when there's nothing to guard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87831 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 84411, the deconstructor part there is a different issue and has a fix waiting on GCC 15 though. *** This bug has been marked as a duplicate of bug 84411 ***
[Bug c++/84411] Missed optimization: static guard variable generated for empty virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84411 Andrew Pinski changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 87831 has been marked as a duplicate of this bug. ***
[Bug libstdc++/61735] pre-C++11 basic_string bug when type_size is char (-D_GLIBCXX_USE_CXX11_ABI=0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61735 Andrew Pinski changed: What|Removed |Added Summary|basic_string bug when |pre-C++11 basic_string bug |type_size is char. |when type_size is char ||(-D_GLIBCXX_USE_CXX11_ABI=0 ||) --- Comment #3 from Andrew Pinski --- I will note that the (default) newer basic_string that was included in GCC 5+ does not have this issue but the pre-c++ ABI basic_string still has this issue. That is you need -D_GLIBCXX_USE_CXX11_ABI=0 to hit the issue now.
