[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398
--- Comment #32 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:a1a0026c659196928113bad1c7889f5ca0999d06
commit r15-9242-ga1a0026c659196928113bad1c7889f5ca0999d06
Author: Richard Sandiford
Date: Mon Apr 7 08:03:49 2025 +0100
combine: Limit insn searchs for 2->2 combinations [PR116398]
As noted in the previous patch, combine still takes >30% of
compile time in the original testcase for PR101523. The problem
is that try_combine uses linear insn searches for some dataflow
queries, so in the worst case, an unlimited number of 2->2
combinations for the same i2 can lead to quadratic behaviour.
This patch limits distribute_links to a certain number
of instructions when i2 is unchanged. As Segher said in the PR trail,
it would make more conceptual sense to apply the limit unconditionally,
but I thought it would be better to change as little as possible at
this development stage. Logically, in stage 1, the --param should
be applied directly by distribute_links with no input from callers.
As I mentioned in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398#c28
I think it's safe to drop log links even if a use exists. All
processing of log links seems to handle the absence of a link
for a particular register in a conservative way.
The initial set-up errs on the side of dropping links, since for example
create_log_links has:
/* flow.c claimed:
We don't build a LOG_LINK for hard registers contained
in ASM_OPERANDs. If these registers get replaced,
we might wind up changing the semantics of the insn,
even if reload can make what appear to be valid
assignments later. */
if (regno < FIRST_PSEUDO_REGISTER
&& asm_noperands (PATTERN (use_insn)) >= 0)
continue;
which excludes combinations by dropping log links, rather than during
try_combine. And:
/* If this register is being initialized using itself, and the
register is uninitialized in this basic block, and there are
no LOG_LINKS which set the register, then part of the
register is uninitialized. In that case we can't assume
anything about the number of nonzero bits.
??? We could do better if we checked this in
reg_{nonzero_bits,num_sign_bit_copies}_for_combine. Then we
could avoid making assumptions about the insn which initially
sets the register, while still using the information in other
insns. We would have to be careful to check every insn
involved in the combination. */
if (insn
&& reg_referenced_p (x, PATTERN (insn))
&& !REGNO_REG_SET_P (DF_LR_IN (BLOCK_FOR_INSN (insn)),
REGNO (x)))
{
struct insn_link *link;
FOR_EACH_LOG_LINK (link, insn)
if (dead_or_set_p (link->insn, x))
break;
if (!link)
{
rsp->nonzero_bits = GET_MODE_MASK (mode);
rsp->sign_bit_copies = 1;
return;
}
}
treats the lack of a log link as a possible sign of uninitialised data,
but that would be a missed optimisation rather than a correctness issue.
One question is what the default --param value should be. I went with
Jakub's suggestion of 3000 from:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398#c25
Also, to answer Jakub's question in that comment, I tried bisecting:
int limit = atoi (getenv ("BISECT"));
(so applying the limit for all calls from try_combine) with an
abort in distribute_links if the limit caused a link to be skipped.
The minimum BISECT value that allowed an aarch64-linux-gnu bootstrap
to succeed with --enable-languages=all --enable-checking=yes,rtl,extra
was 142, so much lower than the parameter value. I realised too late
that --enable-checking=release would probably have been a more
interesting test.
The previous patch meant that distribute_links itself is now linear
for a given i2 definition, since each search starts at the previous
last use, rather than at i2 itself. This means that the limit has
to be applied cumulatively across all searches for the same link.
The patch does that by storing a counter in the insn_link structure.
There was a 32-bit hole there on LP64 hosts.
gcc/
PR testsuite/116398
* params.opt (-param=max-combine-search-insns=): New param.
* doc/invoke.texi: Document it.
* combine.cc (insn_link::insn_count): New field.
[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398 --- Comment #30 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:30a4eedfdbfeb1caaadd43738cbb0b49d7fa120b commit r15-9240-g30a4eedfdbfeb1caaadd43738cbb0b49d7fa120b Author: Richard Sandiford Date: Mon Apr 7 08:03:47 2025 +0100 combine: Avoid split_i2i3 search if i2 is unchanged [PR116398] When combining a single-set i2 into a multi-set i3, combine first tries to match the new multi-set in-place. If that fails, combine considers splitting the multi-set so that one set goes in i2 and the other set stays in i3. That moves a destination from i3 to i2 and so combine needs to update any associated log link for that destination to point to i2 rather than i3. However, that kind of split can also occur for 2->2 combinations. For a 2-instruction combination in which i2 doesn't die in i3, combine tries a 2->1 combination by turning i3 into a parallel of the original i2 and the combined i3. If that fails, combine will split the parallel as above, so that the first set goes in i2 and the second set goes in i3. But that can often leave i2 unchanged, meaning that no destinations have moved and so no search is necessary. gcc/ PR testsuite/116398 * combine.cc (try_combine): Shortcut the split_i2i3 handling if i2 is unchanged.
[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #33 from Richard Sandiford --- Fixed.
[Bug rtl-optimization/114518] [15 regression] gcc.target/powerpc/combine-2-2.c fails after r14-9692-g839bc42772ba7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114518 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed by the PR116398 fixes.
[Bug target/119408] LoongArch: Q Suffix for __float128 Literals Not Supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408 --- Comment #29 from GCC Commits --- The releases/gcc-14 branch has been updated by LuluCheng : https://gcc.gnu.org/g:73a62377ae638ce85c0a40327e67b41c861fb156 commit r14-11538-g73a62377ae638ce85c0a40327e67b41c861fb156 Author: Lulu Cheng Date: Mon Apr 7 10:00:27 2025 +0800 LoongArch: Add LoongArch architecture detection to __float128 support in libgfortran and libquadmath [PR119408]. In GCC14, LoongArch added __float128 as an alias for _Float128. In commit r15-8962, support for q/Q suffixes for 128-bit floating point numbers. This will cause the compiler to automatically link libquadmath when compiling Fortran programs. But on LoongArch `long double` is IEEE quad, so there is no need to implement libquadmath. This causes link failure. PR target/119408 libgfortran/ChangeLog: * acinclude.m4: When checking for __float128 support, determine whether the current architecture is LoongArch. If so, return false. * configure: Regenerate. libquadmath/ChangeLog: * configure.ac: When checking for __float128 support, determine whether the current architecture is LoongArch. If so, return false. * configure: Regenerate. Sigend-off-by: Xi Ruoyao Sigend-off-by: Jakub Jelinek (cherry picked from commit 1534f0099c98ea14c08a401302b05edf2231f411)
[Bug tree-optimization/87900] malloc + memset to calloc doesn't work for aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87900
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #2 from Andrew Pinski ---
here is another testcase:
```
typedef int type;
#define size (1024)
type *foo ()
{
type *p = (type *)__builtin_malloc (size*sizeof(type));
type tmp[size] = {};
__builtin_memcpy(p,tmp,sizeof(tmp));
return p;
}
```
Which will be closer to the IR for after PR 36602.
strlen_pass::handle_builtin_memset is the only place which does the
malloc->calloc transformation.
I will try my hand at implementing this tomorrow.
[Bug libstdc++/119671] New: Use-after-free for formatting floating-point types to wide strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119671
Bug ID: 119671
Summary: Use-after-free for formatting floating-point types to
wide strings
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
int main()
{
auto loc = std::locale::classic();
assert(std::format(loc, "{:L}\n", 1.23) == "1.23");
assert(std::format(loc, L"{:L}\n", 1.23) != std::wstring(L"\0.23", 4));
}
The second assertion fails.
[Bug tree-optimization/119665] False positive warning about unitialized variable while compiling with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119665 --- Comment #2 from Volodymyr Babchuk --- (In reply to Andrew Pinski from comment #1) > So -Og runs a different optimization pipeline than the other optimization > levels do. It does not do any jump threading nor other optimizations which > will confuse debugging and in this case to see if the desc is uninitialized > an optimization that is not done by -Og is needed. So, should the warning be disabled in this case?
[Bug libstdc++/119671] Use-after-free for formatting floating-point types to wide strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119671 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2025-04-07 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |13.4 Ever confirmed|0 |1
[Bug tree-optimization/87901] partial DSE of memset doesn't work for other kind of stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87901
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> Note for s/17/16/ we still fail; I will handle that afterwards.
That was easy to handle also:
```
diff --git a/gcc/tree-ssa-dse.cc b/gcc/tree-ssa-dse.cc
index 82ebc99686c..b97e833a0ea 100644
--- a/gcc/tree-ssa-dse.cc
+++ b/gcc/tree-ssa-dse.cc
@@ -566,16 +566,17 @@ maybe_trim_complex_store (ao_ref *ref, sbitmap live,
gimple *stmt)
The most common case for getting here is a CONSTRUCTOR with no elements
being used to zero initialize an object. We do not try to handle other
cases as those would force us to fully cover the object with the
- CONSTRUCTOR node except for the components that are dead. */
+ CONSTRUCTOR node except for the components that are dead.
+ Also handles integer stores of 0 which can happen with memset/memcpy
optimizations. */
static void
-maybe_trim_constructor_store (ao_ref *ref, sbitmap live, gimple *stmt)
+maybe_trim_constructor_store (ao_ref *ref, sbitmap live, gimple *stmt, bool
was_integer_cst = false)
{
tree ctor = gimple_assign_rhs1 (stmt);
/* This is the only case we currently handle. It actually seems to
catch most cases of actual interest. */
- gcc_assert (CONSTRUCTOR_NELTS (ctor) == 0);
+ gcc_assert (was_integer_cst ? integer_zerop (ctor) : CONSTRUCTOR_NELTS
(ctor) == 0);
int head_trim = 0;
int tail_trim = 0;
@@ -809,6 +810,10 @@ maybe_trim_partially_dead_store (ao_ref *ref, sbitmap
live, gimple *stmt)
case COMPLEX_CST:
maybe_trim_complex_store (ref, live, stmt);
break;
+ case INTEGER_CST:
+ if (integer_zerop (gimple_assign_rhs1 (stmt)))
+ maybe_trim_constructor_store (ref, live, stmt, true);
+ break;
default:
break;
}
```
[Bug target/119617] ICE: in standard_sse_constant_opcode, at config/i386/i386.cc:5465 with -fzero-call-used-regs=all -mabi=ms -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617 --- Comment #6 from Hongtao Liu --- (In reply to Haochen Jiang from comment #4) > (In reply to Hongtao Liu from comment #3) > > (In reply to Hongtao Liu from comment #2) > > > (In reply to Richard Biener from comment #1) > > > > I think we need to disable the effect of -mno-evex512, looks like > > > > there's > > > > still traces of it left? > > > > > > Let's have a quick fix to avoid ICE, the major clean up work is planed for > > > GCC16. > > > > Reject mno-evex512 could be a solution. > > Maybe we could if the option comes in. But I am not sure if it is too > aggressive for GCC 15. I don't think there're real users using -mno-evex512, so it's probably ok.
[Bug middle-end/101018] ICE when enabling OpenMP on a simple loop with SVE intrinsics (aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018 --- Comment #9 from GCC Commits --- The master branch has been updated by Tejas Belagod : https://gcc.gnu.org/g:001fb23ae46ba4bd1b5e43f756fa89e6fb94ce18 commit r15-9268-g001fb23ae46ba4bd1b5e43f756fa89e6fb94ce18 Author: Richard Sandiford Date: Fri May 12 10:33:25 2023 +0100 gomp: Various fixes for SVE types [PR101018] Various parts of the omp code checked whether the size of a decl was an INTEGER_CST in order to determine whether the decl was variable-sized or not. If it was variable-sized, it was expected to have a DECL_VALUE_EXPR replacement, as for VLAs. This patch uses poly_int_tree_p instead, so that variable-length SVE vectors are treated like constant-length vectors. This means that some structures become poly_int-sized, with some fields at poly_int offsets, but we already have code to handle that. An alternative would have been to handle the data via indirection instead. However, that's likely to be more complicated, and it would contradict is_variable_sized, which already uses a check for TREE_CONSTANT rather than INTEGER_CST. gimple_add_tmp_var should probably not add a safelen of 1 for SVE vectors, but that's really a separate thing and might be hard to test. Co-authored-by: Tejas Belagod gcc/ PR middle-end/101018 * poly-int.h (can_and_p): New function. * fold-const.cc (poly_int_binop): Use it to optimize BIT_AND_EXPRs involving POLY_INT_CSTs. * gimplify.cc (omp_notice_variable): Use poly_int_tree_p instead of INTEGER_CST when checking for constant-sized omp data. (gimplify_adjust_omp_clauses_1): Likewise. (gimplify_adjust_omp_clauses): Likewise. * omp-low.cc (scan_sharing_clauses): Likewise.
[Bug tree-optimization/87901] partial DSE of memset doesn't work for other kind of stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87901
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=49872,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=79716
Last reconfirmed||2025-04-07
--- Comment #3 from Andrew Pinski ---
Note PR 79716 is about DSE for non-constant len.
The commit which added this to DSE for memset: r7-5965-g7c9560a578a061 .
Here is another testcase which shows the issue on the trunk now:
```
char z[32];
int
foo1(void)
{
char z1[17];
char z2[24];
__builtin_memset (z1, 0, 17);
__builtin_memcpy (z, z1, 17);
__builtin_memset (z2, 0, 24);
__builtin_memcpy (z+8, z2, 24);
}
```
DSE gets:
```
MEM [(char * {ref-all})&z] = {};
MEM [(char * {ref-all})&z + 8B] = {};
```
And even tries to do the triming:
Trimming statement (head = 0, tail = 9): MEM [(char *
{ref-all})&z] = {};
But does not do the triming. Let me see if I can handle that.
[Bug libstdc++/119673] MinGW-w64 GCC with win32 thread model cannot compile 'std' module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119673 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115126 Ever confirmed|0 |1 Last reconfirmed||2025-04-08 --- Comment #2 from Andrew Pinski --- gthr-posix.h was fixed in r15-3906-g6a4d1c374eed17 ; libgcc/config/i386/gthr-win32.h needs a similar fix.
[Bug libstdc++/119673] New: MinGW-w64 GCC with win32 thread model cannot compile 'std' module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119673 Bug ID: 119673 Summary: MinGW-w64 GCC with win32 thread model cannot compile 'std' module Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: c at cyano dot cn Target Milestone: --- Created attachment 61032 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61032&action=edit Full error message Failed with error: ``` error: 'bool __gnu_cxx::__is_single_threaded()' exposes TU-local entity 'int __gthread_active_p()' note: 'int __gthread_active_p()' declared with internal linkage (and many similar errors on other gthread functions...) ``` GCC is configured with: ``` Using built-in specs. COLLECT_GCC=Z:\tmp\test\mingw64-win32-15\mingw64-win32-15\bin\g++.exe COLLECT_LTO_WRAPPER=Z:/tmp/test/mingw64-win32-15/mingw64-win32-15/bin/../lib/gcc/x86_64-w64-mingw32/15/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../configure --prefix= --libexecdir=/lib --with-gcc-major-version-only --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --build=x86_64-alpine-linux-musl --disable-plugin --disable-shared --enable-static --without-pic --disable-bootstrap --enable-checking=release --enable-languages=c,c++ --disable-libmpx --disable-multilib --enable-nls --enable-threads=win32 --disable-win32-registry --without-libcc1 --with-libiconv CFLAGS=-Os CXXFLAGS=-Os LDFLAGS='-s --static' CFLAGS_FOR_TARGET=-Os CXXFLAGS_FOR_TARGET=-Os 'LDFLAGS_FOR_TARGET=-s --static' Thread model: win32 Supported LTO compression algorithms: zlib gcc version 15.0.1 20250330 (experimental) (GCC) ``` The toolchain binary avialable here: https://github.com/CyanoHao/mingw-lite/actions/runs/14321793190 (Artifact "mingw64-win32-15", "mingw64-win32-15-20250330-r0.tar.zst" in the artifact zip arcive)
[Bug middle-end/61912] Missed (partial) dead store elimination for structures on GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61912 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/87901] partial DSE of memset doesn't work for other kind of stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87901 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > + case INTEGER_CST: > + if (integer_zerop (gimple_assign_rhs1 (stmt))) > + maybe_trim_constructor_store (ref, live, stmt, true); This has a small bug, we need to check to see the the type has mode precision. Otherwise: exact_div (ref->size, BITS_PER_UNIT); Will cause a ICE since size is not an exact multiply of BITS_PER_UNIT .
[Bug c++/119674] New: defaulted assignment operator with xobj syntax is an xobj function instead of an iobj function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119674
Bug ID: 119674
Summary: defaulted assignment operator with xobj syntax is an
xobj function instead of an iobj function
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at gcc dot gnu.org
Target Milestone: ---
dcl.fct.def.default p2
An explicitly defaulted special member function F1 is allowed to differ
from the corresponding special member function F2 that would have been
implicitly declared, as follows:
(2.2) if F2 has an implicit object parameter of type “reference to C”,
F1 may be an explicit object member function whose explicit
object parameter is of (possibly different) type “reference to
C”, in which case the type of F1 would differ from the type of F2
in that the type of F1 has an additional parameter;
I am interpreting this to mean that the declaration of the function
that is defaulted does not effect the actual function that is
generated. I assume there is another passage somewhere that specifies
this more directly.
I'm not 100% sure if my interpretation is correct, but if it is our
current implementation is not.
```
struct S0 {
S0& operator=(S0 const&) = default;
};
struct S1 {
S1& operator=(this S1&, S1 const&) = default;
};
int main()
{
// well-formed, accepted
S0& (S0::* p0)(S0 const&) = &S0::operator=;
// well-formed, rejected
S1& (S1::* p1)(S1 const&) = &S1::operator=;
// ill-formed, rejected
S0& (* p2)(S0&, S0 const&) = &S0::operator=;
// ill-formed, accepted
S1& (* p3)(S1&, S1 const&) = &S1::operator=;
}
```
[Bug rtl-optimization/119672] [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119672 Andrew Pinski changed: What|Removed |Added Component|target |rtl-optimization Target||riscv Target Milestone|--- |15.0 --- Comment #1 from Andrew Pinski --- Most likely r15-9238-g546f28f83ceba7 which touched simplify_const_relational_operation (specifically simplify-rtx.cc:6669).
[Bug tree-optimization/119665] False positive warning about unitialized variable while compiling with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119665 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-04-07 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- (In reply to Volodymyr Babchuk from comment #2) > So, should the warning be disabled in this case? yes, I am starting to think -Wmaybe-uninitialized should not be enabled for -Og. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89723#c2 But other disagree there. Since GCC 15 is so close for release I am not going to propose a patch until after that happens but let's see what discussion comes out of it.
[Bug target/119672] New: [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119672 Bug ID: 119672 Summary: [15 regression] RISC-V: ICE during RTL pass: cse1 in as_a, at machmode.h:391 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ewlu at rivosinc dot com Target Milestone: --- Created attachment 61031 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61031&action=edit freport-bug manually reduced output Postcommit is seeing a ton of errors for all rv32/64 newlib/linux targets. https://github.com/patrick-rivos/gcc-postcommit-ci/issues/2928 Example testcase ./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/ ../gcc/gcc/testsuite/gcc.dg/vect/pr113281-1.c -march=rv32gcv -mabi=ilp32d -mcmodel=medlow -fdiagnostics-plain-output -mno-vector-strict-align -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./pr113281-1.exe -freport-bug during RTL pass: cse1 ../gcc/gcc/testsuite/gcc.dg/vect/pr113281-1.c: In function 'main': ../gcc/gcc/testsuite/gcc.dg/vect/pr113281-1.c:17:1: internal compiler error: in as_a, at machmode.h:391 0x30cf076 internal_error(char const*, ...) ../../../gcc/gcc/diagnostic-global-context.cc:517 0xd05507 fancy_abort(char const*, int, char const*) ../../../gcc/gcc/diagnostic.cc:1749 0xb8cc0b scalar_int_mode as_a(machine_mode) ../../../gcc/gcc/machmode.h:391 0x140fc08 scalar_mode as_a(machine_mode) ../../../gcc/gcc/rtl.h:2328 0x140fc08 wi::int_traits >::get_precision(std::pair const&) ../../../gcc/gcc/rtl.h:2297 0x140fc08 unsigned int wi::get_precision >(std::pair const&) ../../../gcc/gcc/wide-int.h:2168 0x140fc08 wide_int_ref_storage::wide_int_ref_storage >(std::pair const&) ../../../gcc/gcc/wide-int.h:1089 0x140fc08 generic_wide_int >::generic_wide_int >(std::pair const&) ../../../gcc/gcc/wide-int.h:847 0x140fc08 poly_int<2u, generic_wide_int > >::poly_int>(poly_int_hungry, std::pair const&) ../../../gcc/gcc/poly-int.h:464 0x140fc08 poly_int<2u, generic_wide_int > >::poly_int >(std::pair const&) ../../../gcc/gcc/poly-int.h:457 0x140fc08 wi::to_poly_wide(rtx_def const*, machine_mode) ../../../gcc/gcc/rtl.h:2397 0x143c9dd neg_poly_int_rtx ../../../gcc/gcc/simplify-rtx.cc:57 0x14467ed simplify_context::simplify_binary_operation_1(rtx_code, machine_mode, rtx_def*, rtx_def*, rtx_def*, rtx_def*) ../../../gcc/gcc/simplify-rtx.cc:3416 0x1449025 simplify_context::simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) ../../../gcc/gcc/simplify-rtx.cc:2756 0x1450474 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) ../../../gcc/gcc/rtl.h:3508 0x1450474 simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) ../../../gcc/gcc/simplify-rtx.cc:6669 0x144a9be simplify_context::simplify_relational_operation(rtx_code, machine_mode, machine_mode, rtx_def*, rtx_def*) ../../../gcc/gcc/simplify-rtx.cc:6199 0x1449b04 simplify_context::simplify_gen_relational(rtx_code, machine_mode, machine_mode, rtx_def*, rtx_def*) ../../../gcc/gcc/simplify-rtx.cc:393 0x1449b04 simplify_context::simplify_relational_operation_1(rtx_code, machine_mode, machine_mode, rtx_def*, rtx_def*) ../../../gcc/gcc/simplify-rtx.cc:6467 0x2d92e18 simplify_relational_operation(rtx_code, machine_mode, machine_mode, rtx_def*, rtx_def*) ../../../gcc/gcc/rtl.h:3523
[Bug tree-optimization/119655] Copy prop STRING_CST into memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119655
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=36602
--- Comment #4 from Andrew Pinski ---
So I am starting to think:
"In theory we could always use a char[len] type
but that only gains us that the destination and source possibly
no longer will have their address taken."
We should do that anyways. For the same reason why we should convert memset to
`= {}` .
We don't know right away if using `char[len]` might not cause their address
taken but later on with propagation and other improvements it might be easier
to deal with only one form too.
[Bug libstdc++/116440] [14/15 Regression] [C++20] std::tuple> does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116440 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:5cdf31f08074d5ed8d07e93390de573938ad1eb3 commit r14-11536-g5cdf31f08074d5ed8d07e93390de573938ad1eb3 Author: Patrick Palka Date: Thu Mar 13 19:55:00 2025 -0400 libstdc++: Work around C++20 tuple> constraint recursion [PR116440] The type tuple> is clearly copy/move constructible, but for reasons that are not yet completely understood checking this triggers constraint recursion with our C++20 tuple implementation (but not the C++17 implementation). It turns out this recursion stems from considering the non-template tuple(const _Elements&) constructor during the copy/move constructibility check. Considering this constructor is ultimately redundant, since the defaulted copy/move constructors are better matches. GCC has a non-standard "perfect candidate" optimization[1] that causes overload resolution to shortcut considering template candidates if we find a (non-template) perfect candidate. So to work around this issue (and as a general compile-time optimization) this patch turns the problematic constructor into a template so that GCC doesn't consider it when checking for copy/move constructibility of this tuple type. Changing the template-ness of a constructor can affect overload resolution (since template-ness is a tiebreaker) so there's a risk this change could e.g. introduce overload resolution ambiguities. But the original C++17 implementation has long defined this constructor as a template (in order to constrain it etc), so doing the same thing in the C++20 mode should naturally be quite safe. The testcase still fails with Clang (in C++20 mode) since it doesn't implement said optimization. [1]: See r11-7287-g187d0d5871b1fa and https://isocpp.org/files/papers/P3606R0.html PR libstdc++/116440 libstdc++-v3/ChangeLog: * include/std/tuple (tuple::tuple(const _Elements&...)) [C++20]: Turn into a template. * testsuite/20_util/tuple/116440.C: New test. Reviewed-by: Jonathan Wakely (cherry picked from commit 6570fa6f2612a4e4ddd2fcfc119369a1a48656e4)
[Bug tree-optimization/119665] False positive warning about unitialized variable while compiling with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119665 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78394, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89723 Component|c |tree-optimization --- Comment #1 from Andrew Pinski --- So -Og runs a different optimization pipeline than the other optimization levels do. It does not do any jump threading nor other optimizations which will confuse debugging and in this case to see if the desc is uninitialized an optimization that is not done by -Og is needed.
[Bug tree-optimization/87901] partial DSE of memset doesn't work for other kind of stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87901
--- Comment #4 from Andrew Pinski ---
The problem is simple.
```
/* We want &lhs for the MEM_REF expression. */
tree lhs_addr = build_fold_addr_expr (gimple_assign_lhs (stmt));
if (! is_gimple_min_invariant (lhs_addr))
return;
```
We just need a STRIP_USELESS_TYPE_CONVERSION there; At least is what is needed
for the testcase in comment #3 which I think is enough for PR 36602 really.
We get this now:
```
MEM [(char * {ref-all})&z] = {};
MEM [(char * {ref-all})&z + 8B] = {};
```
For the testcase in comment 2, it is harder and not currently handled and I am
not sure it should be here; store merging handles it otherwise.
Note for s/17/16/ we still fail; I will handle that afterwards.
[Bug tree-optimization/114797] Missed optimization : fail to merge memset with unrelated clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114797 --- Comment #4 from Andrew Pinski --- (In reply to XChy from comment #2) > It looks like for completely overlapped memset, it's merged: > https://godbolt.org/z/4r7Eqr1Ee > With clobber, that's not the case: https://godbolt.org/z/8jhaEbKqo Also I think we have an escability issue too.
[Bug tree-optimization/49872] Missed optimization: Could coalesce neighboring memsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49872
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=36602
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #5 from Andrew Pinski ---
I am going to handle this since I have seen this in other places.
Note we also need to handle:
```
MEM [(char * {ref-all})&z] = 0;
MEM [(char * {ref-all})&z + 8B] = {};
```
Which can show up via:
```
char z[32];
void
foo1(void)
{
char z1[8];
char z2[24];
__builtin_memset (z1, 0, 8);
__builtin_memcpy (z, z1, 8);
__builtin_memset (z2, 0, 24);
__builtin_memcpy (z+8, z2, 24);
}
```
Or after PR 36602 is handled.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 Sam James changed: What|Removed |Added Status|REOPENED|ASSIGNED Priority|P3 |P1
[Bug bootstrap/119663] Can't build GCC on aarch64-apple-darwin24.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119663 --- Comment #1 from mcccs at gmx dot com --- version: trunk
[Bug target/119663] Can't build GCC on aarch64-apple-darwin24.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119663 --- Comment #2 from mcccs at gmx dot com --- Right, latest macOS 15.4 which is darwin24.4.0 neither works
[Bug cobol/119211] [15 Regression] Cobol GCC 15 release checklist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211 Bug 119211 depends on bug 119227, which changed state. Bug 119227 Summary: Does the generated HTML for cobol get installed to the website? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119227 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398 --- Comment #29 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:4d7a634f6d41029811cdcbd5f7282b5b07890094 commit r15-9239-g4d7a634f6d41029811cdcbd5f7282b5b07890094 Author: Richard Sandiford Date: Mon Apr 7 08:03:47 2025 +0100 combine: Allow 2->2 combinations, but with a tweak [PR116398] One of the problems in PR101523 was that, after each successful 2->2 combination attempt, try_combine would restart combination attempts at i2 even if i2 hadn't changed. This led to quadratic behaviour as the same failed combinations between i2 and i3 were tried repeatedly. The original patch for the PR dealt with that by disallowing 2->2 combinations. However, that led to various optimisation regressions, so there was interest in allowing the combinations again, at least until an alternative way of getting the same results is in place. This patch is a variant of Richi's in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523#c53 but limited to when we're combining 2 instructions. This speeds up combine by 10x on the original PR101523 testcase and reduces combine's memory footprint by 100x. gcc/ PR testsuite/116398 * combine.cc (try_combine): Reallow 2->2 combinations. Detect when only i3 has changed and restart from i3 in that case. gcc/testsuite/ * gcc.target/aarch64/popcnt-le-1.c: Account for commutativity of TST. * gcc.target/aarch64/popcnt-le-3.c: Likewise AND. * gcc.target/aarch64/pr100056.c: Revert previous patch. * gcc.target/aarch64/sve/pred-not-gen-1.c: Likewise. * gcc.target/aarch64/sve/pred-not-gen-4.c: Likewise. * gcc.target/aarch64/sve/var_stride_2.c: Likewise. * gcc.target/aarch64/sve/var_stride_4.c: Likewise. Co-authored-by: Richard Biener
[Bug target/119556] gcc.target/arm/short-vfp-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119556 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:2a155fab5a015ed4500474bab9b6ce0c4bd6c52e commit r15-9247-g2a155fab5a015ed4500474bab9b6ce0c4bd6c52e Author: Christophe Lyon Date: Thu Apr 3 18:45:51 2025 + testsuite: arm: Tighten compile options for short-vfp-1.c [PR119556] The previous version of this test required arch v6+ (for sxth), and the number of vmov depended on the float-point ABI (where softfp needed more of them to transfer floating-point values to and from general registers). With this patch we require arch v7-a, vfp FPU and -mfloat-abi=hard, we also use -O2 to clean the generated code and convert scan-assembler-times directives into check-function-bodies. Tested on arm-none-linux-gnueabihf and several flavours of arm-none-eabi. gcc/testsuite/ChangeLog: PR target/119556 * gcc.target/arm/short-vfp-1.c: Improve dg directives.
[Bug target/119408] LoongArch: Q Suffix for __float128 Literals Not Supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119408 --- Comment #28 from GCC Commits --- The master branch has been updated by LuluCheng : https://gcc.gnu.org/g:1534f0099c98ea14c08a401302b05edf2231f411 commit r15-9245-g1534f0099c98ea14c08a401302b05edf2231f411 Author: Lulu Cheng Date: Mon Apr 7 10:00:27 2025 +0800 LoongArch: Add LoongArch architecture detection to __float128 support in libgfortran and libquadmath [PR119408]. In GCC14, LoongArch added __float128 as an alias for _Float128. In commit r15-8962, support for q/Q suffixes for 128-bit floating point numbers. This will cause the compiler to automatically link libquadmath when compiling Fortran programs. But on LoongArch `long double` is IEEE quad, so there is no need to implement libquadmath. This causes link failure. PR target/119408 libgfortran/ChangeLog: * acinclude.m4: When checking for __float128 support, determine whether the current architecture is LoongArch. If so, return false. * configure: Regenerate. libquadmath/ChangeLog: * configure.ac: When checking for __float128 support, determine whether the current architecture is LoongArch. If so, return false. * configure: Regenerate. Sigend-off-by: Xi Ruoyao Sigend-off-by: Jakub Jelinek
[Bug tree-optimization/119640] [15 regression] ICE: verify_ssa failed error compiling gem5 since r15-3509-gd34cda72098867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119640 --- Comment #4 from Richard Biener --- The issue is we have an invariant shift, 1<
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 Martin Jambor changed: What|Removed |Added Assignee|jakub at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #21 from Martin Jambor --- I'll look at implementing the required IPA-VR streaming for return values this Friday.
[Bug c++/117849] constraint variable in requires expression rejected, but P2280R4 made it valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117849
Barry Revzin changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Comment #12 from Barry Revzin ---
I'm not sure this is quite right yet. This is on gcc trunk on compiler explorer
right now, which is g++
(Compiler-Explorer-Build-gcc-8fbe7d24373556d40886c7c00e9e2be5d9718c55-binutils-2.42)
15.0.1 20250407 (experimental):
template
struct Array {
constexpr int size() const { return N; }
};
struct A {
Array a;
void f() {
static_assert(a.size() == 4); // ok
}
};
struct B {
Array* p;
void f() {
static_assert(p->size() == 4); // error (expected)
}
};
struct C {
Array& r;
void f() {
static_assert(r.size() == 4); // error (unexpected?)
}
};
struct D {
Array& r;
void f() {
Array& local = r;
static_assert(local.size() == 4); // error (unexpected?)
}
};
The A case works as expected, and the B case fails as expected (we didn't add
pointers to unknown, just references to unknown). But the C and D cases both
fail, and I would have expected them to succeed.
[Bug libstdc++/119645] GCN, nvptx: libstdc++ 'checking for atomic builtins [...]... no'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119645
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:059b5509c14904b55c37f659170240ae0d2c1c8e
commit r15-9256-g059b5509c14904b55c37f659170240ae0d2c1c8e
Author: Thomas Schwinge
Date: Sat Apr 5 23:11:23 2025 +0200
GCN, nvptx libstdc++: Force use of '__atomic' builtins [PR119645]
For both GCN, nvptx, this gets rid of 'configure'-time:
configure: WARNING: No native atomic operations are provided for this
platform.
configure: WARNING: They will be faked using a mutex.
configure: WARNING: Performance of certain classes will degrade as a
result.
..., and changes:
-checking for lock policy for shared_ptr reference counts... mutex
+checking for lock policy for shared_ptr reference counts... atomic
That means, '[...]/[target]/libstdc++-v3/', 'Makefile's change:
-ATOMICITY_SRCDIR = config/cpu/generic/atomicity_mutex
+ATOMICITY_SRCDIR = config/cpu/generic/atomicity_builtins
..., and '[...]/[target]/libstdc++-v3/config.h' changes:
/* Defined if shared_ptr reference counting should use atomic
operations. */
-/* #undef HAVE_ATOMIC_LOCK_POLICY */
+#define HAVE_ATOMIC_LOCK_POLICY 1
/* Define if the compiler supports C++11 atomics. */
-/* #undef _GLIBCXX_ATOMIC_BUILTINS */
+#define _GLIBCXX_ATOMIC_BUILTINS 1
..., and '[...]/[target]/libstdc++-v3/include/[target]/bits/c++config.h'
changes:
/* Defined if shared_ptr reference counting should use atomic
operations. */
-/* #undef _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY */
+#define _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY 1
/* Define if the compiler supports C++11 atomics. */
-/* #undef _GLIBCXX_ATOMIC_BUILTINS */
+#define _GLIBCXX_ATOMIC_BUILTINS 1
This means that '[...]/[target]/libstdc++-v3/libsupc++/atomicity.cc',
'[...]/[target]/libstdc++-v3/libsupc++/atomicity.o' then uses atomic
instructions for synchronization instead of C++ static local variables,
which
in turn for their guard variables, via 'libstdc++-v3/libsupc++/guard.cc',
used
'libgcc/gthr.h' recursive mutexes, which currently are unsupported for GCN.
For GCN, this turns ~500 libstdc++ execution test FAILs into PASSes, and
also
progresses:
PASS: g++.dg/tree-ssa/pr20458.C -std=gnu++17 (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/tree-ssa/pr20458.C -std=gnu++17 execution
test
PASS: g++.dg/tree-ssa/pr20458.C -std=gnu++26 (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/tree-ssa/pr20458.C -std=gnu++26 execution
test
UNSUPPORTED: g++.dg/tree-ssa/pr20458.C -std=gnu++98: exception
handling not supported
(For nvptx, there is no effective change, due to other misconfiguration.)
PR target/119645
libstdc++-v3/
* acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY) [GCN, nvptx]:
Hard-code results.
* configure: Regenerate.
* configure.host [GCN, nvptx] (atomicity_dir): Set to
'cpu/generic/atomicity_builtins'.
[Bug libstdc++/112490] infinite meta error in reverse_iterator::iterator>> (LWG 4218)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=115046
--- Comment #15 from Patrick Palka ---
(In reply to Patrick Palka from comment #10)
> Thanks for testing. The commit that was just pushed uses a slightly
> different approach to work around the constraint recursion that should be
> better overall. Fixed on trunk so far.
>
> (In reply to Chameleon from comment #8)
> > No, it is partially fixed.
> >
> > Please patch also this:
> >
> > template<__detail::__not_a_const_iterator _Sent,
> > same_as _Self>
> > requires sized_sentinel_for<_Sent, _It>
> > friend constexpr difference_type
> > operator-(const _Sent& __x, const _Self& __y)
> > noexcept(noexcept(__x - __y._M_current))
> > { return __x - __y._M_current; }
> Hmm, I considered adjusting this friend operator- too but I couldn't come up
> with a testcase that currently misbehaves. Do you have a testcase? The
> operator-'s sized_sentinel_for constraint doesn't seem as potentially loopy
> as the relops' totally_ordered_with constraint.
Patching this friend operator- fixes the constraint recursion reported in
PR115046!
[Bug libstdc++/115046] meta-recursion when apply join_view with as_const_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115046 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2025-04-07 --- Comment #2 from Patrick Palka --- We need to adjust the constraints on basic_const_iterator's friend operator- as in r15-7757 / LWG4218.
[Bug target/118328] Implement preserve_none for AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118328 --- Comment #22 from Diego Russo --- Another reason to have this implemented is the CPython JIT. It is a template (stencil) JIT where every micro OP is precompiled as stencil. At run time these stencils will be stitched together and patched with the next micro OP instruction. This heavily uses preserve_none (https://github.com/python/cpython/blob/main/Tools/jit/template.c#L86) and so far we can only use clang to build these stencils. It would be really great if gcc reaches feature parity with llvm so, we can start building the JIT with GCC as well.
[Bug c++/119668] New: C++20 Nested concepts with NTTP triggers ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119668
Bug ID: 119668
Summary: C++20 Nested concepts with NTTP triggers ICE
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nlebedenko at hotmail dot com
Target Milestone: ---
The following snippet triggers an ICE in GCC 13.3, and GCC 12.4, 11.4, 10.5. It
does not appear in GCC 14.1+.
See it on godbolt: https://godbolt.org/z/3GzTezb7o
```cpp
// playground.cpp
struct Struct0 {};
struct Struct1 {
Struct0 s0;
};
template
struct Struct2 {
constexpr static Struct1 s1 = s1_;
};
template
concept c0 = true; // can put any condition here
template
concept c1 = c0;
template
// concept c2 = bool(c1); // works
concept c2 = c1; // uh oh!
static_assert(c2>);
```
Console printout (GCC 13.3):
```
# gcc -std=c++20 -freport-bug playground.cpp
playground.cpp:22:47: internal compiler error: in lvalue_kind, at
cp/tree.cc:223
22 | static_assert(c2>);
| ^
0x1153292 internal_error(char const*, ...)
???:0
0x1147921 fancy_abort(char const*, int, char const*)
???:0
0x1347298 lvalue_kind(tree_node const*)
???:0
0x13472c2 lvalue_kind(tree_node const*)
???:0
0x1439bff coerce_template_parms(tree_node*, tree_node*, tree_node*, int, bool)
???:0
0xbe96be evaluate_concept_check(tree_node*)
???:0
0x13594fa maybe_constant_value(tree_node*, tree_node*, mce_value)
???:0
0x184e6f7 finish_static_assert(tree_node*, tree_node*, unsigned int, bool,
bool)
???:0
0x17c8209 c_parse_file()
???:0
0x17ae67c c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug middle-end/119662] New: [OpenMP] Unhelpful debug line location for append_args call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119662
Bug ID: 119662
Summary: [OpenMP] Unhelpful debug line location for append_args
call
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: openmp, wrong-debug
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: sandra at gcc dot gnu.org
Target Milestone: ---
Assume:
66is_targetsync = 0;
67#pragma omp dispatch
68 i = f0_1_tg ();
Currently:
hit Breakpoint 3, check_f0 () at testsuite/libgomp.c/append-args-fr-1.c:66
66is_targetsync = 0;
(gdb) s
GOMP_interop (device_num=-5, n_init=1, [...]
5357{
Expected:
the call to GOMP_interop is associated with the '#pragma omp dispatch' line
(could be any item in that line there).
such that a 'step' to that line is possible (i.e. executing the previous line +
stopping) and one can see what is happening.
I have not checked, but 'adjust_args' might have the same issue.
[Bug tree-optimization/119640] [15 regression] ICE: verify_ssa failed error compiling gem5 since r15-3509-gd34cda72098867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119640 --- Comment #5 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a4abf0fb902816a2508dda5956f407fc27821d88 commit r15-9249-ga4abf0fb902816a2508dda5956f407fc27821d88 Author: Richard Biener Date: Mon Apr 7 11:27:19 2025 +0200 tree-optimization/119640 - ICE with vectorized shift placement When the whole shift is invariant but the shift amount needs to be converted and a vector shift used we can mess up placement of vector stmts because we do not make SLP scheduling aware of the need to insert code for it. The following mitigates this by more conservative placement of such code in vectorizable_shift. PR tree-optimization/119640 * tree-vect-stmts.cc (vectorizable_shift): Always insert code for one of our SLP operands before the code for the vector shift itself. * gcc.dg/vect/pr119640.c: New testcase.
[Bug tree-optimization/119640] [15 regression] ICE: verify_ssa failed error compiling gem5 since r15-3509-gd34cda72098867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119640 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed. I'll note the issue is latent for a "true SLP" shift.
[Bug bootstrap/119663] New: Can't build GCC on aarch64-apple-darwin24.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119663 Bug ID: 119663 Summary: Can't build GCC on aarch64-apple-darwin24.3.0 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mcccs at gmx dot com Target Milestone: --- On macos 15.3.1 (I'll make another comment down if 15.4 is no different), where uname -r says 24.3.0 configure says: *** Configuration aarch64-apple-darwin24.3.0 not supported configuring with ./configure --with-gmp=/opt/homebrew/Cellar/gmp/6.3.0 --with-mpfr=/opt/homebrew/Cellar/mpfr/4.2.2 --with-mpc=/opt/homebrew/Cellar/libmpc/1.3.1
[Bug c++/119666] Incorrect constant propagation of 'const' variable with [[gnu::weak]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119666
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #3 from Richard Biener ---
The reporter thinks this is wrong-code.
The C frontend rejects an extern const initialized object but handles the
following not to the reporters expectations, optimizing it to return 4
(GCC 7 worked):
const int __attribute__((weak)) x = 4;
int foo() { return x; }
I think a weak definition should only be replaceable with a semantically
equivalent strong definition. Note I think we have testcases that verify
we do not inline weak function definitions.
[Bug c++/119666] Incorrect constant propagation of 'const' variable with [[gnu::weak]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119666 --- Comment #4 from Jakub Jelinek --- In C const is something significantly different. In C++ I think we also constant evaluate weak constexpr functions, etc.
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #17 from Sergey Fedorov --- (In reply to Iain Sandoe from comment #16) > Correct, the patch for this was not finished. Let me see if I can dig it > out and refresh to trunk. Thank you, would be very helpful. P. S. For the context, I thought that it will be easier for me to fix some problematic ports (mostly Qt-related) for powerpc if I can first fix them for gcc/libstdc++ on x86 on not-too-old macOS. And ran into all kind of breakages :)
[Bug c/119651] [13/14/15 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nonzero_bits, at fold-const.cc:16702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119651 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I wonder whether for such redeclarations it wouldn't be better to keep TREE_TYPE of the VAR_DECL as it was on the older decl, rather than setting it to error_mark_node. The middle-end is unprepared to see NOP_EXPRs or arithmetics with such VAR_DECLs.
[Bug lto/119625] lto1: fatal error: open failed: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119625 --- Comment #5 from Jakub Jelinek --- Confirmed this fixed the weird LTO lto1: fatal error: open failed: No such file or directory errors.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #23 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e7c3a7ccd6209c1a906bdf59207f0fa4258b692b
commit r15-9246-ge7c3a7ccd6209c1a906bdf59207f0fa4258b692b
Author: Jakub Jelinek
Date: Mon Apr 7 11:57:36 2025 +0200
tailc: Extend the IPA-VRP workaround [PR119614]
The IPA-VRP workaround in the tailc/musttail passes was just comparing
the singleton constant from a tail call candidate return with the ret_val.
This unfortunately doesn't work in the following testcase, where we have
[local count: 152205050]:
baz (); [must tail call]
goto ; [100.00%]
[local count: 762356696]:
_8 = foo ();
[local count: 1073741824]:
# _3 = PHI <0B(4), _8(6)>
return _3;
and in the unreduced testcase even more PHIs before we reach the return
stmt.
Normally when the call has lhs, whenever we follow a (non-EH) successor
edge, it calls propagate_through_phis and that walks the PHIs in the
destination bb of the edge and when it sees a PHI whose argument matches
that of the currently tracked value (ass_var), it updates ass_var to
PHI result of that PHI. I think it is theoretically dangerous that it
picks the first one, perhaps there could be multiple PHIs, so perhaps safer
would be walk backwards from the return value up to the call.
Anyway, this PR is about the IPA-VRP workaround, there ass_var is NULL
because the potential tail call has no lhs, but ret_var is not
TREE_CONSTANT
but SSA_NAME with PHI as SSA_NAME_DEF_STMT. The following patch handles
it by pushing the edges we've walked through when ass_var is NULL into a
vector and if ret_var is SSA_NAME set to PHI result, it attempts to walk
back from the ret_var through arguments of PHIs corresponding to the
edges we've walked back until we reach a constant and compare that constant
against the singleton value as well.
2025-04-07 Jakub Jelinek
PR tree-optimization/119614
* tree-tailcall.cc (find_tail_calls): Remember edges which have
been
walked through if !ass_var. Perform IPA-VRP workaround even when
ret_var is not TREE_CONSTANT, in that case check in a loop if it is
a PHI result and in that case look at the PHI argument from
corresponding edge in the edge vector.
* g++.dg/opt/pr119613.C: Change { c || c++11 } in obviously C++
only
test to just c++11.
* g++.dg/opt/pr119614.C: New test.
[Bug target/119663] Can't build GCC on aarch64-apple-darwin24.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119663 --- Comment #3 from mcccs at gmx dot com --- *typo: configure does succeed, it is from `make` that: *** Configuration aarch64-apple-darwin24.4.0 not supported
[Bug middle-end/119662] [OpenMP] Wrong-code for 'omp dispatch' with append_args clause and unhelpful debug line location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119662
Tobias Burnus changed:
What|Removed |Added
Summary|[OpenMP] Unhelpful debug|[OpenMP] Wrong-code for
|line location for |'omp dispatch' with
|append_args call|append_args clause and
||unhelpful debug line
||location
Keywords||wrong-code
--- Comment #1 from Tobias Burnus ---
-fdump-tree-optimized-lineno:
[testsuite/libgomp.c/append-args-fr-1.c:66:21] is_targetsync = 0;
interopobjs.56[0] = &interop.58;
tgt_tgtsync.57[0] = 1;
GOMP_interop (-5, 1, interopobjs.56, tgt_tgtsync.57, 0B, 0, 0B, 0, 0B, 0,
0B);
[testsuite/libgomp.c/append-args-fr-1.c:68:13] interop.60_58 = interop.58;
[testsuite/libgomp.c/append-args-fr-1.c:68:13] cleanuptmp.59_60 = f0_1_tg_
(interop.60_58);
[testsuite/libgomp.c/append-args-fr-1.c:68:9 discrim 1] GOMP_interop (-5, 0,
0B, 0B, 0B, 0, 0B, 1, interopobjs.56, 0, 0B);
[testsuite/libgomp.c/append-args-fr-1.c:68:9 discrim 2] interop.58 ={v}
{CLOBBER(eob)};
[testsuite/libgomp.c/append-args-fr-1.c:68:11 discrim 2] i_63 =
cleanuptmp.59_60;
[testsuite/libgomp.c/append-args-fr-1.c:69:7] if (i_63 == 4242)
* * *
WRONG CODE ISSUE:
The original issue leading me to find the debugger issue is a crash at runtime.
The problem is a missing '&' before 'interopobjs' in:
GOMP_interop (-5, 1, interopobjs.56, tgt_tgtsync.57, 0B, 0, 0B, 0, 0B, 0,
0B);
GOMP_interop (-5, 0, 0B, 0B, 0B, 0, 0B, 1, interopobjs.56, 0, 0B);
I keep getting confused whether the '&' is technically required or not, but
#pragma omp interop init(target: myobj)
successfully uses
interopobjs.88[0] = &myobj;
tgt_tgtsync.89[0] = 1;
GOMP_interop (-5, 1, &interopobjs.88, &tgt_tgtsync.89, 0B, 0, 0B, 0, 0B, 0,
0B);
* * *
I think the problem is the following (at least on x86-64-gnu-linux).
Assume 'omp_interop_t interopobjs[2]'.
Without '&', I think a 2*sizeof(omp_interop_t) = 2*sizeof(void *) object is
passed on the stack (by value).
But we want to pass the address of the 'interopobjs' array - which is
sizeof(void*).
[Bug tree-optimization/118924] [12/13/14/15 regression] Wrong code at -O2 and above leading to uninitialized accesses on aarch64-linux-gnu since r10-917-g3b47da42de621c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924 --- Comment #19 from GCC Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:07d243670020b339380194f6125cde87ada56148 commit r15-9250-g07d243670020b339380194f6125cde87ada56148 Author: Martin Jambor Date: Mon Apr 7 13:32:09 2025 +0200 sra: Avoid creating TBAA hazards (PR118924) The testcase in PR 118924, when compiled on Aarch64, contains an gimple aggregate assignment statement in between different types which are types_compatible_p but behave differently for the purposes of alias analysis. SRA replaces the statement with a series of scalar assignments which however have LHSs access chains modeled on the RHS type and so do not alias with a subsequent reads and so are DSEd. SRA clearly gets its "same_access_path" logic subtly wrong. One issue is that the same_access_path_p function probably should be implemented more along the lines of (parts of ao_compare::compare_ao_refs) instead of internally relying on operand_equal_p. That is however not the problem in the PR and so I will deal with it only later. The issue here is that even when the access path is the same, it must not be bolted on an aggregate type that does not match. This patch does that, taking just one simple function from the ao_compare::compare_ao_refs machinery and using it to detect the situation. The rest is just merging the information in between accesses of the same access group. I looked at how many times we come across such assignment during "make stage2-bubble" of GCC (configured with only c and C++ and without multilib and libsanitizers) and on an x86_64 there were 87924 such assignments (though now I realize not all of them had to be aggregate), so they do happen. The patch leads to about 5% increase of cases where we don't use an "access path" but resort to a MEM_REF (from 90209 to 95204). On an Aarch64, there were 92268 such assignments and the increase of falling back to MEM_REFs was by 4% (but from a bigger base 132983 to 107991). gcc/ChangeLog: 2025-04-04 Martin Jambor PR tree-optimization/118924 * tree-ssa-alias-compare.h (types_equal_for_same_type_for_tbaa_p): Declare. * tree-ssa-alias.cc: Include ipa-utils.h. (types_equal_for_same_type_for_tbaa_p): New public overloaded variant. * tree-sra.cc: Include tree-ssa-alias-compare.h. (create_access): Initialzie grp_same_access_path to true. (build_accesses_from_assign): Detect tbaa hazards and clear grp_same_access_path fields of involved accesses when they occur. (sort_and_splice_var_accesses): Take previous values of grp_same_access_path into account. gcc/testsuite/ChangeLog: 2025-03-25 Martin Jambor PR tree-optimization/118924 * g++.dg/tree-ssa/pr118924.C: New test.
[Bug tree-optimization/118924] [12/13/14/15 regression] Wrong code at -O2 and above leading to uninitialized accesses on aarch64-linux-gnu since r10-917-g3b47da42de621c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924 --- Comment #20 from GCC Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:40445711b8af113ef423d8bcac1a7ce1c47f62d7 commit r15-9251-g40445711b8af113ef423d8bcac1a7ce1c47f62d7 Author: Martin Jambor Date: Mon Apr 7 13:32:10 2025 +0200 sra: Clear grp_same_access_path of acesses created by total scalarization (PR118924) During analysis of PR 118924 it was discussed that total scalarization invents access paths (strings of COMPONENT_REFs and possibly even ARRAY_REFs) which did not exist in the program before which can have unintended effects on subsequent AA queries. Although not doing that does not mean that SRA cannot create such situations (see the bug for more info), it has been agreed that not doing this is generally better. This patch therfore makes SRA fall back on creating simple MEM_REFs when accessing components of an aggregate corresponding to what a SRA variable now represents. gcc/ChangeLog: 2025-03-26 Martin Jambor PR tree-optimization/118924 * tree-sra.cc (create_total_scalarization_access): Set grp_same_access_path flag to zero.
[Bug target/119663] Can't build GCC on aarch64-apple-darwin24.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119663 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Yes support is not upstream yet. *** This bug has been marked as a duplicate of bug 96168 ***
[Bug libstdc++/119667] New: libstdc++ configure checks for libbacktrace need atomics for void* and size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119667 Bug ID: 119667 Summary: libstdc++ configure checks for libbacktrace need atomics for void* and size_t Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- GLIBCXX_ENABLE_BACKTRACE in acinclude.m4 says: # libbacktrace only needs atomics for int, which we've already tested if test "$glibcxx_cv_atomic_int" = "yes"; then BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS -DHAVE_ATOMIC_FUNCTIONS=1" fi I based that comment on the checks in libbacktrace/configure.ac which only checks __atomic_xxx builtins for int, presumably because it's only checking if the compiler is new enough to support __atomic_ builtins at all. But for libstdc++ we actually care about whether the builtins are supported natively, and we don't want to use them if they're relying on libatomic. So we should be checking for __atomic builtins being expanded to native instructions, rather than an extern call to a libatomic symbol. libbacktrace needs these operations: extern void *backtrace_atomic_load_pointer (void *); extern int backtrace_atomic_load_int (int *); extern void backtrace_atomic_store_pointer (void *, void *); extern void backtrace_atomic_store_size_t (size_t *, size_t); extern void backtrace_atomic_store_int (int *, int); so we should check for load+store on int, size_t and void*.
[Bug middle-end/119662] [OpenMP] Wrong-code for 'omp dispatch' with append_args clause and unhelpful debug line location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119662
--- Comment #2 from Tobias Burnus ---
For 'adjust_args':
void f0(int *);
#pragma omp declare variant(f0) match(construct={dispatch}) \
adjust_args(need_device_ptr: x)
void f(int *x);
void g(int *a, int dev) {
#pragma omp dispatch device(dev)
f(a);
}
This becomes the following - which seems to be okay-ish. However,
(1) It would be presumably good to also add location data to omp_*_device calls
(2) I am not sure whether it makes more sense to have the location in in the
call line (here: line 8) – or in the '#pragma' line (line 7).
Regarding (2):
* In the latter case, it would first step to '#pragma' to do
adjust_args/append_args/device setting; then, second step, executing the
function call, and then as third step, move the source line back to the pragma
line and do the clean up.
* In the former case, one step would do all the library calls, function call
and cleanup in one debugger step.
void g (int * a, int dev)
[f.c:6:25] {
[f.c:7:11] #pragma omp dispatch
{
{
int D.2982;
void * D.2983;
D.2982 = __builtin_omp_get_default_device ();
__builtin_omp_set_default_device (dev);
[f.c:8:5] D.2983 = __builtin_omp_get_mapped_ptr (a, dev);
[f.c:8:5] f0 (D.2983);
__builtin_omp_set_default_device (D.2982);
}
}
}
[Bug c++/119666] Incorrect constant propagation of 'const' variable with [[gnu::weak]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119666 --- Comment #2 from Artem Labazov <123321artyom at gmail dot com> --- (In reply to Jakub Jelinek from comment #1) > I think the GCC behavior is correct here, in C++ const has special meaning > and even attribute like weak shouldn't change that. Perhaps, a more idiomatic C++ code that fulfills my needs would be const int my_number [[gnu::weak]] = 4; This code should be ODR-safe, but it is rejected by GCC due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83271 Still, if the current behaviour of extern const weak symbols is considered correct, in that case the weak attribute neither bears any semantics nor is rejected by the compiler.
[Bug fortran/119669] New: [15 Regression] ICE in compare_parameter since r15-7449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119669 Bug ID: 119669 Summary: [15 Regression] ICE in compare_parameter since r15-7449 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- Since r15-7449-ga8d0a2dd6565ea15ce79d8af90f2671cbf9359c7 the following testcase ICEs cat rh2357847.f90 program a implicit real(a-h,o-z) external abstract_caller, caller, func ! real func call abstract_caller (caller, func, 1.5) call abstract_caller (caller, func, 1.5) end function func (x) real func, x func = x * x - 1. end ./f951.r15-7449 -quiet rh2357847.f90 f951.r15-7449: internal compiler error: in compare_parameter, at fortran/interface.cc:2521 0x2d2466b internal_error(char const*, ...) ../../gcc/diagnostic-global-context.cc:517 0x2cf3e37 fancy_abort(char const*, int, char const*) ../../gcc/diagnostic.cc:1722 0x46df56 compare_parameter ../../gcc/fortran/interface.cc:2521
[Bug fortran/119669] [15 Regression] ICE in compare_parameter since r15-7449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119669 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |15.0 CC||tkoenig at gcc dot gnu.org
[Bug libstdc++/119670] New: [C++26] Implement P2546R5, Debugging Support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119670 Bug ID: 119670 Summary: [C++26] Implement P2546R5, Debugging Support Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 110339 Target Milestone: --- https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2546r5.html Also https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2810r4.html Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339 [Bug 110339] Implement C++26 library features
[Bug c++/119666] Incorrect constant propagation of 'const' variable with [[gnu::weak]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119666 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 36685 ***
[Bug c++/36685] clarify/diagnose use of weak constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36685 Andrew Pinski changed: What|Removed |Added CC||123321artyom at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 119666 has been marked as a duplicate of this bug. ***
[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364
--- Comment #11 from Jakub Jelinek ---
Incremental
--- gcc/cobol/parse.y.jj2025-04-05 22:10:21.694956723 +0200
+++ gcc/cobol/parse.y 2025-04-07 17:44:44.222152716 +0200
@@ -34,6 +34,7 @@
#include "coretypes.h"
#include "../../libgcobol/io.h"
#include "../../libgcobol/ec.h"
+ #include "tree.h"
#pragma GCC diagnostic ignored "-Wmissing-field-initializers"
@@ -4286,7 +4287,8 @@ usage_clause1: usage COMPUTATIONAL[comp
if( gcobol_feature_embiggen() && redefined &&
is_numeric(redefined->type) && redefined->size() == 4) {
// For now, we allow POINTER to expand a 32-bit item to 64
bits.
-field->data.capacity = sizeof(void *);
+field->data.capacity
+ = TREE_INT_CST_LOW (TYPE_SIZE_UNIT (ptr_type_node));
dbgmsg("%s: expanding #" HOST_SIZE_T_PRINT_UNSIGNED
" %s capacity %u => %u", __func__,
(fmt_size_t)field_index(redefined), redefined->name,
fixed the
FAIL: FUNCTION_BIGGER-POINTER__2_.out output file test
FAIL: IBM_dialect_COMP_redefined_by_POINTER_as_64-bit.out output file test
issues for i686-linux -> x86_64-linux cross and is still make check-cobol clean
on native x86_64-linux.
[Bug libstdc++/119670] [C++26] Implement P2546R5, Debugging Support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119670 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2025-04-07 Status|UNCONFIRMED |ASSIGNED
[Bug rtl-optimization/116398] [15 Regression] gcc.target/aarch64/ashltidisi.c fails since r15-268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116398 --- Comment #31 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:107a1b2126ceb42a79edbc388863c868bd4fbc2e commit r15-9241-g107a1b2126ceb42a79edbc388863c868bd4fbc2e Author: Richard Sandiford Date: Mon Apr 7 08:03:48 2025 +0100 combine: Optimise distribute_links search [PR116398] Another problem in PR101523 was that, after each successful 2->2 combination attempt, distribute_links would search further and further for the next combinable use of the i2 destination. Each search would start at i2 itself, making the search quadratic in the worst case. In a 2->2 combination, if i2 is unchanged, the search can start at i3 instead of i2. The same thing applies to i2 when distributing i2's links, since the only changes to earlier instructions are the deletion of i0 and i1. This change, combined with the previous split_i2i3 patch, gives a 34.6% speedup in combine for the testcase in PR101523. Combine goes from being 41% to 34% of compile time. gcc/ PR testsuite/116398 * combine.cc (distribute_links): Take an optional start point. (try_combine): If only i3 has changed, only distribute i3's links, not i2's. Start the search for the new use from i3 rather than from the definition instruction. Likewise start the search for the new use from i2 when distributing i2's links.
[Bug rtl-optimization/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 Sam James changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #68 from Sam James --- Not sure what the current state of this one is, now we have PR116398 fixed. I _think_ done?
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug rtl-optimization/118755] [15 Regression] ccmp_3.c fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118755 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Andrew Pinski --- Fixed by r15-9242-ga1a0026c659196 and the few before hand.
[Bug rtl-optimization/118956] [15/16 regression] gcc.target/aarch64/sve/pred-not-gen-[14].c fail after r15-268-g9dbff9c05520a74e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118956 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|16.0|15.0 Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- (In reply to Richard Sandiford from comment #4) > XFAILed for GCC 15, keeping open for the actual fix. r15-9239-g4d7a634f6d4102 unxfailed these 2 so fixed.
[Bug c/119612] [15 regression] gcc.dg/pr106465.c newly re-broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612 Sam James changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/118911] [15 Regression] bitfield-bitint-abi-align{8,16}.c fails on aarch64-linux-gnu since r15-268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118911 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed by r15-9242-ga1a0026c659196 and the few before hand.
[Bug target/118892] [14 Regression] ICE (segfault) in rebuild_jump_labels on aarch64-linux-gnu since r14-5289
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118892 --- Comment #18 from Tamar Christina --- (In reply to Pavol Rusnak from comment #17) > Is the fix going to be backported from master to 14.x release? Possibly > targeting 14.3.0 release? Yep
[Bug tree-optimization/119351] [15 Regression] Wrong code in GROMACS for AArch64 generic SVE VLS target since r15-6807-g68326d5d1a593d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351 --- Comment #13 from Tamar Christina --- Sorry had a week off, looking into this again today.
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #16 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #15) > This still does not work with gcc-14.2.0. > > ``` > :info:build In file included from > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/ > Frameworks/Security.framework/Headers/AuthSession.h:32, > :info:build from > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/ > Frameworks/Security.framework/Headers/Security.h:42, > :info:build from > /opt/local/var/macports/build/_opt_CatalinaPorts_devel_cmake-bootstrap/cmake- > bootstrap/work/cmake-3.9.6/Utilities/cmcurl/lib/urldata.h:148, > :info:build from > /opt/local/var/macports/build/_opt_CatalinaPorts_devel_cmake-bootstrap/cmake- > bootstrap/work/cmake-3.9.6/Utilities/cmcurl/lib/file.c:52: > :info:build > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/ > Frameworks/Security.framework/Headers/Authorization.h:193:7: error: variably > modified 'bytes' at file scope > :info:build 193 | char bytes[kAuthorizationExternalFormLength]; > :info:build | ^ > :info:build make[2]: *** > [Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/file.c.o] Error 1 > :info:build make[2]: *** Waiting for unfinished jobs > ``` Correct, the patch for this was not finished. Let me see if I can dig it out and refresh to trunk.
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 Iain Sandoe changed: What|Removed |Added Assignee|iains at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- the patch posted does not have all the functionality Simon suggests (but I have found it useful in my development) - anyway unassigning myself, the COBOL maintainers can decide on the errors/warnings/exceptions.
[Bug libstdc++/119642] [15 regression] diagnostic push has no effect because of unmatched pop in bits/formatfwd.h since r15-9198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119642 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/119577] RISC-V: Redundant vector IV roundtrip.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119577 --- Comment #2 from Tamar Christina --- (In reply to Richard Biener from comment #1) > IIRC it depends on the "kind" of early break whether we need the > first IV (scalar IV possible) or the last, but I don't rememeber exactly. First is always required for any early exit, it's the main exit that alternates between first and last. The main exit uses first when the exit chosen as the main one is not the same as the scalar loop. i.e. when PEELED is true, as in this case it means all exits through the vector loop is an early exit. If the loop is not an inverted/vector peeled loop, the main exit uses last.
[Bug tree-optimization/119640] [15 regression] ICE: verify_ssa failed error compiling gem5 since r15-3509-gd34cda72098867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119640 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- I will have a look.
[Bug c/119651] [13/14/15 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nonzero_bits, at fold-const.cc:16702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119651 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug preprocessor/118674] [12/13/14/15 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118674 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 61027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61027&action=edit gcc15-pr118674.patch Untested fix.
[Bug ipa/117432] [12/13 Regression] IPA ICF disregards types of variadic arguments since r10-4643-ga37f58f506e436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432 --- Comment #19 from nightstrike --- (In reply to Sam James from comment #17) > (In reply to nightstrike from comment #16) > > I think you've either made an error and tested with the wrong GCC, or it > needs its own bug. In C23, which is the default on trunk for some time, > va_start can have one argument. Opened PR119658 (In reply to Andrew Pinski from comment #18) > I am suspect this is a bug in mingw's stdarg.h which does NOT support C23 > va_start. IIRC there is a bug about mingw not using GCC's stdarg.h like it > should be but I can't find that bug report. You are exactly right.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #22 from Jakub Jelinek ---
Note, I think the IPA-VRP gathered ranges are normally propagated to
SSA_NAME_{RANGE,PTR}_INFO (for parameters of default defs of SSA_NAMEs for the
PARM_DECLs, for return values into SSA_NAME on the lhs of the calls).
This doesn't work in the tailc case because if the range is singleton like for
volatile int v;
[[gnu::noinline]] static int foo (int) { ++v; return 42; }
int bar (int x) { if (!x) return 42; [[gnu::musttail]] return foo (0); }
with -O2 -flto -flto-partition=max -shared -fpic, the call has no lhs and we
just propagate 42 to where it was used.
Unless there is some other pass that would consume this info, all the tailc
needs is to have a tree somewhere, NULL_TREE for return types with
unsupportable range, or for VARYING or anything that isn't singleton and the
particular INTEGER_CST/REAL_CST if it is singleton.
For non-LTO, ipa_return_value_range (val, callee) && val.singleton_p (&valr)
is what worked for me because nothing drops that info after IPA. But nothing
streams it out and back into LTRANS, so for LTO the info isn't available.
[Bug libstdc++/119642] [15 regression] diagnostic push has no effect because of unmatched pop in bits/formatfwd.h since r15-9198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119642 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/119647] cstdlib: error: 'aligned_alloc' has not been declared in '::'; ctime: error: 'timespec_get' has not been declared in '::'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119647 --- Comment #5 from Iain Sandoe --- this seems odd, ICU is a system component - so presumably the version released on Apple's Open Source repo should be buildable by the system. What version of ICU are you trying to build (and where from)? It would be nice to try and find some recipe that works to resolve the myriad of interacting defines - such that we can release a darwin toolchain that has the right C support for the intended C++ std revision. (bot that's not for this bug).
[Bug libstdc++/119647] cstdlib: error: 'aligned_alloc' has not been declared in '::'; ctime: error: 'timespec_get' has not been declared in '::'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119647 --- Comment #6 from Sergey Fedorov --- (In reply to Iain Sandoe from comment #5) > this seems odd, ICU is a system component - so presumably the version > released on Apple's Open Source repo should be buildable by the system. > What version of ICU are you trying to build (and where from)? 76.1 from MacPorts. I believe, this is the fix: https://github.com/unicode-org/icu/pull/3465 CI pass, but ticket on Jira should be accepted first: https://unicode-org.atlassian.net/browse/ICU-23099
[Bug target/119617] ICE: in standard_sse_constant_opcode, at config/i386/i386.cc:5465 with -fzero-call-used-regs=all -mabi=ms -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617 --- Comment #4 from Haochen Jiang --- (In reply to Hongtao Liu from comment #3) > (In reply to Hongtao Liu from comment #2) > > (In reply to Richard Biener from comment #1) > > > I think we need to disable the effect of -mno-evex512, looks like there's > > > still traces of it left? > > > > Let's have a quick fix to avoid ICE, the major clean up work is planed for > > GCC16. > > Reject mno-evex512 could be a solution. Maybe we could if the option comes in. But I am not sure if it is too aggressive for GCC 15.
[Bug c/119664] New: ICE compiling Linux with h8300-linux compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119664 Bug ID: 119664 Summary: ICE compiling Linux with h8300-linux compiler Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: wbx at openadk dot org Target Milestone: --- Created attachment 61028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61028&action=edit tcp_minisocks preprocessed Hi, now I am targeting real hardware (EDOSK 2674). I get an ICE with Linux 4.4.302. See here the error message: /home/wbx/openadk/toolchain_hitachi-edosk2674_uclibc-ng_flat_nommu/usr/bin/h8300-openadk-linux-uclibc-gcc -Wp,-MD,net/ipv4/.tcp_minisocks.o.d -nostdinc -isystem /home/wbx/openadk/toolchain_hitachi-edosk2674_uclibc-ng_flat_nommu/usr/lib/gcc/h8300-openadk-linux-uclibc/15.0.1/include -I./arch/h8300/include -Iarch/h8300/include/generated/uapi -Iarch/h8300/include/generated -Iinclude -I./arch/h8300/include/uapi -Iarch/h8300/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -ms -mint32 -fno-builtin -D__linux__ -DUTS_SYSNAME=\"uClinux\" -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-int-in-bool-context -Wno-address-of-packed-member -Wno-attribute-alias -Os -fno-allow-store-data-races -DCC_HAVE_ASM_GOTO -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -Wdeclaration-after-statement -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -Wno-packed-not-aligned -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(tcp_minisocks)" -D"KBUILD_MODNAME=KBUILD_STR(tcp_minisocks)" -c -o net/ipv4/tcp_minisocks.o net/ipv4/tcp_minisocks.c net/ipv4/tcp_minisocks.c: In function 'tcp_timewait_state_process': net/ipv4/tcp_minisocks.c:262:1: error: unrecognizable insn: 262 | } | ^ (insn 758 76 759 9 (set (reg:CCZ 12 cc) (eq (zero_extract:QI (reg:QI 5 r5 [orig:130 *th_78(D)+13 ] [130]) (const_int 1 [0x1]) (const_int 2 [0x2])) (const_int 0 [0]))) "include/net/tcp.h":1306:5 -1 (nil)) during RTL pass: split2 net/ipv4/tcp_minisocks.c:262:1: internal compiler error: in extract_insn, at recog.cc:2882 0x7fc0e8327249 __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 0x7fc0e8327304 __libc_start_main_impl ../csu/libc-start.c:360 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. ./toolchain_hitachi-edosk2674_uclibc-ng_flat_nommu/usr/bin/h8300-openadk-linux-uclibc-gcc -v Using built-in specs. COLLECT_GCC=./toolchain_hitachi-edosk2674_uclibc-ng_flat_nommu/usr/bin/h8300-openadk-linux-uclibc-gcc COLLECT_LTO_WRAPPER=/home/wbx/openadk/toolchain_hitachi-edosk2674_uclibc-ng_flat_nommu/usr/libexec/gcc/h8300-openadk-linux-uclibc/15.0.1/lto-wrapper Target: h8300-openadk-linux-uclibc Configured with: /home/wbx/openadk/toolchain_build_hitachi-edosk2674_uclibc-ng_flat_nommu/w-gcc-git-1/gcc-git/configure --prefix=/home/wbx/openadk/toolchain_hitachi-edosk2674_uclibc-ng_flat_nommu/usr --with-bugurl=https://openadk.org --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=h8300-openadk-linux-uclibc --with-gmp=/home/wbx/openadk/host_x86_64-linux-gnu/usr --with-mpfr=/home/wbx/openadk/host_x86_64-linux-gnu/usr --enable-__cxa_atexit --with-system-zlib --with-gnu-ld --with-gnu-as --disable-libsanitizer --disable-install-libiberty --disable-libitm --disable-libmudflap --disable-libgomp --disable-libcc1 --disable-libmpx --disable-libcilkrts --disable-libquadmath --disable-libquadmath-support --disable-decimal-float --disable-gcov --disable-libstdcxx-pch --disable-ppl-version-check --disable-cloog-version-check --without-ppl --without-cloog --without-isl --disable-werror --disable-nls --enable-obsolete --disable-lto --disable-tls --disable-threads --disable-libatomic --disable-shared --disable-libssp --disable-biarch --disable-multilib --enable-languages=c --with-build-sysroot='/../../target_hitachi-edosk2674_uclibc-ng_flat_nommu' --with-sysroot='/../../target_hitachi-edosk2674_uclibc-ng_flat_nommu' Thread model: single Supported LTO compression algorithms: zlib zstd gcc version 15.0.1 20250407 (experimental) (GCC) thanks Waldemar
[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364
--- Comment #10 from Jakub Jelinek ---
Second bug is what I see on FUNCTION_BIGGER-POINTER__2_.cob,
if( gcobol_feature_embiggen() && redefined &&
is_numeric(redefined->type) && redefined->size() == 4) {
// For now, we allow POINTER to expand a 32-bit item to 64
bits.
field->data.capacity = sizeof(void *);
dbgmsg("%s: expanding #" HOST_SIZE_T_PRINT_UNSIGNED
" %s capacity %u => %u", __func__,
(fmt_size_t)field_index(redefined), redefined->name,
redefined->data.capacity, field->data.capacity);
redefined->embiggen();
if( redefined->data.initial ) {
auto s = xasprintf( "%s", redefined->data.initial);
std::replace(s, s + strlen(s), '!', char(0x20));
redefined->data.initial = s;
}
}
The field->data.capacity = sizeof(void *); part is definitely wrong, I think it
needs to decide based on target's pointer size, which would be
POINTER_SIZE_UNITS (or could
TREE_INT_CST_LOW (TYPE_SIZE_UNIT (ptr_type_node))).
[Bug c++/119666] Incorrect constant propagation of 'const' variable with [[gnu::weak]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119666 --- Comment #5 from Jonathan Wakely --- The language semantics require us to do that for C++ constant expressions. You can use that integer (or a constexpr function returning an integer) like this: int a[x]; std::array a2; You cannot delay evaluation of those constant expressions until runtime.
[Bug libstdc++/119642] [15 regression] diagnostic push has no effect because of unmatched pop in bits/formatfwd.h since r15-9198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119642 --- Comment #2 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3b1cf36eb47e217b6f093abd9f76ea358d456e2e commit r15-9260-g3b1cf36eb47e217b6f093abd9f76ea358d456e2e Author: Jonathan Wakely Date: Mon Apr 7 11:30:41 2025 +0100 libstdc++: Remove stray pragma in new header [PR119642] libstdc++-v3/ChangeLog: PR libstdc++/119642 * include/bits/formatfwd.h: Remove stray pragma.
[Bug target/113257] -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native works on arm64 M2 Ultra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257 --- Comment #15 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:3a77a567b1028a28ecbb2f2eadc351d8bd004352 commit r15-9261-g3a77a567b1028a28ecbb2f2eadc351d8bd004352 Author: Iain Sandoe Date: Sun Oct 15 10:19:22 2023 +0100 aarch64, Darwin: Initial implementation of Apple cores [PR113257]. After discussion with the open source support team at Apple, we have established that the cores conform to the 8.5 and 8.6 requirements. One of the mandatory features (FEAT_SPECRES) is not exposed (or available) in user-space code but is supported for privileged code. The values for chip IDs and the LITTLE.big variants have been taken from lists in the XNU and LLVM sources. PR target/113257 gcc/ChangeLog: * config/aarch64/aarch64-cores.def (AARCH64_CORE): Add Apple-a12, Apple-M1, Apple-M2, Apple-M3 with expanded names to allow for the LITTLE.big versions. * config/aarch64/aarch64-tune.md: Regenerate. * doc/invoke.texi: Add apple-m1,2 and 3 cores to the ones listed for arch and tune selections. Signed-off-by: Iain Sandoe
[Bug c++/107065] GCC treats rvalue as an lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107065 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5
[Bug libstdc++/119501] std::ranges::copy_n advances InputIterator one more time than necessary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119501 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-04-07 Status|UNCONFIRMED |ASSIGNED
[Bug c++/118629] [14 Regression] ice in cp_parser_expression_statement with __FUNCTION__ inside decltype for the trailing return type of a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:e2a178a5110db3b4c25773d386b047b27679bfe5
commit r14-11534-ge2a178a5110db3b4c25773d386b047b27679bfe5
Author: Jason Merrill
Date: Fri Apr 4 17:34:08 2025 -0400
c++: __FUNCTION__ in lambda return type [PR118629]
In this testcase, the use of __FUNCTION__ is within a function parameter
scope, the lambda's. And P1787 changed __func__ to live in the parameter
scope. But [basic.scope.pdecl] says that the point of declaration of
__func__ is immediately before {, so in the trailing return type it isn't
in
scope yet, so this __FUNCTION__ should refer to foo().
Looking first for a block scope, then a function parameter scope, gives us
the right result.
PR c++/118629
gcc/cp/ChangeLog:
* name-lookup.cc (pushdecl_outermost_localscope): Look for an
sk_block.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-__func__3.C: New test.
(cherry picked from commit 7d561820525fd3b9d8f3876333c0584d75e7c053)
[Bug c++/119652] [14/15 Regression] constinit empty direct-list-initialization incorrectly rejected since r14-660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119652 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:749221fac55059a145d3fdaf416fe663a4ee33d9 commit r14-11535-g749221fac55059a145d3fdaf416fe663a4ee33d9 Author: Jason Merrill Date: Mon Apr 7 11:49:19 2025 -0400 c++: constinit and value-initialization [PR119652] Value-initialization built an AGGR_INIT_EXPR to set AGGR_INIT_ZERO_FIRST on. Passing that AGGR_INIT_EXPR to maybe_constant_value returned a TARGET_EXPR, which potential_constant_expression_1 mistook for a temporary. We shouldn't add a TARGET_EXPR to the AGGR_INIT_EXPR in this case, just like we already avoid adding it to CONSTRUCTOR or CALL_EXPR. PR c++/119652 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_outermost_constant_expr): Also don't add a TARGET_EXPR around AGGR_INIT_EXPR. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constinit20.C: New test. (cherry picked from commit c7dc9b6f889fa8f9e4ef060c3af107eaf54265c5)
[Bug c++/119652] [14/15 Regression] constinit empty direct-list-initialization incorrectly rejected since r14-660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119652 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c7dc9b6f889fa8f9e4ef060c3af107eaf54265c5 commit r15-9262-gc7dc9b6f889fa8f9e4ef060c3af107eaf54265c5 Author: Jason Merrill Date: Mon Apr 7 11:49:19 2025 -0400 c++: constinit and value-initialization [PR119652] Value-initialization built an AGGR_INIT_EXPR to set AGGR_INIT_ZERO_FIRST on. Passing that AGGR_INIT_EXPR to maybe_constant_value returned a TARGET_EXPR, which potential_constant_expression_1 mistook for a temporary. We shouldn't add a TARGET_EXPR to the AGGR_INIT_EXPR in this case, just like we already avoid adding it to CONSTRUCTOR or CALL_EXPR. PR c++/119652 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_outermost_constant_expr): Also don't add a TARGET_EXPR around AGGR_INIT_EXPR. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constinit20.C: New test.
[Bug c++/119668] C++20 Nested concepts with NTTP triggers ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119668 --- Comment #1 from Andrew Pinski --- >It does not appear in GCC 14.1+. Did you read https://gcc.gnu.org/bugs/#dontwant ? > Duplicate bug reports, or reports of bugs already fixed in the development > tree, especially those that have already been reported as fixed last week :-) Considering this is not a regression this will most likely be closed as a dup or closed as fixed depending on which commit fixed it.
