When partially substituting a requires-expr, we don't want to perform
any additional checks beyond the substitution itself so as to minimize
checking requirements out of order. So don't check the return-type-req
of a compound-requirement during partial substitution. And don't check
the noexcept condition either since we can't do that on templated trees.
PR c++/113966
gcc/cp/ChangeLog:
* constraint.cc (tsubst_compound_requirement): Don't check
the noexcept condition or the return-type-requirement when
partially substituting.
Patrick Palka [Sat, 3 Feb 2024 00:07:08 +0000 (19:07 -0500)]
c++: requires-exprs and partial constraint subst [PR110006]
In r11-3261-gb28b621ac67bee we made tsubst_requires_expr never partially
substitute into a requires-expression so as to avoid checking its
requirements out of order during e.g. generic lambda regeneration.
These PRs however illustrate that we still sometimes do need to
partially substitute into a requires-expression, in particular when it
appears in associated constraints that we're directly substituting for
sake of declaration matching or dguide constraint rewriting. In these
cases we're being called from tsubst_constraint during which
processing_constraint_expression_p is true, so this patch checks this
predicate to control whether we defer substitution or partially
substitute.
In turn, we now need to propagate semantic tsubst flags through
tsubst_requires_expr rather than just using tf_none, notably for sake of
dguide constraint rewriting which sets tf_dguide.
PR c++/110006
PR c++/112769
gcc/cp/ChangeLog:
* constraint.cc (subst_info::quiet): Accomodate non-diagnostic
tsubst flags.
(tsubst_valid_expression_requirement): Likewise.
(tsubst_simple_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_type_requirement_1): Accomodate non-diagnostic tsubst
flags.
(tsubst_type_requirement): Return a substituted _REQ node when
processing_template_decl.
(tsubst_compound_requirement): Likewise. Accomodate non-diagnostic
tsubst flags.
(tsubst_nested_requirement): Likewise.
(tsubst_requires_expr): Don't defer partial substitution when
processing_constraint_expression_p is true, in which case return
a substituted REQUIRES_EXPR.
* pt.cc (tsubst_expr) <case REQUIRES_EXPR>: Accomodate
non-diagnostic tsubst flags.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/class-deduction-alias18.C: New test.
* g++.dg/cpp2a/concepts-friend16.C: New test.
H.J. Lu [Sun, 14 Apr 2024 19:57:39 +0000 (12:57 -0700)]
tree-profile: Disable indirect call profiling for IFUNC resolvers
We can't profile indirect calls to IFUNC resolvers nor their callees as
it requires TLS which hasn't been set up yet when the dynamic linker is
resolving IFUNC symbols.
Add an IFUNC resolver caller marker to cgraph_node and set it if the
function is called by an IFUNC resolver. Disable indirect call profiling
for IFUNC resolvers and their callees.
Tested with profiledbootstrap on Fedora 39/x86-64.
Tamar Christina [Mon, 15 Apr 2024 11:12:30 +0000 (12:12 +0100)]
AArch64: remove ls64 from being mandatory on armv8.7-a..
The Arm Architectural Reference Manual (Version J.a, section A2.9 on FEAT_LS64)
shows that ls64 is an optional extensions and should not be enabled by default
for Armv8.7-a.
This drops it from the mandatory bits for the architecture and brings GCC inline
with LLVM and the achitecture.
Note that we will not be changing binutils to preserve compatibility with older
released compilers.
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def (AARCH64_ARCH): Remove LS64 from
Armv8.7-a.
Jakub Jelinek [Thu, 11 Apr 2024 13:55:53 +0000 (15:55 +0200)]
libstdc++: Regenerate baseline_symbols.txt files for Linux
The following patch regenerates the ABI files for 13 branch (I've only changed
the Linux files which were updated in r13-7289, all but m68k, riscv64 and
powerpc64 are from actual Fedora 39 gcc builds, the rest hand edited).
We've added one symbol very early in the 13.2 cycle, but then added 2
further ones very soon afterwards, quite a long time before 13.2 release
and haven't regenerated. The patch applies cleanly to trunk as well.
Kito Cheng [Wed, 28 Feb 2024 08:01:52 +0000 (16:01 +0800)]
RISC-V: Fix __atomic_compare_exchange with 32 bit value on RV64
atomic_compare_and_swapsi will use lr.w to do obtain the original value,
which sign extends to DI. RV64 only has DI comparisons, so we also need
to sign extend the expected value to DI as otherwise the comparison will
fail when the expected value has the 32nd bit set.
gcc/ChangeLog:
PR target/114130
* config/riscv/sync.md (atomic_compare_and_swap<mode>): Sign
extend the expected value if needed.
Martin Jambor [Mon, 8 Apr 2024 15:34:33 +0000 (17:34 +0200)]
ipa: Self-DCE of uses of removed call LHSs (PR 108007)
PR 108007 is another manifestation where we rely on DCE to clean-up
after IPA-SRA and if the user explicitely switches DCE off, IPA-SRA
can leave behind statements which are fed uninitialized values and
trap, even though their results are themselves never used.
I have already fixed this for unused parameters in callees, this bug
shows that almost the same thing can happen for removed returns, on
the side of callers. This means that the issue has to be fixed
elsewhere, in call redirection. This patch adds a function which
looks for (and through, using a work-list) uses of operations fed
specific SSA names and removes them all.
That would have been easy if it wasn't for debug statements during
tree-inline (from which call redirection is also invoked). Debug
statements are decoupled from the rest at this point and iterating
over uses of SSAs does not bring them up. During tree-inline they are
handled especially at the end, I assume in order to make sure that
relative ordering of UIDs are the same with and without debug info.
This means that during tree-inline we need to make a hash of killed
SSAs, that we already have in copy_body_data, available to the
function making the purging. So the patch duly does also that, making
the interface slightly ugly. Moreover, all newly unused SSA names
need to be freed and as PR 112616 showed, it must be done in a defined
order, which is what newly added ipa_release_ssas_in_hash does.
PR ipa/108007
PR ipa/112616
* cgraph.h (cgraph_edge): Add a parameter to
redirect_call_stmt_to_callee.
* ipa-param-manipulation.h (ipa_param_adjustments): Add a
parameter to modify_call.
(ipa_release_ssas_in_hash): Declare.
* cgraph.cc (cgraph_edge::redirect_call_stmt_to_callee): New
parameter killed_ssas, pass it to padjs->modify_call.
* ipa-param-manipulation.cc (purge_all_uses): New function.
(ipa_param_adjustments::modify_call): New parameter killed_ssas.
Instead of substituting uses, invoke purge_all_uses. If
hash of killed SSAs has not been provided, create a temporary one
and release SSAs that have been added to it.
(compare_ssa_versions): New function.
(ipa_release_ssas_in_hash): Likewise.
* tree-inline.cc (redirect_all_calls): Create
id->killed_new_ssa_names earlier, pass it to edge redirection,
adjust a comment.
(copy_body): Release SSAs in id->killed_new_ssa_names.
Harald Anlauf [Wed, 27 Mar 2024 20:18:04 +0000 (21:18 +0100)]
Fortran: fix DATA and derived types with pointer components [PR114474]
When matching actual arguments in match_actual_arg, these are initially
treated as a possible dummy procedure, assuming that the correct type is
determined later. This resolution could fail when the procedure is a
derived type constructor with a pointer component and appears in a DATA
statement, where the pointer shall be associated with an initial data
target. Check for those cases where the type obviously has not been
resolved yet, and which were missed because there was no component
reference.
gcc/fortran/ChangeLog:
PR fortran/114474
* primary.cc (gfc_variable_attr): Catch variables used in structure
constructors within DATA statements that are still tagged with a
temporary type BT_PROCEDURE from match_actual_arg and which have the
target attribute, and fix their typespec.
gcc/testsuite/ChangeLog:
PR fortran/114474
* gfortran.dg/data_pointer_3.f90: New test.
Iain Sandoe [Sat, 13 Jan 2024 17:20:47 +0000 (17:20 +0000)]
jit, Darwin: Implement library exports list.
Currently, we have no exports list for libgccjit, which means that
all symbols are exported, including those from libstdc++ which is
linked statically into the lib. This causes failures when the
shared libstdc++ is used but some c++ symbols are satisfied from
libgccjit.
This implements an export file for Darwin (which is currently
manually created by cross-checking libgccjit.map). Ideally we'd
script this, at some point. Update libtool current and age to
reflect the current ABI version (we are not bumping the SO name
at this stage).
This fixes a number of new failures in jit testing.
gcc/jit/ChangeLog:
* Make-lang.in: Implement exports list, and use a shared
libgcc.
* libgccjit.exports: New file.
Iain Sandoe [Sun, 31 Mar 2024 10:22:58 +0000 (11:22 +0100)]
testsuite: Remove duplicate -lgcov [PR114034]
Duplicate library entries now cause linker warnings with newer linker
versions on Darwin which leads to these tests regressing. The library
is already added by the test flags so there is no need to put an extra
one in the options.
PR testsuite/114034
gcc/testsuite/ChangeLog:
* g++.dg/gcov/gcov-dump-1.C: Remove extra -lgcov.
* g++.dg/gcov/gcov-dump-2.C: Likewise.
Darwin,debug : Switch to DWARF 3 or 4 when dsymutil supports it.
The main reason that Darwin has been using DWARF2 only as debug is that
earlier debug linkers (dsymutil) did not support any extensions to this
so that the default "non-strict" mode used in GCC would cause tool errors.
There are two sources for dsymutil, those based off a closed source base
"dwarfutils" and those based off LLVM.
For dsymutil versions based off LLVM-7+ we can use up to DWARF-4, and for
versions based on dwarfutils 121+ we can use DWARF-3.
Iain Sandoe [Sun, 31 Mar 2024 22:25:31 +0000 (23:25 +0100)]
Darwin: Do not emit .macinfo when dsymutil cannot consume it.
Some verions of dsymutil do not ignore .macinfo sections, but instead
ignore the entire debug in the file.
To avoid this total loss of debug, when we detect that the debug level
is g3 and the dsymutil version cannot support it, we reduce the level
to g2 and issue a note.
This behaviour can be overidden by -gstrict-dwarf (although the objects
will contain macinfo; dsymutil will not produce a .dSYM with it).
gcc/ChangeLog:
* config/darwin.cc (darwin_override_options): Reduce the debug
level to 2 if dsymutil cannot handle .macinfo sections.
Iain Sandoe [Mon, 18 Mar 2024 10:06:44 +0000 (10:06 +0000)]
testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049].
The intent of the test is to show that we find a framework that
is installed in /System/Library/Frameworks when the user has added
a '-F' option. The trick is to choose some header that is present
for all the Darwin versions we support and that does not contain any
content we cannot parse. We had been using the Kernel framework for
this, but recent SDK versions have revealed that this is not suitable.
Replacing with a use of IOKit.
PR target/114049
gcc/testsuite/ChangeLog:
* gcc.dg/framework-1.c: Use an IOKit header instead of a
Kernel one.
Iain Sandoe [Sun, 29 Oct 2023 07:19:53 +0000 (07:19 +0000)]
testsuite, x86: Handle a broken assembler
Earlier assembler support for complex fp16 on x86_64 Darwin is broken.
This adds an additional test to the existing target-supports that fails
for the broken assemblers but works for the newer, fixed, ones.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Test an asm line that fails on broken
Darwin assembler versions.
Edwin Lu [Mon, 18 Mar 2024 18:43:41 +0000 (11:43 -0700)]
RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]
We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and
there is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
This causes gcc.dg/c23-stdarg-[68].c to fail
PR target/114175
* config/riscv/riscv.cc (riscv_setup_incoming_varargs): Only skip
riscv_funciton_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL
Iain Sandoe [Thu, 8 Feb 2024 17:54:31 +0000 (17:54 +0000)]
libstdc++, Darwin: Handle a linker warning [PR112397].
Darwin's linker warns when we make a direct branch to code that is
in a weak definition (citing that if a different implementation of
the weak function is chosen by the dynamic linker this would be an
error).
As the analysis in the PR shows, this can happen when we have hot/
cold partitioning and there is an error path that is primarily cold
but makes use of epilogue code in the hot section. In this simple
case, we can easily deduce that the code is in fact safe; however
that is not something we can realistically implement in the linker.
Since the user-replaceable allocators are implemented using weak
definitions, this is a warning that is frequently flagged up in both
the testsuite and end-user code.
The chosen solution here is to suppress the hot/cold partitioning for
these cases (it is unlikely to impact performance much c.f. the
actual allocation).
PR target/112397
libstdc++-v3/ChangeLog:
* configure: Regenerate.
* configure.ac: Detect if we are building for Darwin.
* libsupc++/Makefile.am: If we are building for Darwin, then
suppress hot/cold partitioning for the array allocators.
* libsupc++/Makefile.in: Regenerated.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
(cherry picked from commit 1609fdff16f17ead37666f6d0e801800ee3d04d2)
Iain Sandoe [Mon, 18 Mar 2024 09:57:33 +0000 (09:57 +0000)]
libstdc++: Sync the atomic_link_flags implementation with GCC.
For Darwin, in order to allow uninstalled testing, we need to provide
a '-B' option pointing to each path containing an uninstalled library
that we are using (these get appended to the embedded runpaths).
This updates the version of the atomic_link_flags proc in the libstdc++
testsuite to do the same as the one in the GCC testsuite.
libstdc++-v3/ChangeLog:
* testsuite/lib/dg-options.exp (atomic_link_flags): Emit a -B
option for the path to the uninstalled libatomic.
Iain Sandoe [Tue, 19 Mar 2024 10:40:50 +0000 (10:40 +0000)]
libstdc++, Darwin: Do not use dev/null as the file for executables.
Darwin has a separate debug linker, which is invoked when the command
line contains source files and debug is enabled.
Using /dev/null as the executable name does not, therefore, work when
debug is enabled, since the debug linker does not accept /dev/null as
a valid executable name.
The leads to incorrectly UNSUPPORTED testcases because of the unintended
error result from the test compilation.
The solution here is to use a temporary file that is deleted at the
end of the test (which is the mechanism used elsewhere)
libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp (v3_target_compile): Instead of
/dev/null, use a temporary file for test executables on Darwin.
Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
When building gcc's C++ sources against recent libc++, the poisoning of
the ctype macros due to including safe-ctype.h before including C++
standard headers such as <list>, <map>, etc, causes many compilation
errors, similar to:
In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
In file included from /home/dim/src/gcc/master/gcc/system.h:233:
In file included from /usr/include/c++/v1/vector:321:
In file included from
/usr/include/c++/v1/__format/formatter_bool.h:20:
In file included from
/usr/include/c++/v1/__format/formatter_integral.h:32:
In file included from /usr/include/c++/v1/locale:202:
/usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute
only applies to structs, variables, functions, and namespaces
546 | _LIBCPP_INLINE_VISIBILITY
| ^
/usr/include/c++/v1/__config:813:37: note: expanded from macro
'_LIBCPP_INLINE_VISIBILITY'
813 | # define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
| ^
/usr/include/c++/v1/__config:792:26: note: expanded from macro
'_LIBCPP_HIDE_FROM_ABI'
792 |
__attribute__((__abi_tag__(_LIBCPP_TOSTRING(
_LIBCPP_VERSIONED_IDENTIFIER))))
| ^
In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23:
In file included from /home/dim/src/gcc/master/gcc/system.h:233:
In file included from /usr/include/c++/v1/vector:321:
In file included from
/usr/include/c++/v1/__format/formatter_bool.h:20:
In file included from
/usr/include/c++/v1/__format/formatter_integral.h:32:
In file included from /usr/include/c++/v1/locale:202:
/usr/include/c++/v1/__locale:547:37: error: expected ';' at end of
declaration list
547 | char_type toupper(char_type __c) const
| ^
/usr/include/c++/v1/__locale:553:48: error: too many arguments
provided to function-like macro invocation
553 | const char_type* toupper(char_type* __low, const
char_type* __high) const
| ^
/home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note:
macro 'toupper' defined here
146 | #define toupper(c) do_not_use_toupper_with_safe_ctype
| ^
This is because libc++ uses different transitive includes than
libstdc++, and some of those transitive includes pull in various ctype
declarations (typically via <locale>).
There was already a special case for including <string> before
safe-ctype.h, so move the rest of the C++ standard header includes to
the same location, to fix the problem.
PR middle-end/111632
gcc/ChangeLog:
* system.h: Include safe-ctype.h after C++ standard headers.
Jonathan Wakely [Thu, 21 Mar 2024 13:25:15 +0000 (13:25 +0000)]
libstdc++: Destroy allocators in re-inserted container nodes [PR114401]
The allocator objects in container node handles were not being destroyed
after the node was re-inserted into a container. They are stored in a
union and so need to be explicitly destroyed when the node becomes
empty. The containers were zeroing the node handle's pointer, which
makes it empty, causing the handle's destructor to think there's nothing
to clean up.
Add a new member function to the node handle which destroys the
allocator and zeros the pointer. Change the containers to call that
instead of just changing the pointer manually.
We can also remove the _M_empty member of the union which is not
necessary.
libstdc++-v3/ChangeLog:
PR libstdc++/114401
* include/bits/hashtable.h (_Hashtable::_M_reinsert_node): Call
release() on node handle instead of just zeroing its pointer.
(_Hashtable::_M_reinsert_node_multi): Likewise.
(_Hashtable::_M_merge_unique): Likewise.
(_Hashtable::_M_merge_multi): Likewise.
* include/bits/node_handle.h (_Node_handle_common::release()):
New member function.
(_Node_handle_common::_Optional_alloc::_M_empty): Remove
unnecessary union member.
(_Node_handle_common): Declare _Hashtable as a friend.
* include/bits/stl_tree.h (_Rb_tree::_M_reinsert_node_unique):
Call release() on node handle instead of just zeroing its
pointer.
(_Rb_tree::_M_reinsert_node_equal): Likewise.
(_Rb_tree::_M_reinsert_node_hint_unique): Likewise.
(_Rb_tree::_M_reinsert_node_hint_equal): Likewise.
* testsuite/23_containers/multiset/modifiers/114401.cc: New test.
* testsuite/23_containers/set/modifiers/114401.cc: New test.
* testsuite/23_containers/unordered_multiset/modifiers/114401.cc: New test.
* testsuite/23_containers/unordered_set/modifiers/114401.cc: New test.
This is needed to avoid errors outside the immediate context when
evaluating is_default_constructible_v<vector<T, A>> when A is not
default constructible.
To avoid diagnostic regressions for 23_containers/vector/48101_neg.cc we
need to make the std::allocator<cv T> partial specializations default
constructible, which they probably should have been anyway.
libstdc++-v3/ChangeLog:
PR libstdc++/113841
* include/bits/allocator.h (allocator<cv T>): Add default
constructor to partial specializations for cv-qualified types.
* include/bits/stl_vector.h (_Vector_impl::_Vector_impl()):
Constrain so that it's only present if the allocator is default
constructible.
* include/bits/stl_bvector.h (_Bvector_impl::_Bvector_impl()):
Likewise.
* testsuite/23_containers/vector/cons/113841.cc: New test.
Jonathan Wakely [Mon, 18 Mar 2024 13:00:17 +0000 (13:00 +0000)]
libstdc++: Begin lifetime of storage in std::vector<bool> [PR114367]
This doesn't cause a problem with GCC, but Clang correctly diagnoses a
bug in the code. The objects in the allocated storage need to begin
their lifetime before we start using them.
This change uses the allocator's construct function instead of using
std::construct_at directly, in order to support fancy pointers.
libstdc++-v3/ChangeLog:
PR libstdc++/114367
* include/bits/stl_bvector.h (_M_allocate): Use allocator's
construct function to begin lifetime of words.
There are two problems here; first that the emitted asm for
-fdebug-types-section is ELF-specfic leading to assembler errors for
Mach-O. If we fix this, we get a secondary fail since the debug linker
does not recognise DW_FORM_ref_sig8. Disable ths test until we get
DWARF-5 support in the external Darwin toolchain components.
If we want to support multiple object formats and to allow for
scan-assembler tests, we need to make it possible to adjust the
tests on a per-target basis.
This adds similar mechamisms to jit-verify-assembler-output
to those used for the general scan-assembler dg directives.
As an aside; it would, perhaps, be possible to integrate this more
with scanasm.exp (which would also give access to function body
scanning) but I did not attempt that for this patch.
After this, we can accept things like:
... { jit-verify-assembler-output "......" { target *-*-darwin* } } }
gcc/testsuite/ChangeLog:
* jit.dg/jit.exp: Accept target clauses in jit-verify-assembler
handling.
Iain Sandoe [Sat, 13 Jan 2024 12:49:28 +0000 (12:49 +0000)]
testsuite, jit: Handle whitespace in test-link-section-assembler.c.
Darwin has a different .section directive that has more fields and
uses different whitespace. Amend the whitespace in the scan-asm to
be more flexible.
gcc/testsuite/ChangeLog:
* jit.dg/test-link-section-assembler.c: Accept any whitespace
between the .section directive and its arguments.
Marek Polacek [Fri, 29 Mar 2024 20:59:37 +0000 (16:59 -0400)]
c++: ICE with scoped enum in switch condition [PR103825]
Here we ICE when gimplifying
enum class Type { Pawn };
struct Piece {
Type type : 4;
};
void foo() {
switch (Piece().type)
case Type::Pawn:;
}
because we ended up with TYPE_PRECISION (cond) < TYPE_PRECISION (case).
That's because the case expr type here is the unlowered type Type,
whereas the conditional's type is the lowered <unnamed-signed:4>. This
is not supposed to happen: see the comment in pop_switch around the
is_bitfield_expr_with_lowered_type check.
But here we did not revert to the lowered SWITCH_STMT_TYPE, because
the conditional contains a TARGET_EXPR, which has side-effects, which
means that finish_switch_cond -> maybe_cleanup_point_expr wraps it
in a CLEANUP_POINT_EXPR. And is_bitfield_expr_with_lowered_type does
not see through those.
Harald Anlauf [Tue, 5 Mar 2024 20:54:26 +0000 (21:54 +0100)]
Fortran: error recovery while simplifying expressions [PR103707,PR106987]
When an exception is encountered during simplification of arithmetic
expressions, the result may depend on whether range-checking is active
(-frange-check) or not. However, the code path in the front-end should
stay the same for "soft" errors for which the exception is triggered by the
check, while "hard" errors should always terminate the simplification, so
that error recovery is independent of the flag. Separation of arithmetic
error codes into "hard" and "soft" errors shall be done consistently via
is_hard_arith_error().
PR fortran/103707
PR fortran/106987
gcc/fortran/ChangeLog:
* arith.cc (is_hard_arith_error): New helper function to determine
whether an arithmetic error is "hard" or not.
(check_result): Use it.
(gfc_arith_divide): Set "Division by zero" only for regular
numerators of real and complex divisions.
(reduce_unary): Use is_hard_arith_error to determine whether a hard
or (recoverable) soft error was encountered. Terminate immediately
on hard error, otherwise remember code of first soft error.
(reduce_binary_ac): Likewise.
(reduce_binary_ca): Likewise.
(reduce_binary_aa): Likewise.
gcc/testsuite/ChangeLog:
* gfortran.dg/arithmetic_overflow_3.f90: New test.
Harald Anlauf [Thu, 8 Feb 2024 20:51:38 +0000 (21:51 +0100)]
Fortran: error recovery on arithmetic overflow on unary operations [PR113799]
PR fortran/113799
gcc/fortran/ChangeLog:
* arith.cc (reduce_unary): Remember any overflow encountered during
reduction of unary arithmetic operations on array constructors and
continue, and return error status, but terminate on serious errors.
gcc/testsuite/ChangeLog:
* gfortran.dg/arithmetic_overflow_2.f90: New test.
Harald Anlauf [Wed, 17 May 2023 18:39:18 +0000 (20:39 +0200)]
Fortran: set shape of initializers of zero-sized arrays [PR95374,PR104352]
gcc/fortran/ChangeLog:
PR fortran/95374
PR fortran/104352
* decl.cc (add_init_expr_to_sym): Set shape of initializer also for
zero-sized arrays, so that bounds violations can be detected later.
gcc/testsuite/ChangeLog:
PR fortran/95374
PR fortran/104352
* gfortran.dg/zero_sized_13.f90: New test.
Qing Zhao [Thu, 29 Feb 2024 15:07:49 +0000 (15:07 +0000)]
Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407]
This is a bug in tree-ssa-math-opts.cc, when applying the widening mul
optimization, the compiler needs to check whether the operand is in a
ABNORMAL PHI, if YES, we should avoid the transformation.
PR tree-optimization/111407
gcc/ChangeLog:
* tree-ssa-math-opts.cc (convert_mult_to_widen): Avoid the transform
when one of the operands is subject to abnormal coalescing.
Thomas Neumann [Mon, 11 Mar 2024 13:35:20 +0000 (14:35 +0100)]
handle unwind tables that are embedded within unwinding code [PR111731]
Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
The unwinding mechanism registers both the code range and the unwind
table itself within a b-tree lookup structure. That data structure
assumes that is consists of non-overlappping intervals. This
becomes a problem if the unwinding table is embedded within the
code itself, as now the intervals do overlap.
To fix this problem we now keep the unwind tables in a separate
b-tree, which prevents the overlap.
libgcc/ChangeLog:
PR libgcc/111731
* unwind-dw2-fde.c: Split unwind ranges if they contain the
unwind table.
Iain Sandoe [Wed, 25 Oct 2023 14:28:52 +0000 (15:28 +0100)]
Darwin: Handle the fPIE option specially.
For Darwin, PIE requires PIC codegen, but otherwise is only a link-time
change. For almost all Darwin, we do not report __PIE__; the exception is
32bit X86 and from Darwin12 to 17 only (32 bit is no longer supported
after Darwin17).
On macOS, system headers redefine by default some macros (memcpy,
memmove, etc) to checked versions, which defeats the analyzer. We
want to turn this off.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042
Iain Sandoe [Mon, 29 Jan 2024 10:09:25 +0000 (10:09 +0000)]
testsuite, Darwin: Allow for undefined symbols in shared test.
Darwin's linker defaults to error on undefined (which makes it look as
if we do not support shared, leading to tests being marked incorrectly
as unsupported).
This fixes the issue by allowing the symbols used in the target
supports test to be undefined.
Lulu Cheng [Fri, 15 Mar 2024 08:23:05 +0000 (16:23 +0800)]
LoongArch: gcc13: Implement option save/restore.
LTO option streaming and target attributes both require per-function
target configuration, which is achieved via option save/restore.
We implement TARGET_OPTION_{SAVE,RESTORE} to switch the la_target
context in addition to other automatically maintained option states
(via the "Save" option property in the .opt files).
PR target/113233
gcc/ChangeLog:
* config/loongarch/genopts/loongarch.opt.in: Mark options with
the "Save" property.
* config/loongarch/loongarch-opts.cc
(loongarch_update_gcc_opt_status): Update the value of the
la_target to global_options.
* config/loongarch/loongarch-opts.h
(loongarch_update_gcc_opt_status): Add a function declaration.
* config/loongarch/loongarch.cc
(loongarch_option_override_internal): Call the function
loongarch_update_gcc_opt_status.
(loongarch_option_save): New functions.
(loongarch_option_restore): Likewise.
(TARGET_OPTION_SAVE): Define macro.
(TARGET_OPTION_RESTORE): Likewise.
* config/loongarch/loongarch.opt: Regenerate.
Mikael Morin [Thu, 21 Mar 2024 16:27:54 +0000 (17:27 +0100)]
fortran: Ignore use statements on error [PR107426]
This fixes an access to freed memory on the testcase from the PR.
The problem comes from an invalid subroutine statement in an interface,
which is ignored and causes the following statements forming the procedure
body to be rejected. One of them use-associates the intrinsic ISO_C_BINDING
module, which imports new symbols in a namespace that is freed at the time
the statement is rejected. However, this creates dangling pointers as
ISO_C_BINDING is special and its import creates a reference to the imported
C_PTR symbol in the return type of the global intrinsic symbol for C_LOC
(see the function create_intrinsic_function).
This change saves and restores the list of use statements, so that rejected
use statements are removed before they have a chance to be applied to the
current namespace and create dangling pointers.
PR fortran/107426
gcc/fortran/ChangeLog:
* gfortran.h (gfc_save_module_list, gfc_restore_old_module_list):
New declarations.
* module.cc (old_module_list_tail): New global variable.
(gfc_save_module_list, gfc_restore_old_module_list): New functions.
(gfc_use_modules): Set module_list and old_module_list_tail.
* parse.cc (next_statement): Save module_list before doing any work.
(reject_statement): Restore module_list to its saved value.
Two of the encode testcases include '-lobjc' as their dg-options.
Since the library is already appended as part of the generic testsuite
handling, this means that two instances appear on the link line leading
to spurious warnings from Darwin's new linker.
Iain Sandoe [Thu, 25 Jan 2024 20:11:09 +0000 (20:11 +0000)]
Objective-C, Darwin: Do not overalign CFStrings and Objective-C metadata.
We have reports of regressions in both Objective-C and Objective-C++ on
Darwin23 (macOS 14). In some cases, these are linker warnings about the
alignment of CFString constants; in other cases the built executables
crash during runtime initialization. The underlying issue is the same in
both cases; since the objects (CFStrings, Objective-C meta-data) are TU-
local, we are choosing to increase their alignment for efficiency - to
values greater than ABI alignment.
However, although these objects are TU-local, they are also visible to the
linker (since they are placed in specific named sections). In many cases
the metadata can be regarded as tables of data, and thus it is expected
that these sections can be concatenated from multiple TUs and the data
treated as tabular. In order for this to work the data cannot be allowed
to exceed ABI alignment - which leads to the crashes.
For GCC-15+ it would be nice to find a more elegant solution to this issue
(perhaps by adjusting the concept of binds-locally to exclude specific
named sections) - but I do not want to do that in stage 4.
The solution here is to force the alignment to be preserved as created by
setting DECL_USER_ALIGN on the relevant objects.
gcc/ChangeLog:
* config/darwin.cc (darwin_build_constant_cfstring): Prevent over-
alignment of CFString constants by setting DECL_USER_ALIGN.
Iain Sandoe [Mon, 8 Jan 2024 16:17:04 +0000 (16:17 +0000)]
Darwin: Fix a typo in Objective-C meta-data.
We have a typo in the metadata for assigning NSStrings to a specific
section for the V1 (32b) ABI. When that is fixed we should never see
the case where the section needs to be deduced from the properties of
the DECLs.
gcc/ChangeLog:
* config/darwin.cc (darwin_objc1_section): Use the correct
meta-data version for constant strings.
(machopic_select_section): Assert if we fail to handle CFString
sections as Obejctive-C meta-data or drectly.
Although this only fires for one of the Darwin sub-ports, it is latent
elsewhere, it is also a regression c.f. the Darwin system compiler.
In the code we imported from an earlier branch, CFString objects (which
are constant aggregates) are constructed as CONST_DECLs. Although our
current documentation suggests that these are reserved for enumeration
values, in fact they are used elsewhere in the compiler for constants.
This includes Objective-C where they are used to form NSString constants.
In the particular case, we take the address of the constant and that
triggers varasm.cc:decode_addr_constant, which does not currently support
CONST_DECL.
If there is a general intent to allow/encourage wider use of CONST_DECL,
then we should fix decode_addr_constant to look through these and evaluate
the initializer (a two-line patch, but I'm not suggesting it for stage-4).
We also need to update the GCC internals documentation to allow for the
additional uses.
This patch is Darwin-local and fixes the problem by making the CFString
constants into regular variable but TREE_CONSTANT+TREE_READONLY. I plan
to back-port this to the open branches once it has baked a while on trunk.
Since, for Darwin, the Objective-C default is to construct constant
NSString objects as CFStrings; this will also cover the majority of cases
there (this patch does not make any changes to Objective-C NSStrings).
PR target/105522
gcc/ChangeLog:
* config/darwin.cc (machopic_select_section): Handle C and C++
CFStrings.
(darwin_rename_builtins): Move this out of the CFString code.
(darwin_libc_has_function): Likewise.
(darwin_build_constant_cfstring): Create an anonymous var to
hold each CFString.
* config/darwin.h (ASM_OUTPUT_LABELREF): Handle constant
CFstrings.
Iain Sandoe [Sat, 6 Jan 2024 19:21:40 +0000 (19:21 +0000)]
Objective-C, Darwin: Fix a regression in handling bad receivers.
This is seen on 32b hosts with a 64b multilib, and is an ICE when
the build has checking enabled. The fix is to exit the routine
early if the sender or receiver are already error_mark_node.
gcc/objc/ChangeLog:
* objc-next-runtime-abi-02.cc
(build_v2_objc_method_fixup_call): Early exit for cases
where the sender or receiver are known to be in error.
Darwin: Make metadata symbol lables linker-visible for GNU objc.
Now we have shifted to using the same relocation mechanism as clang for
objective-c typeinfo the static linker needs to have a linker-visible
symbol for metadata names (this is only needed for GNU objective C, for
NeXT the names are in separate sections).
gcc/ChangeLog:
* config/darwin.h
(darwin_label_is_anonymous_local_objc_name): Make metadata names
linker-visibile for GNU objective C.
Iain Sandoe [Tue, 17 Oct 2023 10:10:27 +0000 (11:10 +0100)]
Darwin: Check as for .build_version support and use it if available.
This adds support for the minimum OS version data in assembler files.
At present, we have no mechanism to detect the SDK version in use, and
so that is omitted from build_versions.
We follow the implementation in clang, '.build_version' is only emitted
(where supported) for target macOS versions >= 10.14. For earlier macOS
we fall back to using a '.macosx_version_min' directive. This latter is
also emitted when the assembler supports it, but not build_version.
gcc/ChangeLog:
* config.in: Regenerate.
* config/darwin.cc (darwin_file_start): Add assembler directives
for the target OS version, where these are supported by the
assembler.
(darwin_override_options): Check for building >= macOS 10.14.
* configure: Regenerate.
* configure.ac: Check for assembler support of .build_version
directives.
Darwin, configure: Allow for an unrecognisable dsymutil [PR111610].
We had a catch-all configuration case for missing or unrecognised dsymutil
but it was setting the dsymutil source to "UNKNOWN" which is not usable in
this context (since it clashes with an existing enum). We rename this to
DET_UNKNOWN (for Darwin External Toolchain).
PR target/111610
gcc/ChangeLog:
* configure: Regenerate.
* configure.ac: Rename the missing dsymutil case to "DET_UNKNOWN".
Darwin: Place global inits in the correct section.
This handles placement of global initializers into __TEXT,__StaticInit as used
by other platform toolchains.
Since we do see global initialization code getting hot/cold splits, this
patch places the cold parts into text_cold, and keeps the hot part in
the correct Init section per ABI.
* config/darwin-sections.def (static_init_section): Add the
__TEXT,__StaticInit section.
* config/darwin.cc (darwin_function_section): Use the static init
section for global initializers, to match other platform toolchains.
Place unlikely executed global init code into the standard cold
section.
Iain Sandoe [Thu, 31 Aug 2023 18:20:43 +0000 (19:20 +0100)]
Darwin: Match system sections and relocs for exception tables.
System tools from Darwin10 onwards have moved the exceptions tables from
the __DATA segment to the __TEXT one. They also revised the relocations
used for typeinfo. While Darwin9 was not changed at the time, in fact the
tools there are equally happy with the revised scheme - and therefore at
present there seems no reason to special-case it.
Rainer Orth [Thu, 17 Aug 2023 08:14:49 +0000 (10:14 +0200)]
build: Allow for Xcode 15 ld -v output
Since Xcode 15 beta 6, ld -v output differs from previous versions:
* macOS 13/Xcode 14:
@(#)PROGRAM:ld PROJECT:ld64-857.1
* macOS 14/Xcode 15:
@(#)PROGRAM:ld PROJECT:dyld-1015.1
configure cannot handle the new form, so LD64_VERSION isn't set.
This patch fixes this. The autoconf manual states that sed doesn't
portably support alternation, so I'm using two separate expressions to
extract the version number.
configure, Darwin: Adjust handing of stdlib option.
The intent of the configuration choices for -stdlib is that default
setting should choose reasonable options for the target. This should
enable -stdlib= for Darwin targets where libc++ is the default on the
system (so that it is only necessary to provide the headers).
However, it seems that there are some cases where (external) config
scripts are using -stdlib (incorrectly) to determine if the compiler
in use is GCC or clang.
In order to allow for these cases, this patch refines the setting
like so:
--with-gxx-libcxx-include-dir= is used to configure the path containing
libc++ headers; it also controls the enabling of the -stdlib option.
We are adding a special value for path:
if --with-gxx-libcxx-include-dir is 'no' we disable the stdlib option.
Otherwise if the --with-gxx-libcxx-include-dir is set we use the path
provided, and enable the stdlib option.
if --with-gxx-libcxx-include-dir is unset
We decide on the stdlib option based on the OS type and revision being
targeted. The path is set to a fixed position relative to the compiler
install (similar logic to that used for libstdc++ headers).
Xi Ruoyao [Wed, 20 Mar 2024 07:09:21 +0000 (15:09 +0800)]
mips: Fix C23 (...) functions returning large aggregates [PR114175]
We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
arguments and there is nothing to advance, but that is not the case
for (...) functions returning by hidden reference which have one such
artificial argument. This is causing gcc.dg/c23-stdarg-{6,8,9}.c to
fail.
Fix the issue by checking if arg.type is NULL, as r14-9503 explains.
gcc/ChangeLog:
PR target/114175
* config/mips/mips.cc (mips_setup_incoming_varargs): Only skip
mips_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions if arg.type is NULL.
Xi Ruoyao [Mon, 18 Mar 2024 09:18:34 +0000 (17:18 +0800)]
LoongArch: Fix C23 (...) functions returning large aggregates [PR114175]
We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
arguments and there is nothing to advance, but that is not the case
for (...) functions returning by hidden reference which have one such
artificial argument. This is causing gcc.dg/c23-stdarg-6.c and
gcc.dg/c23-stdarg-8.c to fail.
Fix the issue by checking if arg.type is NULL, as r14-9503 explains.
gcc/ChangeLog:
PR target/114175
* config/loongarch/loongarch.cc
(loongarch_setup_incoming_varargs): Only skip
loongarch_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions if arg.type is NULL.
Jakub Jelinek [Thu, 28 Mar 2024 14:00:44 +0000 (15:00 +0100)]
profile-count: Avoid overflows into uninitialized [PR112303]
The testcase in the patch ICEs with
--- gcc/tree-scalar-evolution.cc
+++ gcc/tree-scalar-evolution.cc
@@ -3881,7 +3881,7 @@ final_value_replacement_loop (class loop *loop)
/* Propagate constants immediately, but leave an unused initialization
around to avoid invalidating the SCEV cache. */
- if (CONSTANT_CLASS_P (def) && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rslt))
+ if (0 && CONSTANT_CLASS_P (def) && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rslt))
replace_uses_by (rslt, def);
/* Create the replacement statements. */
(the addition of the above made the ICE latent), because profile_count
addition doesn't check for overflows and if unlucky, we can even overflow
into the uninitialized value.
Getting really huge profile counts is very easy even when not using
recursive inlining in loops, e.g.
__attribute__((noipa)) void
bar (void)
{
__builtin_exit (0);
}
__attribute__((noipa)) void
foo (void)
{
for (int i = 0; i < 1000; ++i)
for (int j = 0; j < 1000; ++j)
for (int k = 0; k < 1000; ++k)
for (int l = 0; l < 1000; ++l)
for (int m = 0; m < 1000; ++m)
for (int n = 0; n < 1000; ++n)
for (int o = 0; o < 1000; ++o)
for (int p = 0; p < 1000; ++p)
for (int q = 0; q < 1000; ++q)
for (int r = 0; r < 1000; ++r)
for (int s = 0; s < 1000; ++s)
for (int t = 0; t < 1000; ++t)
for (int u = 0; u < 1000; ++u)
for (int v = 0; v < 1000; ++v)
for (int w = 0; w < 1000; ++w)
for (int x = 0; x < 1000; ++x)
for (int y = 0; y < 1000; ++y)
for (int z = 0; z < 1000; ++z)
for (int a = 0; a < 1000; ++a)
for (int b = 0; b < 1000; ++b)
bar ();
}
int
main ()
{
foo ();
}
reaches the maximum count already on the 11th loop.
Some other methods of profile_count like apply_scale already
do use MIN (val, max_count) before assignment to m_val, this patch
just extends that to operator{+,+=} methods.
Furthermore, one overload of apply_probability wasn't using
safe_scale_64bit and so could very easily overflow as well
- prob is required to be [0, 10000] and if m_val is near the max_count,
it can overflow even with multiplications by 8.
2024-03-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/112303
* profile-count.h (profile_count::operator+): Perform
addition in uint64_t variable and set m_val to MIN of that
val and max_count.
(profile_count::operator+=): Likewise.
(profile_count::operator-=): Formatting fix.
(profile_count::apply_probability): Use safe_scale_64bit
even in the int overload.
Jakub Jelinek [Tue, 26 Mar 2024 10:21:38 +0000 (11:21 +0100)]
fold-const: Punt on MULT_EXPR in extract_muldiv MIN/MAX_EXPR case [PR111151]
As I've tried to explain in the comments, the extract_muldiv_1
MIN/MAX_EXPR optimization is wrong for code == MULT_EXPR.
If the multiplication is done in unsigned type or in signed
type with -fwrapv, it is fairly obvious that max (a, b) * c
in many cases isn't equivalent to max (a * c, b * c) (or min if c is
negative) due to overflows, but even for signed with undefined overflow,
the optimization could turn something without UB in it (where
say a * c invokes UB, but max (or min) picks the other operand where
b * c doesn't).
As for division/modulo, I think it is in most cases safe, except if
the problematic INT_MIN / -1 case could be triggered, but we can
just punt for MAX_EXPR because for MIN_EXPR if one operand is INT_MIN,
we'd pick that operand already. It is just for completeness, match.pd
already has an optimization which turns x / -1 into -x, so the division
by zero is mostly theoretical. That is also why in the testcase the
i case isn't actually miscompiled without the patch, while the c and f
cases are.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
PR middle-end/111151
* fold-const.cc (extract_muldiv_1) <case MAX_EXPR>: Punt for
MULT_EXPR altogether, or for MAX_EXPR if c is -1.
Jakub Jelinek [Tue, 26 Mar 2024 10:06:15 +0000 (11:06 +0100)]
tsan: Don't instrument non-generic AS accesses [PR111736]
Similar to the asan and ubsan changes, we shouldn't instrument non-generic
address space accesses with tsan, because we just have library functions
which take address of the objects as generic address space pointers, so they
can't handle anything else.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/111736
* tsan.cc (instrument_expr): Punt on non-generic address space
accesses.
Jakub Jelinek [Sat, 23 Mar 2024 10:17:44 +0000 (11:17 +0100)]
predcom: Punt for steps which aren't multiples of access size [PR111683]
On the following testcases, there is no overlap between data references
within a single iteration, but the data references have size which is twice
as large as the step, which means the data references overlap with the next
iteration which predcom doesn't take into account.
As discussed in the PR, even if the reference size is smaller than step,
if step isn't a multiple of the reference size, there could be overlaps with
some other iteration later on.
The initial version of the patch regressed (test still passed, but predcom
didn't optimize anymore) pr71083.c which has a packed char, short structure
and was reading/writing the short 2 bytes in there with step 3.
The following patch deals with that by retrying for COMPONENT_REFs also the
aggregate sizes etc., so that it then compares 3 bytes against step 3.
In make check-gcc/check-g++ this patch I believe affects code generation
for only the 2 new testcases according to statistics I've gathered.
2024-03-23 Jakub Jelinek <jakub@redhat.com>
PR middle-end/111683
* tree-predcom.cc (pcom_worker::suitable_component_p): If has_write
and comp_step is RS_NONZERO, return false if any reference in the
component doesn't have DR_STEP a multiple of access size.
* gcc.dg/pr111683-1.c: New test.
* gcc.dg/pr111683-2.c: New test.
On x86 and avr some address spaces allow 0 pointers (on avr actually
even generic as, but libsanitizer isn't ported to it and
I'm not convinced we should completely kill -fsanitize=null in that
case).
The following patch makes sure those aren't diagnosed for -fsanitize=null,
though they are still sanitized for -fsanitize=alignment.
2024-03-22 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/111736
* ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid
SANITIZE_NULL instrumentation for non-generic address spaces
for which targetm.addr_space.zero_address_valid (as) is true.
Jakub Jelinek [Wed, 20 Mar 2024 16:00:51 +0000 (17:00 +0100)]
visium: Fix up visium_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, visium seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/visium/visium.cc (visium_setup_incoming_varargs): Only skip
TARGET_FUNCTION_ARG_ADVANCE for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 16:00:08 +0000 (17:00 +0100)]
nios2: Fix up nios2_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, nios2 seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/nios2/nios2.cc (nios2_setup_incoming_varargs): Only skip
nios2_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
projects / thirdparty / gcc.git / log
