Philip Herron [Thu, 27 Mar 2025 12:04:41 +0000 (12:04 +0000)]
gccrs: Fix ICE when compiling block expressions in array capacity
We need to reuse the existing compile_constant_item helper which handles
the case if this is a simple expression, fn-call or a block expression.
The patch extracts out this helper as a static method so this can be used
in more places.
Philip Herron [Wed, 26 Mar 2025 19:00:41 +0000 (19:00 +0000)]
gccrs: Add check for super traits being implemented by Self
We need to recursively check the super traits of the predicate the Self
type is trying to implement. Otherwise its cannot implement it.
Fixes Rust-GCC#3553
gcc/rust/ChangeLog:
* typecheck/rust-hir-type-check-item.cc (TypeCheckItem::resolve_impl_block_substitutions):
Track the polarity
* typecheck/rust-tyty-bounds.cc (TypeBoundPredicate::validate_type_implements_this):
new validator
* typecheck/rust-tyty.h: new prototypes
gcc/testsuite/ChangeLog:
* rust/compile/issue-3553.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Philip Herron [Wed, 26 Mar 2025 17:11:36 +0000 (17:11 +0000)]
gccrs: Fix ICE when array elements are not a value
We need to check for error_mark_node when doing adjustments from coercion
sites otherwise we hit assetions as part of the coercion. That fixes the
ICE but the reason for the error_mark_node is because the array element
value.
Fixes Rust-GCC#3567
gcc/rust/ChangeLog:
* backend/rust-compile-expr.cc (CompileExpr::array_value_expr): add value chk for array expr
gcc/testsuite/ChangeLog:
* rust/compile/issue-3567.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Philip Herron [Wed, 26 Mar 2025 14:05:03 +0000 (14:05 +0000)]
gccrs: fix unconstrained infer vars on generic associated type
The trick here is that when Bar::test is resolved it resolves to the
trait method:
fn <Bar<i32>, T> (placeholder) -> placeholder
Which is fine so we need to setup the associated types for Bar<i32> which
means looking up the associated impl block then setting up the projection
of A = T so it becomes:
The issue is that the binding of the generics was still T so this caused
inference variables to be injected again but unlinked. A possible tweak
would be that we are substituting again with new infer vars to actually
just unify them enplace so they are all part of the chain. This still
might be needed but lets hold off for now.
So basically when we are Path probing we dont allow GAT's to generate new
inference vars because they wont be bound to this current segment which
just causes confusion.
Fixes Rust-GCC#3242
gcc/rust/ChangeLog:
* typecheck/rust-hir-trait-reference.h: add default infer arg
* typecheck/rust-hir-trait-resolve.cc: dont add new infer vars
* typecheck/rust-hir-type-check-path.cc (TypeCheckExpr::resolve_segments): dont infer
gcc/testsuite/ChangeLog:
* rust/compile/issue-3242.rs: no longer skip the test
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Owen Avery [Tue, 25 Mar 2025 22:18:21 +0000 (18:18 -0400)]
gccrs: Fix validation of constant items
gcc/rust/ChangeLog:
* checks/errors/rust-ast-validation.cc
(ASTValidation::visit): Allow constant items lacking expressions
if and only if they're associated with a trait definition, not a
trait implementation.
gcc/testsuite/ChangeLog:
* rust/compile/issue-3541-1.rs: New test.
* rust/compile/issue-3541-2.rs: Likewise.
Arthur Cohen [Mon, 24 Mar 2025 14:32:51 +0000 (15:32 +0100)]
rust: Lower minimum supported Rust version to 1.49
gcc/rust/ChangeLog:
* checks/errors/borrowck/ffi-polonius/Cargo.lock: Regenerate.
* checks/errors/borrowck/ffi-polonius/Cargo.toml: Update to use source patching instead of
vendoring, lower edition to 2018.
* checks/errors/borrowck/ffi-polonius/vendor/log/Cargo.toml: Change edition to 2018.
* checks/errors/borrowck/ffi-polonius/vendor/log/src/lib.rs: Remove uses of unstable
feature.
* checks/errors/borrowck/ffi-polonius/.cargo/config.toml: Removed.
libgrust/ChangeLog:
* libformat_parser/Makefile.am: Avoid using --config as it is unsupported by cargo 1.49.
* libformat_parser/Makefile.in: Regenerate.
* libformat_parser/generic_format_parser/src/lib.rs: Use extension trait for missing
features.
* libformat_parser/src/lib.rs: Likewise.
* libformat_parser/.cargo/config: Moved to...
* libformat_parser/.cargo/config.toml: ...here.
Owen Avery [Thu, 20 Mar 2025 16:17:20 +0000 (12:17 -0400)]
gccrs: nr2.0: Fix test const_generics_3.rs
gcc/testsuite/ChangeLog:
* rust/compile/const_generics_3.rs: Modify test to run with name
resolution 2.0 only and to handle the absence of a bogus
resolution error.
* rust/compile/nr2/exclude: Remove const_generics_3.rs.
Those tests are coming from libcore and module inlining was wrong, in
libcore there was a use declaration to import those modules which was
missing here.
Function could not be found and triggered an error message.
gcc/testsuite/ChangeLog:
* rust/compile/feature_rust_attri0.rs: Add extern
function declaration and change name to printf.
* rust/compile/nr2/exclude: Remove now passing test from exclusion
list.
Jørgen Kvalsvik [Mon, 31 Mar 2025 17:03:37 +0000 (19:03 +0200)]
Only write gcov when file output is on [PR119553]
gcov_write_* functions must be guarded so they only are called when
output_to_file is true, like for -fcondition-coverage, otherwise it
triggers an invalid read as detected by valgrind. The gcno file is
mostly written to from profile.cc, so it doesn't make too much sense
to hide it in path-coverage.cc. The find_paths name was a bit
imprecise, and is renamed to instrument_prime_paths.
PR gcov-profile/119553
gcc/ChangeLog:
* path-coverage.cc (find_paths): Return path count, don't
write to gcno, and rename to ...
(instrument_prime_paths): ... this.
* profile.cc (branch_prob): Write path counts to gcno.
Jonathan Wakely [Mon, 31 Mar 2025 16:07:55 +0000 (17:07 +0100)]
libstdc++: Tweak linker script to avoid conflict on Solaris
The new symbols for the _M_construct<bool> function template match an
existing pattern in the GLIBCXX_3.4.21 version, as well as the intended
pattern in the GLIBCXX_3.4.34 version. That causes a linker error on
Solaris.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Make
std::basic_string::_M_construct patterns more precise.
Iain Buclaw [Sat, 29 Mar 2025 22:16:25 +0000 (23:16 +0100)]
d: Fix error with -Warray-bounds and -O2 [PR117002]
The record layout of class types in D don't get any tail padding, so it
is possible for the `classInstanceSize' to not be a multiple of the
`classInstanceAlignment'.
Rather than setting the instance alignment on the underlying
RECORD_TYPE, instead give the type an alignment of 1, which will mark it
as TYPE_PACKED. The value of `classInstanceAlignment' is instead
applied to the DECL_ALIGN of both the static `init' symbol, and the
stack allocated variable used when generating `new' for a `scope' class.
PR d/117002
gcc/d/ChangeLog:
* decl.cc (aggregate_initializer_decl): Set explicit decl alignment of
class instance.
* expr.cc (ExprVisitor::visit (NewExp *)): Likewise.
* types.cc (TypeVisitor::visit (TypeClass *)): Mark the record type of
classes as packed.
Marek Polacek [Thu, 27 Mar 2025 19:03:18 +0000 (15:03 -0400)]
c++: fix reporting routines re-entered [PR119303]
We crash while we call warning_at ("inline function used but never defined")
since it invokes dump_template_bindings -> tsubst -> ... -> convert_like ->
... -> c_common_truthvalue_conversion -> warning_at ("enum constant in boolean
context")
cp_truthvalue_conversion correctly gets complain=0 but it calls
c_common_truthvalue_conversion from c-family which doesn't have
a similar parameter.
We can fix this by tweaking diagnostic_context::report_diagnostic to
check for recursion after checking if the diagnostic was enabled.
PR c++/116960
PR c++/119303
gcc/ChangeLog:
* diagnostic.cc (diagnostic_context::report_diagnostic): Check for
non-zero m_lock later, after checking diagnostic_enabled.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval26.C: New test.
* g++.dg/warn/undefined2.C: New test.
aarch64: Remove +sme -> +sve2 feature flag dependency
As per the AArch64 ISA FEAT_SME does not require FEAT_SVE2. However, we don't
support SME without SVE2 and bail out with a 'sorry' if this configuration is
encountered. We may choose to support this in the future.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (SME): Remove SVE2 as
prerequisite and add in FCMA and F16FML.
* config/aarch64/aarch64.cc (aarch64_override_options_internal):
Diagnose use of SME without SVE2 and implicitly enable SVE2 when
enabling SME after streaming mode diagnosis.
* doc/invoke.texi (sme): Document that this can only be used with the
sve2 extension.
Jason Merrill [Sat, 29 Mar 2025 18:00:55 +0000 (14:00 -0400)]
c++: lambda in function template signature [PR119401]
Here we instantiate the lambda three times in producing A<0>::f:
1) in tsubst_function_type, substituting the type of A<>::f
2) in tsubst_function_decl, substituting the parameters of A<>::f
3) in regenerate_decl_from_template when instantiating A<>::f
The first one gets thrown away by maybe_rebuild_function_decl_type. Before
r15-7202, we happily built all of them and mangled the result wrongly as
lambda #3. After r15-7202, we try to mangle #3 as #1, which breaks because
#1 is already mangled as #1.
This patch avoids building #3 by suppressing regenerate_decl_from_template
if the template signature includes a lambda, fixing the ICE.
We now mangle the lambda as #2, which is still wrong. Addressing that
should involve not calling tsubst_function_type from tsubst_function_decl,
and building the type from the parms types in the first place rather than
fixing it up in maybe_rebuild_function_decl_type.
PR c++/119401
gcc/cp/ChangeLog:
* pt.cc (regenerate_decl_from_template): Don't regenerate if the
signature involves a lambda.
Richard Earnshaw [Mon, 31 Mar 2025 09:37:11 +0000 (10:37 +0100)]
arm: testsuite: fix vect-fmaxmin.c test
This is another case of a test that was both an executable test
requiring specific hardware and an assembler scan test. The
requirement for the hardware was masking some useful testing that
could be done (by scanning the assembly output) on almost all test
runs. Fixed in a similar manner to fmaxmin{,-2}.c by splitting the
test into two, one that scans the assembler output and one that
executes the compiled code if suitable hardware is available.
The masked issue was that this test was expecting vectorization to
occur that was incorrect given the options passed. For correct
vectorization we need -funsafe-math-optimizations as the vector
version of the single-precision operation will apply a truncation of
denormal values.
gcc/testsuite/ChangeLog:
* gcc.target/arm/vect-fmaxmin-2.c: New compile test. Split from ...
* gcc.target/arm/vect-fmaxmin.c: ... here. Remove scan-assembler
subtests. For both, add -funsafe-math-optimizations.
Tobias Burnus [Mon, 31 Mar 2025 09:44:26 +0000 (11:44 +0200)]
OpenMP: modify_call_for_omp_dispatch - fix invalid memory access after 'error' [PR119541]
OpenMP requires that the number of dispatch 'interop' clauses (ninterop)
is less or equal to the number of declare variant 'append_args' interop
objects (nappend).
While 'nappend < ninterop' was diagnosed as error, the processing continues,
which lead to an invalid out-of-bounds memory access. Solution: only
process the first nappend 'interop' clauses.
gcc/ChangeLog:
PR middle-end/119541
* gimplify.cc (modify_call_for_omp_dispatch): Limit interop claues
processing by the number of append_args arguments.
Kyrylo Tkachov [Mon, 24 Mar 2025 08:53:06 +0000 (01:53 -0700)]
PR middle-end/119442: expr.cc: Fix vec_duplicate into vector boolean modes
In this testcase GCC tries to expand a VNx4BI vector:
vector(4) <signed-boolean:4> _40;
_39 = (<signed-boolean:4>) _24;
_40 = {_39, _39, _39, _39};
This ends up in a scalarised sequence of bitfield insert operations.
This is despite the fact that AArch64 provides a vec_duplicate pattern
specifically for vec_duplicate into VNx4BI.
The store_constructor code is overly conservative when trying vec_duplicate
as it sees a requested VNx4BImode and an element mode of QImode, which I guess
is the storage mode of BImode objects.
The vec_duplicate expander in aarch64-sve.md explicitly allows QImode element
modes so it should be safe to use it. This patch extends that mode check
to allow such expanders.
The testcase is heavily auto-reduced from a real application but in itself is
nonsensical, but it does demonstrate the current problematic codegen.
Tomasz Kamiński [Fri, 28 Mar 2025 15:17:18 +0000 (16:17 +0100)]
libstdc++: Constrain formatters for chrono types [PR119517]
The formatters for chrono types defined the parse/format methods
as accepting unconstrained types, this in combination with lack
of constrain on _CharT lead to them falsely satisfying formattable
requirements for any type used as character.
This patch adjust the fromatter<T, CharT>::parse signature to:
constexpr typename basic_format_parse_context<_CharT>::iterator
parse(basic_format_parse_context<_CharT>& __pc);
And formatter<T, CharT>::format to:
template<typename _Out>
typename basic_format_context<_Out, _CharT>::iterator
format(const T& __t,
basic_format_context<_Out, _CharT>& __fc) const;
Furthermore we _CharT with __format::__char (char or wchar_t),
PR libstdc++/119517
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (formatter):
Add __format::__char for _CharT and adjust parse and format
method signatures.
* testsuite/std/time/format/pr119517.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Mon, 31 Mar 2025 08:13:42 +0000 (10:13 +0200)]
gcc_release: Generate srcdir extras/infos/man pages from all FEs [PR119510]
Enabling cobol explicitly (at least unconditionally) in gcc_release has the
disadvantage that the script no longer works for GCC <= 14, I think it would
be better to keep it working for all still supported release branches.
And as mentioned in the PR, we still don't generate the
--enable-generated-files-in-srcdir extras/infos/man pages for languages
not actually enabled.
Using --enable-languages=all would mean gcc_release takes far longer and
more importantly, various FEs have extra dependencies, Ada requires a
working Ada compiler (furthermore not newer than the gcc release, so if
I run this on a system with say GCC 15 installed, even when I have Ada
installed, I won't be able to gcc_release GCC 14 or 13 etc.), D working D
compiler, Go takes a long time to build libgo.
So, the following patch instead takes similar approach to what
make regenerate-opt-urls
takes, it generates stuff even for non-enabled languages.
For most languages it works just fine and is a matter of say for cobol
make cobol.srcextra cobol.srcinfo cobol.srcman
The only problem is Modula 2, which has some messed up dependencies and
when the FE is not enabled, this will try to build the whole FE as well and
fail. I think it would be useful to fix that but at least before that is
fixed on the trunk and all release branches, the following patch just
conditionally (so that it works even for GCC 12 which doesn't have Modula 2)
enables also m2.
And lastly, libffi seems to be only enabled for Go (and maybe D), I'd prefer
not to enable those languages for the reasons stated above, so if we really
need libffi.info in release tarballs (despite libffi being used only as
implementation detail and not installed), the patch just generates it by
hand.
2025-03-29 Jakub Jelinek <jakub@redhat.com>
PR other/119510
* gcc_release: Use --enable-languages=c,c++,lto and if m2 is available,
with,m2 appended to that. Check for all possible languages and run
make $lang.srcextra $lang.srcinfo $lang.srcman for those. Add
libffi/doc/libffi.info.
They were using ssecvt instead of sseicvt, I've also added handling
for sseicvt2 which was introduced without fixing up automata, and
the relevant instruction uses DFmode. IMO this is a quite messy
area that could need TLC in the machine description itself.
Richard Biener [Thu, 27 Mar 2025 11:40:15 +0000 (12:40 +0100)]
target/119010 - add reservations for integer vector compares to zen4/zen5
The following handles TI, OI and XI mode in the respective EVEX
compare reservations that do not use memory (I've not yet run into
ones with). The znver automata has separate reservations for
integer compares (but only for zen1, for zen2 and zen3 there are
no compare reservations at all), but I don't see why that should
be necessary here.
Richard Biener [Thu, 27 Mar 2025 10:29:21 +0000 (11:29 +0100)]
target/119010 - missing reservations for Zen4/5 and SSE compares
There's the znver4_sse_test reservation which matches the memory-less
SSE compares but currently requires prefix_extra == 1. The old
znver automata in this case sometimes uses znver1-double instead of
znver1-direct, but it's quite a maze. The following simply drops
the prefix_extra requirement, but I have no idea what I'm doing here.
There doesn't seem to be any documentation on the scheduler relevant
attributes used, or at least I cannot find that.
PR target/119010
* config/i386/zn4zn5.md (znver4_sse_test): Drop test of
prefix_extra attribute.
which does not look at the mode at all. The zn4zn5 automaton lacks
this and instead has separated store and load-store reservations
in odd ways. The following renames the store one and introduces
a none variant.
PR target/119010
* config/i386/zn4zn5.md (znver4_sse_log1): Rename to
znver4_sse_log1_store.
(znver5_sse_log1): Rename to znver5_sse_log1_store.
(znver4_sse_log1): New memory-less variant.
Jakub Jelinek [Mon, 31 Mar 2025 05:51:04 +0000 (07:51 +0200)]
c++: Honor noipa attribute for FE nothrow discovery [PR119518]
The following testcase has different code generation in bar depending on
whether foo is defined or just declared.
That is undesirable when it has noipa attribute, that attribute is
documented to be a black box between caller and callee, so the caller
shouldn't know about any implicitly determined properties of the callee
and callee shouldn't know about its callers.
E.g. the ipa-pure-const passes including nothrow discovery in there all
honor noipa attribute, but the FE did not.
2025-03-31 Jakub Jelinek <jakub@redhat.com>
PR c++/119518
* decl.cc (finish_function): Don't set TREE_NOTHROW for
functions with "noipa" attribute even when we can prove
they can't throw.
Jakub Jelinek [Mon, 31 Mar 2025 05:39:53 +0000 (07:39 +0200)]
libstdc++: Fix up string _M_constructor<bool> exports [PR103827]
On Thu, Mar 27, 2025 at 02:04:24PM +0100, Jan Hubicka wrote:
> Seems I missed the approval, sorry. I will push it - I think it would
> be useful to have it in.
Unfortunately the exports in this patch only work on targets where size_t is
unsigned long, not e.g. on ia32 where it is unsigned int, or targets where
it is unsigned long long.
2025-03-31 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/103827
PR tree-optimization/80331
PR tree-optimization/87502
* config/abi/pre/gnu.ver (GLIBCXX_3.4.34): Use [jmy] rather than m
in pattern for _M_construct<bool>(char const*, size_t).
Jan Hubicka [Sun, 30 Mar 2025 21:49:49 +0000 (23:49 +0200)]
Optimize string constructor
this patch improves code generation on string constructors. We currently have
_M_construct which takes as a parameter two iterators (begin/end pointers to
other string) and produces new string. This patch adds special case of
constructor where instead of begining/end pointers we readily know the string
size and also special case when we know that source is 0 terminated. This
happens commonly when producing stirng copies. Moreover currently ipa-prop is
not able to propagate information that beg-end is known constant (copied string
size) which makes it impossible for inliner to spot the common case where
string size is known to be shorter than 15 bytes and fits in local buffer.
Finally I made new constructor inline. Because it is explicitely instantiated
without C++20 constexpr we do not produce implicit instantiation (as required
by standard) which prevents inlining, ipa-modref and any other IPA analysis to
happen. I think we need to make many of the other functions inline, since
optimization accross string manipulation is quite important. There is PR94960
to track this issue.
* config/abi/pre/gnu.ver: Add version for _M_construct<bool>
* include/bits/basic_string.h: (basic_string::_M_construct<bool>): Declare.
(basic_string constructors): Use it.
* include/bits/basic_string.tcc: (basic_string::_M_construct<bool>): New template.
* src/c++11/string-inst.cc: Instantated S::_M_construct<bool>.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/pr80331.C: New test.
* g++.dg/tree-ssa/pr87502.C: New test.
Sandra Loosemore [Wed, 26 Mar 2025 18:25:51 +0000 (18:25 +0000)]
Doc: Clean up New/Delete Builtins manual section
I noticed that the "New/Delete Builtins" section failed to explicitly
name or describe the arguments of the builtin functions it purported
to document, outside of using them in an example. I've fixed that
and cleaned up the whole section.
gcc/ChangeLog
* doc/extend.texi (New/Delete Builtins): Cleanup up the text and
explicitly list the builtins being documented.
Sandra Loosemore [Wed, 26 Mar 2025 14:56:02 +0000 (14:56 +0000)]
Doc: Organize atomic memory builtins documentation [PR42270]
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
This installment adds a container section to hold documentation for
both the _atomic and _sync builtins, reordering them so that the new
_atomic interface is presented before the legacy _sync one. I also
incorporated material from the separate x86 transactional memory
section directly into the __atomic builtins documentation instead of
retaining that as a parallel section.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Atomic Memory Access): New section.
(__sync Builtins): Make it a subsection of the above.
(Atomic Memory Access): Likewise.
(x86 specific memory model extensions for transactional memory):
Delete this section, incorporating the text into the discussion
of __atomic builtins.
Sandra Loosemore [Wed, 26 Mar 2025 04:16:24 +0000 (04:16 +0000)]
Doc: Break up and rearrange the "other builtins" section [PR42270]
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
The "Other Builtins" section had become a catch-all for all sorts of
things with very little organization or attempt to differentiate between
important information (e.g., GCC treats a gazillion library functions as
builtins by default) from obscure builtins provided primarily as internal
interfaces. I've split it up into various pieces and attempted to move
the more important or useful-to-users documentation earlier in the chapter.
What's left of the section is still a jumbled mess... but at least it's a
smaller jumbled mess.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Built-in Functions): Incorporate some text
formerly in "Other Builtins" into the introduction. Adjust
menu for new sections.
(Library Builtins): New section, split from "Other Builtins".
(Numeric Builtins): Likewise.
(Stack Allocation): Likewise.
(Constructing Calls): Move __builtin_call_with_static_chain here.
(Object Size Checking): Minor copy-editing.
(Other Builtins): Move text to new sections listed above. Delete
duplicate docs for object-size checking builtins.
* doc/invoke.texi (C dialect options): Update @xref for -fno-builtin.
Sandra Loosemore [Tue, 25 Mar 2025 05:25:34 +0000 (05:25 +0000)]
Doc: Move builtin documentation to a new chapter [PR42270]
This is part of an incremental effort to make the documentation for
GCC extensions better organized by grouping/rearranging sections by
topic.
I was originally intending to consolidate all the sections documenting
builtins as subsections of a new container section within the C
extensions chapter, but I ran into a technical limitation of Texinfo:
it only supports sectioning depth up to @subsubsection, and we already
had quite a few of those in the target-specific builtins sections. So
instead I have pulled all the existing sections out into a new
chapter. This actually makes sense since some of the builtins are
specific to C++ anyway and are not C language extensions at all.
Subsequent patches in this series will move things around within the
new chapter; this one just adds the new container node and adjusts
the menus.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (C Extensions): Move menu items for
builtin-related sections to...
(Built-in Functions): New chapter.
* doc/gcc.texi (Introduction): Add menu entry for new chapter.
Sandra Loosemore [Tue, 25 Mar 2025 02:56:48 +0000 (02:56 +0000)]
Doc: Add a container section to consolidate attribute documentation [PR42270]
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
Note that this patch does not address the restructuring/rewrite
suggested by PR88472 or PR102397, beyond adding a very short
introduction to the new container section that is more explicit about
both syntaxes being accepted as a GNU extension.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Attributes): New section.
(Function Attributes): Make it a subsection of the new section.
(Variable Attributes): Likewise.
(Type Attributes): Likewise.
(Label Attributes): Likewise.
(Enumerator Attributes): Likewise.
(Attribute Syntax): Likewise.
Sandra Loosemore [Tue, 25 Mar 2025 05:22:38 +0000 (05:22 +0000)]
Doc: Remove separate "Target Format Checks" section [PR42270]
This is part of an incremental effort to make the chapter on GCC
extensions better organized by grouping/rearranging sections by topic.
Following the last round of patches, there's a leftover section
"Target Format Checks" that didn't fit into any category. It seems best
to merge this material into the main discussion of the "format" attribute,
in particular because that discussion already contains similar discussion
for mingw/Windows targets.
gcc/ChangeLog
PR other/42270
* doc/extend.texi (Function Attributes): Merge text from "Target
Format Checks" into the main discussion of the format and
format_arg attributes.
(Target Format Checks): Delete section.
Jakub Jelinek [Sun, 30 Mar 2025 18:11:05 +0000 (20:11 +0200)]
testsuite: Fix up atomic-inst-ldlogic.c
r15-8956 changed in the test:
-/* { dg-final { scan-assembler-times "ldclr\t" 16} */
+/* { dg-final { scan-assembler-times "ldclr\t" 16 } */
which made it even worse than before, when the directive has
been silently ignored because it didn't match the regex for
directives. Now it matches it but is unbalanced.
The following patch fixes it and adds space after all the
other scan-assembler-times counts in the file.
2025-03-30 Jakub Jelinek <jakub@redhat.com>
* gcc.target/aarch64/atomic-inst-ldlogic.c: Fix another
unbalanced {} directive problem. Add space after all
scan-assembler-times counts.
Alpha: Add option to avoid data races for partial writes [PR117759]
Similarly to data races with 8-bit byte or 16-bit word quantity memory
writes on non-BWX Alpha implementations we have the same problem even on
BWX implementations with partial memory writes produced for unaligned
stores as well as block memory move and clear operations. This happens
at the boundaries of the area written where we produce unprotected RMW
sequences, such as for example:
ldbu $1,0($3)
stw $31,8($3)
stq $1,0($3)
to zero a 9-byte member at the byte offset of 1 of a quadword-aligned
struct, happily clobbering a 1-byte member at the beginning of said
struct if concurrent write happens while executing on the same CPU such
as in a signal handler or a parallel write happens while executing on
another CPU such as in another thread or via a shared memory segment.
To guard against these data races with partial memory write accesses
introduce the `-msafe-partial' command-line option that instructs the
compiler to protect boundaries of the data quantity accessed by instead
using a longer code sequence composed of narrower memory writes where
suitable machine instructions are available (i.e. with BWX targets) or
atomic RMW access sequences where byte and word memory access machine
instructions are not available (i.e. with non-BWX targets).
Owing to the desire of branch avoidance there are redundant overlapping
writes in unaligned cases where STQ_U operations are used in the middle
of a block so as to make sure no part of data to be written has been
lost regardless of run-time alignment. For the non-BWX case it means
that with blocks whose size is not a multiple of 8 there are additional
atomic RMW sequences issued towards the end of the block in addition to
the always required pair enclosing the block from each end.
Only one such additional atomic RMW sequence is actually required, but
code currently issues two for the sake of simplicity. An improvement
might be added to `alpha_expand_unaligned_store_words_safe_partial' in
the future, by folding `alpha_expand_unaligned_store_safe_partial' code
for handling multi-word blocks whose size is not a multiple of 8 (i.e.
with a trailing partial-word part). It would improve performance a bit,
but current code is correct regardless.
Update test cases with `-mno-safe-partial' where required and add new
ones accordingly.
In some cases GCC chooses to open-code block memory write operations, so
with non-BWX targets `-msafe-partial' will in the usual case have to be
used together with `-msafe-bwa'.
Credit to Magnus Lindholm <linmag7@gmail.com> for sharing hardware for
the purpose of verifying the BWX side of this change.
gcc/
PR target/117759
* config/alpha/alpha-protos.h
(alpha_expand_unaligned_store_safe_partial): New prototype.
* config/alpha/alpha.cc (alpha_expand_movmisalign)
(alpha_expand_block_move, alpha_expand_block_clear): Handle
TARGET_SAFE_PARTIAL.
(alpha_expand_unaligned_store_safe_partial)
(alpha_expand_unaligned_store_words_safe_partial)
(alpha_expand_clear_safe_partial_nobwx): New functions.
* config/alpha/alpha.md (insvmisaligndi): Handle
TARGET_SAFE_PARTIAL.
* config/alpha/alpha.opt (msafe-partial): New option.
* config/alpha/alpha.opt.urls: Regenerate.
* doc/invoke.texi (Option Summary, DEC Alpha Options): Document
the new option.
gcc/testsuite/
PR target/117759
* gcc.target/alpha/memclr-a2-o1-c9-ptr.c: Add
`-mno-safe-partial'.
* gcc.target/alpha/memclr-a2-o1-c9-ptr-safe-partial.c: New file.
* gcc.target/alpha/memcpy-di-unaligned-dst.c: New file.
* gcc.target/alpha/memcpy-di-unaligned-dst-safe-partial.c: New
file.
* gcc.target/alpha/memcpy-di-unaligned-dst-safe-partial-bwx.c:
New file.
* gcc.target/alpha/memcpy-si-unaligned-dst.c: New file.
* gcc.target/alpha/memcpy-si-unaligned-dst-safe-partial.c: New
file.
* gcc.target/alpha/memcpy-si-unaligned-dst-safe-partial-bwx.c:
New file.
* gcc.target/alpha/stlx0.c: Add `-mno-safe-partial'.
* gcc.target/alpha/stlx0-safe-partial.c: New file.
* gcc.target/alpha/stlx0-safe-partial-bwx.c: New file.
* gcc.target/alpha/stqx0.c: Add `-mno-safe-partial'.
* gcc.target/alpha/stqx0-safe-partial.c: New file.
* gcc.target/alpha/stqx0-safe-partial-bwx.c: New file.
* gcc.target/alpha/stwx0.c: Add `-mno-safe-partial'.
* gcc.target/alpha/stwx0-bwx.c: Add `-mno-safe-partial'. Refer
to stwx0.c rather than copying its code and also verify no LDQ_U
or STQ_U instructions have been produced.
* gcc.target/alpha/stwx0-safe-partial.c: New file.
* gcc.target/alpha/stwx0-safe-partial-bwx.c: New file.
Alpha: Add option to avoid data races for sub-longword memory stores [PR117759]
With non-BWX Alpha implementations we have a problem of data races where
a 8-bit byte or 16-bit word quantity is to be written to memory in that
in those cases we use an unprotected RMW access of a 32-bit longword or
64-bit quadword width. If contents of the longword or quadword accessed
outside the byte or word to be written are changed midway through by a
concurrent write executing on the same CPU such as by a signal handler
or a parallel write executing on another CPU such as by another thread
or via a shared memory segment, then the concluding write of the RMW
access will clobber them. This is especially important for the safety
of RCU algorithms, but is otherwise an issue anyway.
To guard against these data races with byte and aligned word quantities
introduce the `-msafe-bwa' command-line option (standing for Safe Byte &
Word Access) that instructs the compiler to instead use an atomic RMW
access sequence where byte and word memory access machine instructions
are not available. There is no change to code produced for BWX targets.
It would be sufficient for the secondary reload handle to use a pair of
scratch registers, as requested by `reload_out<mode>', but it would end
with poor code produced as one of the scratches would be occupied by
data retrieved and the other one would have to be reloaded with repeated
calculations, all within the LL/SC sequence.
Therefore I chose to add a dedicated `reload_out<mode>_safe_bwa' handler
and ask for more scratches there by defining a 256-bit OI integer mode.
While reload is documented in our manual to support an arbitrary number
of scratches in reality it hasn't been implemented for IRA:
/* ??? It would be useful to be able to handle only two, or more than
three, operands, but for now we can only handle the case of having
exactly three: output, input and one temp/scratch. */
and it seems to be the case for LRA as well. Do what everyone else does
then and just have one wide multi-register scratch.
I note that the atomic sequences emitted are suboptimal performance-wise
as the looping branch for the unsuccessful completion of the sequence
points backwards, which means it will be predicted as taken despite that
in most cases it will fall through. I do not see it as a deficiency of
this change proposed as it takes care of recording that the branch is
unlikely to be taken, by calling `alpha_emit_unlikely_jump'. Therefore
generic code elsewhere should instead be investigated and adjusted
accordingly for the arrangement to actually take effect.
Add test cases accordingly.
There are notable regressions between a plain `-mno-bwx' configuration
and a `-mno-bwx -msafe-bwa' one:
FAIL: gcc.dg/torture/inline-mem-cpy-cmp-1.c -O0 execution test
FAIL: gcc.dg/torture/inline-mem-cpy-cmp-1.c -O1 execution test
FAIL: gcc.dg/torture/inline-mem-cpy-cmp-1.c -O2 execution test
FAIL: gcc.dg/torture/inline-mem-cpy-cmp-1.c -O3 -g execution test
FAIL: gcc.dg/torture/inline-mem-cpy-cmp-1.c -Os execution test
FAIL: gcc.dg/torture/inline-mem-cpy-cmp-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test
FAIL: gcc.dg/torture/inline-mem-cpy-cmp-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
FAIL: g++.dg/init/array25.C -std=c++17 execution test
FAIL: g++.dg/init/array25.C -std=c++98 execution test
FAIL: g++.dg/init/array25.C -std=c++26 execution test
They come from the fact that these test cases play tricks with alignment
and end up calling code that expects a reference to aligned data but is
handed one to unaligned data.
This doesn't cause a visible problem with plain `-mno-bwx' code, because
the resulting alignment exception is fixed up by Linux. There's no such
handling currently implemented for LDL_L or LDQ_L instructions (which
are first in the sequence) and consequently the offender is issued with
SIGBUS instead. Suitable handling will be added to Linux to complement
this change that will emulate the trapping instructions[1], so these
interim regressions are seen as harmless and expected.
References:
[1] "Alpha: Emulate unaligned LDx_L/STx_C for data consistency",
<https://lore.kernel.org/r/alpine.DEB.2.21.2502181912230.65342@angie.orcam.me.uk/>
gcc/
PR target/117759
* config/alpha/alpha-modes.def (OI): New integer mode.
* config/alpha/alpha-protos.h (alpha_expand_mov_safe_bwa): New
prototype.
* config/alpha/alpha.cc (alpha_expand_mov_safe_bwa): New
function.
(alpha_secondary_reload): Handle TARGET_SAFE_BWA.
* config/alpha/alpha.md (aligned_store_safe_bwa)
(unaligned_store<mode>_safe_bwa, reload_out<mode>_safe_bwa)
(reload_out<mode>_unaligned_safe_bwa): New expanders.
(mov<mode>, movcqi, reload_out<mode>_aligned): Handle
TARGET_SAFE_BWA.
(reload_out<mode>): Guard against TARGET_SAFE_BWA.
* config/alpha/alpha.opt (msafe-bwa): New option.
* config/alpha/alpha.opt.urls: Regenerate.
* doc/invoke.texi (Option Summary, DEC Alpha Options): Document
the new option.
gcc/testsuite/
PR target/117759
* gcc.target/alpha/stb.c: New file.
* gcc.target/alpha/stb-bwa.c: New file.
* gcc.target/alpha/stb-bwx.c: New file.
* gcc.target/alpha/stba.c: New file.
* gcc.target/alpha/stba-bwa.c: New file.
* gcc.target/alpha/stba-bwx.c: New file.
* gcc.target/alpha/stw.c: New file.
* gcc.target/alpha/stw-bwa.c: New file.
* gcc.target/alpha/stw-bwx.c: New file.
* gcc.target/alpha/stwa.c: New file.
* gcc.target/alpha/stwa-bwa.c: New file.
* gcc.target/alpha/stwa-bwx.c: New file.
IRA+LRA: Let the backend request to split basic blocks
The next change for Alpha will produce extra labels and branches in
reload, which in turn requires basic blocks to be split at completion.
We do this already for functions that can trap, so just extend the
arrangement with a flag for the backend to use whenever it finds it
necessary.
Alpha: Export `emit_unlikely_jump' for a subsequent change to use
Rename `emit_unlikely_jump' function to `alpha_emit_unlikely_jump', so
as to avoid namespace pollution, updating callers accordingly and export
it for use in the machine description. Make it return the insn emitted.
LIU Hao [Sat, 29 Mar 2025 14:47:54 +0000 (22:47 +0800)]
gcc/mingw: Align `.refptr.` to 8-byte boundaries for 64-bit targets
Windows only requires sections to be aligned on a 4-byte boundary. This used
to work because in binutils the `.rdata` section is over-aligned to a 16-byte
boundary, which will be fixed in the future.
This matches the output of Clang.
Signed-off-by: LIU Hao <lh_mouse@126.com> Signed-off-by: Jonathan Yong <10walls@gmail.com>
gcc/ChangeLog:
* config/mingw/winnt.cc (mingw_pe_file_end): Add `.p2align`.
Jason Merrill [Sat, 29 Mar 2025 12:56:09 +0000 (08:56 -0400)]
c++/modules: unexported friend template
Here we were failing to match the injected friend declaration to the
definition because the latter isn't exported. But the friend is attached to
the module, so we need to look for any reachable declaration in that module,
not just the exports.
The duplicate_decls change is to avoid clobbering DECL_MODULE_IMPORT_P on
the imported definition; matching an injected friend doesn't change that
it's imported. I considered checking get_originating_module == 0 or
!decl_defined_p instead of DECL_UNIQUE_FRIEND_P there, but I think this
situation is specific to friends.
I removed an assert because we have a test for the same condition a few
lines above.
gcc/cp/ChangeLog:
* decl.cc (duplicate_decls): Don't clobber DECL_MODULE_IMPORT_P with
an injected friend.
* name-lookup.cc (check_module_override): Look at all reachable
decls in decl's originating module.
gcc/testsuite/ChangeLog:
* g++.dg/modules/friend-9_a.C: New test.
* g++.dg/modules/friend-9_b.C: New test.
Jason Merrill [Mon, 24 Mar 2025 19:28:04 +0000 (15:28 -0400)]
c++: optimize push_to_top_level [PR64500]
Profiling showed that the loop to save away IDENTIFIER_BINDINGs from open
binding levels was taking 5% of total compilation time in the PR116285
testcase. This turned out to be because we were unnecessarily trying to do
this for namespaces, whose bindings are found through
DECL_NAMESPACE_BINDINGS, not IDENTIFIER_BINDING.
As a result we would frequently loop through everything in std::, checking
whether it needs to be stored, and never storing anything.
This change actually appears to speed up compilation for the PR116285
testcase by ~20%.
The replaced comments referred either to long-replaced handling of classes
and templates, or to wanting b to point to :: when the loop exits.
PR c++/64500
PR c++/116285
gcc/cp/ChangeLog:
* name-lookup.cc (push_to_top_level): Don't try to store_bindings
for namespace levels.
Nathaniel Shead [Fri, 28 Mar 2025 12:38:26 +0000 (23:38 +1100)]
c++/modules: Fix modules and LTO with header units [PR118961]
This patch makes some adjustments required to get a simple modules
testcase working with LTO. There are two main issues fixed.
Firstly, modules only streams the maybe-in-charge constructor, and any
clones are recreated on stream-in. These clones are copied from the
existing function decl and then adjusted. This caused issues because
the clones were getting incorrectly marked as abstract, since after
clones have been created (in the imported file) the maybe-in-charge decl
gets marked as abstract. So this patch just ensures that clones are
always created as non-abstract.
The second issue is that we need to explicitly tell cgraph that explicit
instantiations need to be emitted, otherwise LTO will elide them (as
they don't necessarily appear to be used directly) and cause link
errors. Additionally, expand_or_defer_fn doesn't setup comdat groups
for explicit instantiations, so we need to do that here as well.
Currently this is all handled in 'mark_decl_instantiated'; this patch
splits out the linkage handling into a separate function that we can
call from modules code, maybe in GCC16 we could move this somewhere more
central.
PR c++/118961
gcc/cp/ChangeLog:
* class.cc (copy_fndecl_with_name): Mark clones as non-abstract.
* cp-tree.h (setup_explicit_instantiation_definition_linkage):
Declare new function.
* module.cc (trees_in::read_var_def): Use it.
(module_state::read_cluster): Likewise.
* pt.cc (setup_explicit_instantiation_definition_linkage): New
function.
(mark_decl_instantiated): Use it.
gcc/testsuite/ChangeLog:
* g++.dg/modules/lto-1.h: New test.
* g++.dg/modules/lto-1_a.H: New test.
* g++.dg/modules/lto-1_b.C: New test.
* g++.dg/modules/lto-1_c.C: New test.
* g++.dg/modules/lto-2_a.H: New test.
* g++.dg/modules/lto-2_b.C: New test.
* g++.dg/modules/lto-3_a.H: New test.
* g++.dg/modules/lto-3_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jakub Jelinek [Fri, 28 Mar 2025 23:49:27 +0000 (00:49 +0100)]
testsuite: Fix up musttail2.C test
On Wed, Mar 26, 2025 at 10:10:07AM -0700, Andi Kleen wrote:
> I think this needs to be target external_tailcall, otherwise you will
> fail on targets that don't support that.
>
> Or alternatively make this not extern.
You're right (although I don't remember which targets are
non-external_musttail).
Here is a patch to define the function.
2025-03-28 Jakub Jelinek <jakub@redhat.com>
* g++.dg/opt/musttail2.C (foo): Define the function instead of
just declaring it, add [[gnu::noipa]] attribute to it.
Jakub Jelinek [Fri, 28 Mar 2025 23:47:57 +0000 (00:47 +0100)]
cobol: Fix up cobol/{charmaps,valconv}.cc rules
sed -i is not portable, it is supported by GNU sed and perhaps some BSDs,
but not elsewhere.
Furthermore, I think it is far better to always use
#include "../../libgcobol/something.h"
paths rather than something depending on the build directory.
And because we require GNU make, we don't have to have two different
rules for those, can use just one for both.
The l variable in there is just to make it fit into 80 columns.
2025-03-28 Jakub Jelinek <jakub@redhat.com>
* Make-lang.in (cobol/charmaps.cc, cobol/valconv.cc): Used sed -e
instead of cp and multiple sed -i commands. Always prefix libgcobol
header names in #include directives with ../../libgcobol/ rather than
something depending on $(LIB_SOURCE).
Jeremy Bettis [Fri, 28 Mar 2025 07:54:27 +0000 (00:54 -0700)]
libcpp: Fix incorrect line numbers in large files [PR108900]
This patch addresses an issue in the C preprocessor where incorrect
line number information is generated when processing files with a
large number of lines. The problem arises from improper handling
of location intervals in the line map, particularly when locations
exceed LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES.
By ensuring that the highest location is not decremented if it
would move to a different ordinary map, this fix resolves
the line number discrepancies observed in certain test cases.
This change improves the accuracy of line number reporting, benefiting
users relying on precise code coverage and debugging information.
libcpp/ChangeLog:
PR preprocessor/108900
* files.cc (_cpp_stack_file): Do not decrement highest_location
across distinct maps.
Signed-off-by: Jeremy Bettis <jbettis@google.com> Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
Jakub Jelinek [Fri, 28 Mar 2025 19:29:31 +0000 (20:29 +0100)]
testsuite: Don't cycle through option list for gfortran.dg and libgomp.fortran dg-do run tests with -O in dg*options
Here is a new version of the patch.
The current behavior in gfortran.dg/ and libgomp.fortran/libgomp.oacc-fortran
is that tests without any dg-do directive are implicitly dg-do compile
and tests with dg-do compile or without dg-do don't cycle through options
(-O is implicitly added but can be overridden), while test with dg-do run
cycle through the optimization options.
The following patch modifies this, so that even tests with dg-do run
with -O in dg-options or dg-additional-options (after [ \t"{]) don't cycle
either and also get implicit -O which is overridden by that
-O{,0,1,2,3,s,z,g,fast} in dg-{,additional-}options. Previously we were
mostly wasting test time on those, because e.g.
-O0 -O2
-O1 -O2
-O2 -O2
-Os -O2
are still effectively -O2 and so the same thing, while
-O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -O2
and
-O3 -g -O2
are not the same thing (effectively
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -O2
and
-g -O2) I think it isn't worth to test those combinations (especially when
with e.g. -O0 in dg-options it mostly doesn't do much).
Tested with make check-gfortran where this results in slight decrease of
tests:
# of expected passes 73809
# of expected failures 343
# of unsupported tests 78
with unmodified trunk vs.
# of expected passes 72734
# of expected failures 343
# of unsupported tests 73
with the patch, and on the libgomp side
# of expected passes 11162
# of expected failures 238
# of unsupported tests 274
to
# of expected passes 11092
# of expected failures 238
# of unsupported tests 274
(when counting just fortran.exp tests).
Before the patch I see
grep -- '-O[^ ].*-O' testsuite/gfortran/gfortran.log | grep -v '/vect/\|/graphite/' | wc -l
1008
and with the patch
grep -- '-O[^ ].*-O' testsuite/gfortran/gfortran.log | grep -v '/vect/\|/graphite/' | wc -l
0
(vect and graphite have a few occurrences, but not too much).
2025-03-28 Jakub Jelinek <jakub@redhat.com>
* lib/gfortran-dg.exp: Don't cycle through the option list if
dg-options or dg-additional-options contains -O after space, tab,
double quote or open curly bracket.
* gfortran.dg/cray_pointers_2.f90: Remove extraneous space between
dg-do and run and remove comment about it.
Gaius Mulley [Fri, 28 Mar 2025 15:25:55 +0000 (15:25 +0000)]
PR modula2/119504: ICE when attempting to access an element of a constant string
This patch prevents an ICE and generates an error if an array access to a
constant string is attempted. The patch also allows HIGH ("string").
gcc/m2/ChangeLog:
PR modula2/119504
* gm2-compiler/M2Quads.mod (BuildHighFunction): Defend against
Type = NulSym and fall into BuildConstHighFromSym.
(BuildDesignatorArray): Rewrite to detect an array access to
a constant string.
(BuildDesignatorArrayStaticDynamic): New procedure.
gcc/testsuite/ChangeLog:
PR modula2/119504
* gm2/iso/fail/conststrarray2.mod: New test.
* gm2/iso/run/pass/constarray2.mod: New test.
* gm2/pim/pass/hexstring.mod: New test.
Jakub Jelinek [Fri, 28 Mar 2025 14:45:03 +0000 (15:45 +0100)]
srcextra fixes
Here is a patch which uses sed to fix up the copies of the generated
files by flex/bison in the source directories (i.e. what we ship in
release tarballs).
In that case the generated files are in the same directory as the
files they are generated from, so there should be no absolute or relative
directories, just the filenames.
Furthermore, c.srcextra was duplicating the work of gcc.srcextra, there is
nothing C FE specific on gengtype-lex.l.
2025-03-28 Jakub Jelinek <jakub@redhat.com>
gcc/
* Makefile.in (gcc.srcextra): Use sed to turn .../gcc/gengtype-lex.l
in #line directives into just gengtype-lex.l.
gcc/c/
* Make-lang.in (c.srcextra): Don't depend on anything and don't copy
anything.
gcc/cobol/
* Make-lang.in (cobol.srcextra): Use sed to turn
.../gcc/cobol/*.{y,l,h,cc} and cobol/*.{y,l,h,cc} in #line directives
into just *.{y,l,h,cc}.
Richard Biener [Fri, 28 Mar 2025 14:20:16 +0000 (15:20 +0100)]
other/119510 - use --enable-languages=default,cobol for release tarballs
The following adds cobol to the set of languages built during release
tarball building so the bison and flex generated sources for cobol
are included in the tarball.
PR other/119510
maintainer-scripts/
* gcc_release: Use --enable-languages=default,cobol
when building generated files.
Andrew MacLeod [Wed, 26 Mar 2025 14:34:42 +0000 (10:34 -0400)]
If the LHS does not contain zero, neither do multiply operands.
Given ~[0,0] = op1 * op2, range-ops should determine that neither op1 nor
op2 is zero. Add this to the operator_mult for op1_range. op2_range
simply invokes op1_range, so both will be covered.
PR tree-optimzation/110992.c
PR tree-optimzation/119471.c
gcc/
* range-op.cc (operator_mult::op1_range): If the LHS does not
contain zero, return non-zero.
Richard Biener [Fri, 28 Mar 2025 12:48:36 +0000 (13:48 +0100)]
bootstrap/119513 - fix cobol bootstrap with --enable-generated-files-in-srcdir
This adds gcc/cobol/parse.o to compare_exclusions and makes sure to
ignore errors when copying generated files, like it's done when
copying gengtype-lex.cc.
Jakub Jelinek [Fri, 28 Mar 2025 09:49:40 +0000 (10:49 +0100)]
tailc: Handle musttail noreturn calls [PR119483]
The following (first) testcase is accepted by clang (if clang::musttail)
and rejected by gcc, because we discover the call is noreturn and then bail
out because we don't want noreturn tailcalls.
The general reason not to support noreturn tail calls is for cases like
abort where we want nicer backtrace, but if user asks explicitly to
musttail a call which either is explicitly noreturn or is implicitly
determined to be noreturn, I don't see a reason why we couldn't do that.
Both for tail calls and tail recursions.
An alternative would be to keep rejecting musttail to explicit noreturn,
but not actually implicitly mark anything as noreturn if it has any musttail
calls. But it is unclear how we could do that, such marking is I think done
typically before IPA and e.g. for LTO we won't know whether some other TU
could have musttail calls to it. And keeping around both explicit and
implicit noreturn bits would be ugly. Well, I guess we could differentiate
between presence of noreturn/_Noreturn attributes and just ECF_NORETURN
without those, but then tailc would still need to support it, just error out
if it was explicit.
2025-03-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/119483
* tree-tailcall.cc (find_tail_calls): Handle noreturn musttail
calls.
(eliminate_tail_call): Likewise.
(tree_optimize_tail_calls_1): If cfun->has_musttail and
diag_musttail, handle also basic blocks with no successors
with noreturn musttail calls.
* calls.cc (can_implement_as_sibling_call_p): Allow ECF_NORETURN
calls if they are musttail calls.
* c-c++-common/pr119483-1.c: New test.
* c-c++-common/pr119483-2.c: New test.
Jakub Jelinek [Fri, 28 Mar 2025 09:48:31 +0000 (10:48 +0100)]
ipa-sra: Don't change return type to void if there are musttail calls [PR119484]
The following testcase is rejected, because IPA-SRA decides to
turn bar.constprop call into bar.constprop.isra which returns void.
While there is no explicit lhs on the call, as it is a musttail call
the tailc pass checks if IPA-VRP returns singleton from that function
and the function returns the same value and in that case it still turns
it into a tail call. This can't work with IPA-SRA changing it into
void returning function though.
The following patch fixes this by forcing returning the original type
if there are musttail calls.
2025-03-28 Jakub Jelinek <jakub@redhat.com>
PR ipa/119484
* ipa-sra.cc (isra_analyze_call): Don't set m_return_ignored if
gimple_call_must_tail_p even if it doesn't have lhs.
Richard Biener [Fri, 21 Mar 2025 18:30:31 +0000 (19:30 +0100)]
Export native_encode_real operating on REAL_VALUE_TYPE
The following exports the native_encode_real worker, and makes it
take a scalar float mode and REAL_VALUE_TYPE data instead of a tree
for use in the COBOL frontend, avoiding creating of a temporary tree.
* fold-const.h (native_encode_real): Export.
* fold-const.cc (native_encode_real): Change API to take
mode and REAL_VALUE_TYPE.
(native_encode_expr): Adjust.
Iain Sandoe [Thu, 20 Mar 2025 17:08:57 +0000 (17:08 +0000)]
cobol: Do not include <cmath> (no longer needed)
Several of enumerators in parse.y conflict with ones declared in at
least some versions of <cmath> .. e.g. "OVERFLOW". The header is no
longer needed since the FE is not trying to do host arithmetic.
projects / thirdparty / gcc.git / log
