Richard Biener [Thu, 23 Feb 2023 10:03:03 +0000 (11:03 +0100)]
tree-optimization/108888 - call if-conversion
The following makes sure to only predicate calls necessary.
PR tree-optimization/108888
* tree-if-conv.cc (if_convertible_stmt_p): Set PLF_2 on
calls to predicate.
(predicate_statements): Only predicate calls with PLF_2.
Max Filippov [Thu, 23 Feb 2023 06:08:21 +0000 (22:08 -0800)]
xtensa: fix PR target/108876
In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call
insn included (use (reg:SI A0_REG)) to fix the problem, which added
a USE chain unconditionally to the data flow of register A0 during
the sibling call.
As a result, df_regs_ever_live_p (A0_REG) returns true, so even if
register A0 is not used outside of the sibling call insn, saves and
restores to stack slots are emitted in pro/epilogue, and finally
code size increases.
(This is why I never included (use A0) in sibling calls)
/* example */
extern int foo(int);
int test(int a) {
return foo(a * 3 + 1);
}
The essential cause is that we emit (use A0) *before* the insns that
does the stack pointer adjustment during epilogue expansion, so the
liveness of register A0 ends early, so register A0 is reused afterwards.
This patch fixes the problem and avoids such regression by doing the
emit of (use A0) in the sibling call epilogue expansion at the end.
(IMHO the "rnreg" pass doesn't take REG_ALLOC_ORDER into account;
it just seems to allocate registers in fixed_regs index order,
which may have hurt register A0 that became allocatable in the recent
patch)
gcc/ChangeLog:
PR target/108876
* config/xtensa/xtensa.cc (xtensa_expand_epilogue):
Emit (use (reg:SI A0_REG)) at the end in the sibling call
(i.e. the same place as (return) in the normal call).
Marek Polacek [Wed, 22 Feb 2023 20:17:03 +0000 (15:17 -0500)]
c-family: avoid compile-time-hog in c_genericize [PR108880]
This fixes a compile-time hog with UBSan. This only happened in cc1 but
not cc1plus. The problem is ultimately that c_genericize_control_stmt/
STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited
nodes, so it kept on recursing for a long time. We should be able to
use the pset that c_genericize created. We just need to use walk_tree
instead of walk_tree_w_d so that the pset is explicit.
PR c/108880
gcc/c-family/ChangeLog:
* c-gimplify.cc (c_genericize_control_stmt) <case STATEMENT_LIST>: Pass
pset to walk_tree_1.
(c_genericize): Call walk_tree with an explicit pset.
Alexandre Oliva [Wed, 22 Feb 2023 17:35:36 +0000 (14:35 -0300)]
testsuite: Skip module_cmi_p and related unsupported module test
When a multi-source module is found to be unsupported, we fail
module_cmi_p and subsequent sources. Override proc unsupported to
mark the result in module_do, and test it to skip module_cmp_p and
subsequent related tests.
for gcc/testsuite/ChangeLog
* g++.dg/modules/modules.exp: Override unsupported to update
module_do, and test it after dg-test.
Alexandre Oliva [Wed, 22 Feb 2023 17:35:34 +0000 (14:35 -0300)]
[arm] avoid aes-1742098 mitigation in combine tests
The expected asm output for aes-fuse-[12].c does not correspond to
that which is generated when -mfix-cortex-a57-aes-1742098 is enabled.
The mitigation was introduced after the test, and enabled by default
for the selected processor, a72. Select a53 instead, where the
migitation is not enabled by default, and all the expected fusions can
take place.
for gcc/testsuite/ChangeLog
* gcc.target/arm/aes-fuse-1.c: Switch to -mcpu=cortex-a53.
* gcc.target/arm/aes-fuse-2.c: Likewise.
Alexandre Oliva [Wed, 22 Feb 2023 17:35:31 +0000 (14:35 -0300)]
Drop need for constant I in ctf test
Though I is supposed to be a constant expression, this is not the case
on vxworks, but this is not what this debug information format test is
testing for, so use real constants to initialize complex variables.
for gcc/testsuite/ChangeLog
* gcc.dg/debug/ctf/ctf-complex-1.c: Do not test whether I is
usable in initializers.
Alexandre Oliva [Wed, 22 Feb 2023 17:35:27 +0000 (14:35 -0300)]
xfail fp-uint64-convert-double-* on all arm targets
It wasn't long ago that I xfailed these tests on arm-*-eabi, but the
fail is expected on all other arm targets: even when hard float is
available, conversions between 64-bit integers and double are always
emulated on ARM, and the emulation disregards rounding modes. So,
bump the xfail to all of arm-*-*.
for gcc/testsuite/ChangeLog
* gcc.dg/torture/fp-uint64-convert-double-1.c: XFAIL on all of
arm-*-*.
* gcc.dg/torture/fp-uint64-convert-double-2.c: Likewise.
Alexandre Oliva [Wed, 22 Feb 2023 17:35:20 +0000 (14:35 -0300)]
testsuite: Accept pmf-vbit-in-delta extra warning
cp_build_binary_op, that issues -Waddress warnings, issues an extra
warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect
when comparing a pointer-to-member-function literal with null.
The reason for the extra warning is that, on arm targets,
TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, which
causes a different path to be taken, that extracts the
pointer-to-function and the delta fields (minus the vbit) and compares
each one with zero. It's when comparing this pointer-to-function with
zero, in a recursive cp_build_binary_op, that another warning is
issued.
I suppose there should be a way to skip the warning in this recursive
call, without disabling other warnings that might be issued there, but
this patch only arranges for the test to tolerate the extra warning.
for gcc/testsuite/ChangeLog
* g++.dg/warn/Waddress-5.C: Tolerate extra -Waddress warning.
Alexandre Oliva [Wed, 22 Feb 2023 17:35:18 +0000 (14:35 -0300)]
[libstdc++] do not destruct mutex_pool mutexes
On vxworks, after destroying the semaphore used to implement a mutex,
__gthread_mutex_lock fails and __gnu_cxx::__mutex::lock calls
__throw_concurrence_lock_error. Nothing ensures the mutex_pool
mutexes survive init-once objects containing _Safe_sequence_base. If
such an object completes construction before mutex_pool
initialization, it will be registered for atexit destruction after the
mutex_pool mutexes, so the _M_detach_all() call in the
_Safe_sequence_base dtor will use already-destructed mutexes, and
basic_string/requirements/citerators_cc fails calling terminate.
This patch fixes this problem by ensuring the mutex pool mutexes are
constructed on demand, on a statically-allocated buffer, but never
destructed.
for libstdc++-v3/ChangeLog
* src/c++11/shared_ptr.cc (__gnu_internal::get_mutex):
Avoid destruction of the mutex pool.
Alexandre Oliva [Wed, 22 Feb 2023 17:35:13 +0000 (14:35 -0300)]
[libstdc++] [testsuite] intro/names.cc: undef func on vxw7krn
The '#define func' added in 2021, to test that system headers don't
violate the user namespace, exposes such a bug in the vxworks sysLib.h
header, so add yet another such annotated workaround.
for libstdc++-v3/ChangeLog
* testsuite/17_intro/names.cc: Undef func on vxworks >= 7 in
kernel mode.
Thomas Schwinge [Wed, 22 Feb 2023 10:42:43 +0000 (11:42 +0100)]
Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types
As reported in "Rust related issues" at the end of
<https://inbox.sourceware.org/gcc-patches/20221219212344.ewtuzd2jtztm77x2@lug-owl.de>
"Modula-2 / Rust: Many targets failing",
<https://github.com/Rust-GCC/gccrs/issues/1713>
"Test failure on msp430-elfbare target", for '--target=msp430-elfbar' we ICE:
..., were 'targetm.eh_return_filter_mode' (that is,
'gcc/targhooks.cc:default_eh_return_filter_mode',
via calling 'targetm.unwind_word_mode':
'gcc/config/msp430/msp430.cc:msp430_unwind_word_mode') returns 'PSImode',
and 'lang_hooks.types.type_for_mode' (that is,
'gcc/rust/rust-lang.cc:grs_langhook_type_for_mode') returns 'NULL' for
'PSImode'.
As, for example, discussed in <https://gcc.gnu.org/PR46805>
"ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O -fno-tree-scev-cprop -ftree-vectorize",
we have to support "random" modes/types in the 'type_for_mode' langhook.
gcc/rust/
* rust-lang.cc (grs_langhook_type_for_mode): Also consider all
'int_n' modes/types.
Andrew Stubbs [Thu, 28 Jul 2022 15:07:22 +0000 (16:07 +0100)]
vect: inbranch SIMD clones
There has been support for generating "inbranch" SIMD clones for a long time,
but nothing actually uses them (as far as I can see).
This patch add supports for a sub-set of possible cases (those using
mask_mode == VOIDmode). The other cases fail to vectorize, just as before,
so there should be no regressions.
The sub-set of support should cover all cases needed by amdgcn, at present.
gcc/ChangeLog:
* internal-fn.cc (expand_MASK_CALL): New.
* internal-fn.def (MASK_CALL): New.
* internal-fn.h (expand_MASK_CALL): New prototype.
* omp-simd-clone.cc (simd_clone_adjust_argument_types): Set vector_type
for mask arguments also.
* tree-if-conv.cc: Include cgraph.h.
(if_convertible_stmt_p): Do if conversions for calls to SIMD calls.
(predicate_statements): Convert functions to IFN_MASK_CALL.
* tree-vect-loop.cc (vect_get_datarefs_in_loop): Recognise
IFN_MASK_CALL as a SIMD function call.
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Handle
IFN_MASK_CALL as an inbranch SIMD function call.
Generate the mask vector arguments.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-simd-clone-16.c: New test.
* gcc.dg/vect/vect-simd-clone-16b.c: New test.
* gcc.dg/vect/vect-simd-clone-16c.c: New test.
* gcc.dg/vect/vect-simd-clone-16d.c: New test.
* gcc.dg/vect/vect-simd-clone-16e.c: New test.
* gcc.dg/vect/vect-simd-clone-16f.c: New test.
* gcc.dg/vect/vect-simd-clone-17.c: New test.
* gcc.dg/vect/vect-simd-clone-17b.c: New test.
* gcc.dg/vect/vect-simd-clone-17c.c: New test.
* gcc.dg/vect/vect-simd-clone-17d.c: New test.
* gcc.dg/vect/vect-simd-clone-17e.c: New test.
* gcc.dg/vect/vect-simd-clone-17f.c: New test.
* gcc.dg/vect/vect-simd-clone-18.c: New test.
* gcc.dg/vect/vect-simd-clone-18b.c: New test.
* gcc.dg/vect/vect-simd-clone-18c.c: New test.
* gcc.dg/vect/vect-simd-clone-18d.c: New test.
* gcc.dg/vect/vect-simd-clone-18e.c: New test.
* gcc.dg/vect/vect-simd-clone-18f.c: New test.
Ju-Zhe Zhong [Fri, 17 Feb 2023 12:51:14 +0000 (20:51 +0800)]
RISC-V: Add floating-point RVV C/C++ api
Add RVV floating-point C/C++ api tests.
The api unit-tests are all passed but not commit.
They are located at RISC-V foundation repo:
https://github.com/riscv-collab/riscv-gcc/tree/rvv-submission-v1
* gcc.target/riscv/rvv/base/ternop_vv_constraint-3.c: New test.
* gcc.target/riscv/rvv/base/ternop_vv_constraint-4.c: New test.
* gcc.target/riscv/rvv/base/ternop_vv_constraint-5.c: New test.
* gcc.target/riscv/rvv/base/ternop_vv_constraint-6.c: New test.
* gcc.target/riscv/rvv/base/ternop_vx_constraint-8.c: New test.
* gcc.target/riscv/rvv/base/ternop_vx_constraint-9.c: New test.
Thomas Schwinge [Wed, 14 Dec 2022 16:16:42 +0000 (17:16 +0100)]
Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere
I noticed that GCC/Rust recently lost all LTO variants in torture testing:
PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O0 (test for excess errors)
PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O1 (test for excess errors)
PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O2 (test for excess errors)
-PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors)
-PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors)
PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O3 -g (test for excess errors)
PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -Os (test for excess errors)
Etc.
The reason is that when probing for availability of LTO, we run into:
spawn [...]/build-gcc/gcc/testsuite/rust/../../gccrs -B[...]/build-gcc/gcc/testsuite/rust/../../ -fdiagnostics-plain-output -frust-incomplete-and-experimental-compiler-do-not-use -flto -c -o lto8274.o lto8274.c
cc1: warning: command-line option '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but not for C
For GCC/Rust testing, this flag is (as of recently) defaulted in
'gcc/testsuite/lib/rust.exp:rust_init':
A few more "command-line option [...] is valid for [...] but not for [...]"
instances were found in the test suite logs, when more than one language is
involved.
With '-Wno-complain-wrong-lang' used in
'gcc/testsuite/lib/target-supports.exp:check_compile', we get back:
PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O0 (test for excess errors)
PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O1 (test for excess errors)
PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O2 (test for excess errors)
+PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors)
+PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors)
PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -O3 -g (test for excess errors)
PASS: rust/compile/torture/all_doc_comment_line_blocks.rs -Os (test for excess errors)
Etc., and in total:
=== rust Summary for unix ===
# of expected passes [-4990-]{+6718+}
# of expected failures [-39-]{+51+}
Anything that 'gcc/opts-global.cc:complain_wrong_lang' might do is cut
short by '-Wno-complain-wrong-lang', not just the one 'warning'
diagnostic. This corresponds to what already exists via
'lang_hooks.complain_wrong_lang_p'.
The 'gcc/opts-common.cc:prune_options' changes follow the same rationale
as PR67640 "driver passes -fdiagnostics-color= always last": we need to
process '-Wno-complain-wrong-lang' early, so that it properly affects
other options appearing before it on the command line.
Thomas Schwinge [Fri, 10 Feb 2023 09:43:24 +0000 (10:43 +0100)]
In 'contrib/config-list.mk', clarify i686-symbolics-gnu to i686-gnu
Already in the first revision of 'contrib/config-list.mk', i686-symbolics-gnu
has been present, but it's not clear to me whether that was meant to be
Symbolics as in the manufacturer, <https://en.wikipedia.org/wiki/Symbolics>,
with GNU (that is, GNU/Hurd) kernel/operating system (user land), or Symbolics
kernel with GNU operating system (user land)?
I can't find any mention of "Symbolics" in the history of 'config.sub'
upstream.
Either way, GCC configures i686-symbolics-gnu exactly the same as i686-gnu:
$ sed -n -e '/Using .* host machine hooks\.$/q' -e '/^Using the following target machine macro files:$/,$p' log/i686-gnu-make.out
Using the following target machine macro files:
[...]/gcc/config/vxworks-dummy.h
[...]/gcc/config/i386/i386.h
[...]/gcc/config/i386/unix.h
[...]/gcc/config/i386/att.h
[...]/gcc/config/elfos.h
[...]/gcc/config/gnu-user.h
[...]/gcc/config/glibc-stdint.h
[...]/gcc/config/i386/gnu-user-common.h
[...]/gcc/config/i386/gnu-user.h
[...]/gcc/config/gnu.h
[...]/gcc/config/i386/gnu.h
[...]/gcc/config/initfini-array.h
..., so let's clarify i686-symbolics-gnu to i686-gnu.
contrib/
* config-list.mk (LIST): Clarify i686-symbolics-gnu to i686-gnu.
David Malcolm [Tue, 21 Feb 2023 21:58:36 +0000 (16:58 -0500)]
analyzer: stop exploring the path after certain diagnostics [PR108830]
PR analyzer/108830 reports a situation in which there are lots of
followup -Wanalyzer-null-dereference warnings after the first access of
a NULL pointer, leading to very noisy output from -fanalyzer.
The analyzer's logic for stopping emitting multiple warnings from a
state machine doesn't quite work for NULL pointers: it attempts to
transition the malloc state machine's NULL pointer to the "stop" state,
which doesn't seem to make much sense in retrospect, and seems to get
confused over types.
Similarly, poisoned_value_diagnostic can be very noisy for uninit
variables, emitting a warning for every access to an uninitialized
variable. In theory, region_model::check_for_poison makes some attempts
to suppress followups, but only for the symbolic value itself; if the
user's code keeps accessing the same region, we would get a warning on
each one. For example, this showed up in Doom's s_sound.c where there
were 7 followup uninit warnings after the first uninit warning in
"S_ChangeMusic".
This patch adds an extra mechanism, giving pending diagnostics the
option of stopping the analysis of an execution path if they're saved
for emission on it, and turning this on for these warnings:
-Wanalyzer-null-dereference
-Wanalyzer-null-argument
-Wanalyzer-use-after-free
-Wanalyzer-use-of-pointer-in-stale-stack-frame
-Wanalyzer-use-of-uninitialized-value
Doing so should hopefully reduce the cascades of diagnostics that
-fanalyzer can sometimes emit.
I added a -fno-analyzer-suppress-followups for the cases where you
really want the followup warnings (e.g. in some DejaGnu tests, and
for microbenchmarks of UB detection, such as PR analyzer/104224).
Integration testing shows this patch reduces the number of probable
false positives reported by 94, and finds one more true positive:
gcc/analyzer/ChangeLog:
PR analyzer/108830
* analyzer.opt (fanalyzer-suppress-followups): New option.
* engine.cc (impl_region_model_context::warn): Terminate the path
if the diagnostic's terminate_path_p vfunc returns true and
-fanalyzer-suppress-followups is true (the default).
(impl_sm_context::warn): Likewise, for both overloads.
* pending-diagnostic.h (pending_diagnostic::terminate_path_p): New
vfunc.
* program-state.cc (program_state::on_edge): Terminate the path if
the ctxt requests it during updating the edge.
* region-model.cc (poisoned_value_diagnostic::terminate_path_p):
New vfunc.
* sm-malloc.cc (null_deref::terminate_path_p): New vfunc.
(null_arg::terminate_path_p): New vfunc.
Harald Anlauf [Mon, 20 Feb 2023 20:28:09 +0000 (21:28 +0100)]
Fortran: improve checking of character length specification [PR96025]
gcc/fortran/ChangeLog:
PR fortran/96025
* parse.cc (check_function_result_typed): Improve type check of
specification expression for character length and return status.
(parse_spec): Use status from above.
* resolve.cc (resolve_fntype): Prevent use of invalid specification
expression for character length.
gcc/testsuite/ChangeLog:
PR fortran/96025
* gfortran.dg/pr96025.f90: New test.
- Import druntime v2.102.0-beta.1
- The default `Throwable.TraceInfo' generation now is `@nogc'.
- `Object.factory' method has now been deprecated.
Phobos changes:
- Import phobos v2.102.0-beta.1
- Added float- and double-precision implementations for log
function families in std.math.
- `std.typecons.Unique' now calls `destroy` on struct types
gcc/d/ChangeLog:
* Make-lang.in (D_FRONTEND_OBJS): Add d/location.o.
* d-lang.cc (d_init_options): Update for new front-end interface.
(d_post_options): Call Loc::set after handling options.
* dmd/MERGE: Merge upstream dmd 09faa4eacd.
* dmd/VERSION: Bump version to v2.102.0-beta.1.
libphobos/ChangeLog:
* libdruntime/MERGE: Merge upstream druntime 09faa4eacd.
* src/MERGE: Merge upstream phobos 13ef27a56.
* testsuite/libphobos.exceptions/refcounted.d: Add test for chained
reference counted exceptions.
* testsuite/libphobos.shared/finalize.d: Add dg-warning for deprecated
factory interfaces.
* testsuite/libphobos.gc/issue22843.d: New test.
Iain Buclaw [Sun, 29 Jan 2023 20:25:40 +0000 (21:25 +0100)]
d: Only handle the left-to-right evaluation of a call expression during gimplify
Removes an unnecessary rewriting of the front-end AST during lowering.
gcc/d/ChangeLog:
* d-codegen.cc (d_build_call): Remove front-end expansion of
side-effects in a call expression.
* d-gimplify.cc (d_gimplify_call_expr): Gimplify the callee before its
arguments.
The following gets rid of the idea that we should prevent setjmp
like calls from popping up in uncontrolled way in the IL for now.
The solution is probably to handle it similar as noreturn has
the ctrl-altering flag on stmts, but use another flag, for example
ctrl-receiving which would also make sure the stmt is first.
PR tree-optimization/108691
* tree-ssa-dce.cc (eliminate_unnecessary_stmts): Remove
assert about calls_setjmp not becoming true when it was false.
Richard Biener [Mon, 20 Feb 2023 11:58:50 +0000 (12:58 +0100)]
tree-optimization/108793 - niter compute type mismatch
When computing the number of iterations until wrap types are mixed up,
eventually leading to checking ICEs with a pointer bitwise inversion.
The following uses niter_type for the calculation.
PR tree-optimization/108793
* tree-ssa-loop-niter.cc (number_of_iterations_until_wrap):
Use convert operands to niter_type when computing num.
Arthur Cohen [Thu, 17 Nov 2022 15:50:58 +0000 (16:50 +0100)]
gccrs: const evaluator: Remove get_nth_callarg
We only used one path of the C++ folder's get_nth_callarg function:
CALL_EXPR_ARG. Replace all calls to get_nth_callarg by macro calls to
CALL_EXPR_ARG
Philip Herron [Mon, 7 Nov 2022 13:43:04 +0000 (13:43 +0000)]
gccrs: Fix undefined behaviour issues on macos
This adds missing copy constructors to HIR::PathExprSegment which were
wrongly defaulting to empty vectors when apply specified generic arguments
to method calls.
Philip Herron [Fri, 21 Oct 2022 14:43:54 +0000 (15:43 +0100)]
gccrs: Add initial support for argument capture of closures
When we have a closure expression that captures a parent function's
variable we must setup the closure data to contain this. Ignoring
moveability and mutability requires for now, this patch creates the closure
structure with fields for each of the captured variables. When it comes to
compilation of the closure expression in order to support nested closures
we must setup a context of implicit mappings so that for all path
resolution we hit this implicit closure mappings lookups code before any
lookup_var_decl as this decl will not exist so the order here is important
during path resolution which is a similar problem to match expression
destructuring.
Fixes #195
gcc/rust/ChangeLog:
* backend/rust-compile-context.cc (Context::push_closure_context): New function.
(Context::pop_closure_context): Likewise.
(Context::insert_closure_binding): Likewise.
(Context::lookup_closure_binding): Likewise.
* backend/rust-compile-context.h: Declare new functions and closure mappings.
* backend/rust-compile-expr.cc (CompileExpr::visit): Visit captures properly.
(CompileExpr::generate_closure_function): Compile captures properly.
* backend/rust-compile-resolve-path.cc (ResolvePathRef::resolve): Check for
closure bindings.
* backend/rust-compile-type.cc (TyTyResolveCompile::visit): Compile capture list's
types as well.
Philip Herron [Fri, 21 Oct 2022 12:40:40 +0000 (13:40 +0100)]
gccrs: Add closure binding's tracking to name resolution
When we have a closure block referencing variables in a parent function,
we must track what these are. We do this by having a context of closures
so if we have a variable reference and its declared in a rib whose node id
is less than the node id of the closure's node id we know it must be a
captured variable. We also need to iterate all possible closure contexts
as we might be in the case of a nested closure.
Addresses #195
gcc/rust/ChangeLog:
* resolve/rust-ast-resolve-expr.cc (ResolveExpr::visit): Use proper closure
contexts.
* resolve/rust-name-resolver.cc (Scope::lookup_decl_type): New function.
(Scope::lookup_rib_for_decl): Likewise.
(Resolver::insert_resolved_name): Insert captured items.
(Resolver::push_closure_context): New function.
(Resolver::pop_closure_context): Likewise.
(Resolver::insert_captured_item): Likewise.
(Resolver::decl_needs_capture): Likewise.
(Resolver::get_captures): Likewise.
* resolve/rust-name-resolver.h: Declare new functions.
Arthur Cohen [Wed, 26 Oct 2022 14:35:12 +0000 (16:35 +0200)]
gccrs: intrinsics: Cleanup error handling around atomic_store_*
gcc/rust/ChangeLog:
* backend/rust-compile-intrinsic.cc (check_for_basic_integer_type): New function.
(build_atomic_builtin_name): Use HIR Type instead of `tree`.
(atomic_store_handler_inner): Cleanup error handling.
(unchecked_op_inner): Likewise.
Arthur Cohen [Tue, 25 Oct 2022 09:24:10 +0000 (11:24 +0200)]
gccrs: intrinsics: Add early implementation for atomic_store_{seqcst, relaxed, release}
gcc/rust/ChangeLog:
* backend/rust-builtins.cc (BuiltinsContext::setup_atomic_fns): New function.
(BuiltinsContext::setup): Call `setup_atomic_fns`.
* backend/rust-builtins.h: Declare `setup_atomic_fns`.
* backend/rust-compile-intrinsic.cc (atomic_store_handler_inner): New function.
(atomic_store_handler): New handler.
(make_unsigned_long_tree): Add helper around making unsigned long trees.
(prefetch_data_handler): Use `make_unsigned_long_tree`.
(build_atomic_builtin_name): New function.
gcc/testsuite/ChangeLog:
* rust/compile/torture/intrinsics-4.rs: New test.
* rust/compile/torture/intrinsics-5.rs: New test.
* rust/execute/torture/atomic_store.rs: New test.
Philip Herron [Wed, 19 Oct 2022 17:02:36 +0000 (18:02 +0100)]
gccrs: Closure support at CallExpr
gcc/rust/ChangeLog:
* backend/rust-compile-context.h: Add new functions: `insert_closure_decl` and
`lookup_closure_decl`.
* backend/rust-compile-expr.cc (CompileExpr::visit): Start compiling Closures properly.
(CompileExpr::generate_closure_function): New function.
(CompileExpr::generate_closure_fntype): Likewise.
* backend/rust-compile-expr.h: Declare `generate_closure_function` and
`generate_closure_fntype`.
* backend/rust-compile-type.cc (TyTyResolveCompile::visit): Visit closure types properly.
* backend/rust-mangle.cc (legacy_mangle_name): Add support for closures.
* backend/rust-tree.h (RS_CLOSURE_FLAG): Add new tree macro.
(RS_CLOSURE_TYPE_P): And checking for it on tree nodes.
* typecheck/rust-tyty.cc (ClosureType::is_equal): Add implementation.
Philip Herron [Wed, 19 Oct 2022 09:59:18 +0000 (10:59 +0100)]
gccrs: Refactor method call type checking
gcc/rust/ChangeLog:
* typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): Simplify method
call type checking by removing visitor and instead using one static cast. Use the
new interface.
* typecheck/rust-tyty-call.cc (TypeCheckMethodCallExpr::visit): Likewise.
(TypeCheckMethodCallExpr::go): Likewise.
(TypeCheckMethodCallExpr::check): Likewise.
* typecheck/rust-tyty-call.h (class TypeCheckMethodCallExpr): Likewise.
(class Argument): Likewise.