combine: Limit insn searchs for 2->2 combinations [PR116398]
As noted in the previous patch, combine still takes >30% of
compile time in the original testcase for PR101523. The problem
is that try_combine uses linear insn searches for some dataflow
queries, so in the worst case, an unlimited number of 2->2
combinations for the same i2 can lead to quadratic behaviour.
This patch limits distribute_links to a certain number
of instructions when i2 is unchanged. As Segher said in the PR trail,
it would make more conceptual sense to apply the limit unconditionally,
but I thought it would be better to change as little as possible at
this development stage. Logically, in stage 1, the --param should
be applied directly by distribute_links with no input from callers.
I think it's safe to drop log links even if a use exists. All
processing of log links seems to handle the absence of a link
for a particular register in a conservative way.
The initial set-up errs on the side of dropping links, since for example
create_log_links has:
/* flow.c claimed:
We don't build a LOG_LINK for hard registers contained
in ASM_OPERANDs. If these registers get replaced,
we might wind up changing the semantics of the insn,
even if reload can make what appear to be valid
assignments later. */
if (regno < FIRST_PSEUDO_REGISTER
&& asm_noperands (PATTERN (use_insn)) >= 0)
continue;
which excludes combinations by dropping log links, rather than during
try_combine. And:
/* If this register is being initialized using itself, and the
register is uninitialized in this basic block, and there are
no LOG_LINKS which set the register, then part of the
register is uninitialized. In that case we can't assume
anything about the number of nonzero bits.
??? We could do better if we checked this in
reg_{nonzero_bits,num_sign_bit_copies}_for_combine. Then we
could avoid making assumptions about the insn which initially
sets the register, while still using the information in other
insns. We would have to be careful to check every insn
involved in the combination. */
if (insn
&& reg_referenced_p (x, PATTERN (insn))
&& !REGNO_REG_SET_P (DF_LR_IN (BLOCK_FOR_INSN (insn)),
REGNO (x)))
{
struct insn_link *link;
Also, to answer Jakub's question in that comment, I tried bisecting:
int limit = atoi (getenv ("BISECT"));
(so applying the limit for all calls from try_combine) with an
abort in distribute_links if the limit caused a link to be skipped.
The minimum BISECT value that allowed an aarch64-linux-gnu bootstrap
to succeed with --enable-languages=all --enable-checking=yes,rtl,extra
was 142, so much lower than the parameter value. I realised too late
that --enable-checking=release would probably have been a more
interesting test.
The previous patch meant that distribute_links itself is now linear
for a given i2 definition, since each search starts at the previous
last use, rather than at i2 itself. This means that the limit has
to be applied cumulatively across all searches for the same link.
The patch does that by storing a counter in the insn_link structure.
There was a 32-bit hole there on LP64 hosts.
gcc/
PR testsuite/116398
* params.opt (-param=max-combine-search-insns=): New param.
* doc/invoke.texi: Document it.
* combine.cc (insn_link::insn_count): New field.
(alloc_insn_link): Initialize it.
(distribute_links): Add a limit parameter.
(try_combine): Use the new param to limit distribute_links
when only i3 has changed.
Another problem in PR101523 was that, after each successful 2->2
combination attempt, distribute_links would search further and further
for the next combinable use of the i2 destination. Each search would
start at i2 itself, making the search quadratic in the worst case.
In a 2->2 combination, if i2 is unchanged, the search can start at i3
instead of i2. The same thing applies to i2 when distributing i2's
links, since the only changes to earlier instructions are the deletion
of i0 and i1.
This change, combined with the previous split_i2i3 patch, gives a
34.6% speedup in combine for the testcase in PR101523. Combine
goes from being 41% to 34% of compile time.
gcc/
PR testsuite/116398
* combine.cc (distribute_links): Take an optional start point.
(try_combine): If only i3 has changed, only distribute i3's links,
not i2's. Start the search for the new use from i3 rather than
from the definition instruction. Likewise start the search for
the new use from i2 when distributing i2's links.
combine: Avoid split_i2i3 search if i2 is unchanged [PR116398]
When combining a single-set i2 into a multi-set i3, combine
first tries to match the new multi-set in-place. If that fails,
combine considers splitting the multi-set so that one set goes in
i2 and the other set stays in i3. That moves a destination from i3
to i2 and so combine needs to update any associated log link for that
destination to point to i2 rather than i3.
However, that kind of split can also occur for 2->2 combinations.
For a 2-instruction combination in which i2 doesn't die in i3, combine
tries a 2->1 combination by turning i3 into a parallel of the original
i2 and the combined i3. If that fails, combine will split the parallel
as above, so that the first set goes in i2 and the second set goes in i3.
But that can often leave i2 unchanged, meaning that no destinations have
moved and so no search is necessary.
gcc/
PR testsuite/116398
* combine.cc (try_combine): Shortcut the split_i2i3 handling if
i2 is unchanged.
combine: Allow 2->2 combinations, but with a tweak [PR116398]
One of the problems in PR101523 was that, after each successful
2->2 combination attempt, try_combine would restart combination
attempts at i2 even if i2 hadn't changed. This led to quadratic
behaviour as the same failed combinations between i2 and i3 were
tried repeatedly.
The original patch for the PR dealt with that by disallowing 2->2
combinations. However, that led to various optimisation regressions,
so there was interest in allowing the combinations again, at least
until an alternative way of getting the same results is in place.
to be folded to a vector of -1s. One unusual thing about the fold
is that the <1> in the second insn is uninitialised; it looks like
it should be replaced by <0>, or that there should be an insn 4 that
copies <0> to <1>.
As it stands, the test relies on init-regs to insert a zero
initialisation of <1>. This happens after all the cse/pre/fwprop
stuff, with only dce passes between init-regs and combine.
Combine therefore sees:
It looks like the test should then pass through a 3, 9 -> 5 combination,
so that we get an (eq ...) between two zeros and fold it to a vector
of -1s. But although the combination is attempted, the fold doesn't
happen. Instead, combine is left to match the unsimplified (eq ...)
between two zeros, which rightly fails. The test only passes because
late_combine2 happens to try simplifying an (eq ...) between reg X and
reg X, which does fold to a vector of -1s.
The different handling of registers and constants is due to this
code in simplify_const_relational_operation:
if (INTEGRAL_MODE_P (mode) && trueop1 != const0_rtx
&& (code == EQ || code == NE)
&& ! ((REG_P (op0) || CONST_INT_P (trueop0))
&& (REG_P (op1) || CONST_INT_P (trueop1)))
&& (tem = simplify_binary_operation (MINUS, mode, op0, op1)) != 0
/* We cannot do this if tem is a nonzero address. */
&& ! nonzero_address_p (tem))
return simplify_const_relational_operation (signed_condition (code),
mode, tem, const0_rtx);
INTEGRAL_MODE_P matches vector integer modes, but everything else
about the condition is written for scalar integers only. Thus if
trueop0 and trueop1 are equal vector constants, we'll bypass all
the exclusions and try simplifying a subtraction. This will succeed,
giving a vector of zeros. The recursive call will then try to simplify
a comparison between the vector of zeros and const0_rtx, which isn't
well-formed. Luckily or unluckily, the ill-formedness doesn't trigger
an ICE, but it does prevent any simplification from happening.
The least-effort fix would be to replace INTEGRAL_MODE_P with
SCALAR_INT_MODE_P. But the fold does make conceptual sense for
vectors too, so it seemed better to keep the INTEGRAL_MODE_P and
generalise the rest of the condition to match.
gcc/
* simplify-rtx.cc (simplify_const_relational_operation): Generalize
the constant checks in the fold-via-minus path to match the
INTEGRAL_MODE_P condition.
Iain Sandoe [Mon, 31 Mar 2025 12:54:37 +0000 (13:54 +0100)]
testsuite, cobol: Avoid adding duplicate libs.
The discovered paths already include the multilib and so there is
no need to add an extra library to COBOL_UNDER_TEST. Doing so makes
a duplicate, which causes test fails on Darwin, where the linker warns
when duplicate libraries are provided on the link line.
gcc/testsuite/ChangeLog:
* lib/cobol.exp: Simplify the setting of COBOL_UNDER_TEST.
As discussed in the PR, the options had been added during development
to handle specific cases, they are no longer needed (and if they should
become necessary, we will need to guard them such that individual
platforms get the correct handling).
PR cobol/119414
gcc/cobol/ChangeLog:
* gcobolspec.cc (append_rdynamic,
append_allow_multiple_definition, append_fpic): Remove.
(lang_specific_driver): Remove platform-specific command
line option handling.
Doc: Fix description of -Wno-aggressive-loop-optimizations [PR78874]
gcc/ChangeLog
PR middle-end/78874
* doc/invoke.texi (Warning Options): Fix description of
-Wno-aggressive-loop-optimizations to reflect that this turns
off the warning, and the default is for it to be enabled.
Patrick Palka [Sun, 6 Apr 2025 02:39:15 +0000 (22:39 -0400)]
c++: maybe_dependent_member_ref and typenames [PR118626]
Here during maybe_dependent_member_ref for accepted_type<_Up>, we
correctly don't strip the typedef because it's a complex one (its
defaulted template parameter isn't used in its definition) and so
we recurse to consider its corresponding TYPE_DECL.
We then incorrectly decide to not rewrite this use because of the
TYPENAME_TYPE shortcut. But I don't think this shortcut should apply to
a typedef TYPE_DECL.
PR c++/118626
gcc/cp/ChangeLog:
* pt.cc (maybe_dependent_member_ref): Restrict TYPENAME_TYPE
shortcut to non-typedef TYPE_DECL.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias25a.C: New test.
Patrick Palka [Sun, 6 Apr 2025 02:39:12 +0000 (22:39 -0400)]
c++: maybe_dependent_member_ref and stripped alias [PR118626]
Here during maybe_dependent_member_ref (as part of CTAD rewriting
for the variant constructor) for __accepted_type<_Up> we strip this
alias all the way to type _Nth_type<__accepted_index<_Up>>, for which
we return NULL since _Nth_type is at namespace scope and so no
longer needs rewriting.
Note that however the template argument __accepted_index<_Up> of this
stripped type _does_ need rewriting (since it specializes a variable
template from the current instantiation). We end up not rewriting this
variable template reference at any point however because upon returning
NULL, the caller (tsubst) proceeds to substitute the original form of
the type __accepted_type<_Up>, which doesn't directly refer to
__accepted_index. This later leads to an ICE during subsequent alias
CTAD rewriting of this guide that contains a non-rewritten reference
to __accepted_index.
So when maybe_dependent_member_ref decides to not rewrite a class-scope
alias that's been stripped, the caller needs to commit to substituting
the stripped type rather than the original type. This patch essentially
implements that by making maybe_dependent_member_ref call tsubst itself
in that case.
PR c++/118626
gcc/cp/ChangeLog:
* pt.cc (maybe_dependent_member_ref): Substitute and return the
stripped type if we decided to not rewrite it directly.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias25.C: New test.
Per the issue, there were a couple places in the manual where
-Wno-psabi was mentioned, but the option itself was not documented.
gcc/c-family/ChangeLog
PR c/81831
* c.opt (Wpsabi): Remove "Undocumented" modifier and add a
documentation string.
gcc/ChangeLog
PR c/81831
* doc/invoke.texi (Option Summary): Add -Wno-psabi.
(Warning Options): Document -Wpsabi separately from -Wabi.
Note it's enabled by default, not just implied by -Wabi.
Replace the detailed example for a GCC 4.4 change for x86
(which is unlikely to be very interesting nowadays) with
just a list of all targets that presently diagnose these
warnings.
(RS/6000 and PowerPC Options): Add cross-references for
-Wno-psabi.
Patrick Palka [Sat, 5 Apr 2025 19:22:48 +0000 (15:22 -0400)]
c++: harmless use of 'this' rejected despite P2280R4 [PR118249]
Here the implicit use of 'this' in inner.size() template argument was
being rejected despite P2280R4 relaxations, due to the special *this
handling in the INDIRECT_REF case of potential_constant_expression_1.
This handling was originally added by r196737 as part of fixing PR56481,
and it seems obsolete especially in light of P2280R4. There doesn't
seem to be a good reason that we need to handle *this specially from
other dereferences.
This patch therefore removes this special handling. As a side benefit
we now correctly reject some *reinterpret_cast<...>(...) constructs
earlier, via p_c_e_1 rather than via constexpr evaluation (because the
removed STRIP_NOPS step meant we'd overlook such casts), which causes a
couple of diagnostic changes (for the better).
PR c++/118249
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1)
<case INDIRECT_REF>: Remove obsolete *this handling.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-reinterpret2.C: Expect error at
call site of the non-constexpr functions.
* g++.dg/cpp23/constexpr-nonlit12.C: Likewise.
* g++.dg/cpp0x/constexpr-ref14.C: New test.
Docs: Document -fcf-protection without argument [PR112589]
gcc/ChangeLog
PR middle-end/112589
* common.opt (-fcf-protection): Add documentation string.
* doc/invoke.texi (Option Summary): Add entry for -fcf-protection
without argument.
(Instrumentation Options): Tidy the -fcf-protection entry and
and add documention for the form without an argument.
Iain Sandoe [Sat, 15 Mar 2025 22:47:47 +0000 (22:47 +0000)]
cobol, driver, libgcobol: Add support for libgcobol.spec.
Ads support for using a library spec file (e.g. to include the
target requirements for non-standard libraries - or even libm
which we can now configure at the target side).
gcc/cobol/ChangeLog:
* gcobolspec.cc (SPEC_FILE): New.
(lang_specific_driver): Make the 'need libgcobol' flag global
so that the prelink callback can use it. Libm use is now handled
via the library spec.
(lang_specific_pre_link): Include libgcobol.spec where needed.
libgcobol/ChangeLog:
* Makefile.am: Add libgcobol.spec and dependency.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Add libgcobol.spec handling.
* libgcobol.spec.in: New file.
Iain Sandoe [Sat, 22 Mar 2025 16:58:47 +0000 (16:58 +0000)]
libgcobol: C++-ify the configuration steps.
Currently, the library is configured as if it was written in C, however
all the sources are C++, so update to use C++ as the configure language
(and check the CXX instead of CC).
Reorder the configuration steps so that we setup the tools and environment
before carrying out tests.
Remove unused configuration machinery.
Also we configured extra ld flags but never used them. There is no need
to make these extra_ldflags darwin-specific, additions could be required
by other hosts.
libgcobol/ChangeLog:
* aclocal.m4: Regenerate.
* config.h.in: Regenerate.
* Makefile.am: Use the configured LIBS and extra_ldflags.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Shift configure to use c++. Order tests for tools
and environment before other tests.
AVR: Speed up __umulhisi3 for small devices with MUL.
__umulhisi3 had an "rcall 1f" to save 6 bytes, which is an unreasonable
size gain vs. cycle cost. Just use the same code on all devices with MUL,
irrespective of program memory size.
Jason Merrill [Fri, 4 Apr 2025 21:34:08 +0000 (17:34 -0400)]
c++: __FUNCTION__ in lambda return type [PR118629]
In this testcase, the use of __FUNCTION__ is within a function parameter
scope, the lambda's. And P1787 changed __func__ to live in the parameter
scope. But [basic.scope.pdecl] says that the point of declaration of
__func__ is immediately before {, so in the trailing return type it isn't in
scope yet, so this __FUNCTION__ should refer to foo().
Looking first for a block scope, then a function parameter scope, gives us
the right result.
PR c++/118629
gcc/cp/ChangeLog:
* name-lookup.cc (pushdecl_outermost_localscope): Look for an
sk_block.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-__func__3.C: New test.
c++/modules: Fix divergence in streaming/non-streaming tree walks [PR119608]
Modules streaming walks decls multiple times, first as a non-streaming
walk to find dependencies, and then later to actually emit the decls.
The first walk needs to be done to note locations that will be emitted.
In the PR we are getting a checking ICE because we are streaming a decl
that we didn't initially walk when collecting dependencies, so the
location isn't in the noted locations map. This is because in decl_node
we have a branch where a PARM_DECL that hasn't previously been
referenced gets walked by value only if 'streaming_p ()' is true.
The true root cause here is that the decltype(v) in the testcase refers
to a different PARM_DECL from the one in the declaration that we're
streaming; it's the PARM_DECL from the initial forward-declaration, that
we're not streaming. A proper fix would be to ensure that it gets
remapped to the decl in the definition we're actually emitting, but for
now this workaround fixes the bug (and any other bugs that might
manifest similarly).
PR c++/119608
gcc/cp/ChangeLog:
* module.cc (trees_out::decl_node): Maybe require by-value
walking not just when streaming.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr119608_a.C: New test.
* g++.dg/modules/pr119608_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
c++/modules: Propagate bits to DECL_MAYBE_DELETED dups [PR119462]
In the linked PR, we're importing over a DECL_MAYBE_DELETED decl with a
decl that has already been instantiated. This patch ensures that the
needed bits are propagated across and that DECL_MAYBE_DELETED is cleared
from the existing decl, so that later synthesize_method doesn't crash
due to a definition unexpectedly already existing.
PR c++/119462
gcc/cp/ChangeLog:
* module.cc (trees_in::is_matching_decl): Propagate exception
spec and constexpr to DECL_MAYBE_DELETED; clear if appropriate.
gcc/testsuite/ChangeLog:
* g++.dg/modules/noexcept-3_a.C: New test.
* g++.dg/modules/noexcept-3_b.C: New test.
* g++.dg/modules/noexcept-3_c.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jason Merrill [Wed, 29 Jan 2025 10:15:00 +0000 (05:15 -0500)]
c++: lambda in requires outside template [PR99546]
Since r10-7441 we set processing_template_decl in a requires-expression so
that we can use tsubst_expr to evaluate the requirements, but that confuses
lambdas terribly; begin_lambda_type silently returns error_mark_node and we
continue into other failures. This patch clears processing_template_decl
again while we're defining the closure and op() function, so it only remains
set while parsing the introducer (i.e. any init-captures) and building the
resulting object. This properly avoids trying to create another lambda in
tsubst_lambda_expr.
* g++.dg/cpp2a/lambda-requires2.C: New test.
* g++.dg/cpp2a/lambda-requires3.C: New test.
* g++.dg/cpp2a/lambda-requires4.C: New test.
* g++.dg/cpp2a/lambda-requires5.C: New test.
Patrick Palka [Fri, 4 Apr 2025 19:05:09 +0000 (15:05 -0400)]
libstdc++: Avoid redundant value_type object in flat_set::emplace [PR119620]
flat_set::emplace (and flat_multiset's) currently unconditionally
constructs an object outside of the container, but if we're passed
a value_type object we can and should avoid that.
PR libstdc++/119620
libstdc++-v3/ChangeLog:
* include/std/flat_set (_Flat_set_impl::_M_try_emplace): Split
out into two overloads, one taking at least one argument and one
taking zero arguments. Turn __k into an auto&& reference bound
to __arg if it's already a value_type and otherwise bound to a
lifetime-extended value_type temporary.
* testsuite/23_containers/flat_multiset/1.cc (test08): New test.
* testsuite/23_containers/flat_set/1.cc (test08): New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Jakub Jelinek [Fri, 4 Apr 2025 18:57:09 +0000 (20:57 +0200)]
lto: lto-opts fixes [PR119625]
I can reproduce a really weird error in our distro i686 trunk gcc
(but haven't managed to reproduce it with vanilla trunk yet).
echo 'void foo (void) {}' > a.c; gcc -O2 -flto=auto -m32 -march=i686 -ffat-lto-objects -fhardened -o a.o -c a.c; gcc -O2 -flto=auto -m32 -march=i686 -r -o a.lo a.o
lto1: fatal error: open failed: No such file or directory
compilation terminated.
lto-wrapper: fatal error: gcc returned 1 exit status
The error is because
cat ./a.lo.lto.o-args.0
""
a.o
My suspicion is that this "" in there is caused by weird .gnu.lto_.opts
section content during
gcc -O2 -flto=auto -m32 -march=i686 -ffat-lto-objects -fhardened -S -o a.s -c a.c
compilation (and I can reproduce that one with vanilla trunk).
The above results in
.section .gnu.lto_.opts,"e",@progbits
.string "'-fno-openmp' '-fno-openacc' '-fPIC' '' '-m32' '-march=i686' '-O2' '-flto=auto' '-ffat-lto-objects'"
There are two weird things, one (IMHO the cause of the "" later on) is
the '' part, I think it comes from lto_write_options doing
append_to_collect_gcc_options (&temporary_obstack, &first_p, "");
IMHO it shouldn't call append_to_collect_gcc_options at all for that case.
The -fhardened option causes global_options.x_flag_cf_protection
to be set to CF_FULL and later on the backend option processing
sets it to CF_FULL | CF_SET (i.e. 7, a value not handled in
lto_write_options).
The following patch fixes it by not emitting anything there if
flag_cf_protection is one of the unhandled values.
Perhaps it could incrementally use
switch (global_options.x_flag_cf_protection & ~CF_SET)
instead, dunno.
And the other problem is that the -fPIC in there is really weird.
Our distro compiler or vanilla configured trunk certainly doesn't
default to -fPIC and -fhardened uses -fPIE when
-fPIC/-fpic/-fno-pie/-fno-pic is not specified, so I was expecting
-fPIE in there.
The thing is that the -fpie option causes setting of both
global_options.x_flag_pi{c,e} to 1, -fPIE both to 2:
/* If -fPIE or -fpie is used, turn on PIC. */
if (opts->x_flag_pie)
opts->x_flag_pic = opts->x_flag_pie;
else if (opts->x_flag_pic == -1)
opts->x_flag_pic = 0;
if (opts->x_flag_pic && !opts->x_flag_pie)
opts->x_flag_shlib = 1;
so checking first for flag_pic == 2 and then flag_pic == 1
and only afterwards for flag_pie means we never print
-fPIE/-fpie.
Or do you want something further (like
switch (global_options.x_flag_cf_protection & ~CF_SET)
)?
2025-04-04 Jakub Jelinek <jakub@redhat.com>
PR lto/119625
* lto-opts.cc (lto_write_options): If neither flag_pic nor
flag_pie are set, check first for flag_pie and only later
for flag_pic rather than the other way around, use a temporary
variable. If flag_cf_protection is not set, don't append anything
if flag_cf_protection is none of CF_{NONE,FULL,BRANCH,RETURN} and
use a temporary variable.
Jakub Jelinek [Fri, 4 Apr 2025 18:53:19 +0000 (20:53 +0200)]
profile: Another musttail fix [PR119618]
As the following testcase shows, sometimes we can have debug stmts
after a musttail call and profile.cc in that case would incorrectly
allow the edge from that, causing musttail error and -fcompare-debug
failure (because if there are no debug stmts after it, then musttail
is found there and the edge is ignored).
The following patch uses gsi_last_nondebug_bb instead of gsi_last_bb
to find the musttail call. And so that we don't uselessly skip over
debug stmts at the end of many bbs, the patch limits it to
cfun->has_musttail functions.
2025-04-04 Jakub Jelinek <jakub@redhat.com>
PR gcov-profile/119618
* profile.cc (branch_prob): Only check for musttail calls if
cfun->has_musttail. Use gsi_last_nondebug_bb instead of gsi_last_bb.
Jakub Jelinek [Fri, 4 Apr 2025 18:52:41 +0000 (20:52 +0200)]
tailc: Don't reject all tail calls if param has addr taken [PR119616]
Before my PR119376 r15-9145 changes, suitable_for_tail_call_opt_p would
return the same value in the same caller, regardless of the calls in it.
If it fails, the caller clears opt_tailcalls which is a reference and
therefore shared by all calls in the caller and we only do tail recursion,
all non-recursive or tail recursion non-optimizable calls are not
tail call optimized.
For musttail calls we want to allow address taken parameters, but the
r15-9145 change effectively resulted in the behavior where if there
are just musttail calls considered, they will be tail call optimized,
and if there are also other tail call candidates (without musttail),
we clear opt_tailcall and then error out on all the musttail calls.
The following patch fixes that by moving the address taken parameter
discovery from suitable_for_tail_call_opt_p to its single caller.
If there are addressable parameters, if !cfun->has_musttail it will
work as before, disable all tail calls in the caller but possibly
allow tail recursions. If cfun->has_musttail, it will set a new
bool automatic flag and reject non-tail recursions. This way musttail
calls can be still accepted and normal tail call candidates rejected
(and tail recursions accepted).
2025-04-04 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119616
* tree-tailcall.cc (suitable_for_tail_call_opt_p): Move checking
for addressable parameters from here ...
(find_tail_calls): ... here. If cfun->has_musttail, don't clear
opt_tailcalls for it, instead set a local flag and punt if we can't
tail recurse optimize it.
Jakub Jelinek [Fri, 4 Apr 2025 18:51:50 +0000 (20:51 +0200)]
cfgrtl: Remove REG_EH_REGION notes from tail calls [PR119613]
In PR119491 r15-9154 I've allowed some useless EH regions for musttail
calls (if there are no non-debug/clobber stmts before resx which resumes
external throwing).
Now, for -O1+ (but not -O0/-Og) there is a cleanup_eh pass after it
which should optimize that way.
The following testcase ICEs at -O0 though, the cleanup_eh in that case
is before the musttail pass and dunno why it didn't actually optimize
it away.
The following patch catches that during expansion and just removes the note,
which causes EH cleanups to do the rest. A tail call, even when it throws,
will not throw while the musttail caller's frame is still on the stack,
will throw after that and so REG_EH_REGION for it is irrelevant (like it
would be never set before the r15-9154 changes).
Iain Sandoe [Fri, 21 Mar 2025 10:22:58 +0000 (10:22 +0000)]
libgcobol: Check if the target needs libm.
Use the libtool config check and $(LIBM).
libgcobol/ChangeLog:
* Makefile.am: Use $(LIBM) to add the math lib when
it is needed.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check if the target wants libm.
Bob Dubner [Fri, 4 Apr 2025 17:48:58 +0000 (13:48 -0400)]
cobol: Eliminate cobolworx UAT errors when compiling with -Os
Testcases compiled with -Os were failing because static functions and static
variables were being optimized away, because of improper data type casts, and
because strict aliasing (whatever that is) was resulting in some loss of data.
These changes eliminate those known problems.
gcc/cobol
* cobol1.cc: (cobol_langhook_post_options): Implemented in order to set
flag_strict_aliasing to zero.
* genapi.cc: (set_user_status): Add comment.
(parser_intrinsic_subst): Expand SHOW_PARSE information.
(psa_global): Change names of return-code and upsi globals,
(psa_FldLiteralA): Set DECL_PRESERVE_P for FldLiteralA.
* gengen.cc: (show_type): Add POINTER type.
(gg_define_function_with_no_parameters): Set DECL_PRESERVE_P for COBOL-
style nested programs. (gg_array_of_bytes): Fix bad cast.
libgcobol
* charmaps.h: Change __gg__data_return_code to 'short' type.
* constants.cc: Likewise.
Jakub Jelinek [Fri, 4 Apr 2025 18:07:37 +0000 (20:07 +0200)]
rtlanal, i386: Adjust pattern_cost and x86 constant cost [PR115910]
Below is an attempt to fix up RTX costing P1 caused by r15-775
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/thread.html#652446
@@ -21562,7 +21562,8 @@ ix86_rtx_costs (rtx x, machine_mode mode, int outer_code_i, int opno,
if (x86_64_immediate_operand (x, VOIDmode))
*total = 0;
else
- *total = 1;
+ /* movabsq is slightly more expensive than a simple instruction. */
+ *total = COSTS_N_INSNS (1) + 1;
return true;
case CONST_DOUBLE:
change. In my understanding this was partially trying to workaround
weird code in pattern_cost, which uses
return cost > 0 ? cost : COSTS_N_INSNS (1);
That doesn't make sense to me. All costs smaller than COSTS_N_INSNS (1)
mean we need to have at least one instruction there which has the
COSTS_N_INSNS (1) minimal cost. So special casing just cost 0 for the
really cheap immediates which can be used pretty much everywhere but not
ones which have just tiny bit larger cost than that (1, 2 or 3) is just
weird.
So, the following patch changes that to MAX (COSTS_N_INSNS (1), cost)
which doesn't have this weird behavior where set_src_cost 0 is considered
more expensive than set_src_cost 1.
Note, pattern_cost isn't the only spot where costs are computed and normally
we often sum the subcosts of different parts of a pattern or just query
rtx costs of different parts of subexpressions, so the jump from
1 to 5 is quite significant.
Additionally, x86_64 doesn't have just 2 kinds of constants with different
costs, it has 3, signed 32-bit ones are the ones which can appear in
almost all instructions and so using cost of 0 for those looks best,
then unsigned 32-bit ones which can be done with still cheap movl
instruction (and I think some others too) and finally full 64-bit ones
which can be done only with a single movabsq instruction and are quite
costly both in instruction size and even more expensive to execute.
The following patch attempts to restore the behavior of GCC 14 with the
pattern_cost hunk fixed for the unsigned 32-bit ones and only keeps the
bigger cost for the 64-bit ones.
2025-04-04 Jakub Jelinek <jakub@redhat.com>
PR target/115910
* rtlanal.cc (pattern_cost): Return at least COSTS_N_INSNS (1)
rather than just COSTS_N_INTNS (1) for cost <= 0.
* config/i386/i386.cc (ix86_rtx_costs): Set *total to 1 for
TARGET_64BIT x86_64_zext_immediate_operand constants.
Patrick Palka [Fri, 4 Apr 2025 18:03:58 +0000 (14:03 -0400)]
c++: constraint variable used in evaluated context [PR117849]
Here we wrongly reject the type-requirement at parse time due to its use
of the constraint variable 't' within a template argument (an evaluated
context). Fix this simply by refining the "use of parameter outside
function body" error path to exclude constraint variables.
PR c++/104255 tracks the same issue for function parameters, but fixing
that would be more involved, requiring changes to the PARM_DECL case of
tsubst_expr.
PR c++/117849
gcc/cp/ChangeLog:
* semantics.cc (finish_id_expression_1): Allow use of constraint
variable outside an unevaluated context.
Andrew Pinski [Thu, 3 Apr 2025 01:18:50 +0000 (18:18 -0700)]
always turn return into __builtin_unreachable for noreturn fuctions [PR119599]
r8-3988-g356fcc67fba52b added code to turn return statements into __builtin_unreachable
calls inside noreturn functions but only while optimizing. Since -funreachable-traps
was added (r13-1204-gd68d3664253696), it is a good idea to move over to using
__builtin_unreachable (and the trap version with this option which defaults at -O0 and -0g)
instead of just a follow through even at -O0.
This also fixes a regression when inlining a noreturn function that returns at -O0 (due to always_inline)
as we would get an empty bb which has no successor edge instead of one with a call to __builtin_unreachable.
I also noticed there was no testcase testing the warning about __builtin_return inside a noreturn function
so I added a testcase there.
Bootstrapped and tested on x86_64-linux-gnu.
PR ipa/119599
gcc/ChangeLog:
* tree-cfg.cc (pass_warn_function_return::execute): Turn return statements always
into __builtin_unreachable calls.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr119599-1.c: New test.
* gcc.dg/builtin-apply5.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Jakub Jelinek [Fri, 4 Apr 2025 15:27:56 +0000 (17:27 +0200)]
c++, libcpp: Allow some left shifts in the preprocessor [PR119391]
The libcpp left shift handling implements (partially) the C99-C23
wording where shifts are UB if shift count is negative, or too large,
or shifting left a negative value or shifting left non-negative value
results in something not representable in the result type (in the
preprocessor case that is intmax_t).
libcpp actually implements left shift by negative count as right shifts
by negation of the count and similarly right shifts by negative count
as left shifts by negation (not ok), sets overflow for too large shift
count (ok), doesn't check for negative values on left shift (not ok)
and checks correctly for the non-representable ones otherwise (ok).
Now, C++11 to C++17 has different behavior, whereas in C99-C23 1 << 63
in preprocessor is invalid, in C++11-17 it is valid, but 3 << 63 is
not. The wording is that left shift of negative value is UB (like in C)
and signed non-negative left shift is UB if the result isn't representable
in corresponding unsigned type (so uintmax_t for libcpp).
And then C++20 and newer says all left shifts are well defined with the
exception of bad shift counts.
In -fsanitize=undefined we handle these by
/* For signed x << y, in C99 and later, the following:
(unsigned) x >> (uprecm1 - y)
if non-zero, is undefined. */
and
/* For signed x << y, in C++11 to C++17, the following:
x < 0 || ((unsigned) x >> (uprecm1 - y))
if > 1, is undefined. */
Now, we are late in GCC 15 development, so I think making the preprocessor
more strict than it is now is undesirable, so will defer setting overflow
flag for the shifts by negative count, or shifts by negative value left.
The following patch just makes some previously incorrectly rejected or
warned cases valid for C++11-17 and even more for C++20 and later.
2025-04-04 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/119391
* expr.cc (num_lshift): Add pfile argument. Don't set num.overflow
for !num.unsignedp in C++20 or later unless n >= precision. For
C++11 to C++17 set it if orig >> (precision - 1 - n) as logical
shift results in value > 1.
(num_binary_op): Pass pfile to num_lshift.
(num_div_op): Likewise.
arm: testsuite: restore dg-do-what-default in mve.exp
On Arm, running
make check-gcc RUNTESTFLAGS="dwarf2.exp=pr43190.c"
with a target list of "arm-qemu{,-mthumb}"
results in no errors. But running it with
make check-gcc RUNTESTFLAGS="{mve,dwarf2}.exp=pr43190.c"
results in unresolved tests while running the thumb variant. The problem
is that mve.exp is changing dg-do-what-default to "assemble", but failing
to restore the original value once its tests are complete. The result is
that all subsequent tests run with an incorrect underlying default value.
The fix is easy - save dg-do-what-default and restore it after the tests
are complete.
gcc/testsuite/ChangeLog:
* gcc.target/arm/mve/mve.exp: Save dg-do-what-default before
changing it. Restore it once done.
Jonathan Wakely [Wed, 26 Mar 2025 11:47:05 +0000 (11:47 +0000)]
libstdc++: Replace use of __mindist in ranges::uninitialized_xxx algos [PR101587]
In r15-8980-gf4b6acfc36fb1f I introduced a new function object for
finding the smaller of two distances. In bugzilla Hewill Kang pointed
out that we still need to explicitly convert the result back to the
right difference type, because the result might be an integer-like class
type that doesn't convert to an integral type explicitly.
Rather than doing that conversion in the __mindist function object, I
think it's simpler to remove it again and just do a comparison and
assignment. We always want the result to have a specific type, so we can
just check if the value of the other type is smaller, and then convert
that to the other type if so.
libstdc++-v3/ChangeLog:
PR libstdc++/101587
* include/bits/ranges_uninitialized.h (__detail::__mindist):
Remove.
(ranges::uninitialized_copy, ranges::uninitialized_copy_n)
(ranges::uninitialized_move, ranges::uninitialized_move_n): Use
comparison and assignment instead of __mindist.
* testsuite/20_util/specialized_algorithms/uninitialized_copy/constrained.cc:
Check with ranges that use integer-like class type for
difference type.
* testsuite/20_util/specialized_algorithms/uninitialized_move/constrained.cc:
Likewise.
Reviewed-by: Tomasz Kaminski <tkaminsk@redhat.com> Reviewed-by: Hewill Kang <hewillk@gmail.com>
Tomasz Kamiński [Thu, 3 Apr 2025 15:22:39 +0000 (17:22 +0200)]
libstdc++: Provide formatter for vector<bool>::reference [PR109162]
This patch implement formatter for vector<bool>::reference which
is part of P2286R8.
To indicate partial support we define __glibcxx_format_ranges macro
value 1, without defining __cpp_lib_format_ranges.
To avoid including the whole content of the <format> header, we
introduce new bits/formatfwd.h forward declares classes required
for newly introduce formatter.
The signatures of the user-facing parse and format method of the provided
formatters deviate from the standard by constraining types of params:
* _Bit_reference instead T satisfying is-vector-bool-reference<T>
* _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 last three of above as unconstrained types, which leads
to formattable<vector<bool>::reference, char32_t> (and any other type as char)
being true.
PR libstdc++/109162
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add bits/formatfwd.h.
* include/Makefile.in: Add bits/formatfwd.h.
* include/bits/version.def: Define __glibcxx_format_ranges without
corresponding std name.
* include/bits/version.h: Regenerate.
* include/std/format (basic_format_context, __format::__char):
Move declartions to bits/formatfwd.h.
(formatter<_Tp, _CharT>): Remove default argument for _CharT
parameter, now specified in forward declaration in bits/formatfwd.h.
* include/std/vector (formatter<_Bit_reference, _CharT>): Define.
* include/bits/formatfwd.h: New file with forward declarations
for bits of std/format.
* testsuite/23_containers/vector/bool/format.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Eric Botcazou [Fri, 4 Apr 2025 09:45:23 +0000 (11:45 +0200)]
Ada: Fix thinko in Eigensystem for complex Hermitian matrices
The implementation solves the eigensystem for a NxN complex Hermitian matrix
by first solving it for a 2Nx2N real symmetric matrix and then interpreting
the 2Nx1 real vectors as Nx1 complex ones, but the last step does not work.
The patch fixes the last step and also performs a small cleanup throughout
the implementation, mostly in the commentary and without functional changes.
gcc/ada/
* libgnat/a-ngcoar.adb (Eigensystem): Adjust notation and fix the
layout of the real symmetric matrix in the main comment. Adjust
the layout of the associated code accordingly and correctly turn
the 2Nx1 real vectors into Nx1 complex ones.
(Eigenvalues): Minor similar tweaks.
* libgnat/a-ngrear.adb (Jacobi): Minor tweaks in the main comment.
Adjust notation and corresponding parameter names of functions.
Fix call to Unit_Matrix routine. Adjust the comment describing
the various kinds of iterations to match the implementation.
Jonathan Wakely [Thu, 3 Apr 2025 12:59:14 +0000 (13:59 +0100)]
libstdc++: Check feature test macro for std::string_view in <string>
We can use the __glibcxx_string_view macro to guard the uses of
std::string_view in <string>, instead of just checking the value of
__cplusplus. It makes no practical difference because
__glibcxx_string_view is defined for C++17 and up, but it makes it clear
to readers that the lines guarded by that macro are features that depend
on string_view.
We could be more precise and check __glibcxx_string_view >= 201606L
which is the value for the P0254R2 paper that integrated
std::string_view with std::string, but I think just checking for the
macro being defined is clear enough.
We can also check __glibcxx_variant for the _Never_valueless_alt partial
specialization.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h: Check __glibcxx_string_view and
__glibcxx_variant instead of __cplusplus >= 2017L.
* include/bits/cow_string.h: Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Fri, 4 Apr 2025 06:59:51 +0000 (08:59 +0200)]
tailc: Use the IPA-VRP tail call hack even for pointers [PR119614]
As the first two testcases show, even with pointers IPA-VRP can optimize
return values from functions if they have singleton ranges into just the
exact value, so we need to virtually undo that for tail calls similarly
to integers and floats. The third test just adds check that it works
even with floats (which it does).
2025-04-04 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119614
* tree-tailcall.cc (find_tail_calls): Handle also pointer types in the
IPA-VRP workaround.
* c-c++-common/pr119614-1.c: New test.
* c-c++-common/pr119614-2.c: New test.
* c-c++-common/pr119614-3.c: New test.
Thomas Schwinge [Wed, 2 Apr 2025 08:25:17 +0000 (10:25 +0200)]
nvptx: Don't use PTX '.const', constant state space [PR119573]
This avoids cases where a "File uses too much global constant data" (final
executable, or single object file), and avoids cases of wrong code generation:
"error : State space incorrect for instruction 'st'" ('st.const'), or another
case where an "illegal instruction was encountered", or a lot of cases where
for two compilation units (such as a library linked with user code) we ran into
"error : Memory space doesn't match" due to differences in '.const' usage
between definition and use of a variable.
We progress:
ptxas error : File uses too much global constant data (0x1f01a bytes, 0x10000 max)
nvptx-run: cuLinkAddData failed: a PTX JIT compilation failed (CUDA_ERROR_INVALID_PTX, 218)
... into:
PASS: 20_util/to_chars/103955.cc -std=gnu++17 (test for excess errors)
[-FAIL:-]{+PASS:+} 20_util/to_chars/103955.cc -std=gnu++17 execution test
We progress:
ptxas error : File uses too much global constant data (0x36c65 bytes, 0x10000 max)
nvptx-as: ptxas returned 255 exit status
... into:
[-UNSUPPORTED:-]{+PASS:+} gcc.c-torture/compile/pr46534.c -O0 {+(test for excess errors)+}
[-UNSUPPORTED:-]{+PASS:+} gcc.c-torture/compile/pr46534.c -O1 {+(test for excess errors)+}
[-UNSUPPORTED:-]{+PASS:+} gcc.c-torture/compile/pr46534.c -O2 {+(test for excess errors)+}
[-UNSUPPORTED:-]{+PASS:+} gcc.c-torture/compile/pr46534.c -O3 -g {+(test for excess errors)+}
[-UNSUPPORTED:-]{+PASS:+} gcc.c-torture/compile/pr46534.c -Os {+(test for excess errors)+}
[-FAIL:-]{+PASS:+} g++.dg/torture/pr31863.C -O0 (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/torture/pr31863.C -O1 (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/torture/pr31863.C -O2 (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/torture/pr31863.C -O3 -g (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/torture/pr31863.C -Os (test for excess errors)
[-FAIL:-]{+PASS:+} gfortran.dg/bind-c-contiguous-1.f90 -O0 (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} gfortran.dg/bind-c-contiguous-1.f90 -O0 [-compilation failed to produce executable-]{+execution test+}
[-FAIL:-]{+PASS:+} gfortran.dg/bind-c-contiguous-4.f90 -O0 (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} gfortran.dg/bind-c-contiguous-4.f90 -O0 [-compilation failed to produce executable-]{+execution test+}
[-FAIL:-]{+PASS:+} gfortran.dg/bind-c-contiguous-5.f90 -O0 (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} gfortran.dg/bind-c-contiguous-5.f90 -O0 [-compilation failed to produce executable-]{+execution test+}
[-FAIL:-]{+PASS:+} 20_util/to_chars/double.cc -std=gnu++17 (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} 20_util/to_chars/double.cc -std=gnu++17 [-compilation failed to produce executable-]{+execution test+}
[-FAIL:-]{+PASS:+} 20_util/to_chars/float.cc -std=gnu++17 (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} 20_util/to_chars/float.cc -std=gnu++17 [-compilation failed to produce executable-]{+execution test+}
[-FAIL:-]{+PASS:+} special_functions/13_ellint_3/check_value.cc -std=gnu++17 (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} special_functions/13_ellint_3/check_value.cc -std=gnu++17 [-compilation failed to produce executable-]{+execution test+}
[-FAIL:-]{+PASS:+} tr1/5_numerical_facilities/special_functions/14_ellint_3/check_value.cc -std=gnu++17 (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} tr1/5_numerical_facilities/special_functions/14_ellint_3/check_value.cc -std=gnu++17 [-compilation failed to produce executable-]{+execution test+}
..., and progress likewise, but fail later with an unrelated error:
[-FAIL:-]{+PASS:+} ext/special_functions/hyperg/check_value.cc -std=gnu++17 (test for excess errors)
[-UNRESOLVED:-]{+FAIL:+} ext/special_functions/hyperg/check_value.cc -std=gnu++17 [-compilation failed to produce executable-]{+execution test+}
[...]/libstdc++-v3/testsuite/ext/special_functions/hyperg/check_value.cc:12317: void test(const testcase_hyperg<Ret> (&)[Num], Ret) [with Ret = double; unsigned int Num = 19]: Assertion 'max_abs_frac < toler' failed.
..., and:
[-FAIL:-]{+PASS:+} tr1/5_numerical_facilities/special_functions/17_hyperg/check_value.cc -std=gnu++17 (test for excess errors)
[-UNRESOLVED:-]{+FAIL:+} tr1/5_numerical_facilities/special_functions/17_hyperg/check_value.cc -std=gnu++17 [-compilation failed to produce executable-]{+execution test+}
[...]/libstdc++-v3/testsuite/tr1/5_numerical_facilities/special_functions/17_hyperg/check_value.cc:12316: void test(const testcase_hyperg<Ret> (&)[Num], Ret) [with Ret = double; unsigned int Num = 19]: Assertion 'max_abs_frac < toler' failed.
We progress:
nvptx-run: error getting kernel result: an illegal instruction was encountered (CUDA_ERROR_ILLEGAL_INSTRUCTION, 715)
... into:
PASS: g++.dg/cpp1z/inline-var1.C -std=gnu++17 (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/cpp1z/inline-var1.C -std=gnu++17 execution test
PASS: g++.dg/cpp1z/inline-var1.C -std=gnu++20 (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/cpp1z/inline-var1.C -std=gnu++20 execution test
PASS: g++.dg/cpp1z/inline-var1.C -std=gnu++26 (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/cpp1z/inline-var1.C -std=gnu++26 execution test
(A lot of '.const' -> '.global' etc. Haven't researched what the actual
problem was.)
We progress:
ptxas /tmp/cc5TSZZp.o, line 142; error : State space incorrect for instruction 'st'
ptxas /tmp/cc5TSZZp.o, line 174; error : State space incorrect for instruction 'st'
ptxas fatal : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
... into:
[-FAIL:-]{+PASS:+} g++.dg/torture/builtin-clear-padding-1.C -O0 (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} g++.dg/torture/builtin-clear-padding-1.C -O0 [-compilation failed to produce executable-]{+execution test+}
PASS: g++.dg/torture/builtin-clear-padding-1.C -O1 (test for excess errors)
PASS: g++.dg/torture/builtin-clear-padding-1.C -O1 execution test
[-FAIL:-]{+PASS:+} g++.dg/torture/builtin-clear-padding-1.C -O2 (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} g++.dg/torture/builtin-clear-padding-1.C -O2 [-compilation failed to produce executable-]{+execution test+}
[-FAIL:-]{+PASS:+} g++.dg/torture/builtin-clear-padding-1.C -O3 -g (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} g++.dg/torture/builtin-clear-padding-1.C -O3 -g [-compilation failed to produce executable-]{+execution test+}
[-FAIL:-]{+PASS:+} g++.dg/torture/builtin-clear-padding-1.C -Os (test for excess errors)
[-UNRESOLVED:-]{+PASS:+} g++.dg/torture/builtin-clear-padding-1.C -Os [-compilation failed to produce executable-]{+execution test+}
This indeed tried to write ('st.const') into 's2', which was '.const'
(also: 's1' was '.const') -- even though, no explicit 'const' in
'g++.dg/torture/builtin-clear-padding-1.C'; "interesting".
We progress:
error : Memory space doesn't match for '_ZNSt3tr18__detail12__prime_listE' in 'input file 3 at offset 53085', first specified in 'input file 1 at offset 1924'
nvptx-run: cuLinkAddData failed: device kernel image is invalid (CUDA_ERROR_INVALID_SOURCE, 300)
... into execution test PASS for a few dozens of libstdc++ test cases.
We progress:
error : Memory space doesn't match for '_ZNSt6locale17_S_twinned_facetsE' in 'input file 11 at offset 479903', first specified in 'input file 9 at offset 59300'
nvptx-run: cuLinkAddData failed: device kernel image is invalid (CUDA_ERROR_INVALID_SOURCE, 300)
... into:
PASS: g++.dg/tree-ssa/pr20458.C -std=gnu++17 (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/tree-ssa/pr20458.C -std=gnu++17 execution test
PASS: g++.dg/tree-ssa/pr20458.C -std=gnu++26 (test for excess errors)
[-FAIL:-]{+PASS:+} g++.dg/tree-ssa/pr20458.C -std=gnu++26 execution test
..., and likewise for a few hundreds of libstdc++ test cases.
We progress:
error : Memory space doesn't match for '_ZNSt6locale5_Impl19_S_facet_categoriesE' in 'input file 11 at offset 821962', first specified in 'input file 10 at offset 676317'
nvptx-run: cuLinkAddData failed: device kernel image is invalid (CUDA_ERROR_INVALID_SOURCE, 300)
... into execution test PASS for a hundred of libstdc++ test cases.
We progress:
error : Memory space doesn't match for '_ctype_' in 'input file 22 at offset 1698331', first specified in 'input file 9 at offset 57095'
nvptx-run: cuLinkAddData failed: device kernel image is invalid (CUDA_ERROR_INVALID_SOURCE, 300)
... into execution test PASS for another few libstdc++ test cases.
PR target/119573
gcc/
* config/nvptx/nvptx.cc (nvptx_encode_section_info): Don't set
'DATA_AREA_CONST' for 'TREE_CONSTANT', or 'TREE_READONLY'.
(nvptx_asm_declare_constant_name): Use '.global' instead of
'.const'.
gcc/testsuite/
* gcc.c-torture/compile/pr46534.c: Don't 'dg-skip-if' nvptx.
* gcc.target/nvptx/decl.c: Adjust.
libstdc++-v3/
* config/cpu/nvptx/t-nvptx (AM_MAKEFLAGS): Don't amend.
Patrick Palka [Thu, 3 Apr 2025 20:33:46 +0000 (16:33 -0400)]
c++: P2280R4 and speculative constexpr folding [PR119387]
Compiling the testcase in this PR uses 2.5x more memory and 6x more
time ever since r14-5979 which implements P2280R4. This is because
our speculative constexpr folding now does a lot more work trying to
fold ultimately non-constant calls to constexpr functions, and in turn
produces a lot of garbage. We do sometimes successfully fold more
thanks to P2280R4, but it seems to be trivial stuff like calls to
std::array::size or std::addressof. The benefit of P2280 therefore
doesn't seem worth the cost during speculative constexpr folding, so
this patch restricts the paper to only manifestly-constant evaluation.
PR c++/119387
gcc/cp/ChangeLog:
* constexpr.cc (p2280_active_p): New.
(cxx_eval_constant_expression) <case VAR_DECL>: Use it to
restrict P2280 relaxations.
<case PARM_DECL>: Likewise.
Jason Merrill [Tue, 1 Apr 2025 23:22:18 +0000 (19:22 -0400)]
c++/modules: inline loaded at eof
std/format/string.cc and a few other libstdc++ tests were failing with
module std with undefined references to __failed_to_parse_format_spec. This
turned out to be because since r15-8012 we don't end up calling
note_vague_linkage_fn for functions loaded after at_eof is set.
But once import_export_decl decides on COMDAT linkage, we should be able to
just clear DECL_EXTERNAL and let cgraph take it from there.
I initially made this change in import_export_decl, but decided that for GCC
15 it would be safer to limit the change to modules. For GCC 16 I'd like to
do away with DECL_NOT_REALLY_EXTERN entirely, it's been obsolete since
cgraphunit in 2003.
gcc/cp/ChangeLog:
* module.cc (module_state::read_cluster)
(post_load_processing): Clear DECL_EXTERNAL if DECL_COMDAT.
Jason Merrill [Tue, 1 Apr 2025 17:04:05 +0000 (13:04 -0400)]
c++: operator!= rewriting and arg-dep lookup
When considering an op== as a rewrite target, we need to disqualify it if
there is a matching op!= in the same scope. But add_candidates was assuming
that we could use the same set of op!= for all op==, which is wrong if
arg-dep lookup finds op== in multiple namespaces.
This broke 20_util/optional/relops/constrained.cc if the order of the ADL
set changed.
gcc/cp/ChangeLog:
* call.cc (add_candidates): Re-lookup ne_fns if we move into
another namespace.
Looking over the recently-committed change to the musttail attribute
documentation, it appears the comment in the last example was a paste-o,
as it does not agree with either what the similar example in the
-Wmaybe-musttail-local-addr documentation says, or the actual behavior
observed when running the code.
In addition, the entire section on musttail was in need of copy-editing
to put it in the present tense, avoid reference to "the user", etc. I've
attempted to clean it up here.
gcc/ChangeLog
* doc/extend.texi (Statement Attributes): Copy-edit the musttail
attribute documentation and correct the comment in the last
example.
Using specific SSA names in pattern matching in `dg-final' makes tests
"unstable", in that changes in passes prior to the pass whose dump is
analyzed in the particular test may change the numbering of the SSA
variables, causing the test to start failing spuriously.
We thus switch from specific SSA names to the use of a multi-line
regular expression making use of capture groups for matching particular
variables across different statements, ensuring the test will pass
more consistently across different versions of GCC.
PR testsuite/118597
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-fncall-mask.c: Update test directives.
Iain Sandoe [Tue, 25 Mar 2025 15:10:12 +0000 (15:10 +0000)]
libgcobol: Provide fallbacks for C32 strfromf32/64 functions.
strfrom{f,d,l,fN) are all C23 and might not be available in general.
This uses snprintf() to provide fall-backs where the libc does not
yet have support.
libgcobol/ChangeLog:
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for availability of strfromf32 and
strfromf64.
* libgcobol.cc (strfromf32, strfromf64): New.
Tomasz Kamiński [Thu, 3 Apr 2025 08:23:45 +0000 (10:23 +0200)]
libstdc++: Fix handling of field width for wide strings and characters [PR119593]
This patch corrects handling of UTF-32LE and UTF32-BE in
__unicode::__literal_encoding_is_unicode<_CharT>, so they are
recognized as unicode and functions produces correct result for wchar_t.
Use `__unicode::__field_width` to compute the estimated witdh
of the charcter for unicode wide encoding.
PR libstdc++/119593
libstdc++-v3/ChangeLog:
* include/bits/unicode.h
(__unicode::__literal_encoding_is_unicode<_CharT>):
Corrected handing for UTF-16 and UTF-32 with "LE" or "BE" suffix.
* include/std/format (__formatter_str::_S_character_width):
Define.
(__formatter_str::_S_character_width): Updated passed char
length.
* testsuite/std/format/functions/format.cc: Test for wchar_t.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Thu, 3 Apr 2025 11:21:56 +0000 (13:21 +0200)]
c++: Fix typo in RAW_DATA_CST build_list_conv subsubconv hanling [PR119563]
The following testcase ICEs (the embed one actually doesn't but
dereferences random uninitialized pointer far after allocated memory)
because of a typo. In the RAW_DATA_CST handling of list conversion
where there are conversions to something other than
initializer_list<{{,un}signed ,}char>, the code now calls
implicit_conversion for all the RAW_DATA_CST elements and stores them
into subsubconvs array.
The next loop (done in a separate loop because subsubconvs[0] is
handled differently) attempts to do the
for (i = 0; i < len; ++i)
{
conversion *sub = subconvs[i];
if (sub->rank > t->rank)
t->rank = sub->rank;
if (sub->user_conv_p)
t->user_conv_p = true;
if (sub->bad_p)
t->bad_p = true;
}
rank/user_conv_p/bad_p merging, but I mistyped the index, the loop
iterates with j iterator and i is subconvs index, so the loop effectively
doesn't do anything interesting except for merging from one of the
subsubconvs element, if lucky within the subsubconvs array, if unlucky
not even from inside of the array.
The following patch fixes that.
2025-04-03 Andrew Pinski <quic_apinski@quicinc.com>
Jakub Jelinek <jakub@redhat.com>
PR c++/119563
* call.cc (build_list_conv): Fix a typo in loop gathering
summary information from subsubconvs.
* g++.dg/cpp0x/pr119563.C: New test.
* g++.dg/cpp/embed-26.C: New test.
Jan Hubicka [Thu, 3 Apr 2025 11:06:07 +0000 (13:06 +0200)]
Fix costs of x86 move instructions at -Os
This patch fixes problem with size costs declaring all moves to have equal size
(which was caught by the sanity check I tried in prologue move cost hook).
Costs are relative to reg-reg move which is two. Coincidentally it is also size
of the encoding, so the costs should represent typical size of move
instruction.
The patch reduces cc1plus text size 26391115->26205707 (0.7%) and similar changes
also happens to other binaries build during bootstrap.
Bootsrapped/regtested x86_64-linux, plan to commit it tomorrow if there
are no complains
There are other targets that define some load/store costs to be 2 that probably
should be fixed too, but they are mostly very old ones and I don't have way of
benchmarking them.
* config/i386/x86-tune-costs.h (ix86_size_cost): Fix sizes of move
instructions
All tests FAIL as is because they lack either or both of the .LFB0 label
and the .cfi_startproc directive:
* The 32-bit pr82142b.c test lacks both, whether as or gas is in use: as
lacks full support for the cfi directives and the .LFB0 label is only
emitted with -fasynchronous-unwind-tables.
* The 64-bit tests pr111673.c and pr82142a.c already work with gas, but
with as the cfi directives are again missing.
In addition, the 32-bit test (pr82142b.c) still FAILs because 32-bit
Solaris/x86 defaults to -mstackrealign.
To fix all this, this patch adds -fasynchronous-unwind-tables
-fdwarf2-cfi-asm to all tests to force the generation of both the .LFB0
label and .cfi_startproc (which is ok since they are compile tests). In
addition, pr82142b.c is compiled with -mno-stackrealign to avoid
platform differences.
Tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu.
Jakub Jelinek [Thu, 3 Apr 2025 06:46:03 +0000 (08:46 +0200)]
c-family: Regenerate c.opt.urls
On Sun, Mar 30, 2025 at 02:48:43PM +0200, Martin Uecker wrote:
> The warning -Wzero-as-null-pointer-constant is now not only supported
> in C++ but also in C. Change the documentation accordingly.
This change didn't include make regenerate-opt-urls changes, because
moving option documentation to different section can affect the *.urls
files.
Jakub Jelinek [Thu, 3 Apr 2025 06:32:09 +0000 (08:32 +0200)]
fold-const, cobol: Add native_encode_wide_int and use it in COBOL FE [PR119242]
As has been mentioned earlier, various parts of the COBOL FE and the library
aren't endian clean. In the library that means that for now we have to
live with no support for big endian targets, but in the FE that means
that as well as not being able to build cross-compilers from big endian
or pdp endian hosts to little endian targets which are otherwise supported.
The following patch attempts to fix one such spot, where it wants to encode
in target byte ordering wide_int constants into 1, 2, 4, 8 or 16 bytes.
We could wide_int_to_tree and then native_encode_expr, but so that we don't
need to build the constants, the following patch exports from fold-const.cc
a helper for native_encode_int which takes type and const wide_int_ref
reference rather than an expression.
2025-04-03 Jakub Jelinek <jakub@redhat.com>
PR cobol/119242
gcc/
* fold-const.h (native_encode_wide_int): Declare.
* fold-const.cc (native_encode_wide_int): New function.
(native_encode_int): Use it.
gcc/cobol/
* genapi.cc (binary_initial_from_float128): Use
native_encode_wide_int.
The desired vw{add,sub}.wx instructions don't come up on rv32 for the
first two functions, we get v{add,sub}.vx instead.
I suppose this is an oversight, and something about the test is meant
for rv64 only, but the fact that the instruction is spelled out in the
intrinsic name and a different instruction is generated suggests
something may be wrong after all.
[testsuite] [riscv] limit mcpu-xiangshan-nanhu.c to rv64
The testcase makes the -march option conditional on rv64, and #errors
out if the desired CPU properties are not active. This makes the test
fail on rv32. Arrange to skip the test on rv32 instead, moving the
rv64 conditional.
for gcc/testsuite/ChangeLog
* gcc.target/riscv/mcpu-xiangshan-nanhu.c: Skip on non-rv64.
Some of the tests regressed with a fix for the vectorization of
shifts. The riscv cost models need to be adjusted to avoid the
unprofitable optimization. The failure of these tests has been known
since 2024-03-13, without a forthcoming fix, so I suggest we consider
it expected by now. Adjust the tests to reflect that expectation.
[testsuite] [riscv] xfail ssa-dom-cse-2 on riscv64
For the same reasons that affect alpha and other targets,
gcc.dg/tree-ssa/ssa-dom-cse-2.c fails to be optimized to the expected
return statement: the array initializer is vectorized into pairs, and
DOM cannot see through that.
Add riscv*-*-* to the list of affected lp64 platforms. riscv32 is
not affected.
for gcc/testsuite/ChangeLog
* gcc.dg/tree-ssa/ssa-dom-cse-2.c: XFAIL on riscv lp64.
Hongyu Wang [Mon, 31 Mar 2025 08:39:23 +0000 (16:39 +0800)]
APX: Emit nf variant for rotl splitter with mask [PR 119539]
For spiltter after *<rotate_insn><mode>3_mask it now splits the pattern
to *<rotate_insn><mode>3_mask with flag reg clobber, and it doesn't
generate nf variant of rotate. Directly emit nf pattern when
TARGET_APX_NF enabled in these define_insn_and_split.
gcc/ChangeLog:
PR target/119539
* config/i386/i386.md (*<insn><mode>3_mask): Emit NF variant of
rotate when APX_NF enabled, and use force_lowpart_subreg.
(*<insn><mode>3_mask_1): Likewise.
gcc/testsuite/ChangeLog:
PR target/119539
* gcc.target/i386/apx-nf-pr119539.c: New test.
This issue was specifically about a confusing mention of the "second
and third arguments to the memcpy function" when only the second one
is a pointer affected by the attribute, but reading through the entire
discussion I found other things confusing as well; e.g. in some cases
it wasn't clear whether the "arguments" were the arguments to the
attribute or the function, or exactly what a "positional argument"
was. I've tried to rewrite that part to straighten it out, as well as
some light copy-editing throughout.
gcc/ChangeLog
PR c/101440
* doc/extend.texi (Common Function Attributes): Clean up some
confusing language in the description of the "access" attribute.
Doc: Improve wording of -Werror documentation [PR58973]
gcc/ChangeLog
PR driver/58973
* common.opt (Werror, Werror=): Use less awkward wording in
description.
(pedantic-errors): Likewise.
* doc/invoke.texi (Warning Options): Likewise for -Werror and
-Werror= here.
This reverts a change in the upstream D implementation of the compiler,
as it is no longer necessary since another fix for opDispatch got
applied in the same area (merged in r12-6003-gfd43568cc54e17).
Since r15-9062-g70391e3958db79 we perform vector bitmask initialization
via the vec_duplicate expander directly. This triggered a latent bug in
ours where we missed to mask out the single bit which resulted in an
execution FAIL of pr119114.c
The attached patch adds the 1-masking of the broadcast operand.
Bob Dubner [Wed, 2 Apr 2025 16:18:08 +0000 (12:18 -0400)]
cobol: Plug memory leak caused by intermediate_e stack-frame variables. [PR119521]
COBOL variables with attribute intermediate_e are being allocated on
the stack frame, but their data was assigned using malloc(), without
a corresponding call to free(). For numerics, the problem is solved
with a fixed allocation of sixteen bytes for the cblc_field_t::data
member (sixteen is big enough for all data types) and with a fixed
allocation of 8,192 bytes for the alphanumeric type.
In use, the intermediate numeric data types are "shrunk" to the minimum
applicable size. The intermediate alphanumerics, generally used as
destination targets for functions, are trimmed as well.
gcc/cobol
PR cobol/119521
* genapi.cc: (parser_division): Change comment.
(parser_symbol_add): Change intermediate_t handling.
* parse.y: Multiple changes to new_alphanumeric() calls.
* parse_ante.h: Establish named constant for date function
calls. Change declaration of new_alphanumeric() function.
* symbols.cc: (new_temporary_impl): Use named constant
for default size of temporary alphanumerics.
* symbols.h: Establish MAXIMUM_ALPHA_LENGTH constant.
libgcobol
PR cobol/119521
* intrinsic.cc: (__gg__reverse): Trim final result for intermediate_e.
* libgcobol.cc: (__gg__adjust_dest_size): Abort on attempt to increase
the size of a result. (__gg__module_name): Formatting.
__gg__reverse(): Resize only intermediates
This patch addresses a number of issues with the documentation of
- None of the things in this section had @cindex entries [PR114957].
- The document formatting didn't match that of other #pragma
documentation sections.
- The effect of #pragma pack(0) wasn't documented [PR78008].
- There's a long-standing bug [PR60972] reporting that #pragma pack
and the __attribute__(packed) don't get along well. It seems worthwhile
to warn users about that since elsewhere pragmas are cross-referenced
with related or equivalent attributes.
gcc/ChangeLog
PR c/114957
PR c/78008
PR c++/60972
* doc/extend.texi (Structure-Layout Pragmas): Add @cindex
entries and reformat the pragma descriptions to match the markup
used for other pragmas. Document what #pragma pack(0) does.
Add cross-references to similar attributes.
Jakub Jelinek [Wed, 2 Apr 2025 18:02:34 +0000 (20:02 +0200)]
tailc: Deal with trivially useless EH cleanups [PR119491]
The following testcases FAIL, because EH cleanup is performed only before
IPA and then right before musttail pass.
At -O2 etc. (except for -O0/-Og) we handle musttail calls in the tailc
pass though, and we can fail at that point because the calls might appear
to throw internal exceptions which just don't do anything interesting
(perhaps have debug statements or clobber statements in them) before they
continue with resume of the exception (i.e. throw it externally).
As Richi said in the PR (and I agree) that moving passes is risky at this
point, the following patch instead teaches the tail{r,c} and musttail
passes to deal with such extra EDGE_EH edges.
It is fairly simple thing, if we see an EDGE_EH edge from the call we
just look up where it lands and if there are no
non-debug/non-clobber/non-label statements before resx which throws
externally, such edge can be ignored for tail call optimization or
tail recursion. At other spots I just need to avoid using
single_succ/single_succ_edge because the bb might have another edge -
EDGE_EH.
To make this less risky, this is done solely for the musttail calls for now.
2025-04-02 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119491
* tree-tailcall.cc (single_non_eh_succ_edge): New function.
(independent_of_stmt_p): Use single_non_eh_succ_edge (bb)->dest
instead of single_succ (bb).
(empty_eh_cleanup): New function.
(find_tail_calls): Diagnose throwing of exceptions which do not
propagate only if there are no EDGE_EH successor edges. If there are
and the call is musttail, use empty_eh_cleanup to find if the cleanup
is not empty. If not or the call is not musttail, use different
diagnostics. Set is_noreturn even if there are successor edges. Use
single_non_eh_succ_edge (abb) instead of single_succ_edge (abb). Punt
on internal noreturn calls.
(decrease_profile): Don't assert 0 or 1 successor edges.
(eliminate_tail_call): Use
single_non_eh_succ_edge (gsi_bb (t->call_gsi)) instead of
single_succ_edge (gsi_bb (t->call_gsi)).
(tree_optimize_tail_calls_1): Also look into basic blocks with
single succ edge which is EDGE_EH for noreturn musttail calls.
* g++.dg/opt/musttail3.C: New test.
* g++.dg/opt/musttail4.C: New test.
* g++.dg/opt/musttail5.C: New test.
Jakub Jelinek [Wed, 2 Apr 2025 17:28:20 +0000 (19:28 +0200)]
c: Fix ICEs with -fsanitize=pointer-{subtract,compare} [PR119582]
The following testcase ICEs because c_fully_fold isn't performed on the
arguments of __sanitizer_ptr_{sub,cmp} builtins and so e.g.
C_MAYBE_CONST_EXPR can leak into the gimplifier where it ICEs.
2025-04-02 Jakub Jelinek <jakub@redhat.com>
PR c/119582
* c-typeck.cc (pointer_diff, build_binary_op): Call c_fully_fold on
__sanitizer_ptr_sub or __sanitizer_ptr_cmp arguments.
As noted in PR 118965, the initial interop implementation overlooked
the requirement in the OpenMP spec that at least one of the "target"
and "targetsync" modifiers is required in both the interop construct
init clause and the declare variant append_args clause.
Adding the check was fairly straightforward, but it broke about a
gazillion existing test cases. In particular, things like "init (x, y)"
which were previously accepted (and tested for being accepted) aren't
supposed to be allowed by the spec, much less things like "init (target)"
where target was previously interpreted as a variable name instead of a
modifier. Since one of the effects of the change is that at least one
modifier is always required, I found that deleting all the code that was
trying to detect and handle the no-modifier case allowed for better
diagnostics.
gcc/fortran/ChangeLog
PR middle-end/118965
* openmp.cc (gfc_parser_omp_clause_init_modifiers): Fix some
inconsistent code indentation. Remove code for recognizing
clauses without modifiers. Diagnose prefer_type without a
following paren. Adjust error message for an unrecognized modifier.
Diagnose missing target/targetsync modifier.
(gfc_match_omp_init): Fix more inconsistent code indentation.
Iain Sandoe [Mon, 31 Mar 2025 06:02:54 +0000 (07:02 +0100)]
config, toplevel, Darwin: Pass -B instead of -L to C++ commands.
Darwin from 10.11 needs embedded rpaths to find the correct libraries at
runtime. Recent increases in hardening have made it such that the dynamic
loader will no longer fall back to using an installed libstdc++ when the
(new) linked one is not found. This means we fail configure tests (that
should pass) for runtimes that use C++.
We can resolve this by passing '-B' to the C++ command lines instead of '-L'
(-B implies -L on Darwin, but also causes a corresponding embedded rpath).
ChangeLog:
* configure: Regenerate.
* configure.ac: Use -B instead of -L to specifiy the C++ runtime
paths on Darwin.
libstdc++, testsuite, Darwin: Prune a new linker warning present form XCode 16.
Darwin's linker now warns when duplicate rpaths are presented - which
happens when we emit duplicate '-B' paths. In principle, we should avoid
this in the test-suite, however at present we tend to have duplicates
because different parts of the machinery add them. At some point, it might
be nice to have an "add_option_if_missing" and apply that across the whole
of the test infra. However this is not something for late in stage 4. So
the solution here is to prune the warning - the effect of the duplicate in
the libstdc++ testsuite is not important; it will make the exes very slightly
larger but it won't alter the paths that are presented for loading the
runtimes.
libstdc++-v3/ChangeLog:
* testsuite/lib/prune.exp: Prune ld warning about duplicatei
rpaths.
Richard Biener [Wed, 2 Apr 2025 11:12:58 +0000 (13:12 +0200)]
tree-optimization/119586 - aligned access to unaligned data
The following reverts parts of r15-8047 which assesses alignment
analysis for VMAT_STRIDED_SLP is correct by using aligned accesses
where allowed by it. As the PR shows this analysis is still incorrect,
so revert back to assuming we got it wrong.
PR tree-optimization/119586
* tree-vect-stmts.cc (vectorizable_load): Assume we got
alignment analysis for VMAT_STRIDED_SLP wrong.
(vectorizable_store): Likewise.
Jakub Jelinek [Wed, 2 Apr 2025 10:36:29 +0000 (12:36 +0200)]
doc: Extend musttail attribute docs
On Wed, Apr 02, 2025 at 10:32:20AM +0200, Richard Biener wrote:
> I wonder if we can amend the documentation to suggest to end lifetime
> of variables explicitly by proper scoping?
In the -Wmaybe-musttail-local-addr attribute description I've already
tried to show that in the example, but if you think something like
the following would make it clearer.
2025-04-02 Jakub Jelinek <jakub@redhat.com>
* doc/extend.texi (musttail statement attribute): Hint how
to avoid -Wmaybe-musttail-local-addr warnings.
Jonathan Wakely [Tue, 18 Mar 2025 18:37:01 +0000 (18:37 +0000)]
cobol: Fix incorrect use of std::remove_if
The call to std::remove_if used here doesn't remove any elements, it
just overwrites the "removed" elements with later elements, leaving the
total number of elements unchanged. Use std::list::remove_if to actually
remove those unwanted elements from the list.
gcc/cobol/ChangeLog:
* symfind.cc (finalize_symbol_map2): Use std::list::remove_if
instead of std::remove_if.
Jakub Jelinek [Wed, 2 Apr 2025 08:51:42 +0000 (10:51 +0200)]
tailc: Don't fail musttail calls if they use or could use local arguments, instead warn [PR119376]
As discussed here and in bugzilla, [[clang::musttail]] attribute in clang
not just strongly asks for tail call or error, but changes behavior.
To quote:
https://clang.llvm.org/docs/AttributeReference.html#musttail
"The lifetimes of all local variables and function parameters end immediately
before the call to the function. This means that it is undefined behaviour
to pass a pointer or reference to a local variable to the called function,
which is not the case without the attribute. Clang will emit a warning in
common cases where this happens."
The GCC behavior was just to error if we can't prove the musttail callee
could not have dereferenced escaped pointers to local vars or parameters
of the caller. That is still the case for variables with non-trivial
destruction (even in clang), like vars with C++ non-trivial destructors or
variables with cleanup attribute.
The following patch changes the behavior to match that of clang, for all of
[[clang::musttail]], [[gnu::musttail]] and __attribute__((musttail)).
clang 20 actually added warning for some cases of it in
https://github.com/llvm/llvm-project/pull/109255
but it is under -Wreturn-stack-address warning.
Now, gcc doesn't have that warning, but -Wreturn-local-addr instead, and
IMHO it is better to have this under new warnings, because this isn't about
returning local address, but about passing it to a musttail call, or maybe
escaping to a musttail call. And perhaps users will appreciate they can
control it separately as well.
The patch introduces 2 new warnings.
-Wmusttail-local-addr
which is turn on by default and warns for the always dumb cases of passing
an address of a local variable or parameter to musttail call's argument.
And then
-Wmaybe-musttail-local-addr
which is only diagnosed if -Wmusttail-local-addr was not diagnosed and
diagnoses at most one (so that we don't emit 100s of warnings for one call
if 100s of vars can escape) case where an address of a local var could have
escaped to the musttail call. This is less severe, the code doesn't have
to be obviously wrong, so the warning is only enabled in -Wextra.
And I've adjusted also the documentation for this change and addition of
new warnings.
2025-04-02 Jakub Jelinek <jakub@redhat.com>
PR ipa/119376
* common.opt (Wmusttail-local-addr, Wmaybe-musttail-local-addr): New.
* tree-tailcall.cc (suitable_for_tail_call_opt_p): Don't fail for
TREE_ADDRESSABLE PARM_DECLs for musttail calls if diag_musttail.
Emit -Wmusttail-local-addr warnings.
(maybe_error_musttail): Use gimple_location instead of directly
accessing location member.
(find_tail_calls): For musttail calls if diag_musttail, don't fail
if address of local could escape to the call, instead emit
-Wmaybe-musttail-local-addr warnings. Emit
-Wmaybe-musttail-local-addr warnings also for address taken
parameters.
* common.opt.urls: Regenerate.
* doc/extend.texi (musttail statement attribute): Clarify local
variables without non-trivial destruction are considered out of scope
before the tail call instruction.
* doc/invoke.texi (-Wno-musttail-local-addr,
-Wmaybe-musttail-local-addr): Document.
* c-c++-common/musttail8.c: Expect a warning rather than error in one
case.
(f4): Add int * argument.
* c-c++-common/musttail15.c: Don't disallow for C++98.
* c-c++-common/musttail16.c: Likewise.
* c-c++-common/musttail17.c: Likewise.
* c-c++-common/musttail18.c: Likewise.
* c-c++-common/musttail19.c: Likewise. Expect a warning rather than
error in one case.
(f4): Add int * argument.
* c-c++-common/musttail20.c: Don't disallow for C++98.
* c-c++-common/musttail21.c: Likewise.
* c-c++-common/musttail28.c: New test.
* c-c++-common/musttail29.c: New test.
* c-c++-common/musttail30.c: New test.
* c-c++-common/musttail31.c: New test.
* g++.dg/ext/musttail1.C: New test.
* g++.dg/ext/musttail2.C: New test.
* g++.dg/ext/musttail3.C: New test.
projects / thirdparty / gcc.git / log
