[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012 --- Comment #22 from Levi Zim --- This no longer reproduces for gcc 15.1.1+r7+gf36ec88aa85a. I am not sure if the underlying bug is solved or the trigger no longer triggers.
[Bug libstdc++/120171] New: Consider using custom glibc locales for testing std::locale facets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120171 Bug ID: 120171 Summary: Consider using custom glibc locales for testing std::locale facets Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 120170 Target Milestone: --- Some libstdc++ tests for locale facets are non-portable because they assume e.g. nl_NL uses thousands separators, but that might be true on Linux and false on BSD, or true on Fedora and false on Debian, or true today and then change to false tomorrow. When we want to test that std::locale correctly uses the underlying libc locale's information, we don't really care whether or not thousands separators are used in the Netherlands, we only care that the libstdc++ code is doing what it's supposed to do for the underlying locale data. If we created custom glibc locales we could have test locales with the exact properties we want, so that we wouldn't rely on real data from glibc which can change over time or between distros. See https://sourceware.org/glibc/wiki/Locales#Testing_Locales for details on testing custom locales. Obviously this would only work for glibc-based targets, and so only for --enable-clocale=gnu builds. It would still be useful though. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120170 [Bug 120170] [meta-bug] C++ std::locale
[Bug tree-optimization/120164] GCC fails vectorization when using conditional __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164 --- Comment #4 from Richard Biener --- Note with "vectorizing" prefetches I meant adjusting the prefetched address, "vectorizing" it as an induction but only prefetching on the first (or last?) address of the vector induction vector. Aka simply advancing the prefetch address IV by VF * step and keeping the "scalar" prefetch as-is. The other alternative is to handle it like we could other not vectorizable scalar code, duplicate it according to the unroll factor (the VF), but that's likely worse in practice. For the conditional case we'd ideally do if (any(vector_'i' % 1024 == 0)) __builtin_prefetch (&(b[first_of(vector_'i')+1024])); with 'first_of' selecting the "first" element of vector_'i' masked by the vector_'i' % 1024 == 0 test. Or try to express all this with the scalar vector iteration IV somehow (eventually possible for no-VLA). But yes, there's cost for maintaining 'i', for doing the compare-and-branch (which needs to be supported). A trivial implementation might fall out from making loop vectorization support unvectorizable statements (copy them VF times, marshal to/from vector for operands/result as needed) and from supporting control flow within vectorizable loops. For x86 it's low priority, who writes prefetches usually writes vector intrinsics as well.
[Bug libstdc++/120170] [meta-bug] C++ std::locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120170 Bug 120170 depends on bug 96322, which changed state. Bug 96322 Summary: 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/120171] Consider using custom glibc locales for testing std::locale facets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120171 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-08 Blocks|96322 | Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96322 --- Comment #1 from Jonathan Wakely --- Bug 96322 is an example where the glibc locale data changed, and we have a test that started to fail. The fix for glibc apparently doesn't work for FreeBSD. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322 [Bug 96322] 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3
[Bug libfortran/120152] [15/16 Regression] libgfortran ABI problem starting with r15-4124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:66f5f03853035cc917627e7d044bff8ccd9eca3f commit r16-471-g66f5f03853035cc917627e7d044bff8ccd9eca3f Author: Jakub Jelinek Date: Thu May 8 10:43:22 2025 +0200 fortran: Add testcases for PR120152, PR120153 and PR120158 The following patch adds testcase coverage for the 3 recently fixed libgfortran PRs. On trunk before those fixes I'm getting with -m32 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) and with -m64 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120158.f90 -O0 execution test FAIL: gfortran.dg/pr120158.f90 -O1 execution test FAIL: gfortran.dg/pr120158.f90 -O2 execution test FAIL: gfortran.dg/pr120158.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/pr120158.f90 -O3 -g execution test FAIL: gfortran.dg/pr120158.f90 -Os execution test On latest trunk everything PASSes. 2025-05-08 Jakub Jelinek PR libfortran/120152 PR libfortran/120153 PR libfortran/120158 * gfortran.dg/pr120152_1.f90: New test. * gfortran.dg/pr120152_2.f90: New test. * gfortran.dg/pr120153.f90: New test. * gfortran.dg/pr120158.f90: New test.
[Bug tree-optimization/120164] GCC fails vectorization when using conditional __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
--- Comment #5 from Tamar Christina ---
(In reply to Richard Biener from comment #4)
> Note with "vectorizing" prefetches I meant adjusting the prefetched address,
> "vectorizing" it as an induction but only prefetching on the first (or
> last?) address of the vector induction vector. Aka simply advancing the
> prefetch
> address IV by VF * step and keeping the "scalar" prefetch as-is. The
> other alternative is to handle it like we could other not vectorizable scalar
> code, duplicate it according to the unroll factor (the VF), but that's likely
> worse in practice. For the conditional case we'd ideally do
>
> if (any(vector_'i' % 1024 == 0))
>__builtin_prefetch (&(b[first_of(vector_'i')+1024]));
>
For SVE based prefetching you'd have to use the masked based version, i.e.
https://developer.arm.com/documentation/ddi0602/2025-03/SVE-Instructions/PRFW--scalar-plus-immediate---Contiguous-prefetch-words--immediate-index--
as we wouldn't watch the branch in the codegen.
It's a bit harder than just adjusting the scalar IV as it's also supported for
gathers and scatters where you have a vector addresses in the prefetch for e.g.
https://developer.arm.com/documentation/ddi0602/2025-03/SVE-Instructions/PRFW--vector-plus-immediate---Gather-prefetch-words--vector-plus-immediate--
So this would actually need codegen support and be part of the SLP tree so it
can use the invariants created by the vectorizer for addresses and deal with
complexities such as what happens if we scalarize the gather later on.
> For x86 it's low priority, who writes prefetches usually writes vector
> intrinsics as well.
Agreed.
The given example is an easy one to drop, but I wonder what would happen if the
block had other instructions too
void foo(double * restrict a, double * restrict b, int n){
int i;
for(i=0; i
[Bug libstdc++/64797] 22_locale/conversions/string/2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64797 Jonathan Wakely changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #12 from Jonathan Wakely --- *** Bug 64846 has been marked as a duplicate of this bug. ***
[Bug libfortran/120153] Missing UINTEGER symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120153 --- Comment #4 from GCC Commits --- The releases/gcc-15 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0ca51bd433869037061bb72d5b6872e423856189 commit r15-9640-g0ca51bd433869037061bb72d5b6872e423856189 Author: Jakub Jelinek Date: Wed May 7 18:47:50 2025 +0200 libfortran: Add 5 missing UNSIGNED symbols [PR120153] While looking at PR120152, I have noticed that libgfortran.so doesn't export 5 *m16* symbols I would have expected that should be exported. This is caused by 2 issues, one filename was forgotten to be added in r15-4124 to i_maxloc1_c (guess because generated/maxloc1_16_i16.c was kept in the position after generated/maxloc1_8_m16.c and the i -> m difference wasn't spotted), and one some garbage prefix on HAVE_GFC_UINTEGER_16 macro. The first two hunks of this patch fix that. Though, as GCC 15.1 has been released already, we can't add these symbols to GFORTRAN_15 symbol version as they've never been there, so the patch adds them to a new GFORTRAN_15.2 symbol version instead. 2025-05-07 Jakub Jelinek PR libfortran/120153 * Makefile.am (i_maxloc1_c): Add generated/maxloc1_16_m16.c. * intrinsics/random.c (arandom_m16): Use #ifdef HAVE_GFC_UINTEGER_16 guard rather than #ifdef GFC_HAVE_GFC_UINTEGER_16. * gfortran.map (GFORTRAN_15): Remove _gfortran_arandom_m16, _gfortran_maxloc1_16_m16, _gfortran_mmaxloc1_16_m16 and _gfortran_smaxloc1_16_m16. (GFORTRAN_15.2): New symbol version, add those 4 symbols to it. * generated/maxloc1_16_m16.c: New file. * Makefile.in: Regenerate. (cherry picked from commit e0c783f31b39a56cbfcc27d84633f9254b5b508d)
[Bug libfortran/120153] Missing UINTEGER symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120153 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:66f5f03853035cc917627e7d044bff8ccd9eca3f commit r16-471-g66f5f03853035cc917627e7d044bff8ccd9eca3f Author: Jakub Jelinek Date: Thu May 8 10:43:22 2025 +0200 fortran: Add testcases for PR120152, PR120153 and PR120158 The following patch adds testcase coverage for the 3 recently fixed libgfortran PRs. On trunk before those fixes I'm getting with -m32 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) and with -m64 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120158.f90 -O0 execution test FAIL: gfortran.dg/pr120158.f90 -O1 execution test FAIL: gfortran.dg/pr120158.f90 -O2 execution test FAIL: gfortran.dg/pr120158.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/pr120158.f90 -O3 -g execution test FAIL: gfortran.dg/pr120158.f90 -Os execution test On latest trunk everything PASSes. 2025-05-08 Jakub Jelinek PR libfortran/120152 PR libfortran/120153 PR libfortran/120158 * gfortran.dg/pr120152_1.f90: New test. * gfortran.dg/pr120152_2.f90: New test. * gfortran.dg/pr120153.f90: New test. * gfortran.dg/pr120158.f90: New test.
[Bug libfortran/120158] Incorrect UNSIGNED maxval/maxloc etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120158 --- Comment #5 from GCC Commits --- The releases/gcc-15 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7317c72b028e057ddbe918ff6968e5e586a35850 commit r15-9642-g7317c72b028e057ddbe918ff6968e5e586a35850 Author: Jakub Jelinek Date: Thu May 8 10:43:22 2025 +0200 fortran: Add testcases for PR120152, PR120153 and PR120158 The following patch adds testcase coverage for the 3 recently fixed libgfortran PRs. On trunk before those fixes I'm getting with -m32 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) and with -m64 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120158.f90 -O0 execution test FAIL: gfortran.dg/pr120158.f90 -O1 execution test FAIL: gfortran.dg/pr120158.f90 -O2 execution test FAIL: gfortran.dg/pr120158.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/pr120158.f90 -O3 -g execution test FAIL: gfortran.dg/pr120158.f90 -Os execution test On latest trunk everything PASSes. 2025-05-08 Jakub Jelinek PR libfortran/120152 PR libfortran/120153 PR libfortran/120158 * gfortran.dg/pr120152_1.f90: New test. * gfortran.dg/pr120152_2.f90: New test. * gfortran.dg/pr120153.f90: New test. * gfortran.dg/pr120158.f90: New test. (cherry picked from commit 66f5f03853035cc917627e7d044bff8ccd9eca3f)
[Bug libstdc++/64846] FAIL: 22_locale/conversions/string/2.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64846 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Blocks||120170 --- Comment #1 from Jonathan Wakely --- I think this is a dup of PR 64797 and so would have been fixed by r5-7572-gb6584a72ac8d30 *** This bug has been marked as a duplicate of bug 64797 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120170 [Bug 120170] [meta-bug] C++ std::locale
[Bug libfortran/120158] Incorrect UNSIGNED maxval/maxloc etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120158 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:66f5f03853035cc917627e7d044bff8ccd9eca3f commit r16-471-g66f5f03853035cc917627e7d044bff8ccd9eca3f Author: Jakub Jelinek Date: Thu May 8 10:43:22 2025 +0200 fortran: Add testcases for PR120152, PR120153 and PR120158 The following patch adds testcase coverage for the 3 recently fixed libgfortran PRs. On trunk before those fixes I'm getting with -m32 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) and with -m64 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120158.f90 -O0 execution test FAIL: gfortran.dg/pr120158.f90 -O1 execution test FAIL: gfortran.dg/pr120158.f90 -O2 execution test FAIL: gfortran.dg/pr120158.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/pr120158.f90 -O3 -g execution test FAIL: gfortran.dg/pr120158.f90 -Os execution test On latest trunk everything PASSes. 2025-05-08 Jakub Jelinek PR libfortran/120152 PR libfortran/120153 PR libfortran/120158 * gfortran.dg/pr120152_1.f90: New test. * gfortran.dg/pr120152_2.f90: New test. * gfortran.dg/pr120153.f90: New test. * gfortran.dg/pr120158.f90: New test.
[Bug libfortran/120152] [15/16 Regression] libgfortran ABI problem starting with r15-4124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jakub Jelinek --- Fixed for 15.2 and trunk.
[Bug preprocessor/116047] C preprocessor bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116047
--- Comment #7 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:bfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea
commit r15-9638-gbfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea
Author: Jakub Jelinek
Date: Wed May 7 17:25:42 2025 +0200
libcpp: Further fixes for incorrect line numbers in large files [PR120061]
The backport of the PR108900 fix to 14 branch broke building chromium
because static_assert (__LINE__ == expected_line_number, ""); now triggers
as the __LINE__ values are off by one.
This isn't the case on the trunk and 15 branch because we've switched
to 64-bit location_t and so one actually needs far longer header files
to trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12
contain (large) testcases in patch form which show on the 14 branch
that the first one used to fail before the PR108900 backport and now
works correctly, while the second one attempts to match the chromium
behavior and it used to pass before the PR108900 backport and now it
FAILs.
The two testcases show rare problematic cases, because
do_include_common -> parse_include -> check_eol -> check_eol_1 ->
cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start
triggers there
/* Allocate the new line_map. However, if the current map only has a
single line we can sometimes just increase its column_bits
instead. */
if (line_delta < 0
|| last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
|| SOURCE_COLUMN (map, highest) >= (1U << (column_bits -
range_bits))
|| ( /* We can't reuse the map if the line offset is sufficiently
large to cause overflow when computing location_t values.
*/
(to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
>= (((uint64_t) 1)
<< (CHAR_BIT * sizeof (linenum_type) - column_bits)))
|| range_bits < map->m_range_bits)
map = linemap_check_ordinary
(const_cast
(linemap_add (set, LC_RENAME,
ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
ORDINARY_MAP_FILE_NAME (map),
to_line)));
and so creates a new ordinary map on the line right after the
(problematic) #include line.
Now, in the spot that r14-11679-g8a884140c2bcb7 patched,
pfile->line_table->highest_location in all 3 tests (also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13
) is before the decrement the start of the line after the #include line and
so
the decrement is really desirable in that case to put highest_location
somewhere on the line where the #include actually is.
But at the same time it is also undesirable, because if we do decrement it,
then linemap_add LC_ENTER called from _cpp_do_file_change will then
/* Generate a start_location above the current highest_location.
If possible, make the low range bits be zero. */
location_t start_location = set->highest_location + 1;
unsigned range_bits = 0;
if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS)
range_bits = set->default_range_bits;
start_location += (1 << range_bits) - 1;
start_location &= ~((1 << range_bits) - 1);
linemap_assert (!LINEMAPS_ORDINARY_USED (set)
|| (start_location
>= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP
(set;
and we can end up with the new LC_ENTER ordinary map having the same
start_location as the preceding LC_RENAME one.
Next thing that happens is computation of included_from:
if (reason == LC_ENTER)
{
if (set->depth == 0)
map->included_from = 0;
else
/* The location of the end of the just-closed map. */
map->included_from
= (((map[0].start_location - 1 - map[-1].start_location)
& ~((1 << map[-1].m_column_and_range_bits) - 1))
+ map[-1].start_location);
The normal case (e.g. with the testcase included at the start of this
comment) is
that map[-1] starts somewhere earlier and so map->included_from computation
above
nicely computes location_t which expands to the start of the #include line.
With r14-11679 reverted, for #c11 as well as #c12
map[0].start_location == map[-1].start_location above, and so it is
((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1)))
+ map[-1].start_location,
which happens to be start of the #include line.
For #c11 map[0].start_location is 0x53a0 and map[-1] has
m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 12
[Bug libfortran/120158] Incorrect UNSIGNED maxval/maxloc etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120158
--- Comment #4 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:d4fd651d23b007fc9cd93a9300afab21d6dec2ee
commit r15-9641-gd4fd651d23b007fc9cd93a9300afab21d6dec2ee
Author: Jakub Jelinek
Date: Thu May 8 09:36:30 2025 +0200
libfortran: Fix up maxval/maxloc for UNSIGNED [PR120158]
When libgfortran is compiled, there are some -Woverflow warnings like
../../../libgfortran/generated/maxloc0_4_m1.c:99:14: warning: unsigned
conversion from âintâ to âGFC_UINTEGER_1â {aka âunsigned charâ}
changes value from â-255â to â1â [-Woverflow]
99 | maxval = -GFC_UINTEGER_1_HUGE;
| ^
and those actually point a bug in the maxloc*/maxval* implementation
for UNSIGNED.
The intent of
#if defined ('atype_inf`)
result = -atype_inf;
#else
result = atype_min;
#endif
(or similar for maxval) is to initialize the variable with
minimum value of the type, if the type has infinities, then
negative infinity, otherwise the minimum (normalized) value.
atype_min expands for signed integers to say (-GFC_INTEGER_4_HUGE-1)
or for floating point to say -GFC_REAL_8_HUGE.
For UNSIGNED it expands to e.g. -GFC_UINTEGER_4_HUGE, but that is
-0xU which is 1U, while the minimum value of the type is
0.
Haven't tried to construct testcases for that, but I believe e.g.
maskval could return incorrectly 1 on an array (or masked array)
full of 0s, or maxloc could identify incorrectly the maximum location.
The following patch makes sure atype_min expands to 0 for atype_name
GFC_UINTEGER*.
2025-05-07 Jakub Jelinek
PR libfortran/120158
* m4/iparm.m4 (atype_min): For atype_name starting with
GFC_UINTEGER define to 0.
* generated/maxloc0_16_m1.c: Regenerate.
* generated/maxloc0_16_m2.c: Regenerate.
* generated/maxloc0_16_m4.c: Regenerate.
* generated/maxloc0_16_m8.c: Regenerate.
* generated/maxloc0_16_m16.c: Regenerate.
* generated/maxloc0_4_m1.c: Regenerate.
* generated/maxloc0_4_m2.c: Regenerate.
* generated/maxloc0_4_m4.c: Regenerate.
* generated/maxloc0_4_m8.c: Regenerate.
* generated/maxloc0_4_m16.c: Regenerate.
* generated/maxloc0_8_m1.c: Regenerate.
* generated/maxloc0_8_m2.c: Regenerate.
* generated/maxloc0_8_m4.c: Regenerate.
* generated/maxloc0_8_m8.c: Regenerate.
* generated/maxloc0_8_m16.c: Regenerate.
* generated/maxloc1_16_m1.c: Regenerate.
* generated/maxloc1_16_m2.c: Regenerate.
* generated/maxloc1_16_m4.c: Regenerate.
* generated/maxloc1_16_m8.c: Regenerate.
* generated/maxloc1_16_m16.c: Regenerate.
* generated/maxloc1_4_m1.c: Regenerate.
* generated/maxloc1_4_m2.c: Regenerate.
* generated/maxloc1_4_m4.c: Regenerate.
* generated/maxloc1_4_m8.c: Regenerate.
* generated/maxloc1_4_m16.c: Regenerate.
* generated/maxloc1_8_m1.c: Regenerate.
* generated/maxloc1_8_m2.c: Regenerate.
* generated/maxloc1_8_m4.c: Regenerate.
* generated/maxloc1_8_m8.c: Regenerate.
* generated/maxloc1_8_m16.c: Regenerate.
* generated/maxval_m1.c: Regenerate.
* generated/maxval_m2.c: Regenerate.
* generated/maxval_m4.c: Regenerate.
* generated/maxval_m8.c: Regenerate.
* generated/maxval_m16.c: Regenerate.
(cherry picked from commit 8c73c99b6a8c3a562fef360bc269bd60bab36076)
[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061
--- Comment #22 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:bfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea
commit r15-9638-gbfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea
Author: Jakub Jelinek
Date: Wed May 7 17:25:42 2025 +0200
libcpp: Further fixes for incorrect line numbers in large files [PR120061]
The backport of the PR108900 fix to 14 branch broke building chromium
because static_assert (__LINE__ == expected_line_number, ""); now triggers
as the __LINE__ values are off by one.
This isn't the case on the trunk and 15 branch because we've switched
to 64-bit location_t and so one actually needs far longer header files
to trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12
contain (large) testcases in patch form which show on the 14 branch
that the first one used to fail before the PR108900 backport and now
works correctly, while the second one attempts to match the chromium
behavior and it used to pass before the PR108900 backport and now it
FAILs.
The two testcases show rare problematic cases, because
do_include_common -> parse_include -> check_eol -> check_eol_1 ->
cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start
triggers there
/* Allocate the new line_map. However, if the current map only has a
single line we can sometimes just increase its column_bits
instead. */
if (line_delta < 0
|| last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
|| SOURCE_COLUMN (map, highest) >= (1U << (column_bits -
range_bits))
|| ( /* We can't reuse the map if the line offset is sufficiently
large to cause overflow when computing location_t values.
*/
(to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
>= (((uint64_t) 1)
<< (CHAR_BIT * sizeof (linenum_type) - column_bits)))
|| range_bits < map->m_range_bits)
map = linemap_check_ordinary
(const_cast
(linemap_add (set, LC_RENAME,
ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
ORDINARY_MAP_FILE_NAME (map),
to_line)));
and so creates a new ordinary map on the line right after the
(problematic) #include line.
Now, in the spot that r14-11679-g8a884140c2bcb7 patched,
pfile->line_table->highest_location in all 3 tests (also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13
) is before the decrement the start of the line after the #include line and
so
the decrement is really desirable in that case to put highest_location
somewhere on the line where the #include actually is.
But at the same time it is also undesirable, because if we do decrement it,
then linemap_add LC_ENTER called from _cpp_do_file_change will then
/* Generate a start_location above the current highest_location.
If possible, make the low range bits be zero. */
location_t start_location = set->highest_location + 1;
unsigned range_bits = 0;
if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS)
range_bits = set->default_range_bits;
start_location += (1 << range_bits) - 1;
start_location &= ~((1 << range_bits) - 1);
linemap_assert (!LINEMAPS_ORDINARY_USED (set)
|| (start_location
>= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP
(set;
and we can end up with the new LC_ENTER ordinary map having the same
start_location as the preceding LC_RENAME one.
Next thing that happens is computation of included_from:
if (reason == LC_ENTER)
{
if (set->depth == 0)
map->included_from = 0;
else
/* The location of the end of the just-closed map. */
map->included_from
= (((map[0].start_location - 1 - map[-1].start_location)
& ~((1 << map[-1].m_column_and_range_bits) - 1))
+ map[-1].start_location);
The normal case (e.g. with the testcase included at the start of this
comment) is
that map[-1] starts somewhere earlier and so map->included_from computation
above
nicely computes location_t which expands to the start of the #include line.
With r14-11679 reverted, for #c11 as well as #c12
map[0].start_location == map[-1].start_location above, and so it is
((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1)))
+ map[-1].start_location,
which happens to be start of the #include line.
For #c11 map[0].start_location is 0x53a0 and map[-1] has
m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 1
[Bug preprocessor/108900] [libcpp] cpp gives wrong line number information with a file huge number of lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900
--- Comment #20 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:bfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea
commit r15-9638-gbfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea
Author: Jakub Jelinek
Date: Wed May 7 17:25:42 2025 +0200
libcpp: Further fixes for incorrect line numbers in large files [PR120061]
The backport of the PR108900 fix to 14 branch broke building chromium
because static_assert (__LINE__ == expected_line_number, ""); now triggers
as the __LINE__ values are off by one.
This isn't the case on the trunk and 15 branch because we've switched
to 64-bit location_t and so one actually needs far longer header files
to trigger it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12
contain (large) testcases in patch form which show on the 14 branch
that the first one used to fail before the PR108900 backport and now
works correctly, while the second one attempts to match the chromium
behavior and it used to pass before the PR108900 backport and now it
FAILs.
The two testcases show rare problematic cases, because
do_include_common -> parse_include -> check_eol -> check_eol_1 ->
cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start
triggers there
/* Allocate the new line_map. However, if the current map only has a
single line we can sometimes just increase its column_bits
instead. */
if (line_delta < 0
|| last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
|| SOURCE_COLUMN (map, highest) >= (1U << (column_bits -
range_bits))
|| ( /* We can't reuse the map if the line offset is sufficiently
large to cause overflow when computing location_t values.
*/
(to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map))
>= (((uint64_t) 1)
<< (CHAR_BIT * sizeof (linenum_type) - column_bits)))
|| range_bits < map->m_range_bits)
map = linemap_check_ordinary
(const_cast
(linemap_add (set, LC_RENAME,
ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
ORDINARY_MAP_FILE_NAME (map),
to_line)));
and so creates a new ordinary map on the line right after the
(problematic) #include line.
Now, in the spot that r14-11679-g8a884140c2bcb7 patched,
pfile->line_table->highest_location in all 3 tests (also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13
) is before the decrement the start of the line after the #include line and
so
the decrement is really desirable in that case to put highest_location
somewhere on the line where the #include actually is.
But at the same time it is also undesirable, because if we do decrement it,
then linemap_add LC_ENTER called from _cpp_do_file_change will then
/* Generate a start_location above the current highest_location.
If possible, make the low range bits be zero. */
location_t start_location = set->highest_location + 1;
unsigned range_bits = 0;
if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS)
range_bits = set->default_range_bits;
start_location += (1 << range_bits) - 1;
start_location &= ~((1 << range_bits) - 1);
linemap_assert (!LINEMAPS_ORDINARY_USED (set)
|| (start_location
>= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP
(set;
and we can end up with the new LC_ENTER ordinary map having the same
start_location as the preceding LC_RENAME one.
Next thing that happens is computation of included_from:
if (reason == LC_ENTER)
{
if (set->depth == 0)
map->included_from = 0;
else
/* The location of the end of the just-closed map. */
map->included_from
= (((map[0].start_location - 1 - map[-1].start_location)
& ~((1 << map[-1].m_column_and_range_bits) - 1))
+ map[-1].start_location);
The normal case (e.g. with the testcase included at the start of this
comment) is
that map[-1] starts somewhere earlier and so map->included_from computation
above
nicely computes location_t which expands to the start of the #include line.
With r14-11679 reverted, for #c11 as well as #c12
map[0].start_location == map[-1].start_location above, and so it is
((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1)))
+ map[-1].start_location,
which happens to be start of the #include line.
For #c11 map[0].start_location is 0x53a0 and map[-1] has
m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 1
[Bug libstdc++/120170] [meta-bug] C++ std::locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120170 Bug 120170 depends on bug 64846, which changed state. Bug 64846 Summary: FAIL: 22_locale/conversions/string/2.cc execution test https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64846 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug libfortran/120158] Incorrect UNSIGNED maxval/maxloc etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120158 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |15.2 Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for 15.2 and trunk.
[Bug tree-optimization/120164] GCC fails vectorization when using conditional __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
--- Comment #6 from Richard Biener ---
(In reply to Tamar Christina from comment #5)
> The given example is an easy one to drop, but I wonder what would happen if
> the block had other instructions too
>
> void foo(double * restrict a, double * restrict b, int n){
> int i;
> for(i=0; i if (i % 1024 == 0)
> {
> __builtin_prefetch(&(b[i+1024]));
> a[i] = a[i] + b[i];
> }
> }
> }
>
> would block if-conversion if we don't drop it early enough.
I'd simply ignore prefetches during if-conversion analysis and drop them
during transform.
[Bug libfortran/120152] [15/16 Regression] libgfortran ABI problem starting with r15-4124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152 --- Comment #4 from GCC Commits --- The releases/gcc-15 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9d19251042f14fe84a5edc82b1a2b49ace6da6a1 commit r15-9639-g9d19251042f14fe84a5edc82b1a2b49ace6da6a1 Author: Jakub Jelinek Date: Wed May 7 18:46:51 2025 +0200 libfortran: Readd 15 accidentally removed libgfortran symbols [PR120152] The r15-4124-gc0002a675a92e76d change seems to have accidentally dropped 5 sourcefiles from i_maxloc1_c, which resulted in dropping 15 GFORTRAN_8 symbols on x86_64 and 6 on i686. The following patch adds it back, so that we export those symbols again, fixing the ABI problem. 2025-05-07 Jakub Jelinek PR libfortran/120152 * Makefile.am (i_maxloc1_c): Readd generated/maxloc1_4_i8.c, generated/maxloc1_8_i8.c, generated/maxloc1_16_i8.c, generated/maxloc1_4_i16.c, generated/maxloc1_8_i16.c. Move generated/maxloc1_16_i16.c entry earlier in the list. * Makefile.in: Regenerated. (cherry picked from commit 41c8e9b61defb6c616bf35ac9693a52f848afca3)
[Bug libfortran/120153] Missing UINTEGER symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120153 --- Comment #5 from GCC Commits --- The releases/gcc-15 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7317c72b028e057ddbe918ff6968e5e586a35850 commit r15-9642-g7317c72b028e057ddbe918ff6968e5e586a35850 Author: Jakub Jelinek Date: Thu May 8 10:43:22 2025 +0200 fortran: Add testcases for PR120152, PR120153 and PR120158 The following patch adds testcase coverage for the 3 recently fixed libgfortran PRs. On trunk before those fixes I'm getting with -m32 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) and with -m64 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120158.f90 -O0 execution test FAIL: gfortran.dg/pr120158.f90 -O1 execution test FAIL: gfortran.dg/pr120158.f90 -O2 execution test FAIL: gfortran.dg/pr120158.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/pr120158.f90 -O3 -g execution test FAIL: gfortran.dg/pr120158.f90 -Os execution test On latest trunk everything PASSes. 2025-05-08 Jakub Jelinek PR libfortran/120152 PR libfortran/120153 PR libfortran/120158 * gfortran.dg/pr120152_1.f90: New test. * gfortran.dg/pr120152_2.f90: New test. * gfortran.dg/pr120153.f90: New test. * gfortran.dg/pr120158.f90: New test. (cherry picked from commit 66f5f03853035cc917627e7d044bff8ccd9eca3f)
[Bug libfortran/120153] Missing UINTEGER symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120153 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |15.2 Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for 15.2 and trunk.
[Bug libstdc++/120170] [meta-bug] C++ std::locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120170 Bug 120170 depends on bug 112351, which changed state. Bug 112351 Summary: libstdc++ locale init doesn't handle __gthread_once failure https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/112351] libstdc++ locale init doesn't handle __gthread_once failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4 Resolution|--- |FIXED Known to work||13.3.1 Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Biener --- Fixed for GCC 13.4.
[Bug libstdc++/112351] libstdc++ locale init doesn't handle __gthread_once failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351 --- Comment #6 from Richard Biener --- (In reply to Jonathan Wakely from comment #5) > Richi, do you plan to backport this to gcc-13 and maybe gcc-12? Or should we > close it? I have been patching our gcc13 for this for quite some time so let me pick it for the 13 branch and then close the bug.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #19 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:1df8fffba30bf4022dda762bf61acf16ac704c67 commit r16-469-g1df8fffba30bf4022dda762bf61acf16ac704c67 Author: Rainer Orth Date: Thu May 8 09:39:26 2025 +0200 cobol: Allow for undefined NAME_MAX [PR119217] All users of symbols.h fail to compile on Solaris: /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h: At global scope: /vol/gcc/src/hg/master/local/gcc/cobol/symbols.h:1365:13: error: âNAME_MAXâ was not declared in this scope 1365 | char name[NAME_MAX]; | ^~~~ NAME_MAX being undefined is allowed by POSIX.1, actually: it's listed for under "Pathname Variable Values": A definition of one of the symbolic constants in the following list shall be omitted from the header on specific implementations where the corresponding value is equal to or greater than the stated minimum, but where the value can vary depending on the file to which it is applied. The actual value supported for a specific pathname shall be provided by the pathconf() function. As a hack, this patch provides a fallback definition to allow the build to finish. In fact it turned out that cbl_funtion_t.name isn't filename related and never set at all, so this patch serves as a mere stopgap fix to unbreak the build until a real solution can be figured out. Bootstrapped without regressions on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. 2025-04-08 Rainer Orth gcc/cobol: PR cobol/119217 * symbols.h (NAME_MAX): Define fallback.
[Bug tree-optimization/120164] GCC fails vectorization when using conditional __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164 --- Comment #3 from Tamar Christina --- (In reply to Tamar Christina from comment #2) > (In reply to Richard Biener from comment #1) > > As of today this is a job for the vectorizer if-conversion pass then. > > > > OTOH I believe we should work towards vectorizing the prefetches themselves > > rather than dropping them on the floor. We'll also happily keep the > > prefetches in the prologue/epilogue peeled copies which doesn't make much > > sense. > > That would definitely have to be a target hook. To clarify a bit more, As Pinksi mentioned in the other PR software prefetching often times interferes with HW prefetching. On older uarches they *could* have provided some benefits as HW prefetching wasn't as advanced. On newer uarches they are typically just ignored. But you do have fetch and decode overhead for essentially dead instructions. Additionally they have more limited addressing modes and can cause secondary effects like IVops picking a less efficient addressing mode for the loads to share the IV of the prefetch instructions. Aside from that certain SVE prefetch instructions are illegal when in SVE streaming mode. But we would still want to vectorize the loops. So we would need to have a target hook to allow us to drop them.
[Bug tree-optimization/120122] [14/15 Regression] wrong code due to VCE of bool being pulled out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120122 Andrew Pinski changed: What|Removed |Added Summary|[14/15/16 Regression] wrong |[14/15 Regression] wrong |code due to VCE of bool |code due to VCE of bool |being pulled out of loop|being pulled out of loop Target Milestone|14.3|16.0 Known to work||13.3.0, 16.0 Known to fail||14.1.0 --- Comment #3 from Andrew Pinski --- Fixed on the trunk so far.
[Bug libstdc++/120170] New: [meta-bug] C++ std::locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120170 Bug ID: 120170 Summary: [meta-bug] C++ std::locale Product: gcc Version: unknown Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Meta-bug to group issues related to std::locale
[Bug libstdc++/96322] 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96322 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Depends on||120171 Status|NEW |RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed for *-*-linux-gnu targets with r12-6589-g6795e6ae66096d but as that uses pt_PT it presmably fails on FreeBSD now. I created Bug 120171 for the custom locales, although that wouldn't work on non-glibc targets. I'll mark this one as fixed anyway. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120171 [Bug 120171] Consider using custom glibc locales for testing std::locale facets
[Bug libstdc++/5499] True name and named locales
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5499 --- Comment #4 from Jonathan Wakely --- numpunct::_M_initialize_numpunct in config/locale/gnu/numeric_members.cc says: // NB: There is no way to extract this info from posix locales. // _M_truename = __nl_langinfo_l(YESSTR, __cloc); _M_data->_M_truename = "true"; _M_data->_M_truename_size = 4; // _M_falsename = __nl_langinfo_l(NOSTR, __cloc); _M_data->_M_falsename = "false"; _M_data->_M_falsename_size = 5; I don't know where the C++ standard expected this information to come from.
[Bug libstdc++/65909] check_v3_target_namedlocale blows up on targets that don't support command-line arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65909 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug tree-optimization/120164] GCC fails vectorization when using conditional __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
--- Comment #7 from Tamar Christina ---
(In reply to Richard Biener from comment #6)
> (In reply to Tamar Christina from comment #5)
> > The given example is an easy one to drop, but I wonder what would happen if
> > the block had other instructions too
> >
> > void foo(double * restrict a, double * restrict b, int n){
> > int i;
> > for(i=0; i > if (i % 1024 == 0)
> > {
> > __builtin_prefetch(&(b[i+1024]));
> > a[i] = a[i] + b[i];
> > }
> > }
> > }
> >
> > would block if-conversion if we don't drop it early enough.
>
> I'd simply ignore prefetches during if-conversion analysis and drop them
> during transform.
Yeah that's what we did in r15-1211-gadcc815a01ae009d2768b6afb546e357bd37bbd2
though. So I guess this is just a missing case during analysis.
[Bug libstdc++/51018] Test failures on NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51018 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81266 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #3) > Author: redi > Date: Tue Nov 8 12:02:26 2011 > New Revision: 181156 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181156 > Log: > PR libstdc++/51018 > * testsuite/30_threads/thread/native_handle/typesizes.cc: Do not run > on netbsd. This was reverted by r8-1357-gd12366802a9ac3 but the test should pass on netbsd since r10-277-g1a1e427caae53f I don't know the current status of the testsuite on netbsd, somebody should update this bug or we should close it.
[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061 --- Comment #23 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8cbe033a8a88fe6437cc5d343ae0ddf8dd3455c8 commit r14-11749-g8cbe033a8a88fe6437cc5d343ae0ddf8dd3455c8 Author: Jakub Jelinek Date: Thu May 8 11:14:24 2025 +0200 libcpp: Further fixes for incorrect line numbers in large files [PR120061] The backport of the PR108900 fix to 14 branch broke building chromium because static_assert (__LINE__ == expected_line_number, ""); now triggers as the __LINE__ values are off by one. This isn't the case on the trunk and 15 branch because we've switched to 64-bit location_t and so one actually needs far longer header files to trigger it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12 contain (large) testcases in patch form which show on the 14 branch that the first one used to fail before the PR108900 backport and now works correctly, while the second one attempts to match the chromium behavior and it used to pass before the PR108900 backport and now it FAILs. The two testcases show rare problematic cases, because do_include_common -> parse_include -> check_eol -> check_eol_1 -> cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start triggers there /* Allocate the new line_map. However, if the current map only has a single line we can sometimes just increase its column_bits instead. */ if (line_delta < 0 || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits)) || ( /* We can't reuse the map if the line offset is sufficiently large to cause overflow when computing location_t values. */ (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) >= (((uint64_t) 1) << (CHAR_BIT * sizeof (linenum_type) - column_bits))) || range_bits < map->m_range_bits) map = linemap_check_ordinary (const_cast (linemap_add (set, LC_RENAME, ORDINARY_MAP_IN_SYSTEM_HEADER_P (map), ORDINARY_MAP_FILE_NAME (map), to_line))); and so creates a new ordinary map on the line right after the (problematic) #include line. Now, in the spot that r14-11679-g8a884140c2bcb7 patched, pfile->line_table->highest_location in all 3 tests (also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13 ) is before the decrement the start of the line after the #include line and so the decrement is really desirable in that case to put highest_location [jakub@tucnak gcc-15]$ git log -1 --format=%B r15-9638-gbfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea | cat libcpp: Further fixes for incorrect line numbers in large files [PR120061] The backport of the PR108900 fix to 14 branch broke building chromium because static_assert (__LINE__ == expected_line_number, ""); now triggers as the __LINE__ values are off by one. This isn't the case on the trunk and 15 branch because we've switched to 64-bit location_t and so one actually needs far longer header files to trigger it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12 contain (large) testcases in patch form which show on the 14 branch that the first one used to fail before the PR108900 backport and now works correctly, while the second one attempts to match the chromium behavior and it used to pass before the PR108900 backport and now it FAILs. The two testcases show rare problematic cases, because do_include_common -> parse_include -> check_eol -> check_eol_1 -> cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start triggers there /* Allocate the new line_map. However, if the current map only has a single line we can sometimes just increase its column_bits instead. */ if (line_delta < 0 || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits)) || ( /* We can't reuse the map if the line offset is sufficiently large to cause overflow when computing location_t values. */ (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) >= (((uint64_t) 1) << (CHAR_BIT * sizeof (linenum_type) - column_bits))) || range_bits < map->m_range_bits) map = linemap_check_ordinary (const_cast (linemap_add (set, LC_RENAME,
[Bug preprocessor/116047] C preprocessor bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116047 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8cbe033a8a88fe6437cc5d343ae0ddf8dd3455c8 commit r14-11749-g8cbe033a8a88fe6437cc5d343ae0ddf8dd3455c8 Author: Jakub Jelinek Date: Thu May 8 11:14:24 2025 +0200 libcpp: Further fixes for incorrect line numbers in large files [PR120061] The backport of the PR108900 fix to 14 branch broke building chromium because static_assert (__LINE__ == expected_line_number, ""); now triggers as the __LINE__ values are off by one. This isn't the case on the trunk and 15 branch because we've switched to 64-bit location_t and so one actually needs far longer header files to trigger it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12 contain (large) testcases in patch form which show on the 14 branch that the first one used to fail before the PR108900 backport and now works correctly, while the second one attempts to match the chromium behavior and it used to pass before the PR108900 backport and now it FAILs. The two testcases show rare problematic cases, because do_include_common -> parse_include -> check_eol -> check_eol_1 -> cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start triggers there /* Allocate the new line_map. However, if the current map only has a single line we can sometimes just increase its column_bits instead. */ if (line_delta < 0 || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits)) || ( /* We can't reuse the map if the line offset is sufficiently large to cause overflow when computing location_t values. */ (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) >= (((uint64_t) 1) << (CHAR_BIT * sizeof (linenum_type) - column_bits))) || range_bits < map->m_range_bits) map = linemap_check_ordinary (const_cast (linemap_add (set, LC_RENAME, ORDINARY_MAP_IN_SYSTEM_HEADER_P (map), ORDINARY_MAP_FILE_NAME (map), to_line))); and so creates a new ordinary map on the line right after the (problematic) #include line. Now, in the spot that r14-11679-g8a884140c2bcb7 patched, pfile->line_table->highest_location in all 3 tests (also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13 ) is before the decrement the start of the line after the #include line and so the decrement is really desirable in that case to put highest_location [jakub@tucnak gcc-15]$ git log -1 --format=%B r15-9638-gbfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea | cat libcpp: Further fixes for incorrect line numbers in large files [PR120061] The backport of the PR108900 fix to 14 branch broke building chromium because static_assert (__LINE__ == expected_line_number, ""); now triggers as the __LINE__ values are off by one. This isn't the case on the trunk and 15 branch because we've switched to 64-bit location_t and so one actually needs far longer header files to trigger it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12 contain (large) testcases in patch form which show on the 14 branch that the first one used to fail before the PR108900 backport and now works correctly, while the second one attempts to match the chromium behavior and it used to pass before the PR108900 backport and now it FAILs. The two testcases show rare problematic cases, because do_include_common -> parse_include -> check_eol -> check_eol_1 -> cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start triggers there /* Allocate the new line_map. However, if the current map only has a single line we can sometimes just increase its column_bits instead. */ if (line_delta < 0 || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits)) || ( /* We can't reuse the map if the line offset is sufficiently large to cause overflow when computing location_t values. */ (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) >= (((uint64_t) 1) << (CHAR_BIT * sizeof (linenum_type) - column_bits))) || range_bits < map->m_range_bits) map = linemap_check_ordinary (const_cast (linemap_add (set, LC_RENAME,
[Bug libstdc++/65909] check_v3_target_namedlocale blows up on targets that don't support command-line arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65909
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-05-08
Blocks||120170
Ever confirmed|0 |1
--- Comment #5 from Jonathan Wakely ---
(In reply to Martin Liška from comment #4)
> Can the bug be marked as resolved?
I think we could still do Sandra's better solution, e.g.
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -1026,6 +1026,7 @@ proc check_v3_target_namedlocale { args } {
# the required named locale.
set exe nlocale[pid].x
set src nlocale[pid].cc
+ set localename [lindex $args 0]
set f [open $src "w"]
puts $f "#include "
@@ -1045,14 +1046,9 @@ proc check_v3_target_namedlocale { args } {
puts $f "#endif"
puts $f "return result;"
puts $f "}"
- puts $f "int main (int argc, char** argv)"
+ puts $f "int main ()"
puts $f "{"
- puts $f " if (argc < 2)"
- puts $f " {"
- puts $f "printf(\"locale support test not supported\\n\");"
- puts $f "return 1;"
- puts $f " }"
- puts $f " const char *namedloc = transform_locale(*(argv + 1));"
+ puts $f " const char *namedloc = transform_locale(\"$localename\");"
puts $f " try"
puts $f " {"
puts $f "locale((const char*)namedloc);"
@@ -1076,7 +1072,7 @@ proc check_v3_target_namedlocale { args } {
return 0
}
- set result [${tool}_load "./$exe" "$args" ""]
+ set result [${tool}_load "./$exe" "" ""]
set status [lindex $result 0]
verbose "check_v3_target_namedlocale <$args>: status is <$status>" 2
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120170
[Bug 120170] [meta-bug] C++ std::locale
[Bug tree-optimization/120164] GCC fails vectorization when using conditional __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
--- Comment #9 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #8)
> On Thu, 8 May 2025, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
> >
> > --- Comment #7 from Tamar Christina ---
> > (In reply to Richard Biener from comment #6)
> > > (In reply to Tamar Christina from comment #5)
> > > > The given example is an easy one to drop, but I wonder what would
> > > > happen if
> > > > the block had other instructions too
> > > >
> > > > void foo(double * restrict a, double * restrict b, int n){
> > > > int i;
> > > > for(i=0; i > > > if (i % 1024 == 0)
> > > > {
> > > > __builtin_prefetch(&(b[i+1024]));
> > > > a[i] = a[i] + b[i];
> > > > }
> > > > }
> > > > }
> > > >
> > > > would block if-conversion if we don't drop it early enough.
> > >
> > > I'd simply ignore prefetches during if-conversion analysis and drop them
> > > during transform.
> >
> > Yeah that's what we did in
> > r15-1211-gadcc815a01ae009d2768b6afb546e357bd37bbd2
> > though. So I guess this is just a missing case during analysis.
>
> That didn't touch if-conversion at all.
Oh, indeed, my bad. I had confused the change for the masked SIMD calls with
that one in my head :)
[Bug libfortran/120152] [15/16 Regression] libgfortran ABI problem starting with r15-4124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120152 --- Comment #5 from GCC Commits --- The releases/gcc-15 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7317c72b028e057ddbe918ff6968e5e586a35850 commit r15-9642-g7317c72b028e057ddbe918ff6968e5e586a35850 Author: Jakub Jelinek Date: Thu May 8 10:43:22 2025 +0200 fortran: Add testcases for PR120152, PR120153 and PR120158 The following patch adds testcase coverage for the 3 recently fixed libgfortran PRs. On trunk before those fixes I'm getting with -m32 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) and with -m64 FAIL: gfortran.dg/pr120152_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_1.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120152_2.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O0 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O1 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O2 (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/pr120153.f90 -Os (test for excess errors) FAIL: gfortran.dg/pr120158.f90 -O0 execution test FAIL: gfortran.dg/pr120158.f90 -O1 execution test FAIL: gfortran.dg/pr120158.f90 -O2 execution test FAIL: gfortran.dg/pr120158.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/pr120158.f90 -O3 -g execution test FAIL: gfortran.dg/pr120158.f90 -Os execution test On latest trunk everything PASSes. 2025-05-08 Jakub Jelinek PR libfortran/120152 PR libfortran/120153 PR libfortran/120158 * gfortran.dg/pr120152_1.f90: New test. * gfortran.dg/pr120152_2.f90: New test. * gfortran.dg/pr120153.f90: New test. * gfortran.dg/pr120158.f90: New test. (cherry picked from commit 66f5f03853035cc917627e7d044bff8ccd9eca3f)
[Bug preprocessor/120061] [14 Regression] libqt6webengine fails static_assert (__LINE__ == 470, ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #24 from Jakub Jelinek --- Should be hopefully fixed now for 14.3, 15.2 and 16+.
[Bug libstdc++/112351] libstdc++ locale init doesn't handle __gthread_once failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351 --- Comment #5 from Jonathan Wakely --- Richi, do you plan to backport this to gcc-13 and maybe gcc-12? Or should we close it?
[Bug tree-optimization/117965] phiprop fails in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117965 --- Comment #14 from Richard Biener --- Andrew, are you still planning to address this? Otherwise I'll give it a stab.
[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=119977 --- Comment #23 from Sam James --- (In reply to Levi Zim from comment #11) > It comes with a similar pattern that .gnu.lto_.jmpfuncs.1 is the most > different section ignoring offset differences and lto opts. ... then maybe related to PR119977 (would need the lto-dump -list -objects diff to be sure, see what I did over there).
[Bug libstdc++/52389] Allocation/deallocation across DLL boundary in std::locale
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52389
Jonathan Wakely changed:
What|Removed |Added
Blocks||120170
Status|NEW |WAITING
--- Comment #9 from Jonathan Wakely ---
Fixed testcase:
#include
#include
#include
#include
#include
#include
void* operator new[](size_t size)
{
char* p = (char*)malloc(size + 16);
if(!p) throw std::bad_alloc();
*(uint32_t*)p = 0x12345678;
return p + 16;
}
void operator delete[](void* p) noexcept
{
char* p2 = (char*)p - 16;
if(*(uint32_t*)p2 != 0x12345678)
printf("block was not allocated with new[]\n");
free(p2);
}
void operator delete [](void* p, std::size_t) noexcept { operator delete(p); }
struct F : std::locale::facet
{
F() : facet(0) {}
static std::locale::id id;
};
std::locale::id F::id;
int main()
{
std::locale path_locale(std::locale(), new F);
return 0;
}
This seems to work fine on x86_64-w64-mingw32 when testing under Wine.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120170
[Bug 120170] [meta-bug] C++ std::locale
[Bug driver/120148] -fno-builtin suppresses -Wformat warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120148 --- Comment #3 from Sam James --- -> https://sourceforge.net/p/valgrind/mailman/message/59181622/
[Bug c++/120172] New: Preprocessor error leads to cascading failures in standard header instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120172 Bug ID: 120172 Summary: Preprocessor error leads to cascading failures in standard header instantiations Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mario.rodriguezb1 at um dot es Target Milestone: --- The compiler emits a massive cascade of errors and internal failures due to an incomplete or malformed #include directive. A missing file name after #include leads not only to a preprocessing error but triggers downstream parsing and template instantiation errors in and , potentially due to incomplete preprocessed input. ``` #include #include #include #include #include #include ``` Compiler return code 143, after showing an unexpected behaviour, to quicly reproduce: https://gcc.godbolt.org/z/hahjc117x
[Bug tree-optimization/120164] GCC fails vectorization when using conditional __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
--- Comment #8 from rguenther at suse dot de ---
On Thu, 8 May 2025, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164
>
> --- Comment #7 from Tamar Christina ---
> (In reply to Richard Biener from comment #6)
> > (In reply to Tamar Christina from comment #5)
> > > The given example is an easy one to drop, but I wonder what would happen
> > > if
> > > the block had other instructions too
> > >
> > > void foo(double * restrict a, double * restrict b, int n){
> > > int i;
> > > for(i=0; i > > if (i % 1024 == 0)
> > > {
> > > __builtin_prefetch(&(b[i+1024]));
> > > a[i] = a[i] + b[i];
> > > }
> > > }
> > > }
> > >
> > > would block if-conversion if we don't drop it early enough.
> >
> > I'd simply ignore prefetches during if-conversion analysis and drop them
> > during transform.
>
> Yeah that's what we did in r15-1211-gadcc815a01ae009d2768b6afb546e357bd37bbd2
> though. So I guess this is just a missing case during analysis.
That didn't touch if-conversion at all.
[Bug target/119327] [12/13/14 Regression] -Os breaks inlining: raw_hash_set.h: error: inlining failed in call to 'always_inline': target specific option mismatch since r12-5920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327
--- Comment #16 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:cdf689a1f12e887c22c9989e6728ffac981f71ce
commit r14-11750-gcdf689a1f12e887c22c9989e6728ffac981f71ce
Author: Jakub Jelinek
Date: Tue Apr 22 21:27:28 2025 +0200
rs6000: Ignore OPTION_MASK_SAVE_TOC_INDIRECT differences in inlining
decisions [PR119327]
The following testcase FAILs because the always_inline function can't
be inlined.
The rs6000 backend has similarly to other targets a hook which rejects
inlining which would bring in new ISAs which aren't there in the caller.
And this hook rejects this because of OPTION_MASK_SAVE_TOC_INDIRECT
differences.
This flag is set if explicitly requested or by default depending on
whether the current function looks hot (or at least not cold):
if ((rs6000_isa_flags_explicit & OPTION_MASK_SAVE_TOC_INDIRECT) == 0
&& flag_shrink_wrap_separate
&& optimize_function_for_speed_p (cfun))
rs6000_isa_flags |= OPTION_MASK_SAVE_TOC_INDIRECT;
The target nodes that are being compared here are actually the default
target node (which was created when cfun was NULL) vs. one that was
created for the always_inline function when it wasn't NULL, so one
doesn't have it, the other does.
In any case, this flag feels like a tuning decision rather than hard
ISA requirement and I see no problems why we couldn't inline
even explicit -msave-toc-indirect function into -mno-save-toc-indirect
or vice versa.
We already ignore OPTION_MASK_P{8,10}_FUSION which are also more
like tuning flags.
2025-04-22 Jakub Jelinek
PR target/119327
* config/rs6000/rs6000.cc (rs6000_can_inline_p): Ignore also
OPTION_MASK_SAVE_TOC_INDIRECT differences.
* g++.dg/opt/pr119327.C: New test.
(cherry picked from commit 4b62cf555b5446cb02fc471519cf1afa09e1a108)
[Bug target/97786] rs6000 isinf etc. are pretty horrible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97786 --- Comment #7 from Surya Kumari Jangala --- Hi Segher, Thanks for the pointers! We can optimize the code further and remove the branch completely. For P10: xststdcdp 0,1,48 setnbc 9,32 setbc 3,34 isel 3,9,3,2 blr For P9: xststdcdp 0,1,48 setb 9,0 mfcr 3,128 rlwinm 3,3,3,1 lr 4,1 isel 9,9,4,0 isel 3,9,3,2 blr
[Bug target/119327] [12/13 Regression] -Os breaks inlining: raw_hash_set.h: error: inlining failed in call to 'always_inline': target specific option mismatch since r12-5920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119327 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14 Regression] -Os |[12/13 Regression] -Os |breaks inlining:|breaks inlining: |raw_hash_set.h: error: |raw_hash_set.h: error: |inlining failed in call to |inlining failed in call to |'always_inline': target |'always_inline': target |specific option mismatch|specific option mismatch |since r12-5920 |since r12-5920 --- Comment #17 from Jakub Jelinek --- Fixed for 14.3 as well.
[Bug fortran/120173] New: [OpenACC][gcn-offload] wrong 'firstprivate' with 'acc parallel async' [modified libgomp.oacc-fortran/lib-13.f90]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120173 Bug ID: 120173 Summary: [OpenACC][gcn-offload] wrong 'firstprivate' with 'acc parallel async' [modified libgomp.oacc-fortran/lib-13.f90] Product: gcc Version: 16.0 Status: UNCONFIRMED Keywords: openacc, wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: ams at gcc dot gnu.org, sandra at gcc dot gnu.org, tschwinge at gcc dot gnu.org Target Milestone: --- Created attachment 61366 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61366&action=edit Full test case (i.e. patch applied to libgomp.oacc-fortran/lib-13.f90) The following is a modified version of libgomp.oacc-fortran/lib-13.f90 which looks as follows (current version, might have changed by the time you look at it): https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgomp/testsuite/libgomp.oacc-fortran/lib-13.f90 I decided to check the value of the 'k' variable: k(:) = 7 ... ! print *, k if (any (k /= [(7 + N, i = 1, nprocs)])) stop 4 And that fails with GCN but not with Nvptx. Namely: 107 107 ! nvptx vs. 7 1005444 ! gcn 7 207 ! gcn with '!$acc atomic update' * * * In particular, I do not understand why k(j==1) is not increment at all while k(j==2) is too much incremented. * * * Changes to that program - in an attempt to fix the issue: (A) Use atomic update: !$acc atomic update k(j) = k(j) + 1 → Yields consistent results → 7 207 (B) Use explicit clauses: !$acc parallel firstprivate(j) private(i) async (j) → no effect, unsurprisingly as 'firstprivate' is the default. BTW: If I look at the dump, I see: j.16 = j; .omp_data_arr.13.j = &j.16; #pragma omp target oacc_parallel private(i) firstprivate(j) D.4787 = .omp_data_i->j; j = *D.4787; [I wonder whether the address of 'j.16' gets too quickly reused?] * * * Otherwise: !$acc end data should probably be moved after 'call acc_wait' to avoid races, even though I failed to observe any issues for those. See OG14 commit https://gcc.gnu.org/g:8998cc60c1cbbdef603090eab63e5835bf071d41 8998cc60c1c Fix libgomp.oacc-fortran/lib-13.f90 async bug * * * The changed testcase (added atomic update, value check for 'k', moved 'end data'): --- a/libgomp/testsuite/libgomp.oacc-fortran/lib-13.f90 +++ b/libgomp/testsuite/libgomp.oacc-fortran/lib-13.f90 @@ -11,3 +11,3 @@ program main - k(:) = 0 + k(:) = 7 @@ -17,2 +17,3 @@ program main do i = 1, N + !$acc atomic update k(j) = k(j) + 1 @@ -21,7 +22,6 @@ program main end do - !$acc end data call acc_wait_all_async (nprocs + 1) - call acc_wait (nprocs + 1) + !$acc end data @@ -30,2 +30,3 @@ program main if (acc_async_test (nprocs + 1) .neqv. .TRUE.) stop 3 + if (any (k /= [(7 + N, i = 1, nprocs)])) stop 4
[Bug libstdc++/112351] libstdc++ locale init doesn't handle __gthread_once failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112351 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:351ac78e48fa897080cf8bbb71618df9c428ad30 commit r13-9643-g351ac78e48fa897080cf8bbb71618df9c428ad30 Author: Richard Biener Date: Mon Nov 6 11:31:40 2023 +0100 libstdc++/112351 - deal with __gthread_once failure during locale init The following makes the C++98 locale init path follow the way the C++11 performs initialization. This way we deal with pthread_once failing, falling back to non-threadsafe initialization which, given we initialize from the library, should be serialized by the dynamic loader already. PR libstdc++/112351 libstdc++-v3/ * src/c++98/locale.cc (locale::facet::_S_initialize_once): Check whether _S_c_locale is already initialized. (locale::facet::_S_get_c_locale): Always perform non-threadsafe init when threadsafe init failed. (cherry picked from commit 7562f089a190953b8ef615b90b7b0520e812a930)
[Bug tree-optimization/116352] [15 regression] ICE when building opencv-4.9.0 (error: definition in block 208 does not dominate use in block 188) since r15-2820-gab18785840d7b8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352 --- Comment #22 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1e8bd720b1a618a39e2a41eec05e935c32d295f3 commit r16-473-g1e8bd720b1a618a39e2a41eec05e935c32d295f3 Author: Richard Biener Date: Thu May 8 10:56:16 2025 +0200 tree-optimization/116352 - amend previous fix The previous fix restricted external vector builds to defs from the same basic-block. That turns out too restrictive so we have to mitigate the original issue in a different way which is restricting it to the original case where all defs are in the same basic-block. PR tree-optimization/116352 * tree-vect-slp.cc (vect_build_slp_tree_2): When compressing operands from a two-operator node make sure the resulting operation does not mix defs from different basic-blocks.
[Bug c++/120174] New: ICE (Segfault) in GCC when passing array of class to generic lambda taking decltype of lambda with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120174
Bug ID: 120174
Summary: ICE (Segfault) in GCC when passing array of class to
generic lambda taking decltype of lambda with
-std=c++20
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mario.rodriguezb1 at um dot es
Target Milestone: ---
Passing an array of a user-defined class to a generic lambda that captures by
value and takes a decltype of a lambda as its argument causes a segmentation
fault in GCC using -std=c++20.
```
#include
class C{
};
int main(){
C fn[]{};
auto c = [=]
(decltype([](){})){};
c(fn)();
}
```
To quickly reproduce:
https://gcc.godbolt.org/z/GE7KExEGf
[Bug c++/120125] [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor since r15-521-g6ad7ca1bb90573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125 --- Comment #5 from Jakub Jelinek --- The WIP patch looks reasonable to me. On which testcase you see something weird? On the #c1 I don't see anything wrong.
[Bug c/120175] New: Performance: compiling a program with using a library slows other code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120175 Bug ID: 120175 Summary: Performance: compiling a program with using a library slows other code. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: newbie-02 at gmx dot de Target Milestone: --- hello @ all, again stumbled on an exotic issue, and again can't tell if gcc or glibc or "me bad" which is always an option. If wrong asked here please move or point where to put. I'm working on a project about datatype performance, where the idea came up to put simple functions in a library for easy portability. Issue: once anything is compiled using any flavor of library the "normal" direct calls to functions slow down by factor 5. That renders performance comparison useless. E.g. 1000 times "x1d = NAN" takes about 1000 "readtsc()" ticks on my machine if the program doesn't use libraries. Putting the same call in a library it works the same and needs about 5000 ticks for 1000 iterations, I see that as overhead which might be a topic for another day. However once any library compilation is active also the normal direct calls of that statement in the main section slow down to ~5000 ticks ... unexpected and unwanted. I did build some testcases, you find them at https://gitlab.gnome.org/newbie-02/dec_perf/-/tree/main/performance_breakdown_reg_libraries and https://codereview.stackexchange.com/questions/296057/direct-calls-of-simple-functions-e-g-set-a-variable-to-nan-or-inf-become-slow?noredirect=1#comment591096_296057 Since I couldn't find any useful information on the web, even anonchatGPT is at a loss, and CR/SE and SO are more or less bogged down in wording issues (which also means that no one could put their finger on the problem right away), I take the liberty of asking a supplementary question here, although I normally don't like cross site posting. Spontaneous idea while writing this ... is there any optimization active which looks for similar commands and merges them together? And in this case doesn't prefer to use the direct call but the library function with it's overhead? That's just newbie guessing, forget if silly and another explanation is around. Environment: linux ( recent debian ), gcc (Debian 14.2.0-16) 14.2.0 TIA for any help
[Bug c++/118388] Segmentation fault in invalid friend declaration with default argument with -fpermissive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118388 --- Comment #4 from Simon Martin --- We ended up doing a different fix for #118319 and the case I mentionned in the initial comment does not ICE, but the underlying problem still exists. I ran the c++ testsuite with the use of -fpermissive for all tests, and got ICEs due to a `gcc_assert ($SOME_EXPRESSION_WITH_SEEN_ERROR);` for the following tests - g++.dg/cpp0x/constexpr-ice20.C - g++.dg/cpp0x/inh-ctor37.C - g++.dg/cpp0x/lambda/lambda-ice21.C - g++.dg/cpp0x/lambda/lambda-ice5.C - g++.dg/cpp0x/noexcept28.C - g++.dg/cpp0x/pr31437.C - g++.dg/cpp0x/pr34056.C - g++.dg/cpp2a/lambda-uneval25.C - g++.dg/ext/unary_trait_incomplete.C
[Bug c/120175] Performance: compiling a program with using a library slows other code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120175 newbie-02 changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from newbie-02 --- Sorry, withdrawn, writing here helped ( was necessary? ) to clear my head and narrow down the problem between working and not working. I had copied the library compile command from a manual, and didn't think to check the optimization level, it was missing an -O2, so the direct commands are fast again.
[Bug tree-optimization/120043] [15 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
Known to fail||15.1.0
Summary|[15/16 Regression] wrong|[15 Regression] wrong code
|code at -O{s,2,3} with |at -O{s,2,3} with
|-fallow-store-data-races on |-fallow-store-data-races on
|x86_64-linux-gnu since |x86_64-linux-gnu since
|r15-1391-g4b75ed33fa5fd6|r15-1391-g4b75ed33fa5fd6
Known to work||16.0
Priority|P3 |P2
[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 --- Comment #5 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:93586e5d51188bf71f4f8fae4ee94ff631740f24 commit r16-472-g93586e5d51188bf71f4f8fae4ee94ff631740f24 Author: Richard Biener Date: Thu May 8 10:05:42 2025 +0200 tree-optimization/120043 - bogus conditional store elimination The following fixes conditional store elimination to properly check for conditional stores to readonly memory which we can obviously not store to unconditionally. The tree_could_trap_p predicate used is only considering rvalues and the chosen approach mimics that of loop store motion. PR tree-optimization/120043 * tree-ssa-phiopt.cc (cond_store_replacement): Check whether the store is to readonly memory. * gcc.dg/torture/pr120043.c: New testcase.
[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086 --- Comment #15 from Jørgen Kvalsvik --- I don't know why it's only defined for rtems, but I would imagine it's either an oversight, or that it's the only target with libatomic support without hardware atomics. Is there a libatomic for hppa, or hardware atomics? Does testsuite/g++.dg/gcov/gcov-threads-1.C pass? tree-profile.cc checks for HAVE_sync_compare_and_swapdi, HAVE_atomic_compare_and_swapdi. Are these defined for hppa? > There's something wierd happening with gcov-pr86536.c. It doesn't always fail. That test seems unrelated the %zu at least.
[Bug preprocessor/108900] [libcpp] cpp gives wrong line number information with a file huge number of lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900 --- Comment #21 from GCC Commits --- The releases/gcc-14 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8cbe033a8a88fe6437cc5d343ae0ddf8dd3455c8 commit r14-11749-g8cbe033a8a88fe6437cc5d343ae0ddf8dd3455c8 Author: Jakub Jelinek Date: Thu May 8 11:14:24 2025 +0200 libcpp: Further fixes for incorrect line numbers in large files [PR120061] The backport of the PR108900 fix to 14 branch broke building chromium because static_assert (__LINE__ == expected_line_number, ""); now triggers as the __LINE__ values are off by one. This isn't the case on the trunk and 15 branch because we've switched to 64-bit location_t and so one actually needs far longer header files to trigger it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12 contain (large) testcases in patch form which show on the 14 branch that the first one used to fail before the PR108900 backport and now works correctly, while the second one attempts to match the chromium behavior and it used to pass before the PR108900 backport and now it FAILs. The two testcases show rare problematic cases, because do_include_common -> parse_include -> check_eol -> check_eol_1 -> cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start triggers there /* Allocate the new line_map. However, if the current map only has a single line we can sometimes just increase its column_bits instead. */ if (line_delta < 0 || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits)) || ( /* We can't reuse the map if the line offset is sufficiently large to cause overflow when computing location_t values. */ (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) >= (((uint64_t) 1) << (CHAR_BIT * sizeof (linenum_type) - column_bits))) || range_bits < map->m_range_bits) map = linemap_check_ordinary (const_cast (linemap_add (set, LC_RENAME, ORDINARY_MAP_IN_SYSTEM_HEADER_P (map), ORDINARY_MAP_FILE_NAME (map), to_line))); and so creates a new ordinary map on the line right after the (problematic) #include line. Now, in the spot that r14-11679-g8a884140c2bcb7 patched, pfile->line_table->highest_location in all 3 tests (also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13 ) is before the decrement the start of the line after the #include line and so the decrement is really desirable in that case to put highest_location [jakub@tucnak gcc-15]$ git log -1 --format=%B r15-9638-gbfcb5da69a41f7a5e41faab39b763d9d7c8bd2ea | cat libcpp: Further fixes for incorrect line numbers in large files [PR120061] The backport of the PR108900 fix to 14 branch broke building chromium because static_assert (__LINE__ == expected_line_number, ""); now triggers as the __LINE__ values are off by one. This isn't the case on the trunk and 15 branch because we've switched to 64-bit location_t and so one actually needs far longer header files to trigger it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12 contain (large) testcases in patch form which show on the 14 branch that the first one used to fail before the PR108900 backport and now works correctly, while the second one attempts to match the chromium behavior and it used to pass before the PR108900 backport and now it FAILs. The two testcases show rare problematic cases, because do_include_common -> parse_include -> check_eol -> check_eol_1 -> cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start triggers there /* Allocate the new line_map. However, if the current map only has a single line we can sometimes just increase its column_bits instead. */ if (line_delta < 0 || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits)) || ( /* We can't reuse the map if the line offset is sufficiently large to cause overflow when computing location_t values. */ (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) >= (((uint64_t) 1) << (CHAR_BIT * sizeof (linenum_type) - column_bits))) || range_bits < map->m_range_bits) map = linemap_check_ordinary (const_cast (linemap_add (set, LC_RENAME,
[Bug target/119610] [12/13/14 regression] aarch64: Wrong unwind info with -fstack-clash-protection -fstack-protector-strong since r14-3900-g3e4afea3b192c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119610 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:a9d390ab17d9395ce20e899ef0180052ed79d332 commit r14-11751-ga9d390ab17d9395ce20e899ef0180052ed79d332 Author: Richard Sandiford Date: Thu May 8 12:06:41 2025 +0100 aarch64: Fix CFA offsets in non-initial stack probes [PR119610] PR119610 is about incorrect CFI output for a stack probe when that probe is not the initial allocation. The main aarch64 stack probe function, aarch64_allocate_and_probe_stack_space, implicitly assumed that the incoming stack pointer pointed to the top of the frame, and thus held the CFA. aarch64_save_callee_saves and aarch64_restore_callee_saves use a parameter called bytes_below_sp to track how far the stack pointer is above the base of the static frame. This patch does the same thing for aarch64_allocate_and_probe_stack_space. Also, I noticed that the SVE path was attaching the first CFA note to the wrong instruction: it was attaching the note to the calculation of the stack size, rather than to the r11<-sp copy. gcc/ PR target/119610 * config/aarch64/aarch64.cc (aarch64_allocate_and_probe_stack_space): Add a bytes_below_sp parameter and use it to calculate the CFA offsets. Attach the first SVE CFA note to the move into the associated temporary register. (aarch64_allocate_and_probe_stack_space): Update calls accordingly. Start out with bytes_per_sp set to the frame size and decrement it after each allocation. gcc/testsuite/ PR target/119610 * g++.dg/torture/pr119610.C: New test. * g++.target/aarch64/sve/pr119610-sve.C: Likewise. (cherry picked from commit fa61afef18a8566d1907a5ae0e7754e1eac207d9)
[Bug target/120169] [m68k] internal compiler error: in maybe_record_trace_start, at dwarf2cfi.cc:2591 with LRA enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120169 --- Comment #2 from Andreas Schwab --- Inconsistent CFI state! SHOULD have: .cfi_def_cfa 15, 16 .cfi_offset 2, -16 .cfi_offset 10, -12 .cfi_offset 11, -8 .cfi_offset 24, -4 DO have: .cfi_def_cfa 15, 20 .cfi_offset 2, -16 .cfi_offset 10, -12 .cfi_offset 11, -8 .cfi_offset 24, -4
[Bug tree-optimization/120176] New: Missed reduction chain vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120176
Bug ID: 120176
Summary: Missed reduction chain vectorization
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
We fail to handle the 2nd loop of the PR98138 testcase as reduction-chain:
for( int i = 0; i < 4; i++ )
{
HADAMARD4( a0, a1, a2, a3, tmp[0][i], tmp[1][i], tmp[2][i], tmp[3][i]
);
sum += abs2(a0) + abs2(a1) + abs2(a2) + abs2(a3);
}
because after reassoc we have inside of the loop
sum.0_77 = (unsigned int) sum_152;
_157 = _153 + sum.0_77;
_88 = _157 + _132;
_78 = _88 + _127;
sum_108 = (int) _78;
and on the exit
_143 = sum_108 & 65535;
_79 = (unsigned int) _143;
sum.1_80 = (unsigned int) sum_108;
which would be fine, but then forwprop applies folding of the int <-> unsigned
int roundtrip and we end up with
# sum_152 = PHI
sum.0_77 = (unsigned int) sum_152;
_157 = sum.0_77 + _153;
_88 = _132 + _157;
_78 = _88 + _127;
sum_108 = (int) _78;
_75 = _78 & 65535;
_81 = _78 >> 16;
which then fails reduction chain detection in the vectorizer as the
reduction path ends with sum_108 but the live variable on the exit
is _78 and so we fail the single-use check on _78:
if ((op.code != code && !leading_conversion)
/* We can only handle the final value in epilogue
generation for reduction chains. */
|| (i != 1 && !has_single_use (gimple_get_lhs (stmt
is_slp_reduc = false;
the fix is to either avoid the folding with some extensive heuristics
or relax the reduction chain detection, allowing either the trailing
conversion or the last computation result to be live.
Not handling this case as a reduction chain blocks us from using larger
than V4SI vectors for the 2nd loop.
[Bug c++/120125] [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor since r15-521-g6ad7ca1bb90573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125
--- Comment #6 from Nathaniel Shead ---
Created attachment 61367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61367&action=edit
clone-4_b.s
This is the testcase I've been using:
$ cat ~/t/modules/clone-4_a.C
// PR c++/120125
// { dg-additional-options "-fmodules -fdeclone-ctor-dtor" }
// { dg-module-cmi M }
export module M;
void foo();
export extern "C++" template struct __shared_ptr {
__shared_ptr() { foo(); }
};
template class __shared_ptr;
$ cat ~/t/modules/clone-4_b.C
// PR c++/120125
// { dg-additional-options "-fmodules -fdeclone-ctor-dtor -fno-module-lazy" }
import M;
int main() {
__shared_ptr s;
}
$ ./xg++ -B. -fmodules -std=c++23 -fdeclone-ctor-dtor -S ~/t/modules/clone-4_*
With modules, typically an explicit instantiation emitted in a named module
should be considered as an extern template in importers; there's no need to
emit it there because we know a definition already exists.
The assembly for 'clone-4_a.s' that's generated seems reasonable, and matches
what I would expect in a non-modules context; we emit one declaration
_ZN12__shared_ptrIiEC2Ev:
pushq %rbp
movq%rsp, %rbp
subq$16, %rsp
movq%rdi, -8(%rbp)
call_ZW1M3foov
nop
leave
ret
However, 'clone-4_b.s' (attached) doesn't look right. It emits a declaration
for _ZN12__shared_ptrIiEC2Ev, and that declaration doesn't match:
_ZN12__shared_ptrIiEC2Ev:
pushq %rbp
movq%rsp, %rbp
subq$16, %rsp
movq%rdi, -8(%rbp)
movq-8(%rbp), %rax
movq%rax, %rdi
call_ZN12__shared_ptrIiEC4Ev
nop
leave
ret
It seems like the '-fdeclone-ctor-dtor' is being ignored here somehow, since we
also generate all the other constructor clones, I assume because of an
interaction with how the modules streaming rebuilds the clones on stream-in.
This should be fine for 14 (where we didn't handle ABI for explicit
instantiations properly anyway), since whichever definition of
_ZN12__shared_ptrIiEC2Ev is chosen by the linker should still behave the same.
But for 15/16 I would like to avoid this, though I probably won't be able to
look properly at this until next week.
[Bug tree-optimization/120089] [15/16 regression] GCC miscompiles VK-GL-CTS (on aarch64) with -O3 since r15-7533-g589d79e6268b05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120089 --- Comment #27 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9def392a1b63a198d15d972f73b4afc888389d7c commit r16-460-g9def392a1b63a198d15d972f73b4afc888389d7c Author: Richard Biener Date: Mon May 5 14:29:34 2025 +0200 tree-optimization/120089 - force all PHIs live for early-break vect The following makes sure to even mark unsupported PHIs live when doing early-break vectorization since otherwise we fail to validate we can vectorize those and generate wrong code based on the scalar PHIs which would only work with a vectorization factor of one. PR tree-optimization/120089 * tree-vect-stmts.cc (vect_stmt_relevant_p): Mark all PHIs live when not already so and doing early-break vectorization. (vect_mark_stmts_to_be_vectorized): Skip virtual PHIs. * tree-vect-slp.cc (vect_analyze_slp): Robustify handling of early-break forced IVs. * gcc.dg/vect/vect-early-break_134-pr120089.c: New testcase.
[Bug tree-optimization/120164] GCC fails vectorization when using conditional __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-08 --- Comment #1 from Richard Biener --- As of today this is a job for the vectorizer if-conversion pass then. OTOH I believe we should work towards vectorizing the prefetches themselves rather than dropping them on the floor. We'll also happily keep the prefetches in the prologue/epilogue peeled copies which doesn't make much sense.
[Bug preprocessor/119753] gcc -E is not POSIX-compliant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119753 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- IMNSHO it is POSIX that should be fixed. Clearly they've added a requirement there that doesn't match what the compilers actually do (GCC, clang, ICC (both before and after LLVM), nvc++ all do the same). EDG/MSVC on godbolt seems to use #line directives instead of # .
[Bug ada/120110] Instantiation error record aggregate must use (), not []
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120110 --- Comment #3 from Pascal Pignard --- Thanks Eric for your quick answer. Agreed, especially since GNAT 15 is available now with Alire pre-release: https://forum.ada-lang.io/t/gnat-fsf-15-available-in-alire-pre-release/2038
[Bug tree-optimization/116938] move_stmt in phiopt should use rewrite_to_defined_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116938 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:bac74b0d0141a440275797a059c2b43978cd9e1c commit r16-466-gbac74b0d0141a440275797a059c2b43978cd9e1c Author: Andrew Pinski Date: Thu Oct 17 05:30:10 2024 + phiopt: Use rewrite_to_defined_overflow in move_stmt [PR116938] As mentioned previously the rewrite in move_stmt should be using gimple_needing_rewrite_undefined/rewrite_to_defined_unconditional instead of just rewriting the VCE. This moves move_stmt over to those APIs. A few testcases needed to be updated due to ABS_EXPR rewrite that happens. Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/116938 gcc/ChangeLog: * tree-ssa-phiopt.cc (move_stmt): Use rewrite_to_defined_overflow isntead of manually doing the rewrite of the VCE. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/phi-opt-40.c: Update to expect ABSU_EXPR. * gcc.dg/tree-ssa/phi-opt-41.c: Likewise. Signed-off-by: Andrew Pinski
[Bug tree-optimization/120164] GCC fails vectorization when using conditional __builtin_prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120164 --- Comment #2 from Tamar Christina --- (In reply to Richard Biener from comment #1) > As of today this is a job for the vectorizer if-conversion pass then. > > OTOH I believe we should work towards vectorizing the prefetches themselves > rather than dropping them on the floor. We'll also happily keep the > prefetches in the prologue/epilogue peeled copies which doesn't make much > sense. That would definitely have to be a target hook.
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #17 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:aacaa3b13bca508cb6cb803d11cb942b2de8c0db commit r16-463-gaacaa3b13bca508cb6cb803d11cb942b2de8c0db Author: Rainer Orth Date: Thu May 8 09:21:45 2025 +0200 cobol: Don't require GLOB_BRACE etc. [PR119217] cdf-copy.cc doesn't compile on Solaris: /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc: In member function âint copybook_elem_t::open_file(const char*, bool)â: /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc:317:34: error: âGLOB_BRACEâ was not declared in this scope; did you mean âGLOB_ERRâ? 317 | static int flags = GLOB_MARK | GLOB_BRACE | GLOB_TILDE; | ^~ | GLOB_ERR /vol/gcc/src/hg/master/local/gcc/cobol/cdf-copy.cc:317:47: error: âGLOB_TILDEâ was not declared in this scope 317 | static int flags = GLOB_MARK | GLOB_BRACE | GLOB_TILDE; | ^~ GLOB_BRACE and GLOB_TILDE are BSD extensions not in POSIX.1, thus missing on Solaris probably due to its System V heritage. This patch introduces fallback definitions to avoid this. Bootstrapped without regressions on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. 2025-04-08 Rainer Orth gcc/cobol: PR cobol/119217 * cdf-copy.cc (GLOB_BRACE): Define fallback. (GLOB_TILDE): Likewise.
[Bug ipa/120146] [15/16 Regression] ICE: SIGSEGV in all_refs_explicit_p (cgraph.h:3201) with -O -fopenacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120146 --- Comment #3 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b38e3a7196d25bc8bcb1fe55da7663745cea9470 commit r16-464-gb38e3a7196d25bc8bcb1fe55da7663745cea9470 Author: Richard Biener Date: Wed May 7 10:20:55 2025 +0200 ipa/120146 - deal with vanished varpool nodes in IPA PTA I don't understand why they vanish when still refered to, but lets deal with that in a conservative way. PR ipa/120146 * tree-ssa-structalias.cc (create_variable_info_for): If the symtab cannot tell us whether all refs to a variable are explicit assume they are not. * g++.dg/ipa/pr120146.C: New testcase.
[Bug tree-optimization/116939] rewrite_to_defined_overflow/gimple_with_undefined_signed_overflow should also rewrite VCEs (from/to integral types) into casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116939 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:f2bb7ffe84840d8f4ba6c0e5acdbbad8ca9d3603 commit r16-465-gf2bb7ffe84840d8f4ba6c0e5acdbbad8ca9d3603 Author: Andrew Pinski Date: Thu Oct 17 05:18:36 2024 + Rewrite VCEs of integral types [PR116939] Like the patch to phiopt (r15-4033-g1f619fe25925a5f7), this adds rewriting of VCE to gimple_with_undefined_signed_overflow/rewrite_to_defined_overflow. In the case of moving VCE of a bool from being conditional to unconditional, it needs to be rewritten to not to use VCE but a normal cast. pr120122-1.c is an example of where LIM needs this rewriting. The precision of the outer type needs to be less then the inner one. This also renames gimple_with_undefined_signed_overflow to gimple_needing_rewrite_undefined and rewrite_to_defined_overflow to rewrite_to_defined_unconditional as they will be doing more than just handling signed overflow. Changes since v1: * v2: rename the functions. * v3: Add check for precision to be smaller. Bootstrappd and tested on x86_64-linux-gnu. PR tree-optimization/120122 PR tree-optimization/116939 gcc/ChangeLog: * gimple-fold.h (gimple_with_undefined_signed_overflow): Rename to .. (rewrite_to_defined_overflow): This. (gimple_needing_rewrite_undefined): Rename to ... (rewrite_to_defined_unconditional): this. * gimple-fold.cc (gimple_with_undefined_signed_overflow): Rename to ... (gimple_needing_rewrite_undefined): This. Return true for VCE with integral types of smaller precision. (rewrite_to_defined_overflow): Rename to ... (rewrite_to_defined_unconditional): This. Handle VCE rewriting to a cast. * tree-if-conv.cc: s/gimple_with_undefined_signed_overflow/gimple_needing_rewrite_undefined/ s/rewrite_to_defined_overflow/rewrite_to_defined_unconditional. * tree-scalar-evolution.cc: Likewise * tree-ssa-ifcombine.cc: Likewise. * tree-ssa-loop-im.cc: Likewise. * tree-ssa-loop-split.cc: Likewise. * tree-ssa-reassoc.cc: Likewise. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr120122-1.c: New test. Signed-off-by: Andrew Pinski
[Bug tree-optimization/120122] [14/15/16 Regression] wrong code due to VCE of bool being pulled out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120122 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:f2bb7ffe84840d8f4ba6c0e5acdbbad8ca9d3603 commit r16-465-gf2bb7ffe84840d8f4ba6c0e5acdbbad8ca9d3603 Author: Andrew Pinski Date: Thu Oct 17 05:18:36 2024 + Rewrite VCEs of integral types [PR116939] Like the patch to phiopt (r15-4033-g1f619fe25925a5f7), this adds rewriting of VCE to gimple_with_undefined_signed_overflow/rewrite_to_defined_overflow. In the case of moving VCE of a bool from being conditional to unconditional, it needs to be rewritten to not to use VCE but a normal cast. pr120122-1.c is an example of where LIM needs this rewriting. The precision of the outer type needs to be less then the inner one. This also renames gimple_with_undefined_signed_overflow to gimple_needing_rewrite_undefined and rewrite_to_defined_overflow to rewrite_to_defined_unconditional as they will be doing more than just handling signed overflow. Changes since v1: * v2: rename the functions. * v3: Add check for precision to be smaller. Bootstrappd and tested on x86_64-linux-gnu. PR tree-optimization/120122 PR tree-optimization/116939 gcc/ChangeLog: * gimple-fold.h (gimple_with_undefined_signed_overflow): Rename to .. (rewrite_to_defined_overflow): This. (gimple_needing_rewrite_undefined): Rename to ... (rewrite_to_defined_unconditional): this. * gimple-fold.cc (gimple_with_undefined_signed_overflow): Rename to ... (gimple_needing_rewrite_undefined): This. Return true for VCE with integral types of smaller precision. (rewrite_to_defined_overflow): Rename to ... (rewrite_to_defined_unconditional): This. Handle VCE rewriting to a cast. * tree-if-conv.cc: s/gimple_with_undefined_signed_overflow/gimple_needing_rewrite_undefined/ s/rewrite_to_defined_overflow/rewrite_to_defined_unconditional. * tree-scalar-evolution.cc: Likewise * tree-ssa-ifcombine.cc: Likewise. * tree-ssa-loop-im.cc: Likewise. * tree-ssa-loop-split.cc: Likewise. * tree-ssa-reassoc.cc: Likewise. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr120122-1.c: New test. Signed-off-by: Andrew Pinski
[Bug tree-optimization/116938] move_stmt in phiopt should use rewrite_to_defined_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116938 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |16.0 --- Comment #6 from Andrew Pinski --- Fixed.
[Bug tree-optimization/116938] move_stmt in phiopt should use rewrite_to_defined_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116938 Bug 116938 depends on bug 116939, which changed state. Bug 116939 Summary: rewrite_to_defined_overflow/gimple_with_undefined_signed_overflow should also rewrite VCEs (from/to integral types) into casts https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116939 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217
--- Comment #18 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:12d6fa2a21140166181ae3be7711d60e62c569d7
commit r16-467-g12d6fa2a21140166181ae3be7711d60e62c569d7
Author: Rainer Orth
Date: Thu May 8 09:29:56 2025 +0200
cobol: Initialize regmatch_t portably [PR119217]
The dts.h initialization of regmatch_t currently breaks Solaris
compilation:
In file included from /vol/gcc/src/hg/master/local/gcc/cobol/lexio.h:208,
from /vol/gcc/src/hg/master/local/gcc/cobol/lexio.cc:36:
/vol/gcc/src/hg/master/local/gcc/cobol/dts.h: In constructor
âdts::csub_match::csub_match(const char*)â:
/vol/gcc/src/hg/master/local/gcc/cobol/dts.h:36:35: error: invalid
conversion from âintâ to âconst char*â [-fpermissive]
36 | static regmatch_t empty = { -1, -1 };
| ^~
| |
| int
The problem is that Solaris regmatch_t has additional members before
rm_so and rm_eo, as is always allowed by POSIX.1
typedef struct {
const char *rm_sp, *rm_ep; /* Start pointer, end pointer */
regoff_trm_so, rm_eo; /* Start offset, end offset */
int rm_ss, rm_es; /* Used internally */
} regmatch_t;
so the initialization doesn't do what it's supposed to do.
Fixed by initializing the rm_so and rm_eo members explicitly.
Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu.
2025-04-08 Rainer Orth
gcc/cobol:
PR cobol/119217
* dts.h (csub_match): Initialize rm_so, rm_eo fields explicitly.
[Bug tree-optimization/120122] [14/15 Regression] wrong code due to VCE of bool being pulled out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120122 Bug 120122 depends on bug 116939, which changed state. Bug 116939 Summary: rewrite_to_defined_overflow/gimple_with_undefined_signed_overflow should also rewrite VCEs (from/to integral types) into casts https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116939 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/116939] rewrite_to_defined_overflow/gimple_with_undefined_signed_overflow should also rewrite VCEs (from/to integral types) into casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116939 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |16.0 Status|ASSIGNED|RESOLVED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug target/119832] RISC-V: Redundant floating point rounding mode store/restore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119832 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Kito Cheng --- Fixed on trunk
[Bug libfortran/120158] Incorrect UNSIGNED maxval/maxloc etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120158
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8c73c99b6a8c3a562fef360bc269bd60bab36076
commit r16-468-g8c73c99b6a8c3a562fef360bc269bd60bab36076
Author: Jakub Jelinek
Date: Thu May 8 09:36:30 2025 +0200
libfortran: Fix up maxval/maxloc for UNSIGNED [PR120158]
When libgfortran is compiled, there are some -Woverflow warnings like
../../../libgfortran/generated/maxloc0_4_m1.c:99:14: warning: unsigned
conversion from âintâ to âGFC_UINTEGER_1â {aka âunsigned charâ}
changes value from â-255â to â1â [-Woverflow]
99 | maxval = -GFC_UINTEGER_1_HUGE;
| ^
and those actually point a bug in the maxloc*/maxval* implementation
for UNSIGNED.
The intent of
#if defined ('atype_inf`)
result = -atype_inf;
#else
result = atype_min;
#endif
(or similar for maxval) is to initialize the variable with
minimum value of the type, if the type has infinities, then
negative infinity, otherwise the minimum (normalized) value.
atype_min expands for signed integers to say (-GFC_INTEGER_4_HUGE-1)
or for floating point to say -GFC_REAL_8_HUGE.
For UNSIGNED it expands to e.g. -GFC_UINTEGER_4_HUGE, but that is
-0xU which is 1U, while the minimum value of the type is
0.
Haven't tried to construct testcases for that, but I believe e.g.
maskval could return incorrectly 1 on an array (or masked array)
full of 0s, or maxloc could identify incorrectly the maximum location.
The following patch makes sure atype_min expands to 0 for atype_name
GFC_UINTEGER*.
2025-05-07 Jakub Jelinek
PR libfortran/120158
* m4/iparm.m4 (atype_min): For atype_name starting with
GFC_UINTEGER define to 0.
* generated/maxloc0_16_m1.c: Regenerate.
* generated/maxloc0_16_m2.c: Regenerate.
* generated/maxloc0_16_m4.c: Regenerate.
* generated/maxloc0_16_m8.c: Regenerate.
* generated/maxloc0_16_m16.c: Regenerate.
* generated/maxloc0_4_m1.c: Regenerate.
* generated/maxloc0_4_m2.c: Regenerate.
* generated/maxloc0_4_m4.c: Regenerate.
* generated/maxloc0_4_m8.c: Regenerate.
* generated/maxloc0_4_m16.c: Regenerate.
* generated/maxloc0_8_m1.c: Regenerate.
* generated/maxloc0_8_m2.c: Regenerate.
* generated/maxloc0_8_m4.c: Regenerate.
* generated/maxloc0_8_m8.c: Regenerate.
* generated/maxloc0_8_m16.c: Regenerate.
* generated/maxloc1_16_m1.c: Regenerate.
* generated/maxloc1_16_m2.c: Regenerate.
* generated/maxloc1_16_m4.c: Regenerate.
* generated/maxloc1_16_m8.c: Regenerate.
* generated/maxloc1_16_m16.c: Regenerate.
* generated/maxloc1_4_m1.c: Regenerate.
* generated/maxloc1_4_m2.c: Regenerate.
* generated/maxloc1_4_m4.c: Regenerate.
* generated/maxloc1_4_m8.c: Regenerate.
* generated/maxloc1_4_m16.c: Regenerate.
* generated/maxloc1_8_m1.c: Regenerate.
* generated/maxloc1_8_m2.c: Regenerate.
* generated/maxloc1_8_m4.c: Regenerate.
* generated/maxloc1_8_m8.c: Regenerate.
* generated/maxloc1_8_m16.c: Regenerate.
* generated/maxval_m1.c: Regenerate.
* generated/maxval_m2.c: Regenerate.
* generated/maxval_m4.c: Regenerate.
* generated/maxval_m8.c: Regenerate.
* generated/maxval_m16.c: Regenerate.
[Bug tree-optimization/119155] [12/13/14 Regression] Aligned vector element accesses emitted for packed struct access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119155 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|12.5|15.0 Known to fail||14.2.1 Known to work||15.1.0 --- Comment #10 from Richard Biener --- I decided to not backport further, the affected code diverged too much and I don't know any case where this is an actual problem (strict-alignment target with misaligned vector access support required).
[Bug c/120177] ICE in lra_constraints, "maximum number of generated reload insns" with inline assembly using x87 instructions (finitq, fldq, fst) — 13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120177 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code, ||inline-asm, needs-bisection Status|UNCONFIRMED |NEW Known to work||14.1.0 Last reconfirmed||2025-05-08 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Works in 14+, likely a duplicate. Are you filing old issues for old releases?
[Bug target/120169] [m68k] internal compiler error: in maybe_record_trace_start, at dwarf2cfi.cc:2591 with LRA enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120169 --- Comment #3 from Andreas Schwab --- Workaround: -fno-combine-stack-adjustments
[Bug c/120181] New: Bug in alpha jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120181 Bug ID: 120181 Summary: Bug in alpha jump tables Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: camm at debian dot org CC: camm at debian dot org, dave.anglin at bell dot net, deller at gmx dot de, glaubitz at physik dot fu-berlin.de, rth at gcc dot gnu.org Target Milestone: --- Created attachment 61370 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61370&action=edit all files It appears as if the jump table computation is too long by two instructions. Attachments should illustrate problem clearly.
[Bug c/120180] [OpenMP] ICE in C (c_parser_consume_token) / C++ cp_parser_skip_to_pragma_eol in error recovery for metadirective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120180 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #2 from mcccs at gmx dot com --- Bisect found r15-6961-g4e20914d3306d8
[Bug c++/120125] [15/16 Regression] ICE in add_to_same_comdat_group when using -Os or -fdeclone-ctor-dtor since r15-521-g6ad7ca1bb90573
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120125 Nathaniel Shead changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org --- Comment #7 from Nathaniel Shead --- Created attachment 61368 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61368&action=edit proposed fix ...I got nerd-sniped into taking a closer look rather than sleeping; here's a patch appropriate for 15/16 I'll test. For 14 I'll remove the modules.cc hunk and xfail the appropriate scan-assembler check.
[Bug gcov-profile/120086] FAIL: gcc.misc-tests/gcov-29.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086 --- Comment #16 from John David Anglin --- Your patch works for me: https://gcc.gnu.org/pipermail/gcc-testresults/2025-May/846366.html
[Bug c++/120174] ICE (Segfault) in GCC when passing array of class to generic lambda taking decltype of lambda with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120174 --- Comment #2 from mcccs at gmx dot com --- Actually this is most likely an original bug because unlike other bugs that started with the same commit, this one segfaults without printing any stacktrace.
[Bug target/117818] [12/13/14/15/16 regression] vec_add incorrectly generates vadduwm for vector char const inputs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117818 --- Comment #8 from Segher Boessenkool --- We still support powerpc64-* just fine. And powerpc-linux (the 32-bit target) is tested just fine as well, and the community does support it. No one cares _too_ much about it anymore, but why let it degrade if not necessary!
[Bug target/120181] Bug in alpha jump tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120181 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords||wrong-code Status|UNCONFIRMED |WAITING Last reconfirmed||2025-05-08 --- Comment #1 from Andrew Pinski --- How did you configure GCC? How exactly did you compile the source? What options are you passing to GCC?
[Bug testsuite/120168] [16 Regression] gcc.dg/tree-ssa/pr31261.c fails now on targets which char defaults to unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120168 --- Comment #3 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683008.html
[Bug target/120165] [m68k] gfortran segfaults when built with LRA enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120165 --- Comment #3 from John Paul Adrian Glaubitz --- Created attachment 61372 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61372&action=edit Preprocessed source for ICE reported in PR-120165
[Bug tree-optimization/120156] [14 Regression] Segfault while compiling eigen test bdcsvd.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120156 --- Comment #6 from Stefan Schulze Frielinghaus --- Created attachment 61371 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61371&action=edit reduced test
[Bug libstdc++/120160] Implicitly import std if standard library header is included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120160 m.cencora at gmail dot com changed: What|Removed |Added CC||m.cencora at gmail dot com --- Comment #2 from m.cencora at gmail dot com --- I think better option for aiding migration to modules world is to provide something similar to MSVC /translateIncludes option as that would work in case of all code, and not just standard library headers. https://learn.microsoft.com/en-us/cpp/build/reference/translateinclude?view=msvc-170
[Bug tree-optimization/120156] [14 Regression] Segfault while compiling eigen test bdcsvd.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120156 --- Comment #7 from Stefan Schulze Frielinghaus --- Brrr due to aggressive reduction t.ii became kind of invalid/incomplete which means the reduced test case errors out early for release branches 12 and 13. However, running the original tests from eigen for release branches 12 and 13 result in the same ICE. I guess going further backwards/bisecting isn't required for this bug. If you think otherwise just let me know.
