[Bug tree-optimization/121004] float_var*0.0f if we know a is finite be just done as copysign(0.0, a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-07-09
[Bug target/120993] powerpc64le with ibm128 long double LDBL_NORM_MAX does not conform to C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120993 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #4 from Bruno Haible --- > One simple fix would be to change LDBL_MANT_DIG, LDBL_MAX_EXP, > and LDBL_NORM_MAX to equal DBL_MANT_DIG, DBL_MAX_EXP and DBL_NORM_MAX > respectively. I don't think changing LDBL_MANT_DIG is adequate, because - There's a lot of code that assumes that when LDBL_MANT_DIG == DBL_MANT_DIG, 'long double' and 'double' are in fact the same. - There's also a lot of code that assumes that LDBL_MANT_DIG == 106 indicates the 'double-double' representation. I also don't think ISO C 23 requires it: ISO C 23 § 5.2.5.3.3.(2)-(9) defines the characteristics of the floating-point data type. It is always possible to reduce p to any value > 1. For example one could define the floating-point model of IEEE 'double' as having p = 5 instead of p = 53. This would only mean that many more floating-point values would be outside the model. Therefore, in order to get a practically useful model, one should choose the maximum possible value of p. In the case of the 'double-double' representation, this value is p = 106. Namely, every x = s * b^e * (f_1 * b^-1 + ... + f_106 * b^-106) can be represented as a 'double-double' as follows: If f_54 ... f_106 are all zero, set x_low = 0. Otherwise let i be the minimum i >= 54 with f_i != 0 and define x_low = s * b^(e-i+1) * (f_i * b^-1 + ... + f_106 * b^(i-107)) (which has 107-i <= 53 bits in its significand). Then x = s * b^e * (f_1 * b^-1 + ... + f_53 * b^-53) + x_low. So, just as pointless as it would be to define DBL_MANT_DIG to any value < 53, it is pointless to define LDBL_MANT_DIG to any value < 106.
[Bug middle-end/121005] TREE_LANG_FLAG_* does not have a check for !INTEGER_CST and !VECTOR_CST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121005 Richard Biener changed: What|Removed |Added Last reconfirmed||2025-07-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Also MEM_REF and TARGET_MEM_REF, and OMP_ATOMIC, CALL_EXPR, etc.
[Bug middle-end/121005] TREE_LANG_FLAG_* does not have a check for !INTEGER_CST and !VECTOR_CST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121005 --- Comment #2 from Richard Biener --- Best have a TREE_BASE_BITS accessor that captures this, it applies to quite some other accessors.
[Bug tree-optimization/121006] if (float_var == CST || float_var== -CST) is known to be true, __builtin_copysignf(CST, float_var) can be optimized to just float_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121006 Richard Biener changed: What|Removed |Added Last reconfirmed||2025-07-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed, but does this happen in practice?
[Bug tree-optimization/121011] Bad optimizations by GCC 15.0.1 from Fedora
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121011 --- Comment #2 from Richard Biener --- There's a duplicate about this (assigned to me even, IIRC). final value replacement is currently done opportunistically rather than as utility to passes where it would be useful (DCE of the loop, avoiding reduction compute).
[Bug tree-optimization/121006] if (float_var == CST || float_var== -CST) is known to be true, __builtin_copysignf(CST, float_var) can be optimized to just float_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121006 --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > Confirmed, but does this happen in practice? The zero case might happen the most. Otherwise I doubt very much
[Bug fortran/120843] [15/16-Regression, Coarray] Inconsistent ranks for operator reported when coarray ranks differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120843 --- Comment #12 from GCC Commits --- The releases/gcc-15 branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:120efb3931260de35173267ec6870d8f17fbadb5 commit r15-9945-g120efb3931260de35173267ec6870d8f17fbadb5 Author: Andre Vehreschild Date: Wed Jul 2 11:06:17 2025 +0200 Fortran: Remove corank conformability checks [PR120843] Remove the checks on coranks conformability in expressions, because there is nothing in the standard about it. When a coarray has no coindexes it it treated like a non-coarray, when it has a full-corank coindex its result is a regular array. So nothing to check for corank conformability. PR fortran/120843 gcc/fortran/ChangeLog: * resolve.cc (resolve_operator): Remove conformability check, because it is not in the standard. gcc/testsuite/ChangeLog: * gfortran.dg/coarray/coindexed_6.f90: Enhance test to have coarray components covered. (cherry picked from commit 15413e05eb9cde976b8890cd9b597d0a41a8eb27)
[Bug fortran/120843] [15/16-Regression, Coarray] Inconsistent ranks for operator reported when coarray ranks differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120843 Andre Vehreschild changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #13 from Andre Vehreschild --- Backported the "correct" patch, too. I hope now everything is fine. Closing for the last time.
[Bug tree-optimization/120922] [16 Regression] RISC-V: ICE during GIMPLE pass: vect in verify_range with -mrvv-max-lmul=m8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922 --- Comment #7 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:6c8d221b74869f2760ded2d67f95dd9d275bc1a2 commit r16-2119-g6c8d221b74869f2760ded2d67f95dd9d275bc1a2 Author: Tamar Christina Date: Wed Jul 9 08:39:35 2025 +0100 middle-end: don't set range on partial vectors [PR120922] Before the change in g:309dbcea2cabb31bde1a65cdfd30bb7f87b170a2 we would never set a range for constant VF and requires partial vector loops. I think a range could be set, since I think the number of latch executions is a ceiling division of TYPE_MAX_VALUE / vf. To account for the partial iteration. This would also then deal with the ICE cause in the PR where the chosen VF was much higher than TYPE_MAX_VALUE and that a mask is relied upon to make it safe. Since the patch was supposed to not change behavior I've added an additional partial vector check on the const_vf > 0 check to make it explicit that we only set it on non-partial vectors (alternative would have been to swap the order of the vf.constant(&const_vf)) check, but that would have hidden the requirement sneakily. The second patch adds support for ranges for partial masks. gcc/ChangeLog: PR tree-optimization/120922 * tree-vect-loop-manip.cc (vect_gen_vector_loop_niters): Don't set range for partial vectors. gcc/testsuite/ChangeLog: PR tree-optimization/120922 * gcc.dg/vect/pr120922.c: New test.
[Bug tree-optimization/120922] [16 Regression] RISC-V: ICE during GIMPLE pass: vect in verify_range with -mrvv-max-lmul=m8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922 --- Comment #8 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:963d5362c598d48ee7a896e674d2a68c41179785 commit r16-2120-g963d5362c598d48ee7a896e674d2a68c41179785 Author: Tamar Christina Date: Wed Jul 9 08:42:02 2025 +0100 middle-end: Use rounding division for ranges for partial vectors [PR120922] This patch adds support for niters ranges for partial vector loops. Due to the last iteration being partial the bounds should be at least 1 but niters // vf as the max. gcc/ChangeLog: PR tree-optimization/120922 * tree-vect-loop-manip.cc (vect_gen_vector_loop_niters): Support range for partial vectors.
[Bug tree-optimization/120922] [16 Regression] RISC-V: ICE during GIMPLE pass: vect in verify_range with -mrvv-max-lmul=m8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922 --- Comment #9 from Tamar Christina --- (In reply to Robin Dapp from comment #6) > (In reply to Tamar Christina from comment #5) > > Question, can I count on > > > > -march=rv64gcv_zvl1024b -mrvv-vector-bits=zvl -mrvv-max-lmul=m8 > > > > always being available as a codegen option for RVV? or do I need some > > require-effective-target checks? > > For a compile test? Yes, that should always be available. > To be extra sure you can add a target riscv_v. Done, thanks!
[Bug tree-optimization/120922] [16 Regression] RISC-V: ICE during GIMPLE pass: vect in verify_range with -mrvv-max-lmul=m8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Tamar Christina --- Fixed, thanks for the report and testcase!
[Bug tree-optimization/119196] Missed folding of vector comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196 --- Comment #5 from GCC Commits --- The master branch has been updated by Victor Do Nascimento : https://gcc.gnu.org/g:f33cc3af8fd9c498bd02623168054d76a0989ed6 commit r16-2134-gf33cc3af8fd9c498bd02623168054d76a0989ed6 Author: Icen Zeyada Date: Wed Jul 9 12:57:17 2025 +0100 gimple-fold: extend vector simplification to match scalar bitwise optimizations [PR119196] Generalize existing scalar gimple_fold rules to apply the same bitwise comparison simplifications to vector types. Previously, an expression like (x < y) && (x > y) would fold to `false` if x and y are scalars, but equivalent vector comparisons were left untouched. This patch enables folding of patterns of the form (cmp x y) bit_and (cmp x y) (cmp x y) bit_ior (cmp x y) (cmp x y) bit_xor (cmp x y) for vector operands as well, ensuring consistent optimization across all data types. gcc/ChangeLog: PR tree-optimization/119196 * match.pd: Allow scalar optimizations with bitwise AND/OR/XOR to apply to vectors. gcc/testsuite/ChangeLog: * gcc.target/aarch64/vector-compare-5.c: Add new test for vector compare simplification. Signed-off-by: Icen Zeyada
[Bug target/109286] Assembler warnings about .init/.fini sections defined without attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109286 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/109286] Assembler warnings about .init/.fini sections defined without attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109286 --- Comment #4 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:2e6dc9e19cdac43354608a1fc29fe31ec614775c commit r16-2135-g2e6dc9e19cdac43354608a1fc29fe31ec614775c Author: Jan Dubiec Date: Wed Jul 9 06:09:20 2025 -0600 [PATCH] [PR target/109286] H8/300: Fix warnings about initfini sections missing attributes The patch changes order of inclusions, i.e. elfos.h is included before target specific h8300/h8300.h, in a way similar to a few other targets. Thanks to this change it is possible to override macros from elfos.h in h8300/h8300.h, in particular .init/.fini section definitions. PR target/109286 gcc/ChangeLog: * config.gcc: Include elfos.h before h8300/h8300.h. * config/h8300/h8300.h (INIT_SECTION_ASM_OP): Override default version from elfos.h. (FINI_SECTION_ASM_OP): Ditto. (ASM_DECLARE_FUNCTION_NAME): Ditto. (ASM_GENERATE_INTERNAL_LABEL): Macro removed because it was being overridden in elfos.h anyway. (ASM_OUTPUT_SKIP): Ditto.
[Bug tree-optimization/119196] Missed folding of vector comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119196 --- Comment #4 from GCC Commits --- The master branch has been updated by Victor Do Nascimento : https://gcc.gnu.org/g:f6eb8291e1c538f946efcb79b1f597c251be63c4 commit r16-2133-gf6eb8291e1c538f946efcb79b1f597c251be63c4 Author: Icen Zeyada Date: Wed Jul 9 12:57:11 2025 +0100 tree-simplify: unify simple_comparison ops in vec_cond for bit and/or/xor [PR119196] Merge simple_comparison patterns under a single vec_cond_expr for bit_and, bit_ior, and bit_xor in the simplify pass. Ensure that when both operands of a bit_and, bit_or, or bit_xor are simple_comparison results, they reside within the same vec_cond_expr rather than separate ones. This prepares the AST so that subsequent transformations (e.g., folding the comparisons if possible) can take effect. gcc/ChangeLog: PR tree-optimization/119196 * match.pd: Merge multiple vec_cond_expr in a single one for bit_and, bit_ior and bit_xor. Signed-off-by: Icen Zeyada
[Bug preprocessor/107974] compiler can't find source file in path that is longer than 255 characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974 Oliver Old changed: What|Removed |Added CC||Oliver.Old at loewen dot de --- Comment #8 from Oliver Old --- I think this bug is a duplicate of 96027.
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jskumari at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Jakub Jelinek --- Started with r15-1619-g3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #463 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #462)
> (In reply to Oleg Endo from comment #461)
> > Yes, of course. I'm a little overloaded atm. I'll try to find some
> > peaceful moments to update/rebase the branch and commit the existing test
> > cases upstream.
>
> I have applied all the patches from your tree on Github now which add the
> tests, but they aren't run. I have tried to run them with
>
> $ make -j80 check-gcc RUNTESTFLAGS="sh.exp"
>
> but none of the pr55212 tests were run. Do I need to adjust anything?
I don't remember in which place I've put the testcases in the testsuite.
RUNTESTFLAGS="sh.exp" acts as a filter.
To run the full testsuite (incl. GCC, target, libstdc++ etc) on sh-sim:
make -k check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
So for a native sh4-linux config, it's should be enough to specify "make -k
check"
To run one particular test, locate the folder where it's in and the
corresponding .exp file, for example:
make check RUNTESTFLAGS="compile.exp=pr57108.c"
[Bug target/120642] ICE: in validate_change_or_fail, at config/riscv/riscv-v.cc:5705 with -O -mcpu=xt-c920 -mrvv-vector-bits=zvl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120642 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/121015] [16 regression] ICE when building blender
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015 Sam James changed: What|Removed |Added CC||hjl.tools at gmail dot com Target Milestone|--- |16.0 --- Comment #3 from Sam James --- -fdisable-rtl-rrvl works.
[Bug target/121015] [16 regression] ICE when building blender
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015
--- Comment #2 from Sam James ---
This fails with just -O2:
```
union {
int i;
float f;
} int_as_float_u;
int render_result_from_bake_w, render_result_from_bake_h_seed_pass;
float *render_result_from_bake_h_primitive, *render_result_from_bake_h_seed;
float int_as_float(int i) {
int_as_float_u.i = i;
return int_as_float_u.f;
}
void render_result_from_bake_h(int tx) {
while (render_result_from_bake_w) {
for (; tx < render_result_from_bake_w; tx++)
render_result_from_bake_h_primitive[1] =
render_result_from_bake_h_primitive[2] = int_as_float(-1);
if (render_result_from_bake_h_seed_pass) {
*render_result_from_bake_h_seed = 0;
}
}
}
```
[Bug c/121013] New: Possible miscompilation triggered by __builtin_stack_address() at `-O3`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121013
Bug ID: 121013
Summary: Possible miscompilation triggered by
__builtin_stack_address() at `-O3`.
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: moorabbit at proton dot me
Target Milestone: ---
While working on implementing __builtin_stack_address() for Clang, I noticed
that GCC can produce different results for this builtin depending on whether
optimizations are enabled.
Context
--
$ ~/gcc-15.1.0/bin/gcc -v
Target: x86_64-pc-linux-gnu
Configured with: ./configure --prefix=~/gcc-15.1.0 --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.1.0 (GCC)
$ cat /tmp/main.c
extern void f(int, int, long, long, long, long, long, long);
void *a() {
f(1, 2, 3, 4, 5, 6, 7, 8);
return __builtin_stack_address();
}
With optimizations disabled (-O0)
---
$ ~/gcc-15.1.0/bin/gcc -O0 -c /tmp/main.c -o /tmp/main.o && objdump -d
/tmp/main.o
/tmp/main.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 55 push %rbp
1: 48 89 e5 mov%rsp,%rbp
4: 6a 08 push $0x8
6: 6a 07 push $0x7
8: 41 b9 06 00 00 00 mov$0x6,%r9d
e: 41 b8 05 00 00 00 mov$0x5,%r8d
14: b9 04 00 00 00 mov$0x4,%ecx
19: ba 03 00 00 00 mov$0x3,%edx
1e: be 02 00 00 00 mov$0x2,%esi
23: bf 01 00 00 00mov$0x1,%edi
28: e8 00 00 00 00 call 2d
2d: 48 83 c4 10 add$0x10,%rsp
31: 48 89 e0 mov%rsp,%rax
34: c9 leave
35: c3 ret
With optimizations enabled (-O3)
---
$ ~/gcc-15.1.0/bin/gcc -O3 -c /tmp/main.c -o /tmp/main.o && objdump -d
/tmp/main.o
/tmp/main.o: file format elf64-x86-64
Disassembly of section .text:
:
0: 48 83 ec 08 sub$0x8,%rsp
4: 41 b9 06 00 00 00 mov$0x6,%r9d
a: 41 b8 05 00 00 00 mov$0x5,%r8d
10: b9 04 00 00 00 mov$0x4,%ecx
15: 6a 08 push $0x8
17: ba 03 00 00 00 mov$0x3,%edx
1c: be 02 00 00 00 mov$0x2,%esi
21: bf 01 00 00 00 mov$0x1,%edi
26: 6a 07 push $0x7
28: e8 00 00 00 00 call 2d
2d: 48 89 e0 mov%rsp,%rax
30: 48 83 c4 18add$0x18,%rsp
34: c3ret
Issue
---
The issue is in the order of the `mov %rsp, %rax` and `add _, %rsp`
instructions.
At -O0, we first adjust the stack pointer by adding $0x10 to %rsp in .
We then save %rsp to %rax in and return from the procedure.
At -O3, we first save %rsp to %rax in . We then adjust the stack
pointer by adding $0x18 to %rsp in and return from the procedure.
What's the right behavior?
-
The comment within the `static rtx expand_builtin_stack_address()` procedure
located in gcc/builtins.cc states:
```[...] the outgoing on-stack arguments pushed temporarily for a call are
regarded as part of the callee's stack range, rather than the caller's.```
This makes the codegen at -O3 incorrect because, at the moment when %rsp is
saved (), it still includes the space used by the temporary pushed
on-stack arguments. That's not the case at -O0. -O1 and -O2 have the same
problem as -O3.
[Bug tree-optimization/121014] New: vectorizer uses RDIV_EXPR for integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121014
Bug ID: 121014
Summary: vectorizer uses RDIV_EXPR for integer types
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kristerw at gcc dot gnu.org
Target Milestone: ---
The function vect_get_loop_len in tree-vect-loop.cc uses RDIV_EXPR for integer
calculations. This is incorrect, as RDIV_EXPR is only supposed to be used for
floating-point types according to tree.def.
The generation of an integer RDIV_EXPR can be seen when compiling the following
function for RISC-V with -O3 -march=rv64gcbv
#include
void
foo0 (int8_t *f, int16_t *d, int n)
{
for (int i = 0; i < n; ++i)
{
f[i * 2 + 0] = 1;
f[i * 2 + 1] = 2;
d[i] = 3;
}
}
[Bug tree-optimization/121014] vectorizer uses RDIV_EXPR for integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121014 Richard Biener changed: What|Removed |Added Last reconfirmed||2025-07-09 CC||juzhe.zhong at rivai dot ai, ||rguenth at gcc dot gnu.org Target||riscv Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ice-on-valid-code --- Comment #1 from Richard Biener --- Huh. I would have said this should ICE during RTL expansion, but ... I suppose it might want to use EXACT_DIV_EXPR?
[Bug middle-end/120093] [16 Regression] FAIL: gcc.dg/vect/pr101145.c since r16-101-g132d01d96ea9d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120093 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- I have a fix.
[Bug middle-end/120093] [16 Regression] FAIL: gcc.dg/vect/pr101145.c since r16-101-g132d01d96ea9d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120093 --- Comment #4 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8f1cc1ceabdac21940fa0638298d8a3b7c941d4a commit r16-2128-g8f1cc1ceabdac21940fa0638298d8a3b7c941d4a Author: Richard Biener Date: Wed Jul 9 13:10:13 2025 +0200 testsuite/120093 - fix gcc.dg/vect/pr101145.c The following changes noinline to noipa to avoid having IPA-CP clones confusing the vectorized loop counting. PR testsuite/120093 * gcc.dg/vect/pr101145.c: Use noipa instead of noinline attribute.
[Bug middle-end/120093] [16 Regression] FAIL: gcc.dg/vect/pr101145.c since r16-101-g132d01d96ea9d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120093 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug libstdc++/117403] [C++26] Implement P1901R2 Enabling the Use of weak_ptr as Keys in Unordered Associative Containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117403 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |16.0 Status|NEW |RESOLVED --- Comment #3 from Jonathan Wakely --- Implemented for GCC 16
[Bug libstdc++/110339] Implement C++26 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339 Bug 110339 depends on bug 117403, which changed state. Bug 117403 Summary: [C++26] Implement P1901R2 Enabling the Use of weak_ptr as Keys in Unordered Associative Containers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117403 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/117403] [C++26] Implement P1901R2 Enabling the Use of weak_ptr as Keys in Unordered Associative Containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117403 --- Comment #2 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:10b8379252e91c2e129f88482240b12ca392d5e2 commit r16-2131-g10b8379252e91c2e129f88482240b12ca392d5e2 Author: Paul Keir Date: Tue Jul 8 13:36:49 2025 +0100 libstdc++: Add smart ptr owner_equals and owner_hash [PR117403] New structs and member functions added to C++26 by P1901R2. libstdc++-v3/ChangeLog: PR libstdc++/117403 * include/bits/shared_ptr.h (shared_ptr::owner_equal) (shared_ptr::owner_hash, weak_ptr::owner_equal) (weak_ptr::owner_hash): Define new member functions. * include/bits/shared_ptr_base.h (owner_equal, owner_hash): Define new structs. * include/bits/version.def (smart_ptr_owner_equality): Define. * include/bits/version.h: Regenerate. * include/std/memory: Added define for __glibcxx_want_smart_ptr_owner_equality. * testsuite/20_util/owner_equal/version.cc: New test. * testsuite/20_util/owner_equal/cmp.cc: New test. * testsuite/20_util/owner_equal/noexcept.cc: New test. * testsuite/20_util/owner_hash/cmp.cc: New test. * testsuite/20_util/owner_hash/noexcept.cc: New test. * testsuite/20_util/shared_ptr/observers/owner_equal.cc: New test. * testsuite/20_util/shared_ptr/observers/owner_hash.cc: New test. * testsuite/20_util/weak_ptr/observers/owner_equal.cc: New test. * testsuite/20_util/weak_ptr/observers/owner_hash.cc: New test. Signed-off-by: Paul Keir
[Bug target/120642] ICE: in validate_change_or_fail, at config/riscv/riscv-v.cc:5705 with -O -mcpu=xt-c920 -mrvv-vector-bits=zvl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120642 --- Comment #3 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:f2e3886a30c771b104bc2714992e072b21a52e76 commit r16-2132-gf2e3886a30c771b104bc2714992e072b21a52e76 Author: Jeff Law Date: Wed Jul 9 05:23:34 2025 -0600 [RISC-V][PR target/120642] Avoid propagating constant AVL for theadvector AVL propagation currently assumes that it can propagate a constant AVL into any vector insn and trips an assert if the insn fails to recognize after such a propagation. However, for xtheadvector that is not a correct assumption; xtheadvector does not allow the vector length to be a constant integer (other than zero which allowed via x0). After consulting with Jin Ma (thanks!) we agree the right fix is to avoid creating the immediate AVL for xtheadvector. This has been tested in my tester, just waiting for the pre-commit tester to spin it. PR target/120642 gcc/ * config/riscv/riscv-avlprop.cc (pass_avlprop::execute): Do not do constant AVL propagation for xtheadvector. gcc/testsuite/ * gcc.target/riscv/rvv/xtheadvector/pr120642.c: New test.
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #3 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > > we can cleanly see that _26 is an uninitialized variable, whose > > initialization has been eliminated by the previous optimization already due > > to it's not used in IL at all. > > You indeed cannot use (non-constant) TYPE_SIZE_UNIT in this way. If there > is an ARRAY_REF in the IL you can use array_ref_element_size to get at it. > But arbitrary VLA type sizes to not survive unless you use them in the > original GENERIC IL. yeah, that's the major issue. So, passing the original TYPE_SIZE_UNIT to the call to .ACCESS_WITH_SIZE as one argument should add one explicit usage of the TYPE_SIZE_UNIT in the original IL, and the definition of the TYPE_SIZE_UNIT will survive the compiler optimization till the object size phase. is there any other issue with this solution?
[Bug target/111814] [SH] __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111814 --- Comment #12 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #11) > Is there anything that needs to be addressed for this one? Yes, can this be backported to the 14 and 15 branches or are the changes too intrusive? I just ran into this issue when running the glibc testsuite on Debian sh4.
[Bug target/121015] New: [16 regression] ICE when building blender
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015 Bug ID: 121015 Summary: [16 regression] ICE when building blender Product: gcc Version: 16.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 61823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61823&action=edit blender.ii.xz Reported by Paul Zander (negril). ``` $ g++ -c blender.ii -O3 -mavx /var/tmp/paludis/media-gfx-blender-4.4./work/blender-4.4./source/blender/render/intern/engine.cc: In function ‘RenderResult* RE_engine_begin_result(RenderEngine*, int, int, int, int, const char*, const char*)’: /var/tmp/paludis/media-gfx-blender-4.4./work/blender-4.4./source/blender/render/intern/engine.cc:368:1: error: unrecognizable insn: (insn 495 43 45 5 (set (reg:V8QI 340) (const_vector:V8QI [ (const_int -1 [0x]) repeated x8 ])) -1 (expr_list:REG_EQUIV (const_vector:V8QI [ (const_int -1 [0x]) repeated x8 ]) (nil))) during RTL pass: ira /var/tmp/paludis/media-gfx-blender-4.4./work/blender-4.4./source/blender/render/intern/engine.cc:368:1: internal compiler error: in extract_insn, at recog.cc:2882 Please submit a full bug report, with preprocessed source (by using -freport-bug). See <https://bugs.gentoo.org/> for instructions. ``` ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/16 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include/g++-v16 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/16/python --enable-libphobos --enable-objc-gc --enable-languages=c,c++,d,objc,obj-c++,fortran,ada,cobol,m2,rust --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 16.0. p, commit 9dd46ee2eb01d30892f1c6db1599e82a9c6e8b04' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-offload-defaulted --enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp --enable-libada --disable-cet --disable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --with-isl --disable-isl-version-check --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes --with-gxx-libcxx-include-dir=/usr/include/c++/v1 --enable-linker-build-id --with-build-config='bootstrap-O3 bootstrap-lto' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 16.0.0 20250709 (experimental) a09b415b87cd98e3a4f3e197ad4e9e67a335c1d4 (Gentoo Hardened 16.0. p, commit 9dd46ee2eb01d30892f1c6db1599e82a9c6e8b04) ```
[Bug target/121015] [16 regression] ICE when building blender
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015 --- Comment #1 from Sam James --- I'm reducing it now.
[Bug tree-optimization/121004] float_var*0.0f if we know a is finite be just done as copysign(0.0, a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- And obviously for -fno-signed-zeros optimize the copysign to just 0.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #462 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #461) > Yes, of course. I'm a little overloaded atm. I'll try to find some > peaceful moments to update/rebase the branch and commit the existing test > cases upstream. I have applied all the patches from your tree on Github now which add the tests, but they aren't run. I have tried to run them with $ make -j80 check-gcc RUNTESTFLAGS="sh.exp" but none of the pr55212 tests were run. Do I need to adjust anything?
[Bug c++/121008] [16 Regression] Error on 'this' inside noexcept specifier of lambda capturing 'this' inside noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug gcov-profile/120229] [GCOV] AutoFDO cannot distinguish privatized functions within an LTO partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120229 --- Comment #2 from Jan Hubicka --- See thread https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689018.html
[Bug c++/121008] [16 Regression] Error on 'this' inside noexcept specifier of lambda capturing 'this' inside noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121008 Marek Polacek changed: What|Removed |Added Priority|P3 |P1 Keywords|needs-bisection | CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r16-1991: commit e9549b5ee8496af12bac3ebfa3ec0aa8487fb725 Author: Jason Merrill Date: Thu Jul 3 12:05:12 2025 -0400 c++: ICE with 'this' in lambda signature [PR120748]
[Bug preprocessor/96027] Windows: gcc does not resolve long relative header paths correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96027 Oliver Old changed: What|Removed |Added CC||Oliver.Old at loewen dot de --- Comment #2 from Oliver Old --- I am currently struggling with this bug as well. We symlink our toolchain directory into the project, among other source component directories, and managed to hit the path length limitation when a standard header tried to include bits/c++config.h. As it seems, this bug must either be fixed via fixing up the path in MinGW to then forward it as extended path to Windows or it could be fixed by adding a manifest enabling long path awareness for the GCC binaries. I have seen that there already is a mechanism for enabling UTF-8 as default code page via manifest (gcc/config/i386/winnt-utf8.manifest). I do not think it would be much work to add the other option, but I am entirely unfamiliar with the build system and autotools.
[Bug c++/121012] [16 Regression] Error on lambda with auto parameter as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121012 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org
[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870 --- Comment #10 from Sam James --- Created attachment 61824 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61824&action=edit ceval.i.xz ceval.o is broken. ``` $ gcc -c -fno-strict-overflow -O2 -mavx -mtune=znver2 -std=c11 -fvisibility=hidden -fprofile-generate /tmp/ceval.i -o Python/ceval.o ```
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 --- Comment #9 from Segher Boessenkool --- Hrm, the insn here is just a mulldi instruction, a bog-standard integer multiplication (by a constant, 6 here). But insn 58 (where the problems start, "Changing address in insn 58 r218:DI&0xfff0 on equiv sfp:DI+0x20&0xfff0") is a VMX memory access indeed (so with &-16 in it).
[Bug target/121018] New: RVV codegen: spills unused vector registers on function call between RVV intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121018
Bug ID: 121018
Summary: RVV codegen: spills unused vector registers on
function call between RVV intrinsics
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: camel-cdr at protonmail dot com
Target Milestone: ---
The code snippet:
#include
extern int foo(void);
vuint8m1_t bar(vuint8m1_t x) {
foo();
return x;
}
causes gcc to spill vector registers v0-v8, v24-v31 around the foo function
call to the stack, while only v8 needs to be spilled.
See: https://godbolt.org/z/jcrPsrMrr
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #6 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) > Why do you need CLASS_OF_SIZE argument? If count is in bytes, simply pass 1 > to the TYPE_SIZE_UNIT argument. > ACCESS_MODE can be in the same argument as TYPE_OF_SIZE, type of the > INTEGER_CST will be TYPE_OF_SIZE, while the value can be the -1/0/1/2/3 > access mode. > If you need further flags, just or them in (either change -1 to 4, or use > say -4/0/4/8/12 for ACCESS_MODE and low 2 bits for other flags). Yes, that's a good suggestion. The question here I have is: When combining TYPE_OF SIZE with ACCESS_MODE, since the current value of ACCESS_MODE is -1/0/1/2/3, its type should be an INTEGER_TYPE_NODE. however, if the TYPE_OF_SIZE is an UNSIGNED_TYPE_NODE, will there be any issue when I tried to get the correct integer value for ACCESS_MODE?
[Bug fortran/120958] tree-sra "miscompiles" asynchronous MPI (mpi_irecv) in Fortran 77 because of wrong fnspec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958 --- Comment #11 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #10) > The problem is not restricted to mpi_isend. This was supposed to read: ... not restricted to mpi_irecv
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 --- Comment #11 from Jakub Jelinek --- Though even there is uninitialized read I guess from temp.a. That said, LRA obviously shouldn't hang even on code which has UB at runtime.
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #10 from Jakub Jelinek ---
Slightly tweaked testcase to avoid -Wuninitialized as well as avoid the
aliasing violation.
typedef struct { int a; } A;
unsigned char *a;
char b;
int c;
void foo (vector char, vector char, vector char);
void
bar (long stride)
{
vector char v0, v1, v2, v3, v5;
vector char r0 = __builtin_vec_vsx_ld (0, a);
vector char r2 = __builtin_vec_vsx_ld (2 * stride, a - 3);
vector char r3 = __builtin_vec_vsx_ld (3 * stride, a - 3);
vector char r4;
vector char r6 = __builtin_vec_vsx_ld (6 * stride, a - 3);
vector char r7 = __builtin_vec_vsx_ld (7 * stride, a - 3);
vector char r14, h, i, j;
if (b)
return;
v1 = __builtin_vec_vsx_ld (9 * stride, a);
v2 = __builtin_vec_vsx_ld (10 * stride, a - 3);
v3 = __builtin_vec_vsx_ld (11 * stride, a - 3);
r3 = __builtin_vec_mergeh (r3, v3);
v5 = __builtin_vec_mergel (r2, r6);
r14 = __builtin_vec_mergeh (r3, r7);
r4 = __builtin_vec_mergeh (v2, r14);
v0 = __builtin_vec_mergeh (r0, r4);
union { unsigned char a[16]; A b; } temp;
vector signed char k;
h = __builtin_vec_ld (0, temp.a);
i = __builtin_vec_splat (h, 1);
temp.b.a = c;
k = __builtin_vec_ld (0, (signed char *) temp.a);
j = __builtin_vec_and (i, (vector char) k);
foo (v1, v0, j);
foo (v1, v5, j);
}
[Bug fortran/120958] tree-sra "miscompiles" asynchronous MPI (mpi_irecv) in Fortran 77 because of wrong fnspec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-07-09 Known to fail||14.3.1, 15.1.1, 16.0 --- Comment #10 from anlauf at gcc dot gnu.org --- JTFR: I can confirm the failure with 14.3+ here at -O1 and higher. The problem vanishes for: - adding the ASYNCHRONOUS attribute to norm_temp2 - declaring norm_temp2 as ALLOCATABLE and allocate (norm_temp2(2)) - -fno-tree-sra The -fno-tree-sra is really a big hammer... The problem is not restricted to mpi_isend. Replacing the communication by call mpi_isend( norm_temp1, > 2, > dp_type, > reduce_exch_proc(i), > i, > mpi_comm_world, > request, > ierr ) call mpi_recv( norm_temp2, > 2, > dp_type, > reduce_exch_proc(i), > i, > mpi_comm_world, > ierr ) leads to the same observation.
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #10 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #9) > The problem if it is the scalar type rather than pointer to it is that it > could be e.g. too narrow to fit all the ACCESS_MODE values there. Think > about unsigned _BitInt(1) counted_by. Okay, so the final change is like the following: ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, TYPE_OF_SIZE + ACCESS_MODE, TYPE_SIZE_UNIT for element) which returns the REF_TO_OBJ same as the 1st argument; 1st argument REF_TO_OBJ: The reference to the object; 2nd argument REF_TO_SIZE: The reference to the size of the object, 3rd argument TYPE_OF_SIZE + ACCESS_MODE: An integer constant with a pointer TYPE. The pointee TYPE of the pointer TYPE is the TYPE of the object referenced by REF_TO_SIZE. The integer constant value represents the ACCESS_MODE: 0: none 1: read_only 2: write_only 3: read_write 4th argument: The TYPE_SIZE_UNIT of the element TYPE of the array. I have implemented this and worked well in my local workspace. let me know if you see any more issue.
[Bug middle-end/121013] Possible miscompilation triggered by __builtin_stack_address() at `-O3`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121013 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gcc/Return-Address.html#index-_005f_005fbuiltin_005fstack_005faddress
[Bug target/120999] Assembler warning about MOVPRFX generation for NBSL instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120999 ktkachov at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-07-09 Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from ktkachov at gcc dot gnu.org --- Testing a fix.
[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #9 from Jason Merrill --- (In reply to Jason Merrill from comment #8) > Iain, will you backport r16-1507? Actually, I'll do it.
[Bug tree-optimization/104547] std::vector::resize(v.size() - n) produces poor code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104547 --- Comment #13 from Jonathan Wakely --- This test fails with this proposed patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689128.html
[Bug fortran/120958] tree-sra "miscompiles" asynchronous MPI (mpi_irecv) in Fortran 77 because of wrong fnspec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120958
--- Comment #9 from kargls at comcast dot net ---
(In reply to anlauf from comment #8)
> (In reply to Martin Jambor from comment #7)
> > (In reply to kargls from comment #5)
> > >
> > > So, if I understand, you want an fnspec of ". . w w w w w w w".
> > > Can you show f->sym and f->sym-attr from gdb?
> > >
> >
> > (gdb) p *f->sym
> > $5 = {name = 0x7fffbe64a100 "_formal_70", module = 0x0, declared_at = {nextc
> > = 0x4c006a4, u = {lb = 0x4c00620, location = 79693344}}, ts = {type =
> > BT_REAL, kind = 8, u = {derived = 0x0,
>
> The interface is guessed by gfc_get_formal_from_actual_arglist, which
> creates the artifical symbol "_formal_%d". Can we use that information?
Unfortunately, I don't think we can. The actual argument list has been
collapsed to the formal argument list. I was hoping that one of the
attributes would help, but only f->sym->attr.dummy=1.
Looking at the code Martin posted (removing some actual arguments to
reduce line length), his description suggests that norm_temp2 is
modified after mpi_irecv returns, i.e., asynchronous behavior.
do i = 1, l2npcols
if (timeron) call timer_start(t_ncomm)
call mpi_irecv(norm_temp2, ...)
call mpi_send (norm_temp1, ...)
call mpi_wait( request, status, ierr )
if (timeron) call timer_stop(t_ncomm)
norm_temp1(1) = norm_temp1(1) + norm_temp2(1)
norm_temp1(2) = norm_temp1(2) + norm_temp2(2)
enddo
If this is an implicit interface, then norm_temp2 can only be modified
through its associated dummy argument. IIRC, the addition of the ASYNCHRONOUS
attribute and assumed-rank (i.e, DIMENSION(..)) feature were movitated by
MPI. See comment #5 for the different interfaces from 'USE MPI' and
'USE MPI_F08'.
I downloaded the code Martin points to. Just need to build openmpi with
top-of-tree gfortran to do some sleuthing.
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #6 from Jakub Jelinek ---
Reduced -mcpu=power9 -O2:
typedef struct { int a; } A;
unsigned char *a;
char b;
int c;
void foo (vector char, vector char, vector char);
void
bar (long stride)
{
vector char v0, v1, v2, v3, v4, v5;
vector char r0 = __builtin_vec_vsx_ld (0, a);
vector char r2 = __builtin_vec_vsx_ld (2 * stride, a - 3);
vector char r3 = __builtin_vec_vsx_ld (3 * stride, a - 3);
vector char r4;
vector char r6 = __builtin_vec_vsx_ld (6 * stride, a - 3);
vector char r7 = __builtin_vec_vsx_ld (7 * stride, a - 3);
vector char r14, h, i, j;
if (b)
return;
v1 = __builtin_vec_vsx_ld (9 * stride, a);
v2 = __builtin_vec_vsx_ld (10 * stride, a - 3);
v3 = __builtin_vec_vsx_ld (11 * stride, a - 3);
r3 = __builtin_vec_mergeh (r3, v3);
v5 = __builtin_vec_mergel (r2, r6);
r14 = __builtin_vec_mergeh (r3, r7);
r4 = __builtin_vec_mergeh (v2, r14);
v0 = __builtin_vec_mergeh (r0, r4);
unsigned char temp[16];
vector signed char k;
h = __builtin_vec_ld (0, temp);
i = __builtin_vec_splat (h, 1);
((A *) temp)->a = c;
k = __builtin_vec_ld (0, (signed char *) temp);
j = __builtin_vec_and (i, (vector char) k);
foo (v1, v0, j);
foo (v4, v5, j);
}
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #4 from qinzhao at gcc dot gnu.org --- The size of the element of the FAM actually _cannot_ reliably depends on the original TYPE of the FAM that we passed as the 6th parameter to the .ACCESS_WITH_SIZE: TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (gimple_call_arg (call, 5 when the element of the FAM has a variable length type. Since the variable that represents TYPE_SIZE_UNIT has no explicit usage in the original IL, compiler transformations (such as DSE) that are applied before object_size phase might eliminate the whole definition to the variable that represents the TYPE_SIZE_UNIT of the element of the FAM. In order to resolve this correctness issue, instead of passing the original TYPE of the FAM as the 6th argument to .ACCESS_WITH_SIZE, we should explicitly pass the original TYPE_SIZE_UNIT of the element TYPE of the FAM as the 6th argument to the call to .ACCESS_WITH_SIZE. As a result, the new ACCESS_WITH_SIZE is: (change the 6th argument to the TYPE_SIZE_UNIT of the element TYPE of the FAM) ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, CLASS_OF_SIZE, TYPE_OF_SIZE, ACCESS_MODE, TYPE_SIZE_UNIT for element) which returns the REF_TO_OBJ same as the 1st argument; 1st argument REF_TO_OBJ: The reference to the object; 2nd argument REF_TO_SIZE: The reference to the size of the object, 3rd argument CLASS_OF_SIZE: The size referenced by the REF_TO_SIZE represents 0: the number of bytes. 1: the number of the elements of the object type; 4th argument TYPE_OF_SIZE: A constant 0 with its TYPE being the same as the TYPE of the object referenced by REF_TO_SIZE 5th argument ACCESS_MODE: -1: Unknown access semantics 0: none 1: read_only 2: write_only 3: read_write 6th argument: The TYPE_SIZE_UNIT of the element TYPE of the FAM when 3rd argument is 1. NULL when 3rd argument is 0. In tree-object-size.cc, instead of the following current code to get the "element_size": /* The type of the 6th argument type is the pointer TYPE to the original flexible array type. */ tree pointer_to_array_type = TREE_TYPE (gimple_call_arg (call, 5)); gcc_assert (POINTER_TYPE_P (pointer_to_array_type)); tree element_type = TREE_TYPE (TREE_TYPE (pointer_to_array_type)); tree element_size = TYPE_SIZE_UNIT (element_type); the New code should be: + /* The 6th argument is the TYPE_SIZE_UNIT for the element of the original + flexible array. */ + tree element_size = gimple_call_arg (call, 5);
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #7 from qinzhao at gcc dot gnu.org ---
I need to modify the testing case as following to enable
__builtin_dynamic_object_size working as expected:
/* The parameter m must be const qualified to avoid the m is
marked as TREE_SIDE_EFFECTS in IR.
The __builtin_dynamic_object_size will be folded as -1 by
fold_builtin_object_size when m is NOT const qualified. */
void
foo (int n, const int m)
{
typedef int A[m];
struct S { int n, m; A a[2]; A b[] __attribute__((counted_by (n))); } *p;
p = __builtin_malloc (sizeof (struct S) + sizeof (A) * n);
p->n = n;
p->m = m;
EXPECT (__builtin_dynamic_object_size (p->b, 1), sizeof (A) * n);
}
int main ()
{
foo (2, 10);
return 0;
}
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #8 from Jakub Jelinek --- The usual way would be to make the argument pointer to the scalar type, basically have the access mode the same type as the second argument. So e.g. int * or unsigned * or size_t * etc.
[Bug cobol/120794] extra separator periods lead to syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120794 --- Comment #3 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a commit r16-2155-g069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a Author: Robert Dubner Date: Wed Jul 9 12:24:38 2025 -0400 cobol: Development round-up. [PR120765, PR119337, PR120794] This collection of changes reflects development by both Jim Lowden and Bob Dubner. It includes fixes to the cobcd script; refinements to the multiple- period syntax; changes to the parser; implementation of DISPLAY/ACCEPT to and from ENVIRONMENT-NAME, ENVIRONMENT-VALUE, ARGUMENT-NUMBER, ARGUMENT-VALUE and minor changes to genapi.cc to cut down on the number of cppcheck warnings. Co-authored-by: James K. Lowden Co-authored-by: Robert Dubner gcc/cobol/ChangeLog: PR cobol/120765 PR cobol/119337 PR cobol/120794 * Make-lang.in: Take control of the .cc.o rule. * cbldiag.h (error_msg_direct): New declaration. (gcc_location_dump): Forward declaration. (location_dump): Use gcc_location_dump. * cdf.y: Change some tokens. * gcobc: Change dialect handling. * genapi.cc (parser_call_targets_dump): Temporarily remove from service. (parser_compile_dcls): Combine temporary arrays. (get_binary_value_from_float): Apply const to one parameter. (depending_on_value): Localize a boolean variable. (normal_normal_compare): Likewise. (cobol_compare): Eliminate cppcheck warning. (combined_name): Apply const to an input parameter. (parser_perform): Apply const to a variable. (parser_accept): Improve handling of special_name_t parameter and the exception conditions. (parser_display): Improve handling of speciat_name_t parameter; use the os_filename[] string when appropriate. (program_end_stuff): Rename shadowing variable. (parser_division): Consolidate temporary char[] arrays. (parser_file_start): Apply const to a parameter. (inspect_replacing): Likewise. (parser_program_hierarchy): Rename shadowing variable. (mh_identical): Apply const to parameters. (float_type_of): Likewise. (picky_memcpy): Likewise. (mh_numeric_display): Likewise. (mh_little_endian): Likewise. (mh_source_is_group): Apply static to a variable it. (move_helper): Quiet a cppcheck warning. * genapi.h (parser_accept): Add exceptions to declaration. (parser_accept_under_discussion): Add declaration. (parser_display): Change to std::vector; add exceptions to declaration. * lexio.cc (cdf_source_format): Improve source code location handling. (source_format_t::infer): Likewise. (is_fixed_format): Likewise. (is_reference_format): Likewise. (left_margin): Likewise. (right_margin): Likewise. (cobol_set_indicator_column): Likewise. (include_debug): Likewise. (continues_at): Likewise. (indicated): Likewise. (check_source_format_directive): Likewise. (cdftext::free_form_reference_format): Likewise. * parse.y: Tokens; program and function names; DISPLAY and ACCEPT handling. * parse_ante.h (class tokenset_t): Removed. (class current_tokens_t): Removed. (field_of): Removed. * scan.l: Token handling. * scan_ante.h (level_found): Comment. * scan_post.h (start_condition_str): Remove cast author_state:. * symbols.cc (symbols_update): Change error message. (symbol_table_init): Correct and reorder entries. (symbol_unresolved_file_key): New function definition. (cbl_file_key_t::deforward): Change error message. * symbols.h (symbol_unresolved_file_key): New declaration. (keyword_tok): New function. (redefined_token): New function. (class current_tokens_t): New class. * symfind.cc (symbol_match): Revise error message. * token_names.h: Reorder and change numbers in comments. * util.cc (class cdf_directives_t): New class. (cobol_set_indicator_column): New function. (cdf_source_format): New function. (gcc_location_set_impl): Improve column handling in token_location. (gcc_location_dump): New function. (class temp_loc_t): Modify constructor. (error_msg_direct): New function. * util.h (class source_format_t): New class. libgcobol/ChangeLog: * libgcobol.cc (__gg__accept_envar): ACCEPT
[Bug cobol/119337] cobol: gcobc wrapper should deduce output name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119337 --- Comment #7 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a commit r16-2155-g069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a Author: Robert Dubner Date: Wed Jul 9 12:24:38 2025 -0400 cobol: Development round-up. [PR120765, PR119337, PR120794] This collection of changes reflects development by both Jim Lowden and Bob Dubner. It includes fixes to the cobcd script; refinements to the multiple- period syntax; changes to the parser; implementation of DISPLAY/ACCEPT to and from ENVIRONMENT-NAME, ENVIRONMENT-VALUE, ARGUMENT-NUMBER, ARGUMENT-VALUE and minor changes to genapi.cc to cut down on the number of cppcheck warnings. Co-authored-by: James K. Lowden Co-authored-by: Robert Dubner gcc/cobol/ChangeLog: PR cobol/120765 PR cobol/119337 PR cobol/120794 * Make-lang.in: Take control of the .cc.o rule. * cbldiag.h (error_msg_direct): New declaration. (gcc_location_dump): Forward declaration. (location_dump): Use gcc_location_dump. * cdf.y: Change some tokens. * gcobc: Change dialect handling. * genapi.cc (parser_call_targets_dump): Temporarily remove from service. (parser_compile_dcls): Combine temporary arrays. (get_binary_value_from_float): Apply const to one parameter. (depending_on_value): Localize a boolean variable. (normal_normal_compare): Likewise. (cobol_compare): Eliminate cppcheck warning. (combined_name): Apply const to an input parameter. (parser_perform): Apply const to a variable. (parser_accept): Improve handling of special_name_t parameter and the exception conditions. (parser_display): Improve handling of speciat_name_t parameter; use the os_filename[] string when appropriate. (program_end_stuff): Rename shadowing variable. (parser_division): Consolidate temporary char[] arrays. (parser_file_start): Apply const to a parameter. (inspect_replacing): Likewise. (parser_program_hierarchy): Rename shadowing variable. (mh_identical): Apply const to parameters. (float_type_of): Likewise. (picky_memcpy): Likewise. (mh_numeric_display): Likewise. (mh_little_endian): Likewise. (mh_source_is_group): Apply static to a variable it. (move_helper): Quiet a cppcheck warning. * genapi.h (parser_accept): Add exceptions to declaration. (parser_accept_under_discussion): Add declaration. (parser_display): Change to std::vector; add exceptions to declaration. * lexio.cc (cdf_source_format): Improve source code location handling. (source_format_t::infer): Likewise. (is_fixed_format): Likewise. (is_reference_format): Likewise. (left_margin): Likewise. (right_margin): Likewise. (cobol_set_indicator_column): Likewise. (include_debug): Likewise. (continues_at): Likewise. (indicated): Likewise. (check_source_format_directive): Likewise. (cdftext::free_form_reference_format): Likewise. * parse.y: Tokens; program and function names; DISPLAY and ACCEPT handling. * parse_ante.h (class tokenset_t): Removed. (class current_tokens_t): Removed. (field_of): Removed. * scan.l: Token handling. * scan_ante.h (level_found): Comment. * scan_post.h (start_condition_str): Remove cast author_state:. * symbols.cc (symbols_update): Change error message. (symbol_table_init): Correct and reorder entries. (symbol_unresolved_file_key): New function definition. (cbl_file_key_t::deforward): Change error message. * symbols.h (symbol_unresolved_file_key): New declaration. (keyword_tok): New function. (redefined_token): New function. (class current_tokens_t): New class. * symfind.cc (symbol_match): Revise error message. * token_names.h: Reorder and change numbers in comments. * util.cc (class cdf_directives_t): New class. (cobol_set_indicator_column): New function. (cdf_source_format): New function. (gcc_location_set_impl): Improve column handling in token_location. (gcc_location_dump): New function. (class temp_loc_t): Modify constructor. (error_msg_direct): New function. * util.h (class source_format_t): New class. libgcobol/ChangeLog: * libgcobol.cc (__gg__accept_envar): ACCEPT
[Bug cobol/120765] gcobc broken shellscript
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120765 --- Comment #2 from GCC Commits --- The master branch has been updated by Robert Dubner : https://gcc.gnu.org/g:069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a commit r16-2155-g069bf2fe31e99f0415ddb6acaf76cfb6eee8bb6a Author: Robert Dubner Date: Wed Jul 9 12:24:38 2025 -0400 cobol: Development round-up. [PR120765, PR119337, PR120794] This collection of changes reflects development by both Jim Lowden and Bob Dubner. It includes fixes to the cobcd script; refinements to the multiple- period syntax; changes to the parser; implementation of DISPLAY/ACCEPT to and from ENVIRONMENT-NAME, ENVIRONMENT-VALUE, ARGUMENT-NUMBER, ARGUMENT-VALUE and minor changes to genapi.cc to cut down on the number of cppcheck warnings. Co-authored-by: James K. Lowden Co-authored-by: Robert Dubner gcc/cobol/ChangeLog: PR cobol/120765 PR cobol/119337 PR cobol/120794 * Make-lang.in: Take control of the .cc.o rule. * cbldiag.h (error_msg_direct): New declaration. (gcc_location_dump): Forward declaration. (location_dump): Use gcc_location_dump. * cdf.y: Change some tokens. * gcobc: Change dialect handling. * genapi.cc (parser_call_targets_dump): Temporarily remove from service. (parser_compile_dcls): Combine temporary arrays. (get_binary_value_from_float): Apply const to one parameter. (depending_on_value): Localize a boolean variable. (normal_normal_compare): Likewise. (cobol_compare): Eliminate cppcheck warning. (combined_name): Apply const to an input parameter. (parser_perform): Apply const to a variable. (parser_accept): Improve handling of special_name_t parameter and the exception conditions. (parser_display): Improve handling of speciat_name_t parameter; use the os_filename[] string when appropriate. (program_end_stuff): Rename shadowing variable. (parser_division): Consolidate temporary char[] arrays. (parser_file_start): Apply const to a parameter. (inspect_replacing): Likewise. (parser_program_hierarchy): Rename shadowing variable. (mh_identical): Apply const to parameters. (float_type_of): Likewise. (picky_memcpy): Likewise. (mh_numeric_display): Likewise. (mh_little_endian): Likewise. (mh_source_is_group): Apply static to a variable it. (move_helper): Quiet a cppcheck warning. * genapi.h (parser_accept): Add exceptions to declaration. (parser_accept_under_discussion): Add declaration. (parser_display): Change to std::vector; add exceptions to declaration. * lexio.cc (cdf_source_format): Improve source code location handling. (source_format_t::infer): Likewise. (is_fixed_format): Likewise. (is_reference_format): Likewise. (left_margin): Likewise. (right_margin): Likewise. (cobol_set_indicator_column): Likewise. (include_debug): Likewise. (continues_at): Likewise. (indicated): Likewise. (check_source_format_directive): Likewise. (cdftext::free_form_reference_format): Likewise. * parse.y: Tokens; program and function names; DISPLAY and ACCEPT handling. * parse_ante.h (class tokenset_t): Removed. (class current_tokens_t): Removed. (field_of): Removed. * scan.l: Token handling. * scan_ante.h (level_found): Comment. * scan_post.h (start_condition_str): Remove cast author_state:. * symbols.cc (symbols_update): Change error message. (symbol_table_init): Correct and reorder entries. (symbol_unresolved_file_key): New function definition. (cbl_file_key_t::deforward): Change error message. * symbols.h (symbol_unresolved_file_key): New declaration. (keyword_tok): New function. (redefined_token): New function. (class current_tokens_t): New class. * symfind.cc (symbol_match): Revise error message. * token_names.h: Reorder and change numbers in comments. * util.cc (class cdf_directives_t): New class. (cobol_set_indicator_column): New function. (cdf_source_format): New function. (gcc_location_set_impl): Improve column handling in token_location. (gcc_location_dump): New function. (class temp_loc_t): Modify constructor. (error_msg_direct): New function. * util.h (class source_format_t): New class. libgcobol/ChangeLog: * libgcobol.cc (__gg__accept_envar): ACCEPT
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 --- Comment #9 from Jakub Jelinek --- The problem if it is the scalar type rather than pointer to it is that it could be e.g. too narrow to fit all the ACCESS_MODE values there. Think about unsigned _BitInt(1) counted_by.
[Bug target/120993] powerpc64le with ibm128 long double LDBL_NORM_MAX does not conform to C23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120993 --- Comment #5 from Paul Eggert --- (In reply to Bruno Haible from comment #4) > in order to get a practically useful model, one should choose the > maximum possible value of p. > > In the case of the 'double-double' representation, this value is p = 106. That depends on what one means by "useful". Gnulib takes "useful" to mean "numbers are representable in this binary format", and for this meaning, p = 106 indeed makes sense. However, as I understand it GCC takes "useful" to mean "arithmetic works usefully on these numbers", for which p = 106 is excessive. For example, GCC's LDBL_NORM_MAX is (2**1023 - 2**917), and in GCC (LDBL_NORM_MAX - 0x1p917L) yields 2**1023 - 2**918 which is exactly correct. In contrast Gnulib's LDBL_NORM_MAX is (2**1024 - 2**918) and in Gnulib (LDBL_NORM_MAX - 0x1p918L) yields infinity, which is completely bogus as the mathematical result is exactly representable. It's hard to argue that Gnulib conforms to C23 here, unless one takes the position that floating point operations can result in any value, even if wildly wrong - I wouldn't want to go there myself. One possible solution in Gnulib would be to shrink its LDBL_MAX_EXP from 1024 to 1023, and to shrink its LDBL_NORM_MAX to equal GCC's. As far as I know this would fix the C23 conformance issue. I could easily implement that in Gnulib. Similarly, GCC could fix its C23 conformance issue by shrinking its LDBL_MAX_EXP from 1024 to 1023 without changing anything else. This would be far less disruptive than my earlier proposal of changing LDBL_MANT_DIG, LDBL_MAX_EXP, and LDBL_NORM_MAX to match their DBL_* counterparts.
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 --- Comment #3 from Segher Boessenkool --- Does anyone want to take this? Fame and fortune await! We need a reduced test case btw :-)
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 --- Comment #4 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #1) > This is definitely sounding more and more like PR 93658. Yes, and maybe the error / fix / workaround will be similar: replace a VECTOR_MEM_ALTIVEC_P by VECTOR_MEM_ALTIVEC_OR_VSX_P (what a nasty name, it does not say at all what it really is testing, not something a (sane) user would care about anyway). So LRA gets into an infinite loop here as well, do we know that to be true already, is that actually seen?
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 --- Comment #5 from Andrew Pinski --- (In reply to Segher Boessenkool from comment #4) > So LRA gets into an infinite loop here as well, do we know that to be > true already, is that actually seen? Yes from the .reload dump: ``` Changing address in insn 138 r466:DI&0xfff0 on equiv sfp:DI-0x10&0xfff0 Creating newreg=569, assigning class BASE_REGS to base r569 Creating newreg=570, assigning class BASE_REGS to base r570 Creating newreg=571, assigning class BASE_REGS to base r571 ;; repeated many times when I stopped it ```
[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870 Richard Biener changed: What|Removed |Added Keywords||needs-bisection --- Comment #12 from Richard Biener --- Did we bisect this yet?
[Bug libstdc++/120997] std::span::subspan returns initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120997
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a72d0e1a8bf0770ddf1d8d0ebe589f92a4fab4ef
commit r16-2152-ga72d0e1a8bf0770ddf1d8d0ebe589f92a4fab4ef
Author: Jonathan Wakely
Date: Tue Jul 8 14:56:39 2025 +0100
libstdc++: Do not use list-initialization in std::span members [PR120997]
As the bug report shows, for span the return statements of
the form `return {data(), count};` will use the new C++26 constructor,
span(initializer_list).
Although the conversions from data() to bool and count to bool are
narrowing and should be ill-formed, in system headers the narrowing
diagnostics are suppressed. In any case, even if the compiler diagnosed
them as ill-formed, we still don't want the initializer_list constructor
to be used. We want to use the span(element_type*, size_t) constructor
instead.
Replace the braced-init-list uses with S(data(), count) where S is the
correct return type. We need to make similar changes in the C++26
working draft, which will be taken care of via an LWG issue.
libstdc++-v3/ChangeLog:
PR libstdc++/120997
* include/std/span (span::first, span::last, span::subspan): Do
not use braced-init-list for return statements.
* testsuite/23_containers/span/120997.cc: New test.
[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870 --- Comment #13 from Sam James --- It looks like the last commit this machine built python3.14t at was r16-1594-gb03e0d69b37f6e which predates preserve_none being added (r16-1692-g9804b23198b39f). We had a similar problem in PR120840.
[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870 --- Comment #14 from Sam James --- (In reply to Sam James from comment #13) > It looks like the last commit this machine built python3.14t at was > r16-1594-gb03e0d69b37f6e which predates preserve_none being added > (r16-1692-g9804b23198b39f). > > We had a similar problem in PR120840. (i.e. I've not bisected it but I'm fairly sure it's just because preserve_none is now available and is used.)
[Bug c++/121016] coroutine appears to be allergic to {()}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016 --- Comment #1 from Marc Singer --- Created attachment 61825 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61825&action=edit Preprocessed version of the failing source file.
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007
--- Comment #7 from Segher Boessenkool ---
Cool, thanks!
121007.c:36:3: warning: 'v4' may be used uninitialized [-Wmaybe-uninitialized]
No clue why it says "may be" there, it obviously *is* used uninitialised,
this is the first time it is used after all, and that code is always
executed. Well, bar() isn't necessarily ever called, it is maybe about that
:-)
It works fine with -mcpu=power{7,8,10} , and it fails in LRA for
-mcpu=power9, as in #c1 .
Considering alt=0 of insn 21: (0) =r (1) %r (2) r
2 Operand reload: losers++
2 Non-pseudo reload: reject+=2
2 Non input pseudo reload: reject++
overall=9,losers=1,rld_nregs=1
Considering alt=1 of insn 21: (0) r (1) r (2) I
overall=0,losers=0,rld_nregs=0
Considering alt=0 of insn 21: (0) =r (1) %r (2) r
1 Operand reload: losers++
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
overall=9,losers=1 -- refuse
Considering alt=1 of insn 21: (0) r (1) r (2) I
1 Operand reload: losers++
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
overall=9,losers=1 -- refuse
Choosing alt 1 in insn 21: (0) r (1) r (2) I {muldi3}
Changing address in insn 58 r218:DI&0xfff0 on equiv
sfp:DI+0x70&0xfff0
Creating newreg=224, assigning class BASE_REGS to base r224
Creating newreg=225, assigning class BASE_REGS to base r225
(etc., I stopped it before it reached seven digits)
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 --- Comment #8 from Segher Boessenkool --- (Also tested on powerpc-linux (where things just work), and on powerpc64-linux (the older ABI, correct-endian), where it fails just the same as on LE).
[Bug target/114641] sh: fdpic optimization of function address breaks pointer equality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114641 --- Comment #4 from Rich Felker --- It's a C conformance bug that's been present ever since the version of the FDPIC support I submitted for merge, so I think it's appropriate for backport to any branch that's still open and fixing bugs of this type. The code has not been modified since initial merge afaik, so the patch should apply cleanly to any version. I can't speak to whether this patch is the best way to fix it. The condition I'm trying to convey is "non-hidden external symbol". Probably the comment should be updated too, since "weak ref" and "non-hidden external symbol" are distinct conditions that both require going thru the GOT for their own reasons. Weak-ref because it could evaluate to null (which can't be represented as an offset from PC) and non-hidden-external because we need the canonical address for function pointer equality to hold.
[Bug target/121007] [15/16 Regression] compiler hangs when building ffpmeg with -mcpu=power9 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121007 --- Comment #12 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #11) > Though even there is uninitialized read I guess from temp.a. > That said, LRA obviously shouldn't hang even on code which has UB at runtime. Of course. It isn't *necessarily* UB even, perhaps this code isn't executed at all, the compiler should just finish compiling it! Instead of getting into some trivial infinite loop. Has anyone figured out what causes that loop, btw? Or what triggers it at least? It seems obvious something else in LRA does not handle VMX addresses correctly either, but what? And, of course, what do we do about it? Something that works generically so we do not get such PRs ever again would be marvelous :-)
[Bug tree-optimization/121020] [16 regression] genrecog miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020 --- Comment #4 from Sam James --- I'll bisect it now, I won't have a chance to try reduce until the weekend.
[Bug tree-optimization/121020] [16 regression] genrecog miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121020
--- Comment #5 from Sam James ---
(In reply to Sam James from comment #0)
> $ make -j$(nproc) -l$(nproc)
This should read:
$ make -j$(nproc) -l$(nproc) STAGE1_C{,XX}FLAGS="-O3 -march=znver2 -ggdb3"
[Bug target/121015] [16 regression] ICE when building blender for x86_64 with -O3 -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015 H.J. Lu changed: What|Removed |Added Attachment #61827|0 |1 is obsolete|| --- Comment #5 from H.J. Lu --- Created attachment 61829 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61829&action=edit An updated patch
[Bug target/114641] sh: fdpic optimization of function address breaks pointer equality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114641 --- Comment #5 from Oleg Endo --- (In reply to Rich Felker from comment #4) > It's a C conformance bug that's been present ever since the version of the > FDPIC support I submitted for merge, so I think it's appropriate for > backport to any branch that's still open and fixing bugs of this type. The > code has not been modified since initial merge afaik, so the patch should > apply cleanly to any version. OK, got it. > I can't speak to whether this patch is the best way to fix it. The condition > I'm trying to convey is "non-hidden external symbol". > > Probably the comment should be updated too, since "weak ref" and "non-hidden > external symbol" are distinct conditions that both require going thru the > GOT for their own reasons. Weak-ref because it could evaluate to null (which > can't be represented as an offset from PC) and non-hidden-external because > we need the canonical address for function pointer equality to hold. It's probably better to make a dedicated function for that, like 'bool sh_non_hidden_external_symbol_p (rtx sym_ref)' Like that the intention is clearly conveyed in the place where it's being used and if it's later found that the check is not adequate, it can be easily fixed inside that function.
[Bug target/120870] [16 regression] CPython miscompiled with preserve_none and CFLAGS="-O2 -march=znver2 -ggdb3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120870 --- Comment #11 from Sam James --- Without -fprofile-generate: │ 0001ed00 <_Py_Check_ArgsIterable>: │ _Py_Check_ArgsIterable(): │ mov0x18(%rdx),%rax │ cmpq $0x0,0xe8(%rax) │ je 1ed20 <_Py_Check_ArgsIterable+0x20> │ xor%eax,%eax │ ret │ nopl 0x0(%rax) │ data16 cs nopw 0x0(%rax,%rax,1) │ push %r15 │ push %r14 │ push %rbx │ mov%rdi,%rbx │ sub$0x10,%rsp │ mov%rdx,%rdi │ mov%rdx,%r15 │ mov%rsi,%r14 │ call 1ed3a <_Py_Check_ArgsIterable+0x3a> │ R_X86_64_PLT32 PySequence_Check-0x4 │ test %eax,%eax │ je 1ed4a <_Py_Check_ArgsIterable+0x4a> │ xor%eax,%eax │ add$0x10,%rsp │ pop%rbx │ pop%r14 │ pop%r15 │ ret │ mov%rbx,%rdi │ call 1ed52 <_Py_Check_ArgsIterable+0x52> │ R_X86_64_PLT32 _PyErr_Clear-0x4 With -fprofile-generate: +18d0 <_Py_Check_ArgsIterable>: │ +_Py_Check_ArgsIterable(): │ + sub$0x28,%rsp │ + mov0x0(%rip),%rax │ + R_X86_64_GOTTPOFF __gcov_indirect_call-0x4 │ + mov%rdi,%r9 │ + mov%rsi,%rcx │ + cmpq $0x0,%fs:(%rax) │ + jne1920 <_Py_Check_ArgsIterable+0x50> │ + cmpq $0x0,0x0(%rip) │ + R_X86_64_PC32 .bss+0xb6fb │ + je 1960 <_Py_Check_ArgsIterable+0x90> │ + mov0x18(%rdx),%rax │ + cmpq $0x0,0xe8(%rax) │ + je 1990 <_Py_Check_ArgsIterable+0xc0> │ + incq 0x0(%rip) │ + R_X86_64_PC32 .bss+0xb734 │ + xor%eax,%eax │ + add$0x28,%rsp │ + ret │ + nopl (%rax) │ + data16 cs nopw 0x0(%rax,%rax,1) │ + mov%rsi,0x10(%rsp) │ + mov%rdi,0x8(%rsp) │ + lea0x0(%rip),%rsi │ + R_X86_64_PC32 _Py_Check_ArgsIterable-0x4 │ + mov$0x4f5d9de8,%edi │ + mov%rdx,0x18(%rsp) │ + call 1940 <_Py_Check_ArgsIterable+0x70> │ + R_X86_64_PLT32 __gcov_indirect_call_profiler_v4-0x4 │ + cmpq $0x0,0x0(%rip) │ + R_X86_64_PC32 .bss+0xb6fb │ + mov0x18(%rsp),%rdx │ + mov0x10(%rsp),%rcx │ + mov0x8(%rsp),%r9 │ + jne18f2 <_Py_Check_ArgsIterable+0x22> │ + nopl 0x0(%rax) │ + mov0x0(%rip),%rax │ + R_X86_64_PC32 __gcov_time_profiler_counter-0x4 │ + inc%rax │ + mov%rax,0x0(%rip) │ + R_X86_64_PC32 __gcov_time_profiler_counter-0x4 │ + mov%rax,0x0(%rip) │ + R_X86_64_PC32 .bss+0xb6fc │ + mov0x18(%rdx),%rax │ + cmpq $0x0,0xe8(%rax) │ + jne1904 <_Py_Check_ArgsIterable+0x34> │ + nopw 0x0(%rax,%rax,1) │ + mov%rdx,%rdi [...]
[Bug c++/120243] [15/16 Regression] Exception rethrown from coroutine promise type unhandled_exception not caught under -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120243 --- Comment #10 from Iain Sandoe --- (In reply to Jason Merrill from comment #9) > (In reply to Jason Merrill from comment #8) > > Iain, will you backport r16-1507? > > Actually, I'll do it. that's fine too - my plan is to back port the stack of changes made on trunk rather than doing piecemeal - to try and avoid churn..
[Bug target/121013] Possible miscompilation triggered by __builtin_stack_address() at `-O3`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121013 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target||x86_64 Resolution|--- |INVALID Component|middle-end |target --- Comment #2 from Andrew Pinski --- __builtin_stack_address was added to support stack scrubbing: https://inbox.sourceware.org/gcc-patches/orpmti5ikv@lxoliva.fsfla.org/ So reading the user level documentation and the original patch. Both addresses are correct. Specifically this part is the documentation: "Arguments for a callee ___may___ be ___preallocated___ as part of the caller’s stack frame, or allocated on a __per-call__ basis, depending on the target, so they may be on either side of this boundary." In this case it is not only depending on the target but also which optimization level and other options for x86.
[Bug middle-end/121000] __builtin_dynamic_object_size should work for FAM with VLA element when annotated with counted_by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Why do you need CLASS_OF_SIZE argument? If count is in bytes, simply pass 1 to the TYPE_SIZE_UNIT argument. ACCESS_MODE can be in the same argument as TYPE_OF_SIZE, type of the INTEGER_CST will be TYPE_OF_SIZE, while the value can be the -1/0/1/2/3 access mode. If you need further flags, just or them in (either change -1 to 4, or use say -4/0/4/8/12 for ACCESS_MODE and low 2 bits for other flags).
[Bug c++/121016] New: coroutine appears to be allergic to {()}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
Bug ID: 121016
Summary: coroutine appears to be allergic to {()}
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: beewoolie at proton dot me
Target Milestone: ---
Greetings,
I will attach the preprocessed source to this message. I think I see what the
compiler doesn't accept.
/** *** FIXME: code generates a compiler error when enclosed in ({}) */
#define COTHREAD_PROTOTHREAD(f) ({ \
using namespace Glow::Cothreads; \
int result = Completed; \
do { \
int v = f; \
result = Completed; \
if (v & THREAD_READY)result = Yielded; \
if (v & THREAD_BLOCKED) result = Blocked; \
if (v & THREAD_SLEEPING) result = Sleeping; \
if (result != Completed)\
co_yield cothread_result{result}; \
} while (result != Completed); })
When this macro body is enclosed in ({}), the compiler throws an error.
COMPILE projects/blink/blink.cc
projects/blink/blink.cc: In function 'void
Console::cothread_main_console(cothread_main_console(Glow::Cothreads::cothread_corral&,
const
char*)::_ZN7Console21cothread_main_consoleERN4Glow9Cothreads6corralINS1_15cothread_resultEEEPKc.Frame*)':
projects/blink/blink.cc:242:3: internal compiler error: in
gimplify_var_or_parm_decl, at gimplify.cc:3308
242 | }
| ^
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug target/121019] New: Explore removal of DI patterns for rv32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121019
Bug ID: 121019
Summary: Explore removal of DI patterns for rv32
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
rv32 has 32bit GPRs, yet the port defines DI patterns. In the past that was
commonplace to improve performance, but it can sometimes be harmful.
So the goal is to evaluate if removing the DI mode patterns for rv32 would be
helpful in general and to address any regressions arising as a result.
The testcase that motivated me to dive into this problem is:
void bar (long long);
long long foo(int x0, int x1, int x2, int x3, int x4, int x5, int x6,long long
partial) { return partial; }
We get something like this:
addisp,sp,-16
sw a7,12(sp)
lw a0,12(sp)
lw a1,16(sp)
addisp,sp,16
jr ra
The DI mode operation hides the underlying operations from CSE and as a result
CSE is unable to clean things up, particularly memory operations involving
@12(sp). Better code would be:
addisp,sp,-16 # 31[c=4 l=4] *addsi3/1
lw a1,16(sp) # 23[c=28 l=4] *movsi_internal/2
mv a0,a7 # 28[c=4 l=4] *movsi_internal/0
addisp,sp,16# 35[c=4 l=4] *addsi3/1
jr ra # 36[c=0 l=4] simple_return_internal
[Bug target/121015] [16 regression] ICE when building blender for x86_64 with -O3 -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121015 H.J. Lu changed: What|Removed |Added Last reconfirmed||2025-07-09 Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from H.J. Lu --- Created attachment 61827 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61827&action=edit A patch Please try this.
[Bug c++/121021] Move -Wuninitialized from -Wextra to -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021 --- Comment #5 from Žarko Asen --- in my case (C++ 20) -Wunitialized was not enabled by -Wall therefore a critical bug slip through: const uint32_t x = x + 1; // where is a novel variable in the local and global scope This should have been caught by -Wall and it wasn't. G++14.2.0 C++20 -Wall -pedantic -Werror regards, Zarko Asen ase...@gmail.com On Thu, Jul 10, 2025 at 4:24 AM pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121021 > > Andrew Pinski changed: > >What|Removed |Added > > > Status|UNCONFIRMED |RESOLVED > Resolution|--- |INVALID >See Also|| > https://gcc.gnu.org/bugzill >||a/show_bug.cgi?id=117009 > > --- Comment #4 from Andrew Pinski --- > It is a little more complex than this. > > It is enabled by both -Wall and -Wextra. > > For all languages it is enabled by -Wextra. > > For Fortran and C/C++ (and objc/objc++) it is enabled by -Wall . > > The -Wall is a language specific flag which causes confusion really. But > that > is recorded as PR 117009. > > The LTO issue of -Wall not enabling -Wuninitialize is recorded as PR 90844 > (but > that is still -Wall really) > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/121016] coroutine appears to be allergic to {()}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115851 --- Comment #2 from Andrew Pinski --- Yes statement expressions are not fully supported with coroutines yet. See PR 115851 and bug 102508 for other issues related to statement expressions with coroutines .
[Bug c++/121016] coroutine vs statement expressions ({})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016 --- Comment #4 from Marc Singer --- I found that there are cases in the same program where it does compile.
[Bug c++/121016] coroutine vs statement expressions ({})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
--- Comment #3 from Andrew Pinski ---
I think you could just use do { } while(0) instead of a statement expression
here.
That is:
#define COTHREAD_PROTOTHREAD(f) do {\
using namespace Glow::Cothreads; \
int result = Completed; \
do { \
int v = f; \
result = Completed; \
if (v & THREAD_READY)result = Yielded; \
if (v & THREAD_BLOCKED) result = Blocked; \
if (v & THREAD_SLEEPING) result = Sleeping; \
if (result != Completed)\
co_yield cothread_result{result}; \
} while (result != Completed); } while (false)
[Bug c++/121016] coroutine vs statement expressions ({})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016 --- Comment #5 from Andrew Pinski --- (In reply to Marc Singer from comment #4) > I found that there are cases in the same program where it does compile. Yes there might be some cases where statement expressions will work but we know there are bugs with the statement expression extension that does not get along with coroutines.
[Bug c++/121016] coroutine vs statement expressions ({})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121016
--- Comment #6 from Marc Singer ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Marc Singer from comment #4)
> > I found that there are cases in the same program where it does compile.
>
> Yes there might be some cases where statement expressions will work but we
> know there are bugs with the statement expression extension that does not
> get along with coroutines.
...in fact, I was just chasing an error in the program execution. It compiled
with the statement expression, but it didn't evaluate correctly. Removing that
form fixed the bug.
And, yes, of course, we can fall-back to the ol' standby do{}while(false);
Thanks.
[Bug middle-end/121017] New: `__builtin_copysign(0.0, a)` should be optimized to 0.0 for -fno-signed-zeros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121017
Bug ID: 121017
Summary: `__builtin_copysign(0.0, a)` should be optimized to
0.0 for -fno-signed-zeros
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
>From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004#c7 :
```
float f(float a)
{
return __builtin_copysignf(0.0, a);
}
```
This should just be 0.0 with -fno-signed-zeros
[Bug middle-end/121017] `__builtin_copysign(0.0, a)` should be optimized to 0.0 for -fno-signed-zeros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121017 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/121004] float_var*0.0f if we know a is finite be just done as copysign(0.0, a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004 --- Comment #8 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #7) > And obviously for -fno-signed-zeros optimize the copysign to just 0. Filed as PR 121017.
[Bug c++/119328] ICE on generic lambda with defaulted parameter in requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119328 --- Comment #3 from eczbek.void at gmail dot com --- This no longer appears to ICE but still errors: https://godbolt.org/z/699vW5dhn
