[Bug tree-optimization/119351] [15 Regression] Wrong code in GROMACS for AArch64 generic SVE VLS target since r15-6807-g68326d5d1a593d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119351
--- Comment #20 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:46ccce1de686c1b437eff43431dc20d20d4687c0
commit r15-9518-g46ccce1de686c1b437eff43431dc20d20d4687c0
Author: Tamar Christina
Date: Wed Apr 16 13:09:05 2025 +0100
middle-end: Fix incorrect codegen with PFA and VLS [PR119351]
The following example:
#define N 512
#define START 2
#define END 505
int x[N] __attribute__((aligned(32)));
int __attribute__((noipa))
foo (void)
{
for (signed int i = START; i < END; ++i)
{
if (x[i] == 0)
return i;
}
return -1;
}
generates incorrect code with fixed length SVE because for early break we
need
to know which value to start the scalar loop with if we take an early exit.
Historically this means that we take the first element of every induction.
this is because there's an assumption in place, that even with masked loops
the
masks come from a whilel* instruction.
As such we reduce using a BIT_FIELD_REF <, 0>.
When PFA was added this assumption was correct for non-masked loop, however
we
assumed that PFA for VLA wouldn't work for now, and disabled it using the
alignment requirement checks. We also expected VLS to PFA using scalar
loops.
However as this PR shows, for VLS the vectorizer can, and does in some
circumstances choose to peel using masks by masking the first iteration of
the
loop with an additional alignment mask.
When this is done, the first elements of the predicate can be inactive. In
this
example element 1 is inactive based on the calculated misalignment. hence
the
-1 value in the first vector IV element.
When we reduce using BIT_FIELD_REF we get the wrong value.
This patch updates it by creating a new scalar PHI that keeps track of
whether
we are the first iteration of the loop (with the additional masking) or
whether
we have taken a loop iteration already.
The generated sequence:
pre-header:
bb1:
i_1 =
header:
bb2:
i_2 = PHI
â¦
early-exit:
bb3:
i_3 = iv_step * i_2 + PHI
Which eliminates the need to do an expensive mask based reduction.
This fixes gromacs with one OpenMP thread. But with > 1 there is still an
issue.
gcc/ChangeLog:
PR tree-optimization/119351
* tree-vectorizer.h (LOOP_VINFO_MASK_NITERS_PFA_OFFSET,
LOOP_VINFO_NON_LINEAR_IV): New.
(class _loop_vec_info): Add mask_skip_niters_pfa_offset and
nonlinear_iv.
* tree-vect-loop.cc (_loop_vec_info::_loop_vec_info): Initialize
them.
(vect_analyze_scalar_cycles_1): Record non-linear inductions.
(vectorizable_induction): If early break and PFA using masking
create a
new phi which tracks where the scalar code needs to start...
(vectorizable_live_operation): ...and generate the adjustments
here.
(vect_use_loop_mask_for_alignment_p): Reject non-linear inductions
and
early break needing peeling.
gcc/testsuite/ChangeLog:
PR tree-optimization/119351
* gcc.target/aarch64/sve/peel_ind_10.c: New test.
* gcc.target/aarch64/sve/peel_ind_10_run.c: New test.
* gcc.target/aarch64/sve/peel_ind_5.c: New test.
* gcc.target/aarch64/sve/peel_ind_5_run.c: New test.
* gcc.target/aarch64/sve/peel_ind_6.c: New test.
* gcc.target/aarch64/sve/peel_ind_6_run.c: New test.
* gcc.target/aarch64/sve/peel_ind_7.c: New test.
* gcc.target/aarch64/sve/peel_ind_7_run.c: New test.
* gcc.target/aarch64/sve/peel_ind_8.c: New test.
* gcc.target/aarch64/sve/peel_ind_8_run.c: New test.
* gcc.target/aarch64/sve/peel_ind_9.c: New test.
* gcc.target/aarch64/sve/peel_ind_9_run.c: New test.
[Bug testsuite/119286] [15 Regression] GCN vs. "middle-end: delay checking for alignment to load [PR118464]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119286 --- Comment #6 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:fa99720e9f3447565d274baaa81e23c2ddab4a67 commit r15-9519-gfa99720e9f3447565d274baaa81e23c2ddab4a67 Author: Tamar Christina Date: Wed Apr 16 13:11:20 2025 +0100 middle-end: force AMDGCN test for vect-early-break_18.c to consistent architecture [PR119286] The given test is intended to test vectorization of a strided access done by having a step of > 1. GCN target doesn't support load lanes, so the testcase is expected to fail, other targets create a permuted load here which we then then reject. However some GCN arch don't seem to support the permuted loads either, so the vectorizer tries a gather/scatter. But the indices aren't supported by some target, so instead the vectorizer scalarizes the loads. I can't really test for which architecture is being used by the compiler, so instead this updates the testcase to use one single architecture so we get a consistent result. gcc/testsuite/ChangeLog: PR target/119286 * gcc.dg/vect/vect-early-break_18.c: Force -march=gfx908 for amdgcn.
[Bug testsuite/119286] [15 Regression] GCN vs. "middle-end: delay checking for alignment to load [PR118464]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119286 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Tamar Christina --- Should all be fixed now.
[Bug cobol/119211] [15 Regression] Cobol GCC 15 release checklist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 --- Comment #10 from Jakub Jelinek --- I don't see release blockers remaining on the COBOL side, after all, it is a non-default language.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 --- Comment #46 from Jan Hubicka --- Created attachment 61133 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61133&action=edit updated patch The problem in previous patch was that ipa-prop streams 0 to the end of block of summary section but never reads it. I guess someone copied streaming code that expected the block to be 0 terminated but also added logic to count how many summaries are streamed. Now the longer testcase compiles for me, but also it means that the testcase included in patch is not really testing the streaming (since it worked with streaming fully disabled)
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 --- Comment #47 from Jan Hubicka --- Created attachment 61134 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61134&action=edit patch w/o forgotten debug output
[Bug c++/119829] Internal Compiler Error with braced initialization and designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119829 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-04-16 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed. Not a regression I think.
[Bug libstdc++/109162] C++23 improvements to std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162 --- Comment #13 from GCC Commits --- The master branch has been updated by Tomasz Kaminski : https://gcc.gnu.org/g:aef87975224b0a4b5b103f241fd366b0e3a21360 commit r15-9520-gaef87975224b0a4b5b103f241fd366b0e3a21360 Author: Tomasz KamiÅski Date: Wed Apr 16 13:39:04 2025 +0200 libstdc++: Fix constification in range_formatter::format [PR109162] The _Rg is deduced to lvalue reference for the lvalue arguments, and in such case __format::__maybe_const_range<_Rg, _CharT> is always _Rg (adding const to reference does not change behavior). Now we correctly check if _Range = remove_reference_t<_Rg> is const formattable range, furthermore as range_formatter can only format ranges of values of type (possibly const) _Tp, we additional check if the remove_cvref_t> is _Tp. The range_reference_t and range_reference_t have different types (modulo remove_cvref_t) for std::vector (::reference and bool) or flat_map (pair and pair). PR libstdc++/109162 libstdc++-v3/ChangeLog: * include/std/format (range_formatter::format): Format const range, only if reference type is not changed. * testsuite/std/format/ranges/formatter.cc: New tests. Reviewed-by: Jonathan Wakely Signed-off-by: Tomasz KamiÅski
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #11 from Jakub Jelinek --- Though, if even that is too large, guess just grep -C50 'clrmem_short' hb-subset.cc.*[0-9]r.* might be good enough.
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #12 from Sam James --- Unfortunately I can't reproduce it yet. Could you show me `gcc -v`? (Wondering what --with-arch= is, especially, if anything.)
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 --- Comment #52 from Sam James --- Created attachment 61137 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61137&action=edit q.ii.xz This is a lot smaller but still pretty gross. Not reducing it further, but including in case it's of some use.
[Bug rust/119508] Hundreds of rust tests XPASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org See Also||https://github.com/Rust-GCC ||/gccrs/issues/3740 --- Comment #20 from Sam James --- We're discussing further XPASS issues also at https://github.com/Rust-GCC/gccrs/issues/3740.
[Bug fortran/119836] [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- I will test tonight and if good, I will commit it.
[Bug target/119386] [14 Regression] [x64] Shared libraries can no longer be compiled with profiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119386 Sam James changed: What|Removed |Added Summary|[14/15 Regression][x64] |[14 Regression] [x64] |Shared libraries can no |Shared libraries can no |longer be compiled with |longer be compiled with |profiling |profiling Known to work||15.0 Assignee|unassigned at gcc dot gnu.org |ardb at kernel dot org Status|WAITING |ASSIGNED
[Bug fortran/119836] [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
--- Comment #6 from Jerry DeLisle ---
I get one test failure:
FAIL: gfortran.dg/do_concurrent_all_clauses.f90 -O (test for errors, line
21)
from:
! { dg-do compile }
program do_concurrent_all_clauses
implicit none
integer :: i, arr(10), sum, max_val, temp, squared
sum = 0
max_val = 0
do concurrent (i = 1:10, i <= 8) &
default(none) &
local(temp) &
shared(arr, squared, sum, max_val) &
reduce(+:sum) & ! { dg-error "Variable 'sum' at \\(1\\) has already been
specified in a locality-spec" }
reduce(max:max_val) ! { dg-error "Variable 'max_val' at \\(1\\) has
already been specified in a locality-spec" }
block
integer :: temp2
temp = i * 2
temp2 = temp * 2
squared = i * i
arr(i) = temp2 + squared
sum = sum + arr(i)
max_val = max(max_val, arr(i)) ! { dg-error "Reference to impure
function" }
end block
end do
print *, arr, sum, max_val
end program do_concurrent_all_clauses
With the patch we accept the max function. The MAX function is used as an
example of an elemental function which is PURE. All elemental functions are
PURE unless specifically declared as IMPURE.
I will also adjust this test case accordingly. Any other thoughts?
[Bug target/119832] RISC-V: Redundant floating point rounding mode store/restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119832 --- Comment #4 from Li Pan --- (In reply to Kito Cheng from comment #1) > Created attachment 61135 [details] > 0001-RISC-V-Implement-TARGET_MODE_CONFLUENCE.patch > > My working patch for this bug I think TARGET_MODE_CONFLUENCE should be a better place for this issue, which is somehow designed for non-exclusive modes, quote from doc. "some entities might have overlapping, non-exclusive modes, so that it is sometimes possible to represent “mode mode1 or mode mode2” with something more specifi c than “mode not known”." CC Richard S in case my understanding is incorrect. To double confirm, is it a mis-optimized issue instead of correctness?
[Bug libstdc++/119840] FAIL: g++.old-deja/g++.robertl/eb73.C -std=gnu++26 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119840 --- Comment #1 from John David Anglin --- I'm also seeing warnings from this file in build log. Probably, this warning was introduced in the following commit: 473dde525248a694c0f4e62b31a7fc24b238c5b0
[Bug libstdc++/119742] [C++26] Implement P2697R1, Interfacing bitset with string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119742 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-04-17 Keywords||c++26 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- .
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 Neil Booth changed: What|Removed |Added CC||neilb at protonmail dot ch --- Comment #38 from Neil Booth --- @jsm, I'm curious about your statement: "You need to test cases such as that if a macro is defined twice, once with a UCN in its expansion and once with the equivalent character written in UTF-8, the difference in the expansion is diagnosed (whichever of all the valid UCNs for that character is the one used)." My reading of the standards is that a UCN names a character. A spelling is a sequence of characters. Hence there is no difference in spelling between a UCN naming, say, an emoji and that emoji in the source - the spelling of both is a single character. This is clear in the wording of the C++ standards. e.g. C++23 says "The universal-character-name construct provides a way to name other characters." where is is referring to characters in the translation character set. The wording in the C standards is a little ambiguous but I would be surprised if the intent were different. After all, there is nothing to be gained by preserving source code form differences in the preprocessor or compiler - form differences can only be distinguished when stringized, and there a UCN and the actual character are indeed the same (and IMO always were). Clang seems to do a better job in its UCN implementation because it treats a UCN and the character in names as the same in all ways.
[Bug tree-optimization/97640] GCC doesn't optimize-out outside-affecting lambdas within y-combinator while clang does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97640 Andrew Pinski changed: What|Removed |Added Component|c++ |tree-optimization Last reconfirmed||2025-04-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. We get close at -O3 (even at -O2 we are close). GCC even gets the tail call at -O2 which LLVM does not.
[Bug target/119234] openblas miscompiled with -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119234
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #5 from Jeevitha ---
I am able to reproduce the issue on the Power8 build. The issue occurs in the
SGEMV kernels 4x8 and 4x4.
For the below source in sgemv_4x8 below assemble was generated by the compiler,
for (i = 0; i < n/4; i ++) {
temp0 += v_x[i] * va0[i];
temp1 += v_x[i] * va1[i];
temp2 += v_x[i] * va2[i];
temp3 += v_x[i] * va3[i];
temp4 += v_x[i] * va4[i];
temp5 += v_x[i] * va5[i];
temp6 += v_x[i] * va6[i];
temp7 += v_x[i] * va7[i];
}
Assembly:
0x2051d8a0 <+96>:add r30,r6,r9
0x2051d8a4 <+100>: lvx v12,r5,r9
0x2051d8a8 <+104>: lvx v13,r7,r9
0x2051d8ac <+108>: clrrdi r30,r30,4
0x2051d8b0 <+112>: lvx v1,r12,r9
0x2051d8b4 <+116>: lxvd2x vs0,0,r30
0x2051d8b8 <+120>: add r30,r11,r9
0x2051d8bc <+124>: clrrdi r30,r30,4
0x2051d8c0 <+128>: lxvd2x vs13,0,r30
0x2051d8c4 <+132>: add r30,r3,r9
0x2051d8c8 <+136>: clrrdi r30,r30,4
0x2051d8cc <+140>: xxswapd vs0,vs0
0x2051d8d0 <+144>: lxvd2x vs2,0,r30
0x2051d8d4 <+148>: add r30,r4,r9
0x2051d8d8 <+152>: clrrdi r30,r30,4
0x2051d8dc <+156>: xvmaddasp vs6,vs0,vs44
0x2051d8e0 <+160>: xvmaddasp vs7,vs0,vs45
0x2051d8e4 <+164>: xxswapd vs13,vs13
0x2051d8e8 <+168>: xvmaddasp vs10,vs0,vs33
0x2051d8ec <+172>: lxvd2x vs3,0,r30
0x2051d8f0 <+176>: add r30,r8,r9
0x2051d8f4 <+180>: clrrdi r30,r30,4
0x2051d8f8 <+184>: xvmaddasp vs12,vs0,vs13
0x2051d8fc <+188>: xxswapd vs2,vs2
0x2051d900 <+192>: lxvd2x vs4,0,r30
0x2051d904 <+196>: add r30,r10,r9
0x2051d908 <+200>: addir9,r9,16
0x2051d90c <+204>: clrrdi r30,r30,4
0x2051d910 <+208>: xvmaddasp vs8,vs0,vs2
0x2051d914 <+212>: xxswapd vs3,vs3
0x2051d918 <+216>: lxvd2x vs5,0,r30
0x2051d91c <+220>: xvmaddasp vs9,vs0,vs3
0x2051d920 <+224>: xxswapd vs4,vs4
0x2051d924 <+228>: xvmaddasp vs11,vs0,vs4
0x2051d928 <+232>: xxswapd vs5,vs5
0x2051d92c <+236>: xvmaddasp vs32,vs0,vs5
0x2051d930 <+240>: bdnz0x2051d8a0
While debugging the issue, I observed a misaligned lvx instruction in
sgemv_kernel_4x8, which results in incorrect vector loads
0x2051d8a4 71 temp0 += v_x[i] * va0[i];
=> 0x2051d8a4 : ce 48 85 7d lvx
v12,r5,r9
(gdb) p/x $r5
$3 = 0x10033940
(gdb) p/x $r9
$4 = 0x0
(gdb) x/10f $r5
0x10033940: 0 1 2 3
0x10033950: 4 5 6 7
0x10033960: 8 9
(gdb) si
(gdb) p $v12
$6 = {uint128 = 85402898748987885467211345242806550528, v4_float = {0, 1, 2,
3}, v4_int32 = {0, 1065353216, 1073741824,
1077936128}, v8_int16 = {0, 0, 0, 16256, 0, 16384, 0, 16448}, v16_int8 =
{0, 0, 0, 0, 0, 0, -128, 63, 0, 0, 0, 64,
0, 0, 64, 64}}
Above lvx has no issue because, Address is 16-byte aligned. lvx fetches
expected values.
0x2051d8a8 72 temp1 += v_x[i] * va1[i];
=> 0x2051d8a8 : ce 48 a7 7d lvx
v13,r7,r9
(gdb) p/x $r7
$7 = 0x10033a08
(gdb) p/x $r9
$8 = 0x0
(gdb) x/10f $r7
0x10033a08: 50 51 52 53
0x10033a18: 54 55 56 57
0x10033a28: 58 59
(gdb) si
(gdb) p $v13
$9 = {uint128 = 88123662303566147823415553041968922624, v4_float = {48, 49, 50,
51}, v4_int32 = {490560, 752704,
1112014848, 1112276992}, v8_int16 = {0, 16960, 0, 16964, 0, 16968, 0,
16972}, v16_int8 = {0, 0, 64, 66, 0, 0, 68,
66, 0, 0, 72, 66, 0, 0, 76, 66}}
In this case, Address 0x10033a08 is not 16-byte aligned. Internally, lvx masks
(0x___FFF0) changed address to 0x10033a00, so it fetches values
starting two floats earlier than intended.//v4_float = {48, 49, 50, 51}
This causes incorrect computation in temp1 during the loop, and the error
propagates through further vectorized operations
Sample Values (for one loop iteration):
i = 0
v_x[i] = {1.00, 1.00, 1.00, 1.00}
va0[i] = {0.00, 1.00, 2.00, 3.00}
va1[i] = {50.00, 51.00, 52.00, 53.00}
va2[i] = {100.00, 101.00, 102.00, 103.00}
va3[i] = {150.00, 151.00, 152.00, 153.00}
va4[i] = {200.00, 201.00, 202.00, 203.00}
va5[i] = {250.00, 251.00, 252.00, 253.00}
va6[i] = {300.00, 301.00, 302.
[Bug c++/110343] [C++26] P2558R2 - Add @, $, and ` to the basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343 Aaron Ballman changed: What|Removed |Added CC||aaron at aaronballman dot com --- Comment #14 from Aaron Ballman --- (In reply to Jakub Jelinek from comment #11) > I've posted https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657583.html > I don't think we should change the raw string handling for C23, because > unlike C++26 they didn't add the $@` chars to the basic character set, but > next to it. 5.2.1p3 added it to the list of graphic characters in the basic character set?
[Bug c++/110343] [C++26] P2558R2 - Add @, $, and ` to the basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343 --- Comment #16 from Jakub Jelinek --- N3220 does have those 3 in there too, but dunno if that is a post C23 or pre C23 draft.
[Bug middle-end/119831] Missed pointer compare folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119831 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-04-16 --- Comment #1 from Andrew Pinski --- Confirmed. I had just saw a bug about `&a + t` should then infer the range of t is `[0,1]` afterwards but I can't find it right now.
[Bug c++/110343] [C++26] P2558R2 - Add @, $, and ` to the basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343 --- Comment #15 from Jakub Jelinek --- I was looking at N3096 and that one doesn't have that. I see it in N3467. Does official C23 have that change? Or is it C2Y?
[Bug target/117010] [nvptx] Incorrect ptx code-gen for C++ code with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117010 Thomas Schwinge changed: What|Removed |Added Last reconfirmed|2025-03-25 00:00:00 |2025-4-16 Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #10 from Thomas Schwinge --- (In reply to myself from comment #8) > [...] Offloading code generation uses the LTO machinery, including > the 'lto1' front end, and thus has 'gcc/common.opt:in_lto_p' set to 'true': > [...] > [...] What this means semantically: whether > 'in_lto_p' should vs. shouldn't actually be set for offloading compilation, > I/we have to spend more thought on, whether all these > transformations/optimizations guarded by 'in_lto_p' are generally applicable > to offloading compilation or not? -> PR119833 "Clarify which semantics offloading compilation does (not) inherit from using the LTO infrastructure". (In reply to myself from comment #9) > (..., but I've found another "solution" to the original problem; to be > detailed later.) The original problem now is exactly PR97106. *** This bug has been marked as a duplicate of bug 97106 ***
[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 Bug 118518 depends on bug 117010, which changed state. Bug 117010 Summary: [nvptx] Incorrect ptx code-gen for C++ code with templates https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117010 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE
[Bug target/97106] [nvptx] Issues with weak aliases introduced by C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97106 Thomas Schwinge changed: What|Removed |Added CC||prathamesh3492 at gcc dot gnu.org --- Comment #8 from Thomas Schwinge --- *** Bug 117010 has been marked as a duplicate of this bug. ***
[Bug c++/110343] [C++26] P2558R2 - Add @, $, and ` to the basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343 --- Comment #17 from Aaron Ballman --- (In reply to Jakub Jelinek from comment #16) > N3220 does have those 3 in there too, but dunno if that is a post C23 or pre > C23 draft. https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3124.pdf was adopted as a resolution to US-032 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3148.doc), so this was a (late) C23 change.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 --- Comment #53 from GCC Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:eabba7be040e81690332070873d59d23e8c93e11 commit r15-9522-geabba7be040e81690332070873d59d23e8c93e11 Author: Jan Hubicka Date: Wed Apr 16 15:28:32 2025 +0200 Stream ipa_return_value_summary Add streaming of return summaries from compile time to ltrans which are now needed for vrp to not ouput false errors on musttail. Co-authored-by: Jakub Jelinek gcc/ChangeLog: PR tree-optimization/119614 * ipa-prop.cc (ipa_write_return_summaries): New function. (ipa_record_return_value_range_1): Break out from (ipa_record_return_value_range): ... here. (ipa_read_return_summaries): New function. (ipa_prop_read_section): Read return summaries. (read_ipcp_transformation_info): Read return summaries. (ipcp_write_transformation_summaries): Write return summaries; do not stream stray 0. gcc/testsuite/ChangeLog: * g++.dg/lto/pr119614_0.C: New test.
[Bug middle-end/119808] wrong code with _BitInt() and -ftree-coalesce-vars -fstack-protector-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119808 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 --- Comment #41 from Jakub Jelinek --- (In reply to Sam James from comment #38) > The testcase from comment 14 fails for me still with Martin's last patch as > well as Honza's. Though it works with the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614#c26 hack, so guess we need to find out why the singleton retval doesn't make it through to ltrans in this case.
[Bug target/115258] [14 Regression] register swaps for vector perm in some cases after r14-6290
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115258 --- Comment #9 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:94ef80629a5f808ff165d28f87f39021881ed5f4 commit r14-11638-g94ef80629a5f808ff165d28f87f39021881ed5f4 Author: Richard Sandiford Date: Wed Apr 16 13:20:29 2025 +0100 aarch64: Split aarch64_combinev16qi before RA [PR115258] Two-vector TBL instructions are fed by an aarch64_combinev16qi, whose purpose is to put the two input data vectors into consecutive registers. This aarch64_combinev16qi was then split after reload into individual moves (from the first input to the first half of the output, and from the second input to the second half of the output). In the worst case, the RA might allocate things so that the destination of the aarch64_combinev16qi is the second input followed by the first input. In that case, the split form of aarch64_combinev16qi uses three eors to swap the registers around. This PR is about a test where this worst case occurred. And given the insn description, that allocation doesn't semm unreasonable. early-ra should (hopefully) mean that we're now better at allocating subregs of vector registers. The upcoming RA subreg patches should improve things further. The best fix for the PR therefore seems to be to split the combination before RA, so that the RA can see the underlying moves. Perhaps it even makes sense to do this at expand time, avoiding the need for aarch64_combinev16qi entirely. That deserves more experimentation though. gcc/ PR target/115258 * config/aarch64/aarch64-simd.md (aarch64_combinev16qi): Allow the split before reload. * config/aarch64/aarch64.cc (aarch64_split_combinev16qi): Generalize into a form that handles pseudo registers. gcc/testsuite/ PR target/115258 * gcc.target/aarch64/pr115258.c: New test. (cherry picked from commit 39263ed2d39ac1cebde59bc5e72ddcad5dc7a1ec)
[Bug target/118501] [14 regression] aarch64: ICE in simplify_context::simplify_subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501 --- Comment #16 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:14fe427ab5eec008e12e7aa275caf046c0588c68 commit r14-11634-g14fe427ab5eec008e12e7aa275caf046c0588c68 Author: Richard Sandiford Date: Wed Apr 16 13:20:27 2025 +0100 aarch64: Fix invalid subregs in xorsign [PR118501] In the testcase, we try to use xorsign on: (subreg:DF (reg:TI R) 8) i.e. the highpart of the TI. xorsign wants to take a V2DF paradoxical subreg of this, which is rightly rejected as a direct operation. In cases like this, we need to force the highpart into a fresh register first. gcc/ PR target/118501 * config/aarch64/aarch64.md (@xorsign3): Use force_lowpart_subreg. gcc/testsuite/ PR target/118501 * gcc.c-torture/compile/pr118501.c: New test. (cherry picked from commit 6612b8e55471fabd2071a9637a06d3ffce2b05a6)
[Bug target/119133] [14 Regression] ICE: SIGSEGV in mark_label_nuses (emit-rtl.cc:3896) with -O -fno-tree-ter and _Float16 since r14-1131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119133 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Sandiford --- Fixed.
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #9 from lfoldy at gmail dot com --- (In reply to Jakub Jelinek from comment #8) > (In reply to lfoldy from comment #7) > > (In reply to Jakub Jelinek from comment #6) > > > Created attachment 61136 [details] > > > gcc15-pr119834.patch > > > > > > Untested patch (except on a short testcase with memset (ptr, 0, 17); to > > > verify that *clrmem_short -> *xc_zero splitting still works). > > > Without a reproducer it is hard to do more. > > > Perhaps it is late combine that propagates the constant? > > > > > > Can you compile with additional -da (assuming you still hit the ICE) and > > > attach all the *.[0-9]*r.* dumps? > > > > Thanks, I'll try. (It's a qemu system, compiling GCC takes about 24 hours.) > > For the -da files I meant with your current compiler, just retry the > fl_gxx -Isrc/libharfbuzz-subset.so.0.61101.0.p -Isrc > -I../harfbuzz-11.0.1/src -I. -I../harfbuzz-11.0.1 > -I/usr/local/env/s390x-linux-gcc15-alma8/devel/include > -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -D_FILE_OFFSET_BITS=64 > -Wall -Winvalid-pch -std=c++11 -fno-exceptions -O2 -g -fno-exceptions > -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden > -DHAVE_CONFIG_H -O2 -P -fPIC -MD -MQ > src/libharfbuzz-subset.so.0.61101.0.p/hb-subset.cc.o -MF > src/libharfbuzz-subset.so.0.61101.0.p/hb-subset.cc.o.d -o > src/libharfbuzz-subset.so.0.61101.0.p/hb-subset.cc.o -c > ../harfbuzz-11.0.1/src/hb-subset.cc > command with -da added to that and if it reproduces, attach here tarball of > hb_subset.cc.*[0-9]r.* Still running, the dump files are over 3GByte. .vartrack itself is 2 GByte.
[Bug target/118501] [14 regression] aarch64: ICE in simplify_context::simplify_subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118501 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #18 from Richard Sandiford --- Fixed.
[Bug target/115258] [14 Regression] register swaps for vector perm in some cases after r14-6290
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115258 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Sandiford --- Fixed.
[Bug tree-optimization/119399] [12/13/14 Backport] Overlap check in vectorized code may invoke UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:b079728cf34d050a1e7eec6e2a50cf8ce10b15cc commit r14-11632-gb079728cf34d050a1e7eec6e2a50cf8ce10b15cc Author: Richard Sandiford Date: Wed Apr 16 13:20:26 2025 +0100 Avoid using POINTER_DIFF_EXPR for overlap checks [PR119399] In r10-4803-g8489e1f45b50600c I'd used POINTER_DIFF_EXPR to subtract the two pointers involved in an overlap test. I'm not sure whether I'd specifically chosen that over MINUS_EXPR or not; if so, the only reason I can think of is that it is probably faster on targets with PSImode pointers. Regardless, as the PR points out, subtracting unrelated pointers using POINTER_DIFF_EXPR is undefined behaviour. gcc/ PR tree-optimization/119399 * tree-data-ref.cc (create_waw_or_war_checks): Use a MINUS_EXPR on two converted pointers, rather than converting a POINTER_DIFF_EXPR on the pointers. gcc/testsuite/ PR tree-optimization/119399 * gcc.dg/vect/pr119399.c: New test. (cherry picked from commit 4c8c373495d7d863dfb7102726ac3b4b41685df4)
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #10 from Jakub Jelinek --- Use xz -9e to compress it afterwards. And remove the vartrack one, there is nothing interesting in there for this PR.
[Bug tree-optimization/116125] [12/13/14 Regression] Does not fully checking for overlapping memory regions with the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125 --- Comment #11 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:2a4b0a1d02e992a64db39a2b8d5b69ad5db58eeb commit r14-11636-g2a4b0a1d02e992a64db39a2b8d5b69ad5db58eeb Author: Richard Sandiford Date: Wed Apr 16 13:20:28 2025 +0100 vect: Enforce dr_with_seg_len::align precondition [PR116125] tree-data-refs.cc uses alignment information to try to optimise the code generated for alias checks. The assumption for "normal" non-grouped, full-width scalar accesses was that the access size would be a multiple of the alignment. As Richi notes in the PR, this is a documented precondition of dr_with_seg_len: /* The minimum common alignment of DR's start address, SEG_LEN and ACCESS_SIZE. */ unsigned int align; PR115192 was a case in which this assumption didn't hold. The access was part of an aligned 4-element group, but only the first 2 elements of the group were accessed. The alignment was therefore double the access size. In r15-820-ga0fe4fb1c8d78045 I'd "fixed" that by capping the alignment in one of the output routines. But I think that was misconceived. The precondition means that we should cap the alignment at source instead. Failure to do that caused a similar wrong code bug in this PR, where the alignment comes from a short bitfield access rather than from a group access. gcc/ PR tree-optimization/116125 * tree-vect-data-refs.cc (vect_prune_runtime_alias_test_list): Make the dr_with_seg_len alignment fields describe tha access sizes as well as the pointer alignment. * tree-data-ref.cc (create_intersect_range_checks): Don't compensate for invalid alignment fields here. gcc/testsuite/ PR tree-optimization/116125 * gcc.dg/vect/pr116125.c: New test. (cherry picked from commit e8651b80aeb86da935035e218747a6b41b611497)
[Bug target/97106] [nvptx] Issues with weak aliases introduced by C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97106 --- Comment #10 from Thomas Schwinge --- *** Bug 106445 has been marked as a duplicate of this bug. ***
[Bug target/106445] nvptx offloading: C++ constructor symbol alias getting lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106445 Thomas Schwinge changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Thomas Schwinge --- Via commit r15-9523-gca9cffe737d20953082333dacebb65d4261e0d0c "For nvptx offloading, make sure to emit C++ constructor, destructor aliases [PR97106]", this now works; test cases added. *** This bug has been marked as a duplicate of bug 97106 ***
[Bug fortran/119827] Out of bounds check fails on substrings for upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119827 --- Comment #3 from kargls at comcast dot net --- (In reply to Visagan Ravindran from comment #2) > (In reply to kargls from comment #1) > > Perhaps, a review of the Fortran standard is in order. > > > >F2023, 9.4.1 > > > >R910 substring-range is [ scalar-int-expr ] : [ scalar-int-expr ] > > > > If the starting point is greater than the ending point, the substring > > has length zero; otherwise, both the starting point and the ending > > point shall be within the range 1, 2, ..., n. > > > > > > ! This does not raise a compilation or runtime error > > print *, 'MYSTR3= ', mystr(1:1-1) > > > > 1 > 0, so you have zero-length substrin > > > > ! This will not raise an error either... > > print *, 'MYSTR4= ', mystr(1:i-1) ! i-1=0 > > > > 1 > 0, so you have ... > > > > ! ... nor does this... > > i=-1 > > print *, 'MYSTR5= ', mystr(1:i) > > > > 1 > -1, so you have ... > > Thank you for your reply. A colleague informed me that the NAG compiler > picked this up as an error, but I suppose this is entirely in keeping with > the standard. I'm surprise that NAG issued an error. A warning might be appropriate. I edited the above F2023 quote to highlight the key sentence. The "otherwise" clause only applies after the determination of a zero-length string.
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #16 from Jakub Jelinek --- Note, I'm afraid my bootstrap/regtest will take until tomorrow, https://kojipkgs.fedoraproject.org//work/tasks/1218/131601218/build.log it is only make -j3 (and eventhough I've disabled LTO bootstrap, it will still take a while).
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #18 from lfoldy at gmail dot com --- Created attachment 61139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61139&action=edit dump part2
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #19 from lfoldy at gmail dot com --- Created attachment 61140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61140&action=edit dump part3
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #15 from Jakub Jelinek --- If you can reproduce, could you please attach preprocessed source? So that it can be bisected if it is indeed a 15 regression (then it might be a P1) or not?
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #17 from lfoldy at gmail dot com --- Created attachment 61138 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61138&action=edit dump part1
[Bug c++/116954] [13/14/15 Regression] format attribute is being lost for function template with a depedent type argument and decl merging since r13-4160-g2efb237ffc68ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116954 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/119572] [15 Regression] Recent change triggers regression on RISC-V vector test since r15-9062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119572 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Kito Cheng : https://gcc.gnu.org/g:52c1f60bea3f2ec589a694c3a0bf4f1c4666fa5b commit r14-11639-g52c1f60bea3f2ec589a694c3a0bf4f1c4666fa5b Author: Robin Dapp Date: Tue Apr 1 21:17:54 2025 +0200 RISC-V: Fix vec_duplicate[bimode] expander [PR119572]. Since r15-9062-g70391e3958db79 we perform vector bitmask initialization via the vec_duplicate expander directly. This triggered a latent bug in ours where we missed to mask out the single bit which resulted in an execution FAIL of pr119114.c The attached patch adds the 1-masking of the broadcast operand. PR target/119572 gcc/ChangeLog: * config/riscv/autovec.md: Mask broadcast value. (cherry picked from commit 716d39f0a248c1003033e6a312c736180790ef70)
[Bug target/119830] RISC-V:Internal Compiler Error on RISC-V Windows Toolchain (32-bit program) with -march=rv64gc_zbb_zbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119830
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-04-16
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Confirmed.
I think this patch might fix it:
```
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 38f3ae7cd84..0f3a504d064 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1007,16 +1007,16 @@ riscv_build_integer_1 (struct riscv_integer_op
codes[RISCV_MAX_INTEGER_OPS],
/* Now iterate over the bits we want to clear until the cost is
too high or we're done. */
nval = value ^ HOST_WIDE_INT_C (-1);
- nval &= HOST_WIDE_INT_C (~0x7fff);
+ nval &= ~HOST_WIDE_INT_C (0x7fff);
while (nval && alt_cost < cost)
{
HOST_WIDE_INT bit = ctz_hwi (nval);
alt_codes[alt_cost].code = AND;
- alt_codes[alt_cost].value = ~(1UL << bit);
+ alt_codes[alt_cost].value = ~(HOST_WIDE_INT_UC(1) << bit);
alt_codes[alt_cost].use_uw = false;
alt_codes[alt_cost].save_temporary = false;
alt_cost++;
- nval &= ~(1UL << bit);
+ nval &= ~(HOST_WIDE_INT_UC(1) << bit);
}
if (nval == 0 && alt_cost <= cost)
```
But that code is only on the trunk.
[Bug fortran/106948] pure subroutine with pure procedure as dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106948 --- Comment #4 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:4e3060ee17e6eb8bab718d320199f713533dbbd6 commit r15-9528-g4e3060ee17e6eb8bab718d320199f713533dbbd6 Author: Harald Anlauf Date: Tue Apr 15 20:43:05 2025 +0200 Fortran: pure subroutine with pure procedure as dummy [PR106948] PR fortran/106948 gcc/fortran/ChangeLog: * resolve.cc (gfc_pure_function): If a function has been resolved, but esym is not yet set, look at its attributes to see whether it is pure or elemental. gcc/testsuite/ChangeLog: * gfortran.dg/pure_formal_proc_4.f90: New test.
[Bug middle-end/119833] Clarify which semantics offloading compilation does (not) inherit from using the LTO infrastructure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119833 Thomas Schwinge changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97106, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105018 --- Comment #1 from Thomas Schwinge --- As a corollary to commit r15-9523-gca9cffe737d20953082333dacebb65d4261e0d0c "For nvptx offloading, make sure to emit C++ constructor, destructor aliases [PR97106]", in combination with my finding in bug 117010, comment #9, things would actually break for nvptx offloading compilation if we didn't transform weak into strong aliases during offloading compilation (as enabled by 'pass_ipa_whole_program_visibility' via 'in_lto_p' set to 'true'). One potential solution would then be: (In reply to Jakub Jelinek from bug 117010, comment #5) > [...] > So, if some offloading target like NVPTX lacks alias support or lacks weak > alias support, I'm afraid we need to tweak it; add thunks like IPA ICF uses > etc. ..., or implementing proper handling for symbol aliases as well as weak symbols in nvptx 'ld', as discussed in PR105018 "[nvptx] Need better alias support".
[Bug fortran/119836] New: [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836 Bug ID: 119836 Summary: [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- See also thread starting here: https://gcc.gnu.org/pipermail/fortran/2025-April/062044.html My crystal ball suggests the following testcase: program p implicit none integer, parameter :: n = 4 integer :: i integer :: y(n), x(n) do concurrent (i=1:n) x(i) = shiftl (i,1) ! accepted block y(i) = shiftl (i,1)! wrongly rejected end block end do print *, y end I get: foo.f90:9:14: 9 |y(i) = shiftl (i,1)! wrongly rejected | 1 Error: Reference to impure function at (1) inside a DO CONCURRENT
[Bug fortran/119836] [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org, ||kargls at comcast dot net Keywords||rejects-valid Target Milestone|--- |15.0 --- Comment #1 from anlauf at gcc dot gnu.org --- CC'ing Steve and Jerry.
[Bug cobol/119759] LICENSE file in gcc/cobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119759 Robert Dubner changed: What|Removed |Added CC||rdubner at gcc dot gnu.org --- Comment #4 from Robert Dubner --- The fact that there is a gcc/cobol/LICENSE file reflects the evolution; when we started work on the gcc-cobol fork of gcc, it wasn't clear that we were going to pursue donating our efforts to the FSF. We don't need the LICENSE file in gcc/cobol, nor do we need one in libgcobol
[Bug fortran/106948] pure subroutine with pure procedure as dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106948 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Should be fixed in gcc-15. Closing. Thanks for the report!
[Bug fortran/119836] [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Last reconfirmed||2025-04-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug middle-end/119485] OpenACC offloading compilation failure/ICE for C++ templated library functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119485 --- Comment #2 from Thomas Schwinge --- I suspect that we'll need for OpenACC something like 'gcc/omp-offload.cc:omp_discover_implicit_declare_target', and commit r11-3505-g2a10a2c0689db280ee3a94164504b7196b8370f4 "OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)" specifically. (This whole machinery currently is enabled for 'flag_openmp' only in 'gcc/cgraphunit.cc:analyze_functions'.)
[Bug target/119832] RISC-V: Redundant floating point rounding mode store/restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119832 Robin Dapp changed: What|Removed |Added CC||rdapp at gcc dot gnu.org, ||vineetg at rivosinc dot com --- Comment #3 from Robin Dapp --- Vineet is in the process of rewriting the FRM handling. CC'ing him.
[Bug libstdc++/96088] Range insertion into unordered_map is less effective than a loop with insertion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088 --- Comment #11 from Jonathan Wakely --- tl;dr: > The remaining regressions in the number of allocations and temporaries > should be addressed separately, with more conservative optimizations > specific to std::string. That is not part of this commit.
[Bug libgcc/101075] libatomic's libat_lock_n can deadlock from inconsistent locking order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101075
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:61dfb0747afcece3b7a690807b83b366ff34f329
commit r15-9525-g61dfb0747afcece3b7a690807b83b366ff34f329
Author: Jakub Jelinek
Date: Wed Apr 16 17:21:39 2025 +0200
libatomic: Fix up libat_{,un}lock_n [PR119796]
As mentioned in the PR (and I think in PR101075 too), we can run into
deadlock with libat_lock_n calls with larger n.
As mentioned in PR66842, we use multiple locks (normally 64 mutexes
for each 64 byte cache line in 4KiB page) and currently can lock more
than one lock, in particular for n [0, 64] a single lock, for n [65, 128]
2 locks, for n [129, 192] 3 locks etc.
There are two problems with this:
1) we can deadlock if there is some wrap-around, because the locks are
acquired always in the order from addr_hash (ptr) up to
locks[NLOCKS-1].mutex and then if needed from locks[0].mutex onwards;
so if e.g. 2 threads perform libat_lock_n with n = 2048+64, in one
case at pointer starting at page boundary and in another case at
page boundary + 2048 bytes, the first thread can lock the first
32 mutexes, the second thread can lock the last 32 mutexes and
then first thread wait for the lock 32 held by second thread and
second thread wait for the lock 0 held by the first thread;
fixed below by always locking the locks in order of increasing
index, if there is a wrap-around, by locking in 2 loops, first
locking some locks at the start of the array and second at the
end of it
2) the number of locks seems to be determined solely depending on the
n value, I think that is wrong, we don't know the structure alignment
on the libatomic side, it could very well be 1 byte aligned struct,
and so how many cachelines are actually (partly or fully) occupied
by the atomic access depends not just on the size, but also on
ptr % WATCH_SIZE, e.g. 2 byte structure at address page_boundary+63
should IMHO lock 2 locks because it occupies the first and second
cacheline
Note, before this patch it locked exactly one lock for n = 0, while
with this patch it could lock either no locks at all (if it is at cacheline
boundary) or 1 (otherwise).
Dunno of libatomic APIs can be called for zero sizes and whether
we actually care that much how many mutexes are locked in that case,
because one can't actually read/write anything into zero sized memory.
If you think it is important, I could add else if (nlocks == 0) nlocks = 1;
in both spots.
2025-04-16 Jakub Jelinek
PR libgcc/101075
PR libgcc/119796
* config/posix/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE). If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.
[Bug libgcc/119796] Atomic Operations Can Deadlock Without Hardware Support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:61dfb0747afcece3b7a690807b83b366ff34f329
commit r15-9525-g61dfb0747afcece3b7a690807b83b366ff34f329
Author: Jakub Jelinek
Date: Wed Apr 16 17:21:39 2025 +0200
libatomic: Fix up libat_{,un}lock_n [PR119796]
As mentioned in the PR (and I think in PR101075 too), we can run into
deadlock with libat_lock_n calls with larger n.
As mentioned in PR66842, we use multiple locks (normally 64 mutexes
for each 64 byte cache line in 4KiB page) and currently can lock more
than one lock, in particular for n [0, 64] a single lock, for n [65, 128]
2 locks, for n [129, 192] 3 locks etc.
There are two problems with this:
1) we can deadlock if there is some wrap-around, because the locks are
acquired always in the order from addr_hash (ptr) up to
locks[NLOCKS-1].mutex and then if needed from locks[0].mutex onwards;
so if e.g. 2 threads perform libat_lock_n with n = 2048+64, in one
case at pointer starting at page boundary and in another case at
page boundary + 2048 bytes, the first thread can lock the first
32 mutexes, the second thread can lock the last 32 mutexes and
then first thread wait for the lock 32 held by second thread and
second thread wait for the lock 0 held by the first thread;
fixed below by always locking the locks in order of increasing
index, if there is a wrap-around, by locking in 2 loops, first
locking some locks at the start of the array and second at the
end of it
2) the number of locks seems to be determined solely depending on the
n value, I think that is wrong, we don't know the structure alignment
on the libatomic side, it could very well be 1 byte aligned struct,
and so how many cachelines are actually (partly or fully) occupied
by the atomic access depends not just on the size, but also on
ptr % WATCH_SIZE, e.g. 2 byte structure at address page_boundary+63
should IMHO lock 2 locks because it occupies the first and second
cacheline
Note, before this patch it locked exactly one lock for n = 0, while
with this patch it could lock either no locks at all (if it is at cacheline
boundary) or 1 (otherwise).
Dunno of libatomic APIs can be called for zero sizes and whether
we actually care that much how many mutexes are locked in that case,
because one can't actually read/write anything into zero sized memory.
If you think it is important, I could add else if (nlocks == 0) nlocks = 1;
in both spots.
2025-04-16 Jakub Jelinek
PR libgcc/101075
PR libgcc/119796
* config/posix/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE). If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.
[Bug libgcc/119796] Atomic Operations Can Deadlock Without Hardware Support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
--- Comment #10 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:34fe8e90007afbc87941df9b01ffcf8747c11497
commit r15-9526-g34fe8e90007afbc87941df9b01ffcf8747c11497
Author: Jakub Jelinek
Date: Wed Apr 16 17:22:49 2025 +0200
libatomic: Fix up libat_{,un}lock_n for mingw [PR119796]
Here is just a port of the previously posted patch to mingw which
clearly has the same problems.
2025-04-16 Jakub Jelinek
PR libgcc/101075
PR libgcc/119796
* config/mingw/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE). If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.
[Bug libgcc/101075] libatomic's libat_lock_n can deadlock from inconsistent locking order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101075
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:34fe8e90007afbc87941df9b01ffcf8747c11497
commit r15-9526-g34fe8e90007afbc87941df9b01ffcf8747c11497
Author: Jakub Jelinek
Date: Wed Apr 16 17:22:49 2025 +0200
libatomic: Fix up libat_{,un}lock_n for mingw [PR119796]
Here is just a port of the previously posted patch to mingw which
clearly has the same problems.
2025-04-16 Jakub Jelinek
PR libgcc/101075
PR libgcc/119796
* config/mingw/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE). If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.
[Bug c++/114772] [12/13/14/15 Regression] pragma GCC target applied to earlier template function with __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114772 Jason Merrill changed: What|Removed |Added Target Milestone|13.4|12.5 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Summary|[13/14/15 Regression] |[12/13/14/15 Regression] |pragma GCC target applied |pragma GCC target applied |to earlier template |to earlier template |function with |function with |__attribute__((warn_unused_ |__attribute__((warn_unused_ |result)) since r12-6904 |result)) --- Comment #4 from Jason Merrill --- (In reply to Jakub Jelinek from comment #2) > Started with r12-6904-g66b86171188dcb61d2d0e0a4a98a7467e58a84a7 This is incorrect, it fails in all of GCC 4.9-15. 4.3-4.8 accept the testcase (though also don't inline the call at -O0).
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834
--- Comment #23 from Jakub Jelinek ---
Thanks, confirmed it is late_combine that changes
(insn 1817 227 1735 42 (set (reg:DI 2 %r2 [orig:250 _176 ] [250])
(const_int 4 [0x4])) "../src/hb-algs.hh":996:17 1811 {*movdi_64}
(nil))
(note 1735 1817 232 42 NOTE_INSN_DELETED)
(insn 232 1735 233 42 (parallel [
(set (reg:DI 2 %r2 [orig:250 _176 ] [250])
(plus:DI (reg:DI 2 %r2 [orig:250 _176 ] [250])
(const_int -1 [0x])))
(clobber (reg:CC 33 %cc))
]) "../src/hb-algs.hh":996:17 2197 {*adddi3}
(nil))
...
(insn 245 738 784 47 (parallel [
(set (mem:BLK (reg/f:DI 1 %r1 [orig:249 pretmp_381 ] [249]) [0
A8])
(const_int 0 [0]))
(use (reg:DI 2 %r2 [orig:250 _176 ] [250]))
(use (const:BLK (unspec:BLK [
(const_int 0 [0])
] UNSPEC_INSN)))
(clobber (reg:DI 4 %r4 [524]))
(clobber (reg:CC 33 %cc))
]) "../src/hb-algs.hh":996:17 1900 {*clrmem_short}
(nil))
to
(insn 245 738 784 47 (parallel [
(set (mem:BLK (reg/f:DI 1 %r1 [orig:249 pretmp_381 ] [249]) [0
A8])
(const_int 0 [0]))
(use (const_int 3 [0x3]))
(use (const:BLK (unspec:BLK [
(const_int 0 [0])
] UNSPEC_INSN)))
(clobber (reg:DI 4 %r4 [524]))
(clobber (reg:CC 33 %cc))
]) "../src/hb-algs.hh":996:17 1900 {*clrmem_short}
(nil))
So possibly regressed with r15-1579, bisecting now.
[Bug tree-optimization/119835] New: GCN, nvptx offloading: '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119835 Bug ID: 119835 Summary: GCN, nvptx offloading: ' Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, openmp Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org Target Milestone: --- Target: GCN, nvptx I noticed that when building the PR106445 'libgomp.c++/pr106445-1.C' with (default '-O2' and) '-fno-inline' added, we ICE for both GCN, nvptx offloading compilation: during GIMPLE pass: nrv [...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h: In member function 'begin': [...]/build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:1008:7: internal compiler error: in execute, at tree-nrv.cc:179 That's 'gcc/tree-nrv.cc:pass_nrv::execute': 174 /* In a function with an aggregate return value, the 175 gimplifier has changed all non-empty RETURN_EXPRs to 176 return the RESULT_DECL. */ 177 ret_val = gimple_return_retval (return_stmt); 178 if (ret_val) 179 gcc_assert (ret_val == result); If I manually disable the pass, we're back to good.
[Bug target/106445] nvptx offloading: C++ constructor symbol alias getting lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106445
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:0b2a2490bebd29acc4da18562eec7464601cbb05
commit r15-9524-g0b2a2490bebd29acc4da18562eec7464601cbb05
Author: Thomas Schwinge
Date: Thu Mar 20 17:25:14 2025 +0100
Add 'libgomp.c++/pr106445-1{,-O0}.C' [PR106445]
PR target/106445
libgomp/
* testsuite/libgomp.c++/pr106445-1.C: New.
* testsuite/libgomp.c++/pr106445-1-O0.C: Likewise.
[Bug target/100638] FP16 (vector) compare missed optimization on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100638
Spencer Abson changed:
What|Removed |Added
CC||Spencer.Abson at arm dot com
--- Comment #3 from Spencer Abson ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Tamar Christina from comment #0)
> Which can reproduce with just a simple:
> ```
> void foo(_Float16 *x, unsigned short *out) {
> *out = -(*x < 0.0f16);
> }
> ```
I have a patch from January for this:
https://inbox.sourceware.org/gcc-patches/20250131190557.2845160-2-spencer.ab...@arm.com/.
This is formatting revision, the change itself was OK'd for stage-1.
[Bug lto/63215] LTO causes symbols for builtin functions to be omitted from object files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63215 avieira at gcc dot gnu.org changed: What|Removed |Added CC||avieira at gcc dot gnu.org --- Comment #7 from avieira at gcc dot gnu.org --- I think this has been fixed. Following steps below gcc-nm will show me the T abs for the LTO'ed object file.
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x since r15-1579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Priority|P3 |P1 Status|NEW |ASSIGNED Summary|[15 regression] Compiling |[15 regression] Compiling |harfbuzz 11.0.1 with gcc 15 |harfbuzz 11.0.1 with gcc 15 |20250413 fails on s390x |20250413 fails on s390x ||since r15-1579 --- Comment #24 from Jakub Jelinek --- Confirmed it started with r15-1579-g792f97b44ffc5e6a967292b3747fd835e99396e7
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #54 from Jan Hubicka --- Fixed (at least when one does not play with comdats and disabling early vrp)
[Bug target/97106] [nvptx] Issues with weak aliases introduced by C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97106 --- Comment #9 from GCC Commits --- The trunk branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:ca9cffe737d20953082333dacebb65d4261e0d0c commit r15-9523-gca9cffe737d20953082333dacebb65d4261e0d0c Author: Thomas Schwinge Date: Wed Apr 16 14:00:31 2025 +0200 For nvptx offloading, make sure to emit C++ constructor, destructor aliases [PR97106] PR target/97106 gcc/ * config/nvptx/nvptx.cc (nvptx_asm_output_def_from_decls) [ACCEL_COMPILER]: Make sure to emit C++ constructor, destructor aliases. libgomp/ * testsuite/libgomp.c++/pr96390.C: Un-XFAIL nvptx offloading. * testsuite/libgomp.c-c++-common/pr96390.c: Adjust.
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #14 from lfoldy at gmail dot com --- (In reply to Sam James from comment #12) > Unfortunately I can't reproduce it yet. Could you show me `gcc -v`? > (Wondering what --with-arch= is, especially, if anything.) [alma8 build]$ fl_gcc -v Using built-in specs. COLLECT_GCC=fl_gcc COLLECT_LTO_WRAPPER=/usr/local/env/s390x-linux-gcc15-alma8/devel/libexec/gcc/s390x-ibm-linux-gnu/15.0.1/lto-wrapper Target: s390x-ibm-linux-gnu Configured with: ../gcc-15-20250413/configure --prefix=/usr/local/env/s390x-linux-gcc15-alma8/devel --build=s390x-ibm-linux-gnu --enable-checking=release --enable-languages=c,c++,fortran --enable-long-long --enable-threads --enable-__cxa_atexit --disable-libgcj --with-gmp=/usr/local/env/s390x-linux-gcc15-alma8/devel --with-mpfr=/usr/local/env/s390x-linux-gcc15-alma8/devel --with-mpc=/usr/local/env/s390x-linux-gcc15-alma8/devel --with-isl=/usr/local/env/s390x-linux-gcc15-alma8/devel --disable-multilib --disable-libstdcxx-pch --disable-nls --disable-isl-version-check --program-suffix=-15.0.1 --with-demangler-in-ld --enable-host-shared --disable-werror Thread model: posix Supported LTO compression algorithms: zlib gcc version 15.0.1 20250413 (experimental) (GCC)
[Bug c++/102012] GCC accepts any non-bool atomic constraint type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102012 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill --- I agree with Patrick; https://eel.is/c++draft/temp.names#9 says how to evaluate a concept-id, it does not say that a concept-id is always evaluated. The note even talks about one instance of a concept-id not being evaluated in an unevaluated operand.
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 Stefan Schulze Frielinghaus changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-04-16 Ever confirmed|0 |1 --- Comment #13 from Stefan Schulze Frielinghaus --- Confirmed while using default arch z900 (doesn't manifest for me for newer machines like z16). I also gave Jakubs patch a try and that fixes the ICE for me. Thanks for spotting this so quickly!
[Bug target/106447] nvptx offloading: C++ '__iterator_category' 'return' ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106447
Thomas Schwinge changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WORKSFORME
Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot
gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=106445
--- Comment #2 from Thomas Schwinge ---
I'm no longer able to reproduce this (but also can't tell when/how this got
addressed, unfortunately).
as part of commit r15-9524-g0b2a2490bebd29acc4da18562eec7464601cbb05 "Add
'libgomp.c++/pr106445-1{,-O0}.C' [PR106445]", I happened to have added a test
case for:
#pragma omp target
{
std::vector v(100);
[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118518 Bug 118518 depends on bug 106445, which changed state. Bug 106445 Summary: nvptx offloading: C++ constructor symbol alias getting lost https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106445 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug target/119832] RISC-V: Redundant floating point rounding mode store/restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119832 --- Comment #2 from Li Pan --- More details. 7 --- mode change from 10 -> 7 // NONE => DYN <<< 8 --- restore mode is dyn and prev is not call 9 --- mode change from 7 -> 9 // DYN => CALL 10 --- mode change from 10 -> 9 // NONE => CALL 11 --- mode change from 9 -> 7 // CALL => DYN <<< 12 --- backup from prev is call --- 13 --- mode change from 10 -> 9 // NONE => CALL 14 --- mode change from 9 -> 7 // CALL => DYN <<< 15 --- backup from prev is call --- 16 --- mode change from 7 -> 9 // DYN => CALL 17 --- mode change from 7 -> 8 // DYN => EXIT When prev mode is CALL, will always backup frm, and then we meet NONE => DYN, as kito mentioned, the restore will be emitted if mode is dyn and prev mode is not CALL. Not very sure if we can take care of this safely inside the riscv_emit_frm_mode_set right now. Let me reconsider this.
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #20 from Stefan Schulze Frielinghaus --- Created attachment 61141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61141&action=edit preprocessed
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #22 from Stefan Schulze Frielinghaus --- I started a bootstrap+regtest, too, for targets z900,z10,z13,z16. Each run will take around 5 hours. I will report back once they finished or if some fail on the go. I have attached a preprocessed input which fails if gcc was build for z900 using command line: c++ -std=c++11 -fno-exceptions -O2 -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -fPIC hb-subset.ii -c -o foo.o In the meantime I will reduce, too.
[Bug target/119834] [15 regression] Compiling harfbuzz 11.0.1 with gcc 15 20250413 fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119834 --- Comment #21 from lfoldy at gmail dot com --- (In reply to Jakub Jelinek from comment #15) > If you can reproduce, could you please attach preprocessed source? > So that it can be bisected if it is indeed a 15 regression (then it might be > a P1) or not? I have tried the same command line with GCC 14 and it works. [alma8 build]$ fl_gcc -v Using built-in specs. COLLECT_GCC=fl_gcc COLLECT_LTO_WRAPPER=/usr/local/env/s390x-linux-gcc14-alma8/devel/libexec/gcc/s390x-ibm-linux-gnu/14.2.1/lto-wrapper Target: s390x-ibm-linux-gnu Configured with: ../gcc-14-20241221/configure --prefix=/usr/local/env/s390x-linux-gcc14-alma8/devel --build=s390x-ibm-linux-gnu --enable-checking=release --enable-languages=c,c++,fortran --enable-long-long --enable-threads --enable-__cxa_atexit --disable-libgcj --with-gmp=/usr/local/env/s390x-linux-gcc14-alma8/devel --with-mpfr=/usr/local/env/s390x-linux-gcc14-alma8/devel --with-mpc=/usr/local/env/s390x-linux-gcc14-alma8/devel --with-isl=/usr/local/env/s390x-linux-gcc14-alma8/devel --disable-multilib --disable-libstdcxx-pch --disable-nls --disable-isl-version-check --program-suffix=-14.2.1 --with-demangler-in-ld --enable-host-shared --disable-werror Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.2.1 20241221 (GCC)
[Bug c++/110343] [C++26] P2558R2 - Add @, $, and ` to the basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343 --- Comment #18 from Jakub Jelinek --- Created attachment 61142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61142&action=edit gcc15-pr110343-c.patch So far lightly tested patch for allowing those in C23/C2Y.
[Bug fortran/119836] [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836 --- Comment #3 from kargls at comcast dot net --- Well, that's weird. It appears that I'm the guilty person. 'git blame resolve.cc' leads to 7d92901c878c commit 7d92901c878c6c00ada7f9cee8825f03ad4722f1 Author: Steve Kargl Date: Sun Nov 24 18:26:03 2024 -0800 Fortran: Check IMPURE in BLOCK inside DO CONCURRENT. PR fortran/117765 gcc/fortran/ChangeLog: * resolve.cc (check_pure_function): Check the stack to see if the function is in a nested BLOCK and, if that block is inside a DO_CONCURRENT, issue an error. gcc/testsuite/ChangeLog: * gfortran.dg/impure_fcn_do_concurrent.f90: New test.
[Bug fortran/119836] [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
--- Comment #4 from kargls at comcast dot net ---
All intrinsic functions are simple, and therefore pure. The following
patch should fix the issue with functions. A similar fix is needed for
subroutine, but only a few intrinsic subroutine are pure or simple. I
don't have the time today to poke at subroutines.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index cdf043b6411..f4e029bdda1 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -3243,7 +3243,8 @@ pure_stmt_function (gfc_expr *e, gfc_symbol *sym)
/* Check if an impure function is allowed in the current context. */
-static bool check_pure_function (gfc_expr *e)
+static bool
+check_pure_function (gfc_expr *e)
{
const char *name = NULL;
code_stack *stack;
@@ -3258,9 +3259,16 @@ static bool check_pure_function (gfc_expr *e)
if (stack->current->op == EXEC_BLOCK) saw_block = true;
if (saw_block && stack->current->op == EXEC_DO_CONCURRENT)
{
- gfc_error ("Reference to impure function at %L inside a "
-"DO CONCURRENT", &e->where);
- return false;
+ bool is_pure = e->value.function.isym
+|| (e->value.function.esym
+&& (e->value.function.esym->attr.pure
+|| e->value.function.esym->attr.elemental));
+ if (!is_pure)
+ {
+ gfc_error ("Reference to impure function at %L inside a "
+"DO CONCURRENT", &e->where);
+ return false;
+ }
}
}
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 --- Comment #13 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c0d805192b0092235b2ef32a184b17a76ebac401 commit r12-11044-gc0d805192b0092235b2ef32a184b17a76ebac401 Author: Jonathan Wakely Date: Mon Dec 9 17:35:24 2024 + libstdc++: Skip redundant assertions in std::array equality [PR106212] As PR c++/106212 shows, the Debug Mode checks cause a compilation error for equality comparisons involving std::array prvalues in constant expressions. Those Debug Mode checks are redundant when comparing two std::array objects, because we already know we have a valid range. We can also avoid the unnecessary step of using std::__niter_base to do __normal_iterator unwrapping, which isn't needed because our std::array iterators are just pointers. Using std::__equal_aux1 instead of std::equal avoids the redundant checks in std::equal and std::__equal_aux. libstdc++-v3/ChangeLog: PR libstdc++/106212 * include/std/array (operator==): Use std::__equal_aux1 instead of std::equal. * testsuite/23_containers/array/comparison_operators/106212.cc: New test. (cherry picked from commit 3aeb2edee2f9fc39ab77c7e020f09d7204b167ac)
[Bug libstdc++/116549] std::disable_sized_sentinel_for is missing specialisation for std::move_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116549 Jonathan Wakely changed: What|Removed |Added Target Milestone|13.4|12.5 --- Comment #12 from Jonathan Wakely --- Also fixed for 12.5
[Bug libstdc++/117560] std::views::zip incompatible with std::filesystem::directory_iterator & std::views::transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117560 --- Comment #8 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5f3811fd50113571127b849325ab8f6c674158af commit r12-11040-g5f3811fd50113571127b849325ab8f6c674158af Author: Jonathan Wakely Date: Thu Nov 14 01:14:44 2024 + libstdc++: Add missing parts of LWG 3480 for directory iterators [PR117560] It looks like I only read half the resolution of LWG 3480 and decided we already supported it. As well as making the non-member overloads of end take their parameters by value, we need some specializations of the enable_borrowed_range and enable_view variable templates. libstdc++-v3/ChangeLog: PR libstdc++/117560 * include/bits/fs_dir.h (enable_borrowed_range, enable_view): Define specializations for directory iterators, as per LWG 3480. * testsuite/27_io/filesystem/iterators/lwg3480.cc: New test. (cherry picked from commit eec6e8923586b9a54e37f32cef112d26d86e8f01)
[Bug libstdc++/117560] std::views::zip incompatible with std::filesystem::directory_iterator & std::views::transform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117560 Jonathan Wakely changed: What|Removed |Added Target Milestone|13.4|12.5 --- Comment #9 from Jonathan Wakely --- Also fixed for 12.5
[Bug c++/117966] [12/13/14/15 regression] constexpr std::span construction fails to compile with D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117966 --- Comment #17 from Jonathan Wakely --- The error in std::span is fixed for 12.5, 13.4 and 14.3
[Bug c++/119838] optional template keyword with global namespace causing error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119838 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-04-16 Status|UNCONFIRMED |NEW Summary|optional template keyword |optional template keyword |causing error |with global namespace ||causing error Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. It only happens with the global namespace specified (without another namespace). Related to a few other issues. PR 50080 fixed the non-global namespace version.
[Bug libstdc++/113841] Can't swap two std::hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841 --- Comment #18 from Jonathan Wakely --- The std::vector problem is fixed for 12.5 and 13.3 and 14.1
[Bug tree-optimization/116922] [12 Regression] ICE: in op_iter_init, at ssa-iterators.h:604 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116922 --- Comment #10 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:a5929ef809558a3117e7a6e2e66316a828b50f29 commit r12-11048-ga5929ef809558a3117e7a6e2e66316a828b50f29 Author: Andrew Pinski Date: Tue Oct 1 14:48:19 2024 -0700 backprop: Fix deleting of a phi node [PR116922] The problem here is remove_unused_var is called on a name that is defined by a phi node but it deletes it like removing a normal statement. remove_phi_node should be called rather than gsi_remove for phinodes. Note there is a possibility of using simple_dce_from_worklist instead but that is for another day. Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/116922 gcc/ChangeLog: * gimple-ssa-backprop.cc (remove_unused_var): Handle phi nodes correctly. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr116922.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit cea87c84eacdb422caeada734ba5138c994d7022)
[Bug middle-end/116749] [12/13/14/15 Regression] program crash under -O3 optimization since r12-5300-gf98f373dd822b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116749 --- Comment #14 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5347b382a38d664216bd7484dd5438a1863d02a3 commit r12-11047-g5347b382a38d664216bd7484dd5438a1863d02a3 Author: Andrew Pinski Date: Mon Dec 2 08:35:23 2024 -0800 phiopt: Reset the number of iterations information of a loop when changing an exit from the loop [PR117243] After r12-5300-gf98f373dd822b3, phiopt could get the following bb structure: | middle-bb -| || | || | phi<1, 2> | | cond | | || | |+---| Which was considered 2 loops. The inner loop had esimtate of upper_bound to be 8, due to the original `for (b = 0; b <= 7; b++)`. The outer loop was already an infinite one. So phiopt would come along and change the condition to be unconditionally true, we change the inner loop to being an infinite one but don't reset the estimate on the loop and cleanup cfg comes along and changes it into one loop but also does not reset the estimate of the loop. Then the loop unrolling uses the old estimate and decides to add an unreachable there.o So the fix is when phiopt changes an exit to a loop, reset the estimates, similar to how cleanupcfg does it when merging some basic blocks. Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/117243 PR tree-optimization/116749 gcc/ChangeLog: * tree-ssa-phiopt.cc (replace_phi_edge_with_variable): Reset loop estimates if the cond_block was an exit to a loop. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr117243-1.c: New test. * gcc.dg/torture/pr117243-2.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit b7c69cc072ef0da36439ebc55c513b48e68391b7)
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 --- Comment #14 from Jonathan Wakely --- The std::array problem is fixed for 12.5, 13.4 and 14.3
[Bug tree-optimization/111285] [12 Regression] vector ABSU is lowered incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111285 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:df76d7b05693dc511a114cb6ece2cbc5eef25dea commit r12-11049-gdf76d7b05693dc511a114cb6ece2cbc5eef25dea Author: Andrew Pinski Date: Sun Oct 27 13:16:22 2024 -0700 vec-lowering: Fix ABSU lowering [PR111285] ABSU_EXPR lowering incorrectly used the resulting type for the new expression but in the case of ABSU the resulting type is an unsigned type and with ABSU is folded away. The fix is to use a signed type for the expression instead. Bootstrapped and tested on x86_64-linux-gnu. PR middle-end/111285 gcc/ChangeLog: * tree-vect-generic.cc (do_unop): Use a signed type for the operand if the operation was ABSU_EXPR. gcc/testsuite/ChangeLog: * g++.dg/torture/vect-absu-1.C: New test. Signed-off-by: Andrew Pinski (cherry picked from commit ad0084337e901ddaedd48c14e7a5dad9fc2a093e)
[Bug middle-end/117243] [12 regression] program crash under -O3 optimization or higher since r12-5300-gf98f373dd822b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117243 --- Comment #24 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5347b382a38d664216bd7484dd5438a1863d02a3 commit r12-11047-g5347b382a38d664216bd7484dd5438a1863d02a3 Author: Andrew Pinski Date: Mon Dec 2 08:35:23 2024 -0800 phiopt: Reset the number of iterations information of a loop when changing an exit from the loop [PR117243] After r12-5300-gf98f373dd822b3, phiopt could get the following bb structure: | middle-bb -| || | || | phi<1, 2> | | cond | | || | |+---| Which was considered 2 loops. The inner loop had esimtate of upper_bound to be 8, due to the original `for (b = 0; b <= 7; b++)`. The outer loop was already an infinite one. So phiopt would come along and change the condition to be unconditionally true, we change the inner loop to being an infinite one but don't reset the estimate on the loop and cleanup cfg comes along and changes it into one loop but also does not reset the estimate of the loop. Then the loop unrolling uses the old estimate and decides to add an unreachable there.o So the fix is when phiopt changes an exit to a loop, reset the estimates, similar to how cleanupcfg does it when merging some basic blocks. Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/117243 PR tree-optimization/116749 gcc/ChangeLog: * tree-ssa-phiopt.cc (replace_phi_edge_with_variable): Reset loop estimates if the cond_block was an exit to a loop. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr117243-1.c: New test. * gcc.dg/torture/pr117243-2.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit b7c69cc072ef0da36439ebc55c513b48e68391b7)
[Bug tree-optimization/118922] [12 regression] Miscompile at -O2/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118922 --- Comment #29 from GCC Commits --- The releases/gcc-12 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:9d0c2f769553c65a39c12df3c2d0891c53fafd6a commit r12-11050-g9d0c2f769553c65a39c12df3c2d0891c53fafd6a Author: Andrew Pinski Date: Sat Mar 8 22:43:54 2025 -0800 phiopt: Fix value_replacement for middle bb having phi nodes [PR118922] After r12-5300-gf98f373dd822b3, value_replacement would be able to look at the following cfg structure: ``` [local count: 1014686024]: if (h_6 != 0) goto ; [94.50%] else goto ; [5.50%] [local count: 114863530]: # h_6 = PHI <0(4), 1(5)> [local count: 1073741824]: # f_8 = PHI <0(5), h_6(6)> _9 = f_8 ^ 1; a.0_10 = a; _11 = _9 + a.0_10; if (_11 != -117) goto ; [94.50%] else goto ; [5.50%] ``` value_replacement would incorrectly think the middle bb (6) was empty and so it decides to remove condition in bb5 and replacing it with 0 as the function thought it was `h_6 ? 0 : h_6`. But since the there is an incoming phi node to bb6 defining h_6 that is incorrect. The fix is to check if there is phi nodes in the middle bb and set empty_or_with_defined_p to false. This was not needed before r12-5300-gf98f373dd822b3 because the phi would have been dead otherwise due to other checks. Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/118922 gcc/ChangeLog: * tree-ssa-phiopt.cc (value_replacement): Set empty_or_with_defined_p to false when there is phi nodes for the middle bb. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr118922-1.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 7232c005afb5002cdfd0a2dbd0e8b8f2d80250ce)
