[Bug libstdc++/120325] [Regression] GCC-15 cannot build LLVM 20.1.5 with CMAKE_CXX_STANDARD=20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120325 --- Comment #2 from Jonathan Wakely --- I'll comment on github too, but I think the problem is that you're using -DCMAKE_CXX_STANDARD=20 It looks to me like LLVM's iterator facade is completely incompatible with C++20. The operator overloads like operator- and operator+ should be constrained using requires BaseT::IsRandomAccess and operator-- should be constrained with requires BaseT::IsBirectional If the facade provides those operators, then obviously the iterator is going to look like it supports those operations when concepts like std::random_access_iterator are checked. So until LLVM is made C++20-compatible, don't try to build it as C++20.
[Bug tree-optimization/31313] consecutive strcmps are not merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31313
Kael Franco changed:
What|Removed |Added
CC||kaelfandrew at gmail dot com
--- Comment #3 from Kael Franco ---
(In reply to Tobias Schlüter from comment #0)
> I just ran into some code which did something like
>
> int strcmp(const char *, const char *);
>
> int f (const char *c)
> {
> return (strcmp (c, "aaa") == 0 || strcmp (c, "aab") == 0);
> }
>
> It would be possible to optimize this into something like (hopefully I get
> it right)
> int f (const char *c)
> {
> if (strncmp (c, "aa", 2))
> return 0;
> return ((c[2] == 'a' || c[2] == 'b') && !c[3]);
> }
>
> Instead, we scan through the whole string twice, as can be seen in the
> assembly.
>
> Likewise, more complicated combinations of comparisons could be reduced into
> an optimal matching sequence. Putting this into component rtl-optimization,
> because the strcmp calls survive all of the tree optimizers unchanged.
This would require implementing Burst trie or suffix tree:
https://stackoverflow.com/questions/10722410/fast-string-comparison-in-c
[Bug tree-optimization/120331] match causes an extra assignment sometimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120331 --- Comment #7 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683999.html There was no regressions with this version of the patch and the issue I found was solved too.
[Bug c++/120335] Defining a function return type allowed with -pedantic-errors with using statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120335
--- Comment #2 from Andrew Pinski ---
Testcase:
```
using T = struct {}();
```
[Bug target/120333] New: RISC-V: Wrong code with bitmanip extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120333
Bug ID: 120333
Summary: RISC-V: Wrong code with bitmanip extension
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kristerw at gcc dot gnu.org
Target Milestone: ---
Compiling with -O3 -march=rv64gcb causes the function foo below to be
miscompiled:
__attribute__ ((noipa)) _Bool
foo (unsigned char ch, unsigned long mask) {
return (mask << (0x3f - (ch & 0x3f))) >> 0x3f;
}
int main()
{
if (!foo (0x3f, 0x8000ul))
__builtin_abort ();
return 0;
}
The generated assembly fails to take the last shift into account:
foo:
li a5,63
andna0,a5,a0
bexta0,a1,a0
ret
[Bug c++/120335] Defining a function return type allowed with -pedantic-errors with using statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120335 Andrew Pinski changed: What|Removed |Added Summary|Defining a function return |Defining a function return |type allowed with |type allowed with |-pedantic-errors|-pedantic-errors with using ||statement Ever confirmed|0 |1 Last reconfirmed||2025-05-18 Known to fail||4.7.1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. Looks like GCC has incorrectly accepted this ever since the support for using type aliases back in GCC 4.7.0. GCC does reject defining a new type as the return type with typedef and when declaring a function. So it looks like an oversight here even.
[Bug lto/120334] New: lto plugin doesn't check for excess section size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120334
Bug ID: 120334
Summary: lto plugin doesn't check for excess section size
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Originally reported at https://sourceware.org/bugzilla/show_bug.cgi?id=32978
but I realised it's actually an issue on the GCC LTO plugin side.
---
We had a bug report of a confusing error from ld when building Clang:
```
out of memory allocating 6074313780942294634 bytes after a total of 1159128
bytes
```
The cause was a corrupt libLLVM.so:
```
Starting program: /usr/x86_64-pc-linux-gnu/bin/ld -plugin
/usr/libexec/gcc/x86_64-pc-linux-gnu/16/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccrYkTIx.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie
-z now /usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../lib64/Scrt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/16/crtbeginS.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/16
-L/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../.. -L/lib -L/usr/lib
BuildConfusableTable.cpp.o usr/lib/llvm/18/lib64/libLLVM.so.18.1 -v -lstdc++
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-pc-linux-gnu/16/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/16/../../../../lib64/crtn.o
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
GNU ld (Gentoo p1) 2.44.50.20250516
out of memory allocating 6074313780942294634 bytes after a total of 1159128
bytes
Breakpoint 2, __GI_exit (status=status@entry=1) at exit.c:147
147 {
(gdb) bt
#0 __GI_exit (status=status@entry=1) at exit.c:147
#1 0x777f245e in xexit (code=1) at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./libiberty/xexit.c:47
#2 xmalloc_failed (size=6074313780942294634) at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./libiberty/xmalloc.c:139
#3 0x777eee2d in xmalloc (size=size@entry=6074313780942294634) at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./libiberty/xmalloc.c:151
#4 0x777f578b in simple_object_elf_find_sections (sobj=0x55955c60,
pfn=0x777f5940 , data=0x7fffc910, err=0x7fffc904)
at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./libiberty/simple-object-elf.c:613
#5 0x777f44df in simple_object_find_sections (sobj=,
pfn=0x777f5940 , data=0x7fffc910, err=0x7fffc904)
at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./libiberty/simple-object.c:199
#6 claim_file_handler_v2 (file=0x7fffca10, can_be_claimed=0x7fffca0c,
known_used=1) at
/usr/src/debug/sys-devel/gcc-16.0./gcc-16.0./lto-plugin/lto-plugin.c:1262
#7 0x55682afd in plugin_call_claim_file (file=0x7fffca10,
claimed=0x7fffca0c, claim_file_handler_v2=,
known_used=true)
at /usr/src/debug/sys-devel/binutils-/binutils/ld/plugin.c:1185
#8 plugin_object_p (ibfd=0x558c5000, known_used=true) at
/usr/src/debug/sys-devel/binutils-/binutils/ld/plugin.c:1279
#9 0x77812d5a in bfd_check_format_matches (abfd=0x558c5000,
format=format@entry=bfd_object, matching=matching@entry=0x0)
at /usr/src/debug/sys-devel/binutils-/binutils/bfd/format.c:583
#10 0x778139a7 in bfd_check_format (abfd=,
format=format@entry=bfd_object) at
/usr/src/debug/sys-devel/binutils-/binutils/bfd/format.c:105
#11 0x55681ea7 in ldfile_try_open_bfd (attempt=0x7fffdb41
"usr/lib/llvm/18/lib64/libLLVM.so.18.1", entry=entry@entry=0x55875200)
at /usr/src/debug/sys-devel/binutils-/binutils/ld/ldfile.c:533
#12 0x556920a7 in ldfile_open_file (entry=entry@entry=0x55875200)
at /usr/src/debug/sys-devel/binutils-/binutils/ld/ldfile.c:619
#13 0x55691d4e in load_symbols (entry=0x55875200,
place=0x7fffce50) at
/usr/src/debug/sys-devel/binutils-/binutils/ld/ldlang.c:3095
#14 0x5568115c in open_input_bfds.constprop.0 (s=0x55875200,
os=0x558765d0, os@entry=0x0, mode=OPEN_BFD_NORMAL)
at /usr/src/debug/sys-devel/binutils-/binutils/ld/ldlang.c:3731
#15 0x5567b960 in lang_process () at
/usr/src/debug/sys-devel/binutils-/binutils/ld/ldlang.c:8322
#16 0x55689e30 in main (argc=42, argv=0x7fffd258) at
/usr/src/debug/sys-devel/binutils-/binutils/ld/ldmain.c:882
```
```
(gdb) frame 4
#4 0x777f578b in
[Bug target/119966] [16 regression] pru: Invalid register in RTL expression starting with r16-160-ge6f89d78c1a752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119966 --- Comment #9 from GCC Commits --- The master branch has been updated by Dimitar Dimitrov : https://gcc.gnu.org/g:eb2ea476db2182939f585df7d806225649ee4f62 commit r16-718-geb2ea476db2182939f585df7d806225649ee4f62 Author: Dimitar Dimitrov Date: Sat May 3 22:38:30 2025 +0300 emit-rtl: Allow extra checks for paradoxical subregs [PR119966] When a paradoxical subreg is detected, validate_subreg exits early, thus skipping the important checks later in the function. Fix by continuing with the checks instead of declaring early that the paradoxical subreg is valid. One of the newly allowed subsequent checks needed to be disabled for paradoxical subregs. It turned out that combine attempts to create a paradoxical subreg of mem even for strict-alignment targets. That is invalid and should eventually be rejected, but is temporarily left allowed to prevent regressions for armv8l-unknown-linux-gnueabihf. See PR120329 for more details. Tests I did: - No regressions were found for C and C++ for the following targets: - native x86_64-pc-linux-gnu - cross riscv64-unknown-linux-gnu - cross riscv32-none-elf - Sanity checked armv8l-unknown-linux-gnueabihf by cross-building up to including libgcc. Linaro CI bot further confirmed there are no regressions. - Sanity checked powerpc64-unknown-linux-gnu by building native toolchain, but I could not setup qemu-user for DejaGnu testing. PR target/119966 gcc/ChangeLog: * emit-rtl.cc (validate_subreg): Do not exit immediately for paradoxical subregs. Filter subsequent tests which are not valid for paradoxical subregs. Co-authored-by: Richard Sandiford Signed-off-by: Dimitar Dimitrov
[Bug rtl-optimization/120329] Combine temporarily creates paradoxical mem subregs for strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120329 --- Comment #6 from Dimitar Dimitrov --- To reproduce after r16-718-geb2ea476db2182, apply the following change to tighten paradoxical subreg checks, and build libgcc for armv8l-unknown-linux-gnueabihf: - /* Do not allow normal SUBREG with stricter alignment than the inner MEM. - - PR120329: Combine can create paradoxical mem subregs even for - strict-alignment targets. Allow it until combine is fixed. */ + /* Do not allow SUBREG with stricter alignment than the inner MEM. */ else if (reg && MEM_P (reg) && STRICT_ALIGNMENT - && MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (omode) - && known_le (osize, isize)) + && MEM_ALIGN (reg) < GET_MODE_ALIGNMENT (omode)) return false;
[Bug c++/107953] Greater-than operator misparsed inside a lambda expression used as a template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953
Ethan Hancock changed:
What|Removed |Added
CC||ethanhancock at me dot com
--- Comment #5 from Ethan Hancock ---
template
struct Foo {};
Foo<[](){ return 1 >= 0; }> foo1{};
Foo<[](){ return (1 > 0); }> foo2{};
Foo<[](){ return 1 > 0; }> foo3{};
I ran afoul of this bug, and found this issue.
Can confirm that this bug is still present in GCC 15.1.0.
GCC accepts foo1 and foo2, but rejects foo3.
Clang does accept all 3.
[Bug rtl-optimization/120284] inline assembly operand constraint not comply with document
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120284 --- Comment #7 from Huiba Li --- > In that case you need to use "movq %1, %0" in the asm to actually copy the > value, because the constraints don't guarantee it is the same register, it > can very well be a different one. > By using "0" or "+r" you require that the input and output use the same > register and so don't need to copy anything. Thanks for pointing it out. It give me a deeper understanding about the constraints. BTW, is it expected that gcc produces code like this: ``` ... <+64>: movq %r15, %rax <+67>: movq %rax, %r15 vpbroadcastd (%rax), %zmm17 ...``` Especially when gcc can use %rsi, instead of neither %r15 nor %rax.
[Bug gcov-profile/120321] Inconsistent line coverage for "for(;;)" "while(1)" etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120321
--- Comment #1 from Wentao Zhang ---
Another example that shows the effect can propagate from the "while(1)" line
to adjacent no-code, reduced from
https://sources.debian.org/src/lzo2/2.10-2/src/lzo1x_d.ch/#L98
where "NEED_IP" is expanded to "(void) 0".
int g;
int one = 1;
void foo() {
int x = 0;
while(1) { // using variable "one" as predicate changes the behavior
// g++; // uncommenting this line changes the behavior
(void) 0; // <= line coverage refers to C1 - C2
g++; // C1
x++;
if (x >= 7)
break; // C2
g++; // C1 - C2
}
}
int main(void) {
for (int i = 0; i < 11; i++)
foo();
}
[Bug middle-end/120276] [16 Regression] ICE in partial_subreg_p with SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120276
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jennifer Schmitz :
https://gcc.gnu.org/g:2ec5082dd24cef5149ba645ee88a9acd8b4c290a
commit r16-727-g2ec5082dd24cef5149ba645ee88a9acd8b4c290a
Author: Jennifer Schmitz
Date: Thu May 15 07:16:15 2025 -0700
regcprop: Return from copy_value for unordered modes
The ICE in PR120276 resulted from a comparison of VNx4QI and V8QI using
partial_subreg_p in the function copy_value during the RTL pass
regcprop, failing the assertion in
inline bool
partial_subreg_p (machine_mode outermode, machine_mode innermode)
{
/* Modes involved in a subreg must be ordered. In particular, we must
always know at compile time whether the subreg is paradoxical. */
poly_int64 outer_prec = GET_MODE_PRECISION (outermode);
poly_int64 inner_prec = GET_MODE_PRECISION (innermode);
gcc_checking_assert (ordered_p (outer_prec, inner_prec));
return maybe_lt (outer_prec, inner_prec);
}
Returning from the function if the modes are not ordered before reaching
the call to partial_subreg_p resolves the ICE and passes bootstrap and
testing without regression.
OK for mainline?
Signed-off-by: Jennifer Schmitz
gcc/
PR middle-end/120276
* regcprop.cc (copy_value): Return in case of unordered modes.
gcc/testsuite/
PR middle-end/120276
* gcc.dg/torture/pr120276.c: New test.
[Bug target/120344] New: code size increase with gcc 13 due to repeated loading of higher address in assembly for riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120344 Bug ID: 120344 Summary: code size increase with gcc 13 due to repeated loading of higher address in assembly for riscv Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fanghuaqi at vip dot qq.com Target Milestone: --- Created attachment 61465 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61465&action=edit dump.c Hi there, I am facing a code size increase issue when upgrade the compiler from riscv gcc 10 to gcc 13, sample code dump.c as attached, compiler option -march=rv32imafc -mabi=ilp32f -Os. here is compiler explorer link https://godbolt.org/z/j87KW5h6W For gcc 10: Generated asm like this lw a5,304(a2) sh a5,810(a0) lw a5,308(a2) sh a5,812(a0) lw a5,276(a2) sh a5,814(a0) lw a5,348(a3) sh a5,816(a0) lw a5,348(a4) sh a5,818(a0) lw a5,60(a3) sh a5,820(a0) lw a5,60(a4) sh a5,822(a0) lw a5,12(a1) sh a5,824(a0) But for gcc13, it will generate an extra li to load address, but this address can be stored in a register just like gcc 10. addia5,a5,304 lw a5,0(a5) sh a5,810(a0) li a5,-133693440 addia5,a5,308 lw a5,0(a5) sh a5,812(a0) li a5,-133693440 addia5,a5,276 lw a5,0(a5) sh a5,814(a0) li a5,-133955584 addia5,a5,348 lw a5,0(a5) sh a5,816(a0) li a5,-133939200 addia5,a5,348 lw a5,0(a5) sh a5,818(a0) li a5,-133955584 addia5,a5,60 lw a5,0(a5) sh a5,820(a0) li a5,-133939200 addia5,a5,60 lw a5,0(a5) sh a5,822(a0) li a5,-131850240 addia5,a5,12 lw a5,0(a5) sh a5,824(a0) And this issue still present in gcc trunk version.
[Bug target/119847] [13/14/15 Regression] RISC-V:GCC fail to optimize repeated patterns in volatile operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119847 Andrew Pinski changed: What|Removed |Added CC||fanghuaqi at vip dot qq.com --- Comment #2 from Andrew Pinski --- *** Bug 120344 has been marked as a duplicate of this bug. ***
[Bug cobol/119331] cobol: unimplemented exceptions abort compilation - even if requested to NOT use them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119331 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-05-18 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org
[Bug cobol/119771] FE (parser): CONSTANT AS LENGTH OF does not error - but result in length of zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119771 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2025-05-18 Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org --- Comment #1 from James K. Lowden --- fix pending in local parser branch, 319a6f04215e1235e496033bddcd298f11e5464c + ac5942efe2d7c6101afda604ac7bf57a48881839.
[Bug c++/120335] Defining a function return type allowed with -pedantic-errors with using statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120335
--- Comment #4 from Andrew Pinski ---
(In reply to eczbek.void from comment #3)
> This also has the same issue:
> ```
> auto(*x)()->struct{};
> ```
That one fails for me as a parse error even without -pedantic:
```
:1:19: error: expected identifier before '{' token
1 | auto(*x)()->struct{};
| ^
```
[Bug c++/120336] New: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_internal_context_p, at cp/tree.cc:3866 in trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120336
Bug ID: 120336
Summary: internal compiler error: tree check: expected tree
that contains 'decl minimal' structure, have
'error_mark' in decl_internal_context_p, at
cp/tree.cc:3866 in trunk
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
This bug seems related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120314,
not sure if unerlying the are the same, but a different stack dump is shown,
and this one only happens in trunk (at least without reducing).
```
#include
namespace mp = std;
template
struct mp::pair
{
};
```
```
/opt/compiler-explorer/gcc-trunk-20250518/include/c++/16.0.0/bits/stl_pair.h:338:7:
internal compiler error: tree check: expected tree that contains 'decl minimal'
structure, have 'error_mark' in decl_internal_context_p, at cp/tree.cc:3866
338 | swap(const pair& __p) const
| ^~~~
0x2944c55 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x29629c6 internal_error(char const*, ...)
???:0
0x9e1c05 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
???:0
0xd34ab4 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd5fecc instantiate_class_template(tree_node*)
???:0
0xdbaef4 complete_type_or_maybe_complain(tree_node*, tree_node*, int)
???:0
0xdbb01c require_complete_type(tree_node*, int)
???:0
0xaf4a5f build_cxx_call(tree_node*, int, tree_node**, int, tree_node*)
???:0
0xb1027e build_new_function_call(tree_node*, vec**, int)
???:0
0xd7dc6c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0xd2773d instantiate_decl(tree_node*, bool, bool)
???:0
0xd61d32 instantiate_pending_templates(int)
???:0
0xbe6361 c_parse_final_cleanups()
???:0
0xe618f8 c_common_parse_file()
???:0
```
To quickly reproduce:
https://godbolt.org/z/dddPM5TKv
[Bug fortran/120099] [16 regression] gfortran.dg/specifics_1.f90 FAILs since r16-372-g064cac730f88dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120099 --- Comment #21 from anlauf at gcc dot gnu.org --- Patch from comment#16 submitted: https://gcc.gnu.org/pipermail/fortran/2025-May/062180.html I hope I got the description of the issue right in the changelog.
[Bug ada/120106] replace hardcoded gnatmake commands with configuration variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120106 Nicolas Boulenguez changed: What|Removed |Added Attachment #61305|0 |1 is obsolete|| --- Comment #2 from Nicolas Boulenguez --- Created attachment 61462 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61462&action=edit GNATMAKE_FOR_BUILD only, v02 v02 passes GNATMAKE_FOR_BUILD via BASE_TARGET_EXPORT instead of EXTRA_TARGET_FLAGS. Is this less ugly?
[Bug c++/120338] New: internal compiler error: in expand_or_defer_fn_1, at cp/semantics.cc:5479 with main and delete since version 15.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120338
Bug ID: 120338
Summary: internal compiler error: in expand_or_defer_fn_1, at
cp/semantics.cc:5479 with main and delete since
version 15.1
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
ICE in:
```
#include
int main() = delete;
int main(){
return 0;
}
```
Stack dump:
```
:5:1: internal compiler error: in expand_or_defer_fn_1, at
cp/semantics.cc:5479
5 | }
| ^
0x2944c55 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x29629c6 internal_error(char const*, ...)
???:0
0xad8aaa fancy_abort(char const*, int, char const*)
???:0
0xd8027e expand_or_defer_fn(tree_node*)
???:0
0xcfcc93 c_parse_file()
???:0
0xe618c9 c_common_parse_file()
???:0
```
To quickly reproduce:
https://godbolt.org/z/9n69cYzx4
[Bug c++/120335] Defining a function return type allowed with -pedantic-errors with using statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120335
--- Comment #3 from eczbek.void at gmail dot com ---
This also has the same issue:
```
auto(*x)()->struct{};
```
[Bug c++/120337] New: internal compiler error: error reporting routines re-entered. tuple library since version 14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120337
Bug ID: 120337
Summary: internal compiler error: error reporting routines
re-entered. tuple library since version 14.1
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
ICE in:
```
#include
#include
#include
#include
#include
class A {
private:
int b {0};
std::mutex m;
public:
void inc() {
b++;
}
};
int main()
{
A a;
std::thread t1(std::bind(&A::inc,std::ref(a)), a);
t1.join();
}
```
Stack dump
```
/opt/compiler-explorer/gcc-trunk-20250518/include/c++/16.0.0/tuple:992:2:
required by the constraints of 'template template requires __disambiguating_constraint<_UTypes ...>() &&
__constructible<_UTypes ...>() && __dangles<_UTypes ...>() std::tuple<
>::tuple(_UTypes&& ...)'
Segmentation fault
990 | && (__constructible<_UTypes...>())
| ^~~
internal compiler error: error reporting routines re-entered.
0x2944b3e diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2944c55 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x29629c6 internal_error(char const*, ...)
???:0
0xad8aaa fancy_abort(char const*, int, char const*)
???:0
0x294406b diagnostic_context::finish()
???:0
0x29443b7 diagnostic_context::action_after_output(diagnostic_t)
???:0
0x2944a27 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x2944c55 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x29629c6 internal_error(char const*, ...)
???:0
0xe6b211 pp_c_specifier_qualifier_list(c_pretty_printer*, tree_node*)
???:0
0xe6b1f0 pp_c_specifier_qualifier_list(c_pretty_printer*, tree_node*)
???:0
0xe6b445 c_pretty_printer::type_id(tree_node*)
???:0
0xb95770 cxx_pretty_printer::type_id(tree_node*)
???:0
0xe6b211 pp_c_specifier_qualifier_list(c_pretty_printer*, tree_node*)
???:0
0xb9579a cxx_pretty_printer::type_id(tree_node*)
???:0
0xb958b2 cxx_pretty_printer::type_id(tree_node*)
???:0
0xb9779e pp_cxx_parameter_mapping(cxx_pretty_printer*, tree_node*)
???:0
0xbf588b expr_to_string(tree_node*)
???:0
0x2986373 pretty_printer::format(text_info&)
???:0
0x2944796 diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
```
To quickly reproduce:
https://godbolt.org/z/vzEWKfY1b
[Bug ada/120106] replace hardcoded gnatmake commands with configuration variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120106 --- Comment #3 from Nicolas Boulenguez --- Created attachment 61463 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61463&action=edit GNATMAKE for host only, v02 v02 uses the host compiler set by ./configure in gnattools/Makefile.in and gcc-interface/Make-lang.in. Ada/108909 and ada/108983 suggest user interest in GNATMAKE affecting all host compilations.
[Bug c++/120339] New: internal compiler error: Segmentation fault diagnostic_impl since version 14.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120339
Bug ID: 120339
Summary: internal compiler error: Segmentation fault
diagnostic_impl since version 14.1
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
ICE in:
```
#include
int main() {
std::ostream& out = std::cerr;
auto print = [](auto&... args) {
out << std::endl;
}
}
```
Stack dump
```
:5:25: internal compiler error: Segmentation fault
5 | out << std::endl;
| ^~~~
0x2944c55 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x29629c6 internal_error(char const*, ...)
???:0
0xb12f06 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node**, int)
???:0
0xdbd982 build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node*, tree_node**, int)
???:0
0xcfcc93 c_parse_file()
???:0
0xe618c9 c_common_parse_file()
???:0
```
To quickly reproduce:
https://godbolt.org/z/zKx14ne49
[Bug target/120333] [16 Regression] RISC-V: Wrong code with bitmanip extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120333 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-05-18 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114512 --- Comment #1 from Andrew Pinski --- Confirmed. Looks like it might be caused by r16-411-g4cd741dcbd3729 .
[Bug target/120333] [16 Regression] RISC-V: Wrong code with bitmanip extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120333 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |16.0 Summary|RISC-V: Wrong code with |[16 Regression] RISC-V: |bitmanip extension |Wrong code with bitmanip ||extension
[Bug c++/120335] Defining a function return type allowed with -pedantic-errors with using statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120335 --- Comment #6 from Andrew Pinski --- (In reply to eczbek.void from comment #5) > it seems to compile here: https://godbolt.org/z/dq51b7E3o Oh inside a function, outside is not an issue. But I suspect that is a different issue dealing with trailing return types and declarations inside a function. Let me file a seperate bug for that.
[Bug c++/120335] Defining a function return type allowed with -pedantic-errors with using statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120335 --- Comment #5 from eczbek.void at gmail dot com --- it seems to compile here: https://godbolt.org/z/dq51b7E3o
[Bug c++/120335] Defining a function return type allowed with -pedantic-errors with using statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120335 --- Comment #7 from eczbek.void at gmail dot com --- thanks!
[Bug c++/120340] New: Can define a struct type with a trailing return type on a function type as decl inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120340
Bug ID: 120340
Summary: Can define a struct type with a trailing return type
on a function type as decl inside a function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
```
void f() {
auto(*x)()->struct{};
}
```
Should be rejected as the trailing return type is a new type def.
Outside of a function we have a parse error for the new type for the trailing
return type.
Note if we try to use x, x says it is not declared in the scope.
So this might be just an invalid code which will never really show up unless
you are looking for it.
[Bug tree-optimization/120341] New: 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
Bug ID: 120341
Summary: wrong code at -O1 and above with
"-fallow-store-data-races" on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/PK19PqYjq
It appears to be a regression from 14.2, and affects 15.1 and later.
[561] % 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 20250518 (experimental) (GCC)
[562] %
[562] % gcctk -O1 small.c; ./a.out
[563] %
[563] % gcctk -O1 -fallow-store-data-races small.c
[564] % ./a.out
Segmentation fault
[565] %
[565] % cat small.c
char a, *b;
int main() {
b = "0";
if (a)
b[0]++;
return 0;
}
[Bug c++/120335] Defining a function return type allowed with -pedantic-errors with using statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120335 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > (In reply to eczbek.void from comment #5) > > it seems to compile here: https://godbolt.org/z/dq51b7E3o > > Oh inside a function, outside is not an issue. > > But I suspect that is a different issue dealing with trailing return types > and declarations inside a function. Let me file a seperate bug for that. PR 120340 and yes it does look like a totally seperate issue as the variable is not usable after invalid the trailing return type is used.
[Bug tree-optimization/120342] New: wrong code at -O{s,2,3} with "-fno-tree-ccp -fno-tree-forwprop" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120342
Bug ID: 120342
Summary: wrong code at -O{s,2,3} with "-fno-tree-ccp
-fno-tree-forwprop" on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/6Yfse1PMx
It appears to be quite long-latent and affects all versions.
[570] % 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 20250518 (experimental) (GCC)
[571] %
[571] % gcctk -O3 small.c
[572] %
[572] % gcctk -O3 -fno-tree-ccp -fno-tree-forwprop small.c
[573] % ./a.out
Aborted
[574] %
[574] % cat small.c
int main() {
int p = 0;
struct {
char q;
} *r = (void *)&p;
r->q = 1;
if (p != 1)
__builtin_abort();
return 0;
}
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #42 from Nicolas Boulenguez --- Created attachment 61464 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61464&action=edit v17 GNAT.Sockets.Thin_Common wrappers As suggested in https://inbox.sourceware.org/gcc-patches/aBZh8egJTzj_BHFS@pegase/ this version restores the visible types in GNAT.Sockets.Thin_Common, as renamings of System.C_Time types, instead of removing them. User code importing any module under Ada or GNAT should now build unchanged, although with new warnings (Obsolescent, identifier case). If necessary, similar wrappers could also be added under System, except in System.Parameters because this would create a circular dependency. This version tries to mimic better the formatting of existing commit headers. The tarball contains a diff with v16.
[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 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|wrong code at -O1 and above |[15/16 Regregression] wrong |with|code at -O1 and above with |"-fallow-store-data-races" |"-fallow-store-data-races" |on x86_64-linux-gnu |on x86_64-linux-gnu Target Milestone|--- |15.2 Last reconfirmed||2025-05-18 Ever confirmed|0 |1 Keywords||wrong-code --- Comment #1 from Andrew Pinski --- Confirmed, this was NOT fixed by r16-472 but is very much related to PR 120043.
[Bug tree-optimization/120342] wrong code at -O{s,2,3} with "-fno-tree-ccp -fno-tree-forwprop" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120342 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This is an aliasing violation. You write to p via int and then again via the struct and then read it back via int.
[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 #2 from Andrew Pinski --- ``` DECL_P (base) && TREE_READONLY (base) ``` Maybe that should be: (TREE_CODE (base) == STRING_CST || (DECL_P (base) TREE_READONLY (base))) Or some helper function which does the same.
[Bug tree-optimization/120342] wrong code at -O{s,2,3} with "-fno-tree-ccp -fno-tree-forwprop" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120342 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > This is an aliasing violation. > > You write to p via int and then again via the struct and then read it back > via int. I should say write partially via the struct. It does not matter that the field of the struct is char or not, you are still writing via the struct type.
[Bug c++/120343] New: inconvenient order of error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120343
Bug ID: 120343
Summary: inconvenient order of error messages
Product: gcc
Version: 12.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
struct a
{
int f () { return a + b + c; }
int g () { return { ]; }
int a, b, c;
};
% g++ -Wall -Werror -Wextra-semi test.cpp
test.cpp:6:2: error: extra ';' after in-class function definition
[-Werror=extra-semi]
6 | };
| ^
| -
test.cpp:6:3: error: expected '}' at end of input
6 | };
| ^
test.cpp:2:1: note: to match this '{'
2 | {
| ^
test.cpp: In member function 'int a::f()':
test.cpp:3:23: error: expected primary-expression before '+' token
3 | int f () { return a + b + c; }
| ^
test.cpp:3:25: error: 'b' was not declared in this scope
3 | int f () { return a + b + c; }
| ^
test.cpp:3:29: error: 'c' was not declared in this scope
3 | int f () { return a + b + c; }
| ^
test.cpp: In member function 'int a::g()':
test.cpp:4:23: error: expected primary-expression before ']' token
4 | int g () { return { ]; }
| ^
test.cpp:4:23: error: expected '}' before ']' token
test.cpp:4:21: note: to match this '{'
4 | int g () { return { ]; }
| ^
test.cpp:4:23: error: cannot convert '' to
'int' in return
4 | int g () { return { ]; }
| ^
test.cpp:4:23: error: expected ';' before ']' token
test.cpp:4:23: error: expected primary-expression before ']' token
test.cpp: At global scope:
test.cpp:6:3: error: expected unqualified-id at end of input
6 | };
| ^
cc1plus: all warnings being treated as errors
The error in the program is a simple typo (']' instead of '}'), but gcc only
tells me this after a lot of other errors resulting from the incorrect parse of
the following text -- here exemplified by the a, b, c stuff; in my actual code
this was pages of error messages which made it hard to find the actually
relevant ones (expected ... before ']').
[Bug c++/120343] inconvenient order of error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120343 --- Comment #1 from Andrew Pinski --- Hmm, clang even has a similar issue in their diagnostic.
[Bug c++/120343] inconvenient order of error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120343
--- Comment #2 from Andrew Pinski ---
Only MSVC (which is usually bad when it comes to diagnostic issues) actually
does a decent job at providing the good diagnostic here:
(4): error C2187: syntax error: ']' was unexpected here
(2): fatal error C1075: '{': no matching token found
Both clang and EDG provide a very similar in fashion issue as GCC.
[Bug c++/120335] New: Defining a function return type allowed with -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120335 Bug ID: 120335 Summary: Defining a function return type allowed with -pedantic-errors Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eczbek.void at gmail dot com Target Milestone: --- https://godbolt.org/z/5P9nre1rT https://eel.is/c++draft/diff.iso#diff.dcl-7 https://eel.is/c++draft/dcl.fct#16 Clang is correct here
