[Bug c++/120056] New: Circular constraint satisfaction error with non-trivial container iterators to callables taking std::expected parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120056
Bug ID: 120056
Summary: Circular constraint satisfaction error with
non-trivial container iterators to callables taking
std::expected parameters
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: catsith at me dot com
Target Milestone: ---
Created attachment 61265
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61265&action=edit
example .ii
$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/15.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.1.1 20250425 (GCC)
$ cat > gcc.cpp
#include
#include
int main() {
// std::expected template arguments don't matter
using func = void (*)(std::expected);
// fails with std::deque, std::list, std::vector; works with std::array
std::vector v;
return v.begin() == v.end();
}
$ g++ -std=c++23 -save-temps gcc.cpp
In file included from gcc.cpp:1:
/usr/include/c++/15.1.1/expected: In substitution of ‘template
requires !(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u)
{{__t == __u} -> decltype(auto) [requires std::convertible_to<,
bool>];} constexpr bool std::operator==(const expected&, const _Up&)
[with _Up = __gnu_cxx::__normal_iterator),
std::vector)> >]’:
/usr/include/c++/15.1.1/expected:1175:12: required by substitution of
‘template requires !(__is_expected<_Up>) && requires(const _Tp&
__t, const _Up& __u) {{__t == __u} -> decltype(auto) [requires
std::convertible_to<, bool>];} constexpr bool
std::operator==(const expected&, const _Up&) [with _Up =
__gnu_cxx::__normal_iterator),
std::vector)> >]’
1175 | { __t == __u } -> convertible_to;
| ^~
gcc.cpp:9:29: required from here
9 | return v.begin() == v.end();
| ^
/usr/include/c++/15.1.1/expected:1178:2: required by the constraints of
‘template template requires
!(__is_expected<_Up>) && requires(const _Tp& __t, const _Up& __u) {{__t == __u}
-> decltype(auto) [requires std::convertible_to<, bool>];}
constexpr bool std::operator==(const expected<_Tp, _Er>&, const _Up&)’
/usr/include/c++/15.1.1/expected:1174:7: in requirements with ‘const _Tp&
__t’, ‘const _Up& __u’ [with _Tp = int; _Up = __gnu_cxx::__normal_iterator), std::vector),
std::allocator)> > >]
/usr/include/c++/15.1.1/expected:1174:14: error: satisfaction of atomic
constraint ‘requires(const _Tp& __t, const _Up& __u) {{__t == __u} ->
decltype(auto) [requires std::convertible_to<, bool>];} [with _Tp
= _Tp; _Up = _Up]’ depends on itself
1174 | && requires (const _Tp& __t, const _Up& __u) {
| ^~~
1175 | { __t == __u } -> convertible_to;
| ~~~
1176 | }
| ~
[Bug c/120055] New: ice in convert_arguments with recent compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120055 Bug ID: 120055 Summary: ice in convert_arguments with recent compiler Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 61264 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61264&action=edit C source code For the attached C code, recent gcc trunk does this: foundBugs $ ../results/bin/gcc -c -w -std=gnu99 bug1098.c /home/dcb40b/rpmbuild/BUILD/cqueues-rel-20200603/src/lib/dns.c: In function ‘dns _rr_i_start’: /home/dcb40b/rpmbuild/BUILD/cqueues-rel-20200603/src/lib/dns.c:2810:17: internal compiler error: Segmentation fault 2810 | if (i->sort(&rr, &r0, i, P) < 0) | ^~ 0x23a594e ??? /home/dcb40b/gcc/working/gcc/../../trunk/gcc/diagnostic-global-context.c c:517 0xf8d169 ??? /home/dcb40b/gcc/working/gcc/../../trunk/gcc/toplev.cc:321 0x7bef88 tree_check ../../trunk/gcc/tree.h:3979 0x7bef88 fndecl_built_in_p ../../trunk/gcc/tree.h:6922 0x7bef88 convert_arguments /home/dcb40b/gcc/working/gcc/../../trunk/gcc/c/c-typeck.cc:4340 The bug seems to have started in the last few days: foundBugs $ ../results.20250430.ubsan/bin/gcc -c -w -std=gnu99 bug1098.c foundBugs $ ../results.20250501.ubsan/bin/gcc -c -w -std=gnu99 bug1098.c /home/dcb40b/rpmbuild/BUILD/cqueues-rel-20200603/src/lib/dns.c: In function ‘dns _rr_i_start’: /home/dcb40b/rpmbuild/BUILD/cqueues-rel-20200603/src/lib/dns.c:2810:17: internal compiler error: Segmentation fault Further: foundBugs $ ../results.20250430.ubsan/bin/gcc -v 2>&1 | grep exp gcc version 16.0.0 20250430 (experimental) (8709d6a17830c8a9) foundBugs $ ../results.20250501.ubsan/bin/gcc -v 2>&1 | grep exp gcc version 16.0.0 20250501 (experimental) (87c4460024dadef0) foundBugs $
[Bug c/120055] [16 Regression] ice in convert_arguments with recent compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120055 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=119950 Last reconfirmed||2025-05-01 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Also reported here: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682427.html
[Bug c/120055] [16 Regression] ice in convert_arguments with recent compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120055 Andrew Pinski changed: What|Removed |Added Version|15.0|16.0 Summary|ice in convert_arguments|[16 Regression] ice in |with recent compiler|convert_arguments with ||recent compiler Keywords|needs-bisection | Target Milestone|--- |16.0
คุณเดือดร้อน เราช่วยคุณได้ ไม่มีโอนก่อนไม่มีมัดจำ
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 LIU Hao changed: What|Removed |Added Attachment #61251|0 |1 is obsolete|| --- Comment #36 from LIU Hao --- Created attachment 61261 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61261&action=edit final patch 1. Decrease preferred stack alignment from 16 bytes to 4 bytes. The default incoming stack alignment is initialized to this value, so it's also decreased. 2. Make `force_align_arg_pointer` attribute increase preferred alignment to at least 16 bytes, to maintain backward compatibility.
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #38 from LIU Hao --- (In reply to Eric Botcazou from comment #37) > You may want to revert the previous change though. What's the difference between the `-mstackrealign` option and the `force_align_arg_pointer` attribute? I'm quite confused by `-mstackrealign`: It could mean to realign the stack either to the preferred alignment (of every function), or to the required alignment, or just to at least 16 bytes. Without the final patch, the preferred alignment is 16 bytes, but unless a local variable requires 16-byte alignment, no stack realignment actually happens; even when a local variable requires 8-byte alignment (comment #23), the stack is still not aligned to an 8-byte boundary.
[Bug libstdc++/116140] [15/16 Regression] 5-10% slowdown of 483.xalancbmk and 523.xalancbmk_r since r15-2356-ge69456ff9a54ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140 --- Comment #20 from Tamar Christina --- We're currently working on it. The improvements come from architectures where the code vectorized. The performance losses come from those where it didn't vectorize, or the vectorizer generated inefficient code. The GCC RTL unroller isn't very efficient, and that's where the LLVM gain comes from.
[Bug tree-optimization/119044] [15 regression] 5-16% slowdown of 436.cactusADM since r15-7665-gee30e2586a3142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119044 --- Comment #5 from Filip Kastl --- Nice. From the graph it looks like this helped a lot.
[Bug c/120051] New: codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051
Bug ID: 120051
Summary: codeview ICE/segfault starting with 15.1.0
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
Target Milestone: ---
$ gcc -dumpmachine
x86_64-w64-mingw32
$ cat test.c
// gcc -O1 -gcodeview -c test.c
void a();
static void b();
void c() { b(); }
void b() { a(); }
$ gcc -O1 -gcodeview -c test.c
test.c:5:1: internal compiler error: Segmentation fault
5 | void b() { a(); }
| ^~~~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See for instructions.
Let me know if there is anything else I can provide.
Downstream issue: https://github.com/msys2/MINGW-packages/issues/24148
[Bug ada/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698 --- Comment #9 from Eric Botcazou --- > also seen with gcc-13 What do you mean exactly here? That it cannot compile GCC 12, or itself, or GCC 15 or...?
[Bug ipa/120048] [16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com
Priority|P3 |P1
Blocks||119712
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
[Bug 119712] [14/15/16 Regression] compiler hang at -O{1,2,3,s} since r14-5109
[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048
Richard Biener changed:
What|Removed |Added
Summary|[16 Regression] ICE on |[14/15/16 Regression] ICE
|valid code at -O{s,2} with |on valid code at -O{s,2}
|"-fno-tree-vrp |with "-fno-tree-vrp
|-fno-tree-fre" on |-fno-tree-fre" on
|x86_64-linux-gnu: in type, |x86_64-linux-gnu: in type,
|at value-range.h:982|at value-range.h:982
Target Milestone|16.0|14.3
--- Comment #4 from Richard Biener ---
The offending change was backported to GCC 14 and 15, it doesn't reproduce on
the 14 branch but on the 15 branch.
[Bug ipa/120044] [12/13/14/15/16 Regression] wrong code at -O1 and above with "-fno-early-inlining -fno-tree-fre -fno-tree-pre -fno-code-hoisting" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120044
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
||jamborm at gcc dot gnu.org
Priority|P3 |P2
--- Comment #3 from Richard Biener ---
Looks like IPA CP + SRA and the resulting replacements during inlining end up
writing to the const 'c' somehow:
int main ()
{
struct a e;
const int g$b;
char _3;
int _4;
short unsigned int _5;
int _6;
[local count: 1073741824]:
g$b_2 = 0;
_3 = (char) g$b_2;
_4 = (int) _3;
c.b = g$b_2;
e = c;
[Bug c++/120012] [12/13/14/15/16 Regression] P1008R1 causes tail padding reuse in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120012 --- Comment #3 from Jason Merrill --- (In reply to Richard Biener from comment #2) > going to be interesting to decide what to do on branches ... does it affect > the ABI of any part of libstdc++, in the shared object or instantiated > templates in libraries using libstdc++? It seems not to affect libstdc++; the warning I've implemented doesn't fire when building the shared object or running the testsuite. On branches I'm thinking to give the warning under -Wabi=0. It's awkward that plain -Wabi currently gives a warning, though that could change. I suppose we could also add non-default -fabi-version=21 to GCC 15 for only this change, and bump other GCC 16 changes to 22, but I'm not sure how worthwhile that would be. I don't think we can change the default GCC 15 ABI at this point.
[Bug c++/110871] coroutine precondition should be evaluated before the initial suspend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.3
[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #3 from Jerry DeLisle --- I should mention That this issue was first identified by Vincent Magnin. Vincent has also confirmed the issue on gfortran 11.5 on Ubuntu. There is also a variation where it compiles and segfaults at run time. I am traveling the next few days so not sure I will get back to further reducing for a bit.
[Bug c++/120052] New: internal compiler error: in scan_omp_1_op, at omp-low.cc:4005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120052
Bug ID: 120052
Summary: internal compiler error: in scan_omp_1_op, at
omp-low.cc:4005
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
UBSan + OpenMP ICE
C-Vise reduced test case, compile with -fsanitize=undefined -fopenmp.
void copy_n(int, long, int);
unsigned long n_ranks;
long rank;
enum { TYPE_COUNT } ingest_data___trans_tmp_1;
auto ingest_data() {
long counts[TYPE_COUNT][n_ranks];
#pragma omp parallel
for (int i;;)
copy_n(ingest_data___trans_tmp_1, counts[i][rank], 0);
}
This only triggers with **both** UBSan and OpenMP.
Live: https://godbolt.org/z/oKqa6jMrq [May 1st, 2025]
[Bug rtl-optimization/116564] [12 Regression] aarch64: gcc hangs when compiling vst2_f64 instrinsic at -O1 and above since r12-4910-g66f206b853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564
--- Comment #13 from GCC Commits ---
The releases/gcc-12 branch has been updated by Alex Coplan
:
https://gcc.gnu.org/g:91be90b5ae9ee345bd011afdf02df7003d7598d3
commit r12-11082-g91be90b5ae9ee345bd011afdf02df7003d7598d3
Author: Alex Coplan
Date: Mon Mar 10 16:44:15 2025 +
df: Treat partial defs as uses in df_simulate_defs [PR116564]
The PR shows us spinning in dce.cc:fast_dce at the start of combine.
This spinning appears to be because of a disagreement between the fast_dce
code
and the code in df-problems.cc:df_lr_bb_local_compute. Specifically, they
disagree on the treatment of partial defs. For the testcase in the PR, we
have
the following insn in bb 3:
(insn 10 8 13 3 (clobber (subreg:V1DF (reg/v:V2x1DF 104 [ __val ]) 8)) -1
(nil))
which gives rise to a DF def with DF_REF_FLAGS = 0x8b0, i.e.
DF_REF_PARTIAL | DF_REF_READ_WRITE | DF_REF_MUST_CLOBBER | DF_REF_SUBREG.
Eliding the large block comment for readability, the code in
df_lr_bb_local_compute does the following (for each insn):
FOR_EACH_INSN_INFO_DEF (def, insn_info)
{
unsigned int dregno = DF_REF_REGNO (def);
bitmap_set_bit (&bb_info->def, dregno);
if (DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL))
bitmap_set_bit (&bb_info->use, dregno);
else
bitmap_clear_bit (&bb_info->use, dregno);
}
i.e. it models partial defs as a RMW operation; thus for the def arising
from i10 above, it records a use of r104; hence it ends up in the
live-in set for bb 3.
However, as it stands, the code in dce.cc:fast_dce (and its callee
dce_process_block) has no such provision for DF_REF_PARTIAL defs. It
does not treat these as a RMW and does not compute r104 above as being
live-in to bb 3. At the end of dce_process_block we compute the
following "did something happen" condition used to decide termination of
the analysis:
block_changed = !bitmap_equal_p (local_live, DF_LR_IN (bb));
if (block_changed)
bitmap_copy (DF_LR_IN (bb), local_live);
BITMAP_FREE (local_live);
return block_changed;
because of the disagreement between df_lr_local_compute and the local
analysis done by fast_dce, we invariably have r104 in DF_LR_IN, but not
in local_live. Hence we always return true here, call
df_analyze_problem (which re-computes DF_LR_IN according to
df_lr_bb_local_compute, re-adding r104), and so the analysis never
terminates.
This patch therefore adjusts df_simulate_defs (called from
dce_process_block) to match the behaviour of df_lr_bb_local_compute in
this respect, namely we make it model partial defs as RMW operations by
setting the relevant register live. This fixes the spinning in fast_dce
for this testcase.
gcc/ChangeLog:
PR rtl-optimization/116564
* df-problems.cc (df_simulate_defs): For partial defs, mark the
register live (treat it as a RMW operation).
gcc/testsuite/ChangeLog:
PR rtl-optimization/116564
* gcc.target/aarch64/torture/pr116564.c: New test.
(cherry picked from commit 758e617bcf224dc9d4a7e26dd858d43c1e63b916)
[Bug rtl-optimization/116564] [12 Regression] aarch64: gcc hangs when compiling vst2_f64 instrinsic at -O1 and above since r12-4910-g66f206b853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116564 Alex Coplan changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Alex Coplan --- Fixed on all active branches.
[Bug c++/120012] [12/13/14/15/16 Regression] P1008R1 causes tail padding reuse in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120012 --- Comment #4 from Jason Merrill --- (In reply to Jason Merrill from comment #3) > On branches I'm thinking to give the warning under -Wabi=0. It's awkward > that plain -Wabi currently gives a warning, though that could change. That is, since r9-1232-g5cef3733596c64 plain -Wabi warns that it won't warn about anything.
[Bug c++/120052] internal compiler error: in scan_omp_1_op, at omp-low.cc:4005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120052 --- Comment #1 from Andrew Pinski --- Created attachment 61262 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61262&action=edit Cleaned up and reduced testcase
[Bug fortran/119948] Source allocation of pure function result rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #13 from paul.richard.thomas at gmail dot com --- Oh s***t! Don't do that - post in the existing PR. I must confess that I looked at the second testcase and couldn't see the difference. I'll put stronger glasses on. Thanks Paul On Thu, 1 May 2025 at 16:57, kargls at comcast dot net < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 > > --- Comment #12 from kargls at comcast dot net --- > On 5/1/25 07:45, pault at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 > > > > --- Comment #11 from Paul Thomas --- > > (In reply to GCC Commits from comment #10) > >> The master branch has been updated by Paul Thomas : > > > > I will close as fixed if no appetite for backporting is expressed in the > next > > week. > > > > Your patch does not fix pr119948_2.f90 from my patch. I'll submit > a new PR. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/120052] VLA with OpenMP vs -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120052 --- Comment #2 from Andrew Pinski --- during GIMPLE pass: omplower dump file: /app/output.cpp.010t.omplower : In function 'f': :5:14: internal compiler error: in scan_omp_1_op, at omp-low.cc:4005 5 | counts[i][indx] = 1; | ~^~
[Bug c++/120052] VLA with OpenMP vs -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120052 --- Comment #3 from Andrew Pinski --- gcc_checking_assert (TREE_CODE (repl) != ERROR_MARK); This is due to s.1 not being recorded in the #pragma: #pragma omp parallel firstprivate(counts.3) firstprivate(D.3444) private(counts) firstprivate(indx) [child fn: f._omp_fn.0 (???)] .UBSAN_BOUNDS (0B, indx.5, s.1);
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 114411, which changed state. Bug 114411 Summary: [14/15/16 Regression] 12% exec time slowdown of 433.milc on aarch64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114411 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/114411] [14/15/16 Regression] 12% exec time slowdown of 433.milc on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114411 Filip Kastl changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Filip Kastl --- Closing.
[Bug middle-end/120052] [13/14/15/16 Regression] VLA with OpenMP vs -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120052 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #5 from mcccs at gmx dot com --- Bisection bad commit: r13-6375-gc7728805a71074
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #39 from Eric Botcazou --- > What's the difference between the `-mstackrealign` option and the > `force_align_arg_pointer` attribute? -mstackrealign (ix86_force_align_arg_pointer) is only used here: /* In 32bit, use MIN_STACK_BOUNDARY for incoming stack boundary if -mstackrealign is used, it isn't used for sibcall check and estimated stack alignment is 128bit. */ else if (!sibcall && ix86_force_align_arg_pointer && crtl->stack_alignment_estimated == 128) incoming_stack_boundary = MIN_STACK_BOUNDARY; force_align_arg_pointer works for any alignment, not just 128-bit. > I'm quite confused by `-mstackrealign`: It could mean to realign the stack > either to the preferred alignment (of every function), or to the required > alignment, or just to at least 16 bytes. Without the final patch, the > preferred alignment is 16 bytes, but unless a local variable requires > 16-byte alignment, no stack realignment actually happens; even when a local > variable requires 8-byte alignment (comment #23), the stack is still not > aligned to an 8-byte boundary. In practice -mstackrealign forces stack alignment to 16-byte (because it's the preferred alignment) of every function that requires 16-byte alignment. So it has no effects for 8-byte alignment, but that's mostly OK in practice.
[Bug ada/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2025-05-01 Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|WONTFIX |--- --- Comment #13 from Eric Botcazou --- Yes, something appears quite broken here.
[Bug tree-optimization/119965] [16 Regression] 531.deepsjeng_r binary is 50% bigger since r16-116-gcfb04e0de6aa43
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119965 --- Comment #1 from Filip Kastl --- Here is a graph showing this code size increase. https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=293.378.4
[Bug ada/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698 --- Comment #10 from Eric Botcazou --- FIWI I cannot reproduce with GCC 12 on x86-64/Linux and Valgrind is silent (it is usually very good at catching finalization issues), so this may be more a code generation issue on the PA than an Ada issue. What do the results of the Ada testsuite look like there for GCC 12?
[Bug target/120027] Missing simplifications of SVE uxtb intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120027 --- Comment #1 from ktkachov at gcc dot gnu.org --- Note Clang is working on improving some of the cases on their side https://github.com/llvm/llvm-project/pull/137956
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #37 from Eric Botcazou --- You may want to revert the previous change though.
[Bug libstdc++/119282] [15 Regression] views::transform producing ranges piped to views::join | ranges::to() fails to compile in constant evaluation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119282
--- Comment #6 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:9f523d49ada91050445f71821a9a06b0988402f5
commit r16-332-g9f523d49ada91050445f71821a9a06b0988402f5
Author: Patrick Palka
Date: Thu May 1 11:40:44 2025 -0400
c++: poor diag w/ non-constexpr dtor called from constexpr ctor
When diagnosing a non-constexpr constructor call during constexpr
evaluation, explain_invalid_constexpr_fn was passing the genericized
body to require_potential_constant_expression rather than the saved
non-genericized one.
This meant for the below testcase (reduced from PR libstdc++/119282)
in which B::B() is deemed non-constexpr due to the local variable having
a non-constexpr destructor we would then issue the cryptic diagnostic:
constexpr-nonlit19.C:17:16: error: non-constant condition for static
assertion
17 | static_assert(f());
| ~^~
constexpr-nonlit19.C:17:16: in âconstexprâ expansion of âf()â
constexpr-nonlit19.C:13:5: error: âconstexpr B::B()â called in a
constant expression
13 | B b;
| ^
constexpr-nonlit19.C:6:13: note: âconstexpr B::B()â is not usable as a
âconstexprâ function because:
6 | constexpr B() {
| ^
constexpr-nonlit19.C:8:5: error: âgotoâ is not a constant expression
8 | for (int i = 0; i < 10; i++) { }
| ^~~
This patch makes us pass the non-genericized body to
require_potential_constant_expression, and so we now emit:
...
constexpr-nonlit19.C:6:13: note: âconstexpr B::B()â is not usable as a
âconstexprâ function because:
6 | constexpr B() {
| ^
constexpr-nonlit19.C:9:3: error: call to non-âconstexprâ function
âA::~A()â
9 | }
| ^
constexpr-nonlit19.C:3:12: note: âA::~A()â declared here
3 | struct A { ~A() { } };
|^
gcc/cp/ChangeLog:
* constexpr.cc (explain_invalid_constexpr_fn): In the
DECL_CONSTRUCTOR_P branch pass the non-genericized body to
require_potential_constant_expression.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/constexpr-nonlit19.C: New test.
Reviewed-by: Jason Merrill
[Bug c++/120053] New: __is_trivially_constructible() requiring default member initializer unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120053
Bug ID: 120053
Summary: __is_trivially_constructible() requiring default
member initializer unnecessarily
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thiago at kde dot org
Target Milestone: ---
Testcase:
#include
template struct QThreadStorageTraits { };
template struct QThreadStorage
{
using Trait =
QThreadStorageTraits>;
};
struct QQuick3DProfilerSceneGraphData
{
struct Timings {
unsigned nesting = 0;
};
template
struct TimingData
{
Timings timings[size];
};
QThreadStorage> eventTimings;
};
With GCC 14, 15 and trunk (in Godbolt), this produces:
type_traits:3584:7: error: default member initializer for
'QQuick3DProfilerSceneGraphData::Timings::nesting' required before the end of
its enclosing class
3584 | = __is_trivially_constructible(_Tp);
| ^
This doesn't make sense. It looks like an internal state bug.
Godbolt run: https://gcc.godbolt.org/z/6nf7sGMP7
Fortunately, this identified a type that ought to have been trivial and wasn't.
[Bug c++/96645] [12/13/14/15/16 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Andrew Pinski changed: What|Removed |Added CC||thiago at kde dot org --- Comment #33 from Andrew Pinski --- *** Bug 120053 has been marked as a duplicate of this bug. ***
[Bug c++/120053] __is_trivially_constructible() requiring default member initializer unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120053 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 96645 ***
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 102199, which changed state. Bug 102199 Summary: is_default_constructible incorrect for an inner type with NSDMI https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102199 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 96645 ***
[Bug c++/96645] [12/13/14/15/16 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Andrew Pinski changed: What|Removed |Added CC||roi.jacobson1 at gmail dot com --- Comment #35 from Andrew Pinski --- *** Bug 108588 has been marked as a duplicate of this bug. ***
[Bug c++/96645] [12/13/14/15/16 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Andrew Pinski changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #36 from Andrew Pinski --- *** Bug 113008 has been marked as a duplicate of this bug. ***
[Bug c++/108588] __is_constructible returns wrong value for invalid (but non deleted) default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108588 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 96645 ***
[Bug c++/96645] [12/13/14/15/16 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #34 from Andrew Pinski --- *** Bug 102199 has been marked as a duplicate of this bug. ***
[Bug c++/113008] Trivially default constructible requires default member initializer before the end of its enclosing class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113008 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- No it is a dup. *** This bug has been marked as a duplicate of bug 96645 ***
[Bug fortran/119948] Source allocation of pure function result rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #15 from Paul Thomas --- (In reply to kargls from comment #14) > HI Paul, > > The difference in my pr119948_1.f90 and pr119948_2.f90 is > that the former is Damian's testcase with a result-name > while latter does not use result-name so the function-name > is the result variable. Both tests use a 'module procedure' > construct. I did look at your patch (but obviously did not > test it) and thought it would catch the latter. > > Your patch does catch issues with subroutine while my > original patch does not deal with subroutines. Hi Steve, I feel beyond stupid - it's not even a matter of the strength of my glasses :-( I have taken your chunk from primary.cc and rolled the two tests into one. It's regtesting right now. Thanks Paul
[Bug libstdc++/101227] Clang++ fails to instantiate std::optional if nested type has a non-static data member initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101227 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 96645 ***
[Bug c++/96645] [12/13/14/15/16 Regression] [CWG2335] std::variant default constructor and unparsed DMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Andrew Pinski changed: What|Removed |Added CC||florin at iucha dot net --- Comment #37 from Andrew Pinski --- *** Bug 101227 has been marked as a duplicate of this bug. ***
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 101227, which changed state. Bug 101227 Summary: Clang++ fails to instantiate std::optional if nested type has a non-static data member initializer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101227 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/120053] __is_trivially_constructible() requiring default member initializer unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120053 --- Comment #2 from Andrew Pinski --- >This doesn't make sense. It looks like an internal state bug. It is not. It is more complex because the inner type is not exactly completed until the outer one is.
[Bug c++/120039] [15/16 Regression] Structured binding in condition ICE since r15-1793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120039 Richard Biener changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Priority|P3 |P4
[Bug tree-optimization/120043] [15/16 Regression] wrong code at -O{s,2,3} with -fallow-store-data-races on x86_64-linux-gnu since r15-1391-g4b75ed33fa5fd6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120043 Richard Biener changed: What|Removed |Added Version|unknown |15.1.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener --- I'll have a look. Yes, tree_could_trap_p does not know whether it sees a load or a store. OTOH another issue is that we turn *b = 1 into a = 1 with conditional propagation: [local count: 1073741824]: b.1_1 = b; if (b.1_1 != &a) goto ; [70.00%] else goto ; [30.00%] [local count: 322122544]: a = 1; [local count: 1073741824]: return 0; handling this in tree_could_trap_p conservatively would be quite prohibiting. There is ifcvt_memrefs_wont_trap from if-conversion that handles this case correctly (but it uses flow analysis to improve results). I'll see to fix cselim and enhance tree_could_trap_p with a lhs_p flag.
[Bug rtl-optimization/120046] [15/16 Regression] wrong code at -O{s,2} with "-fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre -fno-expensive-optimizations -fno-gcse" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120046 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Priority|P3 |P2
[Bug target/120036] [16 Regression] ICE on highway-1.2.0: during RTL pass: rrvl: in gen_rtx_SUBREG, at emit-rtl.cc:1032 since r16-271-gd1cada7481420a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120036 --- Comment #6 from Sergei Trofimovich --- (In reply to H.J. Lu from comment #5) > A patch is posted at > > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682360.html The change fixes both build and tests for highway-1.2.0 for me on x86_64-linux. Thank you!
[Bug ipa/120048] [16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #3 from mcccs at gmx dot com --- Bisection bad commit: r16-244-gce489c870bf28e
[Bug tree-optimization/119044] [15 regression] 5-16% slowdown of 436.cactusADM since r15-7665-gee30e2586a3142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119044 --- Comment #6 from Richard Biener --- (In reply to Filip Kastl from comment #5) > Nice. From the graph it looks like this helped a lot. Must be sth else, the rev was before the last bad run (r16-292).
[Bug tree-optimization/120003] [12/13/14/15 Regression] missed optimization around a loop with a checker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120003 --- Comment #10 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:aa6f1df4ec46a20d2292291b192d3331e51b59f8 commit r16-324-gaa6f1df4ec46a20d2292291b192d3331e51b59f8 Author: Richard Biener Date: Thu May 1 13:56:25 2025 +0200 Fix gcc.dg/tree-ssa/ssa-dom-thread-7.c for aarch64 So on another machine with a cross I see 17 jumps threaded, so adjusted like that. PR tree-optimization/120003 * gcc.dg/tree-ssa/ssa-dom-thread-7.c: Adjust aarch64 expected thread2 number of threads.
[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048 --- Comment #5 from Andrew Macleod --- It is trapping when asking for the type() of an UNDEFINED range. Looking up the call chain: Breakpoint 2, ipcp_store_vr_results () at /gcc/master/gcc/gcc/ipa-cp.cc:6366 6366 tmp.update_bitmask (bm); (gdb) p tmp.dump(stderr) [irange] short int [0, 0] so tmp starts with a range of [0,0] and then an attempt is made to apply a bitmask (gdb) p bm.dump(stderr) MASK 0xfffe VALUE 0x1$7 = void The bitmask that is being set indicates that we KNOW bit 0 is the value 1. This is incongruent a range of [0,0] and the new code which removes the lower bit ranges of a specified bitmask says [0,0] is not a value range for this bitmask, and we end up making tmp UNDEFINED. It seems like the bitmask is being incorrectly created for this range? 6358 value_range tmp = plats->m_value_range.m_vr; 6359 tree type = ipa_get_type (info, i); 6360 irange_bitmask bm (wide_int::from (bits->get_value (), 6361 TYPE_PRECISION (type), 6362 TYPE_SIGN (type)), 6363 wide_int::from (bits->get_mask (), 6364 TYPE_PRECISION (type), 6365 TYPE_SIGN (type))); 6366 tmp.update_bitmask (bm); 6367 ipa_vr vr (tmp); 6368 ts->m_vr->quick_push (vr); Why is it even creating a bitmask?
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 LIU Hao changed: What|Removed |Added Attachment #61261|0 |1 is obsolete|| --- Comment #42 from LIU Hao --- Created attachment 61263 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61263&action=edit final patch #2 also undefine STACK_REALIGN_DEFAULT.
[Bug ipa/120048] [14/15/16 Regression] ICE on valid code at -O{s,2} with "-fno-tree-vrp -fno-tree-fre" on x86_64-linux-gnu: in type, at value-range.h:982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120048 --- Comment #6 from Andrew Macleod --- (In reply to Andrew Macleod from comment #5) > 6358value_range tmp = plats->m_value_range.m_vr; > 6359tree type = ipa_get_type (info, i); > 6360irange_bitmask bm (wide_int::from (bits->get_value (), > 6361 TYPE_PRECISION > (type), > 6362 TYPE_SIGN (type)), > 6363 wide_int::from (bits->get_mask (), > 6364 TYPE_PRECISION > (type), > 6365 TYPE_SIGN (type))); > 6366tmp.update_bitmask (bm); > 6367ipa_vr vr (tmp); > 6368ts->m_vr->quick_push (vr); > > Why is it even creating a bitmask? was this written out somewhere? I would check where it was written out.. Someone has created a bad bitmask and its getting caught here
[Bug ada/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698 --- Comment #14 from John David Anglin --- I installed Debian gcc and gnat 12.3.0-14. With it, gen_il-main doesn't fault. I'm building 12.4.0-5 and I'll see if I can find issue with Debian build.
[Bug ada/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698 --- Comment #11 from Matthias Klose --- buildability: gcc-13 cannot build anymore gcc-13, seeing the same gnat error. gnat-12 tests: https://buildd.debian.org/status/fetch.php?pkg=gcc-12&arch=hppa&ver=12.4.0-5&stamp=1742217185&raw=1 (search for test-summary) === acats Summary === # of expected passes1770 # of unexpected failures558 Native configuration is hppa-unknown-linux-gnu gnat-13 tests https://buildd.debian.org/status/fetch.php?pkg=gcc-13&arch=hppa&ver=13.3.0-13&stamp=1742197347&raw=1 (search for test summary) === acats Summary === # of expected passes2121 # of unexpected failures207 Native configuration is hppa-unknown-linux-gnu gnat-14 tests https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=hppa&ver=14.2.0-19&stamp=1742110494&raw=1 === acats Summary === # of expected passes2158 # of unexpected failures170 Native configuration is hppa-unknown-linux-gnu gnat-15 tests https://buildd.debian.org/status/fetch.php?pkg=gcc-15&arch=hppa&ver=15.1.0-1&stamp=1745752860&raw=1 I don't have current gcc-15 test results trunk 20250423: https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot&arch=hppa&ver=1%3A20250423-2&stamp=1745662836&raw=1 === acats Summary === # of expected passes2243 # of unexpected failures85 Native configuration is hppa-unknown-linux-gnu all test results are also posted to the gcc-testresults list.
[Bug target/120036] [16 Regression] ICE on highway-1.2.0: during RTL pass: rrvl: in gen_rtx_SUBREG, at emit-rtl.cc:1032 since r16-271-gd1cada7481420a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120036 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target||x86_64-*-*
[Bug c++/115906] [coroutines] missing diagnostic and ICE when co_await used as default argument in function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115906 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:7b4cb031cf7de0ac350197e4ae869df9fe1d08a1 commit r14-11718-g7b4cb031cf7de0ac350197e4ae869df9fe1d08a1 Author: Arsen ArsenoviÄ Date: Thu Jul 25 01:00:02 2024 +0200 c++: diagnose usage of co_await and co_yield in default args [PR115906] This is a partial fix for PR115906. Per [expr.await] 2s3, "An await-expression shall not appear in a default argument ([dcl.fct.default])". This patch introduces the diagnostic in that case, and in the case of a co_yield (as co_yield is defined in terms of co_await, so prerequisites of co_await hold). PR c++/115906 - [coroutines] missing diagnostic and ICE when co_await used as default argument in function declaration gcc/cp/ChangeLog: PR c++/115906 * parser.cc (cp_parser_unary_expression): Reject await expressions if use of local variables is currently forbidden. (cp_parser_yield_expression): Reject yield expressions if use of local variables is currently forbidden. gcc/testsuite/ChangeLog: PR c++/115906 * g++.dg/coroutines/pr115906-yield.C: New test. * g++.dg/coroutines/pr115906.C: New test. * g++.dg/coroutines/co-await-syntax-02-outside-fn.C: Don't rely on default arguments. * g++.dg/coroutines/co-yield-syntax-01-outside-fn.C: Ditto. (cherry picked from commit 0c382da0943dc7d14455ba2ada2f620a25bd1366)
[Bug c++/110872] coroutine postcondition is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872
--- Comment #3 from GCC Commits ---
The releases/gcc-14 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:fbe351c9fa344cc53bff8a4e03068c7121af0d0c
commit r14-11715-gfbe351c9fa344cc53bff8a4e03068c7121af0d0c
Author: Iain Sandoe
Date: Sat Jun 15 17:47:33 2024 +0100
c++, coroutines, contracts: Handle coroutine and void functions
[PR110871,PR110872,PR115434].
The current implementation of contracts emits the checks into function
bodies in three places; for pre-conditions at the start of the body,
for asserts in-line in the function body and for post-conditions as an
addition to return statements.
In general (at least with existing "2a" contract semantics) the in-line
contract asserts behave as expected.
However, the mechanism is not applicable to:
* Handling pre conditions in coroutines since, for those, the standard
specifies a wrapping of the original function body by functionality
implementing initial and final suspends (along with some housekeeping
to route exceptions). Thus for such transformed function bodies, the
preconditions then get actioned after the initial suspend, which does
not behave as intended.
* Handling post conditions in functions that do not have return
statements (which applies to coroutines and void functions).
In the following, we identify a potentially transformed function body
(in the case of coroutines, this is usually called the "ramp()" function).
The patch here re-implements the code insertion in one of the two
following ways (code for exposition only):
* For functions with no post-conditions we wrap the potentially
transformed function as follows:
{
handle_pre_condition_checking ();
potentially_transformed_function_body ();
}
This implements the intent that the preconditions are processed after
the function parameters are initialised but before any other actions.
* For functions with post-conditions:
if (preconditions_exist)
handle_pre_condition_checking ();
try
{
potentially_transformed_function_body ();
}
finally
{
handle_post_condition_checking ();
}
else [only if the function is not marked noexcept(true) ]
{
;
}
In this, post-conditions [that might apply to the return value etc.]
are evaluated on every non-exceptional edge out of the function.
At present, the model here is that exceptions thrown by the function
propagate upwards as if there were no contracts present. If the desired
semantic becomes that an exception is counted as equivalent to a contract
violation - then we can add a second handler in place of the empty
statement.
This patch specifically does not address changes to code-gen and constexpr
handling that are contained in P2900.
PR c++/115434
PR c++/110871
PR c++/110872
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Handle EH_ELSE_EXPR.
* contracts.cc (finish_contract_attribute): Remove excess line.
(build_contract_condition_function): Post condition handlers are
void now.
(emit_postconditions_cleanup): Remove.
(emit_postconditions): New.
(add_pre_condition_fn_call): New.
(add_post_condition_fn_call): New.
(apply_preconditions): New.
(apply_postconditions): New.
(maybe_apply_function_contracts): New.
(apply_postcondition_to_return): Remove.
* contracts.h (apply_postcondition_to_return): Remove.
(maybe_apply_function_contracts): Add.
* coroutines.cc (coro_build_actor_or_destroy_function): Do not
copy contracts to coroutine helpers.
* decl.cc (finish_function): Handle wrapping a possibly
transformed function body in contract checks.
* typeck.cc (check_return_expr): Remove handling of post
conditions on return expressions.
gcc/ChangeLog:
* gimplify.cc (struct gimplify_ctx): Add a flag to show we are
expending a handler.
(gimplify_expr): When we are expanding a handler, and the body
transforms might have re-written DECL_RESULT into a gimple var,
ensure that hander references to DECL_RESULT are also re-written
to refer to the gimple var. When we are processing an EH_ELSE
expression, then add it if either of the cleanup slots is in
use.
gcc/testsuite/ChangeLog:
* g++.dg/contracts/pr115434.C: New test.
* g++.dg/coroutines/pr110871.C: New test.
* g++.dg/coroutines/pr110872.C: New test.
Signed-off-by: Iain Sandoe
(cherry picked from commit d170
[Bug c++/110871] coroutine precondition should be evaluated before the initial suspend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871
--- Comment #3 from GCC Commits ---
The releases/gcc-14 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:fbe351c9fa344cc53bff8a4e03068c7121af0d0c
commit r14-11715-gfbe351c9fa344cc53bff8a4e03068c7121af0d0c
Author: Iain Sandoe
Date: Sat Jun 15 17:47:33 2024 +0100
c++, coroutines, contracts: Handle coroutine and void functions
[PR110871,PR110872,PR115434].
The current implementation of contracts emits the checks into function
bodies in three places; for pre-conditions at the start of the body,
for asserts in-line in the function body and for post-conditions as an
addition to return statements.
In general (at least with existing "2a" contract semantics) the in-line
contract asserts behave as expected.
However, the mechanism is not applicable to:
* Handling pre conditions in coroutines since, for those, the standard
specifies a wrapping of the original function body by functionality
implementing initial and final suspends (along with some housekeeping
to route exceptions). Thus for such transformed function bodies, the
preconditions then get actioned after the initial suspend, which does
not behave as intended.
* Handling post conditions in functions that do not have return
statements (which applies to coroutines and void functions).
In the following, we identify a potentially transformed function body
(in the case of coroutines, this is usually called the "ramp()" function).
The patch here re-implements the code insertion in one of the two
following ways (code for exposition only):
* For functions with no post-conditions we wrap the potentially
transformed function as follows:
{
handle_pre_condition_checking ();
potentially_transformed_function_body ();
}
This implements the intent that the preconditions are processed after
the function parameters are initialised but before any other actions.
* For functions with post-conditions:
if (preconditions_exist)
handle_pre_condition_checking ();
try
{
potentially_transformed_function_body ();
}
finally
{
handle_post_condition_checking ();
}
else [only if the function is not marked noexcept(true) ]
{
;
}
In this, post-conditions [that might apply to the return value etc.]
are evaluated on every non-exceptional edge out of the function.
At present, the model here is that exceptions thrown by the function
propagate upwards as if there were no contracts present. If the desired
semantic becomes that an exception is counted as equivalent to a contract
violation - then we can add a second handler in place of the empty
statement.
This patch specifically does not address changes to code-gen and constexpr
handling that are contained in P2900.
PR c++/115434
PR c++/110871
PR c++/110872
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Handle EH_ELSE_EXPR.
* contracts.cc (finish_contract_attribute): Remove excess line.
(build_contract_condition_function): Post condition handlers are
void now.
(emit_postconditions_cleanup): Remove.
(emit_postconditions): New.
(add_pre_condition_fn_call): New.
(add_post_condition_fn_call): New.
(apply_preconditions): New.
(apply_postconditions): New.
(maybe_apply_function_contracts): New.
(apply_postcondition_to_return): Remove.
* contracts.h (apply_postcondition_to_return): Remove.
(maybe_apply_function_contracts): Add.
* coroutines.cc (coro_build_actor_or_destroy_function): Do not
copy contracts to coroutine helpers.
* decl.cc (finish_function): Handle wrapping a possibly
transformed function body in contract checks.
* typeck.cc (check_return_expr): Remove handling of post
conditions on return expressions.
gcc/ChangeLog:
* gimplify.cc (struct gimplify_ctx): Add a flag to show we are
expending a handler.
(gimplify_expr): When we are expanding a handler, and the body
transforms might have re-written DECL_RESULT into a gimple var,
ensure that hander references to DECL_RESULT are also re-written
to refer to the gimple var. When we are processing an EH_ELSE
expression, then add it if either of the cleanup slots is in
use.
gcc/testsuite/ChangeLog:
* g++.dg/contracts/pr115434.C: New test.
* g++.dg/coroutines/pr110871.C: New test.
* g++.dg/coroutines/pr110872.C: New test.
Signed-off-by: Iain Sandoe
(cherry picked from commit d170
[Bug c++/115906] [coroutines] missing diagnostic and ICE when co_await used as default argument in function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115906 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:ee0736f665971446f8665a94ef597f683f8128e9 commit r14-11717-gee0736f665971446f8665a94ef597f683f8128e9 Author: Arsen Arsenovic Date: Tue Jul 30 13:42:56 2024 +0200 c++: fix ICE on FUNCTION_DECLs inside coroutines [PR115906] When register_local_var_uses iterates a BIND_EXPRs BIND_EXPR_VARS, it fails to account for the fact that FUNCTION_DECLs might be present, and later passes it to DECL_HAS_VALUE_EXPR_P. This leads to a tree check failure in DECL_HAS_VALUE_EXPR_P: tree check: expected var_decl or parm_decl or result_decl, have function_decl in register_local_var_uses We only care about PARM_DECL and VAR_DECL, so select only those. PR c++/115906 - [coroutines] missing diagnostic and ICE when co_await used as default argument in function declaration gcc/cp/ChangeLog: PR c++/115906 * coroutines.cc (register_local_var_uses): Only process PARM_DECL and VAR_DECLs. gcc/testsuite/ChangeLog: PR c++/115906 * g++.dg/coroutines/coro-function-decl.C: New test. (cherry picked from commit a362c9ca4ef6585e678f899705043a9aa10dd670)
[Bug c++/111728] C++ 20 coroutine segmentation fault in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111728 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:074a89e4c5f9b237176626d464fcc494389905f6 commit r14-11716-g074a89e4c5f9b237176626d464fcc494389905f6 Author: Arsen ArsenoviÄ Date: Thu Jul 18 18:16:49 2024 +0200 cp/coroutines: do not rewrite parameters in unevaluated contexts It is possible to use parameters of a parent function of a lambda in unevaluated contexts without capturing them. By not capturing them, we work around the usual mechanism we use to prevent rewriting captured parameters. Prevent this by simply skipping rewrites in unevaluated contexts. Those won't mind the value not being present anyway. This prevents an ICE during parameter substitution. In the testcase from the PR, the rewriting machinery finds a param in the body of the coroutine, which it did not previously encounter while processing the coroutine declaration, and that does not have a DECL_VALUE_EXPR, and fails. gcc/cp/ChangeLog: PR c++/111728 * coroutines.cc (rewrite_param_uses): Skip unevaluated subexpressions. gcc/testsuite/ChangeLog: PR c++/111728 * g++.dg/coroutines/pr111728.C: New test. (cherry picked from commit 1a37d6b732506f8c3f9e9452c9dc6a456f25397b)
[Bug c++/115434] Post contracts are ignored on functions with no return statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:fbe351c9fa344cc53bff8a4e03068c7121af0d0c
commit r14-11715-gfbe351c9fa344cc53bff8a4e03068c7121af0d0c
Author: Iain Sandoe
Date: Sat Jun 15 17:47:33 2024 +0100
c++, coroutines, contracts: Handle coroutine and void functions
[PR110871,PR110872,PR115434].
The current implementation of contracts emits the checks into function
bodies in three places; for pre-conditions at the start of the body,
for asserts in-line in the function body and for post-conditions as an
addition to return statements.
In general (at least with existing "2a" contract semantics) the in-line
contract asserts behave as expected.
However, the mechanism is not applicable to:
* Handling pre conditions in coroutines since, for those, the standard
specifies a wrapping of the original function body by functionality
implementing initial and final suspends (along with some housekeeping
to route exceptions). Thus for such transformed function bodies, the
preconditions then get actioned after the initial suspend, which does
not behave as intended.
* Handling post conditions in functions that do not have return
statements (which applies to coroutines and void functions).
In the following, we identify a potentially transformed function body
(in the case of coroutines, this is usually called the "ramp()" function).
The patch here re-implements the code insertion in one of the two
following ways (code for exposition only):
* For functions with no post-conditions we wrap the potentially
transformed function as follows:
{
handle_pre_condition_checking ();
potentially_transformed_function_body ();
}
This implements the intent that the preconditions are processed after
the function parameters are initialised but before any other actions.
* For functions with post-conditions:
if (preconditions_exist)
handle_pre_condition_checking ();
try
{
potentially_transformed_function_body ();
}
finally
{
handle_post_condition_checking ();
}
else [only if the function is not marked noexcept(true) ]
{
;
}
In this, post-conditions [that might apply to the return value etc.]
are evaluated on every non-exceptional edge out of the function.
At present, the model here is that exceptions thrown by the function
propagate upwards as if there were no contracts present. If the desired
semantic becomes that an exception is counted as equivalent to a contract
violation - then we can add a second handler in place of the empty
statement.
This patch specifically does not address changes to code-gen and constexpr
handling that are contained in P2900.
PR c++/115434
PR c++/110871
PR c++/110872
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Handle EH_ELSE_EXPR.
* contracts.cc (finish_contract_attribute): Remove excess line.
(build_contract_condition_function): Post condition handlers are
void now.
(emit_postconditions_cleanup): Remove.
(emit_postconditions): New.
(add_pre_condition_fn_call): New.
(add_post_condition_fn_call): New.
(apply_preconditions): New.
(apply_postconditions): New.
(maybe_apply_function_contracts): New.
(apply_postcondition_to_return): Remove.
* contracts.h (apply_postcondition_to_return): Remove.
(maybe_apply_function_contracts): Add.
* coroutines.cc (coro_build_actor_or_destroy_function): Do not
copy contracts to coroutine helpers.
* decl.cc (finish_function): Handle wrapping a possibly
transformed function body in contract checks.
* typeck.cc (check_return_expr): Remove handling of post
conditions on return expressions.
gcc/ChangeLog:
* gimplify.cc (struct gimplify_ctx): Add a flag to show we are
expending a handler.
(gimplify_expr): When we are expanding a handler, and the body
transforms might have re-written DECL_RESULT into a gimple var,
ensure that hander references to DECL_RESULT are also re-written
to refer to the gimple var. When we are processing an EH_ELSE
expression, then add it if either of the cleanup slots is in
use.
gcc/testsuite/ChangeLog:
* g++.dg/contracts/pr115434.C: New test.
* g++.dg/coroutines/pr110871.C: New test.
* g++.dg/coroutines/pr110872.C: New test.
Signed-off-by: Iain Sandoe
(cherry picked from commit d170
[Bug c++/112341] error: insufficient contextual information to determine type on co_await result in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112341
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:ad4c136b906c7658d6e800b3a5241a6dac2e0bdc
commit r14-11719-gad4c136b906c7658d6e800b3a5241a6dac2e0bdc
Author: Arsen ArsenoviÄ
Date: Tue Jul 30 23:36:24 2024 +0200
c++/coroutines: only defer expanding co_{await,return,yield} if dependent
[PR112341]
By doing so, we can get diagnostics in template decls when we know we
can. For instance, in the following:
awaitable g();
template
task f()
{
co_await g();
co_yield 1;
co_return "foo";
}
... the coroutine promise type in each statement is always
std::coroutine_handle::promise_type, and all of the operands are
not type-dependent, so we can always compute the resulting types (and
expected types) of these expressions and statements.
Also, when we do not know the type of the CO_AWAIT_EXPR or
CO_YIELD_EXPR, we now return NULL_TREE as the type rather than
unknown_type_node. This is more correct, since the type is not unknown,
it just isn't determined yet. This also means we can remove the
CO_AWAIT_EXPR and CO_YIELD_EXPR special-cases from
type_dependent_expression_p.
PR c++/112341 - error: insufficient contextual information to determine
type on co_await result in function template
gcc/cp/ChangeLog:
PR c++/112341
* coroutines.cc (struct coroutine_info): Also cache the
traits type.
(ensure_coro_initialized): New function. Makes sure we have
initialized the coroutine state successfully, or informs the
caller should it fail to do so. Extracted from
coro_promise_type_found_p.
(coro_get_traits_class): New function. Gets the (cached)
coroutine traits type for a given coroutine. Extracted from
coro_promise_type_found_p and refactored to cache the result.
(coro_promise_type_found_p): Use the two functions above.
(build_template_co_await_expr): New function. Builds a
CO_AWAIT_EXPR representing a CO_AWAIT_EXPR in a template
declaration.
(build_co_await): Use the above if processing_template_decl, and
give it a proper type.
(coro_dependent_p): New function. Returns true iff its
argument is a type-dependent expression OR the current functions
traits class is type dependent.
(finish_co_await_expr): Defer expansion only in the case
coro_dependent_p returns true.
(finish_co_yield_expr): Ditto.
(finish_co_return_stmt): Ditto.
* pt.cc (type_dependent_expression_p): Do not treat
CO_AWAIT/CO_YIELD specially.
gcc/testsuite/ChangeLog:
PR c++/112341
* g++.dg/coroutines/pr112341-2.C: New test.
* g++.dg/coroutines/pr112341-3.C: New test.
* g++.dg/coroutines/torture/co-yield-03-tmpl-nondependent.C: New
test.
* g++.dg/coroutines/pr112341.C: New test.
(cherry picked from commit 32e678b2ed752154b2f96719e33f11a7c6417f20)
[Bug c++/110871] coroutine precondition should be evaluated before the initial suspend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871 Iain Sandoe changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Sandoe --- no plan to back port further.
[Bug c++/115434] Post contracts are ignored on functions with no return statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115434 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Iain Sandoe --- no plan to back port further.
[Bug c++/110872] coroutine postcondition is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from Iain Sandoe --- no plan to back port further.
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #40 from LIU Hao --- (In reply to Eric Botcazou from comment #39) > > What's the difference between the `-mstackrealign` option and the > > `force_align_arg_pointer` attribute? > > -mstackrealign (ix86_force_align_arg_pointer) is only used here: > > /* In 32bit, use MIN_STACK_BOUNDARY for incoming stack boundary > if -mstackrealign is used, it isn't used for sibcall check and > estimated stack alignment is 128bit. */ > else if (!sibcall > && ix86_force_align_arg_pointer > && crtl->stack_alignment_estimated == 128) > incoming_stack_boundary = MIN_STACK_BOUNDARY; > > force_align_arg_pointer works for any alignment, not just 128-bit. This reads to me like `-mstackrealign` usually decreases `incoming_stack_boundary` from 128 to 32; realignment is actually a result of that, right? > In practice -mstackrealign forces stack alignment to 16-byte (because it's > the preferred alignment) of every function that requires 16-byte alignment. > So it has no effects for 8-byte alignment, but that's mostly OK in practice. O_O? Is it right to say 'it has no effects for 8-byte alignment' because it's 8-byte alignment that the function is asking for, which is not 16? Because we want to decrease the preferred alignment to 4 bytes, `incoming_stack_boundary` will be 32, which is same as MIN_STACK_BOUNDARY, and the code above will not have an effect any more. Does it make sense to remove `STACK_REALIGN_DEFAULT` from cygming.h?
[Bug fortran/119948] Source allocation of pure function result rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #12 from kargls at comcast dot net --- On 5/1/25 07:45, pault at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 > > --- Comment #11 from Paul Thomas --- > (In reply to GCC Commits from comment #10) >> The master branch has been updated by Paul Thomas : > > I will close as fixed if no appetite for backporting is expressed in the next > week. > Your patch does not fix pr119948_2.f90 from my patch. I'll submit a new PR.
[Bug c++/119162] missing error with constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119162 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:25fe59805029e164bfbe347adbdf62856d1b1b1e commit r16-325-g25fe59805029e164bfbe347adbdf62856d1b1b1e Author: Jason Merrill Date: Tue Mar 11 11:17:46 2025 -0400 c++: remove TREE_STATIC from constexpr heap vars [PR119162] While working on PR119162 it occurred to me that it would be simpler to detect the problem of a value referring to a heap allocation if we stopped setting TREE_STATIC on them so they naturally are not considered to have a constant address. With that change we no longer need to specifically avoid caching a value that refers to a deleted pointer. But with this change maybe_nonzero_address is not sure whether the variable could have address zero. I don't understand why it returns 1 only for variables in the current function, rather than all non-symtab decls; an auto variable from some other function also won't have address zero. Maybe this made more sense when it was in tree_single_nonzero_warnv_p before r7-5868? But assuming there is some reason for the current behavior, this patch only changes the handling of non-symtab decls when folding_cxx_constexpr. PR c++/119162 gcc/cp/ChangeLog: * constexpr.cc (find_deleted_heap_var): Remove. (cxx_eval_call_expression): Don't call it. Don't set TREE_STATIC on heap vars. (cxx_eval_outermost_constant_expr): Don't mess with varpool. gcc/ChangeLog: * fold-const.cc (maybe_nonzero_address): Return 1 for non-symtab vars if folding_cxx_constexpr.
[Bug ada/119698] gen_il-main: raised PROGRAM_ERROR : finalize/adjust raised exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119698 --- Comment #12 from John David Anglin --- gnat-12 tests: https://buildd.debian.org/status/fetch.php?pkg=gcc-12&arch=hppa&ver=12.4.0-5&stamp=1742217185&raw=1 (search for test-summary) === acats Summary === # of expected passes1770 # of unexpected failures558 *** FAILURES: a83c01i a85013b c24003b c26006a c2a001c c2a008a c32001d c32115b c332001 c34002c c34004a c34005c c34005f c34005p c34005r c34006l c34007f c34007p c34008a c34009g c34014u c341a01 c354003 c35502c c37213h c37215d c37215f c380003 c380004 c38002a c38107a c38202a c391001 c392002 c392003 c392008 c392013 c392014 c392d02 c393012 c393a06 c393b12 c3a0003 c3a0004 c3a0006 c3a0007 c3a0015 c41104a c41206a c41303e c41303g c41304a c41306a c41306b c41306c c43105b c43107a c43204g c43205d c45411c c45503a c45531g c45531k c45531m c45531o c45532c c45532e c45532m c45534b c45613b c45651a c45662b c460006 c460011 c46033a c46043b c46054a c460a02 c47002b c47002d c47004a c47006a c47007a c48004a c48004c c48005a c48006a c48009e c48009g c48010a c48012a c52008a c52008b c52011a c52101a c52103h c52103r c52104g c52104p c53007a c55b04a c55b07b c55b11a c55c02a c56002a c59002c c620002 c62002a c62003b c66002f c730a02 c74206a c74208a c74209a c74302a c74305a c85005d c85005e c85006a c85006b c85006c c85006d c85006e c87b11b c87b15a c87b29a c87b39a c91004b c91004c c91006a c92006a c93005b c93005c c93005d c93005f c93005g c93005h c93008a c94002a c94002b c94002e c94002f c94002g c94004a c94004b c94004c c94005a c95033a c95034a c95034b c95035a c95040b c95040c c95040d c95041a c95085h c95085i c95085j c95085k c95085l c95085m c95087c c95087d c95095a c95095b c95095c c97120a c97120b c97201a c97201b c97201g c97201h c97201x c97305b c97305c c97305d c97307a c974001 c974002 c974003 c974005 cb5002a cc1104c cc1301a cc1304a cc1308a cc1310a cc3004a cc3015a cc3016i cc3019a cc3125a cd1c03g cd1c03i cd3014d cd33001 cd5003c cd5003f ce2102c ce2102i ce2102y ce2103d ce2111b ce2111f ce2201b ce2404a ce3102i ce3112c ce3112d ce3201a ce3301a ce3403d ce3404d ce3409a ce3409e ce3604a ce3604b ce3605b ce3605c ce3704m ce3804f ce3804h ce3809b ce3810b cxa5a08 cxa8001 cxa9001 cxa9002 cxaa001 cxac005 cxacb01 cxb4004 cxb4006 cxb5001 e52103y ee3412c /build/reproducible-path/gcc-12-12.4.0/src/gcc/testsuite/ada/acats/run_all.sh completed at Mon Mar 17 01:24:48 UTC 2025 There is a major difference between my personal test results and the Debian test results. My last personal results for gcc trunk are here: https://gcc.gnu.org/pipermail/gcc-testresults/2025-April/845499.html I almost never see any acats unexpected fails. Maybe it's libisl-dev or libgc-dev requirement.
[Bug fortran/119948] Source allocation of pure function result rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #10 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:0abc77da9d704bba55a376bb5c162a54826ab94a commit r16-329-g0abc77da9d704bba55a376bb5c162a54826ab94a Author: Paul Thomas Date: Thu May 1 15:22:54 2025 +0100 Fortran: Source allocation of pure function result rejected [PR119948] 2025-05-01 Paul Thomas gcc/fortran PR fortran/119948 * resolve.cc (gfc_impure_variable): The result of a module procedure with an interface declaration is not impure even if the current namespace is not the same as the symbol's. gcc/testsuite/ PR fortran/119948 * gfortran.dg/pr119948.f90: New test.
[Bug middle-end/120052] [13/14/15/16 Regression] VLA with OpenMP vs -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120052 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||needs-bisection Target Milestone|--- |13.4 Last reconfirmed||2025-05-01 --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug fortran/119948] Source allocation of pure function result rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #14 from kargls at comcast dot net --- HI Paul, The difference in my pr119948_1.f90 and pr119948_2.f90 is that the former is Damian's testcase with a result-name while latter does not use result-name so the function-name is the result variable. Both tests use a 'module procedure' construct. I did look at your patch (but obviously did not test it) and thought it would catch the latter. Your patch does catch issues with subroutine while my original patch does not deal with subroutines.
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #41 from Eric Botcazou --- > This reads to me like `-mstackrealign` usually decreases > `incoming_stack_boundary` from 128 to 32; realignment is actually a result > of that, right? Yes, both -mstackrealign and force_align_arg_pointer work by decreasing incoming_stack_boundary, which later causes the realignment if a larger alignment is required on the stack. -mstackrealign does it for all functions that require 16-byte alignment, whereas force_align_arg_pointer does it for marked functions only but for all required alignments. > Is it right to say 'it has no effects for 8-byte alignment' because it's > 8-byte alignment that the function is asking for, which is not 16? Yes. > Because we want to decrease the preferred alignment to 4 bytes, > `incoming_stack_boundary` will be 32, which is same as MIN_STACK_BOUNDARY, > and the code above will not have an effect any more. Does it make sense to > remove `STACK_REALIGN_DEFAULT` from cygming.h? Yes, I think that, if the default incoming_stack_boundary is changed, then STACK_REALIGN_DEFAULT should be removed altogether. My understanding is that they are mutually exclusive mechanisms.
[Bug c/119950] __builtin_constant_p warning with -Wdeprecated-non-prototype inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119950 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Florian Weimer : https://gcc.gnu.org/g:b6d37ec1dd2a228d94e7b5b438f3aa53684316bc commit r16-334-gb6d37ec1dd2a228d94e7b5b438f3aa53684316bc Author: Florian Weimer Date: Thu May 1 19:06:45 2025 +0200 c: Suppress -Wdeprecated-non-prototype warnings for builtins Builtins defined with BT_FN_INT_VAR etc. show as functions without a prototype and trigger the warning. gcc/c/ PR c/119950 * c-typeck.cc (convert_arguments): Check for built-in function declaration before warning. gcc/testsuite/ * gcc.dg/Wdeprecated-non-prototype-5.c: New test.
[Bug target/119172] [12/13/14 regression] macOS SDK version is not set by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119172 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:86b51d7287e9e12e9f9936f376537545e31ee03a commit r14-11711-g86b51d7287e9e12e9f9936f376537545e31ee03a Author: Iain Sandoe Date: Sun Mar 9 09:24:34 2025 + Darwin: Pass -macos_version_min to the linker [PR119172]. For binaries to be notarised, the SDK version must be available. Since we do not, at present, parse this information we have been passing "0.0" to ld64. This now results in a warning and a fail to notarise. As a quick-fix, we can fall back to letting ld64 figure out the SDK version (which it does for -macos_version_min). TODO: Parse the SDKSetting.plist at some point. cherry-picked from 952e17223d3a9 and fc728cfd569e291a5 PR target/119172 gcc/ChangeLog: * config.in: Regenerate. * config/darwin.h (DARWIN_PLATFORM_ID): Add the option to use -macos_version_min where available. * configure: Regenerate. * configure.ac: Check for ld64 support of -macos_version_min. Co-authored-by: Andrew Pinski Signed-off-by: Iain Sandoe Signed-off-by: Andrew Pinski
[Bug fortran/119948] Source allocation of pure function result rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #11 from Paul Thomas --- (In reply to GCC Commits from comment #10) > The master branch has been updated by Paul Thomas : I will close as fixed if no appetite for backporting is expressed in the next week. Paul
[Bug target/116809] Failure to build GCC on macOS 15 / Xcode 16 for Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116809 --- Comment #33 from GCC Commits --- The releases/gcc-14 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:cae584bddd0e348d9ac6f9bd917b47255a26458e commit r14-11709-gcae584bddd0e348d9ac6f9bd917b47255a26458e Author: Mark Mentovai Date: Tue Sep 24 16:11:14 2024 -0400 libgcc, Darwin: Drop the legacy library build for macOS >= 10.12 [PR116809]. From macOSX15 SDK, the unwinder no longer exports some of the symbols used in that library which (a) causes bootstrap fail and (b) means that the legacy library is no longer useful. No open branch of GCC emits references to this library - and any already -built code that depends on the symbols would need rework anyway. We have been asked to extend this back to the earliest OS vesion supported by the SDK (10.12). PR target/116809 libgcc/ChangeLog: * config.host: Build legacy libgcc_s.1 on hosts before macOS 10.12. * config/i386/t-darwin: Remove reference to legacy libgcc_s.1 * config/rs6000/t-darwin: Likewise. * config/t-darwin-libgccs1: New file. Signed-off-by: Iain Sandoe (cherry picked from commit d9cafa0c4f0a81304d9b95a78ccc8e9003c6d7a3)
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #11 from GCC Commits --- The releases/gcc-14 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:623aaebc7d755ef8696834bebd14f8eddd88200e commit r14-11713-g623aaebc7d755ef8696834bebd14f8eddd88200e Author: Iain Sandoe Date: Sun Dec 29 23:06:54 2024 + includes, Darwin: Handle modular use for macOS SDKs [PR116827]. Recent changes to the OS SDKs have altered the way in which include guards are used for a number of headers when C++ modules are enabled. Instead of placing the guards in the included header, they are being placed in the including header. This breaks the assumptions in the current GCC stddef.h specifically, that the presence of __PTRDIFF_T and __SIZE_T means that the relevant defs are already made. However in the case of the module-enabled C++ with these SDKs, that is no longer true. stddef.h has a large body of special-cases already, but it seems that the only viable solution here is to add a new one specifically for __APPLE__ and modular code. This fixes around 280 new fails in the modules test-suite; it is needed on all open branches that support modules. PR target/116827 gcc/ChangeLog: * ginclude/stddef.h: Undefine __PTRDIFF_T and __SIZE_T for module- enabled c++ on Darwin/macOS platforms. Signed-off-by: Iain Sandoe (cherry picked from commit 9cf6b52d04df22726d88eef113211b3cc08515de)
[Bug c++/119034] Nested using-declaration doesn't do ADL or uses wrong associated namespace (overly strict use of deleted function before ADL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034 --- Comment #6 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1fb5abc3919f376f3dedccad636eba4a4ad7e4a7 commit r16-330-g1fb5abc3919f376f3dedccad636eba4a4ad7e4a7 Author: Patrick Palka Date: Thu May 1 10:58:50 2025 -0400 c++: more overeager use of deleted function before ADL [PR119034] The PR68942 fix used the tf_conv flag to disable mark_used when substituting a FUNCTION_DECL callee of an ADL-enabled call. In this slightly more elaborate testcase, we end up prematurely calling mark_used anyway on the FUNCTION_DECL directly from the CALL_EXPR case of tsubst_expr during partial instantiation, leading to a bogus "use of deleted function" error. This patch fixes the general problem in a more robust way by ensuring the callee of an ADL-enabled call is wrapped in an OVERLOAD, so that tsubst_expr leaves it alone. PR c++/119034 PR c++/68942 gcc/cp/ChangeLog: * pt.cc (tsubst_expr) : Revert PR68942 fix. * semantics.cc (finish_call_expr): Ensure the callee of an ADL-enabled call is wrapped in an OVERLOAD. gcc/testsuite/ChangeLog: * g++.dg/template/koenig13.C: New test. Reviewed-by: Jason Merrill
[Bug c++/119034] Nested using-declaration doesn't do ADL or uses wrong associated namespace (overly strict use of deleted function before ADL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034 Patrick Palka changed: What|Removed |Added Target Milestone|--- |16.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Patrick Palka --- Fixed for GCC 16
[Bug c++/68942] overly strict use of deleted function before argument-dependent lookup (ADL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68942 --- Comment #6 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1fb5abc3919f376f3dedccad636eba4a4ad7e4a7 commit r16-330-g1fb5abc3919f376f3dedccad636eba4a4ad7e4a7 Author: Patrick Palka Date: Thu May 1 10:58:50 2025 -0400 c++: more overeager use of deleted function before ADL [PR119034] The PR68942 fix used the tf_conv flag to disable mark_used when substituting a FUNCTION_DECL callee of an ADL-enabled call. In this slightly more elaborate testcase, we end up prematurely calling mark_used anyway on the FUNCTION_DECL directly from the CALL_EXPR case of tsubst_expr during partial instantiation, leading to a bogus "use of deleted function" error. This patch fixes the general problem in a more robust way by ensuring the callee of an ADL-enabled call is wrapped in an OVERLOAD, so that tsubst_expr leaves it alone. PR c++/119034 PR c++/68942 gcc/cp/ChangeLog: * pt.cc (tsubst_expr) : Revert PR68942 fix. * semantics.cc (finish_call_expr): Ensure the callee of an ADL-enabled call is wrapped in an OVERLOAD. gcc/testsuite/ChangeLog: * g++.dg/template/koenig13.C: New test. Reviewed-by: Jason Merrill
[Bug c++/105475] coroutines: ICE in coerce_template_parms, at cp/pt.cc:9183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105475 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:d3389c96234eb3c259867edc91876571b5254392 commit r14-11720-gd3389c96234eb3c259867edc91876571b5254392 Author: Iain Sandoe Date: Wed Jul 24 20:59:10 2024 +0100 c++, coroutines: check for members we use in handle_types [PR105475] Currently, it is possible to ICE GCC by giving it sufficiently broken code, where sufficiently broken means a std::coroutine_handle missing a default on the promise_type template argument, and missing members. As the code generator relies on lookups in the coroutine_handle never failing (and has no way to signal that error), lets do it ahead of time, save the result, and use that. This saves us some lookups and allows us to propagate an error. PR c++/105475 - coroutines: ICE in coerce_template_parms, at cp/pt.cc:9183 This includes refactoring from 370a0dee55569, ffd521d8dcddcd4 and 00019b88e714c29c387. gcc/cp/ChangeLog: PR c++/105475 * coroutines.cc (struct coroutine_info): Add from_address. Carries the from_address member we looked up earlier. (coro_resume_identifier): Remove. Unused. (coro_init_identifiers): Do not initialize the above. (struct susp_frame_data): Remove unused members, provide a CTOR. (void_coro_handle_address): New variable. Contains the baselink for the std::coroutine_handle::address() instance method. (get_handle_type_address): New function. Looks up and validates handle_type::address in a given handle_type. (get_handle_type_from_address): New function. Looks up and validates handle_type::from_address in a given handle_type. (coro_promise_type_found_p): Remove reliance on coroutine_handle<> defaulting the promise type to void. Store get_handle_type_* results where appropriate. (struct local_vars_frame_data): Add a CTOR. (replace_continue): Look up expression type. (get_coroutine_from_address): New helper. Gets the handle_type::from_address BASELINK from a coroutine_info. (morph_fn_to_coro): Use susp_frame_data CTOR, and make the suspend state hash map local to the morph function. Use CTOR for local_vars_frame_data instead of brace init. (build_actor_fn): Use the get_coroutine_from_address helper and void_coro_handle_address. gcc/testsuite/ChangeLog: PR c++/105475 * g++.dg/coroutines/pr103868.C: Add std::coroutine_handle members we check for now. * g++.dg/coroutines/pr105287.C: Ditto. * g++.dg/coroutines/pr105301.C: Ditto. * g++.dg/coroutines/pr94528.C: Ditto. * g++.dg/coroutines/pr94879-folly-1.C: Ditto. * g++.dg/coroutines/pr94883-folly-2.C: Ditto. * g++.dg/coroutines/pr98118.C: Ditto. * g++.dg/coroutines/pr105475.C: New test. * g++.dg/coroutines/pr105475-1.C: New test. * g++.dg/coroutines/pr105475-2.C: New test. * g++.dg/coroutines/pr105475-3.C: New test. * g++.dg/coroutines/pr105475-4.C: New test. * g++.dg/coroutines/pr105475-5.C: New test. * g++.dg/coroutines/pr105475-6.C: New test. * g++.dg/coroutines/pr105475-broken-spec.C: New test. * g++.dg/coroutines/pr105475-broken-spec-2.C: New test. Co-authored-by: Arsen ArsenoviÄ (cherry picked from commit 5b4476a165565cb20729c0a97a3f43b060595209)
[Bug fortran/119948] Source allocation of pure function result rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #16 from kargls at comcast dot net --- On 5/1/25 11:55, pault at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 > > --- Comment #15 from Paul Thomas --- > (In reply to kargls from comment #14) >> HI Paul, >> >> The difference in my pr119948_1.f90 and pr119948_2.f90 is >> that the former is Damian's testcase with a result-name >> while latter does not use result-name so the function-name >> is the result variable. Both tests use a 'module procedure' >> construct. I did look at your patch (but obviously did not >> test it) and thought it would catch the latter. >> >> Your patch does catch issues with subroutine while my >> original patch does not deal with subroutines. > > Hi Steve, > > I feel beyond stupid - it's not even a matter of the strength of my glasses > :-( > > I have taken your chunk from primary.cc and rolled the two tests into one. > It's > regtesting right now. > When it passes regtesting, feel free to commit. This seems to be a case of "two heads are better than one". I overlooked issues with subroutines while you missed the issue with function-name.
[Bug c++/107022] error: use of deleted function 'std::unordered_map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107022 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 103923 ***
[Bug libstdc++/103923] is_invocable inexplicably fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923 Andrew Pinski changed: What|Removed |Added CC||piersh at hotmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 107022 has been marked as a duplicate of this bug. ***
[Bug c++/105475] coroutines: ICE in coerce_template_parms, at cp/pt.cc:9183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105475 Iain Sandoe changed: What|Removed |Added Status|WAITING |RESOLVED Target Milestone|--- |14.3 Resolution|--- |FIXED --- Comment #8 from Iain Sandoe --- currently no plans for further back ports
[Bug middle-end/98753] -Wfree-nonheap-object on unreachable code with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98753
Christian Kreibich changed:
What|Removed |Added
CC||christian at zeek dot org
--- Comment #17 from Christian Kreibich ---
The OP's original observation still holds with GCC 14.2.1 built as per the
below.
Since this is happening in Bison-generated code this is tricky to deal with:
one cannot instrument locally via pragmas to suppress, and since the
Bison-generated file includes the user's own parsing code one also doesn't want
to support the warning altogether in case it's correct elsewhere in the file.
test.c
#include
#include
int
main(void)
{
int yyssa[200];
int *yyss = yyssa;
if (yyss != yyssa)
free(yyss);
else
printf("I beg to differ\n");
return 0;
}
$ gcc -o test test.c
test.c: In function ‘main’:
test.c:11:9: warning: ‘free’ called on unallocated object ‘yyssa’
[-Wfree-nonheap-object]
11 | free(yyss);
| ^~
test.c:7:9: note: declared here
7 | int yyssa[200];
| ^
$ ./test
I beg to differ
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-14.2.1-build/gcc-14.2.1-20250110/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.1 20250110 (Red Hat 14.2.1-7) (GCC)
[Bug tree-optimization/118659] get_known_nonzero_bits_1 should use wi::bit_and_not instead of `a & ~b`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118659 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |16.0 --- Comment #3 from Andrew Pinski --- Fixed.
[Bug tree-optimization/118617] the auto_vec converts variable that gets passed into supportable_indirect_convert_operation could use internal storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118617 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:69bcf1d6aa52a531f7bc4976e407325fe9742cf6 commit r16-342-g69bcf1d6aa52a531f7bc4976e407325fe9742cf6 Author: Andrew Pinski Date: Thu May 1 09:05:47 2025 -0700 vect: Use internal storage for converts for call into supportable_indirect_convert_operation [PR118617] While looking into PR 118616, I noticed that supportable_indirect_convert_operation only pushes up to 2 into its vec. And the 2 places which call supportable_indirect_convert_operation, use an auto_vec but without an internal storage. In this case an internal storage of 2 elements would save both memory and slight compile time performance. Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/118617 gcc/ChangeLog: * tree-vect-generic.cc (expand_vector_conversion): Have 2 elements as internal storage for converts. * tree-vect-stmts.cc (vectorizable_conversion): Likewise. Signed-off-by: Andrew Pinski
[Bug tree-optimization/118617] the auto_vec converts variable that gets passed into supportable_indirect_convert_operation could use internal storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118617 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |16.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed.
[Bug rtl-optimization/120059] [16 regression] ICE when building mesa in vartrack since r16-286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120059 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Andrew Pinski --- (subreg:QI (not:SI (reg:SI 20 xmm0 [orig:101 vect__2.6 ] [101])) 0) And yes a subreg here won't work on xmm0 for QI mode. Anyways I am going to test my patch and push it as obvious since simplify_gen_subreg will return NULL for cases like this when it will cause an invalid subreg.
[Bug middle-end/118090] unsignedp argument get_compare_parts is unused by callers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118090 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |16.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed.
