Thomas Schwinge [Wed, 1 Feb 2023 11:30:28 +0000 (12:30 +0100)]
Fix 'omp_allocator_handle_kind' example in 'gfortran.dg/gomp/allocate-4.f90'
I've noticed that while 'gfortran.dg/gomp/allocate-4.f90' is all-PASS for
x86_64-pc-linux-gnu (default) '-m64' testing, it does have one FAIL for
'-m32' testing: 'test for errors, line 25'. Here's the 'diff':
@@ -1,8 +1,3 @@
-source-gcc/gcc/testsuite/gfortran.dg/gomp/allocate-4.f90:25:34:
-
- 25 | !$omp allocate (var1) allocator(10) ! { dg-error "Expected integer expression of the 'omp_allocator_handle_kind' kind at .1." }
- | 1
-Error: Expected integer expression of the ‘omp_allocator_handle_kind’ kind at (1)
source-gcc/gcc/testsuite/gfortran.dg/gomp/allocate-4.f90:28:130:
28 | !$omp allocate (var2) ! { dg-error "'var2' in 'allocate' directive at .1. is not present in associated 'allocate' statement." }
I understand that's due to an "accidental" non-match vs. match of
'10' vs. 'omp_allocator_handle_kind' ('c_intptr_t') data types:
Andrew Stubbs [Mon, 6 Feb 2023 12:47:28 +0000 (12:47 +0000)]
amdgcn: Pass -mstack-size through to runtime
But only for the offload case.
gcc/ChangeLog:
* config/gcn/mkoffload.cc (gcn_stack_size): New global variable.
(process_asm): Create a constructor for GCN_STACK_SIZE.
(main): Parse the -mstack-size option.
Fix the 'strict' modifier status: it is already listed (as 'Y') for OpenMP
5.1 for num_task and grainsize; only strict on num_threads is new with TR11.
libgomp/
* libgomp.texi (OpenMP TR11): Fix item for 'strict' modifier.
Andrew Stubbs [Thu, 1 Dec 2022 17:30:21 +0000 (17:30 +0000)]
amdgcn, libgomp: Manually allocated stacks
Switch from using stacks in the "private segment" to using a memory block
allocated on the host side. The primary reason is to permit the reverse
offload implementation to access values located on the device stack, but
there may also be performance benefits, especially with repeated kernel
invocations.
This implementation unifies the stacks with the "team arena" optimization
feature, and now allows both to have run-time configurable sizes.
A new ABI is needed, so all libraries must be rebuilt, and newlib must be
version 4.3.0.20230120 or newer.
gcc/ChangeLog:
* config/gcn/gcn-run.cc: Include libgomp-gcn.h.
(struct kernargs): Replace the common content with kernargs_abi.
(struct heap): Delete.
(main): Read GCN_STACK_SIZE envvar.
Allocate space for the device stacks.
Write the new kernargs fields.
* config/gcn/gcn.cc (gcn_option_override): Remove stack_size_opt.
(default_requested_args): Remove PRIVATE_SEGMENT_BUFFER_ARG and
PRIVATE_SEGMENT_WAVE_OFFSET_ARG.
(gcn_addr_space_convert): Mask the QUEUE_PTR_ARG content.
(gcn_expand_prologue): Move the TARGET_PACKED_WORK_ITEMS to the top.
Set up the stacks from the values in the kernargs, not private.
(gcn_expand_builtin_1): Match the stack configuration in the prologue.
(gcn_hsa_declare_function_name): Turn off the private segment.
(gcn_conditional_register_usage): Ensure QUEUE_PTR is fixed.
* config/gcn/gcn.h (FIXED_REGISTERS): Fix the QUEUE_PTR register.
* config/gcn/gcn.opt (mstack-size): Change the description.
include/ChangeLog:
* gomp-constants.h (GOMP_VERSION_GCN): Bump.
libgomp/ChangeLog:
* config/gcn/libgomp-gcn.h (DEFAULT_GCN_STACK_SIZE): New define.
(DEFAULT_TEAM_ARENA_SIZE): New define.
(struct heap): Move to this file.
(struct kernargs_abi): Likewise.
* config/gcn/team.c (gomp_gcn_enter_kernel): Use team arena size from
the kernargs.
* libgomp.h: Include libgomp-gcn.h.
(TEAM_ARENA_SIZE): Remove.
(team_malloc): Update the error message.
* plugin/plugin-gcn.c (struct kernargs): Move common content to
struct kernargs_abi.
(struct agent_info): Rename team arenas to ephemeral memories.
(struct team_arena_list): Rename ....
(struct ephemeral_memories_list): to this.
(struct heap): Delete.
(team_arena_size): New variable.
(stack_size): New variable.
(print_kernel_dispatch): Update debug messages.
(init_environment_variables): Read GCN_TEAM_ARENA_SIZE.
Read GCN_STACK_SIZE.
(get_team_arena): Rename ...
(configure_ephemeral_memories): ... to this, and set up stacks.
(release_team_arena): Rename ...
(release_ephemeral_memories): ... to this.
(destroy_team_arenas): Rename ...
(destroy_ephemeral_memories): ... to this.
(create_kernel_dispatch): Add num_threads parameter.
Adjust for kernargs_abi refactor and ephemeral memories.
(release_kernel_dispatch): Adjust for ephemeral memories.
(run_kernel): Pass thread-count to create_kernel_dispatch.
(GOMP_OFFLOAD_init_device): Adjust for ephemeral memories.
(GOMP_OFFLOAD_fini_device): Adjust for ephemeral memories.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/pr47237.c: Xfail on amdgcn.
* gcc.dg/builtin-apply3.c: Xfail for amdgcn.
* gcc.dg/builtin-apply4.c: Xfail for amdgcn.
* gcc.dg/torture/stackalign/builtin-apply-3.c: Xfail for amdgcn.
* gcc.dg/torture/stackalign/builtin-apply-4.c: Xfail for amdgcn.
Mikael Morin [Sun, 29 Jan 2023 20:57:24 +0000 (21:57 +0100)]
fortran: Set name for *LOC default BACK argument [PR108450]
This change fixes an ICE caused by the double resolution of MINLOC,
MAXLOC and FINDLOC expressions which get a default value for the BACK
argument at resolution time. That argument is added without name,
and argument reordering code is not prepared to handle unnamed arguments
coming after named ones, so the second resolution causes a NULL pointer
dereference.
The problem is fixed by explicitly setting the argument name.
PR fortran/108450
gcc/fortran/ChangeLog:
* check.cc (gfc_check_minloc_maxloc): Explicitly set argument name.
(gfc_check_findloc): Ditto.
Harald Anlauf [Wed, 1 Feb 2023 20:01:32 +0000 (21:01 +0100)]
Fortran: error recovery on invalid array section [PR108609]
The testcase for PR108527 uncovered a latent issue with invalid array
sections that resulted in different paths being taken on different
architectures. Detect the invalid array declaration for a clean recovery.
gcc/fortran/ChangeLog:
PR fortran/108609
* expr.cc (find_array_section): Add check to prevent interpreting an
mpz non-integer constant as an integer.
gcc/testsuite/ChangeLog:
PR fortran/108609
* gfortran.dg/pr108527.f90: Adjust test pattern.
Harald Anlauf [Tue, 24 Jan 2023 21:36:25 +0000 (22:36 +0100)]
Fortran: fix ICE in compare_bound_int [PR108527]
gcc/fortran/ChangeLog:
PR fortran/108527
* resolve.cc (compare_bound_int): Expression to compare must be of
type INTEGER.
(compare_bound_mpz_t): Likewise.
(check_dimension): Fix comment on checks applied to array section
and clean up associated logic.
gcc/testsuite/ChangeLog:
PR fortran/108527
* gfortran.dg/pr108527.f90: New test.
Patrick Palka [Fri, 3 Feb 2023 14:41:10 +0000 (09:41 -0500)]
c++: unexpected ADDR_EXPR after overload set pruning [PR107461]
Here the ahead-of-time overload set pruning in finish_call_expr is
unintentionally returning a CALL_EXPR whose (pruned) callee is wrapped
in an ADDR_EXPR, despite the original callee not being wrapped in an
ADDR_EXPR. This ends up causing a bogus declaration mismatch error in
the below testcase because the call to min in #1 gets expressed as a
CALL_EXPR of ADDR_EXPR of FUNCTION_DECL, whereas the level-lowered call
to min in #2 gets expressed instead as a CALL_EXPR of FUNCTION_DECL.
This patch fixes this by stripping the spurious ADDR_EXPR appropriately.
Thus the first call to min now also gets expressed as a CALL_EXPR of
FUNCTION_DECL, matching the behavior before r12-6075-g2decd2cabe5a4f.
PR c++/107461
gcc/cp/ChangeLog:
* semantics.cc (finish_call_expr): Strip ADDR_EXPR from
the selected callee during overload set pruning.
* gcc.target/gcn/cond_shift_3.c: New test.
* gcc.target/gcn/cond_shift_3_run.c: New test.
* gcc.target/gcn/cond_shift_4.c: New test.
* gcc.target/gcn/cond_shift_4_run.c: New test.
* gcc.target/gcn/cond_shift_8.c: New test.
* gcc.target/gcn/cond_shift_8_run.c: New test.
* gcc.target/gcn/cond_shift_9.c: New test.
* gcc.target/gcn/cond_shift_9_run.c: New test.
Jonathan Wakely [Tue, 31 Jan 2023 22:28:16 +0000 (22:28 +0000)]
libstdc++: Fix std::random_device for avr
This fixes a build failure that affects avr, but could affect other
targets in theory. The _M_fini function should not try to use ::open or
::fopen if _GLIBCXX_USE_DEV_RANDOM is not defined, because no file can
ever have been opened.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (random_device::_M_fini): Do not try to
close the file handle if the target doesn't support the
/dev/random and /dev/urandom files.
Jonathan Wakely [Tue, 31 Jan 2023 22:16:31 +0000 (22:16 +0000)]
libstdc++: Fix build failures for avr
The abr-libc <errno.h> does not define EOVERFLOW, which means that
std::errc::value_too_large is not defined, and so <charconv> cannot be
compiled. Define value_too_large for avr with a value that does not
clash with any that is defined in <errno.h>. This is a kluge to fix
bootstrap for avr; it can be removed after PR libstdc++/104883 is
resolved.
The avr-libc <errno.h> fails to meet the C and POSIX requirements that
each error macro has a distinct integral value, and is usable in #if
directives. Add a special case for avr to system_error.cc so that only
the valid errors are recognized. Also disable the errno checks in
std::filesystem::remove_all that assume a meaningful value for errno.
On avr-libc <unistd.h> exists but does not define the POSIX functions
needed by std::filesystem, so _GLIBCXX_HAVE_UNISTD_H is not sufficient
to check for basic POSIX APIs. Check !defined __AVR__ as well as
_GLIBCXX_HAVE_UNISTD_H before using those functions. This is a kluge and
we should really have a specific macro that says the required functions
are available.
libstdc++-v3/ChangeLog:
* config/os/generic/error_constants.h (errc::value_too_large)
[__AVR__]: Define.
* src/c++11/system_error.cc
(system_category::default_error_condition) [__AVR__]: Only match
recognize values equal to EDOM, ERANGE, ENOSYS and EINTR.
* src/c++17/fs_ops.cc (fs::current_path) [__AVR__]: Do not check
for ENOENT etc. in switch.
(fs::remove_all) [__AVR__]: Likewise.
* src/filesystem/ops-common.h [__AVR__]: Do not use POSIX open,
close etc.
Patrick Palka [Sun, 6 Nov 2022 16:30:47 +0000 (11:30 -0500)]
libstdc++: Declare const global variables inline
The changes inside the regex_constants and execution namespaces seem to
be (the only) unimplemented parts of P0607R0 "Inline Variable for the
Standard Library"; the rest of the changes are to implementation details.
Jakub Jelinek [Thu, 2 Feb 2023 09:06:22 +0000 (10:06 +0100)]
nested, openmp: Wrap OMP_CLAUSE_*_GIMPLE_SEQ into GIMPLE_BIND for declare_vars [PR108435]
When gimplifying OMP_CLAUSE_{LASTPRIVATE,LINEAR}_STMT, we wrap it always
into a GIMPLE_BIND, but when putting statements directly into
OMP_CLAUSE_{LASTPRIVATE,LINEAR}_GIMPLE_SEQ, we do it only if needed (there
are any temporaries that need to be declared in the sequence).
convert_nonlocal_omp_clauses was relying on the GIMPLE_BIND to be there always
because it called declare_vars on it.
The following patch wraps it into GIMPLE_BIND in tree-nested if we need to
declare_vars on it on demand.
2023-02-02 Jakub Jelinek <jakub@redhat.com>
PR middle-end/108435
* tree-nested.cc (convert_nonlocal_omp_clauses)
<case OMP_CLAUSE_LASTPRIVATE>: If info->new_local_var_chain and *seq
is not a GIMPLE_BIND, wrap the sequence into a new GIMPLE_BIND
before calling declare_vars.
(convert_nonlocal_omp_clauses) <case OMP_CLAUSE_LINEAR>: Merge
with the OMP_CLAUSE_LASTPRIVATE handling except for whether
seq is initialized to &OMP_CLAUSE_LASTPRIVATE_GIMPLE_SEQ (clause)
or &OMP_CLAUSE_LINEAR_GIMPLE_SEQ (clause).
Martin Jambor [Wed, 1 Feb 2023 17:58:09 +0000 (18:58 +0100)]
ipa: Release body more carefully when removing nodes (PR 107944)
The code removing function bodies when the last call graph clone of a
node is removed is too aggressive when there are nodes up the
clone_of chain which still need them. Fixed by expanding the check.
gcc/ChangeLog:
2023-01-18 Martin Jambor <mjambor@suse.cz>
PR ipa/107944
* cgraph.cc (cgraph_node::remove): Check whether nodes up the
lcone_of chain also do not need the body.
Marek Polacek [Tue, 31 Jan 2023 19:36:30 +0000 (14:36 -0500)]
c++: ICE with -Wlogical-op [PR107755]
Here we crash in the middle end because warn_logical_operator calls
build_range_check which calls various fold_* functions and those
don't work too well when we're still processing template trees. For
instance here we crash because we're converting a RECORD_TYPE to bool.
At this point VIEW_CONVERT_EXPR<struct Foo>(b) hasn't yet been converted
to Foo::operator bool (&b).
I was excited to fix this with instantiation_dependent_expression_p
which can now be called from c-family/ as well, but the problem isn't
that the expression is dependent. So, p_t_d it is.
PR c++/107755
gcc/cp/ChangeLog:
* call.cc (build_new_op): Don't call warn_logical_operator when
processing a template.
Jakub Jelinek [Wed, 1 Feb 2023 10:24:11 +0000 (11:24 +0100)]
c++, openmp: Handle some OMP_*/OACC_* constructs during constant expression evaluation [PR108607]
While potential_constant_expression_1 handled most of OMP_* codes (by saying that
they aren't potential constant expressions), OMP_SCOPE was missing in that list.
I've also added OMP_SCAN, though that is less important (similarly to OMP_SECTION
it ought to appear solely inside of OMP_{FOR,SIMD} resp. OMP_SECTIONS).
As the testcase shows, it isn't enough, potential_constant_expression_1
can catch only some cases, as soon as one uses switch or ifs where at least
one of the possible paths could be constant expression, we can run into the
same codes during cxx_eval_constant_expression, so this patch handles those
there as well.
2023-02-01 Jakub Jelinek <jakub@redhat.com>
PR c++/108607
* constexpr.cc (cxx_eval_constant_expression): Handle OMP_*
and OACC_* constructs as non-constant.
(potential_constant_expression_1): Handle OMP_SCAN and OMP_SCOPE.
Marek Polacek [Tue, 31 Jan 2023 16:54:03 +0000 (11:54 -0500)]
c++: fix ICE with -Wduplicated-cond [PR107593]
Here we crash because a CAST_EXPR, representing T(), doesn't have
its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't
expect that. (o_e_p is called from warn_duplicated_cond_add_or_warn.)
In the past we've adjusted o_e_p to better cope with template codes,
but in this case I think we just want to avoid attempting to warn
about inst-dependent expressions; I don't think I've ever envisioned
-Wduplicated-cond to warn about them. Also destroy the chain when
an inst-dependent expression is encountered to not warn in
Wduplicated-cond4.C.
The ICE started with r12-6022, two-stage name lookup for overloaded
operators, which gave dependent operators a TREE_TYPE (in particular,
DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p:
/* Similar, if either does not have a type (like a template id),
they aren't equal. */
if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1))
return false;
PR c++/107593
PR c++/108597
gcc/c-family/ChangeLog:
* c-common.h (instantiation_dependent_expression_p): Declare.
* c-warn.cc (warn_duplicated_cond_add_or_warn): If the condition
is dependent, invalidate the chain.
Andrew MacLeod [Mon, 30 Jan 2023 19:59:30 +0000 (14:59 -0500)]
Correctly detect shifts out of range
get_shift_range was incorrectly communicating that it couldn't calculate
a range when the shift values was always out fo range. Fix this and
alwasy return [0, 0] when the shift value is always out of range.
PR tree-optimization/108306
gcc/
* range-op.cc (operator_lshift::fold_range): Return [0, 0] not
varying for shifts that are always out of void range.
(operator_rshift::fold_range): Return [0, 0] not
varying for shifts that are always out of void range.
Jan Hubicka [Mon, 16 Jan 2023 14:40:45 +0000 (15:40 +0100)]
Disable gather/scatter for zen4
this patch adds more tunes for zen4:
- new tunes for avx512 scater instructions.
In micro benchmarks these seems consistent loss compared to open-coded coe
- disable use of gather for zen4
While these are win for a micro benchmarks (based on TSVC), enabling gather
is a loss for parest. So for now it seems safe to keep it off.
- disable pass to avoid FMA chains for znver4 since fmadd was optimized and does not seem
to cause regressions.
* config/i386/i386.cc (ix86_vectorize_builtin_scatter): Guard scatter
by TARGET_USE_SCATTER.
* config/i386/i386.h (TARGET_USE_SCATTER_2PARTS,
TARGET_USE_SCATTER_4PARTS, TARGET_USE_SCATTER): New macros.
* config/i386/x86-tune.def (TARGET_USE_SCATTER_2PARTS,
TARGET_USE_SCATTER_4PARTS, TARGET_USE_SCATTER): New tunes.
(X86_TUNE_AVOID_256FMA_CHAINS, X86_TUNE_AVOID_512FMA_CHAINS): Disable
for znver4. (X86_TUNE_USE_GATHER): Disable for zen4.
Jan Hubicka [Thu, 22 Dec 2022 09:55:46 +0000 (10:55 +0100)]
Zen4 tuning part 2
Adds tunes needed for zen4 microarchitecture. I added two new knobs.
TARGET_AVX512_SPLIT_REGS which is used to specify that internally 512 vectors
are split to 256 vectors. This affects vectorization costs and reassociation
width. It probably should also affect RTX costs however I doubt it is very useful
since RTL optimizers are usually not judging between 256 and 512 vectors.
I also added X86_TUNE_AVOID_256FMA_CHAINS. Since fma has improved in zen4 this
flag may not be a win except for very specific benchmarks. I am still doing some
more detailed testing here.
Oherwise I disabled gathers on zen4 for 2 parts nad 4 parts. We can open code them
and since the latencies has only increased since zen3 opencoding is better than
actual instrucction. This shows at 4 tsvc benchmarks.
I ended up setting AVX256_OPTIMAL. This is a compromise. There are some tsvc
benchmarks that increase noticeably (up to 250%) however there are also few
regressions. Most of these can be solved by incrasing vec_perm cost in the
vectorizer. However this does not cure about 14% regression on x264 that is
quite important. Here we produce vectorized loops for avx512 that probably
would be faster if the loops in question had high enough iteration count.
We hit this problem with avx256 too: since the loop iterates few times, only
prologues/epilogues are used. Adding another round of prologue/epilogue
code does not make it better.
Finally I enabled avx stores for constnat sized memcpy and memset. I am not
sure why this is an opt-in feature. I think for most hardware this is a win.
gcc/ChangeLog:
2022-12-22 Jan Hubicka <hubicka@ucw.cz>
* config/i386/i386-expand.cc (ix86_expand_set_or_cpymem): Add
TARGET_AVX512_SPLIT_REGS
* config/i386/i386-options.cc (ix86_option_override_internal):
Honor x86_TONE_AVOID_256FMA_CHAINS.
* config/i386/i386.cc (ix86_vec_cost): Honor TARGET_AVX512_SPLIT_REGS.
(ix86_reassociation_width): Likewise.
* config/i386/i386.h (TARGET_AVX512_SPLIT_REGS): New tune.
* config/i386/x86-tune.def (X86_TUNE_USE_GATHER_2PARTS): Disable
for znver4.
(X86_TUNE_USE_GATHER_4PARTS): Likewise.
(X86_TUNE_AVOID_256FMA_CHAINS): Set for znver4.
(X86_TUNE_AVOID_512FMA_CHAINS): New utne; set for znver4.
(X86_TUNE_AVX256_OPTIMAL): Add znver4.
(X86_TUNE_AVX512_SPLIT_REGS): New tune.
(X86_TUNE_AVX256_MOVE_BY_PIECES): Add znver1-3.
(X86_TUNE_AVX256_STORE_BY_PIECES): Add znver1-3.
(X86_TUNE_AVX512_MOVE_BY_PIECES): Add znver4.
(X86_TUNE_AVX512_STORE_BY_PIECES): Add znver4.
Jan Hubicka [Thu, 22 Dec 2022 01:16:24 +0000 (02:16 +0100)]
Update znver4 costs
Update cost of znver4 mostly based on data measued by Agner Fog.
Compared to previous generations x87 became bit slower which is probably not
big deal (and we have minimal benchmarking coverage for it). One interesting
improvement is reducation of FMA cost. I also updated costs of AVX256
loads/stores based on latencies (not throughput which is twice of avx256).
Overall AVX512 vectorization seems to improve noticeably some of TSVC
benchmarks but since internally 512 vectors are split to 256 vectors it is
somewhat risky and does not win in SPEC scores (mostly by regressing benchmarks
with loop that have small trip count like x264 and exchange), so for now I am
going to set AVX256_OPTIMAL tune but I am still playing with it. We improved
since ZNVER1 on choosing vectorization size and also have vectorized
prologues/epilogues so it may be possible to make avx512 small win overall.
2022-12-22 Jan Hubicka <hubicka@ucw.cz>
* config/i386/x86-tune-costs.h (znver4_cost): Upate costs of FP and SSE
moves, division multiplication, gathers, L2 cache size, and more
complex FP instrutions.
Harald Anlauf [Mon, 23 Jan 2023 20:19:03 +0000 (21:19 +0100)]
Fortran: avoid ICE on invalid array subscript triplets [PR108501]
gcc/fortran/ChangeLog:
PR fortran/108501
* interface.cc (get_expr_storage_size): Check array subscript triplets
that we actually have integer values before trying to extract with
mpz_get_si.
gcc/testsuite/ChangeLog:
PR fortran/108501
* gfortran.dg/pr108501.f90: New test.
This patch surrounds the scalar operand of the MVE vcmp patterns with a
vec_duplicate to ensure both operands of the comparision operator have the same
(vector) mode.
Marek Polacek [Wed, 25 Jan 2023 22:19:54 +0000 (17:19 -0500)]
opts: SANITIZE_ADDRESS wrongly cleared [PR108543]
Here we crash on a null fndecl ultimately because we haven't defined
the built-ins described in sanitizer.def. So
builtin_decl_explicit (BUILT_IN_ASAN_POINTER_SUBTRACT);
returns NULL_TREE, causing an ICE later.
DEF_SANITIZER_BUILTIN only actually defines the built-ins when flag_sanitize
has SANITIZE_ADDRESS, or some of the other SANITIZE_*, but it doesn't check
SANITIZE_KERNEL_ADDRESS or SANITIZE_USER_ADDRESS. Unfortunately, with
-fsanitize=address -fno-sanitize=kernel-address
or
-fsanitize=kernel-address -fno-sanitize=address
SANITIZE_ADDRESS ends up being unset from flag_sanitize even though
_USER/_KERNEL are set. That's because -fsanitize=address means
SANITIZE_ADDRESS | SANITIZE_USER_ADDRESS and -fsanitize=kernel-address
is SANITIZE_ADDRESS | SANITIZE_KERNEL_ADDRESS but parse_sanitizer_options
does
flags &= ~sanitizer_opts[i].flag;
so the subsequent -fno- unsets SANITIZE_ADDRESS. Then no sanitizer
built-ins are actually defined.
I'm not sure why SANITIZE_ADDRESS isn't just SANITIZE_USER_ADDRESS |
SANITIZE_KERNEL_ADDRESS, I don't think we need 3 bits.
PR middle-end/108543
gcc/ChangeLog:
* opts.cc (parse_sanitizer_options): Don't always clear SANITIZE_ADDRESS
if it was previously set.
gcc/testsuite/ChangeLog:
* c-c++-common/asan/pointer-subtract-5.c: New test.
* c-c++-common/asan/pointer-subtract-6.c: New test.
* c-c++-common/asan/pointer-subtract-7.c: New test.
* c-c++-common/asan/pointer-subtract-8.c: New test.
Dimitar Dimitrov [Sat, 21 Jan 2023 16:10:59 +0000 (18:10 +0200)]
pru: Fix CLZ expansion for QI and HI modes
The recent gcc.dg/tree-ssa/clz-char.c test case failed for PRU target,
exposing a wrong code generation bug in the PRU backend. The "clz"
pattern did not produce correct output for QI and HI input operand
modes. SI mode is ok.
The "clz" pattern is expanded to an LMBD instruction to get the
left-most bit position having value "1". In turn, to get the correct
"clz" value, that bit position must be subtracted from the MSB bit
position of the input operand. The old behaviour of hard-coding 31
for MSB bit position is wrong.
The LMBD instruction returns 32 if input operand is zero, irrespective
of its register mode. This maps nicely for SI mode, where the "clz"
pattern outputs -1. It also leads to peculiar (but valid!) output
values from the "clz" pattern for QI and HI zero-valued inputs.
The corresponding commit in trunk contains two new test cases, which
have been removed here because they depend on r13-5195-g4798080d4a3530.
Regtested for pru-unknown-elf.
gcc/ChangeLog:
* config/pru/pru.h (CLZ_DEFINED_VALUE_AT_ZERO): Fix value for QI
and HI input modes.
* config/pru/pru.md (clz): Fix generated code for QI and HI
input modes.
Tobias Burnus [Thu, 26 Jan 2023 10:13:52 +0000 (11:13 +0100)]
install.texi: Bump newlib version for nvptx + gcn
Before, newlib 3.2 was required for amdgcn and 3.1 for nvptx.
Now recommended is 4.3.0 which was just released on 2023-01-20.
While currently the old versions would work fine, upcoming GCC
changes depend on a newer newlib. Thus, the minimal version is
bumped instead of just recommending the new version.
For GCN, the bump is in preparation for permitting non-threadlocal
stack variables and vectorized math functions - both scheduled for
GCC 13 and added to newlib in 4.3.0.
For nvptx, this includes an emulated clock (commit 6bb96d13a),
a calloc fix (5fca4e0f1) and changes to permit libgfortran to be
compiled with I/O support instead of only in minimal mode.
(Patch approved for GCC 13 but pending on a nvtpx patch,
which for which review is pending.)
Christophe Lyon [Tue, 14 Jun 2022 21:08:33 +0000 (21:08 +0000)]
aarch64: fix warning emission for ABI break since GCC 9.1
While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be. This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.
We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1. This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.
The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers. This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information). However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.
The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.
We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.
2022-11-28 Christophe Lyon <christophe.lyon@arm.com>
Richard Sandiford <richard.sandiford@arm.com>
* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.
Richard Biener [Mon, 19 Dec 2022 13:55:45 +0000 (14:55 +0100)]
tree-optimization/108164 - undefined overflow with IV vectorization
vect_update_ivs_after_vectorizer can end up emitting a signed
IV update when the loop body performed an unsigned computation.
The following makes sure to perform that update in the type
of the loop update type to avoid undefined behavior on overflow.
PR tree-optimization/108164
* tree-vect-loop-manip.cc (vect_update_ivs_after_vectorizer):
Perform vect_step_op_add update in the appropriate type.
Richard Biener [Mon, 12 Dec 2022 16:52:46 +0000 (17:52 +0100)]
tree-optimization/108076 - if-conversion and forced labels
When doing if-conversion we simply throw away labels without checking
whether they are possibly targets of non-local gotos or have their
address taken. The following rectifies this and refuses to if-convert
such loops.
PR tree-optimization/108076
* tree-if-conv.cc (if_convertible_loop_p_1): Reject blocks
with non-local or forced labels that we later remove
labels from.
`xputenv()` (and `putenv()`) don't copy strings and only store the
pointer in the `environ` global table. As a result `environ` got
corrupted as soon as `jinfo.skipped_makeflags` store got deallocated.
This started causing bootstrap crashes in `execv()` calls:
xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address
The change restores memory allocation for `xputenv()` argument.
Andreas Krebbel [Mon, 23 Jan 2023 07:56:05 +0000 (08:56 +0100)]
PR 106101: IBM zSystems: Fix strict_low_part problem
This avoids generating illegal (strict_low_part (reg ...)) RTXs. This
required two changes:
1. Do not use gen_lowpart to generate the inner expression of a
STRICT_LOW_PART. gen_lowpart might fold the SUBREG either because
there is already a paradoxical subreg or because it can directly be
applied to the register. A new wrapper function makes sure that we
always end up having an actual SUBREG.
2. Change the movstrict patterns to enforce a SUBREG as inner operand
of the STRICT_LOW_PARTs. The new predicate introduced for the
destination operand requires a SUBREG expression with a
register_operand as inner operand. However, since reload strips away
the majority of the SUBREGs we have to accept single registers as well
once we reach reload.
Bootstrapped and regression tested on IBM zSystems 64 bit.
gcc/ChangeLog:
PR target/106101
* config/s390/predicates.md (subreg_register_operand): New
predicate.
* config/s390/s390-protos.h (s390_gen_lowpart_subreg): New
function prototype.
* config/s390/s390.cc (s390_gen_lowpart_subreg): New function.
(s390_expand_insv): Use s390_gen_lowpart_subreg instead of
gen_lowpart.
* config/s390/s390.md ("*get_tp_64", "*zero_extendhisi2_31")
("*zero_extendqisi2_31", "*zero_extendqihi2_31"): Likewise.
("movstrictqi", "movstricthi", "movstrictsi"): Use the
subreg_register_operand predicate instead of register_operand.
gcc/testsuite/ChangeLog:
PR target/106101
* gcc.c-torture/compile/pr106101.c: New test.
Thomas Schwinge [Wed, 21 Sep 2022 16:58:34 +0000 (18:58 +0200)]
nvptx, libgcc: Stub unwinding implementation
Adding stub '_Unwind_Backtrace', '_Unwind_GetIPInfo' functions is necessary
for linking libbacktrace, as a normal (non-'LIBGFOR_MINIMAL') configuration
of libgfortran wants to do, for example.
The file 'libgcc/config/nvptx/unwind-nvptx.c' is copied from
'libgcc/config/gcn/unwind-gcn.c'.
libgcc/ChangeLog:
* config/nvptx/t-nvptx: Add unwind-nvptx.c.
* config/nvptx/unwind-nvptx.c: New file.
Co-authored-by: Andrew Stubbs <ams@codesourcery.com>
Thomas Schwinge [Sun, 13 Nov 2022 13:19:30 +0000 (14:19 +0100)]
nvptx: Support global constructors/destructors via 'collect2'
The function attributes 'constructor', 'destructor', and 'init_priority' now
work, as do the C++ features making use of this. Test cases with effective
target 'global_constructor' and 'init_priority' now generally work, and
'check-gcc-c++' test results greatly improve; no more "sorry, unimplemented:
global constructors not supported on this target".
This depends on <https://github.com/MentorEmbedded/nvptx-tools/pull/40> "'nm'"
generally, and for global destructors support: newlib
<https://inbox.sourceware.org/newlib/878rjqaku5.fsf@dem-tschwing-1.ger.mentorg.com/>
"nvptx: Implement '_exit' instead of 'exit'".
gcc/
* collect2.cc (write_c_file_glob): Allow for
'COLLECT2_MAIN_REFERENCE' override.
* config.gcc <case ${target} in nvptx-*>: Set 'use_collect2=yes'.
* config/nvptx/nvptx.h: Adjust.
gcc/testsuite/
* gcc.dg/no_profile_instrument_function-attr-1.c: GCC/nvptx is
'NO_DOT_IN_LABEL' but not 'NO_DOLLAR_IN_LABEL', so '$' may apper
in identifiers.
* lib/target-supports.exp
(check_effective_target_global_constructor): Enable for nvptx.
libgcc/
* config.host <case ${host} in nvptx-*>: Add 'crtbegin.o',
'crtend.o' to 'extra_parts'.
* config/nvptx/crt0.c: Invoke '__do_global_ctors',
'__do_global_dtors'.
* config/nvptx/crtstuff.c: New.
* config/nvptx/t-nvptx: Adjust.
Thomas Schwinge [Mon, 19 Dec 2022 16:19:19 +0000 (17:19 +0100)]
nvptx: Prevent emitting duplicate declarations for '__nvptx_stacks', '__nvptx_uni'
As I have reported to Nvidia in 2022-12-01 'NVIDIA Incident Report (3891704):
ptxas: Duplicate declaration error: "cannot be resolved by a '.static'"',
'ptxas' has an inscrutable error mode for duplicate declarations:
ptxas softstack-decl-1.o, line 11; error : '.extern' variable '__nvptx_stacks' cannot be resolved by a '.static'
ptxas fatal : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
ptxas uniform-simt-decl-1.o, line 12; error : '.extern' variable '__nvptx_uni' cannot be resolved by a '.static'
ptxas fatal : Ptx assembly aborted due to errors
nvptx-as: ptxas returned 255 exit status
This is inscrutable, because (a) what is "cannot be resolved by a '.static'"
supposed to tell me (there is no '.static' in PTX?), and (b) why arent't
repeated declaration just verified to match the first, but otherwise a no-op
(like in other programming languages)?
... to document the status quo re implicit (via 'need_softstack_decl',
'need_unisimt_decl') and explicit declarations of '__nvptx_stacks',
'__nvptx_uni'.
Thomas Schwinge [Mon, 12 Dec 2022 21:05:37 +0000 (22:05 +0100)]
nvptx: Make 'nvptx_uniform_warp_check' fit for non-full-warp execution
For example, this allows for '-muniform-simt' code to be executed
single-threaded, which currently fails (device-side 'trap'), as the 0xffffffff
mask isn't correct if not all 32 threads of a warp are active. The same
issue/fix, I suppose but have not verified, would apply if we were to allow for
OpenACC 'vector_length' smaller than 32, for example for OpenACC 'serial'.
We use 'nvptx_uniform_warp_check' only for PTX ISA version less than 6.0.
Otherwise we're using 'nvptx_warpsync', which emits 'bar.warp.sync 0xffffffff',
which evidently appears to do the right thing. (I've tested '-muniform-simt'
code executing single-threaded.)
gcc/
* config/nvptx/nvptx.md (nvptx_uniform_warp_check): Make fit for
non-full-warp execution.
gcc/testsuite/
* gcc.target/nvptx/nvptx.exp
(check_effective_target_default_ptx_isa_version_at_least_6_0):
New.
* gcc.target/nvptx/uniform-simt-5.c: New.
libgomp/
* plugin/plugin-nvptx.c (nvptx_exec): Assert what we know about
'blockDimX'.
Thomas Schwinge [Fri, 20 Jan 2023 16:17:21 +0000 (17:17 +0100)]
Fix 'libgomp.c/simd-math-1.c' configuration, again
Tobias pointed out that as of my recent
og12 commit e7d4bcb974915bfe95be6c385641fc66a4201581
"Fix 'libgomp.c/simd-math-1.c' configuration",
in GCC configurations without GCN offloading configured, we'd get:
xgcc: error: GCC is not configured to support 'amdgcn-amdhsa' as '-foffload=' argument
("Interestingly", GCC doesn't complain for '-foffload-options=-lm' if there are
no offload targets configured...)
Thus, restrict that ooption to GCN offloading compilation, and on the other
hand, there's no reason to skip this test for non-GCN offloading execution:
even if not SIMD-vectorized there, we still benefit from correctness testing.
Jakub Jelinek [Thu, 19 Jan 2023 20:22:22 +0000 (21:22 +0100)]
openmp: Fix up OpenMP expansion of non-rectangular loops [PR108459]
expand_omp_for_init_counts was using for the case where collapse(2)
inner loop has init expression dependent on non-constant multiple of
the outer iterator and the condition upper bound expression doesn't
depend on the outer iterator fold_unary (NEGATE_EXPR, ...). This
will just return NULL if it can't be folded, we need fold_build1
instead.
2023-01-19 Jakub Jelinek <jakub@redhat.com>
PR middle-end/108459
* omp-expand.cc (expand_omp_for_init_counts): Use fold_build1 rather
than fold_unary for NEGATE_EXPR.
Jonathan Wakely [Thu, 22 Dec 2022 09:56:47 +0000 (09:56 +0000)]
libstdc++: Avoid recursion in __nothrow_wait_cv::wait [PR105730]
The commit r12-5877-g9e18a25331fa25 removed the incorrect
noexcept-specifier from std::condition_variable::wait and gave the new
symbol version @@GLIBCXX_3.4.30. It also redefined the original symbol
std::condition_variable::wait(unique_lock<mutex>&)@GLIBCXX_3.4.11 as an
alias for a new symbol, __gnu_cxx::__nothrow_wait_cv::wait, which still
has the incorrect noexcept guarantee. That __nothrow_wait_cv::wait is
just a wrapper around the real condition_variable::wait which adds
noexcept and so terminates on a __forced_unwind exception.
This doesn't work on uclibc, possibly due to a dynamic linker bug. When
__nothrow_wait_cv::wait calls the condition_variable::wait function it
binds to the alias symbol, which means it just calls itself recursively
until the stack overflows.
This change avoids the possibility of a recursive call by changing the
__nothrow_wait_cv::wait function so that instead of calling
condition_variable::wait it re-implements it. This requires accessing
the private _M_cond member of condition_variable, so we need to use the
trick of instantiating a template with the member-pointer of the private
member.
libstdc++-v3/ChangeLog:
PR libstdc++/105730
* src/c++11/compatibility-condvar.cc (__nothrow_wait_cv::wait):
Access private data member of base class and call its wait
member.
Jonathan Wakely [Thu, 28 Jul 2022 15:15:58 +0000 (16:15 +0100)]
libstdc++: Unblock atomic wait on non-futex platforms [PR106183]
When using a mutex and condition variable, the notifying thread needs to
increment _M_ver while holding the mutex lock, and the waiting thread
needs to re-check after locking the mutex. This avoids a missed
notification as described in the PR.
By moving the increment of _M_ver to the base _M_notify we can make the
use of the mutex local to the use of the condition variable, and
simplify the code a little. We can use a relaxed store because the mutex
already provides sequential consistency. Also we don't need to check
whether __addr == &_M_ver because we know that's always true for
platforms that use a condition variable, and so we also know that we
always need to use notify_all() not notify_one().
Reviewed-by: Thomas Rodgers <trodgers@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/106183
* include/bits/atomic_wait.h (__waiter_pool_base::_M_notify):
Move increment of _M_ver here.
[!_GLIBCXX_HAVE_PLATFORM_WAIT]: Lock mutex around increment.
Use relaxed memory order and always notify all waiters.
(__waiter_base::_M_do_wait) [!_GLIBCXX_HAVE_PLATFORM_WAIT]:
Check value again after locking mutex.
(__waiter_base::_M_notify): Remove increment of _M_ver.
projects / thirdparty / gcc.git / log
