Jakub Jelinek [Sat, 22 Mar 2025 07:39:38 +0000 (08:39 +0100)]
Fix up some further cases of missing or extraneous spaces in diagnostics
Given the recent PR119406 I've tried to grep for concatenated string
literals without space at the end of one line and at the start of next line,
unless it was obviously intentional.
Furthermore, I've then looked through gcc.pot looking for 2 adjacent spaces
and looking back if that wasn't the case of "something "
" with spaces at both sides".
Here is the result from that.
I think just the c.opt change needs an explanation, the "" in the
description is simply eaten up somewhere during the option processing and
gcc -v --help before this patch was displaying
-Wdeprecated-literal-operator Warn about deprecated space between and suffix in a user-defined literal operator.
2025-03-22 Jakub Jelinek <jakub@redhat.com>
gcc/
* gimplify.cc (warn_switch_unreachable_and_auto_init_r): Add missing
space in the middle of diagnostics.
* tree-vect-stmts.cc (vectorizable_load): Add missing space in the
middle of debug dump message.
* sym-exec/sym-exec-state.cc (state::check_args_compatibility):
Likewise.
gcc/c-family/
* c.opt (Wdeprecated-literal-operator): Use \"\" rather than ""
in option description.
gcc/fortran/
* resolve.cc (resolve_procedure_expression): Remove extraneous space
from the middle of diagnostics.
Iain Sandoe [Fri, 21 Mar 2025 15:14:19 +0000 (15:14 +0000)]
cobol, driver: Handle targets without HAVE_LD_STATIC_DYNAMIC.
This fixes a typo where libraries were not added for targets without
HAVE_LD_STATIC_DYNAMIC.
It also adds the libraries in this case;
typically, a target without HAVE_LD_STATIC_DYNAMIC can take the
-static-libgcobol and use that to drive a spec substitution viz:
%{static-libgcobol:%:replace-outfile(-lgcobol libgcobol.a%s)}
which needs both the library and -static-libgcobol to be present
in the driver output.
gcc/cobol/ChangeLog:
* gcobolspec.cc (add_arg_lib): Fix typo.
(lang_specific_driver): Arrange to append both -lgcobol
and -static-libgcobol for targets without
HAVE_LD_STATIC_DYNAMIC.
Tobias Burnus [Fri, 21 Mar 2025 23:36:44 +0000 (00:36 +0100)]
libgomp.fortran/get-mapped-ptr-1.f90: Use -6 for non-conf dev number
This is a fix for the GOMP_interop commit r15-8654-g99e2906ae255fc that
added GOMP_DEVICE_DEFAULT_OMP_61 alias omp_default_device, which is a
conforming device number. But that test used -5 as check for a
non-conforming device number.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/get-mapped-ptr-1.f90: Use -6
not -5 as non-conforming device number.
Tobias Burnus [Fri, 21 Mar 2025 20:39:42 +0000 (21:39 +0100)]
libgomp/plugin: Add initial interop support to nvptx + gcn
The interop directive operates on an opaque object that represents a
foreign runtime. This commit adds support for
this to the two offloading plugins.
For nvptx, it supports cuda, cuda_driver and hip; the latter is AMD's
version of CUDA which for Nvidia devices boils down to normal CUDA.
Thus, at the end for this limited use, cuda/cuda_driver/hip are all
the same - and for plugin-nvptx.c, the they differ only in terms of
what gets fr_id, fr_name and get_interop_type_desc return.
For gcn, it supports hip and hsa.
Regarding get-mapped-ptr-1.c: That's actually a fix for the
GOMP_interop commit r15-8654-g99e2906ae255fc that added
GOMP_DEVICE_DEFAULT_OMP_61 alias omp_default_device, which is
a conforming device number. But that test used -5 as check for a
non-conforming device number.
libgomp/ChangeLog:
* plugin/plugin-gcn.c (_LIBGOMP_PLUGIN_INCLUDE): Define.
(struct hsa_runtime_fn_info): Add two queue functions.
(hipError_t, hipCtx_t, hipStream_s, hipStream_t): New types.
(struct hip_runtime_fn_info): New.
(hip_runtime_lib, hip_fns): New global vars.
(init_environment_variables): Handle hip_runtime_lib.
(init_hsa_runtime_functions): Load the two queue functions.
(init_hip_runtime_functions, GOMP_OFFLOAD_interop,
GOMP_OFFLOAD_get_interop_int, GOMP_OFFLOAD_get_interop_ptr,
GOMP_OFFLOAD_get_interop_str,
GOMP_OFFLOAD_get_interop_type_desc): New.
* plugin/plugin-nvptx.c (_LIBGOMP_PLUGIN_INCLUDE): Define.
(GOMP_OFFLOAD_interop, GOMP_OFFLOAD_get_interop_int,
GOMP_OFFLOAD_get_interop_ptr, GOMP_OFFLOAD_get_interop_str,
GOMP_OFFLOAD_get_interop_type_desc): New.
* testsuite/libgomp.c/interop-fr-1.c: New test.
* testsuite/libgomp.c-c++-common/get-mapped-ptr-1.c: Use -6
not -5 as non-conforming device number.
Jakub Jelinek [Fri, 21 Mar 2025 19:26:00 +0000 (20:26 +0100)]
lra, v2: emit caller-save register spills before call insn [PR116028]
Here is an updated version of Surya's PR116028 fix from August, which got
reverted because it caused bootstrap failures on aarch64, later on bootstrap
comparison errors there as well and problems on other targets as well.
Original description:
LRA emits insns to save caller-save registers in the
inheritance/splitting pass. In this pass, LRA builds EBBs (Extended
Basic Block) and traverses the insns in the EBBs in reverse order from
the last insn to the first insn. When LRA sees a write to a pseudo (that
has been assigned a caller-save register), and there is a read following
the write, with an intervening call insn between the write and read,
then LRA generates a spill immediately after the write and a restore
immediately before the read. The spill is needed because the call insn
will clobber the caller-save register.
If there is a write insn and a call insn in two separate BBs but
belonging to the same EBB, the spill insn gets generated in the BB
containing the write insn. If the write insn is in the entry BB, then
the spill insn that is generated in the entry BB prevents shrink wrap
from happening. This is because the spill insn references the stack
pointer and hence the prolog gets generated in the entry BB itself.
This patch ensures the the spill insn is generated before the call insn
instead of after the write. This also ensures that the spill occurs
only in the path containing the call.
The changes compared to the first r15-2810 version are:
1) the reason for aarch64 miscompilations and later on bootstrap comparison
issues as can be seen on the pr118615.c testcase in the patch was that
when curr_insn is a JUMP_INSN or some cases of CALL_INSNs,
split_if_necessary is called with before_p true and if it is successful,
the code set use_insn = PREV_INSN (curr_insn); instead of use_insn =
curr_insn; and that use_insn is then what is passed to
add_next_usage_insn; now, if the patch decides to emit the save
instruction(s) before the first call after curr_insn in the ebb rather
than before the JUMP_INSN/CALL_INSN, PREV_INSN (curr_insn) is some random
insn before it, not anything related to the split_reg actions.
If it is e.g. a DEBUG_INSN in one case vs. some unrelated other insn
otherwise, that can affect further split_reg within the same function
2) as suggested by Surya in PR118615, it makes no sense to try to change
behavior if the first call after curr_insn is in the same bb as curr_insn
3) split_reg is actually called sometimes from within inherit_in_ebb but
sometimes from elsewhere; trying to use whatever last call to
inherit_in_ebb saw last is a sure way to run into wrong-code issues,
so instead of clearing the rtx var at the start of inherit_in_ebb it is
now cleared at the end of it
4) calling the var latest_call_insn was weird, inherit_in_ebb walks the ebb
backwards, so what the var contains is the first call insn within the
ebb (after curr_insn)
5) the patch was using
lra_process_new_insns (PREV_INSN (latest_call_insn), NULL, save,
"Add save<-reg");
to emit the save insn before latest_call_insn. That feels quite weird
given that latest_call_insn has explicit support for adding stuff
before some insn or after some insn, adding something before some
insn doesn't really need to be done as addition after PREV_INSN
6) some formatting nits + new testcase + removal of xfail even on arm32
Bootstrapped/regtested on x86_64-linux/i686-linux (my usual
--enable-checking=yes,rtl,extra builds), aarch64-linux (normal default
bootstrap) and our distro scratch build
({x86_64,i686,aarch64,powerpc64le,s390x}-linux --enable-checking=release
LTO profiledbootstrap/regtest), I think Sam James tested on 32-bit arm
too.
On aarch64-linux this results in
-FAIL: gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping"
I admit I don't know the code well nor understood everything it is doing.
I have some concerns:
1) I wonder if there is a guarantee that first_call_insn if non-NULL will be
always in between curr_insn and usage_insn when call_save_p; I'd hope
yes because if usage_insn is before first_call_insn in the ebb,
presumably it wouldn't need to find call save regs because the range
wouldn't cross any calls
2) I wonder whether it wouldn't be better instead of inserting the saves
before first_call_insn insert it at the start of the bb containing that
call (after labels of course); emitting it right before a call could
mislead code looking for argument slot initialization of the call
3) even when avoiding the use_insn = PREV_INSN (curr_insn);, I wonder
if it is ok to use use_insn equal to curr_insn rather than the insns
far later where we actually inserted it, but primarily because I don't
understand the code much; I think for the !before_p case it is doing
similar thing on a shorter distance, the saves were emitted after
curr_insn and we record it on curr_insn
2025-03-21 Surya Kumari Jangala <jskumari@linux.ibm.com>
Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/116028
PR rtl-optimization/118615
* lra-constraints.cc (first_call_insn): New variable.
(split_reg): Spill register before first_call_insn if call_save_p
and the call is in a different bb in the ebb.
(split_if_necessary): Formatting fix.
(inherit_in_ebb): Set first_call_insn when handling a CALL_INSN.
For successful split_if_necessary with before_p, only change
use_insn if it emitted any new instructions before curr_insn.
Clear first_call_insn before returning.
* gcc.dg/ira-shrinkwrap-prep-1.c: Remove xfail for powerpc.
* gcc.dg/pr10474.c: Remove xfail for powerpc and arm.
* gcc.dg/pr118615.c: New test.
OpenMP: 'interop' construct - add ME support + target-independent libgomp
This patch partially enables use of the OpenMP interop construct by adding
middle end support, mostly in the omplower pass, and in the target-independent
part of the libgomp runtime. It follows up on previous patches for C, C++ and
Fortran front ends support. The full interop feature requires another patch to
enable foreign runtime support in libgomp plugins.
gcc/ChangeLog:
* builtin-types.def
(BT_FN_VOID_INT_INT_PTR_PTR_PTR_INT_PTR_INT_PTR_UINT_PTR): New.
* gimple-low.cc (lower_stmt): Handle GIMPLE_OMP_INTEROP.
* gimple-pretty-print.cc (dump_gimple_omp_interop): New function.
(pp_gimple_stmt_1): Handle GIMPLE_OMP_INTEROP.
* gimple.cc (gimple_build_omp_interop): New function.
(gimple_copy): Handle GIMPLE_OMP_INTEROP.
* gimple.def (GIMPLE_OMP_INTEROP): Define.
* gimple.h (gimple_build_omp_interop): Declare.
(gimple_omp_interop_clauses): New function.
(gimple_omp_interop_clauses_ptr): Likewise.
(gimple_omp_interop_set_clauses): Likewise.
(gimple_return_set_retval): Handle GIMPLE_OMP_INTEROP.
* gimplify.cc (gimplify_scan_omp_clauses): Handle OMP_CLAUSE_INIT,
OMP_CLAUSE_USE and OMP_CLAUSE_DESTROY.
(gimplify_omp_interop): New function.
(gimplify_expr): Replace sorry with call to gimplify_omp_interop.
* omp-builtins.def (BUILT_IN_GOMP_INTEROP): Define.
* omp-low.cc (scan_sharing_clauses): Handle OMP_CLAUSE_INIT,
OMP_CLAUSE_USE and OMP_CLAUSE_DESTROY.
(scan_omp_1_stmt): Handle GIMPLE_OMP_INTEROP.
(lower_omp_interop_action_clauses): New function.
(lower_omp_interop): Likewise.
(lower_omp_1): Handle GIMPLE_OMP_INTEROP.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_clause_destroy): Make addressable.
(c_parser_omp_clause_init): Make addressable.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_omp_clause_init): Make addressable.
gcc/fortran/ChangeLog:
* trans-openmp.cc (gfc_trans_omp_clauses): Make OMP_CLAUSE_DESTROY and
OMP_CLAUSE_INIT addressable.
* types.def (BT_FN_VOID_INT_INT_PTR_PTR_PTR_INT_PTR_INT_PTR_UINT_PTR):
New.
Jason Merrill [Thu, 20 Mar 2025 16:57:15 +0000 (12:57 -0400)]
ipa: target clone and mangling alias [PR114992]
Since the mangling of the second lambda changed (previously we counted all
lambdas, now we only count lambdas with the same signature), we
generate_mangling_alias for handler<lambda2> for backward compatibility.
Since handler is COMDAT, resolve_alias puts the alias in the same comdat
group as handler itself. Then create_dispatcher_calls tries to add the
alias to the same comdat group as the dispatcher, but it's already in a
same_comdat_group, so we ICE.
It seems like we're just missing a remove_from_same_comdat_group before
add_to_same_comdat_group.
PR c++/114992
gcc/ChangeLog:
* multiple_target.cc (create_dispatcher_calls):
remove_from_same_comdat_group before add_to_same_comdat_group.
Paul Thomas [Fri, 21 Mar 2025 16:20:21 +0000 (16:20 +0000)]
Fortran: Implement the F2018 reduce intrinsic [PR85836]
2025-03-21 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/85836
* check.cc (get_ul_from_cst_cl): New function used in
check_operation.
(check_operation): New function used in check_reduce and
check_co_reduce.
(gfc_check_co_reduce): Use it.
(gfc_check_reduce): New function.
(gfc_check_rename): Add prototype for intrinsic with 6 arguments.
* gfortran.h : Add isym id for reduce and prototype for f6.
* intrinsic.cc (do_check): Add another argument expression and use
it in the call to the six argument specific check.
(add_sym_6): New function.
(add_functions): Add the discription of the reduce intrinsic and
add it to the intrinsic list.
* intrinsic.h : Add prototypes for gfc_check_reduce and
gfc_resolve_reduce.
* iresolve.cc (generate_reduce_op_wrapper): Generate a wrapper
subroutine for the 'operation' function to enable the library
implementation to be type agnostic and use pointer arithmetic
throughout.
(gfc_resolve_reduce): New function.
* trans-expr.cc (gfc_conv_procedure_call): Add flag for scalar
reduce. Generate a return variable 'sr' for scalar reduce, pass its
address to the library function and return it as the scalar result.
* trans-intrinsic.cc (gfc_conv_intrinsic_function): Array valued
reduce is called in same way as reshape. Fall through for call to
the scalar version.
gcc/testsuite/
PR fortran/85836
* gfortran.dg/reduce_1.f90: New test
* gfortran.dg/reduce_2.f90: New test
libgfortran/
PR libfortran/85836
* Makefile.am : Add reduce.c
* Makefile.in : Regenerated
* gfortran.map : Add _gfortran_reduce, _gfortran_reduce_scalar,
_gfortran_reduce_c and _gfortran_reduce_scalar_c to the list.
* intrinsics/reduce.c (reduce, reduce_scalar, reduce_c,
reduce_scalar_c): New functions and prototypes
Richard Earnshaw [Fri, 21 Mar 2025 15:20:03 +0000 (15:20 +0000)]
arm: testsuite: make unaligned-memcpy-*.c executable tests [PR91614]
These tests have been looking for a very specific instruction sequence
which has the tendency to be fairly unstable as a result. But what is
more interesting is that the the tests must not contain instructions
that can't be used for unaligned data, and whether or not the copy is
executed correctly.
So make these tests executable and scan the assembler only to confirm
the absence of instructions that must not be used when the data is not
aligned.
These tests also used to be restricted to targets that support
unaligned accesses (because you get very different code otherwise).
But now we've made the tests executable and to check for the absence
of problem instructions, just falling back to memcpy *is* an
acceptable implementation. So remove the requirement for unaligned
accesses.
gcc/testsuite:
PR target/91614
* gcc.target/arm/unaligned-memcpy-1.c: Make the test executable.
Only scan for the absence of instructions that cannot access
misaligned data. Remove constraint of having unaligned accesses.
* gcc.target/arm/unaligned-memcpy-2.c: Likewise.
* gcc.target/arm/unaligned-memcpy-3.c: Likewise.
* gcc.target/arm/unaligned-memcpy-4.c: Likewise.
This test is designed to check that if one of the operands is
aligned (but the other isn't) we expand to a sensible sequence and
bypass most of the overhead of doing a memcpy. But on targets without
unaligned accessess, we still end up calling memcpy. It's then a
lottery as to whether the prologue and epilogue code, plus the
set-up for the memcpy itself, generate instructions that match the
scan patterns.
Since in those cases we're not actually testing what the test is looking
for anyway, just skip the test on strict-alignment targets.
Thomas Schwinge [Wed, 19 Mar 2025 11:18:26 +0000 (12:18 +0100)]
C++: Adjust implicit '__cxa_bad_cast' prototype to reality
In 2001 Subversion r40924 (Git commit 52a11cbfcf0cfb32628b6953588b6af4037ac0b6)
"IA-64 ABI Exception Handling", '__cxa_bad_cast' changed from 'void *' to
'void' return type:
--- libstdc++-v3/libsupc++/exception_support.cc
+++ /dev/null
@@ -1,388 +0,0 @@
-[...]
-// Helpers for rtti. Although these don't return, we give them return types so
-// that the type system is not broken.
-extern "C" void *
-__cxa_bad_cast ()
-{
- [...]
-}
-[...]
..., which is in conflict with the library code with 'void' return type:
// BEGIN GLOBAL FUNCTION DECL: __cxa_bad_cast
.visible .func __cxa_bad_cast;
// BEGIN GLOBAL FUNCTION DEF: __cxa_bad_cast
.visible .func __cxa_bad_cast
{
[...]
}
..., and we thus get execution test FAIL for 'g++.dg/rtti/dyncast2.C':
error : Prototype doesn't match for '__cxa_bad_cast' in 'input file 7 at offset 51437', first defined in 'input file 7 at offset 51437'
nvptx-run: cuLinkAddData failed: device kernel image is invalid (CUDA_ERROR_INVALID_SOURCE, 300)
With this patched, we get the expected:
// BEGIN GLOBAL FUNCTION DECL: __cxa_bad_cast
-.extern .func (.param .u64 %value_out) __cxa_bad_cast;
+.extern .func __cxa_bad_cast;
... next to '-malias' variant: commit a1865fd33897bc6c6e0109df0a12ee73ce386315
"Add 'g++.target/nvptx/alias-g++.dg_init_dtor2-1.C'", to document what we're
doing to '-mno-alias'.
Tobias Burnus [Fri, 21 Mar 2025 12:54:49 +0000 (13:54 +0100)]
testsuite/lib/libgomp.exp: compile with -fdiagnostics-plain-output
libgomp.exp added -fno-diagnostics-show-caret and -fdiagnostics-color=never
as 'additional_flags' for compilation. However, it turned out that this now
is insufficient as the [...] part of diagnostics have a hyperlink URL.
Solution: Use the -fdiagnostics-plain-output flag instead, added in commit r11-2701-g129a1319c0ab73. This flag currently implies the following flags:
-fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers
-fdiagnostics-color=never
-fdiagnostics-urls=never
-fdiagnostics-path-format=separate-events
-fdiagnostics-text-art-charset=none
-fno-diagnostics-show-event-links
libgomp/ChangeLog:
* testsuite/lib/libgomp.exp (libgomp_init): Add
-fdiagnostics-plain-output to additional_flags; remove
-fno-diagnostics-show-caret and -fdiagnostics-color=never.
Arthur Cohen [Fri, 3 Jan 2025 15:14:45 +0000 (15:14 +0000)]
gccrs: derive(Clone): Implement derive clone for enum struct variants
gcc/rust/ChangeLog:
* expand/rust-derive-clone.cc (DeriveClone::clone_enum_struct): New function for deriving
enum struct variants.
(DeriveClone::visit_enum): Call into the new function.
gcc/testsuite/ChangeLog:
* rust/compile/nr2/exclude:
* rust/compile/derive_clone_enum1.rs: New test.
* rust/compile/derive_clone_enum2.rs: New test.
* rust/compile/derive_clone_enum3.rs: New test.
* rust/execute/torture/derive_clone_enum1.rs: New test.
Arthur Cohen [Thu, 26 Dec 2024 21:46:03 +0000 (21:46 +0000)]
gccrs: ast: Refactor how lang item paths are handled.
Lang item typepaths were not handled properly, and required a complete overhaul.
All old classes that concerned lang item paths are now modified to use a simpler
version of `AST::LangItemPath`, which has been removed. TypePath segments can now
be lang items, as this is requied for having generic lang item paths such as
PhantomData<T>.
Arthur Cohen [Tue, 23 Jan 2024 16:19:31 +0000 (17:19 +0100)]
gccrs: Fix scan-gimple testcases on LE platforms.
gcc/testsuite/ChangeLog:
* rust/compile/macros/builtin/eager1.rs: Switch to scan-assembler directive as the
GIMPLE dump does not contain strings on LE.
* rust/compile/macros/builtin/recurse2.rs: Likewise.
Owen Avery [Fri, 15 Nov 2024 00:57:42 +0000 (19:57 -0500)]
gccrs: Add ForeverStackStore
ForeverStackStore is meant to partially unify the internal states of
per-namespace ForeverStack instances. This commit does not contain
modifications to ForeverStack which would allow it to rely on a
ForeverStackStore to store nodes, but a future commit should address
this.
gcc/rust/ChangeLog:
* Make-lang.in: Handle rust-forever-stack.cc.
* resolve/rust-forever-stack.h
(class ForeverStackStore): Add.
* resolve/rust-forever-stack.cc: New file, based on
rust-forever-stack.hxx.
liushuyu [Mon, 2 Dec 2024 21:52:35 +0000 (14:52 -0700)]
gccrs: add two more tests to test try-catch (unwind) code generation
gcc/testsuite/ChangeLog:
* rust/compile/try-catch-unwind-old.rs: add a test to test the older
try intrinsics from plain old Rust to v1.78.0
* rust/compile/try-catch-unwind-new.rs: add a test to test the newer
catch_unwind instrinsics since Rust v1.78.0
liushuyu [Mon, 2 Dec 2024 21:24:04 +0000 (14:24 -0700)]
gccrs: rust/intrinsic: add new "catch_unwind" variant of API
gcc/rust/ChangeLog:
* backend/rust-compile-intrinsic.cc: add the new `catch_unwind` variant
of the `try` intrinsic: this variant can be seen on Rust 1.78+
and returns `()` instead of `i32`.
Philip Herron [Thu, 9 Jan 2025 16:47:47 +0000 (16:47 +0000)]
gccrs: match arms are a LUB
Unify rules are not the same as coercion rules. The coercion of ! is
allowed to any type but not for a unify site which is different.
Match arms are another least upper bound coercion.
gcc/rust/ChangeLog:
* backend/rust-compile-expr.cc (CompileExpr::visit): implement coercion
* typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): this is an LUB
* typecheck/rust-unify.cc (UnifyRules::go): remove unify ! coercion
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Philip Herron [Tue, 7 Jan 2025 18:15:37 +0000 (18:15 +0000)]
gccrs: cleanup our enum type layout to be closer to rustc
This changes our enum type layout so for example:
enum Foo {
A,
B,
C(char),
D { x: i32, y: i32 },
}
Used to get layed out like this in gccrs:
union {
struct A { int RUST$ENUM$DISR; };
struct B { int RUST$ENUM$DISR; };
struct C { int RUST$ENUM$DISR; char __0; };
struct D { int RUST$ENUM$DISR; i64 x; i64 y; };
}
This has some issues notably with the constexpr because this is just a
giant union it means its not simple to constify what enum variant we are
looking at because the discriminant is a mess.
This now gets layed out as:
struct {
int RUST$ENUM$DISR;
union {
struct A { };
struct B { };
struct C { char __0; };
struct D { i64 x; i64 y; };
} payload;
}
This layout is much cleaner and allows for our constexpr to work properly.
gcc/rust/ChangeLog:
* backend/rust-compile-expr.cc (CompileExpr::visit): new layout
* backend/rust-compile-pattern.cc (CompilePatternCheckExpr::visit): likewise
(CompilePatternBindings::visit): likewise
* backend/rust-compile-resolve-path.cc: likewise
* backend/rust-compile-type.cc (TyTyResolveCompile::visit): implement new layout
* rust-gcc.cc (constructor_expression): get rid of useless assert
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Owen Avery [Tue, 7 Jan 2025 19:03:13 +0000 (14:03 -0500)]
gccrs: nr2.0: Resolve Self inside impl blocks
gcc/rust/ChangeLog:
* resolve/rust-toplevel-name-resolver-2.0.cc
(TopLevel::visit): Insert a definition for Self when visiting
InherentImpl and TraitImpl instances.
* resolve/rust-toplevel-name-resolver-2.0.h
(TopLevel::visit): Add visitors for InherentImpl and TraitImpl.
Philip Herron [Thu, 19 Dec 2024 16:43:49 +0000 (16:43 +0000)]
gccrs: add support for lang_item eq and PartialEq trait
The Eq and Partial Ord are very similar to the operator overloads
we support for add/sub/etc... but they differ in that usually the
function call name matches the name of the lang item. This time
we need to have support to send in a new path for the method call
on the lang item we want instead of just the name of the lang item.
NOTE: this test case doesnt work correctly yet we need to support
the derive of partial eq on enums to generate the correct comparison
code for that.
Fixes Rust-GCC#3302
gcc/rust/ChangeLog:
* backend/rust-compile-expr.cc (CompileExpr::visit): handle partial_eq possible call
* backend/rust-compile-expr.h: handle case where lang item calls differ from name
* hir/tree/rust-hir-expr.cc (OperatorExprMeta::OperatorExprMeta): new helper
* hir/tree/rust-hir-expr.h: likewise
* typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): handle partial_eq
(TypeCheckExpr::resolve_operator_overload): likewise
* typecheck/rust-hir-type-check-expr.h: likewise
* util/rust-lang-item.cc (LangItem::ComparisonToLangItem): map comparison to lang item
(LangItem::ComparisonToSegment): likewise
* util/rust-lang-item.h: new lang items PartialOrd and Eq
* util/rust-operators.h (enum class): likewise
gcc/testsuite/ChangeLog:
* rust/compile/nr2/exclude: nr2 cant handle this
* rust/compile/cmp1.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Owen Avery [Thu, 2 Jan 2025 10:55:38 +0000 (05:55 -0500)]
gccrs: nr2.0: Improve default, top-level, and late resolvers
gcc/rust/ChangeLog:
* resolve/rust-default-resolver.cc
(DefaultResolver::visit): Make sure to scope visitation of the
children of type definition items.
* resolve/rust-default-resolver.h
(DefaultResolver::visit): Add overrides for TupleStruct, Union,
and TypeAlias.
* resolve/rust-late-name-resolver-2.0.cc
(Late::visit): Remove override for Enum.
* resolve/rust-late-name-resolver-2.0.h
(Late::visit): Likewise.
* resolve/rust-toplevel-name-resolver-2.0.cc
(TopLevel::visit): Rely more on DefaultResolver::visit.
* resolve/rust-toplevel-name-resolver-2.0.h
(TopLevel::visit): Remove override for BlockExpr.
Arthur Cohen [Sat, 21 Dec 2024 22:56:52 +0000 (22:56 +0000)]
gccrs: ast: Add new Kind enums for more precise downcasting
This commit adds things like Item::Kind, Expr::Kind, etc, and implements the associated `get_*_kind` functions.
It also removes the more generic AST::Kind enum we were using, which was incomplete and painful to use.
Arthur Cohen [Wed, 25 Dec 2024 17:55:09 +0000 (17:55 +0000)]
gccrs: lower: Correctly lower parenthesized types
This is useful for handling multiple trait bounds, and required for better handling of auto traits.
gcc/rust/ChangeLog:
* hir/rust-ast-lower-type.cc (ASTLoweringType::visit): Add implementation for
ParenthesizedType.
* hir/rust-ast-lower-type.h: Declare that new visitor.
Liam Naddell [Tue, 17 Dec 2024 16:48:03 +0000 (11:48 -0500)]
gccrs: Fix NR2.0 compiler ICE caused by Generics in Enums
gcc/rust/ChangeLog:
* resolve/rust-late-name-resolver-2.0.cc:
Change the late name resolver to enter proper lexical scope during typechecking
* resolve/rust-late-name-resolver-2.0.h:
Add needed prototype to header
* resolve/rust-toplevel-name-resolver-2.0.cc:
Add generic parameters to enum's scoped RIB to allow for proper name resolution on types.
gcc/testsuite/ChangeLog:
* rust/compile/issue-3304.rs:
Add small test for generics+enums combination for NR2.0
Arthur Cohen [Wed, 18 Dec 2024 11:20:27 +0000 (12:20 +0100)]
gccrs: lang-items: Collect trait functions that are lang items
gcc/rust/ChangeLog:
* ast/rust-collect-lang-items.cc (CollectLangItems::visit): Add visitor for collecting
functions that might be lang items.
* ast/rust-collect-lang-items.h: Likewise.
Arthur Cohen [Wed, 25 Dec 2024 11:03:44 +0000 (11:03 +0000)]
gccrs: resolve: Name resolve trait bounds properly
gcc/rust/ChangeLog:
* resolve/rust-ast-resolve-type.cc (ResolveTypeToCanonicalPath::visit): Resolve additional
trait bounds.
* resolve/rust-late-name-resolver-2.0.cc (Late::visit): Error out properly on unresolved
type-path instead of crashing.
gcc/testsuite/ChangeLog:
* rust/compile/nr2/exclude: Exclude additional-trait-bounds2 for different error message.
* rust/compile/additional-trait-bounds1.rs: New test.
* rust/compile/additional-trait-bounds2.rs: New test.
* rust/compile/additional-trait-bounds2nr2.rs: New test.
Philip Herron [Fri, 13 Dec 2024 15:51:55 +0000 (15:51 +0000)]
gccrs: implement the TuplePattern and use it for function patterns
In order to handle the tuple pattern of: fn test ((x _) : (i32, i32)) -> i32 { x }
we need to recognize that ABI wise this function still takes a tuple as the parameter
to this function its just how we can address the "pattern" of the tuple changes.
So reall if this was C it would look like:
void test (struct tuple_type __prameter)
{
return __parameter.0
}
The code here reuses our existing pattern code so that we generate these implicit
bindings of the paramter with a field access so any time x is referenced it's really
just emplacing __parameter.0 for the field access into the struct which is a tuple.
Fixes Rust-GCC#2847
gcc/rust/ChangeLog:
* backend/rust-compile-fnparam.cc (CompileFnParam::visit): compile tuple patterns
(CompileSelfParam::compile): update return type
(CompileFnParam::create_tmp_param_var): return Bvariable not tree to stop ICE
* backend/rust-compile-fnparam.h: update prototype
* backend/rust-compile-pattern.cc (CompilePatternBindings::visit): implement TuplePattern
* backend/rust-compile-pattern.h: update prototype
gcc/testsuite/ChangeLog:
* rust/compile/issue-2847.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Dhruv Chawla [Wed, 19 Mar 2025 16:34:09 +0000 (09:34 -0700)]
aarch64: Add support for -mcpu=olympus
This adds support for the NVIDIA Olympus core to the AArch64 backend. The
initial patch does not add any special tuning decisions, and those may come
later.
Bootstrapped and tested on aarch64-none-linux-gnu.
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def (olympus): New entry.
* config/aarch64/aarch64-tune.md: Regenerate.
* doc/invoke.texi (AArch64 Options): Document the above.
Arthur Cohen [Wed, 6 Nov 2024 15:32:35 +0000 (16:32 +0100)]
gccrs: hir: Start adapting visitors to accept multiple kinds of Paths
gcc/rust/ChangeLog:
* ast/rust-item.h: Add new method to specifically get a type-path.
* ast/rust-path.cc (LangItemPath::as_string): Implement properly.
* hir/rust-ast-lower-type.cc (ASTLowerTypePath::translate): Adapt
visitor to use the new LangItemPath.
* hir/rust-ast-lower-type.h: Likewise.
* resolve/rust-ast-resolve-item.cc (ResolveItem::visit): Likewise.
* resolve/rust-ast-resolve-type.h: Likewise.
projects / thirdparty / gcc.git / log
