[Bug target/120856] New: [avr] during RTL pass: split2: internal compiler error: Segmentation fault with -mno-lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120856
Bug ID: 120856
Summary: [avr] during RTL pass: split2: internal compiler
error: Segmentation fault with -mno-lra
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
unsigned long long _Fract
func (long f)
{
return __builtin_avr_ullrbits (f < 0 ? 0 : f);
}
This test case ICEs with -Os -mno-lra when split2 tries to split the following
insn:
(insn 10 40 29 4 (set (reg:DI 24 r24 [orig:49 _2 ] [49])
(zero_extend:DI (reg:SI 24 r24 [orig:48 _1 ] [48])))
"":4:46 827 {zero_extendsidi2}
because it splits to R24:SI = R22:SI and R28:SI = 0, but the latter is denied
since hard_regno_mode_ok denies R28:SI with -mno-lra but allowed R22:DI.
This ICE accurs when building libgcc, so might be annoying when comparing -mlra
against -mno-lra.
[Bug target/120856] [avr] during RTL pass: split2: internal compiler error: Segmentation fault with -mno-lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120856 --- Comment #1 from Georg-Johann Lay --- (In reply to Georg-Johann Lay from comment #0) > R22:DI. Should read R24:DI.
[Bug target/120840] [16 Regression] CPython miscompiled with preserve_none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120840 H.J. Lu changed: What|Removed |Added Attachment #61731|0 |1 is obsolete|| --- Comment #11 from H.J. Lu --- Created attachment 61745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61745&action=edit A patch
[Bug ada/120854] compilation of concatenation with illegal character constant hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120854 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug ada/120854] compilation of concatenation with illegal character constant hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120854 Eric Botcazou changed: What|Removed |Added Summary|gnat never exits|compilation of ||concatenation with illegal ||character constant hangs CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2025-06-28 Keywords||diagnostic Ever confirmed|0 |1 Target Milestone|--- |15.2 --- Comment #1 from Eric Botcazou --- Indeed, the error message should be: p.adb:4:30: error: expected type "Standard.Character" p.adb:4:30: error: found type universal integer
[Bug target/120856] [avr] during RTL pass: split2: internal compiler error: Segmentation fault with -mno-lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120856 --- Comment #2 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:13390e1b65f499ba33b7b5ff76bd9936e81b74e4 commit r16-1758-g13390e1b65f499ba33b7b5ff76bd9936e81b74e4 Author: Georg-Johann Lay Date: Sat Jun 28 16:22:50 2025 +0200 AVR: target/120856 - Deny R24:DI in avr_hard_regno_mode_ok with Reload. This fixes an ICE with -mno-lra when split2 tries to split the following zero_extendsidi2 insn: (set (reg:DI 24) (zero_extend:DI (reg:SI **))) The ICE is because avr_hard_regno_mode_ok allows R24:DI but disallows R28:SI when Reload is used. R28:SI is a result of zero_extendsidi2. This ICE only occurs with Reload (which will die before very long), but it occurs when building libgcc. gcc/ PR target/120856 * config/avr/avr.cc (avr_hard_regno_mode_ok) [-mno-lra]: Deny hard regs >= 4 bytes that overlap Y.
[Bug target/120856] [avr] during RTL pass: split2: internal compiler error: Segmentation fault with -mno-lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120856 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |16.0 Resolution|--- |FIXED --- Comment #3 from Georg-Johann Lay --- Fixed on trunk. I don't see it on v15, so no backport.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 120644, which changed state. Bug 120644 Summary: [modules] conflicting type for imported declaration with variable template and auto https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120644 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/120644] [modules] conflicting type for imported declaration with variable template and auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120644 Nathaniel Shead changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Nathaniel Shead --- Fixed on trunk.
[Bug c++/120644] [modules] conflicting type for imported declaration with variable template and auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120644 --- Comment #13 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:98fd493db6216cff11142c9dc477a3ff8e4269fa commit r16-1759-g98fd493db6216cff11142c9dc477a3ff8e4269fa Author: Nathaniel Shead Date: Mon Jun 23 22:24:22 2025 +1000 c++/modules: Ensure type of partial spec VAR_DECL is consistent with its template [PR120644] We were erroring because the TEMPLATE_DECL of the existing partial specialisation has an undeduced return type, but the imported declaration did not. The root cause is similar to what was fixed in r13-2744-g4fac53d6522189, where modules streaming code assumes that a TEMPLATE_DECL and its DECL_TEMPLATE_RESULT will always have the same TREE_TYPE. That commit fixed the issue by ensuring that when the type of a variable is deduced the TEMPLATE_DECL is updated as well, but missed handling partial specialisations. This patch ensures that the same adjustment is made there as well. PR c++/120644 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Also propagate type to partial templates. * module.cc (trees_out::decl_value): Add assertion that the TREE_TYPE of a streamed template decl matches its inner. (trees_in::is_matching_decl): Clarify function return type deduction should only occur for non-TEMPLATE_DECL. * pt.cc (template_for_substitution): Handle partial specs. gcc/testsuite/ChangeLog: * g++.dg/modules/auto-7.h: New test. * g++.dg/modules/auto-7_a.H: New test. * g++.dg/modules/auto-7_b.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill Reviewed-by: Patrick Palka
[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358 Sam James changed: What|Removed |Added Attachment #61748|0 |1 is obsolete|| --- Comment #11 from Sam James --- Created attachment 61749 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61749&action=edit small.cxx
[Bug c/120860] add ability to silence -Wmissing-field-initializers warnings on selected structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120860
--- Comment #2 from Bruno Haible ---
> Or do you want anything attribute on the fields which are optional.
Either way would be suitable to fix the problem:
* Either an attribute on the struct type, to avoid a
-Wmissing-field-initializers warning for any field of the struct.
* Or an attribute on the field(s) that should not elicit a
-Wmissing-field-initializers warning.
No special-casing of the last field should be done, because the problem occurs
also with the designated-initializer syntax:
{ .name = "foo", .val = 42 }
and therefore the solution should apply to both the
fields-in-their-listed-order syntax and to the designated-initializer syntax.
> It seems like some fields are optional, they are put in another struct
> and then use {} or {0}.
I would like to avoid using a different syntax than the natural one (that is
valid C99!), for example:
- initializing the remaining fields explicitly,
- use of {},
- use of a macro that expands to the remaining field initializers,
- use if a variadic macro that provides the remaining field initializers
when needed,
because these would be workarounds that make the code harder to grasp.
In other words, I want to use the simplest valid C99 syntax.
[Bug c/120860] New: add ability to silence -Wmissing-field-initializers warnings on selected structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120860
Bug ID: 120860
Summary: add ability to silence -Wmissing-field-initializers
warnings on selected structs
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno at clisp dot org
Target Milestone: ---
The -Wmissing-field-initializers warning is generally useful: it helps
detecting programmer mistakes.
However, some struct types are designed to have mandatory and optional fields.
It would be useful to be able to silence the warning for such struct types.
Currently I have to write code like this:
BEGIN_ALLOW_OMITTING_FIELD_INITIALIZERS
static struct program_option const options[] =
{
{ "width", 'w', required_argument },
{ NULL, 'x', no_argument },
{ "help",'h', no_argument, &show_help, 1 },
{ "version", 'V', no_argument, &show_version, 1 },
};
END_ALLOW_OMITTING_FIELD_INITIALIZERS
where the macros are defined like this:
#define BEGIN_ALLOW_OMITTING_FIELD_INITIALIZERS \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wmissing-field-initializers\"")
#define END_ALLOW_OMITTING_FIELD_INITIALIZERS \
_Pragma("GCC diagnostic pop")
I would prefer to be able to attach an attribute to the struct type definition,
and then get rid of the BEGIN_ALLOW_OMITTING_FIELD_INITIALIZERS and
END_ALLOW_OMITTING_FIELD_INITIALIZERS macros.
[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358
--- Comment #12 from Andrew Pinski ---
(In reply to Sam James from comment #11)
> Created attachment 61749 [details]
> small.cxx
I think there might be some aliasing issue with char16_t and Qchar.
```
QChar *begin() const { return reinterpret_cast(d.bp()); }
bn d;
bn::d :
ag *bp() const { return bv; }
ag *bv;
struct QChar {
QChar(char16_t) {}
char16_t bg;
};
```
I suspect this is true of the original code too.
[Bug ada/120665] assertion failure on problematic container aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120665 --- Comment #5 from GCC Commits --- The releases/gcc-15 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:80c55b15f8d6e6b1f10c193b60e19194a871070d commit r15-9872-g80c55b15f8d6e6b1f10c193b60e19194a871070d Author: Eric Botcazou Date: Tue Jun 17 18:55:39 2025 +0200 Ada: Fix assertion failure on problematic container aggregate This is an assertion failure on code using a container aggregate in the primitives referenced by the Aggregate aspect, which cannot work. gcc/ada/ PR ada/120665 * sem_aggr.adb (Resolve_Container_Aggregate): Use robust guards. gcc/testsuite/ * gnat.dg/specs/aggr8.ads: New test.
[Bug middle-end/120855] New: [16 Regression] Recent changes causing ICE in assemble_name_resolve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120855 Bug ID: 120855 Summary: [16 Regression] Recent changes causing ICE in assemble_name_resolve Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- This change: commit 0337e3c2743ca0c57da8c6b78b725a7d83f0b721 (HEAD) Author: Nathaniel Shead Date: Wed May 21 01:18:49 2025 +1000 c++/modules: Avoid name clashes when streaming internal labels [PR98375,PR118904] Is causing the mcore-elf port to regress a few tests. One example: Running /home/jlaw/test/gcc/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ... FAIL: gcc.dg/tree-ssa/pr107355.c (internal compiler error: in assemble_name_resolve, at varasm.cc:2910) FAIL: gcc.dg/tree-ssa/pr107355.c (test for excess errors) There's about 2 dozen tests in total failing with this signature. Thankfully I don't think you need a full cross toolchain, just cc1 and the testcase from the testsuite.
[Bug target/120818] [16 Regression] g++.target/i386/shrink_wrap_separate.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120818 --- Comment #5 from GCC Commits --- The master branch has been updated by Lili Cui : https://gcc.gnu.org/g:e7fb2459b00cde4fb14062076df29320efafdb98 commit r16-1757-ge7fb2459b00cde4fb14062076df29320efafdb98 Author: Lili Cui Date: Sat Jun 28 06:19:19 2025 -0700 Relax the testcase check for Solaris [PR120818] gcc/testsuite/ChangeLog: PR target/120818 * g++.target/i386/shrink_wrap_separate.C: Relax the check.
[Bug tree-optimization/120747] [16 Regression] 435.gromacs miscompares since r16-1550-g9244ea4bf55638
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120747 --- Comment #13 from Filip Kastl --- My theory is that the "miscompiled" functions are actually two: inl1100 and inl1120. If I compile these two functions with r16-1549 and the rest of innerf.f with r16-1550, I get the same gromacs output as when compiling the entire gromacs with r16-1549. My approach in greater detail: I patched r16-1550 so that I can turn off Andrew's changes using debug counters (thanks to the people that suggested this to me). diff --git a/gcc/dbgcnt.def b/gcc/dbgcnt.def index ac23a85567e..bd5477dbc5b 100644 --- a/gcc/dbgcnt.def +++ b/gcc/dbgcnt.def @@ -163,6 +163,7 @@ DEBUG_COUNTER (dse) DEBUG_COUNTER (dse1) DEBUG_COUNTER (dse2) DEBUG_COUNTER (ext_dce) +DEBUG_COUNTER (foo_counter) DEBUG_COUNTER (form_fma) DEBUG_COUNTER (gcse2_delete) DEBUG_COUNTER (gimple_unroll) diff --git a/gcc/value-range.cc b/gcc/value-range.cc index 5e97fdb7691..43d613d6697 100644 --- a/gcc/value-range.cc +++ b/gcc/value-range.cc @@ -31,6 +31,9 @@ along with GCC; see the file COPYING3. If not see #include "fold-const.h" #include "gimple-range.h" +#include "dbgcnt.h" +#include "print-tree.h" + // Return the bitmask inherent in a range : TYPE [MIN, MAX]. // This use to be get_bitmask_from_range (). @@ -2442,7 +2445,10 @@ irange::set_range_from_bitmask () // Make sure we call intersect, so do it first. changed = intersect (mask_range) | changed; // Npw make sure each subrange endpoint matches the bitmask. - changed |= snap_subranges (); + if (!dbg_cnt (foo_counter)) +changed |= snap_subranges (); + else +debug_tree(cfun->decl); return changed; } So if I do gfortran -std=legacy -c -o innerf.o -Ofast -g -march=native -mtune=native innerf.f -fdbg-cnt=foo_counter:662-679:716-733 between 662th and 679th trigger of the debug counter, the call to snap_subranges() is skipped and the same between 716th and 733th trigger. Thanks to debug_tree(cfun->decl) I know that these skips happen while compiling inl1100 and inl1120. When I link gromacs with innerf.o compiled in this way, the output (gromacs.out) is -3.23724e+05 3.09998e+02 1.06630e+10 which is the same as when I compile gromacs with r16-1549. Btw, compiling gromacs purely with r16-1550: -3.23364e+05 3.12012e+02 1.06604e+10 the reference values: -3.22397e+05 3.07684e+02 1.06621e+10 compiling gromacs with -fdbg-cnt=foo_counter:662-679: -3.22599e+05 3.07123e+02 1.06713e+10 compiling gromacs with -fdbg-cnt=foo_counter:716-733: -3.22302e+05 3.08683e+02 1.06655e+10 This is why I think that the "miscompilation" is both in inl1100 and inl1120.
[Bug c/120860] add ability to silence -Wmissing-field-initializers warnings on selected structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120860
--- Comment #3 from Andrew Pinski ---
What I am thinking about is do we want a full attribute which allows some
fields to be optional or the attribute for the whole struct. I think the
attribute for the whole struct is not wanted for the case listed here.
Having it for the whole struct means some required fields will be initialized
to 0/null like what Wmissing-field-initializers warning is trying to prevent.
Also does the attribute apply recursively or just for the fields of the struct.
That is:
```
struct a
{
int f1, f2;
};
struct b newattribute_disable_warning
{
struct a f1;
struct a f2;
};
struct b var = { {1} };
```
Attribute on the fields marking them as optional seems like a better option
[Bug c++/120863] New: ICE: in convert_like_internal, at cp/call.cc:9228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120863
Bug ID: 120863
Summary: ICE: in convert_like_internal, at cp/call.cc:9228
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rush102333 at gmail dot com
Target Milestone: ---
The following code starts to crash since gcc-10.2:
https://godbolt.org/z/8oxGfvd9f
struct X { };
struct Y : X { };
template
X &&f1(Y &y) {
T instance;
return y; }
Stack Dump:
: In function 'X&& f1(Y&)':
:6:9: internal compiler error: in convert_like_internal, at
cp/call.cc:9228
6 | return y; }
| ^
0x2843285 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2865e26 internal_error(char const*, ...)
???:0
0xaedd7c fancy_abort(char const*, int, char const*)
???:0
0xb25678 initialize_reference(tree_node*, tree_node*, int, int)
???:0
0xdf27e0 convert_for_initialization(tree_node*, tree_node*, tree_node*, int,
impl_conv_rhs, tree_node*, int, int)
???:0
0xdf408d check_return_expr(tree_node*, bool*, bool*)
???:0
0xd938d8 finish_return_stmt(tree_node*)
???:0
0xd16663 c_parse_file()
???:0
0xe7e3c9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/120864] New: ICE Segmentation fault with deduced return type and concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120864
Bug ID: 120864
Summary: ICE Segmentation fault with deduced return type and
concept
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rush102333 at gmail dot com
Target Milestone: ---
Starts to bailing out since gcc-12.1: https://godbolt.org/z/xf4xWPezv
Test Input:
~~
template < typename S > struct A
{
template
concept C = true;
template < C T > static auto f () { return 0; }
template
concept C = true;
template < class U = decltype (f < S > ()) > int g () { return 0; }
};
auto a = A < int > {}.g ();
~~
Stack Dump:
~~
:4:9: error: concept 'C' not in namespace scope [-Wtemplate-body]
4 | concept C = true;
| ^
:5:12: error: 'C' has not been declared [-Wtemplate-body]
5 | template < C T > static auto f () { return 0; }
|^
:7:9: error: concept 'C' not in namespace scope [-Wtemplate-body]
7 | concept C = true;
| ^
: In instantiation of 'struct A':
:11:21: required from here
11 | auto a = A < int > {}.g ();
| ^
:8:40: internal compiler error: Segmentation fault
8 | template < class U = decltype (f < S > ()) > int g () { return 0; }
|^~
0x2843285 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2865e26 internal_error(char const*, ...)
???:0
0xd4bccd tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd4c254 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0xd7a59c instantiate_class_template(tree_node*)
???:0
0xd96436 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0xd16663 c_parse_file()
???:0
0xe7e3c9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
~~
[Bug target/120840] [16 Regression] CPython miscompiled with preserve_none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120840 H.J. Lu changed: What|Removed |Added Attachment #61745|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment #12 from H.J. Lu --- Created attachment 61746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61746&action=edit A patch with a run-time test
[Bug target/120840] Functions with no_callee_saved_registers attribute should preserve frame pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120840
H.J. Lu changed:
What|Removed |Added
Summary|[16 Regression] CPython |Functions with
|miscompiled with|no_callee_saved_registers
|preserve_none |attribute should preserve
||frame pointer
--- Comment #13 from H.J. Lu ---
Functions with no_callee_saved_registers attribute should preserve frame
pointer:
[hjl@gnu-zen4-1 pr120840]$ cat pr120840-1a.c
/* { dg-do run } */
/* { dg-options "-save-temps -O2 -fno-omit-frame-pointer
-mtune-ctrl=prologue_using_move,epilogue_using_move,use_leave" } */
#ifndef DONT_SAVE_REGS1
# define DONT_SAVE_REGS1 __attribute__((no_callee_saved_registers))
#endif
#ifndef DONT_SAVE_REGS2
# define DONT_SAVE_REGS2 __attribute__((no_callee_saved_registers))
#endif
/* Keep labels and directives ('.cfi_startproc', '.cfi_endproc'). */
/* { dg-final { check-function-bodies "**" "" "" { target "*-*-linux*" }
{^\t?\.} } } */
/*
**do_test:
**.LFB[0-9]+:
**...
** leave
**...
** ret
**...
*/
#include
DONT_SAVE_REGS1
__attribute__ ((weak, __optimize__ ("-fomit-frame-pointer")))
void
continuation (int arg1, int arg2, int arg3, int arg4, int arg5, int arg6)
{
/* Clobber frame_pointer register. */
asm ("xor %%ebp, %%ebp" ::: "ebp");
if (arg1 != 17)
abort ();
if (arg2 != 8)
abort ();
if (arg3 != 20)
abort ();
if (arg4 != -3)
abort ();
if (arg5 != -4)
abort ();
if (arg6 != 26)
abort ();
}
DONT_SAVE_REGS2
__attribute__ ((weak, __optimize__ ("-fomit-frame-pointer")))
void
entry (int arg1, int arg2, int arg3, int arg4, int arg5, int arg6)
{
/* Clobber frame_pointer register. */
asm ("xor %%ebp, %%ebp" ::: "ebp");
if (arg1 != 17)
abort ();
if (arg2 != 8)
abort ();
if (arg3 != 20)
abort ();
if (arg4 != -3)
abort ();
if (arg5 != -4)
abort ();
if (arg6 != 26)
abort ();
continuation (arg1, arg2, arg3, arg4, arg5, arg6);
}
__attribute__ ((weak))
void
do_test (void)
{
entry (17, 8, 20, -3, -4, 26);
}
int
main (void)
{
do_test ();
return 0;
}
[hjl@gnu-zen4-1 pr120840]$ make x CC=/usr/gcc-14.2.1-x32/bin/gcc
/usr/gcc-14.2.1-x32/bin/gcc -O2 -fno-omit-frame-pointer
-mtune-ctrl=prologue_using_move,epilogue_using_move -o x pr120840-1a.c
[hjl@gnu-zen4-1 pr120840]$ ./x
Segmentation fault (core dumped)
[hjl@gnu-zen4-1 pr120840]$
[Bug target/120858] New: __builtin_rev_crc64_data64 poorly optimised when computing crc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120858 Bug ID: 120858 Summary: __builtin_rev_crc64_data64 poorly optimised when computing crc32 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sh1.gccbug at tikouka dot nz Target Milestone: --- There appears to be no __builtin_rev_crc32_data64(). Fine. I know how to fake that: return __builtin_rev_crc64_data64(crc32, x, 0x04C11DB7); That calculates the same result, but when the CRC instruction with a 64-bit operand is available it should be used. Instead we get table-based generation. https://godbolt.org/z/WWjn55TG1 Tested on armv8-a, but it appears to also happen on x86_64 (you'll need to include the recent fix for bug 120719 to test that).
[Bug middle-end/120855] [16 Regression] Recent changes causing ICE in assemble_name_resolve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120855 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |16.0 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2025-06-28 Ever confirmed|0 |1 Version|unknown |16.0 --- Comment #2 from Andrew Pinski --- .
[Bug target/120858] __builtin_rev_crc64_data64 poorly optimised when computing crc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120858 --- Comment #1 from Simon H. --- Slightly more 'valid' test, removing possible doubt about input endianness: https://godbolt.org/z/e63f7KGbj
[Bug middle-end/120858] __builtin_rev_crc64_data64 poorly optimised when computing crc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120858 --- Comment #2 from Sam James --- Please always include testcases as attachments as well (godbolt links are fine, but attach as well).
[Bug middle-end/120858] __builtin_rev_crc64_data64 poorly optimised when computing crc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120858 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug debug/120849] Missing debug (tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120849 --- Comment #1 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:5e5de088f99319aa755ef2af3def30a4ccd5765a commit r16-1762-g5e5de088f99319aa755ef2af3def30a4ccd5765a Author: H.J. Lu Date: Sat Jun 28 07:32:01 2025 +0800 Add "void debug (tree)" Add "void debug (tree)" to support: (gdb) call debug (expr) unit-size user align:256 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fffe99cebd0 fields XF x.c:2:15 size unit-size align:128 warn_if_not_align:0 offset_align 128 decl_not_flexarray: 1 offset bit-offset context chain >> used read BLK x.c:7:6 size unit-size align:256 warn_if_not_align:0 context arg-type > (gdb) PR debug/120849 * print-tree.cc (debug): New. * print-tree.h (debug): Likewise. Signed-off-by: H.J. Lu
[Bug testsuite/120859] New: FAIL: gcc.dg/tree-prof/afdo-crossmodule-1b.c compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120859 Bug ID: 120859 Summary: FAIL: gcc.dg/tree-prof/afdo-crossmodule-1b.c compilation Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz Target Milestone: --- commit 7b28a7dc9dfb277ef1f053dda84899837f8ed0c1 Author: Jan Hubicka Date: Thu Jun 26 10:48:20 2025 +0200 Add testcase for afdo offlining and fix two bugs caused: FAIL: gcc.dg/tree-prof/afdo-crossmodule-1b.c compilation, -fprofile-generate -D_PROFILE_GENERATE FAIL: gcc.dg/tree-prof/afdo-crossmodule-1b.c compilation, -fprofile-generate -D_PROFILE_GENERATE FAIL: gcc.dg/tree-prof/afdo-crossmodule-1b.c compilation, -g -DFOR_AUTOFDO_TESTING FAIL: gcc.dg/tree-prof/afdo-crossmodule-1b.c compilation, -g -DFOR_AUTOFDO_TESTING
[Bug testsuite/120859] FAIL: gcc.dg/tree-prof/afdo-crossmodule-1b.c compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120859 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-06-28 Status|UNCONFIRMED |NEW Keywords||testsuite-fail Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- .
[Bug debug/120849] Missing debug (tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120849 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |16.0 --- Comment #2 from H.J. Lu --- Fixed.
[Bug c/120861] New: ICE on x86_64-linux-gnu: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in remap_type_1, at tree-inline.cc:564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120861
Bug ID: 120861
Summary: ICE on x86_64-linux-gnu: tree check: expected tree
that contains 'decl minimal' structure, have
'error_mark' in remap_type_1, at tree-inline.cc:564
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangchangwu at smail dot nju.edu.cn
Target Milestone: ---
Compiler Explorer: https://gcc.godbolt.org/z/xM3nfPET7
***
gcc version:
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk --enable-coverage
--disable-werror --enable-checking=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250613 (experimental) (GCC)
***
Program:
$ cat mutant.c
int a, c;
void d() {
typedef struct {
char e[a];
} f;
f b;
#pragma omp parallel for
for (c = 0; c < 8; c++)
b;
}
***
Command Lines:
$ gcc -fopenmp mutant.c
during GIMPLE pass: omplower
mutant.c: In function 'd':
mutant.c:7:9: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'error_mark' in remap_type_1, at
tree-inline.cc:564
7 | #pragma omp parallel for
| ^~~
0x5554b38 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x2961e1f tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.cc:9276
0xec7c27 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3857
0x22af026 remap_type_1
../../gcc/gcc/tree-inline.cc:564
0x22b0aa0 remap_type(tree_node*, copy_body_data*)
../../gcc/gcc/tree-inline.cc:714
0x22ad5df remap_type_1
../../gcc/gcc/tree-inline.cc:458
0x22b0aa0 remap_type(tree_node*, copy_body_data*)
../../gcc/gcc/tree-inline.cc:714
0x22acc31 remap_type_1
../../gcc/gcc/tree-inline.cc:426
0x22b0aa0 remap_type(tree_node*, copy_body_data*)
../../gcc/gcc/tree-inline.cc:714
0x1d4d3db fixup_remapped_decl
../../gcc/gcc/omp-low.cc:909
0x1d55f8d scan_sharing_clauses
../../gcc/gcc/omp-low.cc:1847
0x1d5a798 scan_omp_parallel
../../gcc/gcc/omp-low.cc:2374
0x1d6854d scan_omp_1_stmt
../../gcc/gcc/omp-low.cc:4177
0x18f6101 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:618
0x18f32bc walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:51
0x18f6634 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:681
0x18f32bc walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:51
0x18f6367 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:645
0x18f32bc walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:51
0x1d692f5 scan_omp
../../gcc/gcc/omp-low.cc:4322
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358 --- Comment #15 from Andrew Pinski --- (In reply to Sam James from comment #13) > FWIW, it fails with -fno-strict-aliasing still (and the original). oh.
[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358 --- Comment #13 from Sam James --- FWIW, it fails with -fno-strict-aliasing still (and the original).
[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358 --- Comment #14 from Andrew Pinski --- https://doc.qt.io/qt-6/qchar.html yes what they mention is totally wrong. I am 99% sure QT code is not alias friendly at all and needs to be fixed and it looks hard to fix as they treat char16_t and QChar as compatible from an aliasing point of view but that is never true in C++. Doing stores via QChar and then loads via char16_t is fine but the opposite is undefined. And then in this case doing comparisons of pointers will cause issues.
[Bug c/120860] add ability to silence -Wmissing-field-initializers warnings on selected structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120860 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120358 --- Comment #10 from Sam James --- Created attachment 61748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61748&action=edit small.cxx Not sure if this testcase is valid but it aborts with >=15 with -O3 and works with -fno-tree-pta. It still needs to link against Qt though.
[Bug c/120860] add ability to silence -Wmissing-field-initializers warnings on selected structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120860
--- Comment #1 from Andrew Pinski ---
It seems like some fields are optional, they are put in another struct and then
use {} or {0}.
Or do you want anything attribute on the fields which are optional. But if that
won't allow if a set of fields are optional together. That field1 and field2
need to be initiated or neither.
In the case here what is the last field, is it only optional if the second to
last field exists or they both required together?
[Bug middle-end/120858] __builtin_rev_crc64_data64 poorly optimised when computing crc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120858 Jeffrey A. Law changed: What|Removed |Added Last reconfirmed||2025-06-29 Ever confirmed|0 |1 Status|UNCONFIRMED |SUSPENDED --- Comment #3 from Jeffrey A. Law --- The problem is internally within the compiler we need an extra bit, so 65 bits, which won't fit into a HOST_WIDE_INT. So the 64bit cases are generally punted. This is per design, though I do hope it gets fixed at some point.
[Bug c/120862] New: ICE on x86_64-linux-gnu: verify_gimple failed during IPA pass: remove_symbols at -O2/s with aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120862
Bug ID: 120862
Summary: ICE on x86_64-linux-gnu: verify_gimple failed during
IPA pass: remove_symbols at -O2/s with aligned
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangchangwu at smail dot nju.edu.cn
Target Milestone: ---
Compiler Explorer: https://gcc.godbolt.org/z/3fGG4K94r
***
gcc version:
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk --enable-coverage
--disable-werror --enable-checking=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250613 (experimental) (GCC)
***
Program:
$ cat mutant.c
int b;
void c() {
struct d {
int a[b];
} __attribute__((aligned)) e() {
struct d f;
return f;
}
struct d g() { return e(); }
g();
}
void main() {}
***
Command Lines:
$ gcc -O2 mutant.c
mutant.c: In function 'e':
mutant.c:12:1: error: invalid conversion in return statement
12 | void main() {}
| ^~~~
struct d
struct d
# VUSE <.MEM_14>
return ;
during IPA pass: remove_symbols
mutant.c:12:1: internal compiler error: verify_gimple failed
0x5554b38 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x2211fdc verify_gimple_in_cfg(function*, bool, bool)
../../gcc/gcc/tree-cfg.cc:5700
0x1e90b0f execute_function_todo
../../gcc/gcc/passes.cc:2103
0x1e8eb8c do_per_function
../../gcc/gcc/passes.cc:1710
0x1e90f6b execute_todo
../../gcc/gcc/passes.cc:2155
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug middle-end/120858] __builtin_rev_crc64_data64 poorly optimised when computing crc32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120858 Andrew Pinski changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #4 from Andrew Pinski --- So two things. For aarch64 and x86 (and riscv) (TARGET_SUPPORTS_WIDE_INT is true), const_wide_int should be able to use on the RTX side. Which is exactly what you want for > HOST_WIDE_INT. So this should not be suspended rather just confirmed. Considering Both the tree level supports wide_int (which is > HOST_WIDE_INT) and RTL also supports const_wide_int. It looks like this code was written originally based on much older GCC based on interfaces which most likely should be deprecated (though it is hard to change all of the previous code to use wide_int).
[Bug ada/120854] compilation of concatenation with illegal character constant hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120854 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Eric Botcazou --- Fixed on the mainline and 15 branch.
[Bug middle-end/120855] [16 Regression] Recent changes causing ICE in assemble_name_resolve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120855 --- Comment #1 from Nathaniel Shead --- Created attachment 61747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61747&action=edit possible fix Sorry for the breakage. The issue is this assertion in assemble_name_resolve: mark_referenced (id); ultimate_transparent_alias_target (&id); if (id != id_orig) name = IDENTIFIER_POINTER (id); gcc_assert (! TREE_CHAIN (id)); With my change, not just IDENTIFIER_TRANSPARENT_ALIAS identifiers can have TREE_CHAINs. It appears that perhaps only platforms with ASM_OUTPUT_WEAKREF undefined will run into this. Unfortunately I don't really have much capacity to look into this for the next few weeks, but I imagine something like the attached patch may work. (And adding some other assertions to validate that my assumption that a IDENTIFIER_INTERNAL_P will never be a transparent alias.) At some point I can try building a cross-compiler to verify, but otherwise please feel free to submit (a version of) this patch if it resolves the issue.
[Bug c/120837] [12/13/14/15/16 regression] False-positive from -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120837 --- Comment #14 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #12) > Dunno if the best thing is to just drop this altogether, or don't do it for > -fsanitize=undefined, or do it but on pointer sized ints instead of pointers. I say remove/drop it for GCC 16 but disable it with -fsanitize=undefined for GCC 15/14/13/12. I suspect we would run into some aliasing issues too (I can't seem to find it right but `&a-1` causes the aliasing info here to point to nothing and things go down here from there).
[Bug ada/120854] compilation of concatenation with illegal character constant hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120854 --- Comment #3 from GCC Commits --- The releases/gcc-15 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:06a26f4d643a5d045d893cd443425b13bd3d1b4b commit r15-9873-g06a26f4d643a5d045d893cd443425b13bd3d1b4b Author: Eric Botcazou Date: Sat Jun 28 17:42:26 2025 +0200 Fix compilation of concatenation with illegal character constant This fixes an error recovery issue, whereby the compilation of a string concatenation with an illegal character constant hangs. gcc/ada/ PR ada/120854 * sem_eval.adb (Get_String_Val): Be prepared for an integer literal after a serious error is detected, and raise PE on other nodes. gcc/testsuite/ * gnat.dg/concat6.adb: New test.
[Bug middle-end/116375] redundant copy not eliminated with CONSTRUCTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116375 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=42909 --- Comment #4 from Andrew Pinski --- In this case, with tail calls on aarch64, PR 42909 fixes this specific testcase but not one without a tail call.
[Bug c/120837] [12/13/14/15/16 regression] False-positive from -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120837
Jakub Jelinek changed:
What|Removed |Added
Component|middle-end |c
CC||jsm28 at gcc dot gnu.org
--- Comment #12 from Jakub Jelinek ---
So, c-typeck.cc (build_binary_op) is called on
x > y ? (void **)&b : (void **)&a
as orig_op0 and y - 1 as orig_op1, code PLUS_EXPR.
That calls pointer_int_sum with the same operands.
But then c-common.cc (pointer_int_sum)'s
/* If what we are about to multiply by the size of the elements
contains a constant term, apply distributive law
and multiply that constant term separately.
This helps produce common subexpressions. */
if ((TREE_CODE (intop) == PLUS_EXPR || TREE_CODE (intop) == MINUS_EXPR)
&& !TREE_CONSTANT (intop)
&& TREE_CONSTANT (TREE_OPERAND (intop, 1))
&& TREE_CONSTANT (size_exp)
/* If the constant comes from pointer subtraction,
skip this optimization--it would cause an error. */
&& TREE_CODE (TREE_TYPE (TREE_OPERAND (intop, 0))) == INTEGER_TYPE
/* If the constant is unsigned, and smaller than the pointer size,
then we must skip this optimization. This is because it could cause
an overflow error if the constant is negative but INTOP is not. */
&& (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (intop))
|| (TYPE_PRECISION (TREE_TYPE (intop))
== TYPE_PRECISION (TREE_TYPE (ptrop)
{
enum tree_code subcode = resultcode;
tree int_type = TREE_TYPE (intop);
if (TREE_CODE (intop) == MINUS_EXPR)
subcode = (subcode == PLUS_EXPR ? MINUS_EXPR : PLUS_EXPR);
/* Convert both subexpression types to the type of intop,
because weird cases involving pointer arithmetic
can result in a sum or difference with different type args. */
ptrop = build_binary_op (EXPR_LOCATION (TREE_OPERAND (intop, 1)),
subcode, ptrop,
convert (int_type, TREE_OPERAND (intop, 1)),
true);
intop = convert (int_type, TREE_OPERAND (intop, 0));
}
That looks just wrong generally, there is no attempt to prove that ptrop - 1 is
not invalid, this is sort of optimization I'd expect to be done in ivopts or so
and use uintptr_t arithmetics instead of pointer arithmetics.
This is 1992-ish code with some later extensions.
Dunno if the best thing is to just drop this altogether, or don't do it for
-fsanitize=undefined, or do it but on pointer sized ints instead of pointers.
[Bug c++/120857] New: The wording of the warning issued by Wreturn-type is overly confident for the current implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120857
Bug ID: 120857
Summary: The wording of the warning issued by Wreturn-type is
overly confident for the current implementation
Product: gcc
Version: 16.0
URL: https://godbolt.org/z/xn5Th8avT
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tiborgyri at gmail dot com
CC: tiborgyri at gmail dot com
Target Milestone: ---
As discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629, the current
implementation for issuing -Wreturn-type warnings is relatively simplistic and
has limitations due to how early it runs. This results in false positive
warnings being issued even in cases where it is trivial that control cannot
reach the end of the function, such as this:
int foo (bool a) {
if (a) return 0;
else if (!a) return 1;
}
Despite these current (as of GCC 16 trunk) (and longstanding) limitations, the
message emitted is extremely confident:
warning: control reaches end of non-void function [-Wreturn-type]
The wording unambiguously states that control reaches the end, without any
shred of uncertainty. I feel like given how easy it is to run into a false
positive, this is overly confident wording. The issue is made worse by the fact
that Wreturn-type is enabled by default for C++.
I propose that GCC should be more honest about the limitations of its
implementations, such as by changing this message to the following:
warning: cannot prove that control does not reach end of non-void function
[-Wreturn-type]
This message would be clear about the condition being detected and the limited
trust the user should put into the current implementation.
[Bug c++/120857] The wording of the warning issued by Wreturn-type is overly confident for the current implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120857 Andrew Pinski changed: What|Removed |Added URL|https://godbolt.org/z/xn5Th | |8avT| --- Comment #1 from Andrew Pinski --- https://godbolt.org/z/xn5Th8avT
[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629 Tibor Győri changed: What|Removed |Added CC||tiborgyri at gmail dot com --- Comment #11 from Tibor Győri --- Reconfirmed for GCC 16 trunk. https://godbolt.org/z/xn5Th8avT
[Bug c/120837] [12/13/14/15/16 regression] False-positive from -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120837 --- Comment #13 from Jakub Jelinek --- And/or detect cases where doing this optimization is valid on pointers, say &arr[0] + (x + 4) where (&arr[0] + 4) + x is valid because the arr is array and has 4+ elements, or &arr[1] + (x - 1) where (&arr[1] - 1) + x is valid too. But when for ptr + (x + cst) or ptr + (x - cst) ptr + cst or ptr - cst aren't valid pointer arithmetics, we can only do non-pointer arithmetics or punt.
[Bug c++/120857] The wording of the warning issued by Wreturn-type is overly confident for the current implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120857 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug ada/120854] compilation of concatenation with illegal character constant hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120854 --- Comment #2 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:0788add46a172b7b1c565fafdef80979be3dc2a6 commit r16-1761-g0788add46a172b7b1c565fafdef80979be3dc2a6 Author: Eric Botcazou Date: Sat Jun 28 17:42:26 2025 +0200 Fix compilation of concatenation with illegal character constant This fixes an error recovery issue, whereby the compilation of a string concatenation with an illegal character constant hangs. gcc/ada/ PR ada/120854 * sem_eval.adb (Get_String_Val): Be prepared for an integer literal after a serious error is detected, and raise PE on other nodes. gcc/testsuite/ * gnat.dg/concat6.adb: New test.
