Jonathan Wakely [Fri, 9 May 2025 10:39:39 +0000 (11:39 +0100)]
libstdc++: Suppress GDB output from new 'skip' commands [PR118260]
I added some gdb.execute('skip -rfu ...') commands to the Python hook
loaded with libstdc++.so but this makes GDB print output like:
Function(s) ^std::(move|forward|as_const|(__)?addressof) will be skipped when stepping.
This probably aren't interesting to users, so this change suppresses
that output by capturing the output into the gdb.execute return value
(which is then ignored). An exception is thrown if the gdb.execute
command fails, so this doesn't suppress any errors which might be
meaningful to users or libstdc++ developers.
libstdc++-v3/ChangeLog:
PR libstdc++/118260
* python/hook.in: Suppress output from gdb.execute calls to
register skips.
Richard Biener [Sun, 11 May 2025 12:03:12 +0000 (14:03 +0200)]
tree-optimization/120211 - constrain LOOP_VINFO_EARLY_BREAKS_LIVE_IVS more
The PR120089 fix added more PHIs to LOOP_VINFO_EARLY_BREAKS_LIVE_IVS
but not checking that we only add PHIs with a latch argument. The
following adds this missing check.
PR tree-optimization/120211
* tree-vect-stmts.cc (vect_stmt_relevant_p): Only add PHIs
from the loop header to LOOP_VINFO_EARLY_BREAKS_LIVE_IVS.
* gcc.dg/vect/vect-early-break_135-pr120211.c: New testcase.
* gcc.dg/torture/pr120211-1.c: Likewise.
Richard Biener [Wed, 7 May 2025 08:20:55 +0000 (10:20 +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.
Richard Biener [Wed, 7 May 2025 07:43:54 +0000 (09:43 +0200)]
tree-optimization/120143 - ICE with failed early break store move
The early break vectorization store moving was incorrectly trying
to move the pattern stmt instead of the original one which failed
to register and then confused virtual SSA form due to the update
triggered by a degenerate virtual PHI.
PR tree-optimization/120143
* tree-vect-data-refs.cc (vect_analyze_early_break_dependences):
Move/update the original stmts, not the pattern stmts which
lack virtual operands and are not in the IL.
* gcc.dg/vect/vect-early-break_135-pr120143.c: New testcase.
Richard Biener [Mon, 5 May 2025 12:29:34 +0000 (14:29 +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.
Richard Biener [Thu, 8 May 2025 08:05:42 +0000 (10:05 +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.
Thomas Koenig [Tue, 6 May 2025 16:05:41 +0000 (18:05 +0200)]
Fix PR 119928, formal arguments used to wrongly inferred for CLASS.
The problem was indeed that generating a formal from an actual
arglist is a bad idea when classes are involved. Fixed in the
attached patch. I think it still makes sense to remove the checks
when the other attributes are present (or PR96073 may come back
in different guise, even if I have to test case at present).
I have also converted the test to a run-time check.
gcc/fortran/ChangeLog:
PR fortran/119928
* interface.cc (gfc_check_dummy_characteristics): Do not issue
error if one dummy symbol has been generated from an actual
argument and the other one has OPTIONAL, INTENT, ALLOCATABLE,
POINTER, TARGET, VALUE, ASYNCHRONOUS or CONTIGUOUS.
(gfc_get_formal_from_actual_arglist): Do nothing if symbol
is a class.
gcc/testsuite/ChangeLog:
PR fortran/119928
* gfortran.dg/interface_60.f90: New test.
Andrew Pinski [Sun, 11 May 2025 00:13:05 +0000 (17:13 -0700)]
testsuite: Fix pr119131-1.c for targets which emit a psabi warning for vectors of DFP [PR119909]
On PowerPC, there is a psabi warning for argument passing of a DFP vector.
We are not expecting this warning and we get a failure due to it.
Adding -Wno-psabi fixes the testcase.
Harald Anlauf [Sat, 3 May 2025 18:35:57 +0000 (20:35 +0200)]
Fortran: array subreferences and components of derived types [PR119986]
PR fortran/119986
gcc/fortran/ChangeLog:
* expr.cc (is_subref_array): When searching for array references,
do not terminate early so that inquiry references to complex
components work.
* primary.cc (gfc_variable_attr): A substring reference can refer
to either a scalar or array character variable. Adjust search
accordingly.
but stretch_14 is a 8-bit boolean so the two forms are not equivalent, that
is to say dropping the "& 1" is wrong. It's another instance of the issue:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558537.html
Here it's the reverse case: the bitwise NOT (~) is treated as logical by the
machinery in range-op.cc but the bitwise AND (&) is *not* treated as logical
by that of vr-values.cc, leading to the same problematic outcome.
gcc/
* vr-values.cc (simplify_using_ranges::simplify) <BIT_AND_EXPR>:
Do not call simplify_bit_ops_using_ranges for boolean types whose
precision is not 1.
gcc/testsuite/
* gnat.dg/opt106.adb: New test.
* gnat.dg/opt106_pkg1.ads, gnat.dg/opt106_pkg1.adb: New helper.
* gnat.dg/opt106_pkg2.ads, gnat.dg/opt106_pkg2.adb: Likewise.
Jakub Jelinek [Thu, 8 May 2025 07:36:30 +0000 (09:36 +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
-0xffffffffU 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*.
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 <jakub@redhat.com>
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.
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.
Jakub Jelinek [Wed, 7 May 2025 15:25:42 +0000 (17:25 +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 <line_map *>
(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 0x500003a0 and map[-1] has
m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 12 and
map[0].included_from is set to 0x50000320.
For #c12 map[0].start_location is 0x606c0402 and map[-2].start_location is
0x606c0400 and m_column_and_range_bits is 0 for all 3 maps.
map[0].included_from is set to 0x606c0401.
The last important part is again in linemap_add when doing LC_LEAVE:
/* (MAP - 1) points to the map we are leaving. The
map from which (MAP - 1) got included should be the map
that comes right before MAP in the same file. */
from = linemap_included_from_linemap (set, map - 1);
/* A TO_FILE of NULL is special - we use the natural values. */
if (to_file == NULL)
{
to_file = ORDINARY_MAP_FILE_NAME (from);
to_line = SOURCE_LINE (from, from[1].start_location);
sysp = ORDINARY_MAP_IN_SYSTEM_HEADER_P (from);
}
Here it wants to compute the right to_line which ought to be the line after
the #include directive.
On the #c11 testcase that doesn't work correctly though, because
map[-1].included_from is 0x50000320, from[0] for that is LC_ENTER with
start_location 0x4080 and m_column_and_range_bits 12 but note that we've
earlier computed map[-1].start_location + (-1 & 0xffffff80) and so only
decreased by 7 bits, so to_line is still on the line with #include and not
after it. In the #c12 that doesn't happen, all the ordinary maps involved
there had 0 m_column_and_range_bits and so this computes correct line.
Below is a fix for the trunk including testcases using the
location_overflow_plugin hack to simulate the bugs without needing huge
files (in the 14 case it is just 330KB and almost 10MB, but in the 15
case it would need to be far bigger).
The pre- r15-9018 trunk has
FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*6[^\n\r]*== 6
and current trunk
FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*6[^\n\r]*== 6
FAIL: gcc.dg/plugin/location-overflow-test-pr120061.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*5[^\n\r]*== 5
and with the patch everything PASSes.
I'll post afterwards a 14 version of the patch.
The patch reverts the r15-9018 change, because it is incorrect,
we really need to decrement it even when crossing ordinary map
boundaries, so that the location is not on the line after the #include
line but somewhere on the #include line. It also patches two spots
in linemap_add mentioned above to make sure we get correct locations
both in the included_from location_t when doing LC_ENTER (second
line-map.cc hunk) and when doing LC_LEAVE to compute the right to_line
(first line-map.cc hunk), both in presence of an added LC_RENAME
with the same start_location as the following LC_ENTER (i.e. the
problematic cases).
The LC_ENTER hunk is mostly to ensure included_form location_t is
at the start of the #include line (column 0), without it we can
decrease include_from not enough and end up at some random column
in the middle of the line, because it is masking away
map[-1].m_column_and_range_bits bits even when in the end the resulting
include_from location_t will be found in map[-2] map with perhaps
different m_column_and_range_bits. That alone doesn't fix the bug
though.
The more important is the LC_LEAVE hunk and the problem there is
caused by linemap_line_start not actually doing
r = set->highest_line + (line_delta << map->m_column_and_range_bits);
when adding a new map (the LC_RENAME one because we need to switch to
different number of directly encoded ranges, or columns, etc.).
So, in the original PR108900 case that
to_line = SOURCE_LINE (from, from[1].start_location);
doesn't do the right thing, from there is the last < 0x50000000 map
with m_column_and_range_bits 12, from[1] is the first one above it
and map[-1].included_from is the correct location of column 0 on
the #include line, but as the new LC_RENAME map has been created without
actually increasing highest_location to be on the new line (we've just
set to_line of the new LC_RENAME map to the correct line),
to_line = SOURCE_LINE (from, from[1].start_location);
stays on the same source line. I've tried to just replace that with
to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1;
i.e. just find out the #include line from map[-1].included_from and
add 1 to it, unfortunately that breaks the
c-c++-common/cpp/line-4.c
test where we expect to stay on the same 0 line for LC_LEAVE from
<command line> and gcc.dg/cpp/trad/Wunused.c, gcc.dg/cpp/trad/builtins.c
and c-c++-common/analyzer/named-constants-via-macros-traditional.c tests
all with -traditional-cpp preprocessing where to_line is also off-by-one
from the expected one.
So, this patch instead conditionalizes it, uses the
to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1;
way only if from[1] is a LC_RENAME map (rather than the usual
LC_ENTER one), that should limit it to the problematic cases of when
parse_include peeked after EOL and had to create LC_RENAME map with
the same start_location as the LC_ENTER after it.
Some further justification for the LC_ENTER hunk, using the
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682774.html testcase
(old is 14 before r14-11679, vanilla current 14 and new with the 14 patch)
I get
$ /usr/src/gcc-14/obj/gcc/cc1.old -quiet -std=c23 pr116047.c -nostdinc
In file included from pr116047-1.h:327677:21,
from pr116047.c:4:
pr116047-2.h:1:1: error: unknown type name ‘a’
1 | a b c;
| ^
pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
1 | a b c;
| ^
pr116047-1.h:327677:1: error: static assertion failed: ""
327677 | #include "pr116047-2.h"
| ^~~~~~~~~~~~~
$ /usr/src/gcc-14/obj/gcc/cc1.vanilla -quiet -std=c23 pr116047.c -nostdinc
In file included from pr116047-1.h:327678,
from pr116047.c:4:
pr116047-2.h:1:1: error: unknown type name ‘a’
1 | a b c;
| ^
pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
1 | a b c;
| ^
$ /usr/src/gcc-14/obj/gcc/cc1.new -quiet -std=c23 pr116047.c -nostdinc
In file included from pr116047-1.h:327677,
from pr116047.c:4:
pr116047-2.h:1:1: error: unknown type name ‘a’
1 | a b c;
| ^
pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’
1 | a b c;
| ^
pr116047-1.h has on lines 327677+327678:
#include "pr116047-2.h"
static_assert (__LINE__ == 327678, "");
so the static_assert failure is something that was dealt mainly in the
LC_LEAVE hunk and files.cc reversion, but please have a look at the
In file included from lines.
14.2 emits correct line (#include "pr116047-2.h" is indeed on line
327677) but some random column in there (which is not normally printed
for smaller headers; 21 is the . before extension in the filename).
Current trunk emits incorrect line (327678 instead of 327677, clearly
it didn't decrement).
And the patched compiler emits the right line with no column, as would
be printed if I remove e.g. 300000 newlines from the file.
2025-05-07 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/108900
PR preprocessor/116047
PR preprocessor/120061
* files.cc (_cpp_stack_file): Revert 2025-03-28 change.
* line-map.cc (linemap_add): Use
SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; instead of
SOURCE_LINE (from, from[1].start_location); to compute to_line
for LC_LEAVE. For LC_ENTER included_from computation, look at
map[-2] or even lower if map[-1] has the same start_location as
map[0].
* gcc.dg/plugin/plugin.exp: Add location-overflow-test-pr116047.c
and location-overflow-test-pr120061.c.
* gcc.dg/plugin/location_overflow_plugin.cc (plugin_init): Don't error
on unknown values, instead just break. Handle 0x4fHHHHHH arguments
differently.
* gcc.dg/plugin/location-overflow-test-pr116047.c: New test.
* gcc.dg/plugin/location-overflow-test-pr116047-1.h: New test.
* gcc.dg/plugin/location-overflow-test-pr116047-2.h: New test.
* gcc.dg/plugin/location-overflow-test-pr120061.c: New test.
* gcc.dg/plugin/location-overflow-test-pr120061-1.h: New test.
* gcc.dg/plugin/location-overflow-test-pr120061-2.h: New test.
Jason Merrill [Wed, 30 Apr 2025 14:18:46 +0000 (10:18 -0400)]
c++: C++17/20 class layout divergence [PR120012]
C++20 made a class with only explicitly defaulted constructors no longer
aggregate, and this wrongly affected whether the class is considered "POD
for layout purposes" under the ABI.
Conveniently, we already have check_non_pod_aggregate to diagnose cases
where this makes a difference, due to PR103681 around a C++14 aggregate
change.
This backport is the same code change as the trunk version, but since
-fabi-version=21 cannot be selected, the fix is not available, only the
warning, so the first testcase is different.
PR c++/120012
gcc/cp/ChangeLog:
* cp-tree.h (struct lang_type): Add non_aggregate_pod.
(CLASSTYPE_NON_AGGREGATE_POD): New.
* class.cc (check_bases_and_members): Set it.
(check_non_pod_aggregate): Diagnose it.
gcc/testsuite/ChangeLog:
* g++.dg/abi/base-defaulted1.C: New test.
* g++.dg/abi/base-defaulted1a.C: New test.
Jason Merrill [Thu, 1 May 2025 13:42:40 +0000 (09:42 -0400)]
c++: let plain -Wabi warn about future changes
c_common_post_options limits flag_abi_version and flag_abi_compat_version to
actual ABI version numbers, but let's not do that for warn_abi_version; we
might want to add a warning relative to a future ABI version that isn't
available in the current release, such backporting the PR120012 warning.
Also allow plain -Wabi to include such a warning without complaining that
it's useless.
Also warn about an unsupported -fabi-version argument.
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Let plain -Wabi warn
about changes in a future version.
Martin Jambor [Tue, 6 May 2025 15:28:43 +0000 (17:28 +0200)]
ipa: Do not emit info about temporary clones to ipa-clones dump (PR119852)
As described in PR 119852, the output of -fdump-ipa-clones can contain
"(null)" as the suffix/reason for cloning when we need to create a
clone to hold the original function during recursive inlining. Such
clone is never output and so should not be part of the dump output
either.
gcc/ChangeLog:
2025-04-23 Martin Jambor <mjambor@suse.cz>
PR ipa/119852
* cgraphclones.cc (dump_callgraph_transformation): Document the
function. Do not dump if suffix is NULL.
Martin Jambor [Tue, 6 May 2025 15:28:42 +0000 (17:28 +0200)]
Document option -fdump-ipa-clones
I have noticed that the option -fdump-ipa-clones is not documented
although there are users who depend on it. This patch adds the
missing documentation along with the description of the information it
dumps and the format it uses.
I am never quite sure which of the texinfo mark-ups is the most
appropriate in which situation, I'll of course incorporate any
feedback on this as well as the general wording of the text.
After we settle on a version, I'd like to backport the documentation
also at least to GCC 15, 14 and 13.
Is it perhaps OK for master and the branches or what would better be
changed?
Tomasz Kamiński [Mon, 5 May 2025 14:32:58 +0000 (16:32 +0200)]
libstdc++: Fix width computation for the chrono formatting [PR120114]
Use `__unicode::_field_width` to compute the field width of the output when writting
the formatted output for std::chrono::types. This applies both to characters copied
from format string, and one produced by localized formatting.
We also use _Str_sink::view() instead of get(), which avoids copying the content of
the buffer to std::string in case of small output.
PR libstdc++/120114
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__formatter_chrono::_M_format): Use __field_width.
* testsuite/std/time/format/pr120114.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
(cherry picked from commit 52f6ab55051ff43fd1b40ff06d9501043f8ba844)
Andrew MacLeod [Fri, 2 May 2025 19:48:08 +0000 (15:48 -0400)]
Allow IPA_CP to handle UNDEFINED as VARYING.
When applying a bitmask to reflect ranges, it is sometimes deferred and
this can result in an UNDEFINED result. IPA is not expecting this, and
add a check for it, and convert to VARYING if encountered.
PR tree-optimization/120048
gcc/
* ipa-cp.cc (ipcp_store_vr_results): Check for UNDEFINED.
libstdc++: fix possible undefined atomic lock-free type aliases in module std
When building for 'i386-*' targets, all basic types are 'sometimes lock-free'
and thus std::atomic_signed_lock_free and std::atomic_unsigned_lock_free are
not declared. In the header <atomic>, they are placed in preprocessor
condition __cpp_lib_atomic_lock_free_type_aliases. In module std, they should
be the same.
libstdc++-v3/ChangeLog:
* src/c++23/std.cc.in (atomic_signed_lock_free): Guard with
preprocessor check for __cpp_lib_atomic_lock_free_type_aliases.
(atomic_unsigned_lock_free): Likewise.
The following testcase ICEs because of a mismatch between wide_int
precision, in particular lr_and_mask has 32-bit precision while sign has
16-bit.
decode_field_reference ensures that {ll,lr,rl,rr}_and_mask has
{ll,lr,rl,rr}_bitsize precision, so the
ll_and_mask |= sign;
and
rl_and_mask |= sign;
and
ll_and_mask &= sign;
and
rl_and_mask &= sign;
cases should work right, sign has in those cases {ll,rl}_bitsize
precision. The problem is that nothing until much later guarantees
that ll_bitsize == lr_bitsize or rl_bitsize == rr_bitsize.
In the testcase there is
((b ^ a) & 3) < 0
where a is 16-bit and b is 32-bit, so it is the lsignbit handling,
and because of the xor the xor operand is moved to the *r_and_mask, so
with ll_and_mask being 16-bit 3 and lr_and_mask being 32-bit 3.
Now, either b in the above case would be INTEGER_CST, in that case
if rr_arg was also INTEGER_CST we'd use the l_const && r_const case
and try to handle it, or we'd run into (though much later)
if (ll_bitsize != lr_bitsize || rl_bitsize != rr_bitsize
...
return 0;
One possibility is dealing with a different precision using wide_int::from.
Another option used in this patch as it is safest is
+ if (ll_bitsize != lr_bitsize)
+ return 0;
if (!lr_and_mask.get_precision ())
lr_and_mask = sign;
else
lr_and_mask &= sign;
and similarly in the other hunk, i.e. punt if there is a mismatch
early.
And yet another option would be to compute
the sign
wide_int sign = wi::mask (ll_bitsize - 1, true, ll_bitsize);
/* If ll_arg is zero-extended and we're testing the sign bit, we know
what the result should be. Shifting the sign bit out of sign will get
us to mask the entire field out, yielding zero, i.e., the sign bit of
the zero-extended value. We know the masked value is being compared
with zero, so the compare will get us the result we're looking
for: TRUE if EQ_EXPR, FALSE if NE_EXPR. */
if (lsignbit > ll_bitsize && ll_unsignedp)
sign <<= 1;
once again for the lr_and_mask and rr_and_mask cases using rl_bitsize.
As we just return 0; anyway unless l_const && r_const, if l_const & r_const
are false it doesn't really matter what is chosen, but for the const
cases it matters and I'm not sure what is right. So the second option
might be safest.
2025-05-06 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/120074
* gimple-fold.cc (fold_truth_andor_for_ifcombine): For
lsignbit && l_xor case, punt if ll_bitsize != lr_bitsize. Similarly
for rsignbit && r_xor case, punt if rl_bitsize != rr_bitsize.
Formatting fix.
Fix udr-sve.c target test that to check for the correct results based on the
OpenMP clauses used. The test was first written with a misunderstood
functionality of the reduction clause.
Richard Biener [Wed, 30 Apr 2025 08:01:47 +0000 (10:01 +0200)]
ipa/120006 - wrong code with IPA PTA
When PTA gets support for special-handling more builtins in
find_func_aliases the corresponding code in find_func_clobbers
needs updating as well since for unhandled cases it assumes
the former will populate ESCAPED accordingly. The following
fixes a few omissions, the testcase runs into the missing strdup
handling. I believe the more advanced handling using modref
results and fnspecs opened a larger gap, the proper fix is to
merge both functions, gating the clobber/use part on a parameter
to avoid diverging.
Richard Biener [Mon, 28 Apr 2025 09:15:53 +0000 (11:15 +0200)]
ipa/119973 - IPA PTA issue with global initializers
For global initializers with IPA PTA we initialize them from the
IPA reference data but that lacks references to the constant pool.
The following conservatively considers the whole initializer.
PR ipa/119973
* tree-ssa-structalias.cc (create_variable_info_for):
Build constraints from DECL_INITIAL directly rather than
the IPA reference list which is incomplete.
Eric Botcazou [Mon, 5 May 2025 10:58:58 +0000 (12:58 +0200)]
Ada: Fix assertion failure on Finalizable aspect for tagged record type
This is a (benign) assertion failure on the mainline for the new Finalizable
aspect put on a tagged record type when not all the primitives are declared.
This compiles and runs on the 15 branch because assertions are disabled.
gcc/ada/
PR ada/120104
* exp_ch3.adb (Expand_Freeze_Record_Type): For a controlled tagged
type, freeze only the controlled primitives that are present.
gcc/testsuite/
* gnat.dg/specs/finalizable1.ads: New test.
Harald Anlauf [Thu, 24 Apr 2025 19:28:35 +0000 (21:28 +0200)]
Fortran: fix procedure pointer handling with -fcheck=pointer [PR102900]
PR fortran/102900
gcc/fortran/ChangeLog:
* trans-decl.cc (gfc_generate_function_code): Use sym->result
when generating fake result decl for functions returning
allocatable or pointer results.
* trans-expr.cc (gfc_conv_procedure_call): When checking the
pointer status of an actual argument passed to a non-allocatable,
non-pointer dummy which is of type CLASS, do not check the
class container of the actual if it is just a procedure pointer.
(gfc_trans_pointer_assignment): Fix treatment of assignment to
NULL of a procedure pointer.
gcc/testsuite/ChangeLog:
* gfortran.dg/proc_ptr_52.f90: Add -fcheck=pointer to options.
* gfortran.dg/proc_ptr_57.f90: New test.
Jakub Jelinek [Fri, 2 May 2025 19:19:05 +0000 (21:19 +0200)]
c: Fix up RAW_DATA_CST handling in check_constexpr_init [PR120057]
The pr120057-1.c testcase is incorrectly rejected since
r15-4377 (and for a while it also ICEd after the error), i.e.
the optimization of large C initializers using RAW_DATA_CST.
Similarly, the embed-18.c testcase is incorrectly rejected since
the embed support has been introduced and RAW_DATA_CST used for that.
The callers of check_constexpr_init (store_init_value and
output_init_element) compute int_const_expr as
int_const_expr = (TREE_CODE (init) == INTEGER_CST
&& !TREE_OVERFLOW (init)
&& INTEGRAL_TYPE_P (TREE_TYPE (init)));
but that is only passed through down to check_constexpr_init.
I think tweaking those 2 callers to also allow RAW_DATA_CST for
int_const_expr when check_constexpr_init needs top special case it
no matter what would be larger, so the patch just changes
check_constexpr_init to deal with RAW_DATA_CST in the initializers.
For TYPE_UNSIGNED char precision integral types RAW_DATA_CST is
always valid, for !TYPE_UNSIGNED we need to check for 128-255 values
being turned into negative ones.
c++/modules: Ensure deduction guides for imported types are reachable [PR120023]
In the linked PR, because the deduction guides depend on an imported
type, we never walk the type and so never call add_deduction_guides.
This patch ensures that we make bindings for deduction guides if we saw
any deduction guide at all.
PR c++/120023
gcc/cp/ChangeLog:
* module.cc (depset::hash::find_dependencies): Also call
add_deduction_guides when walking one.
gcc/testsuite/ChangeLog:
* g++.dg/modules/dguide-7_a.C: New test.
* g++.dg/modules/dguide-7_b.C: New test.
* g++.dg/modules/dguide-7_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit fb4583566afdee50aad12e1219610813b44bdff4)
c++/modules: Fix imported CNTTPs being considered non-constant [PR119938]
When importing a CNTTP object, since r15-3031-g0b7904e274fbd6 we
shortcut the processing of the generated NTTP so that we don't attempt
to recursively load pendings. However, due to an oversight we do not
properly set TREE_CONSTANT or DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P
on the decl, which confuses later processing. This patch ensures that
this happens correctly.
PR c++/119938
gcc/cp/ChangeLog:
* pt.cc (get_template_parm_object): When !check_init, add assert
that expr really is constant and mark decl as such.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tpl-nttp-2_a.H: New test.
* g++.dg/modules/tpl-nttp-2_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit d613678c94f06809656e56b37f314501b37a5ddd)
c++/modules: Catch exposures of TU-local values through inline references [PR119996]
In r15-9136-g0210bedf481a9f we started erroring for inline variables
that exposed TU-local entities in their definition, as such variables
would need to have their definitions emitted in importers but would not
know about the TU-local entities they referenced.
A case we mised was potentially-constant references, which disable
streaming of their definitions in make_dependency so as to comply with
[expr.const] p9.2. This meant that we didn't see the definition
referencing a TU-local entity, leading to nonsensical results.
PR c++/119551
PR c++/119996
gcc/cp/ChangeLog:
* module.cc (depset::hash::make_dependency): Also mark inline
variables referencing TU-local values as exposures here.
(depset::hash::finalize_dependencies): Add error message for
inline variables.
gcc/testsuite/ChangeLog:
* g++.dg/modules/internal-13.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
(cherry picked from commit 22ccaded63e96e5a42f4e3676dbbb57aa05b36f9)
Andrew MacLeod [Mon, 14 Apr 2025 20:25:15 +0000 (16:25 -0400)]
Always reflect lower bits from mask in subranges.
During intersection, we expand the subranges to exclude the lower values
from a bitmask with trailing zeros. This leads to inconsistant evaluations
and in this case of this PR, that lead to an infinite cycle.
Always expand the lower subranges in set_range_from_bitmask instead.
PR tree-optimization/119712
gcc/
* value-range.cc (range_bitmask::adjust_range): Delete.
(irange::set_range_from_bitmask): Integrate adjust_range.
(irange::update_bitmask): Do nothing if bitmask doesnt change.
(irange:intersect_bitmask): Do not call adjust_range. Exit if there
is no second bitmask.
* value-range.h (adjust_range): Remove prototype.
In r15-123 and r14-11434 we unconditionally set processing_template_decl
when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to
handle instantiation of the dependently scoped friend declaration
template<int N>
template<class T>
friend class A<N>::B;
where the scope A<N> remains dependent after instantiation. But this
turns out to misbehave for the UNBOUND_CLASS_TEMPLATE in the below
testcase representing
g<[]{}>::template fn
since with the flag set substituting the args of test3 into the lambda
causes us to defer the substitution and yield a lambda that still looks
dependent, which in turn makes g<[]{}> still dependent and not suitable
for qualified name lookup.
This patch restricts setting processing_template_decl during
UNBOUND_CLASS_TEMPLATE substitution to the case where there are multiple
levels of introduced template parameters, as in the friend declaration.
(This means we need to substitute the template parameter list(s) first,
which makes sense since they lexically appear first.)
PR c++/119981
PR c++/119378
gcc/cp/ChangeLog:
* pt.cc (tsubst) <case UNBOUND_CLASS_TEMPLATE>: Substitute
into template parameter list first. When substituting the
context, only set processing_template_decl if there's more
than one level of introduced template parameters.
Eric Botcazou [Wed, 30 Apr 2025 10:41:36 +0000 (12:41 +0200)]
Fix GNAT build failure for x86/FreeBSD
gcc/ada/
PR ada/112958
* Makefile.rtl (LIBGNAT_TARGET_PAIRS) [x86 FreeBSD]: Add specific
version of s-dorepr.adb.
* libgnat/s-dorepr__freebsd.adb: New file.
AVR: target/119989 - Add missing clobbers to xload_<mode>_libgcc.
libgcc's __xload_1...4 is clobbering Z (and also R21 is some cases),
but avr.md had clobbers of respective GPRs only up to reload.
Outcome was that code reading from the same __memx address twice
could be wrong. This patch adds respective clobbers.
Forward-port from 2025-04-30 r14-11703
PR target/119989
gcc/
* config/avr/avr.md (xload_<mode>_libgcc): Clobber R21, Z.
gcc/testsuite/
* gcc.target/avr/torture/pr119989.h: New file.
* gcc.target/avr/torture/pr119989-memx-1.c: New test.
* gcc.target/avr/torture/pr119989-memx-2.c: New test.
* gcc.target/avr/torture/pr119989-memx-3.c: New test.
* gcc.target/avr/torture/pr119989-memx-4.c: New test.
* gcc.target/avr/torture/pr119989-flashx-1.c: New test.
* gcc.target/avr/torture/pr119989-flashx-2.c: New test.
* gcc.target/avr/torture/pr119989-flashx-3.c: New test.
* gcc.target/avr/torture/pr119989-flashx-4.c: New test.
Adapt testsuite v3_target_compile to strip version namespace from compiler
output so that dg-error and dg-warning directives do not need to consider it.
Avoid a aligned_storage check as behavior has been fixed only when using
gnu-versioned-namespace as it is an abi breaking change.
libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp (v3_target_compile): Strip version namespace
from compiler output.
* testsuite/20_util/aligned_storage/value.cc [_GLIBCXX_INLINE_VERSION]:
Avoid align_msa check.
* testsuite/20_util/function/cons/70692.cc: Remove now useless __8 namespace
pattern.
* testsuite/23_containers/map/48101_neg.cc: Likewise.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
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.
c++/modules: Ensure DECL_FRIEND_CONTEXT is streamed [PR119939]
An instantiated friend function relies on DECL_FRIEND_CONTEXT being set
to be able to recover the template arguments of the class that
instantiated it, despite not being a template itself. This patch
ensures that this data is streamed even when DECL_CLASS_SCOPE_P is not
true.
PR c++/119939
gcc/cp/ChangeLog:
* module.cc (trees_out::lang_decl_vals): Also stream
lang->u.fn.context when DECL_UNIQUE_FRIEND_P.
(trees_in::lang_decl_vals): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/modules/concept-11_a.H: New test.
* g++.dg/modules/concept-11_b.C: New test.
c++/modules: Find non-exported reachable decls when instantiating friend classes [PR119863]
In r15-9029-geb26b667518c95, we started checking for conflicting
declarations with any reachable decl attached to the same originating
module. This exposed the issue in the PR, where we would always create
a new type even if a matching type existed in the original module.
This patch reworks lookup_imported_hidden_friend to handle this case
better, by first checking for any reachable decl in the attached module
before looking in the mergeable decl slots.
PR c++/119863
gcc/cp/ChangeLog:
* name-lookup.cc (get_mergeable_namespace_binding): Remove
no-longer-used function.
(lookup_imported_hidden_friend): Also look for hidden imported
decls in an attached decl's module.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tpl-friend-18_a.C: New test.
* g++.dg/modules/tpl-friend-18_b.C: New test.
* g++.dg/modules/tpl-friend-18_c.C: New test.
Jakub Jelinek [Fri, 25 Apr 2025 12:42:01 +0000 (14:42 +0200)]
s390: Allow 5+ argument tail-calls in some -m31 -mzarch special cases [PR119873]
Here is a patch to handle the PARALLEL case too.
I think we can just use rtx_equal_p there, because it will always use
SImode in the EXPR_LIST REGs in that case.
2025-04-25 Jakub Jelinek <jakub@redhat.com>
PR target/119873
* config/s390/s390.cc (s390_call_saved_register_used): Don't return
true if default definition of PARM_DECL SSA_NAME of the same register
is passed in call saved register in the PARALLEL case either.
Tomasz Kamiński [Tue, 22 Apr 2025 07:56:42 +0000 (09:56 +0200)]
libstdc++: Define __cpp_lib_format_ranges in format header [PR109162]
As P2286R8 and P2585R1 as now fully implemented, we now define
__cpp_lib_format_ranges feature test macro with __cpp_lib_format_ranges.
This macro is provided only in <format>.
Uses of internal __glibcxx_format_ranges are also updated.
PR libstdc++/109162
libstdc++-v3/ChangeLog:
* include/bits/version.def (format_ranges): Remove no_stdname and
update value.
* include/bits/version.h: Regenerate.
* src/c++23/std.cc.in: Replace __glibcxx_format_ranges with
__cpp_lib_format_ranges.
* testsuite/std/format/formatter/lwg3944.cc: Likewise.
* testsuite/std/format/parse_ctx.cc: Likewise.
* testsuite/std/format/string.cc: Likewise.
* testsuite/std/format/ranges/feature_test.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
(cherry picked from commit 049fefd7e1501ac9dcc66a5ef6c34cea0331dc43)
Tomasz Kamiński [Fri, 18 Apr 2025 12:56:39 +0000 (14:56 +0200)]
libstdc++: Implement formatters for queue, priority_queue and stack [PR109162]
This patch implements formatter specializations for standard container adaptors
(queue, priority_queue and stack) from P2286R8.
To be able to access the protected `c` member, the adaptors befriend
corresponding formatter specializations. Note that such specialization
may be disable if the container is formattable, in such case
specializations are unharmful.
As in the case of previous commits, the signatures of the user-facing parse
and format methods of the provided formatters deviate from the standard by
constraining types of parameters:
* _CharT is constrained __formatter::__char
* basic_format_parse_context<_CharT> for parse argument
* basic_format_context<_Out, _CharT> for format second argument
The standard specifies all above as unconstrained types. In particular
_CharT constrain, allow us to befriend all allowed specializations.
Furthermore the standard specifies these formatters as delegating to
formatter<ranges::ref_view<const? _Container>, charT>, which in turn
delegates to range_formatter. This patch avoids one level of indirection,
and dependency of ranges::ref_view. This is technically observable if
user specializes formatter<std::ref_view<PD>> where PD is program defined
container, but I do not think this is the case worth extra indirection.
This patch also moves the formattable and it's dependencies to the formatfwd.h,
so it can be used in adapters formatters, without including format header.
The definition of _Iter_for is changed from alias to denoting
back_insert_iterator<basic_string<_CharT>>, to struct with type nested typedef
that points to same type, that is forward declared.
PR libstdc++/109162
libstdc++-v3/ChangeLog:
* include/bits/formatfwd.h (__format::__parsable_with)
(__format::__formattable_with, __format::__formattable_impl)
(__format::__has_debug_format, __format::__const_formattable_range)
(__format::__maybe_const_range, __format::__maybe_const)
(std::formattable): Moved from std/format.
(__format::Iter_for, std::range_formatter): Forward declare.
* include/bits/stl_queue.h (std::formatter): Forward declare.
(std::queue, std::priority_queue): Befriend formatter specializations.
* include/bits/stl_stack.h (std::formatter): Forward declare.
(std::stack): Befriend formatter specializations.
* include/std/format (__format::_Iter_for): Define as struct with
(__format::__parsable_with, __format::__formattable_with)
(__format::__formattable_impl, __format::__has_debug_format)
(_format::__const_formattable_range, __format::__maybe_const_range)
(__format::__maybe_const, std::formattable): Moved to bits/formatfwd.h.
(std::range_formatter): Remove default argument specified in declaration
in bits/formatfwd.h.
* include/std/queue: Include bits/version.h before bits/stl_queue.h.
(formatter<queue<_Tp, _Container, _Compare>, _CharT>)
(formatter<priority_queue<_Tp, _Container, _Compare>, _CharT>): Define.
* include/std/stack: Include bits/version.h before bits/stl_stack.h
(formatter<stack<_Tp, _Container, _Compare>, _CharT>): Define.
* testsuite/std/format/ranges/adaptors.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
(cherry picked from commit 3d808ede38b959d283baaed1864434392eeb41e3)
Jakub Jelinek [Thu, 24 Apr 2025 21:44:28 +0000 (23:44 +0200)]
s390: Allow 5+ argument tail-calls in some special cases [PR119873]
protobuf (and therefore firefox too) currently doesn't build on s390*-linux.
The problem is that it uses [[clang::musttail]] attribute heavily, and in
llvm (IMHO llvm bug) [[clang::musttail]] calls with 5+ arguments on
s390*-linux are silently accepted and result in a normal non-tail call.
In GCC we just reject those because the target hook refuses to tail call it
(IMHO the right behavior).
Now, the reason why that happens is as s390_function_ok_for_sibcall attempts
to explain, the 5th argument (assuming normal <= wordsize integer or pointer
arguments, nothing that needs 2+ registers) is passed in %r6 which is not
call clobbered, so we can't do tail call when we'd have to change content
of that register and then caller would assume %r6 content didn't change and
use it again.
In the protobuf case though, the 5th argument is always passed through
from the caller to the musttail callee unmodified, so one can actually
emit just jg tail_called_function or perhaps tweak some registers but
keep %r6 untouched, and in that case I think it is just fine to tail call
it (at least unless the stack slots used for 6+ argument can't be modified
by the callee in the ABI and nothing checks for that).
So, the following patch checks for this special case, where the argument
which uses %r6 is passed in a single register and it is passed default
definition of SSA_NAME of a PARM_DECL with the same DECL_INCOMING_RTL.
It won't really work at -O0 but should work for -O1 and above, at least when
one doesn't really try to modify the parameter conditionally and hope it will
be optimized away in the end.
2025-04-24 Jakub Jelinek <jakub@redhat.com>
Stefan Schulze Frielinghaus <stefansf@gcc.gnu.org>
PR target/119873
* config/s390/s390.cc (s390_call_saved_register_used): Don't return
true if default definition of PARM_DECL SSA_NAME of the same register
is passed in call saved register.
(s390_function_ok_for_sibcall): Adjust comment.
* gcc.target/s390/pr119873-1.c: New test.
* gcc.target/s390/pr119873-2.c: New test.
* gcc.target/s390/pr119873-3.c: New test.
* gcc.target/s390/pr119873-4.c: New test.
Jakub Jelinek [Tue, 22 Apr 2025 19:27:28 +0000 (21:27 +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 <jakub@redhat.com>
PR target/119327
* config/rs6000/rs6000.cc (rs6000_can_inline_p): Ignore also
OPTION_MASK_SAVE_TOC_INDIRECT differences.
Jakub Jelinek [Fri, 25 Apr 2025 08:23:15 +0000 (10:23 +0200)]
Adjust gcc_release for id href web transformations
We now have some script which transforms e.g.
<h2 id="15.1">GCC 15.1</h2>
line in gcc-15/changes.html to
<h2 id="15.1"><a href="#15.1">GCC 15.1</a></h2>
This unfortunately breaks the gcc_release script, which looks for
GCC 15.1 appearing in gennews after optional blanks from the start of
the line in the NEWS file, which is no longer the case, there is
[129]GCC 15.1
or something like that with an URL later on
129. https://gcc.gnu.org/gcc-15/changes.html#15.1
The following patch handles this.
2025-04-25 Jakub Jelinek <jakub@redhat.com>
* gcc_release: Allow optional \[[0-9]+\] before GCC major.minor
in the NEWS file.
opts.cc Simplify handling of explicit -flto-partition= and -fipa-reorder-for-locality
The handling of an explicit -flto-partition= and -fipa-reorder-for-locality
should be simpler. No need to have a new default option. We can use opts_set
to check if -flto-partition is explicitly set and use that information in the
error handling.
Remove -flto-partition=default and update accordingly.
Bootstrapped and tested on aarch64-none-linux-gnu.
This non-standard optimization breaks real-world code that expects the
result of std::projected to always (be a class type and) have a value_type
member, which isn't true for e.g. I=int*, so revert it for now.
aarch64: Update FP8 dependencies for -mcpu=olympus
We had not noticed that after g:299a8e2dc667e795991bc439d2cad5ea5bd379e2 the
FP8FMA and FP8DOT4 features aren't implied by FP8FMA. The intent is for
-mcpu=olympus to support all of them.
Fix the definition to include the relevant sub-features explicitly.
testsuite: XFAIL predcom-8.c on aarch64 [PR118407]
gcc.dg/tree-ssa/predcom-8.c fails on aarch64 for the reasons discussed
in the PR trail. The fix didn't make it into GCC 15, so this patch
XFAILs the test instead.
Other targets might benefit from an XFAIL too, but people who work on
those targets would be better placed to know the right conditions.
gcc/testsuite/
PR tree-optimization/118407
* gcc.dg/tree-ssa/predcom-8.c: Add XFAIL for aarch64.
cobol: Restrict COBOL to supported Linux arches [PR119217]
The COBOL frontend is currently built on all x86_64 and aarch64 hosts
although the code contains some Linux/glibc specifics that break the build
e.g. on Solaris/amd64.
Document locality partitioning params in invoke.texi
Filip Kastl pointed out that contrib/check-params-in-docs.py complains
about params not documented in invoke.texi, so this patch adds the short
explanation from params.opt for these to the invoke.texi section.
Thanks for the reminder.
testsuite: Use sigsetjmp in gcc.misc-tests/gcov-31.c
The gcc.misc-tests/gcov-31.c test FAILs on Solaris and Darwin:
FAIL: gcc.misc-tests/gcov-31.c (test for excess errors)
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.misc-tests/gcov-31.c:23:5:
error: implicit declaration of function '__sigsetjmp'; did you mean
'sigsetjmp'? [-Wimplicit-function-declaration]
__sigsetjmp is a Linux/glibc implementation detail. Other tests just
use sigsetjmp directly, so this patch follows suit.
Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-pc-linux-gnu, and x86_64-apple-darwin24.4.0.
projects / thirdparty / gcc.git / log
