[Bug libstdc++/120388] constraint on expected's comparison operator causes infinite recursion, overload resolution fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120388 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- . *** This bug has been marked as a duplicate of bug 120387 ***
[Bug libstdc++/120387] constraint on expected's comparison operator causes infinite recursion, overload resolution fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- This is PR119714 which is already fixed. You didn't show the output of 'gcc -v' as requested, but I suspect you're using a snapshot before that fix. *** This bug has been marked as a duplicate of bug 119714 ***
[Bug libstdc++/119714] [15/16 Regression] Failure when using == operator on a class derived from std::expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119714 Jonathan Wakely changed: What|Removed |Added CC||justend29 at gmail dot com --- Comment #11 from Jonathan Wakely --- *** Bug 120387 has been marked as a duplicate of this bug. ***
[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243 --- Comment #7 from Iain Sandoe --- update: It seems not simply the inlining of the actor into the ramp but also when the result of that is then inlined into main() If I apply DECL_DISREGARD_INLINE_LIMITS() to the actor - so that it is inlined into the ramp at O1 - but then mark the ramp as __attribute__((__noinline__)) then the code works as expected (including at O2, O3) .. so two levels of inlining are involved..
[Bug target/120368] [16 Regression] wrong code with -O -fno-forward-propagate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120368 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/120368] [16 Regression] wrong code with -O -fno-forward-propagate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120368 --- Comment #1 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:8459c546197dc9178d250994db021b36405f1bd6 commit r16-807-g8459c546197dc9178d250994db021b36405f1bd6 Author: Jeff Law Date: Wed May 21 14:15:23 2025 -0600 [RISC-V][PR target/120368] Fix 32bit shift on rv64 So a followup to last week's bugfix. In last week's change we we stopped using define_insn_and_split to rewrite instructions. That change was done to avoid dropping a masking instruction out of the RTL. As a result the pattern(s) were changed into simple define_insns, which is good. One of them uses the GPR iterator since it's supposed to work for both 32bit and 64bit shifts on rv64. But we failed to emit the right opcode for a 32bit shift on rv64. Thankfully the fix is trivial. If the mode is anything but word_mode, then we must be doing a 32-bit shift on rv64, ie the various "w" shift instructions. It's run through my tester. Just waiting on the upstream CI system to spin it. PR target/120368 gcc/ * config/riscv/riscv.md (shift with masked shift count): Fix opcode when generating an SImode shift on rv64. gcc/testsuite/ * gcc.target/riscv/pr120368.c: New test.
[Bug modula2/120389] Assigning a CHAR to an INTEGER crashes the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120389 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-05-22 --- Comment #1 from Gaius Mulley --- Confirmed, thanks for the report.
[Bug libstdc++/120390] Request to improve error with private destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390 --- Comment #6 from nightstrike --- (In reply to Jonathan Wakely from comment #5) > (In reply to nightstrike from comment #3) > > I know it isn't a bug, > > You're missing the point. It *is* a bug if the diagnostic is bad. My point > is that it's not a *compiler* bug, it's a library bug. > > The compiler is doing exactly what the library code tells it to do. Ah, thank you for the clarification. I didn't understand that distinction, as you surmised.
[Bug target/120362] [GCC-15.1] Illegal Insn when run spec2017 511 ref size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120362 --- Comment #17 from Li Pan --- FYI, the spec2017 619 ref size, with --thread > 1 can also trigger this issue, but with another load. 10cf4: 0287f107vl1re64.v v2,(a5) thread = 1 is OK, as above code appears at omp related part, aka 00010cac :.
[Bug libstdc++/120387] New: constraint on expected's comparison operator causes infinite recursion, overload resolution fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387
Bug ID: 120387
Summary: constraint on expected's comparison operator causes
infinite recursion, overload resolution fails
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: justend29 at gmail dot com
Target Milestone: ---
Created attachment 61488
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61488&action=edit
minimum reproducible example
ISSUE
=
The requires clause introduced in GCC15 on std::expected::operator==
prevents any type from being compared if it has std::expected as a template
argument, as evaluation of the constraint depends on itself.
The specific function causing the error is here
(https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/expected;h=5dc1dfbe5b8a954826d2779a9cbc51c953b5e5f0;hb=1b306039ac49f8ad91ca71d3de3150a3c9fa792a#l1172),
where its definition is as such:
1172 template
1173 requires (!__expected::__is_expected<_Up>)
1174 && requires (const _Tp& __t, const _Up& __u) {
1175 { __t == __u } -> convertible_to;
1176 }
1177 friend constexpr bool
1178 operator==(const expected& __x, const _Up& __v)
1179 noexcept(noexcept(bool(*__x == __v)))
1180 { return __x.has_value() && bool(*__x == __v); }
Minimum Reproducible Example
Included below is a minimum reproducible example. You'll notice that
std::expected is never compared. Merely, the compiler's evaluation of the
constraint on operator== during overload resolution causes the infinite
recursion.
// mre.cpp
#include
#include
template
class A {
public:
friend bool operator==(const A&, const A&) {
return true; // not using T == T;
}
T t;
};
int main() {
static_assert(std::equality_comparable>>);
};
This issue is seen on GCC 15+, but not on GCC14, as the requires clause did not
yet exist. Compiler output with GCC 15.1.1 compiling mre.cpp with g++ mre.cpp
is shown below:
In file included from mre.cpp:2:
/usr/include/c++/15.1.1/expected: In substitution of ‘template
requires !(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u)
{{__t == __u} -> decltype(auto) [requires std::convertible_to<,
bool>];} constexpr bool std::operator==(const expected&, const _Up&)
[with _Up = A >]’:
/usr/include/c++/15.1.1/expected:1175:12: required by substitution of
‘template requires !(__is_expected<_Up>) && requires(const _Tp&
__t, const _Up& __u) {{__t == __u} -> decltype(auto) [requires
std::convertible_to<, bool>];} constexpr bool
std::operator==(const expected&, const _Up&) [with _Up =
A >]’
1175 | { __t == __u } -> convertible_to;
| ^~
/usr/include/c++/15.1.1/concepts:306:10: required from here
306 | { __t == __u } -> __boolean_testable;
| ^~
/usr/include/c++/15.1.1/expected:1178:2: required by the constraints of
‘template template requires
!(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u) {{__t == __u}
-> decltype(auto) [requires std::convertible_to<, bool>];}
constexpr bool std::operator==(const expected<_Tp, _Er>&, const _Up&)’
/usr/include/c++/15.1.1/expected:1174:7: in requirements with ‘const _Tp&
__t’, ‘const _Up& __u’ [with _Tp = int; _Up = A >]
/usr/include/c++/15.1.1/expected:1174:14: error: satisfaction of atomic
constraint ‘requires(const _Tp& __t, const _Up& __u) {{__t == __u} ->
decltype(auto) [requires std::convertible_to<, bool>];} [with _Tp
= _Tp; _Up = _Up]’ depends on itself
1174 | && requires (const _Tp& __t, const _Up& __u) {
| ^~~
1175 | { __t == __u } -> convertible_to;
| ~~~
1176 | }
| ~
Problem Evaluation
==
I believe these evaluation steps form the issue:
1. Overload resolution occurs for operator== between two
A>
types
2. std::expected is instantiated, along with its operator== shown
above.
3. Since std::expected is a template argument to A, namespace std is
involved in ADL with std::expected. The instantiated operator==
from
(2.) is then considered.
4. Although no std::expected is being compared, since constraints must be
evaluated before overload resolution, the compiler evaluates the
constraint on line 1175 above when considering the expected's operator==.
Within the constraint, lookup is again performed for operator== between
_Tp and _Up. For this MRE, _Tp is int (from std::expected) and _Up
is
A>.
5. When looking up operator== for the evaluation of the constraint,
std::expected is again a template argument, again bringing in
namespace s
[Bug middle-end/118694] OpenMP: target/metadirective/teams directive nesting gives error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694 --- Comment #7 from sandra at gcc dot gnu.org --- Hmmm, that is helpful. Which pass is it that depends on the strict nesting of "omp teams" within "omp target" for code generation? Is that also in omp-low (where the nesting error is diagnosed) or some later pass?
[Bug libstdc++/120387] constraint on expected's comparison operator causes infinite recursion, overload resolution fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387 --- Comment #1 from Jonathan Wakely --- *** Bug 120388 has been marked as a duplicate of this bug. ***
[Bug cobol/119256] Capture source ranges for tokens in gcobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119256 --- Comment #4 from David Malcolm --- James, I see you closed this as WONTFIX; was that just for the trailing "." issue mentioned in comment #2, or for the whole idea? I thought you were keen on having ranges rather than points.
[Bug c++/120392] New: GCC Segmentation Fault Cross Compiling C++ Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 Bug ID: 120392 Summary: GCC Segmentation Fault Cross Compiling C++ Source Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ad...@u-group13.org Target Milestone: --- GCC (ARM C++ cross compiler, to be specific) segfaults when attempting to compile the libcamera library (addon for Circle) using its standard instructions with make. Compilation completes normally with v11.4.0 on my laptop. libcamera is cloned from commit 0b04195, make v4.4.1 was used, and the cross compiler's version is v9.3.0 Error output is: during GIMPLE pass: fnsplit camerabuffer.cpp: In function 'CCameraBuffer::TPixel CCameraBuffer::GetPixel(unsigned int, unsigned int)': camerabuffer.cpp:265:1: internal compiler error: Segmentation fault 265 | } | ^ unrecognized DWARF version in .debug_info at 6 unrecognized DWARF version in .debug_info at 6 unrecognized DWARF version in .debug_info at 6 Command triggering issue (as invoked by make): arm-none-eabi-g++ -fno-exceptions -fno-rtti -nostdinc++ -DAARCH=32 -mcpu=arm1176jzf-s -marm -mfpu=vfp -mfloat-abi=hard -Wall -fsigned-char -g -DUSE_USB_FIQ -D__circle__=49 -DRASPPI=1 -DSTDLIB_SUPPORT=1 -D__VCCOREVER__=0x0400 -U__unix__ -U__linux__ -I ../include -I ../circle/include -I ../circle/addon -I ../circle/app/lib -I ../circle/addon/vc4 -I ../circle/addon/vc4/interface/khronos/include -O2 -ffreestanding -std=c++14 -Wno-aligned-new -c -o camerabuffer.o camerabuffer.cpp gcc -v output: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-unknown-linux-gnu/14.2.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /builddir/gcc-14.2.1+20250405/configure --build=x86_64-unknown-linux-gnu --enable-gnu-unique-object --enable-vtable-verify --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --libexecdir=/usr/lib64 --libdir=/usr/lib64 --enable-threads=posix --enable-__cxa_atexit --disable-multilib --with-system-zlib --enable-shared --enable-lto --enable-plugins --enable-linker-build-id --disable-werror --disable-nls --enable-default-pie --enable-default-ssp --enable-checking=release --disable-libstdcxx-pch --with-isl --with-linker-hash-style=gnu --disable-sjlj-exceptions --disable-target-libiberty --disable-libssp --enable-languages=c,c++,objc,obj-c++,fortran,lto,go,ada Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.2.1 20250405 (GCC) Operating system: Void Linux x64, kernel v6.12.29_1 CPU: AMD Ryzen 7 3700X
[Bug c++/120392] GCC Segmentation Fault Cross Compiling C++ Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 --- Comment #1 from Sam James --- (In reply to admin from comment #0) > Command triggering issue (as invoked by make): > [...] Please run this with -save-temps appened, then upload camerabuffer.ii (or .cpp.ii). This is the preprocessed source mentioned at https://gcc.gnu.org/bugs/#need.
[Bug c++/120392] GCC Segmentation Fault Cross Compiling C++ Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 --- Comment #2 from ad...@u-group13.org --- Created attachment 61490 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61490&action=edit Preprocessed source for component Forgot to attach
[Bug c++/120392] GCC Segmentation Fault Cross Compiling C++ Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 --- Comment #3 from Sam James --- Wait, you're reporting this for GCC 9.3.0? Anything under 12 is EOL.
[Bug tree-optimization/120392] GCC Segmentation Fault Cross Compiling C++ Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 --- Comment #4 from ad...@u-group13.org --- (In reply to Sam James from comment #3) > Wait, you're reporting this for GCC 9.3.0? Anything under 12 is EOL. Ah, apologies for the confusion. For some reason, Void's repos have an up-to-date version of main GCC, but this particular cross-compiler is old. I apparently got mixed up when checking package versions.
[Bug target/114064] [meta-bug] Use SVE instructions more for Advanced. SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114064 Bug 114064 depends on bug 113328, which changed state. Bug 113328 Summary: Some fixed length vector constants can be generated using SVE index instruction https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113328 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/113328] Some fixed length vector constants can be generated using SVE index instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113328 Pengxuan Zheng changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Pengxuan Zheng --- Fixed.
[Bug tree-optimization/120392] GCC Segmentation Fault Cross Compiling C++ Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 --- Comment #5 from Andrew Pinski --- I can reproduce it with: xgcc (GCC) 15.0.1 20250319 (experimental) [trunk 37680168360]
[Bug c++/120392] GCC Segmentation Fault Cross Compiling C++ Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 --- Comment #6 from Andrew Pinski --- Can reproduced on the trunk with x86_64-linux-gnu and -m32 -Os.
[Bug rtl-optimization/120374] ext-dce fails to realize a shift pair makes bits dead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120374 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-05-22
[Bug c++/120392] GCC Segmentation Fault Cross Compiling C++ Source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 --- Comment #7 from Andrew Pinski --- Created attachment 61491 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61491&action=edit Reduced ICEs at -O2+.
[Bug target/100837] nds32le-linux: error: array subscript 2 is above array bounds of 'rtx_def* [2]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100837 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to work||16.0 Last reconfirmed||2025-05-22
[Bug modula2/120389] New: Assigning a CHAR to an INTEGER crashes the compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120389 Bug ID: 120389 Summary: Assigning a CHAR to an INTEGER crashes the compiler Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: belka at caraus dot de Target Milestone: --- Created attachment 61489 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61489&action=edit -freport-bug output Here is the source code: ``` MODULE M; VAR X: ARRAY[1..5] OF INTEGER; BEGIN X[1] := 'c'; END M. ``` So it just declares an array of integers and assigns a character to an element. Compiling this results in an ICE. Details are in the attachment.
[Bug tree-optimization/119835] GCN, nvptx offloading: ICE 'during GIMPLE pass: nrv' in "return value optimizations for functions which return aggregate types"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119835
Thomas Schwinge changed:
What|Removed |Added
Last reconfirmed|2025-05-20 00:00:00 |2025-5-21
Keywords||ABI
Summary|GCN, nvptx offloading: |GCN, nvptx offloading: ICE
|'libgomp.c++/pr106445-1.C' |'during GIMPLE pass: nrv'
|with '-fno-inline': ICE |in "return value
|'during GIMPLE pass: nrv' |optimizations for functions
||which return aggregate
||types"
--- Comment #2 from Thomas Schwinge ---
So, per my current understanding, this is another host vs. offload target
ABI-related issue...
For example, also for C (not C++!) code:
typedef struct {int a;} sint;
static sint rsint(void)
{
sint t;
t.a = sizeof t;
return t;
}
..., on the x86_64 host, 'gcc/gimplify.cc:gimplify_return_expr', we get:
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x778b9150
fields
SI
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:10:21
size unit-size
align:32 warn_if_not_align:0 offset_align 128
decl_not_flexarray: 1
offset
bit-offset context
>
chain >
ignored SI
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:45:13
size unit-size
align:32 warn_if_not_align:0 context >
..., and 'aggregate_value_p (result_decl, TREE_TYPE (current_function_decl))'
then does 'return false;' (at end of function). In particular:
2132 if (targetm.calls.return_in_memory (type, fntype))
... does not 'return true;'.
Therefore, 'gimplify_return_expr' then does:
1934 result = create_tmp_reg (TREE_TYPE (result_decl));
[...]
..., and does not do the "If aggregate_value_p is true, then we can return the
bare RESULT_DECL." thing where it would set: 'result = result_decl;'.
(Similarly, presumably but not verified, for ppc64le host.)
However then in nvptx offloading compilation, we get:
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x777b07e0
fields
SI
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:10:21
size unit-size
align:32 warn_if_not_align:0 offset_align 128
decl_not_flexarray: 1
offset
bit-offset context
>>
ignored BLK
source-gcc/libgomp/testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c:45:13
size unit-size
align:32 warn_if_not_align:0 context >
..., and with that 'aggregate_value_p' runs into:
2132 if (targetm.calls.return_in_memory (type, fntype))
(gdb)
2133return true;
... because:
pass_in_memory (mode=E_BLKmode, type=type@entry=0x777b0a80,
for_return=for_return@entry=true) at
../../source-gcc/gcc/config/nvptx/nvptx.cc:658
658 {
(gdb) n
659 if (type)
(gdb)
661 if (AGGREGATE_TYPE_P (type))
(gdb)
662 return true;
This is probably not surprising given 'BLK'?
(Similarly, presumably but not verified, for GCN offload target.)
This 'return true;' from 'aggregate_value_p' then enables the
'gcc/tree-nrv.cc:pass_nrv::execute' processing, which then fails in:
tree result = DECL_RESULT (current_function_decl);
[...]
if (greturn *return_stmt = dyn_cast (stmt))
{
/* In a function with an aggregate return value, the
gimplifier has changed all non-empty RETURN_EXPRs to
return the RESULT_DECL. */
ret_val = gimple_return_retval (return_stmt);
if (ret_val)
gcc_assert (ret_val == result);
}
..., as the host code has not been set up conforming to that.
Any good suggestion about how to address this mismatch?
I don't understand enough of the GIMPLE/'DECL_RESULT' semantics to tell if we
could just disable this 'assert' here, and the pass would still be doing
correct transformations, or if that'd then potentially result in wrong code?
Per a quick instrumented run on powerpc64le-unknown-linux-gnu, for
'check-gcc-{c,c++,fortran}' and 'check-target' (for host, not offloading), this
pass is doing any code transformations only for exactly 24 (only!?) test cases,
so one option might be to just disable it for offloading compilation...
(Yuck!)
But then, there's the more general problem of 'aggregate_value_p' potentially
returning different things for host vs. offload target -- somewhat similar to
what we had seen in PR120308 "'TYPE_EMPTY_P' vs. code offloading"...
Help?
[Bug tree-optimization/120357] [16 Regression] RISC-V: ICE in vect pass "error: definition in block 9 does not dominate use in block 3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-21 Ever confirmed|0 |1
[Bug libstdc++/120387] constraint on expected's comparison operator causes infinite recursion, overload resolution fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387 --- Comment #3 from Jonathan Wakely --- (In reply to Justen Di Ruscio from comment #0) > The specific function causing the error is here > (https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/ > expected;h=5dc1dfbe5b8a954826d2779a9cbc51c953b5e5f0; > hb=1b306039ac49f8ad91ca71d3de3150a3c9fa792a#l1172), where its definition is > as such: If you look at the current code instead of an older version, you'll see it's different: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/expected;hb=releases/gcc-15#l1172
[Bug c++/120391] New: Enhancement: deduplicate constexpr char[] arrays with identical or overlapping contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120391
Bug ID: 120391
Summary: Enhancement: deduplicate constexpr char[] arrays with
identical or overlapping contents
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickooo314 at gmail dot com
Target Milestone: ---
In optimized builds, GCC currently does not deduplicate "constexpr char[]"
arrays that have identical or overlapping contents, even when using flags like
-Os or -fmerge-all-constants. This results in unnecessary duplication in
.rodata, especially for embedded or size-constrained targets.
Example (no deduplication):
$ cat merge_test.cpp
#include
constexpr char c1[] = {'H','e','l','l','o',' ','w','o','r','l','d','!','\0'};
constexpr char c2[] = {'w','o','r','l','d','!','\0'};
int main() {
puts(c1);
puts(c2);
}
$ /test/bin/g++ -Os -fmerge-all-constants -o merge_test merge_test.cpp
$ objdump -s -j .rodata merge_test
merge_test: file format elf64-x86-64
Contents of section .rodata:
402000 01000200 776f726c 64210a00 world!..
402010 48656c6c 6f20776f 726c6421 0a00 Hello world!..
Even though c2 is a suffix of c1, GCC emits both arrays independently in
.rodata, as opposed to string literals which get optimized (in fact even
without "-fmerge-all-constants"):
constexpr auto c1 = "Hello world!";
constexpr auto c2 = "world!";
$ objdump -s -j .rodata merge_test
merge_test: file format elf64-x86-64
Contents of section .rodata:
402000 01000200 48656c6c 6f20776f 726c6421 Hello world!
402010 00
Is there any reason GCC doesn't perform this optimization even with
"-fmerge-all-constants" for constexpr char arrays?
[Bug libstdc++/120390] Request to improve error with private destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390 Jonathan Wakely changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #5 from Jonathan Wakely --- (In reply to nightstrike from comment #3) > I know it isn't a bug, You're missing the point. It *is* a bug if the diagnostic is bad. My point is that it's not a *compiler* bug, it's a library bug. The compiler is doing exactly what the library code tells it to do.
[Bug c++/120391] Enhancement: deduplicate constexpr char[] arrays with identical or overlapping contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120391 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- ``` .section.rodata.str1.1,"aMS",@progbits,1 .type _ZL2c2, @object .size _ZL2c2, 7 _ZL2c2: .string "world!" .section.rodata.str1.8,"aMS",@progbits,1 .align 8 .type _ZL2c1, @object .size _ZL2c1, 13 _ZL2c1: .string "Hello world!" ``` With -fmerge-all-constants, the variables are emitted into the mergable sections. So there is nothing for GCC to do here. The problem for x86_64 ABI, since c1 is larger than 8, it has an alignment for 8. Note the `.8` in the section name there. So on aarch64 we get: ``` .section.rodata.str1.1,"aMS",@progbits,1 .type _ZL2c2, %object .size _ZL2c2, 7 _ZL2c2: .string "world!" .type _ZL2c1, %object .size _ZL2c1, 13 _ZL2c1: .string "Hello world!" ``` Which then the linker can/will merge. So this comes down to ABI requirements of x86_64.
[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #3 from Jonathan Wakely --- Mine then (I think we're deallocating an invalid pointer).
[Bug cobol/119232] gcobol -fdump-lang-all produces no dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119232 James K. Lowden changed: What|Removed |Added Ever confirmed|0 |1 CC||jklowden at gcc dot gnu.org Last reconfirmed||2025-05-21 Status|UNCONFIRMED |SUSPENDED --- Comment #3 from James K. Lowden --- Isn't GENERIC itself the AST? "The purpose of GENERIC is simply to provide a language-independent way of representing an entire function in trees." What more abstraction is needed? Perhaps my point of view explains my opinion that GENERIC should have a canonical, compilable textual representation. IMO a mature, well-designed language to represent compilable trees already exists: Lisp. If GENERIC could be dumped as Lisp, it could be examined in detail, and the output of different front-ends (or different versions of the same front-end) could be compared. For us, GENERIC dumps were a requirement to get the COBOL FE up and running. No existing dump options were useful. We wrote our own GENERIC dumper (twice!) only to see it rejected. An ambition of mine, when we add OO to GCC COBOL, is to make COBOL objects binary compatible with C++ objects (within semantic constraints). A fine-grained understanding of C++ GENERIC will doubtless be part of that endeavor. I'm not sure what to do with this PR. I don't understand what the goal of -fdump-lang-all would be for COBOL, or what it would show, or how it would improve on what we have already found useful.
[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367
--- Comment #4 from Jonathan Wakely ---
Here's the fix:
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -1969,7 +1969,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_M_range_initialize_n(_Iterator __first, _Sentinel __last,
size_type __n)
{
- pointer __start = this->_M_impl._M_start =
+ pointer __start = this->_M_impl._M_start = this->_M_impl._M_finish =
this->_M_allocate(_S_check_init_len(__n, _M_get_Tp_allocator()));
this->_M_impl._M_end_of_storage = __start + __n;
this->_M_impl._M_finish
Because vector(from_range_t, R&&) uses constructor delegation, it means that
the ~vector destructor will be run if an exception happens during the
delegating constructor.
When ~vector runs it destroys all the objects in the range [_M_start,_M_finish)
but we never set _M_finish, so it just destroys garbage.
The fix is to set _M_finish == _M_start so that ~vector has nothing to do.
[Bug cobol/119221] RFE: fix-it hints for cobol syntax errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119221
James K. Lowden changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Ever confirmed|0 |1
Last reconfirmed||2025-05-21
CC||jklowden at gcc dot gnu.org
--- Comment #1 from James K. Lowden ---
Current output is better, but no hints yet.
tbug.cbl:1:10: error: syntax error, unexpected NAME, expecting IDENTIFICATION
DIVISION or PROGRAM-ID
1 | PORGRAM-ID. TBUG.
| ^
I marked this as "suspended" because the important part IMO ("expecting") is
done, and errors/warnings are due for another overhaul RSN. As experience
accumulates with GCC COBOL, we can review the diagnostics again for user
friendliness.
[Bug c++/120377] ICE with fmtlib and modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120377 --- Comment #2 from Cameron Angus --- (In reply to Nathaniel Shead from comment #1) > Having preprocessed sources makes it a lot easier for me, and I understand > that there's some concerns about making sure that bugzilla remains as a > source of truth for the issue even if say godbolt goes down or any of the > other links rot. But if you can't do that I'd still prefer having a bug > over nothing at all :) Understood, yeah that makes sense. Sometimes those extra couple of steps just end up being the difference between me posting a bug or it sitting around for a couple of weeks, that's all. > Your attached sources don't reproduce for me on my current build of trunk; > on GCC15 I get an "error reporting routines re-entered", so it looks like > something we've possibly already fixed for GCC16. Hmm, interesting. I'm on the latest build I have access to, but it is a little over a week old now. I expect a new one will come through soon and I'll test again. I'm fairly sure I went through at least two distinct issues in the process of reducing though, so I may just need to tweak things again. The original ICE I was getting was a segmentation fault, and it changed to the "error reporting routines re-entered" issue somewhere mid-reduction.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #6 from Robert Dubner --- I compiled and installed cppcheck 2.17, which was a bit of an intelligence test. The error messages were very chatty, but didn't actually tell me what I needed to know. It took a while, but the internet came through. So I have a working installation of cppcheck 2.17 Here is simple attempt: bob@doobie:~/repos/gcc-cobol/gcc/cobol$ cppcheck genapi.cc Checking genapi.cc ... genutil.h:104:1: error: There is an unknown macro here somewhere. Configuration is required. If FIXED_WIDE_INT is a macro then please configure it. [unknownMacro] FIXED_WIDE_INT(128) get_power_of_ten(int n); ^ Checking genapi.cc: INCORPORATE_ANALYZER... Checking genapi.cc: LINE_TICK... Checking genapi.cc: YDFLTYPE;YDFLTYPE_IS_DECLARED... Checking genapi.cc: YYLTYPE;YYLTYPE_IS_DECLARED... Checking genapi.cc: _CBLDIAG_H... Checking genapi.cc: _SYMBOLS_H_... Checking genapi.cc: condition_lists... Checking genapi.cc: yy_flex_debug... Since there are a bunch of .h file in gcc/, I tried this: bob@doobie:~/repos/gcc-cobol/gcc/cobol$ cppcheck genapi.cc --force -I.. Checking genapi.cc ... ../hwint.h:62:5: error: #error "Unable to find a suitable type for HOST_WIDE_INT" [preprocessorErrorDirective] #error "Unable to find a suitable type for HOST_WIDE_INT" ^ I don't know what I am doing differently, or why I am seeing errors that you're not.
[Bug lto/58203] memset/memcpy are discarded with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58203 Andrew Pinski changed: What|Removed |Added CC||jas...@chili-chips.com --- Comment #9 from Andrew Pinski --- *** Bug 120393 has been marked as a duplicate of this bug. ***
[Bug lto/58203] memset/memcpy are discarded with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58203 --- Comment #10 from Andrew Pinski --- The basic problem is the gimple IR has no reference to either memset or memcpy in the case of zeroing aggregates or copying them. So the linker does think memset/memcpy is needed. And then when gcc expands the zeroing or copying, a reference happens but it is already too late to bring back in them. Marking memset/memcpy as used should bring in the reference to them if memcpy/memset is only in lto ir.
[Bug bootstrap/120394] c++tools: configure doesn't honer --disable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120394 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-22 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- c++tools/configure.ac has: # Check whether --enable-default-pie was given. AC_ARG_ENABLE(default-pie, [AS_HELP_STRING([--enable-default-pie], [enable Position Independent Executable as default])], [PICFLAG=-fPIE], [PICFLAG=]) So yes --disable-default-pie will be handled incorrectly here. AC_ARG_ENABLE(host-pie, [AS_HELP_STRING([--enable-host-pie], [build host code as PIE])], [PICFLAG=-fPIE; LD_PICFLAG=-pie], []) AC_SUBST(PICFLAG) is also wrong. So is: AC_ARG_ENABLE(host-bind-now, [AS_HELP_STRING([--enable-host-bind-now], [link host code as BIND_NOW])], [LD_PICFLAG="$LD_PICFLAG -Wl,-z,now"], [])
[Bug c++/120393] New: Link-time optimization vs. Os/O2; baremetal memcpy elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120393
Bug ID: 120393
Summary: Link-time optimization vs. Os/O2; baremetal memcpy
elimination
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jas...@chili-chips.com
Target Milestone: ---
Use of `-flto' option generates an error for initialized char string variables.
Here is an example:
char test[] = "Hello world!\r\n";
for (i = 0; i < 14; i++) {
uart_send_char(csr, test[i]);
}
/usr/lib/gcc/riscv64-unknown-elf/13.2.0/../../../riscv64-unknown-elf/bin/ld:
/tmp/ccerPl2Y.ltrans0.ltrans.o: in function `main':
:(.text.startup+0x314): undefined reference to `memcpy'
The error comes from premature optimization, where linker concludes that the
`memcpy' function is not used in the source code, and eliminates it. The
workaround is to accompany the `memcpy' declaration with __attribute__((used)),
such as:
__attribute__((used)) void *memcpy(void *dest, const void *src, size_t
len);
Hence the questions:
Q1) why does `-flto' option make the compile flow optimize out `memcpy'
function, which was actually inserted by the flow, to copy the initialized
strings?
Q2) can other functions outside of `main.cpp', including calls from boot CRT
Assembly code, be similarly eliminated by `-flto'?
This issue is uncovered in Wireguard-FPGA project, where tracked under:
https://github.com/chili-chips-ba/wireguard-fpga/issues/17
It seems related to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119424
[Bug c++/120393] Link-time optimization vs. Os/O2; baremetal memcpy elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120393 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 58203 ***
[Bug other/120394] New: c++tools: configure doesn't honer --disable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120394
Bug ID: 120394
Summary: c++tools: configure doesn't honer
--disable-default-pie
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: deminhan at gcc dot gnu.org
Target Milestone: ---
when pass --disable-default-pie, the enable_default_pie var would be "no".
The if condition met, and PICFLAG was set wrongly.
We should use "yes" or "no" for condition.
Similar issues for host-pie and host-bind-now.
# Check whether --enable-default-pie was given.
# Check whether --enable-default-pie was given.
if test "${enable_default_pie+set}" = set; then :
enableval=$enable_default_pie; PICFLAG=-fPIE
else
PICFLAG=
fi
# Enable --enable-host-pie
# Check whether --enable-host-pie was given.
if test "${enable_host_pie+set}" = set; then :
enableval=$enable_host_pie; PICFLAG=-fPIE; LD_PICFLAG=-pie
fi
# Enable --enable-host-bind-now
# Check whether --enable-host-bind-now was given.
if test "${enable_host_bind_now+set}" = set; then :
enableval=$enable_host_bind_now; LD_PICFLAG="$LD_PICFLAG -Wl,-z,now"
fi
[Bug libstdc++/120388] New: constraint on expected's comparison operator causes infinite recursion, overload resolution fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120388
Bug ID: 120388
Summary: constraint on expected's comparison operator causes
infinite recursion, overload resolution fails
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: justend29 at gmail dot com
Target Milestone: ---
ISSUE
=
The requires clause introduced in GCC15 on std::expected::operator==
prevents any type from being compared if it has std::expected as a template
argument, as evaluation of the constraint depends on itself.
The specific function causing the error is here
(https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/expected;h=5dc1dfbe5b8a954826d2779a9cbc51c953b5e5f0;hb=1b306039ac49f8ad91ca71d3de3150a3c9fa792a#l1172),
where its definition is as such:
1172 template
1173 requires (!__expected::__is_expected<_Up>)
1174 && requires (const _Tp& __t, const _Up& __u) {
1175 { __t == __u } -> convertible_to;
1176 }
1177 friend constexpr bool
1178 operator==(const expected& __x, const _Up& __v)
1179 noexcept(noexcept(bool(*__x == __v)))
1180 { return __x.has_value() && bool(*__x == __v); }
Minimum Reproducible Example
Included below is a minimum reproducible example. You'll notice that
std::expected is never compared. Merely, the compiler's evaluation of the
constraint on operator== during overload resolution causes the infinite
recursion.
// mre.cpp
#include
#include
template
class A {
public:
friend bool operator==(const A&, const A&) {
return true; // not using T == T;
}
T t;
};
int main() {
static_assert(std::equality_comparable>>);
};
This issue is seen on GCC 15+, but not on GCC14, as the requires clause did not
yet exist. Compiler output with GCC 15.1.1 compiling mre.cpp with g++ mre.cpp
is shown below:
In file included from mre.cpp:2:
/usr/include/c++/15.1.1/expected: In substitution of ‘template
requires !(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u)
{{__t == __u} -> decltype(auto) [requires std::convertible_to<,
bool>];} constexpr bool std::operator==(const expected&, const _Up&)
[with _Up = A >]’:
/usr/include/c++/15.1.1/expected:1175:12: required by substitution of
‘template requires !(__is_expected<_Up>) && requires(const _Tp&
__t, const _Up& __u) {{__t == __u} -> decltype(auto) [requires
std::convertible_to<, bool>];} constexpr bool
std::operator==(const expected&, const _Up&) [with _Up =
A >]’
1175 | { __t == __u } -> convertible_to;
| ^~
/usr/include/c++/15.1.1/concepts:306:10: required from here
306 | { __t == __u } -> __boolean_testable;
| ^~
/usr/include/c++/15.1.1/expected:1178:2: required by the constraints of
‘template template requires
!(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u) {{__t == __u}
-> decltype(auto) [requires std::convertible_to<, bool>];}
constexpr bool std::operator==(const expected<_Tp, _Er>&, const _Up&)’
/usr/include/c++/15.1.1/expected:1174:7: in requirements with ‘const _Tp&
__t’, ‘const _Up& __u’ [with _Tp = int; _Up = A >]
/usr/include/c++/15.1.1/expected:1174:14: error: satisfaction of atomic
constraint ‘requires(const _Tp& __t, const _Up& __u) {{__t == __u} ->
decltype(auto) [requires std::convertible_to<, bool>];} [with _Tp
= _Tp; _Up = _Up]’ depends on itself
1174 | && requires (const _Tp& __t, const _Up& __u) {
| ^~~
1175 | { __t == __u } -> convertible_to;
| ~~~
1176 | }
| ~
Problem Evaluation
==
I believe these evaluation steps form the issue:
1. Overload resolution occurs for operator== between two
A>
types
2. std::expected is instantiated, along with its operator== shown
above.
3. Since std::expected is a template argument to A, namespace std is
involved in ADL with std::expected. The instantiated operator==
from
(2.) is then considered.
4. Although no std::expected is being compared, since constraints must be
evaluated before overload resolution, the compiler evaluates the
constraint on line 1175 above when considering the expected's operator==.
Within the constraint, lookup is again performed for operator== between
_Tp and _Up. For this MRE, _Tp is int (from std::expected) and _Up
is
A>.
5. When looking up operator== for the evaluation of the constraint,
std::expected is again a template argument, again bringing in
namespace std into scope, and recursing to step (3.)
Solution
The std::expected's operator== above is similar to this overloa
[Bug c++/120390] Request to improve error with private destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-21 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=117294 --- Comment #2 from Jonathan Wakely --- The error is telling you that the assertion "type is destructible" failed. Like when you get static_assert(some_cond) or assert(some_cond) and it says that some_cond failed. But I usually try to phrase the static assert messages as "X must be Y" to avoid this ambiguity. I'll change that one. I don't think this is a compiler bug. The code failed to compile because of a static_assert, and that's exactly what the compiler tells you. Maybe something like Bug 117294 could help, if that was extended to static_assert as well as concept satisfaction failures.
[Bug c++/120390] Request to improve error with private destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390 --- Comment #3 from nightstrike --- I know it isn't a bug, it's bad code that the compiler is correctly erroring out on. My point is that the original error message was spot on perfect in highlighting the issue being that the destructor was private. The new error message leaves that important detail out.
[Bug c++/120390] Request to improve error with private destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390 --- Comment #4 from Jonathan Wakely --- There's also the source context which should be pretty clear what the assertion was testing when it failed: 188 | static_assert(is_destructible<_Value_type>::value, But I think the best solution is to move the static_assert so it is only checked for types with a trivial destructor, because it isn't needed otherwise: --- a/libstdc++-v3/include/bits/stl_construct.h +++ b/libstdc++-v3/include/bits/stl_construct.h @@ -204,9 +204,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION typedef typename iterator_traits<_ForwardIterator>::value_type _Value_type; #if __cplusplus >= 201103L - // A deleted destructor is trivial, this ensures we reject such types: - static_assert(is_destructible<_Value_type>::value, - "value type must be destructible"); if constexpr (!__has_trivial_destructor(_Value_type)) for (; __first != __last; ++__first) std::_Destroy(std::__addressof(*__first)); @@ -215,6 +212,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION for (; __first != __last; ++__first) std::destroy_at(std::__addressof(*__first)); #endif + else + // A deleted destructor is trivial, this ensures we reject such types: + static_assert(is_destructible<_Value_type>::value, + "value type must be destructible"); #else std::_Destroy_aux<__has_trivial_destructor(_Value_type)>:: __destroy(__first, __last); This restores the original error: 'MovieData::~MovieData()' is private within this context
[Bug target/120090] [16 Regression] gcc.target/i386/avx512bw-pr103750-2.c since r16-160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120090 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Andrew Pinski --- Fixed.
[Bug target/120090] [16 Regression] gcc.target/i386/avx512bw-pr103750-2.c since r16-160
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120090 --- Comment #10 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:f725d6765373f7884a2ea23bc11409b15545958b commit r16-809-gf725d6765373f7884a2ea23bc11409b15545958b Author: Andrew Pinski Date: Mon May 5 09:46:14 2025 -0700 combine: gen_lowpart_no_emit vs CLOBBER [PR120090] The problem here is simplify-rtx.cc expects gen_lowpart_no_emit to return NULL on failure but combine's hook was returning CLOBBER. After r16-160-ge6f89d78c1a7528e93458278, gcc.target/i386/avx512bw-pr103750-2.c started to fail at -m32 due to this as new simplify code would return a RTL with a clobber in it rather than returning NULL. To fix this gen_lowpart_no_emit should return NULL when there was an failure instead of a clobber. This only changes the gen_lowpart_no_emit hook and not the generic gen_lowpart hook as parts of combine just pass gen_lowpart result directly without checking the return value. Bootstrapped and tested on x86_64-linux-gnu. PR rtl-optimization/120090 gcc/ChangeLog: * combine.cc (gen_lowpart_for_combine_no_emit): New function. (RTL_HOOKS_GEN_LOWPART_NO_EMIT): Set to gen_lowpart_for_combine_no_emit. Signed-off-by: Andrew Pinski
[Bug c++/120390] Request to improve error with private destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390 --- Comment #1 from nightstrike --- (In reply to nightstrike from comment #0) > either 1) I was missing private:, "missing public:", obviously
[Bug c++/120390] New: Request to improve error with private destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390
Bug ID: 120390
Summary: Request to improve error with private destructor
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nightstrike at gmail dot com
Target Milestone: ---
I recently encountered this exact problem:
https://web.archive.org/web/20250521203035/https://stackoverflow.com/questions/67962227/static-assert-failed-because-value-type-is-destructible-for-stdvector
(which I conveniently saved to archive.org for whoever reads this in 20 years.)
Since that post is effectively the same as my own issue, I'm reposting that
(shortened) code instead of my own:
```
#include
class MovieData {
MovieData(){}
~MovieData(){}
};
int main() {
std::vector movies; // Line 16
return 0;
}
```
On old gcc 4.8.2, we get a loud but ultimately useful error output:
/usr/include/c++/4.8.2/bits/stl_construct.h: In instantiation of ‘void
std::_Destroy(_Tp*) [with _Tp = MovieData]’:
/usr/include/c++/4.8.2/bits/stl_construct.h:103:46: required from ‘static
void std::_Destroy_aux< >::__destroy(_ForwardIterator,
_ForwardIterator) [with _ForwardIterator = MovieData*; bool =
false]’
/usr/include/c++/4.8.2/bits/stl_construct.h:127:27: required from ‘void
std::_Destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator =
MovieData*]’
/usr/include/c++/4.8.2/bits/stl_construct.h:151:31: required from ‘void
std::_Destroy(_ForwardIterator, _ForwardIterator, std::allocator<_T2>&) [with
_ForwardIterator = MovieData*; _Tp = MovieData]’
/usr/include/c++/4.8.2/bits/stl_vector.h:416:30: required from
‘std::vector<_Tp, _Alloc>::~vector() [with _Tp = MovieData; _Alloc =
std::allocator]’
a.cc:9:29: required from here
a.cc:5:10: error: ‘MovieData::~MovieData()’ is private
~MovieData(){}
^
In file included from /usr/include/c++/4.8.2/vector:62:0,
from a.cc:1:
/usr/include/c++/4.8.2/bits/stl_construct.h:93:7: error: within this context
{ __pointer->~_Tp(); }
^
Specifically, "error: ‘MovieData::~MovieData()’ is private". This is great!
However, on 14.1, we get the more verbose and less helpful output:
In file included from /tmp/gcc-14.1-rh7/include/c++/14.1.0/vector:64,
from a.cc:1:
/tmp/gcc-14.1-rh7/include/c++/14.1.0/bits/stl_construct.h: In instantiation of
'void std::_Destroy(_ForwardIterator, _ForwardIterator) [with _ForwardIterator
= MovieData*]':
/tmp/gcc-14.1-rh7/include/c++/14.1.0/bits/alloc_traits.h:944:20: required
from 'void std::_Destroy(_ForwardIterator, _ForwardIterator, allocator<_T2>&)
[with _ForwardIterator = MovieData*; _Tp = MovieData]'
944 | std::_Destroy(__first, __last);
| ~^
/tmp/gcc-14.1-rh7/include/c++/14.1.0/bits/stl_vector.h:735:15: required from
'std::vector<_Tp, _Alloc>::~vector() [with _Tp = MovieData; _Alloc =
std::allocator]'
735 | std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
| ~^
736 | _M_get_Tp_allocator());
| ~~
a.cc:9:29: required from here
9 | std::vector movies; // Line 16
|^~
/tmp/gcc-14.1-rh7/include/c++/14.1.0/bits/stl_construct.h:188:51: error: static
assertion failed: value type is destructible
188 | static_assert(is_destructible<_Value_type>::value,
| ^
/tmp/gcc-14.1-rh7/include/c++/14.1.0/bits/stl_construct.h:188:51: note:
'std::integral_constant::value' evaluates to false
There are a few things that made this difficult to track down. Obviously, the
original message describing the core problem is gone -- that the destructor is
private. Instead, it's replaced with "value type is destructible", which is
confusing. At first glance, when I looked at the code, I thought "Of course
it's destructible, there's the destructor!" And when I removed the destructor,
it compiled perfectly. This was puzzling, and the error output sent me in
ambiguous circles. Now, obviously, I should have recognized that either 1) I
was missing private:, or 2) I was using class, not struct, but I'm a flawed
human that makes mistakes. It'd be awesome if the compiler could help me make
fewer of them :)
[Bug tree-optimization/120357] [15 16 Regression] RISC-V: ICE in vect pass "error: definition in block 9 does not dominate use in block 3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 Jeffrey A. Law changed: What|Removed |Added CC||acoplan at gcc dot gnu.org Summary|[16 Regression] RISC-V: ICE |[15 16 Regression] RISC-V: |in vect pass "error:|ICE in vect pass "error: |definition in block 9 does |definition in block 9 does |not dominate use in block |not dominate use in block |3" |3" --- Comment #1 from Jeffrey A. Law --- Bisect lands on: commit 68326d5d1a593dc0bf098c03aac25916168bc5a9 (HEAD) Author: Alex Coplan Date: Mon Mar 11 13:09:10 2024 + vect: Force alignment peeling to vectorize more early break loops [PR118211] This allows us to vectorize more loops with early exits by forcing peeling for alignment to make sure that we're guaranteed to be able to safely read an entire vector iteration without crossing a page boundary. To make this work for VLA architectures we have to allow compile-time non-constant target alignments. We also have to override the result of the target's preferred_vector_alignment hook if it isn't a power-of-two multiple of the TYPE_SIZE of the chosen vector type. [ ... ]
[Bug c++/120318] Module deduced return type error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120318
--- Comment #3 from Patrick Palka ---
Probably not very useful but here's a mechanically reduced testcase (fixed by
r16-504):
$ cat std.ii
module;
16:56 [38/1494]
namespace std {
template auto declval() -> decltype(0);
template void forward() {}
template
concept convertible_to = requires { declval; };
template
concept move_constructible = convertible_to<_Tp, _Tp>;
namespace ranges {
inline namespace _Cpo {}
} // namespace ranges
namespace __detail {
template using __iter_concept = _Iter;
}
template
concept input_iterator = requires { typename __detail::__iter_concept<_Iter>;
};
namespace ranges {
namespace _Cpo {
int end;
}
template
concept range = requires { end; };
template
concept input_range = input_iterator<_Tp>;
template
concept viewable_range = range<_Tp>;
} // namespace ranges
struct vector {};
namespace ranges {
template
concept __adaptor_invocable = requires { declval<_Adaptor>; };
template struct _Partial;
template
concept __is_range_adaptor_closure = requires(_Tp __t) { __t; };
template
requires __is_range_adaptor_closure<_Self> &&
__adaptor_invocable<_Self, _Range>
constexpr auto operator|(_Range &&, _Self &&) {}
template struct _RangeAdaptorClosure {
template
requires __is_range_adaptor_closure<_Self> &&
__adaptor_invocable<_Self, _Range>
friend constexpr auto operator|(_Range &&, _Self &&);
};
struct _RangeAdaptor {
template auto operator()(_Args...) {
return _Partial{0, forward<_Args>...};
}
};
template
struct _Partial<_Adaptor, _Arg> : _RangeAdaptorClosure<_Arg> {
template _Partial(int, _Tp) {}
};
namespace views {
_RangeAdaptorClosure all;
template using all_t = decltype(all);
} // namespace views
template class transform_view;
template
transform_view() -> transform_view, _Fp>;
namespace views {
namespace __detail {
template
concept __can_transform_view = requires { transform_view(declval); };
} // namespace __detail
struct _Transform : _RangeAdaptor {
template
requires __detail::__can_transform_view<_Range, _Fp>
auto operator0();
} inline transform;
} // namespace views
} // namespace ranges
} // namespace std
export module std;
export namespace std {
namespace ranges {
namespace views {
using views::transform;
}
} // namespace ranges
using std::vector;
} // namespace std
$ cat 120318.C
import std;
using std::vector;
using std::ranges::views::transform;
int main(int argl,char**argv)
{
vector v;
v | transform([](int x){return x * x % 24;});
return 0;
}
[Bug libstdc++/120387] constraint on expected's comparison operator causes infinite recursion, overload resolution fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387 --- Comment #4 from Justen Di Ruscio --- Pardon me for not seeing that this has been resolved. I'll also ensure to expressly include the output of 'gcc -v', as opposed to mentioning the version, even if the cause is provided. This is my first report.
[Bug libstdc++/120387] constraint on expected's comparison operator causes infinite recursion, overload resolution fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120387 --- Comment #5 from Jonathan Wakely --- The instructions at https://gcc.gnu.org/bugs/ are very explicit about including that information. 15.1.1 is not a release, it's any snapshot between the date of the 15.1.0 release and now, so is not enough to tell us what you're using. That's why we ask for the 'gcc -v' output.
[Bug tree-optimization/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting/eiline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 --- Comment #11 from Andrew Pinski --- (In reply to Andrew Pinski from comment #10) > > Note this is a GCC extension even. For C++.
[Bug c++/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ice-on-valid-code --- Comment #8 from Andrew Pinski --- .
[Bug tree-optimization/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 Andrew Pinski changed: What|Removed |Added Attachment #61491|0 |1 is obsolete|| --- Comment #9 from Andrew Pinski --- Created attachment 61492 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61492&action=edit Reduced slightly some more This one also fails with the C front-end but in einline rather than fnsplit. But both are the same issue.
[Bug tree-optimization/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 Andrew Pinski changed: What|Removed |Added Component|c++ |tree-optimization Blocks|16994 | Target Milestone|--- |12.5 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 [Bug 16994] [meta-bug] VLA and C++
[Bug tree-optimization/120392] [12/13/14/15/16 REgression] ICE with VLA typedef and function splitting/eiline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120392 --- Comment #10 from Andrew Pinski --- The original code: ``` typedef u16 TImage[][m_nBytesPerLine / sizeof (u16)]; ``` Note this is a GCC extension even.
[Bug bootstrap/103459] Make configury regenerate cleanly with `autoreconf -Wall`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103459 pietro changed: What|Removed |Added CC||pietro at gcc dot gnu.org --- Comment #4 from pietro --- Patch to fix some warnings: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684459.html
[Bug c++/120379] [modules] dependency file generation causes ICE when two export module declarations are provided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120379 Nathaniel Shead changed: What|Removed |Added Ever confirmed|0 |1 Summary|[modules] |[modules] dependency file |-fdeps-format=p1689r5 |generation causes ICE when |causes ICE when two export |two export module |module declarations are |declarations are provided |provided| Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-21 --- Comment #1 from Nathaniel Shead --- Actually, just '-M' is enough.
[Bug cobol/119231] gcobol -static produces a dynamically linked executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119231 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Last reconfirmed||2025-05-21 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug cobol/119221] RFE: fix-it hints for cobol syntax errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119221 Bug 119221 depends on bug 119256, which changed state. Bug 119256 Summary: Capture source ranges for tokens in gcobol https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119256 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX
[Bug c/120382] ICE with hardbool attribute and undeclared variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120382 Kael Franco changed: What|Removed |Added CC||kaelfandrew at gmail dot com --- Comment #2 from Kael Franco --- This is a regression between 15.1 and 20250519 according to Godbolt.
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #7 from David Binderman --- (In reply to Robert Dubner from comment #6) > I don't know what I am doing differently, or why I am seeing errors that > you're not. Instead of trying to duplicate my results, you could try just fixing the problems I reported.
[Bug c/120382] [14/15/16 Regression] ICE with hardbool attribute and undeclared variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120382 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.3 Known to fail||14.2.0 Known to work||13.3.0 Summary|ICE with hardbool attribute |[14/15/16 Regression] ICE |and undeclared variable |with hardbool attribute and ||undeclared variable --- Comment #3 from Andrew Pinski --- (In reply to Kael Franco from comment #2) > This is a regression between 15.1 and 20250519 according to Godbolt. Not really: :1: confused by earlier errors, bailing out GCC 14 and 15 also ICEs but it is hidden due to previous error message and the release compilers use --enable-checking=release while the trunk is compiled with --enable-checking=yes. If anything it is a regression from GCC 13.
[Bug c++/120377] ICE with fmtlib and modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120377 --- Comment #3 from Cameron Angus --- Just updated to version 16.0.0 20250518 which just came through, but still seeing the same ICE (error routines re-entered). So will have to wait for the next one, or if I can work out how maybe I'll try to build from source, since it seems that would be the best way to avoid wasting time on things that are already fixed.
[Bug c++/120377] ICE with fmtlib and modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120377 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org --- Comment #1 from Nathaniel Shead --- Thanks for the report! (In reply to Cameron Angus from comment #0) > I also created a reproduction on Compiler Explorer, though the precise ICE > seems to be slightly different due to a difference in GCC and/or fmtlib > version: https://godbolt.org/z/j1as93bvv The godbolt is showing a different error due to the flags that CMake has added for scanning dependencies; I've created PR120379 for this. (It looks like there might have been some accidental copy/pasting of module definitions into the same file, perhaps?) Your attached sources don't reproduce for me on my current build of trunk; on GCC15 I get an "error reporting routines re-entered", so it looks like something we've possibly already fixed for GCC16. > I'd also like to ask, in future is logging a bug report with a Compiler > Explorer reproduction only (no preprocessed sources) an option? I'm not a > regular user of GCC or Linux systems so the process of recreating on CE is > simpler for me if that is acceptable. Having preprocessed sources makes it a lot easier for me, and I understand that there's some concerns about making sure that bugzilla remains as a source of truth for the issue even if say godbolt goes down or any of the other links rot. But if you can't do that I'd still prefer having a bug over nothing at all :)
[Bug tree-optimization/120341] [15/16 Regregression] wrong code at -O1 and above with "-fallow-store-data-races" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120341
--- Comment #4 from Zhendong Su ---
Here is another very similar reproducer that only fails at -Os and seems to go
back to at least as early as 10.1.
Compiler Explorer: https://godbolt.org/z/7e4jePnY7
[508] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250521 (experimental) (GCC)
[509] %
[509] % gcctk -Os small.c; ./a.out
[510] %
[510] % gcctk -Os -fallow-store-data-races small.c
[511] % ./a.out
Segmentation fault
[512] %
[512] % cat small.c
char a, *b;
int main() {
while (a) {
b = "0";
b[0]++;
}
return 0;
}
[Bug c++/120385] [14/15/16 Regression] GCC 14 incorrectly accepts array prvalues with certain operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120385
--- Comment #1 from Andrew Pinski ---
Is this still valid?
```
int main()
{
using IA = int[];
using IP = int*;
void(+IP{IA{ 1, 2, 3 }});
}
```
Which makes this kinda of inconsistent after all.
[Bug libstdc++/120386] New: std::unique_copy uses the output type for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120386
Bug ID: 120386
Summary: std::unique_copy uses the output type for comparisons
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
struct X { X(int){} };
void uniq(const int* first, const int* last, X* out)
{
std::unique_copy(first, last, out);
}
/usr/include/c++/14/bits/predefined_ops.h:117:23: error: no match for
‘operator==’ (operand types are ‘X’ and ‘const int’)
117 | { return *__it1 == *__it2; }
|~~~^
When the output iterator has category std::forward_iterator_tag we choose an
implementation that compares the output value with the input value, even though
they might be different types.
The standard is clear (since C++98) that the comparisons should be on two
values from the input range:
Copies only the first element from every consecutive group of equal elements
referred
to by the iterator i in the range [first, last) for which the following
corresponding
conditions hold: *i == *(i - 1) or pred(*i, *(i - 1)) != false
We seem to have done this wrong since the beginning of time (at least since
2001).
[Bug libstdc++/120386] std::unique_copy uses the output type for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120386 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2025-05-21 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug middle-end/118694] OpenMP: target/metadirective/teams directive nesting gives error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694
--- Comment #6 from Tobias Burnus ---
> Are we required to diagnose this as an error
> or is it allowable to permit this as an extension?
Answer "no" and "yes" - but the problem is that in general it does not work.
(Potential wrong code issues, albeit as below only bad and not very bad.)
The problem is that for
#pragma omp target
#pragma teams
on common offload hardware (like the AMD and Nvidia GPUs), the code is
not executed as:
- Start the offload kernel
- then, on the device start multiple teams
But:
- Start the offload kernel with several teams
Thus, it is impossible to add code between 'target' and 'teams'. For user code,
this is really very easy to generate wrong code in this case! And there is also
no directive that syncs multiple teams (contention groups) - except that once
the teams construct has finished, all teams have finished. Otherwise, only
thread synchronization in a single team (contention group works → cgroup ~
pteam).
* * *
In particular, if I execute your code and set the GOMP_DEBUG=1 env var, I see:
GOMP_OFFLOAD_run: kernel f$_omp_fn$0: launch [(teams: 1), 1, 1] [(lanes: 32),
(threads: 8), 1]
GOMP_OFFLOAD_run: kernel f$_omp_fn$0: launch [(teams: 1), 1, 1] [(lanes: 32),
(threads: 8), 1]
If I replace the condition by
when (user={condition(1)}: teams loop) \
the result is (twice):
GOMP_OFFLOAD_run: kernel f$_omp_fn$0: launch [(teams: 60), 1, 1] [(lanes:
32), (threads: 8), 1]
Thus, the code runs with 60 teams while your code is run only with a single
team. This implies that the the runtime could be 60 faster, cutting it down
from 1 hour to 1 minute!
(It could be even a bit faster if memory access + caching improve, but
typically it is quite a bit less than 60×, but it should still be very
visible!)
* * *
BTW: I wonder why it doesn't work for
constexpr int flag2 = 1;
...
when (user={condition(flag2)}: teams loop) \
shouldn't this be compile-time optimized (assuming C23 or a semi-new C++)?
I still see:
teams2.c:10:11: warning: ‘target’ construct with nested ‘teams’ construct
contains directives outside of the ‘teams’ construct [-Wopenmp]
and for the launch accordingly: "launch [(teams: 1),".
And, unsurprisingly, I also get the same for:
when (device={kind(nohost)}: teams loop) \
which is the case that we want to handle here.
[Bug middle-end/120378] Support narrowing clip idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378 --- Comment #1 from Hongtao Liu --- > The ifcvt'ed code before vect is: > > _4 = *_3; > x.0_12 = (unsigned int) _4; > _38 = -x.0_12; > _15 = (int) _38; > _16 = _15 >> 31; > _29 = x.0_12 > 255; > _17 = _29 ? _16 : _4; > _18 = (unsigned char) _17; > For the testcase in PR, I think x.0_12 > 255 must be false since it's zero_extend from unsigned char. So the comparison can be optimized off?
[Bug cobol/119332] cobol frontend does not support version dump options specified in --help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119332 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org --- Comment #2 from James K. Lowden --- $ gcobol -dumpmachine /dev/null aarch64-unknown-linux-gnu $ gcobol -dumpmachine gcobol: fatal error: no input files Not sure this is right, either: gcobol -dumpversion /dev/null 16.0.0
[Bug c/120382] New: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:6562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120382 Bug ID: 120382 Summary: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:6562 Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: xieym3 at zohomail dot com Target Milestone: --- $ cat file.c typedef int __attribute__((hardbool(0, a))) B; $ gcc -v Using built-in specs. COLLECT_GCC=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/bin/gcc COLLECT_LTO_WRAPPER=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /data/xieym/work-rgf/misc_tools/src/gcc-trunk/configure --enable-coverage --enable-checking --disable-multilib --disable-shared --disable-bootstrap --enable-language=c,c++ --prefix=/data/xieym/work-rgf/misc_tools/install/gcc-trunk Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 16.0.0 20250519 (experimental) (GCC) $ gcc -c file.c -o /dev/null :1:1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in extended_tree, at tree.h:6562 1 | typedef int __attribute__((hardbool(0, a))) B; | ^~~ 0x260c7a5 diagnostic_context::diagnostic_impl(rich_location*, diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag (*) [1], diagnostic_t) ???:0 0x262a516 internal_error(char const*, ...) ???:0 0x8fab53 tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) ???:0 0xa0ea76 decl_attributes(tree_node**, tree_node*, int, tree_node*) ???:0 0xa307b9 start_decl(c_declarator*, c_declspecs*, bool, tree_node*, bool, unsigned long*) ???:0 0xabbbee c_parse_file() ???:0 0xb3c959 c_common_parse_file() ???:0 Godbolt url: https://godbolt.org/z/5bnnPThWE
[Bug libstdc++/120367] [15/16 Regression] C++23 ranges::transform | ranges::to exception catching (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367
--- Comment #5 from Jonathan Wakely ---
Reduced:
#include
int main()
{
struct X
{
X(int) { throw 1; } // Cannot successfully construct an X.
~X() { VERIFY(false); } // So should never need to destroy one.
};
try
{
int i[1]{};
std::vector v(std::from_range, i);
}
catch (int)
{
}
}
[Bug cobol/119329] cobol frontend does not support -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119329 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org Assignee|pinskia at gcc dot gnu.org |jklowden at gcc dot gnu.org --- Comment #3 from James K. Lowden --- This may depend on 117009 but that, if necessary, is insufficient. Warnings at present are not enumerated to the framework, and so have no names to turn on/off, or to elevate to errors. Those changes need to be done in the COBOL FE, and that makes this PR my job.
[Bug libstdc++/120386] std::unique_copy uses the output type for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120386 --- Comment #1 from Jonathan Wakely --- It looks like I've rediscovered https://cplusplus.github.io/LWG/issue2439 which summarized (and fixed) the requirements that imply how this needs to work. https://cplusplus.github.io/LWG/issue241 and https://cplusplus.github.io/LWG/issue538 tried to state the requirements for std::unique_copy, but failed to notice the same-type requirement.
[Bug tree-optimization/120383] New: Improving early break unrolled sequences with Adv. SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120383
Bug ID: 120383
Summary: Improving early break unrolled sequences with Adv.
SIMD
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Blocks: 53947, 115130
Target Milestone: ---
Target: aarch64*
Today if we unroll an early break loop such as:
#define N 640
long long a[N] = {};
long long b[N] = {};
int f1 (long long c)
{
for (int i = 0; i < N; i++)
{
if (a[i] == c)
return 1;
}
return 0;
}
we generate an ORR reduction followed by a compression sequence when using Adv.
SIMD.
ldp q31, q30, [x1], 32
cmeqv31.2d, v31.2d, v27.2d
cmeqv30.2d, v30.2d, v27.2d
orr v31.16b, v31.16b, v30.16b
umaxp v31.4s, v31.4s, v31.4s
fmovx4, d31
cbz x4, .L2
fmovw1, s29
However the dependency chain here is long enough that it removes the vector
profitability.
This sequence can however be replaced by:
ldp q31, q30, [x0], 32
cmeqv31.2d, v31.2d, v29.2d
cmeqv30.2d, v30.2d, v29.2d
addhn v31.2s, v31.2d, v30.2d
fmovx2, d31
cbz x2, .L15
with addhn replacing the ORR reduction and the UMAXP compression.
When using 3 compare statements, we can use nested addhn, when 4 we can create
2 ORRs + ADDHN.
The AArch64 ADDHN (Add and Halve Narrow) instruction performs an addition of
two vectors of the same size, then truncates (narrow) the result by keeping
only the higher half of each element.
This means that this is hard to do in RTL as you wouldn't be able to match this
long sequence with combine, and the intermediate combinations aren't valid. for
instance it's only possible when the vector mask values are 0 and -1 and so we
would need to know that the values in the registers are vector mask values.
An RTL folder won't work either as it won't let us get the nested variant.
Which leaves a gimple folder or support in the vectorizer for this.
By far the simplest version is using the vectorizer, as it knows about mask
type (e.g. VECTOR_BOOLEAN_P (..)) , it knows about the precision of the mask
type and it's the one generating the sequence so it can choose how to do the
reductions.
However for this to work we have to introduce an optab for addhn. Open coding
the sequence doesn't work as we don't have a way to describe that the addition
is done as a higher precision.
With the optab the final codegen can generate a scalar cbranch rather than a
vector one and gets the result we want.
This makes unrolling an early break loop much more profitable on AArch64.
Having looked into the options and describing the limitations above, are you ok
with a new optab
for addhn Richi?
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115130
[Bug 115130] [meta-bug] early break vectorization
[Bug tree-optimization/120383] Improving early break unrolled sequences with Adv. SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120383 Tamar Christina changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||rguenth at gcc dot gnu.org Last reconfirmed||2025-05-21
[Bug c++/120385] New: Incorrectly accepts array prvalues with certain operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120385
Bug ID: 120385
Summary: Incorrectly accepts array prvalues with certain
operators
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: language.lawyer at gmail dot com
Target Milestone: ---
GCC 14 started accepting array prvalue operands where they are not allowed
(https://godbolt.org/z/6hj5YbTx7)
int main()
{
using IA = int[];
void(+IA{ 1, 2, 3 });
void(*IA{ 1, 2, 3 });
void(IA{ 1, 2, 3 } + 0);
void(IA{ 1, 2, 3 } - 0);
void(0 + IA{ 1, 2, 3 });
void(IA{ 1, 2, 3 } - IA{ 1, 2, 3 });
}
All of the void(...) lines shall make the program ill-formed
[Bug c++/120385] [14/15/16 Regression] Regression] GCC 14 incorrectly accepts array prvalues with certain operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120385 Andrew Pinski changed: What|Removed |Added Summary|[Regression] GCC 14 |[14/15/16 Regression] |incorrectly accepts array |Regression] GCC 14 |prvalues with certain |incorrectly accepts array |operators |prvalues with certain ||operators Target Milestone|--- |14.3
[Bug c/120380] New: internal compiler error: error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120380
Bug ID: 120380
Summary: internal compiler error: error reporting routines
re-entered
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: xieym3 at zohomail dot com
Target Milestone: ---
$ cat file.c
struct pair_t {
char c;
__int128_t i;
} __attribute__((packed));
typedef struct unaligned_int128_t_ {
struct unaligned_int128_t_ {
struct unaligned_int128_t_ {
__int128_t value;
}
}
} __attribute__((packed, may_alias)) unaligned_int128_t;
struct pair_t p = {0, 1};
unaligned_int128_t *addr = (unaligned_int128_t *)&p.i;
int main() {
addr->value = 0;
return 0;
}
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/bin/gcc
COLLECT_LTO_WRAPPER=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /data/xieym/work-rgf/misc_tools/src/gcc-trunk/configure
--enable-coverage --enable-checking --disable-multilib --disable-shared
--disable-bootstrap --enable-language=c,c++
--prefix=/data/xieym/work-rgf/misc_tools/install/gcc-trunk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250519 (experimental) (GCC)
$ gcc -c file.c -o /dev/null
internal compiler error: error reporting routines re-entered.
0x260c68e diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x260c7a5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2628d71 warning(diagnostic_option_id, char const*, ...)
???:0
0xa0d188 build_type_attribute_qual_variant(tree_node*, tree_node*, int)
???:0
0x264dec3 pretty_printer::format(text_info&)
???:0
0x260c2e6 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x260c7a5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2629dff error_at(unsigned long, char const*, ...)
???:0
0xa56ae2 build_component_ref(unsigned long, tree_node*, tree_node*, unsigned
long, unsigned long, bool)
???:0
0xabbbee c_parse_file()
???:0
0xb3c959 c_common_parse_file()
???:0
Godbolt url: https://godbolt.org/z/9nMEo96as
[Bug middle-end/119600] HOST_WIDEST_FAST_INT should be used instead of long for BITMAP_WORD in bitmap.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119600 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #1) > (In reply to Andrew Pinski from comment #0) > > Looks like I missed this while I implemented PR 13987. > > I missed it because I was changing HOST_WIDE_INT places and bitmap.h was > changed to use long in r0-47360-g72e42e26cb760d which I assume to fix a > similar compile time regression. I did that because the bitmap stuff was very high in the overall profiles. It didn't have anything to do with a compile-time regression, at least not directly.
[Bug target/120368] [16 Regression] wrong code with -O -fno-forward-propagate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120368 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2025-05-21 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug cobol/119256] Capture source ranges for tokens in gcobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119256 James K. Lowden changed: What|Removed |Added Status|WAITING |RESOLVED CC||jklowden at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from James K. Lowden --- The source range is indicated as designed. The dot in PROGRAM-ID. is specified as an optional part of the syntax. In the ISO spec under "8.3.5 Separators", it says: "3) The COBOL character period, when followed by a space, is a separator. The separator period shall be used only to indicate the end of a sentence, or as shown in formats." This is a "shown in format" case. Granted, it's debatable whether or not "an optional part of the syntax" is part of the error. Variations in input will provoke slightly different messages. But the user is not confused, and the diagnostic is not malformed.
[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243
--- Comment #6 from Iain Sandoe ---
a slightly modified testcase (without the lambda, so the dumps are easier to
read)
#include
struct coro {
struct promise_type {
promise_type() = default;
std::suspend_never initial_suspend() const noexcept {
__builtin_printf("initial_suspend\n");
return {};
}
std::suspend_never final_suspend() const noexcept { return {}; }
void unhandled_exception() {
__builtin_printf("unhandled_exception\n");
throw;
}
coro get_return_object() { return {}; }
void return_void() {}
};
};
coro
test ()
{
__builtin_printf("test\n");
throw "hello";
__builtin_abort();
co_return;
}
int main() {
coro C;
try {
C = test ();
}
catch(...) {
__builtin_printf("Caught!\n");
}
}
===
This fails for O2 and passes for O1
The first difference in the dumps is in fixup_cfg3 and the difference is that
the actor function gets inlined into the ramp.
-fnoinline restores function.
GCC-14 does not seem to inline the same case.
.. next to figure out how the inlining is breaking the EH.
[Bug c/120381] [14/15/16 Regression] internal compiler error: in composite_type_internal, at c/c-typeck.cc:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381 --- Comment #2 from Joseph S. Myers --- Nesting one definition of struct A inside another is never valid (and the godbolt link shows the expected "nested redefinition" error that the PR doesn't quote).
[Bug cobol/119335] cobol frontend ignores -M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119335 James K. Lowden changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from James K. Lowden --- Marked as fixed until further notice. The list produced by -M is taken from the names recorded by processing COPY statements. The same list is used to prevent COPY recursion and to report filenames and line numbers for diagnostic messages. It should be right. We do not as of now attempt to report nesting; all copybooks used by X are reported as dependencies of X. If one copybook in that chain depends on another, that fact is not evinced by the -M option.
[Bug libstdc++/120384] New: [12/13/14/15/16] _BinaryPredicateConcept checks in std::unique_copy are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120384
Bug ID: 120384
Summary: [12/13/14/15/16] _BinaryPredicateConcept checks in
std::unique_copy are wrong
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#define _GLIBCXX_CONCEPT_CHECKS 1
#include
void uniq(const int* first, const int* last, int* out)
{
std::unique_copy(first, last, out);
}
This valid code fails to compile with:
/usr/include/c++/14/bits/predefined_ops.h:117:16: error: invalid type argument
of unary ‘*’ (have ‘int’)
117 | { return *__it1 == *__it2; }
|^~
/usr/include/c++/14/bits/predefined_ops.h:117:26: error: invalid type argument
of unary ‘*’ (have ‘int’)
117 | { return *__it1 == *__it2; }
| ^~
This was broken by r0-125454-gea89b2482f97aa
[Bug libstdc++/120384] [12/13/14/15/16] _BinaryPredicateConcept checks in std::unique_copy are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120384 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Known to fail||12.4.0, 13.3.0, 14.2.0, ||15.1.0, 16.0, 4.9.0 Known to work||4.8.5 Last reconfirmed||2025-05-21 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug c/120381] New: internal compiler error: in composite_type_internal, at c/c-typeck.cc:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381
Bug ID: 120381
Summary: internal compiler error: in composite_type_internal,
at c/c-typeck.cc:848
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: xieym3 at zohomail dot com
Target Milestone: ---
$ cat file.c
struct A {
struct A {
struct A *p;
} *p;
};
int foo(const struct A *q) { return q->p == q; }
void bar(int);
void baz() {
struct A a;
while (foo(&a))
bar(foo(&a));
}
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/bin/gcc
COLLECT_LTO_WRAPPER=/data/xieym/work-rgf/misc_tools/install/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /data/xieym/work-rgf/misc_tools/src/gcc-trunk/configure
--enable-coverage --enable-checking --disable-multilib --disable-shared
--disable-bootstrap --enable-language=c,c++
--prefix=/data/xieym/work-rgf/misc_tools/install/gcc-trunk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250519 (experimental) (GCC)
$ gcc -c file.c -o /dev/null
:6:22: internal compiler error: in composite_type_internal, at
c/c-typeck.cc:848
6 | int foo(const struct A *q) { return q->p == q; }
| ^
0x260c7a5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x262a516 internal_error(char const*, ...)
???:0
0x9f37e0 fancy_abort(char const*, int, char const*)
???:0
0xa53093 build_binary_op(unsigned long, tree_code, tree_node*, tree_node*,
bool)
???:0
0xa55496 parser_build_binary_op(unsigned long, tree_code, c_expr, c_expr)
???:0
0xabbbee c_parse_file()
???:0
0xb3c959 c_common_parse_file()
???:0
Godbolt url: https://godbolt.org/z/PKefohbPv
[Bug c/120381] internal compiler error: in composite_type_internal, at c/c-typeck.cc:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-21 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed, I don't know if this is valid or not but GCC should NOT ICE. It is a front-end issue related to the struct tag rules in C23.
[Bug c/120381] [14/15/16 Regression] internal compiler error: in composite_type_internal, at c/c-typeck.cc:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120381 Andrew Pinski changed: What|Removed |Added Summary|internal compiler error: in |[14/15/16 Regression] |composite_type_internal, at |internal compiler error: in |c/c-typeck.cc:848 |composite_type_internal, at ||c/c-typeck.cc:848 Target Milestone|--- |14.3
[Bug c/120382] ICE with hardbool attribute and undeclared variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120382 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-21 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/120380] [14/15/16 Regression] internal compiler error: error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120380 Andrew Pinski changed: What|Removed |Added Known to work||13.3.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |14.3 Last reconfirmed||2025-05-21 Summary|internal compiler error:|[14/15/16 Regression] |error reporting routines|internal compiler error: |re-entered |error reporting routines ||re-entered --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug cobol/119336] cobol: missing copybooks break parser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119336
James K. Lowden changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot
gnu.org
Resolution|--- |WONTFIX
CC||jklowden at gcc dot gnu.org
--- Comment #2 from James K. Lowden ---
This is a comedy of errors, only partly fixable.
When the COPY statement fails, lexing has moved to the next line. The reported
error is correct. But the source range for the caret is wrong on the 2nd
message because of the dance between the CDF parser, the lexer, and the main
parser. It's not that the caret points to the wrong word ("DIVISION") in a
2-word token. It's pointing to the column for the '.' on the previous line,
which was abandoned by the CDF is and is invalid in the main program ahead of
IDENTIFICATION DIVISION.
What actually happens by design might be surprising. We're using the CDF here
only to report errors.
COPY processing happens in the file-reader (lexio) before the input stream is
directed to the lexer. If lexio parses the COPY directive successfully (and
reads the file), the COPY directive is erased from the input, and the file's
text is inserted, bracketed by line-directives to keep the parser informed
about the filenames. If lexio cannot parse the COPY directive or read the
file, it leaves the COPY directive intact, where it is parsed by the CDF
parser, which naturally reports syntax errors and missing-file problems.
Errors at the very top of the program are at the very top of the LALR parser.
Error recovery in Bison proceeds (usually) by discarding tokens that would fill
the current production, and moving "up a level". If that level is the very
top, it quits.
IMO that's just fine. If the problem is the very top of the program, nothing
is gained by parsing, say, 400,000 lines filled with errors due to a missing
copybook. Most programmers learn early to fix the first error first, and that
lesson is well applied here.
