H.J. Lu [Tue, 14 Mar 2023 18:41:51 +0000 (11:41 -0700)]
x86: Properly find the maximum stack slot alignment
Don't assume that stack slots can only be accessed by stack or frame
registers. We first find all registers defined by stack or frame
registers. Then check memory accesses by such registers, including
stack and frame registers.
gcc/
PR target/109780
PR target/109093
* config/i386/i386.cc (ix86_update_stack_alignment): New.
(ix86_find_all_reg_use_1): Likewise.
(ix86_find_all_reg_use): Likewise.
(ix86_find_max_used_stack_alignment): Also check memory accesses
from registers defined by stack or frame registers.
Jakub Jelinek [Sat, 15 Feb 2025 23:45:21 +0000 (16:45 -0700)]
[PR tree-optimization/98028] Use relationship between operands to simplify SUB_OVERFLOW
So this is a fairly old regression, but with all the ranger work that's been
done, it's become easy to resolve.
The basic idea here is to use known relationships between two operands of a
SUB_OVERFLOW IFN to statically compute the overflow state and ultimately allow
turning the IFN into simple arithmetic (or for the tests in this BZ elide the
arithmetic entirely).
The regression example is when the two inputs are known equal. In that case
the subtraction will never overflow. But there's a few other cases we can
handle as well.
a == b -> never overflows
a > b -> never overflows when A and B are unsigned
a >= b -> never overflows when A and B are unsigned
a < b -> always overflows when A and B are unsigned
Bootstrapped and regression tested on x86, and regression tested on the usual
cross platforms.
This is Jakub's version of the vr-values.cc fix rather than Jeff's.
PR tree-optimization/98028
gcc/
* vr-values.cc (check_for_binary_op_overflow): Try to use a known
relationship betwen op0/op1 to statically determine overflow state.
gcc/testsuite
* gcc.dg/tree-ssa/pr98028.c: New test.
Harald Anlauf [Sat, 15 Feb 2025 19:36:15 +0000 (20:36 +0100)]
Fortran: passing of derived type to VALUE,OPTIONAL dummy argument [PR118080]
For scalar OPTIONAL dummy arguments with the VALUE attribute, gfortran
passes a hidden flag to denote presence or absence of the actual argument
for intrinsic types. Extend this treatment to derived type (user-defined
as well as from intrinsic module ISO_C_BINDING).
PR fortran/118080
gcc/fortran/ChangeLog:
* gfortran.texi: Adjust documentation.
* trans-decl.cc (create_function_arglist): Adjust to pass hidden
presence flag also for derived type dummies with VALUE,OPTIONAL
attribute.
* trans-expr.cc (gfc_conv_expr_present): Expect hidden presence
flag also for derived type dummies with VALUE,OPTIONAL attribute.
(conv_cond_temp): Adjust to allow derived types.
(conv_dummy_value): Extend to handle derived type dummies with
VALUE,OPTIONAL attribute.
(gfc_conv_procedure_call): Adjust for actual arguments passed to
derived type dummies with VALUE,OPTIONAL attribute.
* trans-types.cc (gfc_get_function_type): Adjust fndecl for
hidden presence flag.
Jerry DeLisle [Fri, 14 Feb 2025 04:19:56 +0000 (20:19 -0800)]
Fortran: gfortran allows type(C_ptr) in I/O list
Before this patch, gfortran was accepting invalid use of
type(c_ptr) in I/O statements. The fix affects several
existing test cases so no new test case needed.
Existing tests were modified to pass by either using the
transfer function to convert to an acceptable value or
using an assignment to a like type (non-I/O).
PR fortran/117430
gcc/fortran/ChangeLog:
* resolve.cc (resolve_transfer): Change gfc_notify_std to
gfc_error.
gcc/testsuite/ChangeLog:
* gfortran.dg/c_loc_test_17.f90: Use an assignment rather than
PRINT.
* gfortran.dg/c_ptr_tests_10.f03: Use a transfer function.
* gfortran.dg/c_ptr_tests_16.f90: Use an assignment.
* gfortran.dg/c_ptr_tests_9.f03: Use a transfer function.
* gfortran.dg/init_flag_17.f90: Likewise.
* gfortran.dg/pr32601_1.f03: Use an assignment.
Robin Dapp [Sat, 15 Feb 2025 16:21:34 +0000 (09:21 -0700)]
[PATCH] RISC-V: Fix some widen-complicate tests.
this patch adds two bridge patterns for combine in order to fix the
widen-complicate tests that regressed since GCC 14.
They key is to allow combination with a ephemeral binary-operation insn
that widens its first operand. This can subsequently be combined two
a double-widening insn. If the combination doesn't happen we fall back
to the original non-combined two insns. We have been doing the same
thing for multiply-add patterns for a while.
There are still remaining tests of a similar kind that fail. The issue
there is indeed that combine (now) lacks the capability to continue in
cases where there is no apparent local progress but two or three
seemingly no-progress combinations would help us get a better "global" result.
late_combine cannot rescue us here either because it only performs a
propagation if the source can be propagated into all its uses which is
not the case here. What we might need to do is create internal functions
for those widening operations and combine/simplify at gimple-level already.
I have done testing on rv64gcv_zvl512b but on an older local commit.
Curious what the CI has to say about it now.
Regards
Robin
gcc/ChangeLog:
* config/riscv/autovec-opt.md
(*single_widen_first_<any_widen_binop:optab><any_extend:su><mode>):
New combine "bridge" pattern.
Keith Packard [Sat, 15 Feb 2025 16:17:41 +0000 (09:17 -0700)]
[PATCH] rx: allow cmpstrnsi len to be zero
The SCMPU instruction doesn't change the C and Z flags when the
incoming length is zero, which means the insn will produce a
value based upon the existing flag values.
As a quick kludge, adjust these flags to ensure a zero result in this
case.
David Malcolm [Sat, 15 Feb 2025 13:18:19 +0000 (08:18 -0500)]
sarif-replay: handle the 'fixes' property (§3.27.30)
This adds support to sarif-replay to display fix-it hints
stored in GCC's SARIF output.
gcc/ChangeLog:
* libsarifreplay.cc (sarif_replayer::handle_result_obj): Call
handle_fix_object if we see a single-element "fixes" array.
(sarif_replayer::handle_fix_object): New.
(sarif_replayer::handle_artifact_change_object): New.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-1.sarif: New test.
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-2.sarif: New test.
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-3.sarif: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Sat, 15 Feb 2025 13:15:58 +0000 (08:15 -0500)]
sarif-replay: handle relatedLocations without messages (§3.27.22)
Given the .sarif output from e.g.:
too-many-arguments.c: In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1
14 | fn_a (42);
| ^~~~ ~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
the underlining of the stray argument (the "42") is captured in
'relatedLocations' (§3.27.22) but previously sarif-replay would not
display this:
In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1 [error]
14 | fn_a (42);
| ^~~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
With this patch sarif-replay handles the relatedLocations element as
a secondary location in libgdiagnostics, and correctly underlines
the "42":
In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1 [error]
14 | fn_a (42);
| ^~~~ ~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
gcc/ChangeLog:
* libsarifreplay.cc (sarif_replayer::handle_result_obj): Treat any
relatedLocations without messages as secondary ranges within the
diagnostic. Doing so requires stashing the notes until after
the diagnostic has been finished, so that relatedLocations can be
walked in one pass.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/unlabelled-secondary-locations.sarif:
New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Sat, 15 Feb 2025 13:13:06 +0000 (08:13 -0500)]
sarif-replay: display annotations as labelled ranges (§3.28.6) [PR118881]
In our .sarif output from e.g.:
bad-binary-op.c: In function ‘test_4’:
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’})
19 | return callee_4a () + callee_4b ();
| ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
| | |
| | T {aka struct t}
| S {aka struct s}
the labelled ranges are captured in the 'annotations' property of the
'location' object (§3.28.6).
However sarif-replay emits just:
In function 'test_4':
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’}) [error]
19 | return callee_4a () + callee_4b ();
| ^
missing the labelled ranges.
This patch adds support to sarif-replay for the 'annotations' property;
with this patch we emit:
In function 'test_4':
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’}) [error]
19 | return callee_4a () + callee_4b ();
| ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
| | |
| | T {aka struct t}
| S {aka struct s}
thus showing the labelled ranges.
Doing so requires adding a new entrypoint to libgdiagnostics:
diagnostic_physical_location_get_file
Given that we haven't yet released a stable version and that
sarif-replay is built together with libgdiagnostics I didn't
bother updating the ABI version.
gcc/ChangeLog:
PR sarif-replay/118881
* doc/libgdiagnostics/topics/physical-locations.rst: Add
diagnostic_physical_location_get_file.
* libgdiagnostics++.h (physical_location::get_file): New wrapper.
(diagnostic::add_location): Likewise.
* libgdiagnostics.cc (diagnostic_manager::get_file_by_name): New.
(diagnostic_physical_location::get_file): New.
(diagnostic_physical_location_get_file): New.
* libgdiagnostics.h (diagnostic_physical_location_get_file): New.
* libgdiagnostics.map (diagnostic_physical_location_get_file): New.
* libsarifreplay.cc (class annotation): New.
(add_any_annotations): New.
(sarif_replayer::handle_result_obj): Collect vectors of
annotations in the calls to handle_location_object and apply them
to "err" and to "note" as appropriate.
(sarif_replayer::handle_thread_flow_location_object): Pass nullptr
for annotations.
(sarif_replayer::handle_location_object): Handle §3.28.6
"annotations" property, using it to populate a new
"out_annotations" param.
gcc/testsuite/ChangeLog:
PR sarif-replay/118881
* sarif-replay.dg/2.1.0-valid/3.28.6-annotations-1.sarif: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Nathaniel Shead [Wed, 12 Feb 2025 08:15:22 +0000 (19:15 +1100)]
c++/modules: Don't treat template parameters as TU-local [PR118846]
There are two separate issues making various template parameters behave
as if they were TU-local.
Firstly, the TU-local detection code uses WILDCARD_TYPE_P to check for
types that are not yet concrete; for some reason UNBOUND_CLASS_TEMPLATE
is not on that list. I don't see any particular reason why it shouldn't
be, so this patch adds it; this may solve other latent issues as well.
Secondly, the TEMPLATE_DECL for a type with expressions involving
TEMPLATE_TEMPLATE_PARM_Ps is currently always constrained to internal
linkage, because the result does not have TREE_PUBLIC set. Rather than
messing with TREE_PUBLIC here, I think rather we just should ensure that
we only attempt to constrain visiblity of templates of type, variable,
or function decls.
PR c++/118846
gcc/cp/ChangeLog:
* cp-tree.h (WILDCARD_TYPE_P): Include UNBOUND_CLASS_TEMPLATE.
* decl2.cc (min_vis_expr_r): Don't assume a TEMPLATE_DECL will
be a function or variable.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr118846_a.C: New test.
* g++.dg/modules/pr118846_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jason Merrill [Sat, 15 Feb 2025 09:48:17 +0000 (10:48 +0100)]
c++: NRVO, constexpr, lambda [PR118053]
Here during constant evaluation we encounter a VAR_DECL with DECL_VALUE_EXPR
of the RESULT_DECL, where the latter has been adjusted for
pass-by-invisible-reference. We already had the code to deal with this, we
just need to use it in the non-capture case of DECL_VALUE_EXPR as well.
PR c++/118053
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Generalize
DECL_VALUE_EXPR invisiref handling.
Jonathan Wakely [Thu, 13 Feb 2025 00:26:27 +0000 (00:26 +0000)]
libstdc++: Simplify and comment std::jthread extension [PR100612]
Use a requires-clause on the partial specialization of the
__pmf_expects_stop_token variable template, which is used for the
extension that allows constructing std::jthread with a
pointer-to-member-function that accepts a std::stop_token argument.
Also add a comment referring to the related Bugzilla PR.
Jonathan Wakely [Wed, 12 Feb 2025 19:43:05 +0000 (19:43 +0000)]
libstdc++: Add conditional noexcept to remaining range access functions
Add conditional noexcept to the remaining range access functions that
were not changed in r15-5669-g8692cb10e82e72. This is now being proposed
for C++26 by P3623R0 (not published yet).
libstdc++-v3/ChangeLog:
* include/bits/range_access.h (rbegin, rend, crbegin, crend):
Add conditional noexcept, as per P3623R0.
* testsuite/24_iterators/headers/iterator/range_access.cc: Add
noexcept-specifier to rbegin, rend, crbegin and crend
declarations.
Jonathan Wakely [Wed, 12 Feb 2025 19:52:01 +0000 (19:52 +0000)]
libstdc++: Combine three tests into one
Instead of a test with { target c++11_only } and another with
c++14_only and another with c++17 we can have a single test that uses
{ target c++11 }. This avoids needing to make edits to three very
similar tests.
Also fix the signatures for std::cbegin and std::cend which had the
wrong expression in the trailing-return-type and were missing their
constexpr and conditional noexcept (which were always present even in
C++14). That was wrong in two files, but now only needs to be fixed in
one place!
Thomas Koenig [Sat, 15 Feb 2025 10:38:05 +0000 (11:38 +0100)]
Fix PR 118884, Lapack build failure.
The fix for PR 118845 introduced new checks, which in turn exposed
a case where the typespec information on a symbol generated symbol
was not set. This led to an apparent type of BT_UNKNOWN, and hence
an error. Fixed as obvoius and simple.
gcc/fortran/ChangeLog:
* frontend-passes.cc (check_externals_procedure): Copy
typespec from old to new symbol.
Thomas Schwinge [Mon, 19 Dec 2022 14:05:53 +0000 (15:05 +0100)]
nvptx: Tag 'gcc/config/nvptx/nvptx.cc:nvptx_record_needed_fndecl' as 'static'
As of Subversion r231013 (Git commit 00e5241831c1227615a45b7bcba29c393671cb3f)
"[PTX] Another libcall patch", only used 'nvptx_record_needed_fndecl' is
locally.
gcc/
* config/nvptx/nvptx.cc (nvptx_record_needed_fndecl): Tag as
'static'.
Andrew Pinski [Thu, 13 Feb 2025 22:10:06 +0000 (14:10 -0800)]
libstdc++: Improve list assumption after constructor [PR118865]
The code example here does:
```
if (begin == end) __builtin_unreachable();
std::list nl(begin, end);
for (auto it = nl.begin(); it != nl.end(); it++)
{
...
}
/* Remove the first element of the list. */
nl.erase(nl.begin());
```
And we get a warning because because we jump threaded the case were we
think the list was empty from the for loop BUT we populated it without
an empty array. So can help the compiler here by adding that after initializing
the list with non empty array, that the list will not be empty either.
This is able to remove the -Wfree-nonheap-object warning in the first reduced
testcase (with the fix for `begin == end` case added) in the PR 118865; the second
reduced testcase has been filed off as PR 118867.
Bootstrapped and tested on x86_64-linux-gnu.
libstdc++-v3/ChangeLog:
PR libstdc++/118865
* include/bits/stl_list.h (_M_initialize_dispatch): Add an
unreachable if the iterator was not empty that the list will
now be not empty.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Georg-Johann Lay [Fri, 14 Feb 2025 17:53:29 +0000 (18:53 +0100)]
AVR: target/118878 - Don't ICE on result from paradoxical reg's alloc.
After register allocation, paradoxical subregs may become something
like r20:SI += r22:SI which doesn't make much sense as assembly code.
Hence avr_out_plus_1() used to ICE on such code. However, paradoxical
subregs appear to be a common optimization device (instead of proper
mode demotion).
PR target/118878
gcc/
* config/avr/avr.cc (avr_out_plus_1): Don't ICE on result of
paradoxical reg's register allocation.
gcc/testsuite/
* gcc.target/avr/torture/pr118878.c: New test.
Thomas Schwinge [Tue, 11 Feb 2025 16:23:28 +0000 (17:23 +0100)]
GCN: Set 'UI_TARGET' for 'TARGET_EXCEPT_UNWIND_INFO' [PR94282, PR113331]
In commit 7f1989249e25af6fc0f124452efa24b3796b767a
"[gcn] Set 'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO' [PR94282]", we've copied
the 'UI_NONE' idea from nvptx to GCN.
I understand the intention of using 'UI_NONE' like this, and it happens to work
in a lot of cases, but there are ICEs elsewhere: code paths where we run into
'internal compiler error: in get_personality_function, at expr.cc:13512':
13494 /* Extracts the personality function of DECL and returns the corresponding
13495 libfunc. */
13496
13497 rtx
13498 get_personality_function (tree decl)
13499 {
13500 tree personality = DECL_FUNCTION_PERSONALITY (decl);
13501 enum eh_personality_kind pk;
13502
13503 pk = function_needs_eh_personality (DECL_STRUCT_FUNCTION (decl));
13504 if (pk == eh_personality_none)
13505 return NULL;
13506
13507 if (!personality
13508 && pk == eh_personality_any)
13509 personality = lang_hooks.eh_personality ();
13510
13511 if (pk == eh_personality_lang)
13512 gcc_assert (personality != NULL_TREE);
13513
13514 return XEXP (DECL_RTL (personality), 0);
13515 }
..., where 'lang_hooks.eh_personality ()' ends up calling
'gcc/expr.cc:build_personality_function', and we 'return NULL;' for 'UI_NONE':
13448 /* Build a decl for a personality function given a language prefix. */
13449
13450 tree
13451 build_personality_function (const char *lang)
13452 {
13453 const char *unwind_and_version;
13454 tree decl, type;
13455 char *name;
13456
13457 switch (targetm_common.except_unwind_info (&global_options))
13458 {
13459 case UI_NONE:
13460 return NULL;
[...]
(Comparing to nvptx' current use of 'UI_NONE', this problem (ICEs mentioned
above) is way more prevalent for GCN.)
The GCC internals documentation indeed states, 'gcc/doc/tm.texi':
@deftypefn {Common Target Hook} {enum unwind_info_type} TARGET_EXCEPT_UNWIND_INFO (struct gcc_options *@var{opts})
This hook defines the mechanism that will be used for exception handling
by the target. If the target has ABI specified unwind tables, the hook
should return @code{UI_TARGET}. If the target is to use the
@code{setjmp}/@code{longjmp}-based exception handling scheme, the hook
should return @code{UI_SJLJ}. If the target supports DWARF 2 frame unwind
information, the hook should return @code{UI_DWARF2}.
A target may, if exceptions are disabled, choose to return @code{UI_NONE}.
This may end up simplifying other parts of target-specific code. [...]
Here, note: "if exceptions are disabled" (meaning: '-fno-exceptions' etc.) may
"return @code{UI_NONE}". That's what other back ends do with code like:
/* For simplicity elsewhere in this file, indicate that all unwind
info is disabled if we're not emitting unwind tables. */
if (!opts->x_flag_exceptions && !opts->x_flag_unwind_tables)
return UI_NONE;
else
return UI_TARGET;
The corresponding "simplifying other parts of target-specific code"/
"simplicity elsewhere" would then be the early returns from
'TARGET_ASM_UNWIND_EMIT', 'ARM_OUTPUT_FN_UNWIND', etc. for
'TARGET_EXCEPT_UNWIND_INFO != UI_TARGET' (that is, for 'UI_NONE').
From the documentation (and implementation), however, it does *not* follow that
if a target doesn't implement support for exception handling, it may just set
'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO'.
Therefore, switch to 'UI_TARGET', allocating a "fake" 'exception_section'.
With that, all these 'internal compiler error: in get_personality_function'
test cases turn into PASS, or UNSUPPORTED ('exception handling not supported'),
or re-classify into a few other, already known issues. And, this change also
happens to resolve the class of errors identified in GCC PR113331
"AMDGCN: Compilation failure due to duplicate .LEHB<n>/.LEHE<n> symbols".
(In case that use of 'UI_NONE' like originally intended really makes sense, and
is preferable over this 'UI_TARGET' solution, then more work will be necessary
for implementing the missing parts, where 'UI_NONE' currently isn't handled.)
I understand the intention of using 'UI_NONE' like this, and it happens to work
in a lot of cases, but there are ICEs elsewhere: code paths where we run into
'internal compiler error: in get_personality_function, at expr.cc:13512':
13494 /* Extracts the personality function of DECL and returns the corresponding
13495 libfunc. */
13496
13497 rtx
13498 get_personality_function (tree decl)
13499 {
13500 tree personality = DECL_FUNCTION_PERSONALITY (decl);
13501 enum eh_personality_kind pk;
13502
13503 pk = function_needs_eh_personality (DECL_STRUCT_FUNCTION (decl));
13504 if (pk == eh_personality_none)
13505 return NULL;
13506
13507 if (!personality
13508 && pk == eh_personality_any)
13509 personality = lang_hooks.eh_personality ();
13510
13511 if (pk == eh_personality_lang)
13512 gcc_assert (personality != NULL_TREE);
13513
13514 return XEXP (DECL_RTL (personality), 0);
13515 }
..., where 'lang_hooks.eh_personality ()' ends up calling
'gcc/expr.cc:build_personality_function', and we 'return NULL;' for 'UI_NONE':
13448 /* Build a decl for a personality function given a language prefix. */
13449
13450 tree
13451 build_personality_function (const char *lang)
13452 {
13453 const char *unwind_and_version;
13454 tree decl, type;
13455 char *name;
13456
13457 switch (targetm_common.except_unwind_info (&global_options))
13458 {
13459 case UI_NONE:
13460 return NULL;
[...]
(Comparing to nvptx' current use of 'UI_NONE', this problem (ICEs mentioned
above) is way more prevalent for GCN.)
The GCC internals documentation indeed states, 'gcc/doc/tm.texi':
@deftypefn {Common Target Hook} {enum unwind_info_type} TARGET_EXCEPT_UNWIND_INFO (struct gcc_options *@var{opts})
This hook defines the mechanism that will be used for exception handling
by the target. If the target has ABI specified unwind tables, the hook
should return @code{UI_TARGET}. If the target is to use the
@code{setjmp}/@code{longjmp}-based exception handling scheme, the hook
should return @code{UI_SJLJ}. If the target supports DWARF 2 frame unwind
information, the hook should return @code{UI_DWARF2}.
A target may, if exceptions are disabled, choose to return @code{UI_NONE}.
This may end up simplifying other parts of target-specific code. [...]
Here, note: "if exceptions are disabled" (meaning: '-fno-exceptions' etc.) may
"return @code{UI_NONE}". That's what other back ends do with code like:
/* For simplicity elsewhere in this file, indicate that all unwind
info is disabled if we're not emitting unwind tables. */
if (!opts->x_flag_exceptions && !opts->x_flag_unwind_tables)
return UI_NONE;
else
return UI_TARGET;
The corresponding "simplifying other parts of target-specific code"/
"simplicity elsewhere" would then be the early returns from
'TARGET_ASM_UNWIND_EMIT', 'ARM_OUTPUT_FN_UNWIND', etc. for
'TARGET_EXCEPT_UNWIND_INFO != UI_TARGET' (that is, for 'UI_NONE').
From the documentation (and implementation), however, it does *not* follow that
if a target doesn't implement support for exception handling, it may just set
'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO'.
Therefore, switch (back) to 'UI_TARGET', implementing some basic support for
'exception_section': discard (via a PTX comment block) whatever GCC writes into
it.
With that, all these 'internal compiler error: in get_personality_function'
test cases turn into PASS, or UNSUPPORTED ('exception handling not supported'),
or re-classify into a few other, already known issues.
(In case that use of 'UI_NONE' like originally intended really makes sense, and
is preferable over this 'UI_TARGET' solution, then more work will be necessary
for implementing the missing parts, where 'UI_NONE' currently isn't handled.)
Thomas Schwinge [Wed, 12 Feb 2025 23:35:31 +0000 (00:35 +0100)]
nvptx: Sanity-check 'init_frag' state
The 'init_frag' machinery is used by 'nvptx_assemble_integer' (via
'TARGET_ASM_INTEGER'), 'nvptx_output_skip' (via 'ASM_OUTPUT_SKIP'),
'nvptx_output_ascii' (via 'ASM_OUTPUT_ASCII'). But, it's not obvious that
these are called only when that machinery is active (and in a consistent
state), which it only is in 'nvptx_output_aligned_decl' (via
'ASM_OUTPUT_ALIGNED_DECL_COMMON', or 'ASM_OUTPUT_ALIGNED_DECL_LOCAL'), or in
'nvptx_assemble_undefined_decl' (via 'TARGET_ASM_ASSEMBLE_UNDEFINED_DECL'), or
within a region started by 'nvptx_assemble_decl_begin' (via
'nvptx_asm_declare_constant_name' (via 'TARGET_ASM_DECLARE_CONSTANT_NAME'), or
via 'nvptx_declare_object_name' (via 'ASM_DECLARE_OBJECT_NAME')) and ended by
'nvptx_assemble_decl_end' (via 'TARGET_ASM_DECL_END').
And indeed, in a GCC/nvptx offloading configuration, we then find that
'nvptx_output_skip' (via 'ASM_OUTPUT_SKIP') is getting called in inconsistent
'init_frag' state, in 'gcc/varasm.cc', via 'assemble_zeros', from
'output_object_block', to "Move to the object's offset, padding with zeros".
Supposedly, this didn't cause any damage, but we now handle it explicitly.
(..., and the question remains whether such "padding" etc. shouldn't actually
be attempted for targets like nvptx.)
gcc/
* config/nvptx/nvptx.cc (init_frag): New 'bool active' member.
(output_init_frag, nvptx_assemble_value, nvptx_assemble_integer)
(nvptx_output_skip, nvptx_assemble_decl_begin)
(nvptx_assemble_decl_end): Sanity-check its state.
Richard Biener [Fri, 14 Feb 2025 13:48:41 +0000 (14:48 +0100)]
tree-optimization/118852 - wrong code with 502.gcc_r
502.gcc_r when built with -fprofile-generate exposes a SLP discovery
issue where an IV forced live due to early break is not properly
discovered if its latch def is part of a different IVs SSA cycle.
To mitigate this we have to make sure to create an SLP instance
for the original IV. Ideally we'd handle all vect_induction_def
the same but this is left for next stage1.
PR tree-optimization/118852
* tree-vect-slp.cc (vect_analyze_slp): For early-break
forced-live IVs make sure we create an appropriate
entry into the SLP graph.
Jason Merrill [Fri, 14 Feb 2025 09:53:01 +0000 (10:53 +0100)]
c++: extended temp cleanups [PR118856]
A later testcase in PR118856 highlights a preexisting problem with multiple
reference-extended temporaries in a single declaration; if initializing a
later one throws, the cleanup for the earlier one is not in scope yet.
Let's deal with this by keeping a dummy TARGET_EXPR to hold the EH cleanup
until all other initialization is complete. See the comment for various
other considered approaches.
We now avoid extending TARGET_EXPRs with CLEANUP_EH_ONLY set; all such
TARGET_EXPRs were already only internal iterator/flag variables that don't
want to be extended, as they are dead after initialization is complete even
if other temporaries are extended. But some other internal temporaries did
not have the flag set because they don't have TARGET_EXPR_CLEANUP; I
introduce a get_internal_target_expr function to set the flag rather than
directly set the flag (and add a comment) in such places. The places
changed to call get_internal_target_expr either already set the flag, or
have no cleanup at all.
PR c++/118856
gcc/cp/ChangeLog:
* call.cc (set_up_extended_ref_temp): Retain a TARGET_EXPR for
cleanups if something later in initialization throws.
(extend_temps_r): Don't extend eliding or EH-only TARGET_EXPRs.
* cp-tree.h (get_internal_target_expr): Declare.
* tree.cc (get_internal_target_expr): New.
* decl.cc (cp_finish_decomp, expand_static_init): Use it.
* except.cc (build_throw): Likewise.
* init.cc (build_new_1, build_vec_init, build_delete): Likewise.
(build_vec_delete): Likewise.
* typeck2.cc (maybe_push_temp_cleanup): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/eh/ref-temp3.C: New test.
* g++.dg/eh/ref-temp4.C: New test.
Jonathan Wakely [Wed, 12 Feb 2025 18:33:46 +0000 (18:33 +0000)]
libstdc++: Fix more unqualified uses of make_pair
There are some unqualified calls to make_pair in Parallel Mode. Fix
these by just using a qualified call, because it's simpler and I don't
care about this code much.
libstdc++-v3/ChangeLog:
* include/parallel/algobase.h (__mismatch_switch): Qualify calls
to make_pair to avoid ADL.
Jonathan Wakely [Wed, 12 Feb 2025 18:30:21 +0000 (18:30 +0000)]
libstdc++: Fix use of make_pair that used ADL
_Rb_tree::_M_equal_range calls make_pair unqualified, which means it
uses ADL. As the new testcase shows, this can find something other than
std::make_pair. Rather than just changing it to use a qualified call,
remove the use of make_pair entirely. We don't need to deduce any types
here, we know exactly what type of std::pair we want to construct, so do
that explicitly.
libstdc++-v3/ChangeLog:
* include/bits/stl_tree.h (_Rb_tree::_M_equal_range): Replace
unqualified call to make_pair with explicit construction of
std::pair.
* testsuite/23_containers/set/operations/equal_range_adl.cc:
New test.
libstdc++: Conditionally use floating-point fetch_add builtins
- Some hardware has support for floating point atomic fetch_add (and
similar).
- There are existing compilers targetting this hardware that use
libstdc++ -- e.g. NVC++.
- Since the libstdc++ atomic<float>::fetch_add and similar is written
directly as a CAS loop these compilers can not emit optimal code when
seeing such constructs.
- I hope to use __atomic_fetch_add builtins on floating point types
directly in libstdc++ so these compilers can emit better code.
- Clang already handles some floating point types in the
__atomic_fetch_add family of builtins.
- In order to only use this when available, I originally thought I could
check against the resolved versions of the builtin in a manner
something like `__has_builtin(__atomic_fetch_add_<fp-suffix>)`.
I then realised that clang does not expose resolved versions of these
atomic builtins to the user.
From the clang discourse it was suggested we instead use SFINAE (which
clang already supports).
- I have recently pushed a patch for allowing the use of SFINAE on
builtins: r15-6042-g9ed094a817ecaf
Now that patch is committed, this patch does not change what happens
for GCC, while it uses the builtin for codegen with clang.
- I have previously sent a patchset upstream adding the ability to use
__atomic_fetch_add and similar on floating point types.
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/668754.html
Once that patchset is upstream (plus the automatic linking of
libatomic as Joseph pointed out in the email below
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665408.html )
then current GCC should start to use the builtin branch added in this
patch.
So *currently*, this patch allows external compilers (NVC++ in
particular) to generate better code, and similarly lets clang understand
the operation better since it maps to a known builtin.
I hope that by GCC 16 this patch would also allow GCC to understand the
operation better via mapping to a known builtin.
libstdc++-v3/ChangeLog:
* include/bits/atomic_base.h (__atomic_fetch_addable): Define
new concept.
(__atomic_impl::__fetch_add_flt): Use new concept to make use of
__atomic_fetch_add when available.
(__atomic_fetch_subtractable, __fetch_sub_flt): Likewise.
(__atomic_add_fetchable, __add_fetch_flt): Likewise.
(__atomic_sub_fetchable, __sub_fetch_flt): Likewise.
Signed-off-by: Matthew Malcomson <mmalcomson@nvidia.com> Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
where the return type of value should be 'int &' since '(val)' is an
expression, not a name, and decltype(auto) performs the type deduction
using the decltype rules.
The problem is that we weren't propagating REF_PARENTHESIZED_P
correctly: the return value of finish_non_static_data_member in this
test was a REFERENCE_REF_P, so we didn't set the flag. We should
use force_paren_expr like below.
PR c++/116379
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr) <COMPONENT_REF>: Use force_paren_expr to set
REF_PARENTHESIZED_P.
Jakub Jelinek [Fri, 14 Feb 2025 11:01:13 +0000 (12:01 +0100)]
tree: Fix up the DECL_VALUE_EXPR GC marking [PR118790]
The ggc_set_mark call in gt_value_expr_mark_2 is actually wrong, that
just marks the VAR_DECL itself, but doesn't mark the subtrees of it (type
etc.). So, I think we need to test gcc_marked_p for whether it is marked
or not, if not marked walk the DECL_VALUE_EXPR and then gt_ggc_mx mark
the VAR_DECL that was determined not marked and needs to be marked now.
One option would be to call gt_ggc_mx (t) right after the DECL_VALUE_EXPR
walking, but I'm a little bit worried that the subtree marking could mark
other VAR_DECLs (e.g. seen from DECL_SIZE or TREE_TYPE and the like) and
if they would be DECL_HAS_VALUE_EXPR_P we might not walk their
DECL_VALUE_EXPR anymore later.
So, the patch defers the gt_ggc_mx calls until we've walked all the
DECL_VALUE_EXPRs directly or indirectly connected to already marked
VAR_DECLs.
2025-02-14 Jakub Jelinek <jakub@redhat.com>
PR debug/118790
* tree.cc (struct gt_value_expr_mark_data): New type.
(gt_value_expr_mark_2): Don't call ggc_set_mark, instead check
ggc_marked_p. Treat data as gt_value_expr_mark_data * with pset
in it rather than address of the pset itself and push to be marked
VAR_DECLs into to_mark vec.
(gt_value_expr_mark_1): Change argument from hash_set<tree> *
to gt_value_expr_mark_data * and find pset in it.
(gt_value_expr_mark): Pass to traverse_noresize address of
gt_value_expr_mark_data object rather than hash_table<tree> and
for all entries in the to_mark vector after the traversal call
gt_ggc_mx.
Lulu Cheng [Tue, 10 Dec 2024 12:59:22 +0000 (20:59 +0800)]
LoongArch: Adjust the cost of ADDRESS_REG_REG.
After changing this cost from 1 to 3, the performance of spec2006
401 473 416 465 482 can be improved by about 2% on LA664.
Add option '-maddr-reg-reg-cost='.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Add
option '-maddr-reg-reg-cost='.
* config/loongarch/loongarch-def.cc
(loongarch_rtx_cost_data::loongarch_rtx_cost_data): Initialize
addr_reg_reg_cost to 3.
* config/loongarch/loongarch-opts.cc
(loongarch_target_option_override): If '-maddr-reg-reg-cost='
is not used, set it to the initial value.
* config/loongarch/loongarch-tune.h
(struct loongarch_rtx_cost_data): Add the member
addr_reg_reg_cost and its assignment function to the structure
loongarch_rtx_cost_data.
* config/loongarch/loongarch.cc (loongarch_address_insns):
Use la_addr_reg_reg_cost to set the cost of ADDRESS_REG_REG.
* config/loongarch/loongarch.opt: Regenerate.
* config/loongarch/loongarch.opt.urls: Regenerate.
* doc/invoke.texi: Add description of '-maddr-reg-reg-cost='.
Lulu Cheng [Tue, 11 Feb 2025 12:36:17 +0000 (20:36 +0800)]
LoongArch: After setting the compilation options, update the predefined macros.
PR target/118828
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (loongarch_pragma_target_parse):
Update the predefined macros.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/pr118828.c: New test.
* gcc.target/loongarch/pr118828-2.c: New test.
* gcc.target/loongarch/pr118828-3.c: New test.
* gcc.target/loongarch/pr118828-4.c: New test.
Lulu Cheng [Tue, 11 Feb 2025 12:05:13 +0000 (20:05 +0800)]
LoongArch: Split the function loongarch_cpu_cpp_builtins into two functions.
Split the implementation of the function loongarch_cpu_cpp_builtins into two parts:
1. Macro definitions that do not change (only considering 64-bit architecture)
2. Macro definitions that change with different compilation options.
gcc/ChangeLog:
* config/loongarch/loongarch-c.cc (builtin_undef): New macro.
(loongarch_cpu_cpp_builtins): Split to loongarch_update_cpp_builtins
and loongarch_define_unconditional_macros.
(loongarch_def_or_undef): New functions.
(loongarch_define_unconditional_macros): Likewise.
(loongarch_update_cpp_builtins): Likewise.
Richard Biener [Wed, 12 Feb 2025 13:18:06 +0000 (14:18 +0100)]
tree-optimization/90579 - avoid STLF fail by better optimizing
For the testcase in question which uses a fold-left vectorized
reduction of a reverse iterating loop we'd need two forwprop
invocations to first bypass the permute emitted for the reverse
iterating loop and then to decompose the vector load that only
feeds element extracts. The following moves the first transform
to a match.pd pattern and makes sure we fold the element extracts
when the vectorizer emits them so the single forwprop pass can
then pick up the vector load decomposition, avoiding the forwarding
fail that causes.
Moving simplify_bitfield_ref also makes forwprop remove the dead
VEC_PERM_EXPR via the simple-dce it uses - this was also
previously missing.
PR tree-optimization/90579
* tree-ssa-forwprop.cc (simplify_bitfield_ref): Move to
match.pd.
(pass_forwprop::execute): Adjust.
* match.pd (bit_field_ref (vec_perm ...)): New pattern
modeled after simplify_bitfield_ref.
* tree-vect-loop.cc (vect_expand_fold_left): Fold the
element extract stmt, combining it with the vector def.
Nathaniel Shead [Fri, 31 Jan 2025 12:01:15 +0000 (23:01 +1100)]
c++: Clear lambda scope for unattached member template lambdas
In r15-7202 we made lambdas between a template parameter scope and a
class/function/initializer be considered TU-local, in lieu of working
out how to mangle them to the succeeding declaration.
I neglected to clear any existing mangling on the template declaration
however; this means that such lambdas can occasionally get a lambda
scope, and will in general inherit the lambda scope of their
instantiation context (whatever that might be).
This patch ensures that the scope is cleared on the template declaration
as well.
gcc/cp/ChangeLog:
* lambda.cc (record_lambda_scope): Clear mangling scope for
otherwise unattached lambdas in class member templates.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval22.C: Add check that the primary
specialisation of the lambda is TU-local.
Nathaniel Shead [Fri, 31 Jan 2025 10:19:45 +0000 (21:19 +1100)]
c++: Fix mangling of lambas in static member template initializers [PR107741]
My fix for this issue in r15-7147 turns out to not be quite sufficient;
static member templates apparently go down a different code path and
need their own handling.
PR c++/107741
gcc/cp/ChangeLog:
* cp-tree.h (is_static_data_member_initialized_in_class):
Declare new predicate.
* decl2.cc (start_initialized_static_member): Push the
TEMPLATE_DECL when appropriate.
(is_static_data_member_initialized_in_class): New predicate.
(finish_initialized_static_member): Use it.
* lambda.cc (record_lambda_scope): Likewise.
* parser.cc (cp_parser_init_declarator): Start the member decl
early for static members so that lambda scope is set.
(cp_parser_template_declaration_after_parameters): Don't
register in-class initialized static members here.
Robin Dapp [Thu, 13 Feb 2025 23:33:24 +0000 (16:33 -0700)]
RISC-V: Avoid more unsplit insns in const expander [PR118832].
Hi,
in PR118832 we have another instance of the problem already noticed in
PR117878. We sometimes use e.g. expand_simple_binop for vector
operations like shift or and. While this is usually OK, it causes
problems when doing it late, e.g. during LRA.
In particular, we might rematerialize a const_vector during LRA, which
then leaves an insn laying around that cannot be split any more if it
requires a pseudo. Therefore we should only use the split variants
in expand_const_vector.
This patch fixed the issue in the PR and also pre-emptively rewrites two
other spots that might be prone to the same issue.
Regtested on rv64gcv_zvl512b. As the two other cases don't have a test
(so might not even trigger) I unconditionally enabled them for my testsuite
run.
Regards
Robin
PR target/118832
gcc/ChangeLog:
* config/riscv/riscv-v.cc (expand_const_vector): Expand as
vlmax insn during lra.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr118832.c: New test.
Marek Polacek [Tue, 26 Nov 2024 19:37:21 +0000 (14:37 -0500)]
driver: -fhardened and -z lazy/-z norelro [PR117739]
As the manual states, using "-fhardened -fstack-protector" will produce
a warning because -fhardened wants to enable -fstack-protector-strong,
but it can't since it's been overriden by the weaker -fstack-protector.
-fhardened also attempts to enable -Wl,-z,relro,-z,now. By the same
logic as above, "-fhardened -z norelro" or "-fhardened -z lazy" should
produce the same warning. But we don't detect this combination, so
this patch fixes it. I also renamed a variable to better reflect its
purpose.
Also don't check warn_hardened in process_command, since it's always
true there.
Also tweak wording in the manual as Jon Wakely suggested on IRC.
PR driver/117739
gcc/ChangeLog:
* doc/invoke.texi: Tweak wording for -Whardened.
* gcc.cc (driver_handle_option): If -z lazy or -z norelro was
specified, don't enable linker hardening.
(process_command): Don't check warn_hardened.
gcc/testsuite/ChangeLog:
* c-c++-common/fhardened-16.c: New test.
* c-c++-common/fhardened-17.c: New test.
* c-c++-common/fhardened-18.c: New test.
* c-c++-common/fhardened-19.c: New test.
* c-c++-common/fhardened-20.c: New test.
* c-c++-common/fhardened-21.c: New test.
Jason Merrill [Wed, 12 Feb 2025 17:47:17 +0000 (18:47 +0100)]
c++: omp declare variant tweak
In r15-6707 I changed this function to use build_stub_object to more simply
produce the right type, but it occurs to me that forward_parm would be even
better, specifically for the diagnostic.
This changes nothing with respect to PR118791.
gcc/cp/ChangeLog:
* decl.cc (omp_declare_variant_finalize_one): Use forward_parm.
Thomas Koenig [Thu, 13 Feb 2025 20:47:39 +0000 (21:47 +0100)]
Fix LAPACK build error due to global symbol checking.
This was an interesting regression. It came from my recent
patch, where an assert was triggered because a procedure artificial
dummy argument generated for a global symbol did not have the
information if if was a function or a subroutine. Fixed by
adding the information in gfc_get_formal_from_actual_arglist.
This information then uncovered some new errors, also in the
testsuite, which needed fixing. Finally, the error is made to
look a bit nicer, so the user gets a pointer to where the
original interface comes from.
gcc/fortran/ChangeLog:
PR fortran/118845
* interface.cc (compare_parameter): If the formal attribute has been
generated from an actual argument list, also output an pointer to
there in case of an error.
(gfc_get_formal_from_actual_arglist): Set function and subroutine
attributes and (if it is a function) the typespec from the actual
argument.
gcc/testsuite/ChangeLog:
PR fortran/118845
* gfortran.dg/recursive_check_4.f03: Adjust call so types matche.
* gfortran.dg/recursive_check_6.f03: Likewise.
* gfortran.dg/specifics_2.f90: Adjust calls so types match.
* gfortran.dg/interface_52.f90: New test.
* gfortran.dg/interface_53.f90: New test.
Jason Merrill [Thu, 13 Feb 2025 10:54:48 +0000 (11:54 +0100)]
c++: -frange-for-ext-temps and reused temps [PR118856]
Some things in the front-end use a TARGET_EXPR to create a temporary, then
refer to its TARGET_EXPR_SLOT separately later; in this testcase,
maybe_init_list_as_range does. So we need to handle that pattern in
extend_all_temps.
This proposal was implemented a long time ago by my r9-5271,
but it took me this long to verify that it still works as per P2308.
This patch adds assorted tests, both from clang and from [temp.arg.nontype].
Fortunately I did not discover any issues in the compiler.
PR c++/113800
DR 2450
gcc/testsuite/ChangeLog:
* g++.dg/cpp26/pack-indexing15.C: New test.
* g++.dg/cpp2a/nontype-class68.C: New test.
* g++.dg/cpp2a/nontype-class69.C: New test.
* g++.dg/cpp2a/nontype-class70.C: New test.
* g++.dg/cpp2a/nontype-class71.C: New test.
* g++.dg/cpp2a/nontype-class72.C: New test.
Jakub Jelinek [Thu, 13 Feb 2025 13:14:50 +0000 (14:14 +0100)]
tree, gengtype: Fix up GC issue with DECL_VALUE_EXPR [PR118790]
The following testcase ICEs, because we have multiple levels of
DECL_VALUE_EXPR VAR_DECLs:
character(kind=1) id_string[1:.id_string] [value-expr: *id_string.55];
character(kind=1)[1:.id_string] * id_string.55 [value-expr: FRAME.107.id_string.55];
integer(kind=8) .id_string [value-expr: FRAME.107..id_string];
id_string is the user variable mentioned in BLOCK_VARS, it has
DECL_VALUE_EXPR because it is a VLA, id_string.55 is a temporary created by
gimplify_vla_decl as the address that points to the start of the VLA, what
is normally used in the IL to access it. But as this artificial var is then
used inside of a nested function, tree-nested.cc adds DECL_VALUE_EXPR to it
too and moves the actual value into the FRAME.107 object's member.
Now, remove_unused_locals removes id_string.55 (and various other VAR_DECLs)
from cfun->local_decls, simply because it is not mentioned in the IL at all
(neither is id_string itself, but that is kept in BLOCK_VARS as it has
DECL_VALUE_EXPR). So, after this point, id_string.55 tree isn't referenced from
anywhere but id_string's DECL_VALUE_EXPR. Next GC collection is triggered,
and we are unlucky enough that in the value_expr_for_decl hash table
(underlying hash map for DECL_VALUE_EXPR) the id_string.55 entry comes
before the id_string entry. id_string is ggc_marked_p because it is
referenced from BLOCK_VARS, but id_string.55 is not, as we don't mark
DECL_VALUE_EXPR anywhere but by gt_cleare_cache on value_expr_for_decl.
But gt_cleare_cache does two things, it calls clear_slots on entries
where the key is not ggc_marked_p (so the id_string.55 mapping to
FRAME.107.id_string.55 is lost and DECL_VALUE_EXPR (id_string.55) becomes
NULL) but then later we see id_string entry, which is ggc_marked_p, so mark
the whole hash table entry, which sets ggc_set_mark on id_string.55. But
at this point its DECL_VALUE_EXPR is lost.
Later during dwarf2out.cc we want to emit DW_AT_location for id_string, see
it has DECL_VALUE_EXPR, so emit it as indirection of id_string.55 for which
we again lookup DECL_VALUE_EXPR as it has DECL_HAS_VALUE_EXPR_P, but as it
is NULL, we ICE, instead of finding it is a subobject of FRAME.107 for which
we can find its stack location.
Now, as can be seen in the PR, I've tried to tweak tree-ssa-live.cc so that
it would keep id_string.55 in cfun->local_decls; that prohibits it from
the DECL_VALUE_EXPR of it being GC until expansion, but then we shrink and
free cfun->local_decls completely and so GC at that point still can throw
it away.
The following patch adds an extension to the GTY ((cache)) option, before
calling the gt_cleare_cache on some hash table by specifying
GTY ((cache ("somefn"))) it calls somefn on that hash table as well.
And this extra hook can do any additional ggc_set_mark needed so that
gt_cleare_cache preserves everything that is actually needed and throws
away the rest.
In order to make it just 2 pass rather than up to n passes - (if we had
say
id1 -> something, id2 -> x(id1), id3 -> x(id2), id4 -> x(id3), id5 -> x(id4)
in the value_expr_for_decl hash table in that order (where idN are VAR_DECLs
with DECL_HAS_VALUE_EXPR_P, id5 is the only one mentioned from outside and
idN -> X stands for idN having DECL_VALUE_EXPR X, something for some
arbitrary tree and x(idN) for some arbitrary tree which mentions idN
variable) and in each pass just marked the to part of entries with
ggc_marked_p base.from we'd need to repeat until we don't mark anything)
the patch calls walk_tree on DECL_VALUE_EXPR of the marked trees and if it
finds yet unmarked tree, it marks it and walks its DECL_VALUE_EXPR as well
the same way.
2025-02-13 Jakub Jelinek <jakub@redhat.com>
PR debug/118790
* gengtype.cc (write_roots): Remove cache variable, instead break from
the loop on match and test o for NULL. If the cache option has
non-empty string argument, call the specified function with v->name
as argument before calling gt_cleare_cache on it.
* tree.cc (gt_value_expr_mark_2, gt_value_expr_mark_1,
gt_value_expr_mark): New functions.
(value_expr_for_decl): Use GTY ((cache ("gt_value_expr_mark"))) rather
than just GTY ((cache)).
* doc/gty.texi (cache): Document optional argument of cache option.
Christophe Lyon [Tue, 11 Feb 2025 20:51:23 +0000 (20:51 +0000)]
arm: gimple fold aes[ed] [PR114522]
Almost a copy/paste from the recent aarch64 version of this patch,
this one is a bit more intrusive because it also introduces
arm_general_gimple_fold_builtin.
With this patch,
gcc.target/arm/aes_xor_combine.c scan-assembler-not veor
passes again.
gcc/ChangeLog:
PR target/114522
* config/arm/arm-builtins.cc (arm_fold_aes_op): New function.
(arm_general_gimple_fold_builtin): New function.
* config/arm/arm-builtins.h (arm_general_gimple_fold_builtin): New
prototype.
* config/arm/arm.cc (arm_gimple_fold_builtin): Call
arm_general_gimple_fold_builtin as needed.
Nathaniel Shead [Wed, 12 Feb 2025 12:07:43 +0000 (23:07 +1100)]
c++: Constrain visibility for CNTTPs with internal types [PR118849]
While looking into PR118846 I noticed that we don't currently constrain
the linkage of functions involving CNTTPs of internal-linkage types. It
seems to me that this would be sensible to do.
PR c++/118849
gcc/cp/ChangeLog:
* decl2.cc (min_vis_expr_r): Constrain visibility according to
the type of decl_constant_var_p decls.
Jakub Jelinek [Thu, 13 Feb 2025 10:53:04 +0000 (11:53 +0100)]
testsuite: Add another range for coroutines testcase [PR118574]
This patch adds another range for coroutine testcase, which doesn't
extend (across co_await) just the __for_range var and what it binds
to (so passes even without -frange-for-ext-temps), but also some other
temporaries and verifies they are destructed in the right order.
2025-02-13 Jakub Jelinek <jakub@redhat.com>
PR c++/118574
* g++.dg/coroutines/range-for2.C: New test.
Jakub Jelinek [Thu, 13 Feb 2025 09:21:29 +0000 (10:21 +0100)]
c++: Fix up regressions caused by for/while loops with declarations [PR118822]
The recent PR86769 r15-7426 changes regressed the following two testcases,
the first one is more important as it is derived from real-world code.
The first problem is that the chosen
prep = do_pushlevel (sk_block);
// emit something
body = push_stmt_list ();
// emit further stuff
body = pop_stmt_list (body);
prep = do_poplevel (prep);
way of constructing the {FOR,WHILE}_COND_PREP and {FOR,WHILE}_BODY
isn't reliable. If during parsing a label is seen in the body and then
some decl with destructors, sk_cleanup transparent scope is added, but
the correspondiong result from push_stmt_list is saved in
*current_binding_level and pop_stmt_list then pops even that statement list
but only do_poplevel actually attempts to pop the sk_cleanup scope and so we
ICE.
The reason for not doing do_pushlevel (sk_block); do_pushlevel (sk_block);
is that variables should be in the same scope (otherwise various e.g.
redeclaration*.C tests FAIL) and doing do_pushlevel (sk_block); do_pushlevel
(sk_cleanup); wouldn't work either as do_poplevel would silently unwind even
the cleanup one.
The second problem is that my assumption that the declaration in the
condition will have zero or one cleanup is just wrong, at least for
structured bindings used as condition, there can be as many cleanups as
there are names in the binding + 1.
So, the following patch changes the earlier approach. Nothing is removed
from the {FOR,WHILE}_COND_PREP subtrees while doing adjust_loop_decl_cond,
push_stmt_list isn't called either; all it does is remember as an integer
the number of cleanups (CLEANUP_STMT at the end of the STATEMENT_LISTs)
from querying stmt_list_stack and finding the initial *body_p in there
(that integer is stored into {FOR,WHILE}_COND_CLEANUP), and temporarily
{FOR,WHILE}_BODY is set to the last statement (if any) in the innermost
STATEMENT_LIST at the adjust_loop_decl_cond time; then at
finish_{for,while}_stmt a new finish_loop_cond_prep routine takes care of
do_poplevel for the scope (which is in {FOR,WHILE}_COND_PREP) and finds
given {FOR,WHILE}_COND_CLEANUP number and {FOR,WHILE}_BODY tree the right
spot where body statements start and moves that into {FOR,WHILE}_BODY.
Finally genericize_c_loop then inserts the cond, body, continue label, expr
into the right subtree of {FOR,WHILE}_COND_PREP.
The constexpr evaluation unfortunately had to be changed as well, because
we don't want to evaluate everything in BIND_EXPR_BODY (*_COND_PREP ())
right away, we want to evaluate it with the exception of the CLEANUP_STMT
cleanups at the end (given {FOR,WHILE}_COND_CLEANUP levels), and defer
the evaluation of the cleanups until after cond, body, expr are evaluated.
2025-02-13 Jakub Jelinek <jakub@redhat.com>
PR c++/118822
PR c++/118833
gcc/
* tree-iterator.h (tsi_split_stmt_list): Declare.
* tree-iterator.cc (tsi_split_stmt_list): New function.
gcc/c-family/
* c-common.h (WHILE_COND_CLEANUP): Change description in comment.
(FOR_COND_CLEANUP): Likewise.
* c-gimplify.cc (genericize_c_loop): Adjust for COND_CLEANUP
being CLEANUP_STMT/TRY_FINALLY_EXPR trailing nesting depth
instead of actual cleanup.
gcc/cp/
* semantics.cc (adjust_loop_decl_cond): Allow multiple trailing
CLEANUP_STMT levels in *BODY_P. Set *CLEANUP_P to the number
of levels rather than one particular cleanup, keep the cleanups
in *PREP_P. Set *BODY_P to the last stmt in the cur_stmt_list
or NULL if *CLEANUP_P and the innermost cur_stmt_list is empty.
(finish_loop_cond_prep): New function.
(finish_while_stmt, finish_for_stmt): Use it. Don't call
set_one_cleanup_loc.
* constexpr.cc (cxx_eval_loop_expr): Adjust handling of
{FOR,WHILE}_COND_{PREP,CLEANUP}.
gcc/testsuite/
* g++.dg/expr/for9.C: New test.
* g++.dg/cpp26/decomp12.C: New test.
Rainer Orth [Thu, 13 Feb 2025 09:17:50 +0000 (10:17 +0100)]
build: Remove HAVE_LD_EH_FRAME_CIEV3
Old versions of Solaris ld and GNU ld didn't support CIEv3 in .eh_frame.
To avoid this breaking the build
[build] Default to DWARF 4 on Solaris if linker supports CIEv3
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00669.html
checked for the necessary linker support, defaulting to DWARF-2 if
necessary. Solaris ld was fixed in Solaris 11.1, GNU ld in binutils
2.16, so this is long obsolete and only used in Solaris code anyway.
This patch thus removes both the configure check and
solaris_override_options.
Bootstrapped without regressions on i386-pc-solaris2.11 and
sparc-sun-solaris2.11.
Rainer Orth [Thu, 13 Feb 2025 08:59:43 +0000 (09:59 +0100)]
doc: Update install.texi for GCC 15 on Solaris
Apart from minor updates, this patch is primarily an important caveat
about binutils PR ld/32580, which has broken the binutils 2.44 ld on
Solaris/x86.
where the shift count operand does not trivially fit the scheme of
address operands. Reject those operands, especially since
strip_address_mutations() expects expressions of the form
(and ... (const_int ...)) and fails for (and ... (const_wide_int ...)).
Thus, be more strict here and accept only CONST_INT operands. Done by
replacing immediate_operand() with const_int_operand() which is enough
since the former only additionally checks for LEGITIMATE_PIC_OPERAND_P
and targetm.legitimate_constant_p which are always true for CONST_INT
operands.
While on it, fix indentation of the if block.
gcc/ChangeLog:
PR target/118835
* config/s390/s390.cc (s390_valid_shift_count): Reject shift
count operands which do not trivially fit the scheme of
address operands.
Richard Biener [Wed, 12 Feb 2025 14:01:53 +0000 (15:01 +0100)]
tree-optimization/118817 - fix ICE with VN CTOR simplification
The representation of CONSTRUCTOR nodes in VN NARY and gimple_match_op
do not agree so do not attempt to marshal between them.
PR tree-optimization/118817
* tree-ssa-sccvn.cc (vn_nary_simplify): Do not process
CONSTRUCTOR NARY or update from CONSTRUCTOR simplified
gimple_match_op.
So inline-asm is known not to trap BUT it can have undefined behavior
if made executed speculatively. This fixes the loop invariant pass to
treat it similarly as trapping cases. If the inline-asm could be executed
always, then it will be pulled out of the loop; otherwise it will be kept
inside the loop.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR rtl-optimization/102150
* loop-invariant.cc (find_invariant_insn): Treat inline-asm similar to
trapping instruction and only move them if always executed.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
So unlike loop invariant motion, moving an inline-asm out of an
if is not always profitable and the cost estimate for the instruction
inside inline-asm is unknown.
This is a regression from GCC 4.6 which didn't speculatively move inline-asm
as far as I can tell.
Bootstrapped and tested on x86_64-linux-gnu.
PR rtl-optimization/102150
gcc/ChangeLog:
* ifcvt.cc (cheap_bb_rtx_cost_p): Return false if the insn
has an inline-asm in it.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
AVR: target/118806 - Add -mno-call-main to tweak running main().
On devices with very limited resources, it may be desirable to run
main in a more efficient way than provided by the startup code
XCALL main
XJMP exit
from section .init9. In AVR-LibC v2.3, that code has been moved to
libmcu.a, hence symbol __call_main can be satisfied so that the
respective code is no more pulled in from that library.
Instead, main can be run by putting it in section .init9.
The patch adds attributes noreturn and section(".init9"), and
sets __call_main=0 when it encounters main().
gcc/
PR target/118806
* config/avr/avr.opt (-mcall-main): New option and...
(avropt_call_main): ...variable.
* config/avr/avr.cc (avr_no_call_main_p): New variable.
(avr_insert_attributes) [-mno-call-main, main]: Add attributes
noreturn and section(".init9") to main. Set avr_no_call_main_p.
(avr_file_end) [avr_no_call_main_p]: Define symbol __call_main.
* doc/invoke.texi (AVR Options) <-mno-call-main>: Document.
<-mnodevicelib>: Extend explanation.
Sandra Loosemore [Tue, 11 Feb 2025 21:52:36 +0000 (21:52 +0000)]
Doc: Fix some typos and other nearby sloppy-writing issues
I spotted some typos in the GCC manual. Since often these are a sign
that the text was inserted without being proofread, I looked at the
context and fixed some grammar/punctuation/wording issues as well.
gcc/ChangeLog
* doc/extend.texi: Fix a bunch of typos and other writing bugs.
* doc/invoke.texi: Likewise.
Sandra Loosemore [Wed, 12 Feb 2025 00:17:30 +0000 (00:17 +0000)]
Doc: Delete obsolete interface.texi chapter from GCC internals manual
The "Interfacing to GCC Output" chapter used to be part of the
user-facing GCC documentation but ended up in the GCC internals manual
when the two documents were separated in 2001. It hasn't been updated
in any substantive way since then, and is now very bit-rotten. (PCC is
no longer the "standard compiler" on any target, and the target-specific
issues mentioned are for very old architectures.)
Meanwhile, the GCC user documentation now has a chapter called "Binary
Compatibility" that covers ABI issues in a generic way and also covers
C++ compatibility. Let's keep that one and throw out the obsolete
text that seems to predate the whole notion of an ABI.
gcc/ChangeLog
* Makefile.in (TEXI_GCCINT_FILES): Remove interface.texi.
* doc/gccint.texi (Top): Remove menu entry for the "interface" node,
and include of interface.texi.
* doc/interface.texi: Delete.
Yangyu Chen [Wed, 12 Feb 2025 01:40:41 +0000 (18:40 -0700)]
RISC-V: Drop __riscv_vendor_feature_bits
As discussed from RISC-V C-API PR #101 [1], As discussed in #96, current
interface is insufficient to support some cases, like a vendor buying a
CPU IP from the upstream vendor but using their own mvendorid and custom
features from the upstream vendor. In this case, we might need to add
these extensions for each downstream vendor many times. Thus, making
__riscv_vendor_feature_bits guarded by mvendorid is not a good idea. So,
drop __riscv_vendor_feature_bits for now, and we should have time to
discuss a better solution.
Jeff Law [Tue, 11 Feb 2025 23:55:03 +0000 (16:55 -0700)]
[PR target/115478] Accept ADD, IOR or XOR when combining objects with no bits in common
So the change to prefer ADD over IOR for combining two objects with no bits in
common is (IMHO) generally good. It has some minor fallout.
In particular the aarch64 port (and I suspect others) have patterns that
recognize IOR, but not PLUS or XOR for these cases and thus tests which
expected to optimize with IOR are no longer optimizing.
Roger suggested using a code iterator for this purpose. Richard S. suggested a
new match operator to cover those cases.
I really like the match operator idea, but as Richard S. notes in the PR it
would require either not validating the "no bits in common", which dramatically
reduces the utility IMHO or we'd need some work to allow consistent results
without polluting the nonzero bits cache.
So this patch goes back to Roger's idea of just using a match iterator in the
aarch64 backend (and presumably anywhere else we see this popping up).
Bootstrapped and regression tested on aarch64-linux-gnu where it fixes
bitint-args.c (as expected).
PR target/115478
gcc/
* config/aarch64/iterators.md (any_or_plus): New code iterator.
* config/aarch64/aarch64.md (extr<mode>5_insn): Use any_or_plus.
(extr<mode>5_insn_alt, extrsi5_insn_uxtw): Likewise.
(extrsi5_insn_uxtw_alt, extrsi5_insn_di): Likewise.
Jason Merrill [Tue, 11 Feb 2025 12:51:32 +0000 (13:51 +0100)]
c++: don't default -frange-for-ext-temps in -std=gnu++20 [PR188574]
Since -frange-for-ext-temps has been causing trouble, let's not enable it
by default in pre-C++23 GNU modes for GCC 15, and also allow disabling it in
C++23 and up.
PR c++/188574
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Only enable
-frange-for-ext-temps by default in C++23.
Jason Merrill [Mon, 10 Feb 2025 14:44:13 +0000 (15:44 +0100)]
c++: change implementation of -frange-for-ext-temps [PR118574]
The implementation in r15-3840 used a novel technique of wrapping the entire
range-for loop in a CLEANUP_POINT_EXPR, which confused the coroutines
transformation. Instead let's use the existing extend_ref_init_temps
mechanism.
This does not revert all of r15-3840, only the parts that change how
CLEANUP_POINT_EXPRs are applied to range-for declarations.
Andrew Carlotti [Wed, 5 Feb 2025 17:27:56 +0000 (17:27 +0000)]
aarch64: Update fp8 dependencies
We agreed with LLVM developers to not enforce the architectural
dependencies between fp8 multiplication features, and they have already
been removed from LLVM and Binutils. Remove them from GCC as well.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def
(SSVE_FP8FMA): Adjust formatting.
(FP8DOT4): Replace FP8FMA dependency with FP8.
(SSVE_FP8DOT4): Replace SSVE_FP8FMA dependency with SME2+FP8.
(FP8DOT2): Replace FP8DOT4 dependency with FP8.
(SSVE_FP8DOT2): Replace SSVE_FP8DOT4 dependency with SME2+FP8.
Andrew Carlotti [Tue, 4 Feb 2025 19:45:31 +0000 (19:45 +0000)]
testsuite: Enable reduced parallel batch sizes
Various aarch64 tests attempt to reduce the batch size for parallel test
execution to a single test per batch, but it looks like the necessary
changes to gcc_parallel_test_run_p were accidentally omitted when the
aarch64-*-acle-asm.exp files were merged. This patch corrects that
omission.
This does have a measurable performance impact when running a limited
number of tests. For example, in aarch64-sve-acle-asm.exp the use of
torture options results in 16 compiler executions for each test; when
running two such tests I observed a total test duration of 3m39 without
this patch, and 1m55 with the patch. A full batch of 10 tests would
have taken over 15 minutes to run on this machine.
gcc/testsuite/ChangeLog:
* lib/gcc-defs.exp
(gcc_runtest_parallelize_limit_minor): New global variable.
(gcc_parallel_test_run_p): Use new variable for batch size.
OpenMP: Pass a 3-way flag to omp_check_context_selector instead of a bool.
The OpenMP "begin declare variant" directive has slightly different
requirements for context selectors than regular "declare variant", so
something more than a bool is required to tell the error-checking routine
what to check.
gcc/ChangeLog
* omp-general.cc (omp_check_context_selector): Change
metadirective_p argument to a 3-way flag. Add extra check for
OMP_CTX_BEGIN_DECLARE_VARIANT.
* omp-general.h (enum omp_ctx_directive): New.
(omp_check_context_selector): Adjust declaration.
gcc/c/ChangeLog
* c-parser.cc (c_finish_omp_declare_variant): Update call to
omp_check_context_selector.
(c_parser_omp_metadirective): Likewise.
gcc/cp/ChangeLog
* parser.cc (cp_finish_omp_declare_variant): Update call to
omp_check_context_selector.
(cp_parser_omp_metadirective): Likewise.
gcc/fortran/ChangeLog
* trans-openmp.cc (gfc_trans_omp_declare_variant): Update call to
omp_check_context_selector.
(gfc_trans_omp_metadirective): Likewise.
gcc/ChangeLog
* omp-general.cc (omp_context_selector_props_compare): Handle
arbitrary expressions in the "user" and "device_num" selectors.
(omp_context_selector_set_compare): Detect mismatch when one
selector specifies a score and the other doesn't.
Martin Jambor [Tue, 11 Feb 2025 15:39:56 +0000 (16:39 +0100)]
lto: Add an entry for cold attribute to lto_gnu_attributes
PR 118125 is a performance regression stemming from the fact that we
lose the cold attribute of our __builtin_unreachable. The attribute
is simply and silently dropped on the floor by decl_attributes (in
attribs.cc) in the process of building decls for builtins because it
cannot look it up in the gnu attribute name space by
lookup_scoped_attribute_spec. For that not to happen it must be in
lto_gnu_attributes and this patch adds it there.
In comment 13 of the bug Andrew identified other attributes which are
in builtin-attrs.def but missing in lto_gnu_attributes but apart from
cold it seems that they are either not used in builtins.def or are
used in DEF_LIB_BUILTIN which I guess might be less critical?
Eventually I decided to go for the most simple of patches and only add
things if they are requested. For the same reason I also did not add
any checking to the attribute "handle" callback or any exclusion check.
They seem to be mostly relevant before LTO FE kicks in to me, but
again, I'm happy to add any if they seem to be useful.
Since Ian fixed PR 118746, the same issue has also been fixed in the
Go front-end and so I have added a simple checking assert to the
redirect_to_unreachable function to make sure it has the intended
effect.
gcc/ChangeLog:
2025-02-03 Martin Jambor <mjambor@suse.cz>
PR lto/118125
* ipa-fnsummary.cc (redirect_to_unreachable): Add checking assert
that the builtin_unreachable decl has attribute cold.
gcc/lto/ChangeLog:
2025-02-03 Martin Jambor <mjambor@suse.cz>
PR lto/118125
* lto-lang.cc (lto_gnu_attributes): Add an entry for cold attribute.
(handle_cold_attribute): New function.
Simon Martin [Tue, 11 Feb 2025 14:59:02 +0000 (15:59 +0100)]
c++: Reject cdtors and conversion operators with a single * as return type [PR118304, PR118306]
We currently accept the following constructor declaration (clang, EDG
and MSVC do as well), and ICE on the destructor declaration
=== cut here ===
struct A {
*A ();
~A () = default;
};
=== cut here ===
The problem is that we end up in grokdeclarator with a cp_declarator of
kind cdk_pointer but no type, and we happily go through (if we have a
reference instead we eventually error out trying to form a reference to
void).
This patch makes sure that grokdeclarator errors out and strips the
invalid declarator when processing a cdtor (or a conversion operator
with no return type specified) with a declarator representing a pointer
or a reference type.
PR c++/118306
PR c++/118304
gcc/cp/ChangeLog:
* decl.cc (maybe_strip_indirect_ref): New.
(check_special_function_return_type): Take declarator as input.
Call maybe_strip_indirect_ref and error out if it returns true.
(grokdeclarator): Update call to
check_special_function_return_type.
gcc/testsuite/ChangeLog:
* g++.old-deja/g++.jason/operator.C: Adjust bogus test
expectation (char** vs char*).
* g++.dg/parse/constructor4.C: New test.
* g++.dg/parse/constructor5.C: New test.
* g++.dg/parse/conv_op2.C: New test.
* g++.dg/parse/default_to_int.C: New test.
David Malcolm [Tue, 11 Feb 2025 13:54:15 +0000 (08:54 -0500)]
sarif-replay: fix off-by-one in handling of "endColumn" (§3.30.8) [PR118792]
gcc/ChangeLog:
PR sarif-replay/118792
* libsarifreplay.cc (sarif_replayer::handle_region_object): Fix
off-by-one in handling of endColumn property so that the code
matches the comment and the SARIF spec (§3.30.8).
gcc/testsuite/ChangeLog:
PR sarif-replay/118792
* sarif-replay.dg/2.1.0-valid/error-with-note.sarif: Update
expected output to reflect fix to off-by-one error in handling of
"endColumn" property.
* sarif-replay.dg/2.1.0-valid/malloc-vs-local-4.c.sarif: Likewise.
* sarif-replay.dg/2.1.0-valid/signal-1.c.moved.sarif: Likewise.
* sarif-replay.dg/2.1.0-valid/signal-1.c.sarif: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
projects / thirdparty / gcc.git / log
