[Bug libgomp/120194] USM offloading vs. 'libgomp.c++/declare_target-1.C'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120194 --- Comment #3 from Tobias Burnus --- > ... this is ill-formed OpenMP? For 'requires unified_shared_memory', you are in the realm of un(der)specified behavior as OpenMP does not even mention how this case is handled. If you do (A) - or (B.1) + (B.2) - you are on the safe side. [I think; having 'map' clauses while the library otherwise assumes shared memory might have some corner-case issues.] (A) also works without USM (ignoring pointer members) while (B) means that host and device data are always in sync. * * * Note that for 'self_maps' the following applies: "all corresponding list items created by the 'enter' clauses specified by 'declare target' directives in the compilation unit share storage with the original list items." [I note that this doesn't talk about the 'link' clause, though.] While GCC supports 'self_maps' since GCC 15, this feature subfeature is not yet implemented and on my to-do list for GCC 16. The idea is to implement it as (B.1) [i.e. turn 'enter' to 'link'] plus (B.2) - but simply setting all 'link' pointers by the host pointer. For 'unified_shared_memory' (B.2) is probably useful as well, but regarding 'enter' → 'link' I am not sure.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #13 from Christoph Reiter --- We found another crash in gegl. I'll try to reduce later.
[Bug rtl-optimization/92080] Missed CSE of _mm512_set1_epi8(c) with _mm256_set1_epi8(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080 H.J. Lu changed: What|Removed |Added Target Milestone|--- |16.0
[Bug rtl-optimization/92080] Missed CSE of _mm512_set1_epi8(c) with _mm256_set1_epi8(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080 H.J. Lu changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment #13 from H.J. Lu --- Created attachment 61392 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61392&action=edit A patch I am testing this.
[Bug target/120209] New: [SH] Float constant 1.0 is loaded from constant pool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120209
Bug ID: 120209
Summary: [SH] Float constant 1.0 is loaded from constant pool
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: paul at crapouillou dot net
Target Milestone: ---
With the following code compiled at -Os:
float sh4_floorf(float x) {
float x2 = (float)(int)x;
if (x < -1.0f)
x2 += -1.0f;
return x2;
}
GCC generates:
_sh4_floorf:
mova.L6,r0
fmov.s @r0+,fr1
ftrcfr5,fpul
fcmp/gt fr5,fr1
bf/s.L5
float fpul,fr0
fldi1 fr1
fsubfr1,fr0
.L5:
rts
nop
.L6:
.long -1082130432
Notice how the 1.0f constant is loaded from .L6 using mova + fmov.s, while it
could be loaded using fldi1 directly.
The compiler also does not seem to understand that fr1 contains -1.0f which it
can add to fr0 directly, and instead it will load 1.0f with fldi1 this time and
substract it to fr0.
[Bug tree-optimization/111479] [12/13 regression] aarch64 SVE ICE: in compute_live_loop_exits, at tree-ssa-loop-manip.cc:248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111479 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #3 from mcccs at gmx dot com --- Solved in 12.4 and 13.3. Now it remains to determine if the issue is fixed or latent. Bisecting on the gcc-12 branch: bad ommit r12-9384-ge11513c7688f58 good commit: r12-10186-g9d033155254ac6 it seems fixed to me
[Bug tree-optimization/111479] [12/13 regression] aarch64 SVE ICE: in compute_live_loop_exits, at tree-ssa-loop-manip.cc:248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111479 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Turns out to be a dup. *** This bug has been marked as a duplicate of bug 111478 ***
[Bug tree-optimization/111478] [12 Regression] aarch64 SVE ICE: in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111478 --- Comment #12 from Andrew Pinski --- *** Bug 111479 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/120208] -Wmaybe-uninitialized with -O2 obviously wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120208 --- Comment #2 from Andrew Pinski --- (In reply to Stas Sergeev from comment #1) > While I am at it, I wonder > how to ask gcc to ignore the > #lineno directives in a > preprocessed input. I've found > -P to not generate them, but > if they are added, then locating > the problematic spot in a > preprocessed source seems > challenging. > > So how to ignore the #lineno's? I found using grep allows me to delete the linemarkers: ``` grep -v '^# ' ```
[Bug tree-optimization/120208] -Wmaybe-uninitialized with -O2 obviously wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120208 --- Comment #3 from Andrew Pinski --- It is not exactly scan is the issue but what is assigned to scan. Both start and newstart are initialized conditionally. And it seems like it is hard to figure out if the conditions at which they are set are the same conditions we reach when assigning scan from start. Even myself has a hard time figuring it out if there is any path which either newstart or start is used uninitialized because it seems like it depends on the context of g->strip and more.
[Bug tree-optimization/120208] -Wmaybe-uninitialized with -O2 obviously wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120208 Kael Franco changed: What|Removed |Added CC||kaelfandrew at gmail dot com --- Comment #4 from Kael Franco --- Created attachment 61394 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61394&action=edit Reduce C Code
[Bug debug/120207] print_rtl_single_with_indent is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120207 H.J. Lu changed: What|Removed |Added Ever confirmed|1 |0 Component|middle-end |debug Status|ASSIGNED|UNCONFIRMED --- Comment #4 from H.J. Lu --- (In reply to Andrew Pinski from comment #3) > Created attachment 61395 [details] > Patch which I am testing -/* Like print_rtx, except specify a file. */ +/* Like print_rtx, except only print the first of the chain ^^ Shouldn't it be print_rtl? + rather than all of the chain. */
[Bug debug/120207] print_rtl_single_with_indent is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120207 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/120212] New: : Optional empty repetitions should not match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120212
Bug ID: 120212
Summary: : Optional empty repetitions should not match
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
int main() {
try {
std::string s{"b"};
std::regex r{"(a*)*"};
std::smatch m;
bool result = std::regex_search(s, m, r);
printf("regex_search: %d\n", result);
for (unsigned i = 0; i < m.size(); ++i) {
printf("m[%d]", i);
if (m[i].matched) {
printf(".str(): \"%s\"\n", m[i].str().c_str());
} else {
puts(".matched: false");
}
}
} catch (const std::exception& e) {
printf("Exception: %s\n", e.what());
}
}
Expected: "" and false, per
https://262.ecma-international.org/5.1/#sec-15.10.2.5 note 4.
Actual: "" and "".
https://godbolt.org/z/s7ejf7GKv
Also present in libc++ and ms-stl
https://github.com/llvm/llvm-project/issues/133314
https://github.com/microsoft/STL/issues/5490
[Bug c++/120197] ICE in GCC with decltype(cout << a) in default function parameter leads to recursive diagnostics with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120197
mcccs at gmx dot com changed:
What|Removed |Added
CC||mcccs at gmx dot com
--- Comment #1 from mcccs at gmx dot com ---
Minimized testcase:
struct basic_ostream {int operator<<(auto x);
}; template bool __derived_from_ios_base;
template
requires __derived_from_ios_base<_Os>
using __rvalue_stream_insertion_t = _Os;
template < typename _Ostream, typename _Tp > __rvalue_stream_insertion_t<
_Ostream, _Tp > operator<<(_Ostream ,
_Tp );
basic_ostream cout;
template < class T > void myFunc(T a, decltype(cout << a) = cout){ }
int main0 {
myFunc(5)
}
[Bug target/117184] m2 fails with "terminate called after throwing an instance of 'unsigned int'" with LRA on alpha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117184 --- Comment #1 from John Paul Adrian Glaubitz --- This bug still exists on gcc-16.
[Bug c/120208] New: -Wmaybe-uninitialized with -O2 obviously wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120208
Bug ID: 120208
Summary: -Wmaybe-uninitialized with -O2 obviously wrong
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stsp at users dot sourceforge.net
Target Milestone: ---
Created attachment 61391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61391&action=edit
test case
Attached is a preprocessed source.
gcc -O2 -Wall -xc regcomp.E -c -fpreprocessed -o regcomp.o
In function ‘findmust’,
inlined from ‘regcomp’ at regcomp.E:1261:2:
regcomp.E:2178:21: warning: ‘scan’ may be used uninitialized
[-Wmaybe-uninitialized]
2178 | while (((s = *scan++)&0x7c00) != (2<<(26)) )
| ^~
regcomp.E: In function ‘regcomp’:
regcomp.E:2124:7: note: ‘scan’ was declared here
2124 | sop *scan;
Now if we look into the source,
then we see this:
scan = start;
for (i = g->mlen; i > 0; i--) {
while (((s = *scan++)&0x7c00) != (2<<(26)) )
So it was initialized just 2 lines above.
[Bug c/120208] -Wmaybe-uninitialized with -O2 obviously wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120208 --- Comment #1 from Stas Sergeev --- While I am at it, I wonder how to ask gcc to ignore the #lineno directives in a preprocessed input. I've found -P to not generate them, but if they are added, then locating the problematic spot in a preprocessed source seems challenging. So how to ignore the #lineno's?
[Bug fortran/120163] [15/16 Regression] Can not import module containig call to pure routine via abstract interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120163 Thomas Koenig changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/120080] [16 regression] ICE when building llvm-20.1.3 (find_bit_tests, at tree-switch-conversion.cc:1799) since r16-347-g1381a5114788a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120080 --- Comment #13 from GCC Commits --- The master branch has been updated by Filip Kastl : https://gcc.gnu.org/g:358a5aedf2b5b61f4edfc7964144355a4897dbb9 commit r16-513-g358a5aedf2b5b61f4edfc7964144355a4897dbb9 Author: Filip Kastl Date: Sat May 10 16:18:33 2025 +0200 gimple: Don't assert that switch has nondefault cases during lowering [PR120080] I have mistakenly assumed that switch lowering cannot encounter a switch with zero clusters. This patch removes the relevant assert and instead gives up bit-test lowering when this happens. PR tree-optimization/120080 gcc/ChangeLog: * tree-switch-conversion.cc (bit_test_cluster::find_bit_tests): Replace assert with return. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr120080.c: New test. Signed-off-by: Filip Kastl
[Bug tree-optimization/120080] [16 regression] ICE when building llvm-20.1.3 (find_bit_tests, at tree-switch-conversion.cc:1799) since r16-347-g1381a5114788a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120080 Filip Kastl changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Filip Kastl --- Thanks, Andrew, for the explanation and for the testcase! This should be fixed now.
[Bug debug/120207] New: [12/13/14/15/16 Regression] print_rtl_single_with_indent is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120207 Bug ID: 120207 Summary: [12/13/14/15/16 Regression] print_rtl_single_with_indent is undefined Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- rtl.h has extern void print_rtl_single_with_indent (FILE *, const_rtx, int); But it isn't defined. It looks like an oversight when switching GCC source to C++.
[Bug libgomp/120194] USM offloading vs. 'libgomp.c++/declare_target-1.C'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120194 --- Comment #4 from Tobias Burnus --- Hmm, actually, it looks as if I have already implemented (B.2) in GCC 15+ in libgomp/target.c's gomp_load_image_to_device: if (is_link_var && (omp_requires_mask & (GOMP_REQUIRES_UNIFIED_SHARED_MEMORY | GOMP_REQUIRES_SELF_MAPS))) gomp_copy_host2dev (devicep, NULL, (void *) target_var->start, &k->host_start, sizeof (void *), false, NULL); while my (b.2) diff change (comment 1) actually misses an 'omp' between '#pragma' and 'target' ... In any case, at least for self_maps, the automatic 'enter'->'link' change still needs to be implemented.
[Bug preprocessor/119753] gcc -E is not POSIX-compliant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753 --- Comment #11 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #8) > IMNSHO it is POSIX that should be fixed. Clearly they've added a > requirement there that doesn't match what the compilers actually do (GCC, > clang, ICC (both before and after LLVM), nvc++ all do the same). EDG/MSVC > on godbolt seems to use #line directives instead of # > . Yes, I might ask the POSIX committee why they standardized something that isn't existing practice.
[Bug target/120209] [SH] Float constant 1.0 is loaded from constant pool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120209 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug cobol/119335] cobol frontend ignores -M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119335 James K. Lowden changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org Status|WAITING |ASSIGNED --- Comment #1 from James K. Lowden --- Is this acceptable? $ gcobol -I CLBRY-SM101A -M SM101A.cbl SM101A.cbl: \ CLBRY-SM101A/K101A \ CLBRY-SM101A/K1FDA \ CLBRY-SM101A/K1P01 \ CLBRY-SM101A/K1PRA \ CLBRY-SM101A/K1SEA \ CLBRY-SM101A/K1W01 \ CLBRY-SM101A/K1W02 \ CLBRY-SM101A/K1W03 \ CLBRY-SM101A/K1W04 \ CLBRY-SM101A/K1WKA
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 Iouri Kharon changed: What|Removed |Added Attachment #61379|0 |1 is obsolete|| --- Comment #14 from Iouri Kharon --- Created attachment 61393 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61393&action=edit A complex patch fixed for this (and several similar) problems. Workaround for a bug that prevented some binutils and gcc components from being built with -gcodeview. Marked as TODO, since "optimized information" about local variables like CONST_STRING is now discarded, since to save it you either have to write your own helper (duplicating the one in final.cc) or make it public.
[Bug c++/120197] ICE in GCC with decltype(cout << a) in default function parameter leads to recursive diagnostics with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120197 --- Comment #2 from mcccs at gmx dot com --- Bisection: r10-7361-gfddfd3ce555965
[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #26 from anlauf at gcc dot gnu.org --- Have you tried to move some of the checks *after* the resolution stage? The checks in check.cc are invoked rather early. Maybe look into trans-intrinsic.cc (conv_isocbinding_function)?
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #45 from GCC Commits --- The master branch has been updated by Jonathan Yong : https://gcc.gnu.org/g:ee7c0a5b70dc316477f45abc0f09dd2af9abe5cb commit r16-511-gee7c0a5b70dc316477f45abc0f09dd2af9abe5cb Author: LIU Hao Date: Tue Apr 29 10:43:06 2025 +0800 i386/cygming: Decrease default preferred stack boundary for 32-bit targets This commit decreases the default preferred stack boundary to 4. In i386-options.cc, there's ix86_default_incoming_stack_boundary = PREFERRED_STACK_BOUNDARY; which sets the default incoming stack boundary to this value, if it's not overridden by other options or attributes. Previously, GCC preferred 16-byte alignment like other platforms, unless `-miamcu` was specified. However, the Microsoft x86 ABI only requires the stack be aligned to 4-byte boundaries. Callback functions from MSVC code may break this assumption by GCC (see reference below), causing local variables to be misaligned. For compatibility reasons, when the attribute `force_align_arg_pointer` is attached to a function, it continues to ensure the stack is at least aligned to a 16-byte boundary, as the documentation seems to suggest. After this change, `STACK_REALIGN_DEFAULT` no longer has an effect on this target, so it is removed. Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07#c9 Signed-off-by: LIU Hao Signed-off-by: Jonathan Yong <10wa...@gmail.com> gcc/ChangeLog: PR target/07 * config/i386/cygming.h (PREFERRED_STACK_BOUNDARY_DEFAULT): Override definition from i386.h. (STACK_REALIGN_DEFAULT): Undefine, as it no longer has an effect. * config/i386/i386.cc (ix86_update_stack_boundary): Force minimum 128-bit alignment if `force_align_arg_pointer`.
[Bug fortran/120163] [15/16 Regression] Can not import module containig call to pure routine via abstract interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120163 --- Comment #2 from Thomas Koenig --- Patch at https://gcc.gnu.org/pipermail/fortran/2025-May/062123.html
[Bug middle-end/120207] print_rtl_single_with_indent is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120207 --- Comment #2 from Andrew Pinski --- It was never used except for print_rtl_single . Added with https://inbox.sourceware.org/gcc-patches/CABu31nMr3UPWBjGMCKqZ-EhgJoEZZFXx9h=9lry2o5su1ek...@mail.gmail.com/ It was going to be used in https://inbox.sourceware.org/gcc-patches/433c36f2.5040...@naturalbridge.com/ (which is an earlier patch).
[Bug middle-end/120207] print_rtl_single_with_indent is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120207 Andrew Pinski changed: What|Removed |Added Summary|[12/13/14/15/16 Regression] |print_rtl_single_with_inden |print_rtl_single_with_inden |t is undefined |t is undefined | --- Comment #1 from Andrew Pinski --- extern void print_mem_expr (FILE *, const_tree); extern void print_rtl (FILE *, const_rtx); extern void print_simple_rtl (FILE *, const_rtx); extern void print_rtl_single (FILE *, const_rtx); extern void print_rtl_single_with_indent (FILE *, const_rtx, int); extern void print_inline_rtx (FILE *, const_rtx, int);
[Bug cobol/119335] cobol frontend ignores -M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119335 --- Comment #2 from Simon Sobisch --- That's totally fine if those are _really_ the files read-in as copybooks (if they were opened with an extension, then of course this should be in).
[Bug middle-end/120207] print_rtl_single_with_indent is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120207 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2025-05-10 Status|UNCONFIRMED |ASSIGNED
[Bug middle-end/120207] print_rtl_single_with_indent is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120207 --- Comment #3 from Andrew Pinski --- Created attachment 61395 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61395&action=edit Patch which I am testing
[Bug middle-end/109996] csmith: -O2 -fno-strict-aliasing causing run time trouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109996 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #5 from mcccs at gmx dot com --- Created attachment 61396 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61396&action=edit adapted for trunk and older GCCs and Clang, removed warnings Here's the a little bit hand-simplified version (I mostly removed redundant attributes and header lines) that works in earlier GCCs, LLVM, latest trunk. LLVM's sanitizers don't find a problem. It fails with O2 or O3 since 7.1. I can't bisect because I only have aarch64 vm on mac and they haven't responded to my cfarm account request yet, so someone else has to do the bisection since the trunk of earlier than 2018 can't be built on aarch64. If you open a text editor and replace the single occurence of __attribute__((used)) with nothing, which is the single use of the attribute "used" in my cleaned up version, the segmentation fault is gone.
[Bug middle-end/109996] csmith: -O2 -fno-strict-aliasing causing run time trouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109996 --- Comment #6 from Sam James --- (In reply to mcccs from comment #5) > Created attachment 61396 [details] > adapted for trunk and older GCCs and Clang, removed warnings > > Here's the a little bit hand-simplified version (I mostly removed redundant > attributes and header lines) that works in earlier GCCs, LLVM, latest trunk. > LLVM's sanitizers don't find a problem. > For these, add a check into platform_main_end that just aborts on the wrong checksum. Then to do better, run the good + bad binaries like `diff -u <(./good 1) <(./bad 1)` (the '1' IIRC is how you get the verbose output of checksums at each stage), then you can drop everything after the first difference and add an abort on that instead.
[Bug tree-optimization/120210] New: [12/13/14/15 Regression] std::array like class gives an maybe-uninitialized warning on size() function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120210
Bug ID: 120210
Summary: [12/13/14/15 Regression] std::array like class gives
an maybe-uninitialized warning on size() function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Blocks: 116697
Target Milestone: ---
Like PR 101831 but using a custom class.
```
template
struct a
{
constexpr int size() const { return s; }
int data[s];
};
int f()
{
a<10> b;
return b.size();
}
```
I am not even sure we want to warn on the usage from size method at all.
Maybe we can special case it based on the method name of size instead of the
change that was done for PR 101831.
begin (PR 116697) and end also seems like good candidates too.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116697
[Bug 116697] Bogus -Wuninitialized warning when no access to uninitialized data
is done
[Bug cobol/119769] FE: GnuCOBOL extension BINARY-C-LONG missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119769 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2025-05-10 Ever confirmed|0 |1 --- Comment #3 from James K. Lowden --- To gitlab.cobolworx.com:COBOLworx/gcc-cobol.git 45ec6946015..1e4b3981966 parser -> parser This adds BINARY-C-LONG as an alias for BINARY-DOUBLE with -dialect gnu. It also adds -dialect gnu to the command line invoked by gcobc. dialects are now cumulative: "gcobol -dialect mf -dialect gnu" is valid. > in 32bit it would equate to BINARY-LONG We do not expect gcobol to produce 32-bit binaries. As of GCC 15, gcobol has been tested only on x86_64 and aarch64. Work on portability to other 64-bit architectures is ongoing, but it has been over a decade since Apple, Microsoft, or any major Linux distribution has been released for a 32-bit machine.
[Bug tree-optimization/120211] New: ICE on valid code at -O3 with "-fno-tree-copy-prop -fno-tree-dominator-opts -fno-tree-loop-ivcanon -fno-tree-pre -fno-code-hoisting" on x86_64-linux-gnu: in gimple_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120211
Bug ID: 120211
Summary: ICE on valid code at -O3 with "-fno-tree-copy-prop
-fno-tree-dominator-opts -fno-tree-loop-ivcanon
-fno-tree-pre -fno-code-hoisting" on x86_64-linux-gnu:
in gimple_phi_arg_def_from_edge, at gimple.h:4759
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/osPh7hq4h
It might be a recent regression as it doesn't reproduce with 15.1 and earlier.
[590] % 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 20250510 (experimental) (GCC)
[591] %
[591] % gcctk -O3 -fno-tree-copy-prop -fno-tree-dominator-opts
-fno-tree-loop-ivcanon -fno-tree-pre -fno-code-hoisting small.c
during GIMPLE pass: vect
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in gimple_phi_arg_def_from_edge, at
gimple.h:4759
2 | int main() {
| ^~~~
0x2633896 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0x9f0f42 fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1815
0x8f76ed gimple_phi_arg_def_from_edge(gphi const*, edge_def const*)
../../gcc-trunk/gcc/gimple.h:4759
0x8f76ed gimple_phi_arg_def_from_edge(gphi const*, edge_def const*)
../../gcc-trunk/gcc/gimple.h:4757
0x8f76ed vect_analyze_slp(vec_info*, unsigned int, bool)
../../gcc-trunk/gcc/tree-vect-slp.cc:4986
0x1458304 vect_analyze_loop_2
../../gcc-trunk/gcc/tree-vect-loop.cc:2861
0x145a1f4 vect_analyze_loop_1
../../gcc-trunk/gcc/tree-vect-loop.cc:3422
0x145a94b vect_analyze_loop(loop*, gimple*, vec_info_shared*)
../../gcc-trunk/gcc/tree-vect-loop.cc:3582
0x14b443c try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.cc:1095
0x14b443c try_vectorize_loop
../../gcc-trunk/gcc/tree-vectorizer.cc:1214
0x14b4d8c execute
../../gcc-trunk/gcc/tree-vectorizer.cc:1330
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[592] %
[592] % cat small.c
int a, b[1];
int main() {
int c = 0;
for (; c < 1; c++) {
while (a)
c++;
b[c] = 0;
}
}
[Bug fortran/120193] Incorrect debug info for unsigned(kind=1) and unsigned(kind=4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120193 --- Comment #2 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:512371d786e70d27dbaef38d60e9036c11f458c6 commit r16-516-g512371d786e70d27dbaef38d60e9036c11f458c6 Author: Jakub Jelinek Date: Sat May 10 21:20:09 2025 +0200 fortran: Fix debug info for unsigned(kind=1) and unsigned(kind=4) [PR120193] As the following testcase shows, debug info for unsigned(kind=1) and unsigned(kind=4) vars is wrong while unsigned(kind=2), unsigned(kind=8) and unsigned(kind=16) look right. Instead of objects having unsigned(kind=1) type they have character(kind=1) and instead of unsigned(kind=4) they have character(kind=4). This means in gdb e.g. unsigned(kind=1) :: a(2) variable initialized to 97 will print as 'aa' rather than (97, 97) etc. While there can be just one unsigned_char_type_node and one unsigned_type_node type, each can have arbitrary number of variants (e.g. consider C typedef unsigned char uc; where uc is a variant type to unsigned char) or even distinct types with different TYPE_MAIN_VARIANT. The following patch uses a variant of the character(kind=4) type for unsigned(kind=4) and a distinct type based on character(kind=1) type for unsigned(kind=1). The reason for the latter is that unsigned_char_type_node has TYPE_STRING_FLAG set on it, so it has DW_AT_encoding DW_ATE_unsigned_char rather than DW_ATE_unsigned and so the debugger then likes to print it as characters rather than numbers. That is IMHO in Fortran desirable for character(kind=1) but not for unsigned(kind=1). I've made sure TYPE_CANONICAL of the unsigned(kind=1) type is still character(kind=1), so they are considered compatible by the middle-end also e.g. for aliasing etc. 2025-05-10 Jakub Jelinek PR fortran/120193 * trans-types.cc (gfc_init_types): For flag_unsigned use build_distinct_type_copy or build_variant_type_copy from gfc_character_types[index_char] if index_char > -1 instead of gfc_character_types[index_char] or gfc_build_unsigned_type (&gfc_unsigned_kinds[index]). * gfortran.dg/guality/pr120193.f90: New test.
[Bug middle-end/120207] print_rtl_single_with_indent is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120207 --- Comment #5 from Andrew Pinski --- (In reply to H.J. Lu from comment #4) > (In reply to Andrew Pinski from comment #3) > > Created attachment 61395 [details] > > Patch which I am testing > > -/* Like print_rtx, except specify a file. */ > +/* Like print_rtx, except only print the first of the chain > ^^ Shouldn't it be print_rtl? > + rather than all of the chain. */ Yes I will fix it before submitting it. Though it seems like sometimes rtl and other times rtx is used. e.g. print_rtx and print_rtl both does exist as a method of rtx_writer. Though print_rtl_single is basically the same as print_rtx ... So let me try to clean that mess up some more then. My patch is just a stop gap.
[Bug fortran/102891] Passing real part of complex type component using w%z%re to a subroutine gives erroneous value of dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102891 --- Comment #6 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:94fa992b60e53dcf807fc7055ab606d828b931d8 commit r16-518-g94fa992b60e53dcf807fc7055ab606d828b931d8 Author: Harald Anlauf Date: Tue May 6 20:59:48 2025 +0200 Fortran: fix passing of inquiry ref of complex array to TRANSFER [PR102891] PR fortran/102891 gcc/fortran/ChangeLog: * dependency.cc (gfc_ref_needs_temporary_p): Within an array reference, inquiry references of complex variables generally need a temporary. gcc/testsuite/ChangeLog: * gfortran.dg/transfer_array_subref.f90: New test.
[Bug c++/120174] ICE (Segfault) in GCC when passing array of class to generic lambda taking decltype of lambda with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120174
--- Comment #3 from Andrew Pinski ---
Reduced testcase:
```
auto t = [](decltype([](){}) &){};
```
[Bug c++/120174] ICE (Segfault) in GCC when passing array of class to generic lambda taking decltype of lambda with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120174
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Reduced testcase:
> ```
> auto t = [](decltype([](){}) &){};
> ```
Actually this is the reduced testcase:
```
auto c = [](decltype([](){})={}){ return 0; };
auto t = c(1);
```
[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15 since r15-3153-g68ee624bc52ba1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #20 from Iain Sandoe --- CWG2563 has been reworded, which clarifies that the behaviour expected here is the design intent. I have a patch series in progress.
[Bug c++/120174] ICE (Segfault) in GCC when passing array of class to generic lambda taking decltype of lambda with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120174 Andrew Pinski changed: What|Removed |Added Keywords||c++-lambda Last reconfirmed||2025-05-10 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/107430] [meta-bug] lambda in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107430 Bug 107430 depends on bug 120174, which changed state. Bug 120174 Summary: ICE (Segfault) in GCC when passing array of class to generic lambda taking decltype of lambda with -std=c++20 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120174 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/120174] ICE (Segfault) in GCC when passing array of class to generic lambda taking decltype of lambda with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120174 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 99505 ***
[Bug c++/99505] ICE Segmentation fault when decltype lambda in parameter list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99505 Andrew Pinski changed: What|Removed |Added CC||mario.rodriguezb1 at um dot es --- Comment #8 from Andrew Pinski --- *** Bug 120174 has been marked as a duplicate of this bug. ***
[Bug middle-end/109996] csmith: -O2 -fno-strict-aliasing causing run time trouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109996
Sam James changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #8 from Sam James ---
(In reply to mcccs from comment #7)
> Thank you Sam for the prompt reply and clear instructions. I was going to do
> that but before it printed anything it aborted.
>
You're welcome! Thanks for the help recently.
> I think the issue is INVALID because on this line:
>
> static union U3 g_979 __attribute__((aligned(8), common, deprecated)) =
> {1UL};
>
I agree -- see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982#c13. It was
filed around the same time, so I suspect the same thing happened here.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051
--- Comment #15 from Christoph Reiter ---
Thanks, that seems to have fixed the babl build.
Because I already had it, a reduced example:
$ cat test.c
// gcc -O2 -gcodeview -c test.c
typedef long a;
typedef int b;
int c(void *, void *, a);
b d() {
"" ? ({
char *e;
char *f = "";
{
a g;
c(e, 0, g);
}
})
: "";
}
[Bug tree-optimization/120211] [16 regression] ICE on valid code at -O3 with "-fno-tree-copy-prop -fno-tree-dominator-opts -fno-tree-loop-ivcanon -fno-tree-pre -fno-code-hoisting" on x86_64-linux-gnu:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120211 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |16.0 Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-10 Ever confirmed|0 |1 Summary|ICE on valid code at -O3|[16 regression] ICE on |with "-fno-tree-copy-prop |valid code at -O3 with |-fno-tree-dominator-opts|"-fno-tree-copy-prop |-fno-tree-loop-ivcanon |-fno-tree-dominator-opts |-fno-tree-pre |-fno-tree-loop-ivcanon |-fno-code-hoisting" on |-fno-tree-pre |x86_64-linux-gnu: in|-fno-code-hoisting" on |gimple_phi_arg_def_from_edg |x86_64-linux-gnu: in |e, at gimple.h:4759 |gimple_phi_arg_def_from_edg ||e, at gimple.h:4759 Keywords||needs-bisection --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/119907] ICE in tsubst_expr, at cp/pt.cc:21973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119907 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-11 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #6 from Andrew Pinski --- .
[Bug testsuite/119909] gcc.dg/torture/pr119131-1.c fails since r15-7974-g0bbdffc5d4f723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119909 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
[Bug testsuite/119909] gcc.dg/torture/pr119131-1.c fails since r15-7974-g0bbdffc5d4f723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119909 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:bfb61bf309ed207694a97adabc454bfd0936b269 commit r16-522-gbfb61bf309ed207694a97adabc454bfd0936b269 Author: Andrew Pinski Date: Sat May 10 17:13:05 2025 -0700 testsuite: Fix pr119131-1.c for targets which emit a psabi warning for vectors of DFP [PR119909] On PowerPC, there is a psabi warning for argument passing of a DFP vector. We are not expecting this warning and we get a failure due to it. Adding -Wno-psabi fixes the testcase. Committed as obvious after a quick test. gcc/testsuite/ChangeLog: PR testsuite/119909 * gcc.dg/torture/pr119131-1.c: Add -Wno-psabi. Signed-off-by: Andrew Pinski
[Bug middle-end/109996] csmith: -O2 -fno-strict-aliasing causing run time trouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109996
--- Comment #7 from mcccs at gmx dot com ---
Thank you Sam for the prompt reply and clear instructions. I was going to do
that but before it printed anything it aborted.
I think the issue is INVALID because on this line:
static union U3 g_979 __attribute__((aligned(8), common, deprecated)) = {1UL};
If I remove aligned(8) or make it "16" it doesn't segfault. This makes sense
because "union U3" has unsigned __int128 members, so GCC optimizations require
alignment of 16 for these.
It segfaults on this statement:
g_979.f1 = 0;
for
union U3 {
unsigned __int128 f0;
unsigned __int128 f1;
...
}
so obviously it aborts.
[Bug rtl-optimization/92080] Missed CSE of _mm512_set1_epi8(c) with _mm256_set1_epi8(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080 H.J. Lu changed: What|Removed |Added Attachment #61392|0 |1 is obsolete|| --- Comment #14 from H.J. Lu --- Created attachment 61397 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61397&action=edit An updated patch
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 --- Comment #6 from James K. Lowden --- Taking a cue from Iain, the output is now: $ gcobol OB/OBIC2A.cbl OB/OBIC2A.cbl:131:24: warning: SECTION segment ‘30. ’ was ignored 131 | 013000 SECT-IC219-0001 SECTION 30. OBIC24.2 |^ There is no provision as yet to suppress warnings. That is on the TODO list. It was the case, briefly, that cbl_unimplmentedw (ending in 'w') was a warning and not an error. Now it uses DK_SORRY, which is documented not to produce an object file. There are currently 11 uses of that function in the COBOL FE that will need to be addressed along with other warning/error issues. This particular issue will be closed with the understanding that there remains a need both to suppress warnings with -Wno- and to elevate them to errors with -Werror.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #16 from Christoph Reiter --- (In reply to Christoph Reiter from comment #15) > Thanks, that seems to have fixed the babl build. ah, I meant the gegl build.
[Bug rtl-optimization/101995] [12/13/14 Regression] regression built-in memset missed-optimization arm -Os since r9-3594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120214 --- Comment #20 from Andrew Pinski --- (In reply to Andrew Pinski from comment #19) > (In reply to Andrew Pinski from comment #17) > > This is a different issue where the C++ front-end does not add a fnspec for > > the constructor (and deconstructor) with `targetm.cxx.cdtor_returns_this ()` > > returning true. I will file this a sperate issue. > > Filed as PR 119699 . Also file PR 120214 for another related issue for stack address vs REG_RETURNED; I have not looked into fix that one though which is required to the testcase in comment #16.
[Bug c++/119699] fnspec for constructors/deconstructors don't say they return this when targetm.cxx.cdtor_returns_this () returns true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119699
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > Yes because REG_RETURNED does not work always. I will file a new bug for
> > that.
>
> PR 120214 .
>
> As for tail call, that is a different issue; I have not fully looked into
> yet.
> Cannot tail-call: call and return value are different: x::x (_2(D));
>
> The call flags are definitely set but I will need to debug what is going
> wrong.
Oh it is on the function type rather than the decl.
So this works for the tail call testcase in comment #1:
```
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 03e8c98d4b6..c1a9b22454b 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -14370,6 +14370,16 @@ grokdeclarator (const cp_declarator *declarator,
else
returned_attrs = attr_chainon (returned_attrs, att);
}
+ if (inner_declarator
+ && inner_declarator->kind == cdk_id
+ && (inner_declarator->u.id.sfk == sfk_destructor
+ || inner_declarator->u.id.sfk == sfk_constructor)
+ && targetm.cxx.cdtor_returns_this ())
+ {
+ attrs = tree_cons (get_identifier ("fn spec"),
+ build_tree_list (NULL_TREE, build_string (2, "1 ")),
+ attrs);
+ }
/* Actually apply the contract attributes to the declaration. */
for (tree *p = &attrs; *p;)
```
[Bug target/120215] New: [16 Regression] FAIL: gcc.target/i386/pr78794.c scan-assembler pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120215 Bug ID: 120215 Summary: [16 Regression] FAIL: gcc.target/i386/pr78794.c scan-assembler pandn Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- Target: x86-64 On x86-64, r16-517-g993aa0bd28722c gave: FAIL: gcc.target/i386/pr78794.c scan-assembler pandn
[Bug target/120216] New: openmp unified shared memory currently requires pageableMemoryAccess perhaps managedMemory would suffice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120216 Bug ID: 120216 Summary: openmp unified shared memory currently requires pageableMemoryAccess perhaps managedMemory would suffice Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: schulz.benjamin at googlemail dot com Target Milestone: --- Hi there, as per the gcc 15.1 documentation: https://gcc.gnu.org/onlinedocs/gcc-15.1.0/libgomp/nvptx.html OpenMP code that has a requires directive with self_maps or unified_shared_memory runs on nvptx devices if and only if all of those support the pageableMemoryAccess property;5 otherwise, all nvptx device are removed from the list of available devices (“host fallback”). However, there are devices, like the Nvidia gtx 1660 super, which has cuda capability 7.5 and the cuda flags concurrentManagedAccess and managedMemory, but no pageableMemoryAccess. In that case, the Nvidia documentation says: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#um-cc60 For devices with compute capability 6.x or higher but without pageable memory access, CUDA Managed Memory is fully supported and coherent. The programming model and performance tuning of unified memory is largely similar to the model as described in Unified memory on devices with full CUDA Unified Memory support, with the notable exception that system allocators cannot be used to allocate memory. Thus, the following list of sub-sections do not apply: System-Allocated Memory: in-depth examples Hardware/Software Coherency So, is pageable memory access really needed for the openmp unified shared memory directive? unified_shared_memory? Because if I understand the nividia documentation correctly, if managed memory and concurrent managed access are there, then the compiler could just look whether a pointer is needed on the device, and then replace malloc by cudamallocmanaged and then it would have the shared pointer?
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #18 from Christoph Reiter --- (In reply to Iouri Kharon from comment #17) > (In reply to Christoph Reiter from comment #16) > > (In reply to Christoph Reiter from comment #15) > > > Thanks, that seems to have fixed the babl build. > > > > ah, I meant the gegl build. > > And did you apply the patch that I posted on the 10th? > Because this example compiles for me. Yes. And yes, it compiles for me too. I just added the reduced example for future reference.
[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049
--- Comment #27 from kargls at comcast dot net ---
On 5/10/25 06:21, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049
>
> --- Comment #26 from anlauf at gcc dot gnu.org ---
> Have you tried to move some of the checks *after* the resolution stage?
>
> The checks in check.cc are invoked rather early. Maybe look into
> trans-intrinsic.cc (conv_isocbinding_function)?
>
The checks in check.cc should still occur, but I think we need
something like my WIP. The diff is hard to read, so:
/* C_PTR_1 shall be a scalar of type C_PTR or C_FUNPTR.
C_PTR_2 (optional) shall be a scalar of the same type as C_PTR_1.
In 'A = C_ASSOCIATED(C_LOC(X))' and similar expression where C_LOC
is indirectly accessed through a user's module and not directly from
ISO_C_BINDING, the */
bool
gfc_check_c_associated (gfc_expr *c_ptr_1, gfc_expr *c_ptr_2)
{
bool saw_c_ptr = false, saw_fun_ptr = false;
if (!scalar_check (c_ptr_1, 0))
return false;
/* This test might be too restrictive due to renaming as from_intmod
might not be set. */
if (c_ptr_1->ts.type == BT_DERIVED
&& c_ptr_1->ts.u.derived->from_intmod == INTMOD_ISO_C_BINDING)
{
if (c_ptr_1->ts.u.derived->intmod_sym_id == ISOCBINDING_PTR)
saw_c_ptr = true;
else if (c_ptr_1->ts.u.derived->intmod_sym_id == ISOCBINDING_FUNPTR)
saw_c_funptr = true;
else
goto error1;
}
else if (c_ptr_1->expr_type == EXPR_FUNCTION && c_ptr_1->ts.type ==
BT_VOID)
{
if (c_ptr_1->ts.u.derived->intmod_sym_id == ISOCBINDING_PTR)
saw_c_ptr = true;
else if (c_ptr_1->ts.u.derived->intmod_sym_id == ISOCBINDING_FUNPTR)
saw_c_funptr = true;
else
goto error1;
}
else
goto error1;
if (c_ptr_2 && !scalar_check (c_ptr_2, 1))
return false;
if (c_ptr_2 && saw_c_ptr)
{
if (c_ptr_2->ts.type == BT_DERIVED
&& c_ptr_2->ts.u.derived->from_intmod == INTMOD_ISO_C_BINDING
&& c_ptr_2->ts.u.derived->intmod_sym_id != ISOCBINDING_PTR)
goto erro2;
else if (c_ptr_2->expr_type == EXPR_FUNCTION
&& c_ptr_2->ts.type == BT_VOID)
{
}
else
goto error2;
}
else if (c_ptr_2 && saw_c_funptr)
{
/* Same type of checking as for C_PTR. */
}
else
goto error2;
return true;
error1:
gfc_error ("Argument C_PTR_1 at %L to C_ASSOCIATED shall have the "
"type TYPE(C_PTR) or TYPE(C_FUNPTR)", &c_ptr_1->where);
return false;
error2:
gfc_error ("Argument C_PTR_2 at %L to C_ASSOCIATED shall have the "
"same type as C_PTR_1: %s instead of %s", &c_ptr_1->where,
gfc_typename (&c_ptr_1->ts), gfc_typename (&c_ptr_2->ts));
return false;
}
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #17 from Iouri Kharon --- (In reply to Christoph Reiter from comment #16) > (In reply to Christoph Reiter from comment #15) > > Thanks, that seems to have fixed the babl build. > > ah, I meant the gegl build. And did you apply the patch that I posted on the 10th? Because this example compiles for me.
[Bug middle-end/118072] [14/15/16 Regression] (n%7) sometimes uses udiv and sometimes does not depending on if `n/7` is used beforehand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118072
mcccs at gmx dot com changed:
What|Removed |Added
CC||mcccs at gmx dot com
--- Comment #5 from mcccs at gmx dot com ---
Yes, they are very close.
> Function 1 took 2304345 microseconds
> Function 2 took 2304357 microseconds
Other runs output similar values.
for the code:
#include
#include
__attribute__((noipa)) void g(int r) {(void) r;}
__attribute__((noipa)) unsigned long mod7(unsigned long n) {
return n % 7;
}
__attribute__((noipa)) unsigned long div7(unsigned long n) {
return n / 7;
}
__attribute__((noipa)) unsigned long mod7_1(unsigned long n) {
return n % 7;
}
// Function 1 to benchmark
void function1() {
// Simulate some work
for (long i = (1l << 50); i < (1l << 50)+ 10; i++) {
g(mod7(i));
}
}
// Function 2 to benchmark
void function2() {
// Simulate some work
for (long i = (1l << 50); i < (1l << 50)+ 10; i++) {
g(mod7_1(i));
}
}
// Benchmark function
template
auto benchmark(Func func) {
auto start = std::chrono::high_resolution_clock::now();
func();
auto end = std::chrono::high_resolution_clock::now();
auto duration = std::chrono::duration_cast(end -
start);
return duration.count();
}
int main() {
g(mod7(1l << 50));
g(mod7_1(1l << 50));
// Benchmark function1
auto time1 = benchmark(function1);
std::cout << "Function 1 took " << time1 << " microseconds" << std::endl;
// Benchmark function2
auto time2 = benchmark(function2);
std::cout << "Function 2 took " << time2 << " microseconds" << std::endl;
return 0;
}
[Bug c++/119897] Conversion to any integer type succeeds, when should be ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119897 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-10 Ever confirmed|0 |1 Status|UNCONFIRMED |SUSPENDED --- Comment #2 from Andrew Pinski --- Oh look there is an active C++ defect report specifically for this: https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#954 So suspending until that defect report is fixed.
[Bug c++/119897] Conversion to any integer type succeeds, when should be ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119897 --- Comment #1 from Andrew Pinski --- So GCC, EDG and MSVC all agree that the code is not ambiguous when there is `operator bool` (or operator int). Only clang disagrees with the above case. EDG does not think it is ambiguous even without the `operator bool`. GCC, clang and MSVC all think it is ambiguous without `operator bool` case. I am not sure what the correct answer is based on that.
[Bug c++/33990] bug in lookup of member template conversion operator for pointer to member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33990 --- Comment #7 from Andrew Pinski --- https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#954 and https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#545 look related
[Bug c++/89580] template conversion operator not considered for operator == of pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89580 --- Comment #2 from Andrew Pinski --- https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#954 Looks related.
[Bug c++/118277] g++ ICEs with depedent inline-asm string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118277 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug rtl-optimization/92080] Missed CSE of _mm512_set1_epi8(c) with _mm256_set1_epi8(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080 --- Comment #15 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:ba9d228a92057d3b839e7ea32b12c93fcfc5ff1e commit r16-519-gba9d228a92057d3b839e7ea32b12c93fcfc5ff1e Author: H.J. Lu Date: Sun May 11 06:17:45 2025 +0800 x86: Change dest to src in replace_vector_const Replace rtx dest = SET_SRC (set); with rtx src = SET_SRC (set); in replace_vector_const to avoid confusion. PR target/92080 PR target/117839 * config/i386/i386-features.cc (replace_vector_const): Change dest to src. Signed-off-by: H.J. Lu
[Bug c/120213] New: analyzer report a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120213
Bug ID: 120213
Summary: analyzer report a false positive
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: raffaellobertini at gmail dot com
Target Milestone: ---
compile this code:
```
#include
#include
#include
#define NUM_CHARS 1
void split_string(const char* str)
{
const size_t l = strnlen(str, 2);
if (l > NUM_CHARS)
{
char s[NUM_CHARS + 1];
memcpy(s, str, NUM_CHARS);
s[NUM_CHARS] = '\0';
split_string(s);
split_string(&str[NUM_CHARS]);
return;
}
printf("%s", str);
}
int main()
{
split_string("H");
return 0;
}
```
using a cmake conifg of:
```
add_executable(split-string src/split-string.c)
target_compile_options(split-string
PRIVATE "-Wall" "-Wextra"
$<$: -fanalyzer>
)
```
the output reported is a warning: "warning: stack-based buffer over-read
[CWE-126]"
Also the output seems a little bit corrupted:
```
[build]13 | memcpy(s, str, NUM_CHARS);
[build] | ^
[build] 'main': events 1-2
[build] Γöé
[build] Γöé 23 | int main()
[build] Γöé | ^~~~
[build] Γöé | |
[build] Γöé | (1) entry to 'main'
[build] Γöé 24 | {
[build] Γöé 25 | split_string("H");
[build] Γöé | ~
[build] Γöé | |
[build] Γöé | (2) calling 'split_string' from 'main'
[build] Γöé
[build] ΓööΓöÇΓöÇ> 'split_string': events 3-7
[build]Γöé
[build]Γöé7 | void split_string(const char* str)
[build]Γöé | ^~~~
[build]Γöé | |
[build]Γöé | (3) entry to 'split_string'
[build]Γöé..
[build]Γöé 10 | if (l > NUM_CHARS)
[build]Γöé |~
[build]Γöé ||
[build]Γöé |(5) following 'true' branch (when 'l >
1')... ΓöÇ>ΓöÇΓöÉ
[build]Γöé |
Γöé
[build]Γöé |
Γöé
[build]Γöé
|ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
[build]Γöé 11 |Γöé{
[build]Γöé 12 |Γöéchar s[NUM_CHARS + 1];
[build]Γöé |Γöé ~
[build]Γöé |Γöé |
[build]Γöé |Γöé (4) capacity: 2 bytes
[build]Γöé 13 |Γöémemcpy(s, str, NUM_CHARS);
[build]Γöé |Γöé~
[build]Γöé |Γöé|
[build]Γöé |ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇ>(6) ...to here
[build]Γöé 14 | s[NUM_CHARS] = '\0';
[build]Γöé 15 | split_string(s);
[build]Γöé | ~~~
[build]Γöé | |
[build]Γöé | (7) calling 'split_string' from
'split_string'
[build]Γöé
[build]ΓööΓöÇΓöÇ> 'split_string': events 8-12
[build] Γöé
[build] Γöé7 | void split_string(const char* str)
[build] Γöé | ^~~~
[build] Γöé | |
[build] Γöé | (8) entry to 'split_string'
[build] Γöé..
[build] Γöé 10 | if (l > NUM_CHARS)
[build] Γöé |~
[build] Γöé ||
[build] Γöé |(10) following 'true' branch (when
'l > 1')... ΓöÇ>ΓöÇΓöÉ
[build] Γöé |
Γöé
[build] Γöé |
Γöé
[build] Γöé
|ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ
[...]
```
It looks like the analyzer is assuming the branch of `if (l> NUM_CHARS)` true
even when is false, basically doesn't logically follow the first 2 lines of the
spit_string function.
At least it looks like so to me.
[Bug target/117839] Redundant vector XOR instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117839 --- Comment #7 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:ba9d228a92057d3b839e7ea32b12c93fcfc5ff1e commit r16-519-gba9d228a92057d3b839e7ea32b12c93fcfc5ff1e Author: H.J. Lu Date: Sun May 11 06:17:45 2025 +0800 x86: Change dest to src in replace_vector_const Replace rtx dest = SET_SRC (set); with rtx src = SET_SRC (set); in replace_vector_const to avoid confusion. PR target/92080 PR target/117839 * config/i386/i386-features.cc (replace_vector_const): Change dest to src. Signed-off-by: H.J. Lu
[Bug c++/59465] [11/12/13 Regression] g++ allows direct-initialization of an array of class type from another array in a mem-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59465 Andrew Pinski changed: What|Removed |Added Target Milestone|11.5|14.0
[Bug cobol/119337] cobol: gcobc wrapper should deduce output name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119337
--- Comment #2 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:a3f5aac402a7ef721e1e832f96ed77ec21f5a25c
commit r16-520-ga3f5aac402a7ef721e1e832f96ed77ec21f5a25c
Author: Robert Dubner
Date: Sat May 10 18:05:29 2025 -0400
cobol: Auto-detect source format; some FldLiteralN; infer gcobc name.
[PR119337]
This commit includes changes to the parser's auto-detection heuristic for
source
code formatting. The heuristic now examines the line containing
"program-id" to
determine whether the code is in ISO "fixed-form reference format", or ISO
"free-form reference format", or the IBM "extended source format".
Changes to the parser also changes to token processing.
On the code generation side, there are some changes that begin to process
numeric literals in order generate more efficient code using information
known
at compilation time.
gcc/cobol/ChangeLog:
PR cobol/119337
* Make-lang.in: Change how $(FLEX) is invoked.
* cdf.y: Change parser tokens.
* gcobc: Changed how name is inferred for PR119337
* gcobol.1: Documentation for SOURCE format heuristic
* genapi.cc: Eliminate __gg__odo_violation.
(parser_display_field): Change comment.
* genutil.cc:Eliminate __gg__odo_violation.
(REFER): New macro for analyzing subscript/refmod calculations.
(get_integer_value): Likewise.
(get_data_offset): Eliminate __gg__odo_violation.
(scale_by_power_of_ten_N): Eliminate unnecessary var_decl_rdigits
operation.
(refer_is_clean): Check for FldLiteralN.
(REFER_CHECK): Eliminate.
(refer_refmod_length): Streamline var_decl_rdigits processing.
(refer_fill_depends): Likewise.
(refer_offset): Streamline processing when FldLiteralN.
(refer_size): Tag with REFER macro.
(refer_size_dest): Likewise.
(refer_size_source): Likewise.
* genutil.h (get_integer_value): Delete declaration for
odo_violation;
change comment for get_integer_value
(REFER_CHECK): Delete declaration.
(refer_check): Delete #define.
* lexio.cc (is_fixed_format): Changes for source format
auto-detect.
(is_reference_format): Likewise.
(check_source_format_directive): Likewise.
(valid_sequence_area): Likewise.
(is_p): Likewise.
(is_program_id): Likewise.
(likely_nist_file): Likewise.
(infer_reference_format): Likewise.
(cdftext::free_form_reference_format): Likewise.
* parse.y: Token changes.
* parse_ante.h (class tokenset_t): Likewise.
(class current_tokens_t): Likewise.
(cmd_or_env_special_of): Likewise.
* scan.l: Likewise.
* scan_ante.h (bcomputable): Likewise.
(keyword_alias_add): Likewise.
(struct bint_t): Likewise.
(binary_integer_usage): Likewise.
(binary_integer_usage_of): Likewise.
* scan_post.h (start_condition_str): Likewise.
* symbols.cc (symbol_table_init): Formatting.
* symbols.h (struct cbl_field_data_t): Add "input" method to
field_data_t.
(keyword_alias_add): Add forward declaration.
(binary_integer_usage_of): Likewise.
* token_names.h: Change list of tokens.
* util.cc (iso_cobol_word): Change list of COBOL reserved words.
libgcobol/ChangeLog:
* common-defs.h (ec_cmp): Delete "getenv("match_declarative")"
calls.
(enabled_exception_match): Delete "getenv("match_declarative")"
calls.
* libgcobol.cc: Eliminate __gg__odo_violation.
gcc/testsuite/ChangeLog:
* cobol.dg/group1/simple-if.cob: Make explicitly >>SOURCE FREE
[Bug analyzer/120213] analyzer report a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120213 --- Comment #1 from Andrew Pinski --- >Also the output seems a little bit corrupted: That looks like a cmake issue and not a GCC issue. See https://godbolt.org/z/P4WbhT4Ee
[Bug analyzer/120213] analyzer report a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120213 --- Comment #2 from Sam James --- I can't reproduce that corrupted output. Did you get that from a CI system or something like that?
[Bug c++/120128] Excesive output in recursive lambda composition, that can lead to g++:fatal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120128 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- This is a won't fix. If you want to limit the number of errors, then you need to use the -fmax-errors= option. GCC has decided to default to unlimited errors on purpose especially when other compilers would stop after a few errors. >To reproduce g++: fatal error: This is just a timeout limit and nothing else.
[Bug analyzer/120213] analyzer report a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120213 --- Comment #4 from Andrew Pinski --- (In reply to Raffaello Bertini from comment #3) > (In reply to Sam James from comment #2) > > I can't reproduce that corrupted output. Did you get that from a CI system > > or something like that? > > no i had that from the embedded terminal of the IDE VsCode > > my environment is: > > MSYS2 (Windows) > VsCode > cmake v4.0.1 > GCC 15.1.0 I would complain to VScode because it is works just fine for other terminals that implement ascii control characters with UTF-8.
[Bug analyzer/120213] analyzer report a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120213 --- Comment #3 from Raffaello Bertini --- (In reply to Sam James from comment #2) > I can't reproduce that corrupted output. Did you get that from a CI system > or something like that? no i had that from the embedded terminal of the IDE VsCode my environment is: MSYS2 (Windows) VsCode cmake v4.0.1 GCC 15.1.0
[Bug analyzer/120213] analyzer report a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120213 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > I would complain to VScode because it is works just fine for other terminals > that implement ascii control characters with UTF-8. Oh XScode should be using the sarif output format anyways. So it still not a GCC bug.
[Bug c++/120124] "g++: fatal error: Killed signal..." when reporting error involving very complex lambda type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120124 Andrew Pinski changed: What|Removed |Added Keywords||c++-lambda Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-05-10 --- Comment #1 from Andrew Pinski --- Confirmed. #589 0x02993fb0 in error (gmsgid=gmsgid@entry=0x2aaa480 "no match for call to %<(%T) (%A)%>") at /home/apinski/src/upstream-gcc-isel/gcc/gcc/diagnostic-core.h:75 is taking a long time to print out the function name I think.
[Bug analyzer/120213] analyzer report a false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120213 --- Comment #6 from Sam James --- Looks like it doesn't default to UTF8: https://github.com/Microsoft/vscode/issues/19837.
[Bug c++/119699] fnspec for constructors/deconstructors don't say they return this when targetm.cxx.cdtor_returns_this () returns true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119699
--- Comment #3 from Andrew Pinski ---
(In reply to Christophe Lyon from comment #2)
> FTR I tried this based on your suggestion:
> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> index a785d5e79cb..a709bde8f15 100644
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -18945,6 +18945,7 @@ maybe_prepare_return_this (tree cdtor)
>if (targetm.cxx.cdtor_returns_this ())
> if (tree val = DECL_ARGUMENTS (cdtor))
>{
> + set_call_expr_flags (cdtor, ECF_RET1);
> suppress_warning (val, OPT_Wuse_after_free);
> return val;
>}
> but it had no effect on codegen.
Yes because REG_RETURNED does not work always. I will file a new bug for that.
[Bug rtl-optimization/120214] New: REG_RETURNED Does not always work for stack addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120214 Bug ID: 120214 Summary: REG_RETURNED Does not always work for stack addresses Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64 arm Created attachment 61400 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61400&action=edit testcase Take the testcase in the attachment. Compile with -O2 on aarch64 or arm (for some reason RISCV works). You should get: ``` bl memset bl doStuff ``` But currently we get: ``` add x0, sp, 16 stp x29, x30, [sp] .cfi_offset 29, -4128 .cfi_offset 30, -4120 mov x29, sp bl memset add x0, sp, 16 bl doStuff ``
[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 --- Comment #15 from Benjamin Schulz --- Hi there, my recent openmp version of the code seems to compile now (after a small change) executes without error on gcc 15.1 on gpu. So I now think about whether I have to re-convert some of it back to openACC. But, first and foremost, I can now add more features to the code and make the library really usable. So, thanks. I will alert you, if I come across further compilation problems in gcc, of course.
[Bug c++/118590] [14 regression] ICE with acc enter data copyin and dependent types since r14-7033-g1413af02d62182
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118590 --- Comment #13 from Benjamin Schulz --- Thanks. Works with 15.1
[Bug testsuite/119909] gcc.dg/torture/pr119131-1.c fails since r15-7974-g0bbdffc5d4f723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119909 --- Comment #7 from GCC Commits --- The releases/gcc-15 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:de014484f013225bc32bc6eeb11e44038925ae1b commit r15-9648-gde014484f013225bc32bc6eeb11e44038925ae1b Author: Andrew Pinski Date: Sat May 10 17:13:05 2025 -0700 testsuite: Fix pr119131-1.c for targets which emit a psabi warning for vectors of DFP [PR119909] On PowerPC, there is a psabi warning for argument passing of a DFP vector. We are not expecting this warning and we get a failure due to it. Adding -Wno-psabi fixes the testcase. Committed as obvious after a quick test. gcc/testsuite/ChangeLog: PR testsuite/119909 * gcc.dg/torture/pr119131-1.c: Add -Wno-psabi. Signed-off-by: Andrew Pinski (cherry picked from commit bfb61bf309ed207694a97adabc454bfd0936b269)
[Bug testsuite/119909] gcc.dg/torture/pr119131-1.c fails since r15-7974-g0bbdffc5d4f723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119909 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |15.2 Resolution|--- |FIXED --- Comment #8 from Andrew Pinski --- Fixed.
[Bug tree-optimization/120208] -Wmaybe-uninitialized with -O2 obviously wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120208 Kael Franco changed: What|Removed |Added Attachment #61394|0 |1 is obsolete|| --- Comment #5 from Kael Franco --- Created attachment 61399 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61399&action=edit Reduce C code
[Bug c++/119907] ICE in tsubst_expr, at cp/pt.cc:21973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119907 --- Comment #1 from Andrew Pinski --- >Why is the GCC Bugzilla become so slowly lately??? This was due to AI scrapers, see https://techcrunch.com/2025/03/27/open-source-devs-are-fighting-ai-crawlers-with-cleverness-and-vengeance/ . Anubis is now used on sourceware/gcc.gnu.org and it has helped a lot.
[Bug c++/119907] ICE in tsubst_expr, at cp/pt.cc:21973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119907 --- Comment #3 from Andrew Pinski --- I think we are trying to print out something like: :8:47: error: cannot call member function 'std::bool_constant view::foo(R&) [with R = std::ranges::empty_view; std::bool_constant = std::bool_constant]' without object
[Bug c++/119907] ICE in tsubst_expr, at cp/pt.cc:21973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119907 --- Comment #2 from Andrew Pinski --- 0x29592b6 error(char const*, ...) ???:0 We are trying to print out an error and then ICEing.
[Bug c++/119907] ICE in tsubst_expr, at cp/pt.cc:21973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119907 --- Comment #4 from Andrew Pinski --- Created attachment 61398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61398&action=edit Semi reduced, could not remove std::bool_constant yet.
[Bug c++/119907] ICE in tsubst_expr, at cp/pt.cc:21973
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119907 --- Comment #5 from Andrew Pinski --- (In reply to 康桓瑋 from comment #0) > This is high duplicate of PR 119906: It looks more closely a dup of bug 98800.
[Bug c++/119699] fnspec for constructors/deconstructors don't say they return this when targetm.cxx.cdtor_returns_this () returns true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119699 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Yes because REG_RETURNED does not work always. I will file a new bug for > that. PR 120214 . As for tail call, that is a different issue; I have not fully looked into yet. Cannot tail-call: call and return value are different: x::x (_2(D)); The call flags are definitely set but I will need to debug what is going wrong.
