The svzero_mask_za intrinsic tried to use the shortest combination
of .b, .h, .s and .d tiles, allowing mixtures of sizes where necessary.
However, Iain S pointed out that LLVM instead requires the tiles to
have the same suffix. GAS supports both versions, so this patch
generates the LLVM-friendly form.
gcc/
* config/aarch64/aarch64.cc (aarch64_output_sme_zero_za): Require
all tiles to have the same suffix.
gcc/testsuite/
* gcc.target/aarch64/sme/acle-asm/zero_mask_za.c (zero_mask_za_ab)
(zero_mask_za_d7, zero_mask_za_bf): Expect a list of .d tiles instead
of a mixture.
s390: testsuite: Xfail range-sincos.c and vrp-float-abs-1.c
As mentioned in PR114678 those failures will be fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648303.html
For GCC 14 just xfail them which should be reverted once the patch is
applied.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/range-sincos.c: Xfail for s390.
* gcc.dg/tree-ssa/vrp-float-abs-1.c: Dito.
Patrick Palka [Fri, 12 Apr 2024 12:59:27 +0000 (08:59 -0400)]
c++: templated substitution into lambda-expr [PR114393]
The below testcases use a lambda-expr as a template argument and they
all trip over the below added tsubst_lambda_expr sanity check ultimately
because current_template_parms is empty which causes push_template_decl
to return error_mark_node from the call to begin_lambda_type. Were it
not for the sanity check this silent error_mark_node result leads to
nonsensical errors down the line, or silent breakage.
In the first testcase, we hit this assert during instantiation of the
dependent alias template-id c1_t<_Data> from instantiate_template, which
clears current_template_parms via push_to_top_level. Similar story for
the second testcase. For the third testcase we hit the assert during
partial instantiation of the member template from instantiate_class_template
which similarly calls push_to_top_level.
These testcases illustrate that templated substitution into a lambda-expr
is not always possible, in particular when we lost the relevant template
context. I experimented with recovering the template context by making
tsubst_lambda_expr fall back to using scope_chain->prev->template_parms if
current_template_parms is empty which worked but seemed like a hack. I
also experimented with preserving the template context by keeping
current_template_parms set during instantiate_template for a dependent
specialization which also worked but it's at odds with the fact that we
cache dependent specializations (and so they should be independent of
the template context).
So instead of trying to make such substitution work, this patch uses the
extra-args mechanism to defer templated substitution into a lambda-expr
when we lost the relevant template context.
PR c++/114393
PR c++/107457
PR c++/93595
gcc/cp/ChangeLog:
* cp-tree.h (LAMBDA_EXPR_EXTRA_ARGS): Define.
(tree_lambda_expr::extra_args): New field.
* module.cc (trees_out::core_vals) <case LAMBDA_EXPR>: Stream
LAMBDA_EXPR_EXTRA_ARGS.
(trees_in::core_vals) <case LAMBDA_EXPR>: Likewise.
* pt.cc (has_extra_args_mechanism_p): Return true for LAMBDA_EXPR.
(tree_extra_args): Handle LAMBDA_EXPR.
(tsubst_lambda_expr): Use LAMBDA_EXPR_EXTRA_ARGS to defer templated
substitution into a lambda-expr if we lost the template context.
Add sanity check for error_mark_node result from begin_lambda_type.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ2.C: New test.
* g++.dg/cpp2a/lambda-targ3.C: New test.
* g++.dg/cpp2a/lambda-targ4.C: New test.
Ian McInerney [Thu, 4 Apr 2024 15:16:32 +0000 (16:16 +0100)]
libgfortran: Fix compilation of gf_vsnprintf
The fallback function (gf_vsnprintf) to provide a vsnprintf function
if the system library doesn't have one would not compile due to the
variable name for the string's destination buffer not being updated
after the refactor in 2018 in edaaef601d0d6d263fba87b42d6d04c99dd23dba.
This updates the internal logic of gf_vsnprintf to now use the str
variable defined in the function signature.
libgfortran/ChangeLog:
2024-04-04 Ian McInerney <i.mcinerney17@imperial.ac.uk>
* runtime/error.c (gf_vsnprintf): Fix compilation
Signed-off-by: Ian McInerney <i.mcinerney17@imperial.ac.uk>
Pan Li [Fri, 12 Apr 2024 08:38:18 +0000 (16:38 +0800)]
RISC-V: Fix Werror=sign-compare in riscv_validate_vector_type
This patch would like to fix the Werror=sign-compare similar to below:
gcc/config/riscv/riscv.cc: In function ‘void
riscv_validate_vector_type(const_tree, const char*)’:
gcc/config/riscv/riscv.cc:5614:23: error: comparison of integer
expressions of different signedness: ‘int’ and ‘unsigned int’
[-Werror=sign-compare]
5614 | if (TARGET_MIN_VLEN < required_min_vlen)
The TARGET_MIN_VLEN is *int* by default but the required_min_vlen
returned from riscv_vector_required_min_vlen is **unsigned**. Thus,
adjust the related function and reference variable(s) to int type
to avoid such kind of Werror.
The below test suite is passed for this patch.
* The rv64gcv fully regression tests.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_vector_float_type_p): Take int
as the return value instead of unsigned.
(riscv_vector_element_bitsize): Ditto.
(riscv_vector_required_min_vlen): Ditto.
(riscv_validate_vector_type): Take int type for local variable(s).
analyzer: Bail out on function pointer for -Wanalyzer-allocation-size
On s390 pr94688.c is failing due to excess error
pr94688.c:6:5: warning: allocated buffer size is not a multiple of the pointee's size [CWE-131] [-Wanalyzer-allocation-size]
This is because on s390 functions are by default aligned to an 8-byte
boundary and during function type construction size is set to function
boundary. Thus, for the assignment
a.0_1 = (void (*<T237>) ()) &a;
we have that the right-hand side is pointing to a 4-byte memory region
whereas the size of the function pointer is 8 byte and a warning is
emitted.
Since -Wanalyzer-allocation-size is not about pointers to code, bail out
early.
gcc/analyzer/ChangeLog:
* region-model.cc (region_model::check_region_size): Bail out
early on function pointers.
Jakub Jelinek [Fri, 12 Apr 2024 09:00:43 +0000 (11:00 +0200)]
tree-cfg: Make the verifier returns_twice message translatable
While translation of the verifier messages is questionable, that case is
something that ideally should never happen except to gcc developers
and so pressumably English should be fine, we use error etc. APIs and
those imply translatations and some translators translate it.
The following patch adjusts the code such that we don't emit
appel returns_twice est not first dans le bloc de base 33
in French (i.e. 2 English word in the middle of a French message).
Similarly Swedish or Ukrainian.
Note, the German translator did differentiate between these verifier
messages vs. normal user facing and translated it to:
"Interner Fehler: returns_twice call is %s in basic block %d"
so just a German prefix before English message.
2024-04-12 Jakub Jelinek <jakub@redhat.com>
* tree-cfg.cc (gimple_verify_flow_info): Make the misplaced
returns_twice diagnostics translatable.
Jakub Jelinek [Fri, 12 Apr 2024 08:59:54 +0000 (10:59 +0200)]
Limit special asan/ubsan/bitint returns_twice handling to calls in bbs with abnormal pred [PR114687]
The tree-cfg.cc verifier only diagnoses returns_twice calls preceded
by non-label/debug stmts if it is in a bb with abnormal predecessor.
The following testcase shows that if a user lies in the attributes
(a function which never returns can't be pure, and can't return
twice when it doesn't ever return at all), when we figure it out,
we can remove the abnormal edges to the "returns_twice" call and perhaps
whole .ABNORMAL_DISPATCHER etc.
edge_before_returns_twice_call then ICEs because it can't find such
an edge.
The following patch limits the special handling to calls in bbs where
the verifier requires that.
2024-04-12 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/114687
* gimple-iterator.cc (gsi_safe_insert_before): Only use
edge_before_returns_twice_call if bb_has_abnormal_pred.
(gsi_safe_insert_seq_before): Likewise.
* gimple-lower-bitint.cc (bitint_large_huge::lower_call): Only
push to m_returns_twice_calls if bb_has_abnormal_pred.
contrib/check-params-in-docs.py is a script that checks that all options
reported with gcc --help=params are in gcc/doc/invoke.texi and vice
versa.
gcc/doc/invoke.texi lists target-specific params but gcc --help=params
doesn't. This meant that the script would mistakenly complain about
parms missing from --help=params. Previously, the script was just set
to ignore aarch64 and gcn params which solved this issue only for x86.
This patch sets the script to ignore all target-specific params.
contrib/ChangeLog:
* check-params-in-docs.py: Ignore target specific params.
Prevent loop unrolling of the innermost loop because otherwise we are
left with no loop interchange for targets like s390 which have a more
aggressive loop unrolling strategy.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/loop-interchange-16.c: Prevent loop unrolling
of the innermost loop.
Pan Li [Fri, 12 Apr 2024 03:12:24 +0000 (11:12 +0800)]
RISC-V: Bugfix ICE non-vector in TARGET_FUNCTION_VALUE_REGNO_P
This patch would like to fix one ICE when vector is not enabled
in hook TARGET_FUNCTION_VALUE_REGNO_P implementation. The vector
regno is available if and only if the TARGET_VECTOR is true. The
previous implement missed this condition and then result in ICE
when rv64gc build option without vector.
The below test suite is passed for this patch.
* The rv64gcv fully regression tests.
* The rv64gc fully regression tests.
PR target/114639
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_function_value_regno_p): Add
TARGET_VECTOR predicate for V_RETURN regno.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr114639-1.c: New test.
* gcc.target/riscv/pr114639-2.c: New test.
* gcc.target/riscv/pr114639-3.c: New test.
* gcc.target/riscv/pr114639-4.c: New test.
The type for member 'c' is correct, but the comment for the member
incorrectly reads "BTF_KIND_UNKN ''". This was caused by an
incorrect type lookup in btf_asm_type_ref that could happen if the
source file has types which can be represented in CTF but not in BTF.
This patch fixes the issue by changing btf_asm_type_ref to work fully
in the CTF ID space until writing out the final BTF ID. That ensures
types are correctly identified when writing the asm debug comments,
like the following fixed comment for the above case.
Note that there was no problem with the actual BTF information, the
only error was in the comment. This patch does not change the output
BTF information, and no tests were affected.
gcc/
* btfout.cc (btf_asm_type_ref): Convert IDs to BTF internally and
fix potentially looking up wrong type for asm debug comment info.
Split into...
(btf_asm_datasec_type_ref): ... This. New.
(btf_asm_datasec_entry): Call it here, instead of btf_asm_type_ref.
(btf_asm_type, btf_asm_array, btf_asm_varent, btf_asm_sou_member)
(btf_asm_func_arg, btf_asm_func_type): Adapt btf_asm_type_ref call.
David Faust [Thu, 11 Apr 2024 18:18:55 +0000 (11:18 -0700)]
btf: emit non-representable bitfield as void
This patch fixes an issue with mangled BTF that could occur when
a struct type contains a bitfield member which cannot be represented
in BTF. It is undefined what should happen in such cases, but we can
at least do something reasonable.
Commit
936dd627cd9 "btf: do not skip members of data type with type id
BTF_VOID_TYPEID"
made a similar change for un-representable non-bitfield members, but
had an unintended side-effect of mangling BTF for un-representable
bitfields: the struct (or union) would account for the offending
bitfield in its member count but the bitfield member itself was
not emitted, making the member count incorrect.
This change ensures that non-representable bitfield members of struct
and union types are always emitted with BTF_VOID_TYPEID. This avoids
corrupting the BTF information for the entire struct or union type.
gcc/
* btfout.cc (btf_asm_sou_member): Always emit non-representable
bitfield members as having 'void' type. Refactor slightly.
gcc/testsuite/
* gcc.dg/debug/btf/btf-bitfields-4.c: Add two new checks.
contrib/check-params-in-docs.py is a script that checks that all
options reported with ./gcc/xgcc -Bgcc --help=param are in
gcc/doc/invoke.texi and vice versa.
gcn-preferred-vectorization-factor is in the manual but normally not
reported by --help, probably because I do not have gcn offload
configured. This patch makes the script silently about this particular
fact.
Jakub Jelinek [Thu, 11 Apr 2024 14:37:26 +0000 (16:37 +0200)]
libstdc++: Regenerate trunk baseline_symbols.txt files for Linux
While the previous patch was regeneration from 13.2 release (with hand
edits for arches I don't have libraries for but which are still well
maintained), thius one is regeneration from the trunk (this time for
hand edits everywhere for the PR114692
https://gcc.gnu.org/pipermail/libstdc++/2024-April/058570.html
patch; plus again hand edits for arches I don't have libraries for).
Andrew Carlotti [Fri, 5 Apr 2024 16:12:46 +0000 (17:12 +0100)]
aarch64: Remove FMV features whose names may change
Some architecture features have been combined under a single command
line flag, but have been assigned multiple FMV feature names with the
command line flag name enabling only a subset of these features in
the FMV specification. I've proposed reallocating names in the FMV
specification to match the command line flags [1], but for GCC 14 we'll
just remove them from the FMV feature list.
Andrew Carlotti [Wed, 3 Apr 2024 22:53:52 +0000 (23:53 +0100)]
aarch64: Remove unsupported FMV features
It currently isn't possible to support function multiversioning features
properly in GCC without also enabling the extension in the command line
options (with the exception of features such as "rpres" that do not
require assembler support). We therefore remove unsupported features
from GCC's list of FMV features.
Some of these features ("fcma", "jscvt", "frintts", "flagm2", "wfxt",
"rcpc2", and perhaps "dpb" and "dpb2") will be added back in the future
once support for the command line option has been added.
The rest of the removed features I have proposed removing from the ACLE
specification as well, since it doesn't seem worthwhile to include support
for them; see the ACLE pull request for more detailed justification:
https://github.com/ARM-software/acle/pull/315
Andrew Carlotti [Wed, 3 Apr 2024 22:35:08 +0000 (23:35 +0100)]
aarch64: Fix FMV array iteration bounds
There was an assumption in some places that the aarch64_fmv_feature_data
array contained FEAT_MAX elements. While this assumption held up till
now, it is safer and more flexible to use the array size directly.
Also fix the lower bound in compare_feature_masks to use ">=0" instead
of ">0", and add a test using the features at index 0 and 1. However,
the test already passed, because the earlier popcount check makes it
impossible to reach the loop if the masks differ in exactly one
location.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (compare_feature_masks):
Use ARRAY_SIZE and >=0 for iteration bounds.
(aarch64_mangle_decl_assembler_name): Use ARRAY_SIZE.
Andrew Carlotti [Wed, 3 Apr 2024 22:32:12 +0000 (23:32 +0100)]
aarch64: Reorder FMV feature priorities
Some higher priority FMV features were dependent subsets of lower
priority features. Fix this, using the new priorities specified in
https://github.com/ARM-software/acle/pull/279.
Jonathan Wakely [Thu, 11 Apr 2024 11:28:25 +0000 (12:28 +0100)]
libstdc++: Export std::__basic_file::native_handle as GLIBCXX_3.4.33 [PR114692]
I added this new symbol in the wrong version. GLIBCXX_3.4.32 was
already used for the GCC 13.2.0 release, so the new symbol should have
been in a new GLIBCXX_3.4.33 version.
Additionally, the pattern doesn't need to use [cw] because we only ever
use __basic_file<char>, even for std::basic_filebuf<wchar_t>.
libstdc++-v3/ChangeLog:
PR libstdc++/114692
* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Move new exports for
__basic_file::native_handle to ...
(GLIBCXX_3.4.33): ... here. Adjust to not match wchar_t
specialization, which isn't used.
* testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.33 and update
latest version check.
Patrick Palka [Thu, 11 Apr 2024 14:16:41 +0000 (10:16 -0400)]
c++: build_extra_args recapturing local specs [PR114303]
r13-6452-g341e6cd8d603a3 made build_extra_args walk evaluated contexts
first so that we prefer processing a local specialization in an evaluated
context even if its first use is in an unevaluated context. But this
means we need to avoid walking a tree that already has extra args/specs
saved because the list of saved specs appears to be an evaluated
context which we'll now walk first. It seems then that we should be
calculating the saved specs from scratch each time, rather than
potentially walking the saved specs list from an earlier partial
instantiation when calling build_extra_args a second time around.
PR c++/114303
gcc/cp/ChangeLog:
* constraint.cc (tsubst_requires_expr): Clear
REQUIRES_EXPR_EXTRA_ARGS before calling build_extra_args.
* pt.cc (tree_extra_args): Define.
(extract_locals_r): Assert *_EXTRA_ARGS is empty.
(tsubst_stmt) <case IF_STMT>: Clear IF_SCOPE on the new
IF_STMT. Call build_extra_args on the new IF_STMT instead
of t which might already have IF_STMT_EXTRA_ARGS.
Jakub Jelinek [Thu, 11 Apr 2024 13:55:53 +0000 (15:55 +0200)]
libstdc++: Regenerate baseline_symbols.txt files for Linux
The following patch regenerates the ABI files for 13 branch (I've only changed
the Linux files which were updated in r13-7289, all but m68k, riscv64 and
powerpc64 are from actual Fedora 39 gcc builds, the rest hand edited).
We've added one symbol very early in the 13.2 cycle, but then added 2
further ones very soon afterwards, quite a long time before 13.2 release
and haven't regenerated. The patch applies cleanly to trunk as well.
Jakub Jelinek [Thu, 11 Apr 2024 09:12:11 +0000 (11:12 +0200)]
asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027]
On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote:
> > > So, try to add some other variable with larger size and smaller alignment
> > > to the frame (and make sure it isn't optimized away).
> > >
> > > alignb above is the alignment of the first partition's var, if
> > > align_frame_offset really needs to depend on the var alignment, it probably
> > > should be the maximum alignment of all the vars with alignment
> > > alignb * BITS_PER_UNIT <=3D MAX_SUPPORTED_STACK_ALIGNMENT
> > >
>
> In asan_emit_stack_protection, when it allocated fake stack, it assume
> bottom of stack is also aligned to alignb. And the place violated this
> is the first var partition. which is 32 bytes offsets, it should be
> BIGGEST_ALIGNMENT / BITS_PER_UNIT.
> So I think we need to use MAX (BIGGEST_ALIGNMENT /
> BITS_PER_UNIT, ASAN_RED_ZONE_SIZE) for the first var partition.
Your first patch aligned offsets[0] to maximum of alignb and
ASAN_RED_ZONE_SIZE. But as I wrote in the reply to that mail, alignb there
is the alignment of just a single variable which is the first one to appear
in the sorted list and is placed in the highest spot in the stack frame.
That is not necessarily the largest alignment, the sorting ensures that it
is a variable with the largest size in the frame (and only if several of
them have equal size, largest alignment from the same sized ones). Your
second patch used maximum of BIGGEST_ALIGNMENT / BITS_PER_UNIT and
ASAN_RED_ZONE_SIZE. That doesn't change anything at all when using
-mno-avx512f - offsets[0] is still just 32-byte aligned in that case
relative to top of frame, just changes the -mavx512f case to be 64-byte
aligned offsets[0] (aka offsets[0] is then either 0 or -64 instead of either
0 or -32). That will not help if any variable in the frame needs 128-byte,
256-byte, 512-byte ... 4096-byte alignment. If you want to fix the bug in
the spot you've touched, you'd need to walk all the
stack_vars[stack_vars_sorted[si2]] for si2 [si + 1, n - 1] and for those
where the loop would do anything (i.e.
stack_vars[i2].representative == i2
&& TREE_CODE (decl2) == SSA_NAME
? SA.partition_to_pseudo[var_to_partition (SA.map, decl2)] == NULL_RTX
: DECL_RTL (decl2) == pc_rtx
and the pred applies (but that means also walking the earlier ones!
because with -fstack-protector* the vars can be processed in several calls) and
alignb2 * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT
and compute maximum of those alignments.
That maximum is already computed,
data->asan_alignb = MAX (data->asan_alignb, alignb);
computes that, but you get the final result only after you do all the
expand_stack_vars calls. You'd need to compute it before.
Though, that change would be still in the wrong place.
The thing is, it would be a waste of the precious stack space when it isn't
needed at all (e.g. when asan will not at compile time do the use after
return checking, or if it won't do it at runtime, or even if it will do at
runtime it will waste the space on the stack).
The following patch fixes it solely for the __asan_stack_malloc_N
allocations, doesn't enlarge unnecessarily further the actual stack frame.
Because asan is only supported on FRAME_GROWS_DOWNWARD architectures
(mips, rs6000 and xtensa are conditional FRAME_GROWS_DOWNWARD arches, which
for -fsanitize=address or -fstack-protector* use FRAME_GROWS_DOWNWARD 1,
otherwise 0, others supporting asan always just use 1), the assumption for
the dynamic stack realignment is that the top of the stack frame (aka offset
0) is aligned to alignb passed to the function (which is the maximum of alignb
of all the vars in the frame). As checked by the assertion in the patch,
offsets[0] is 0 most of the time and so that assumption is correct, the only
case when it is not 0 is if -fstack-protector* is on together with
-fsanitize=address and cfgexpand.cc (create_stack_guard) created a stack
guard. That is the only variable which is allocated in the stack frame
right away, for all others with -fsanitize=address defer_stack_allocation
(or -fstack-protector*) returns true and so they aren't allocated
immediately but handled during the frame layout phases. So, the original
frame_offset of 0 is changed because of the stack guard to
-pointer_size_in_bytes and later at the
if (data->asan_vec.is_empty ())
{
align_frame_offset (ASAN_RED_ZONE_SIZE);
prev_offset = frame_offset.to_constant ();
}
to -ASAN_RED_ZONE_SIZE. The asan_emit_stack_protection code wasn't
taking this into account though, so essentially assumed in the
__asan_stack_malloc_N allocated memory it needs to align it such that
pointer corresponding to offsets[0] is alignb aligned. But that isn't
correct if alignb > ASAN_RED_ZONE_SIZE, in that case it needs to ensure that
pointer corresponding to frame offset 0 is alignb aligned.
The following patch fixes that. Unlike the previous case where
we knew that asan_frame_size + base_align_bias falls into the same bucket
as asan_frame_size, this isn't in some cases true anymore, so the patch
recomputes which bucket to use and if going to bucket 11 (because there is
no __asan_stack_malloc_11 function in the library) disables the after return
sanitization.
2024-04-11 Jakub Jelinek <jakub@redhat.com>
PR middle-end/110027
* asan.cc (asan_emit_stack_protection): Assert offsets[0] is
zero if there is no stack protect guard, otherwise
-ASAN_RED_ZONE_SIZE. If alignb > ASAN_RED_ZONE_SIZE and there is
stack pointer guard, take the ASAN_RED_ZONE_SIZE bytes allocated at
the top of the stack into account when computing base_align_bias.
Recompute use_after_return_class from asan_frame_size + base_align_bias
and set to -1 if that would overflow to 11.
Richard Biener [Thu, 11 Apr 2024 06:47:19 +0000 (08:47 +0200)]
middle-end/114681 - condition coverage and inlining
When inlining a gcond it can map to multiple stmts, esp. with
non-call EH. The following makes sure to pick up the remapped
condition when dealing with condition coverage.
PR middle-end/114681
* tree-inline.cc (copy_bb): Key on the remapped stmt
to identify gconds to have condition coverage data remapped.
Jakub Jelinek [Thu, 11 Apr 2024 07:46:00 +0000 (09:46 +0200)]
c++: Fix ANNOTATE_EXPR instantiation [PR114409]
The following testcase ICEs starting with the r14-4229 PR111529
change which moved ANNOTATE_EXPR handling from tsubst_expr to
tsubst_copy_and_build.
ANNOTATE_EXPR is only allowed in the IL to wrap a loop condition,
and the loop condition of while/for loops can be a COMPOUND_EXPR
with DECL_EXPR in the first operand and the corresponding VAR_DECL
in the second, as created by finish_cond
else if (!empty_expr_stmt_p (cond))
expr = build2 (COMPOUND_EXPR, TREE_TYPE (expr), cond, expr);
Since then Patrick reworked the instantiation, so that we have now
tsubst_stmt and tsubst_expr and ANNOTATE_EXPR ended up in the latter,
while only tsubst_stmt can handle DECL_EXPR.
Now, the reason why the while/for loops with variable declaration
in the condition works in templates without the pragmas (i.e. without
ANNOTATE_EXPR) is that both the FOR_STMT and WHILE_STMT handling uses
RECUR aka tsubst_stmt in handling of the *_COND operand:
case FOR_STMT:
stmt = begin_for_stmt (NULL_TREE, NULL_TREE);
RECUR (FOR_INIT_STMT (t));
finish_init_stmt (stmt);
tmp = RECUR (FOR_COND (t));
finish_for_cond (tmp, stmt, false, 0, false);
and
case WHILE_STMT:
stmt = begin_while_stmt ();
tmp = RECUR (WHILE_COND (t));
finish_while_stmt_cond (tmp, stmt, false, 0, false);
Therefore, it will handle DECL_EXPR embedded in COMPOUND_EXPR of the
{WHILE,FOR}_COND just fine.
But if that COMPOUND_EXPR with DECL_EXPR is wrapped with one or more
ANNOTATE_EXPRs, because ANNOTATE_EXPR is now done solely in tsubst_expr
and uses RECUR there (i.e. tsubst_expr), it will ICE on DECL_EXPR in there.
This could be fixed by keeping ANNOTATE_EXPR handling in tsubst_expr but
using tsubst_stmt for the first operand, but this patch instead
moves ANNOTATE_EXPR handling to tsubst_stmt (and uses tsubst_expr for the
second/third operand).
2024-04-11 Jakub Jelinek <jakub@redhat.com>
PR c++/114409
* pt.cc (tsubst_expr) <case ANNOTATE_EXPR>: Move to ...
(tsubst_stmt) <case ANNOTATE_EXPR>: ... here. Use tsubst_expr
instead of RECUR for the last 2 arguments.
Pan Li [Thu, 11 Apr 2024 01:39:44 +0000 (09:39 +0800)]
RISC-V: Bugfix ICE for the vector return arg in mode switch
This patch would like to fix a ICE in mode sw for below example code.
during RTL pass: mode_sw
test.c: In function ‘vbool16_t j(vuint64m4_t)’:
test.c:15:1: internal compiler error: in create_pre_exit, at
mode-switching.cc:451
15 | }
| ^
0x3978f12 create_pre_exit
__RISCV_BUILD__/../gcc/mode-switching.cc:451
0x3979e9e optimize_mode_switching
__RISCV_BUILD__/../gcc/mode-switching.cc:849
0x397b9bc execute
__RISCV_BUILD__/../gcc/mode-switching.cc:1324
extern size_t get_vl ();
vbool16_t
test (vuint64m4_t a)
{
unsigned long b;
return __riscv_vmsne_vx_u64m4_b16 (a, b, get_vl ());
}
The create_pre_exit would like to find a return value copy. If
not, there will be a reason in assert but not available for above
sample code when vector calling convension is enabled by default.
This patch would like to override the TARGET_FUNCTION_VALUE_REGNO_P
for vector register and then we will have hard_regno_nregs for copy_num,
aka there is a return value copy.
As a side-effect of allow vector in TARGET_FUNCTION_VALUE_REGNO_P, the
TARGET_GET_RAW_RESULT_MODE will have vector mode and which is sizeless
cannot be converted to fixed_size_mode. Thus override the hook
TARGET_GET_RAW_RESULT_MODE and return VOIDmode when the regno is-not-a
fixed_size_mode.
The below tests are passed for this patch.
* The fully riscv regression tests.
* The reproducing test in bugzilla PR114639.
PR target/114639
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_function_value_regno_p): New func
impl for hook TARGET_FUNCTION_VALUE_REGNO_P.
(riscv_get_raw_result_mode): New func imple for hook
TARGET_GET_RAW_RESULT_MODE.
(TARGET_FUNCTION_VALUE_REGNO_P): Impl the hook.
(TARGET_GET_RAW_RESULT_MODE): Ditto.
* config/riscv/riscv.h (V_RETURN): New macro for vector return.
(GP_RETURN_FIRST): New macro for the first GPR in return.
(GP_RETURN_LAST): New macro for the last GPR in return.
(FP_RETURN_FIRST): Diito but for FPR.
(FP_RETURN_LAST): Ditto.
(FUNCTION_VALUE_REGNO_P): Remove as deprecated and replace by
TARGET_FUNCTION_VALUE_REGNO_P.
gcc/testsuite/ChangeLog:
* g++.target/riscv/rvv/base/pr114639-1.C: New test.
* gcc.target/riscv/rvv/base/pr114639-1.c: New test.
btf: do not skip members of data type with type id BTF_VOID_TYPEID
The previous fix in gen_ctf_sou_type () exposes an issue in BTF
generation, however: BTF emission was currently decrementing the vlen
(indicating the number of members) to skip members of type CTF_K_UNKNOWN
altogether, but still emitting the BTF for the corresponding member (in
output_asm_btf_sou_fields ()).
One can see malformed BTF by executing the newly added CTF testcase
(gcc.dg/debug/ctf/ctf-bitfields-5.c) with -gbtf instead or even existing
btf-struct-2.c without this patch.
To fix the issue, it makes sense to rather _not_ skip members of data
type of type id BTF_VOID_TYPEID.
gcc/ChangeLog:
* btfout.cc (btf_asm_type): Do not skip emitting members of
unknown type.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-bitfields-4.c: Update the vlen check.
* gcc.dg/debug/btf/btf-struct-2.c: Check that member named 'f'
with void data type is emitted.
PR debug/112878: ICE: in ctf_add_slice, at ctfc.cc:499 with
_BitInt > 255 in a struct and -gctf1
The CTF generation in GCC does not have a mechanism to roll-back an
already added type. In this testcase presented in the PR, we hit a
representation limit in CTF slices (for a member of a struct) and ICE,
after the type for struct (CTF_K_STRUCT) has already been added to the
container.
To exit gracefully instead, we now check for both the offset and size of
the bitfield to be explicitly <= 255. If the check fails, we emit the
member with type CTF_K_UNKNOWN. Note that, the value 255 stems from the
existing binutils libctf checks which were motivated to guard against
malformed inputs.
Although it is not accurate to say that this is a CTF representation
limit, mark the code with TBD_CTF_REPRESENTATION_LIMIT for now so that
this can be taken care of with the next format version bump, when
libctf's checks for the slice data can be lifted as well.
gcc/ChangeLog:
PR debug/112878
* dwarf2ctf.cc (gen_ctf_sou_type): Check for conditions before
call to ctf_add_slice. Use CTF_K_UNKNOWN type if fail.
gcc/testsuite/ChangeLog:
PR debug/112878
* gcc.dg/debug/ctf/ctf-bitfields-5.c: New test.
Marek Polacek [Fri, 5 Apr 2024 16:37:19 +0000 (12:37 -0400)]
target: missing -Whardened with -fcf-protection=none [PR114606]
-Whardened warns when -fhardened couldn't enable a hardening option
because that option was disabled on the command line, e.g.:
$ ./cc1plus -quiet g.C -fhardened -O2 -fstack-protector
cc1plus: warning: '-fstack-protector-strong' is not enabled by '-fhardened' because it was specified on the command line [-Whardened]
but it doesn't work as expected with -fcf-protection=none:
David Malcolm [Wed, 10 Apr 2024 20:43:30 +0000 (16:43 -0400)]
analyzer: fix ICE on negative values for size_t [PR114472]
I made several attempts to fix this properly, but for now apply
a band-aid to at least prevent crashing on such cases.
gcc/analyzer/ChangeLog:
PR analyzer/114472
* access-diagram.cc (bit_size_expr::maybe_get_formatted_str):
Reject attempts to print sizes that are too large.
* region.cc (region_offset::calc_symbolic_bit_offset): Use a
typeless svalue for the bit offset.
* store.cc (bit_range::intersects_p): Replace assertion with
test.
(bit_range::exceeds_p): Likewise.
(bit_range::falls_short_of_p): Likewise.
gcc/testsuite/ChangeLog:
* c-c++-common/analyzer/out-of-bounds-pr114472.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Wed, 10 Apr 2024 20:43:28 +0000 (16:43 -0400)]
analyzer: add SARIF property bags to -Wanalyzer-overlapping-buffers
gcc/analyzer/ChangeLog:
* call-details.cc: Include "diagnostic-format-sarif.h".
(overlapping_buffers::overlapping_buffers): Add params for new
fields.
(overlapping_buffers::maybe_add_sarif_properties): New.
(overlapping_buffers::m_byte_range_a): New field.
(overlapping_buffers::byte_range_b): New field.
(overlapping_buffers::m_num_bytes_read_sval): New field.
(call_details::complain_about_overlap): Pass new params to
overlapping_buffers ctor.
* ranges.cc (symbolic_byte_offset::to_json): New.
(symbolic_byte_range::to_json): New.
* ranges.h (symbolic_byte_offset::to_json): New decl.
(symbolic_byte_range::to_json): New decl.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Harald Anlauf [Tue, 9 Apr 2024 21:07:59 +0000 (23:07 +0200)]
Fortran: fix argument checking of intrinsics C_SIZEOF, C_F_POINTER [PR106500]
The interpretation of the F2018 standard regarding valid arguments to the
intrinsic C_SIZEOF(X) was clarified in an edit to 18-007r1:
https://j3-fortran.org/doc/year/22/22-101r1.txt
loosening restrictions and giving examples. The F2023 text has:
! F2023:18.2.3.8 C_SIZEOF (X)
!
! X shall be a data entity with interoperable type and type parameters,
! and shall not be an assumed-size array, an assumed-rank array that
! is associated with an assumed-size array, an unallocated allocatable
! variable, or a pointer that is not associated.
where
! 3.41 data entity
! data object, result of the evaluation of an expression, or the
! result of the execution of a function reference
Update the checking code for interoperable arguments accordingly, and extend
to reject functions returning pointer as FPTR argument to C_F_POINTER.
gcc/fortran/ChangeLog:
PR fortran/106500
* check.cc (is_c_interoperable): Fix checks for C_SIZEOF.
(gfc_check_c_f_pointer): Reject function returning a pointer as FPTR,
and improve an error message.
gcc/testsuite/ChangeLog:
PR fortran/106500
* gfortran.dg/c_sizeof_6.f90: Remove wrong dg-error.
* gfortran.dg/sizeof_2.f90: Adjust pattern.
* gfortran.dg/c_f_pointer_tests_9.f90: New test.
* gfortran.dg/c_sizeof_7.f90: New test.
Richard Biener [Wed, 10 Apr 2024 08:33:40 +0000 (10:33 +0200)]
tree-optimization/114672 - WIDEN_MULT_PLUS_EXPR type mismatch
The following makes sure to restrict WIDEN_MULT*_EXPR to a mode
precision final compute type as the mode is used to find the optab
and type checking chokes when seeing bit-precisions later which
would likely also not properly expanded to RTL.
PR tree-optimization/114672
* tree-ssa-math-opts.cc (convert_plusminus_to_widen): Only
allow mode-precision results.
Andre Vieira [Wed, 10 Apr 2024 15:29:46 +0000 (16:29 +0100)]
aarch64: Add support for _BitInt
This patch adds support for C23's _BitInt for the AArch64 port when compiling
for little endianness. Big Endianness requires further target-agnostic
support and we therefor disable it for now.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (TARGET_C_BITINT_TYPE_INFO): Declare MACRO.
(aarch64_bitint_type_info): New function.
(aarch64_return_in_memory_1): Return large _BitInt's in memory.
(aarch64_function_arg_alignment): Adapt to correctly return the ABI
mandated alignment of _BitInt(N) where N > 128 as the alignment of
TImode.
(aarch64_composite_type_p): Return true for _BitInt(N), where N > 128.
libgcc/ChangeLog:
* config/aarch64/t-softfp (softfp_extras): Add floatbitinthf,
floatbitintbf, floatbitinttf and fixtfbitint.
* config/aarch64/libgcc-softfp.ver (GCC_14.0.0): Add __floatbitinthf,
__floatbitintbf, __floatbitinttf and __fixtfbitint.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/bitint-alignments.c: New test.
* gcc.target/aarch64/bitint-args.c: New test.
* gcc.target/aarch64/bitint-sizes.c: New test.
* gcc.target/aarch64/bitfield-bitint-abi.h: New header.
* gcc.target/aarch64/bitfield-bitint-abi-align16.c: New test.
* gcc.target/aarch64/bitfield-bitint-abi-align8.c: New test.
Andre Vieira [Wed, 10 Apr 2024 15:29:21 +0000 (16:29 +0100)]
aarch64: Do not give ABI change diagnostics for _BitInt(N)
This patch makes sure we do not give ABI change diagnostics for the ABI breaks
of GCC 9, 13 and 14 for any type involving _BitInt(N), since that type did not
exist before this GCC version.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (bitint_or_aggr_of_bitint_p): New function.
(aarch64_layout_arg): Don't emit diagnostics for types involving
_BitInt(N).
Jonathan Wakely [Wed, 10 Apr 2024 12:24:51 +0000 (13:24 +0100)]
libstdc++: Adjust expected locale-dependent date formats in tests
The std/time/year_month_day/io.cc test assumes that %x in the fr_FR
locale is %d/%m/%Y but on FreeBSD it is %d.%m.%Y instead. Make the test
PASS for either format.
Similarly, 27_io/manipulators/extended/get_time/char/2.cc expects that
%a in the de_DE locale is "Di" but on FreeBSD it's "Di." with a trailing
period. Adjust the input string to be "1971 Di." instead of "Di 1971"
and that way if %a doesn't expect the trailing '.' it simply won't
extract it from the stream.
This fixes:
FAIL: std/time/year_month_day/io.cc -std=gnu++20 execution test
FAIL: 27_io/manipulators/extended/get_time/char/2.cc -std=gnu++17 execution test
libstdc++-v3/ChangeLog:
* testsuite/27_io/manipulators/extended/get_time/char/2.cc:
Adjust input string so that it matches %a with or without a
trailing period.
* testsuite/std/time/year_month_day/io.cc: Adjust expected
format for %x in the fr_FR locale.
Jonathan Wakely [Mon, 8 Apr 2024 16:41:00 +0000 (17:41 +0100)]
libstdc++: Handle EMLINK and EFTYPE in std::filesystem::remove_all
Although POSIX requires ELOOP, FreeBSD documents that openat with
O_NOFOLLOW returns EMLINK if the last component of a filename is a
symbolic link. Check for EMLINK as well as ELOOP, so that the TOCTTOU
mitigation in remove_all works correctly.
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214633 or the
FreeBSD man page for reference.
According to its man page, DragonFlyBSD also uses EMLINK for this error,
and NetBSD uses its own EFTYPE. OpenBSD follows POSIX and uses EMLINK.
This fixes these failures on FreeBSD:
FAIL: 27_io/filesystem/operations/remove_all.cc -std=gnu++17 execution test
FAIL: experimental/filesystem/operations/remove_all.cc -std=gnu++17 execution test
libstdc++-v3/ChangeLog:
* src/c++17/fs_ops.cc (remove_all) [__FreeBSD__ || __DragonFly__]:
Check for EMLINK as well as ELOOP.
[__NetBSD__]: Check for EFTYPE as well as ELOOP.
Jakub Jelinek [Wed, 10 Apr 2024 08:08:12 +0000 (10:08 +0200)]
c++: Implement C++26 P2809R3 - Trivial infinite loops are not Undefined Behavior
The following patch attempts to implement P2809R3, which has been voted
in as a DR.
The middle-end has its behavior documented:
'-ffinite-loops'
Assume that a loop with an exit will eventually take the exit and
not loop indefinitely. This allows the compiler to remove loops
that otherwise have no side-effects, not considering eventual
endless looping as such.
This option is enabled by default at '-O2' for C++ with -std=c++11
or higher.
So, the following patch attempts to detect trivial infinite loops by detecting
trivially empty loops, if their condition is not INTEGER_CST (that case is
handled by the middle-end right already) trying to constant evaluate with
mce=true their condition and if it evaluates to true (and -ffinite-loops and
not processing_template_decl) wraps the condition into an ANNOTATE_EXPR which
tells the middle-end that the loop shouldn't be loop->finite_p despite
-ffinite-loops).
Furthermore, the patch adds -Wtautological-compare warnings for loop
conditions containing std::is_constant_evaluated(), either if those
always evaluate to true, or always evaluate to false, or will evaluate
to true just when checking if it is trivial infinite loop (and if in non-constexpr
function also say that it will evaluate to false otherwise).
The user is doing something weird in all those cases.
2024-04-10 Jakub Jelinek <jakub@redhat.com>
PR c++/114462
gcc/
* tree-core.h (enum annot_expr_kind): Add
annot_expr_maybe_infinite_kind enumerator.
* gimplify.cc (gimple_boolify): Handle annot_expr_maybe_infinite_kind.
* tree-cfg.cc (replace_loop_annotate_in_block): Likewise.
(replace_loop_annotate): Likewise. Move loop->finite_p initialization
before the replace_loop_annotate_in_block calls.
* tree-pretty-print.cc (dump_generic_node): Handle
annot_expr_maybe_infinite_kind.
gcc/cp/
* semantics.cc: Implement C++26 P2809R3 - Trivial infinite
loops are not Undefined Behavior.
(maybe_warn_for_constant_evaluated): Add trivial_infinite argument
and emit special diagnostics for that case.
(finish_if_stmt_cond): Adjust caller.
(finish_loop_cond): New function.
(finish_while_stmt): Use it.
(finish_do_stmt): Likewise.
(finish_for_stmt): Likewise.
gcc/testsuite/
* g++.dg/cpp26/trivial-infinite-loop1.C: New test.
* g++.dg/cpp26/trivial-infinite-loop2.C: New test.
* g++.dg/cpp26/trivial-infinite-loop3.C: New test.
Kewen Lin [Wed, 10 Apr 2024 07:59:43 +0000 (02:59 -0500)]
testsuite: Adjust pr113359-2_*.c with unsigned long long [PR114662]
pr113359-2_*.c define a struct having unsigned long type
members ay and az which have 4 bytes size at -m32, while
the related constants CL1 and CL2 used for equality check
are always 8 bytes, it makes compiler consider the below
69 if (a.ay != CL1)
70 __builtin_abort ();
always to abort and optimize away the following call to
getb, which leads to the expected wpa dumping on
"Semantic equality" missing.
This patch is to modify the types with unsigned long long
accordingly.
PR testsuite/114662
gcc/testsuite/ChangeLog:
* gcc.dg/lto/pr113359-2_0.c: Use unsigned long long instead of
unsigned long.
* gcc.dg/lto/pr113359-2_1.c: Likewise.
Peter Bergner [Tue, 9 Apr 2024 20:24:39 +0000 (15:24 -0500)]
rs6000: Replace OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR [PR101865]
This is a cleanup patch in preparation to fixing the real bug in PR101865.
TARGET_DIRECT_MOVE is redundant with TARGET_P8_VECTOR, so alias it to that.
Also replace all usages of OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR
and delete the now dead mask.
2024-04-09 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/101865
* config/rs6000/rs6000.h (TARGET_DIRECT_MOVE): Define.
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Replace
OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR. Delete redundant
OPTION_MASK_DIRECT_MOVE usage. Delete TARGET_DIRECT_MOVE dead code.
(rs6000_opt_masks): Neuter the "direct-move" option.
* config/rs6000/rs6000-c.cc (rs6000_target_modify_macros): Replace
OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR. Delete useless
comment.
* config/rs6000/rs6000-cpus.def (ISA_2_7_MASKS_SERVER): Delete
OPTION_MASK_DIRECT_MOVE.
(OTHER_VSX_VECTOR_MASKS): Likewise.
(POWERPC_MASKS): Likewise.
* config/rs6000/rs6000.opt (mdirect-move): Remove Mask and Var.
Nathaniel Shead [Fri, 29 Mar 2024 02:53:54 +0000 (13:53 +1100)]
c++: Keep DECL_SAVED_TREE of cdtor instantiations in modules [PR104040]
A template instantiation still needs to have its DECL_SAVED_TREE so that
its definition is emitted into the CMI. This way it can be emitted in
the object file of any importers that use it, in case it doesn't end up
getting emitted in this TU.
This is true even for maybe-in-charge functions, because we don't
currently stream the clones directly but instead regenerate them from
this function.
PR c++/104040
gcc/cp/ChangeLog:
* semantics.cc (expand_or_defer_fn_1): Keep DECL_SAVED_TREE for
all vague linkage cdtors with modules.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr104040_a.C: New test.
* g++.dg/modules/pr104040_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Hongyu Wang [Tue, 9 Apr 2024 01:50:11 +0000 (09:50 +0800)]
[APX] Prohibit SHA/KEYLOCKER usage of EGPR when APX enabled
The latest APX spec announced removal of SHA/KEYLOCKER evex promotion,
which means the SHA/KEYLOCKER insn does not support EGPR when APX
enabled. Update the corresponding constraints to their EGPR-disabled
counterparts.
gcc/ChangeLog:
* config/i386/sse.md (sha1msg1): Use "ja" instead of "Bm" for
memory constraint.
(sha1msg2): Likewise.
(sha1nexte): Likewise.
(sha1rnds4): Likewise.
(sha256msg1): Likewise.
(sha256msg2): Likewise.
(sha256rnds2): Likewise.
(aes<aesklvariant>u8): Use "jm" instead of "m" for memory
constraint.
(*aes<aeswideklvariant>u8): Likewise.
(*encodekey128u32): Use "jr" instead of "r" for register
constraints.
(*encodekey256u32): Likewise.
c++: Track declarations imported from partitions [PR99377]
The testcase in comment 15 of the linked PR is caused because the
following assumption in depset::hash::make_dependency doesn't hold:
if (DECL_LANG_SPECIFIC (not_tmpl)
&& DECL_MODULE_IMPORT_P (not_tmpl))
{
/* Store the module number and index in cluster/section,
so we don't have to look them up again. */
unsigned index = import_entity_index (decl);
module_state *from = import_entity_module (index);
/* Remap will be zero for imports from partitions, which
we want to treat as-if declared in this TU. */
if (from->remap)
{
dep->cluster = index - from->entity_lwm;
dep->section = from->remap;
dep->set_flag_bit<DB_IMPORTED_BIT> ();
}
}
This is because at least for template specialisations, we first see the
declaration in the header unit imported from the partition, and then the
instantiation provided by the partition itself. This means that the
'import_entity_index' lookup doesn't report that the specialisation was
declared in the partition and thus should be considered as-if it was
part of the TU, and get emitted into the CMI.
We always need to emit definitions from module partitions into the
primary module interface's CMI, as unlike with other kinds of transitive
imports the built CMIs for module partitions are not visible to
importers.
To fix this, this patch allows, as a special case for installing an
entity from a partition, to overwrite the entity_map entry with the
(later) index into the partition so that this assumption holds again.
We only do this for the first time we override with a partition, so that
entities are at least still reported as originating from the first
imported partition that declares them (rather than the last); existing
tests check for this and this seems to be a friendlier approach to go
for, albeit slightly more expensive.
PR c++/99377
gcc/cp/ChangeLog:
* module.cc (trees_in::install_entity): Overwrite entity map
index if installing from a partition.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr99377-3_a.H: New test.
* g++.dg/modules/pr99377-3_b.C: New test.
* g++.dg/modules/pr99377-3_c.C: New test.
* g++.dg/modules/pr99377-3_d.C: New test.
David Faust [Mon, 8 Apr 2024 20:33:48 +0000 (13:33 -0700)]
btf: improve btf-datasec-3.c test [PR114642]
This test failed on powerpc --target_board=unix'{-m32}' because two
variables were not placed in sections where the test silently (and
incorrectly) assumed they would be.
The important thing for the test is only that BTF_KIND_DATASEC entries
are NOT generated for the extern variable declarations without an
explicit section attribute. Make the test more robust by placing the
non-extern variables in explicit sections, and invert the checks to
more accurately verify what we care about in this test.
gcc/testsuite/
PR testsuite/114642
* gcc.dg/debug/btf/btf-datasec-3.c: Make test more robust on different
architectures.
s390x: Optimize vector permute with constant indexes
Loop vectorizer can generate vector permutes with constant indexes
where all indexes are equal. Optimize this case to use vector
replicate instead of vector permute.
David Faust [Mon, 8 Apr 2024 18:10:41 +0000 (11:10 -0700)]
btf: emit symbol refs in DATASEC entries only for BPF [PR114608]
The behavior introduced in fa60ac54964 btf: Emit labels in DATASEC bts_offset entries.
is only fully correct when compiling for the BPF target with BPF CO-RE
enabled. In other cases, depending on optimizations, it can result in
an incorrect symbol reference in the entry bts_offset field for a symbol
which may not be emitted at all, causing link-time undefined symbol
reference errors like in PR114608.
The offending bts_offset field of BTF_KIND_DATASEC entries is in reality
only currently useful to consumers of BTF information for BPF programs
anyway. Correct the regression by only emitting symbol references in
these entries when compiling for the BPF target. For other targets, the
behavior returns to that prior to fa60ac54964.
The underlying cause is related to PR 113566 "btf: incorrect
BTF_KIND_DATASEC entries for variables which are optimized out." A
complete fix for 113566 is more involved and unsuitable for stage 4,
but will be addressed in the near future.
gcc/
PR debug/114608
* btfout.cc (btf_asm_datasec_entry): Only emit a symbol reference when
generating BTF for BPF CO-RE target.
gcc/testsuite/
PR debug/114608
* gcc.dg/debug/btf/btf-datasec-1.c: Check bts_offset symbol references
only for BPF target.
* gcc.dg/debug/btf/btf-datasec-2.c: Likewise.
* gcc.dg/debug/btf/btf-pr106773.c: Likewise.
Richard Ball [Tue, 9 Apr 2024 15:31:35 +0000 (16:31 +0100)]
aarch64: Fix ACLE SME streaming mode error in neon-sve-bridge
When using LTO, handling the pragma for sme before the pragma
for the neon-sve-bridge caused the following error on svset_neonq,
in the neon-sve-bridge.c test.
error: ACLE function '0' can only be called when SME streaming mode is enabled.
This has been resolved by changing the pragma handlers to accept two modes.
One where they add functions normally and a second in which registered_functions
is filled with a placeholder value.
By using this, the ordering of the functions can be maintained.
gcc/ChangeLog:
* config/aarch64/aarch64-c.cc (aarch64_pragma_aarch64):
Add functions_nulls parameter to pragma_handlers.
* config/aarch64/aarch64-protos.h: Likewise.
* config/aarch64/aarch64-sve-builtins.h
(enum handle_pragma_index): Add enum to count
number of pragmas to be handled.
* config/aarch64/aarch64-sve-builtins.cc
(GTY): Add global variable for initial indexes
and change overload_names to an array.
(function_builder::function_builder):
Add pragma handler information.
(function_builder::add_function):
Add code for overwriting previous
registered_functions entries.
(add_unique_function):
Use an array to register overload_names
for both pragma handler modes.
(add_overloaded_function): Likewise.
(init_builtins):
Add functions_nulls parameter to pragma_handlers.
(handle_arm_sve_h):
Initialize pragma handler information.
(handle_arm_neon_sve_bridge_h): Likewise.
(handle_arm_sme_h): Likewise.
Richard Biener [Tue, 9 Apr 2024 12:25:57 +0000 (14:25 +0200)]
lto/114655 - -flto=4 at link time doesn't override -flto=auto at compile time
The following adjusts -flto option processing in lto-wrapper to have
link-time -flto override any compile time setting.
PR lto/114655
* lto-wrapper.cc (merge_flto_options): Add force argument.
(merge_and_complain): Do not force here.
(run_gcc): But here to make the link-time -flto option override
any compile-time one.
PR114601 shows that it is possible to reach the condition_uid lookup
without having also created the fn->cond_uids, through
compiler-generated conditionals. Consider all lookups on non-existing
maps misses, which they are from the perspective of the source code, to
avoid the NULL access.
Jakub Jelinek [Tue, 9 Apr 2024 10:35:18 +0000 (12:35 +0200)]
i386: Fix aes/vaes patterns [PR114576]
On Wed, Apr 19, 2023 at 02:40:59AM +0000, Jiang, Haochen via Gcc-patches wrote:
> > > (define_insn "aesenc"
> > > - [(set (match_operand:V2DI 0 "register_operand" "=x,x")
> > > - (unspec:V2DI [(match_operand:V2DI 1 "register_operand" "0,x")
> > > - (match_operand:V2DI 2 "vector_operand" "xBm,xm")]
> > > + [(set (match_operand:V2DI 0 "register_operand" "=x,x,v")
> > > + (unspec:V2DI [(match_operand:V2DI 1 "register_operand" "0,x,v")
> > > + (match_operand:V2DI 2 "vector_operand"
> > > + "xBm,xm,vm")]
> > > UNSPEC_AESENC))]
> > > - "TARGET_AES"
> > > + "TARGET_AES || (TARGET_VAES && TARGET_AVX512VL)"
> > > "@
> > > aesenc\t{%2, %0|%0, %2}
> > > + vaesenc\t{%2, %1, %0|%0, %1, %2}
> > > vaesenc\t{%2, %1, %0|%0, %1, %2}"
> > > - [(set_attr "isa" "noavx,avx")
> > > + [(set_attr "isa" "noavx,aes,avx512vl")
> > Shouldn't it be vaes_avx512vl and then remove " || (TARGET_VAES &&
> > TARGET_AVX512VL)" from condition.
>
> Since VAES should not imply AES, we need that "|| (TARGET_VAES &&
> TARGET_AVX512VL)"
>
> And there is no need to add vaes_avx512vl since the last alternative will only
> be hit when there is no aes. When there is no aes, the pattern will need vaes
> and avx512vl both or we could not use this pattern. avx512vl here is just like
> a placeholder.
As the following testcase shows, the above change was incorrect.
Using aes isa for the second alternative is obviously wrong, aes is enabled
whenever -maes is, regardless of -mavx or -mno-avx, so the above change
means that for -maes -mno-avx RA can choose, either it matches the first
alternative with the dup operand, or it matches the second one (but that
is of course wrong because vaesenc VEX encoded insn needs AES & AVX CPUID).
The big question is if "Since VAES should not imply AES" is the case or not.
Looking around at what LLVM does on godbolt, seems since clang 6 which added
-mvaes support -mvaes there implies -maes, but GCC treats those two
independent.
Now, if we'd take the LLVM path of making -mvaes imply -maes and -mno-aes
imply -mno-vaes, then we should probably just revert the above patch and
tweak common/config/i386/ to do the implications (+ add the testcase from
this patch).
If we keep the current behavior, where AES and VAES are completely
independent extensions, then we need to do more changes as the following
patch attempts to do.
We should use the aesenc etc. insns for noavx as before, we know at that
point that TARGET_AES must be true because (TARGET_VAES && TARGET_AVX512VL)
won't be true when !TARGET_AVX - TARGET_AVX512VL implies TARGET_AVX.
For the second alternative, i.e. the AVX AES VEX or VAES AVX512F EVEX case
without using %xmm16+/EGPR regs, the patch uses avx isa, but we need to
emit {evex} prefix in the assembly if AES ISA is not enabled.
For the last alternative, we need to use a new vaes_avx512vl isa attribute,
because the %xmm16+/EGPR support is there only if both VAES and AVX512VL
is enabled, not just AVX and AES.
Still, I wonder if -mvaes shouldn't imply at least -mavx512f and
-mno-avx512f shouldn't imply -mno-vaes, because otherwise can't see how
it could use 512-bit registers (this part not done in the patch).
2024-04-09 Jakub Jelinek <jakub@redhat.com>
PR target/114576
* config/i386/i386.md (isa): Remove aes, add vaes_avx512vl.
(enabled): Remove aes isa check, add vaes_avx512vl.
* config/i386/sse.md (aesenc, aesenclast, aesdec, aesdeclast): Use
jm instead of m for second alternative and emit {evex} prefix
for it if !TARGET_AES. Use noavx,avx,vaes_avx512vl isa attribute.
(vaesdec_<mode>, vaesdeclast_<mode>, vaesenc_<mode>,
vaesenclast_<mode>): Add second alternative with x instead of v
and jm instead of m.
Gaius Mulley [Tue, 9 Apr 2024 10:21:02 +0000 (11:21 +0100)]
modula2: remove description of fdebug-trace-quad, fdebug-trace-api and add fm2-debug-trace=
This documentation fix removes the descriptions of -fdebug-trace-quad
and -fdebug-trace-api. It adds a description of -fm2-debug-trace=
together with the trace alternatives: line,token,quad,all.
Yang Yujie [Mon, 8 Apr 2024 08:45:13 +0000 (16:45 +0800)]
LoongArch: Enable switchable target
This patch fixes the back-end context switching in cases where functions
should be built with their own target contexts instead of the
global one, such as LTO linking and functions with target attributes (TBD).
PR target/113233
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_reg_init):
Reinitialize the loongarch_regno_mode_ok cache.
(loongarch_option_override): Same.
(loongarch_save_restore_target_globals): Restore target globals.
(loongarch_set_current_function): Restore the target contexts
for functions.
(TARGET_SET_CURRENT_FUNCTION): Define.
* config/loongarch/loongarch.h (SWITCHABLE_TARGET): Enable
switchable target context.
* config/loongarch/loongarch-builtins.cc (loongarch_init_builtins):
Initialize all builtin functions at startup.
(loongarch_expand_builtin): Turn assertion of builtin availability
into a test.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Define condition loongarch_sx_as.
* gcc.dg/lto/pr113233_0.c: New test.
Generating the constants used for recording the edges taken for
condition coverage would trigger undefined behavior when an expression
had exactly 64 (== sizeof (1ULL)) conditions, as it would generate the
constant for the next iteration at the end of the loop body, even if there
was never a next iteration. By moving the check and constant generation
to the top of the loop and hoisting the increment flag there is no
opportunity for UB.
PR middle-end/114627
gcc/ChangeLog:
* tree-profile.cc (instrument_decisions): Generate constant
at the start of loop.
Properly add the condition -> expression mapping of inlined gconds from
the caller into the callee map. This is a fix for PR114599 that works
beyond fixing the segfault, as the previous fixed copied references to
the source gconds, not the deep copied ones that end up in the calle
body.
The new tests checks this, both in the case of a calle without
conditions (which triggered the segfault), and a test that shows that
conditions are properly mapped, and not mixed.
PR middle-end/114599
gcc/ChangeLog:
* tree-inline.cc (copy_bb): Copy cond_uids into callee.
(prepend_lexical_block): Remove outdated comment.
(add_local_variables): Remove bad cond_uids copy.
Jakub Jelinek [Tue, 9 Apr 2024 07:40:45 +0000 (09:40 +0200)]
libquadmath: Provide __BYTE_ORDER, __LITTLE_ENDIAN and __BIG_ENDIAN definitions
My earlier libquadmath change apparently broke mingw32 build, while on Linux
<bits/endian.h> is included and defines these, on Mingw apparently that isn't
the case, while soft-fp wants a guarantee that sfp-machine.h defines these.
2024-04-09 Jakub Jelinek <jakub@redhat.com>
* sfp-machine.h (__LITTLE_ENDIAN, __BIG_ENDIAN, __BYTE_ORDER): Define
if __BYTE_ORDER isn't defined.
Jakub Jelinek [Tue, 9 Apr 2024 07:31:42 +0000 (09:31 +0200)]
c++: Fix up maybe_warn_for_constant_evaluated calls [PR114580]
When looking at maybe_warn_for_constant_evaluated for the trivial
infinite loops patch, I've noticed that it can emit weird diagnostics
for if constexpr in templates, first warn that std::is_constant_evaluted()
always evaluates to false (because the function template is not constexpr)
and then during instantiation warn that std::is_constant_evaluted()
always evaluates to true (because it is used in if constexpr condition).
Now, only the latter is actually true, even when the if constexpr
is in a non-constexpr function, it will still always evaluate to true.
So, the following patch fixes it to call maybe_warn_for_constant_evaluated
always with IF_STMT_CONSTEXPR_P (if_stmt) as the second argument rather than
true if it is if constexpr with non-dependent condition etc.
2024-04-09 Jakub Jelinek <jakub@redhat.com>
PR c++/114580
* semantics.cc (finish_if_stmt_cond): Call
maybe_warn_for_constant_evaluated with IF_STMT_CONSTEXPR_P (if_stmt)
as the second argument, rather than true/false depending on if
it is if constexpr with non-dependent constant expression with
bool type.
* g++.dg/cpp2a/is-constant-evaluated15.C: New test.
Jakub Jelinek [Tue, 9 Apr 2024 07:29:08 +0000 (09:29 +0200)]
Fix up duplicated words mostly in comments, part 2
Another patch from eyeballing
git grep -v 'long long\|optab optab\|template template\|double double' | grep ' \([a-zA-Z]\+\) \1 '
output, this time in gcc/ subdirectory.
2024-04-09 Jakub Jelinek <jakub@redhat.com>
gcc/
* expr.cc (convert_mode_scalar): Fix duplicated words in comment;
into into -> it into.
* function.h (function::cond_uids): Fix duplicated words in comment;
same same -> same.
* config/riscv/riscv-vector-costs.cc
(costs::adjust_vect_cost_per_loop): Fix duplicated words in comment;
model model -> model.
* config/riscv/riscv-vector-builtins-shapes.cc (build_base): Fix
duplicated words in comment; for for -> for.
* config/riscv/riscv-avlprop.cc (pass_avlprop::execute): Fix
duplicated words in comment; more more -> more.
* config/aarch64/driver-aarch64.cc (host_detect_local_cpu): Fix
duplicated words in comment; be be -> be.
* tree-profile.cc (masking_vectors): Fix duplicated words in comment;
has has -> has, the the -> the.
* value-range.cc (irange::set_range_from_bitmask): Fix duplicated
words in comment; the the -> the.
* gcov.cc (add_condition_counts): Fix duplicated words in comment;
to to -> to.
* vr-values.cc (get_scev_info): Fix duplicated words in comment;
the the -> to the.
* tree-vrp.cc (fully_replaceable): Fix duplicated words in comment;
by by -> by.
* mode-switching.cc (single_succ_confluence_n): Fix duplicated words
in comment; the the -> the.
* tree-ssa-phiopt.cc (value_replacement): Fix duplicated words in
comment; can can -> we can.
* gimple-range-phi.cc (phi_analyzer::process_phi): Fix duplicated words
in comment; it it -> it is.
* tree-ssa-sccvn.cc (visit_phi): Fix duplicated words in comment;
to to -> to.
* rtl-ssa/accesses.h (use_info::next_debug_insn_use): Fix duplicated
words in comment; if if -> if.
* doc/options.texi (InverseMask): Fix duplicated words; and and -> and.
Change take to takes.
* doc/invoke.texi (fanalyzer-undo-inlining): Fix duplicated words;
be be -> be.
(-minline-memops-threshold): Likewise.
gcc/analyzer/
* analyzer.opt (Wanalyzer-undefined-behavior-strtok): Fix duplicated
words; in in -> in.
* program-state.cc (sm_state_map::replay_call_summary): Fix duplicated
words in comment; to to -> to.
(program_state::replay_call_summary): Likewise.
* region-model.cc (region_model::replay_call_summary): Likewise.
gcc/c/
* c-decl.cc (previous_tag): Fix duplicated words in comment; the the
-> the.
(diagnose_mismatched_decls): Fix duplicated words in comment;
about about -> about.
gcc/cp/
* constexpr.cc (build_new_constexpr_heap_type): Fix duplicated words
in comment; is is -> is.
* cp-tree.def (CO_RETURN_EXPR): Fix duplicated words in comment;
for for -> for.
* parser.cc (fixup_blocks_walker): Fix duplicated words in comment;
is is -> is.
* semantics.cc (fixup_template_type): Fix duplicated words in comment;
for for -> for.
(finish_omp_for): Fix duplicated words in comment; the the -> the.
* pt.cc (more_specialized_fn): Fix duplicated words in comment;
think think -> think.
(type_targs_deducible_from): Fix duplicated words in comment; the the
-> the.
gcc/jit/
* docs/topics/expressions.rst (Constructor expressions): Fix
duplicated words; have have -> have.
Jakub Jelinek [Tue, 9 Apr 2024 07:28:27 +0000 (09:28 +0200)]
bitint: Don't move debug stmts from before returns_twice calls [PR114628]
Debug stmts are allowed by the verifier before the returns_twice calls.
More importantly, they don't have a lhs, so the current handling of
arg_stmts statements to force them on the edges ICEs.
The following patch just keeps them where they were before.
2024-04-09 Jakub Jelinek <jakub@redhat.com>
PR middle-end/114628
* gimple-lower-bitint.cc (gimple_lower_bitint): Keep debug stmts
before returns_twice calls as is, don't push them into arg_stmts
vector/move to edges.
Sergey Bugaev [Sat, 23 Mar 2024 14:35:11 +0000 (17:35 +0300)]
Move GNU/Hurd startfile spec from config/i386/gnu.h to config/gnu.h
Since it's not i386-specific; this makes it possible to reuse it for other
architectures.
Also, add a warning for the case gnu.h is specified before gnu-user.h, which
would cause gnu-user's version of the spec to override gnu's, and not the other
way around as it's intended. The i?86-gnu target currently specifies them in
the right order, but it's easy to accidentally put them in a wrong order.
Richard Biener [Mon, 8 Apr 2024 08:50:18 +0000 (10:50 +0200)]
middle-end/114604 - ranger allocates bitmap without initialized obstack
The following fixes ranger bitmap allocation when invoked from IPA
context where the global bitmap obstack possibly isn't initialized.
Instead of trying to use one of the ranger obstacks the following
simply initializes the global bitmap obstack around an active ranger.
PR middle-end/114604
* gimple-range.cc (enable_ranger): Initialize the global
bitmap obstack.
(disable_ranger): Release it.
Jakub Jelinek [Tue, 9 Apr 2024 06:17:25 +0000 (08:17 +0200)]
libquadmath: Use soft-fp for sqrtq finite positive arguments [PR114623]
sqrt should be 0.5ulp precise, but the current implementation is less
precise than that.
The following patch uses the soft-fp code (like e.g. glibc for x86) for it
if possible. I didn't want to replicate the libgcc infrastructure for
choosing the right sfp-machine.h, so the patch just uses a single generic
implementation. As the code is used solely for the finite positive arguments,
it shouldn't generate NaNs (so the exact form of canonical QNaN/SNaN is
irrelevant), and sqrt for these shouldn't produce underflows/overflows either,
for < 1.0 arguments it always returns larger values than the argument and for
> 1.0 smaller values than the argument.
2024-04-09 Jakub Jelinek <jakub@redhat.com>
PR libquadmath/114623
* sfp-machine.h: New file.
* math/sqrtq.c: Include from libgcc/soft-fp also soft-fp.h and quad.h
if possible.
(USE_SOFT_FP): Define in that case.
(sqrtq): Use soft-fp based implementation for the finite positive
arguments if possible.
H.J. Lu [Tue, 9 Apr 2024 01:57:49 +0000 (18:57 -0700)]
x86: Define __APX_INLINE_ASM_USE_GPR32__
Define __APX_INLINE_ASM_USE_GPR32__ for -mapx-inline-asm-use-gpr32.
When __APX_INLINE_ASM_USE_GPR32__ is defined, inline asm statements
should contain only instructions compatible with r16-r31.
gcc/
PR target/114587
* config/i386/i386-c.cc (ix86_target_macros_internal): Define
__APX_INLINE_ASM_USE_GPR32__ for -mapx-inline-asm-use-gpr32.
Kewen Lin [Tue, 9 Apr 2024 02:02:17 +0000 (21:02 -0500)]
testsuite: Add profile_update_atomic check to gcov-20.c [PR114614]
As PR114614 shows, the newly added test case gcov-20.c by
commit r14-9789-g08a52331803f66 failed on targets which do
not support atomic profile update, there would be a message
like:
warning: target does not support atomic profile update,
single mode is selected
Since the test case adopts -fprofile-update=atomic, it
requires effective target check profile_update_atomic, this
patch is to add the check accordingly.
Kewen Lin [Tue, 9 Apr 2024 02:01:36 +0000 (21:01 -0500)]
rs6000: Fix wrong align passed to build_aligned_type [PR88309]
As the comments in PR88309 show, there are two oversights
in rs6000_gimple_fold_builtin that pass align in bytes to
build_aligned_type but which actually requires align in
bits, it causes unexpected ICE or hanging in function
is_miss_rate_acceptable due to zero align_unit value.
This patch is to fix them by converting bytes to bits, add
an assertion on positive align_unit value and notes function
build_aligned_type requires align measured in bits in its
function comment.
PR target/88309
Co-authored-by: Andrew Pinski <quic_apinski@quicinc.com>
gcc/ChangeLog:
* config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Fix
wrong align passed to function build_aligned_type.
* tree-ssa-loop-prefetch.cc (is_miss_rate_acceptable): Add an
assertion to ensure align_unit should be positive.
* tree.cc (build_qualified_type): Update function comments.
Gaius Mulley [Tue, 9 Apr 2024 01:35:11 +0000 (02:35 +0100)]
PR modula2/114648 cc1gm2 by default does not handle C pre-processor file and line directives
This patch fixes the default behavior of cc1gm2 to the description in
the documentation. By default cc1gm2 will allow C preprocessor
directives (they can be turned off via -fno-cpp).
gcc/m2/ChangeLog:
PR modula2/114648
* gm2-compiler/M2Options.mod (LineDirectives): Initially
set to true.
gcc/testsuite/ChangeLog:
PR modula2/114648
* gm2/cpp/default/pass/AdvParse.def: New test.
* gm2/cpp/default/pass/AdvParse.mod: New test.
* gm2/cpp/default/pass/cpp-default-pass.exp: New test.
combine: Fix ICE in try_combine on pr112494.c [PR112560]
The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
internal compiler error: RTL check: expected elt 0 type 'e' or 'u', have 'E' (rtx unspec) in try_combine, at combine.cc:3237
This is
3236 /* Just replace the CC reg with a new mode. */
3237 SUBST (XEXP (*cc_use_loc, 0), newpat_dest);
3238 undobuf.other_insn = cc_use_insn;
in combine.cc, where *cc_use_loc is
(unspec:DI [
(reg:CC 17 flags)
] UNSPEC_PUSHFL)
combine assumes CC must be used inside of a comparison and uses XEXP (..., 0)
without checking on the RTX type of the argument.
Replace cc_use_loc with the entire new RTX only in case cc_use_loc satisfies
COMPARISON_P predicate. Otherwise scan the entire cc_use_loc RTX for CC reg
to be updated with a new mode.
PR rtl-optimization/112560
gcc/ChangeLog:
* combine.cc (try_combine): Replace cc_use_loc with the entire
new RTX only in case cc_use_loc satisfies COMPARISON_P predicate.
Otherwise scan the entire cc_use_loc RTX for CC reg to be updated
with a new mode.
* config/i386/i386.md (@pushf<mode>2): Allow all CC modes for
operand 1.
..., and specify '--param=gcn-preferred-vectorization-factor=64' for
'gcc.target/gcn/[...]' test cases with 'scan-assembler' directives that
are specific to 64-lane vectors. This resolves regressions introduced
in commit 6dedafe166cc02ae87b6a0699ad61ce3ffc46803
"amdgcn: Prefer V32 on RDNA devices".
-PASS: gcc.c-torture/compile/asmgoto-2.c -O0 (test for excess errors)
+ERROR: gcc.c-torture/compile/asmgoto-2.c -O0 : no files matched glob pattern "lra1020113.c.[0-9][0-9][0-9]r.reload" for " dg-do 2 compile { target lra } "
Etc.
However, nvptx appears to support 'asm goto' with outputs, including the
new execution test case:
PASS: gcc.dg/pr107385.c execution test
Therefore, generally use new effective-target 'asm_goto_with_outputs' instead
of 'lra'. One exceptions is 'gcc.dg/pr110079.c', which doesn't use 'asm goto'
with outputs, and continues using effective-target 'lra', with special-casing
nvptx target, to avoid ERROR for 'lra'.
Thomas Schwinge [Thu, 7 Mar 2024 13:42:07 +0000 (14:42 +0100)]
GCN, nvptx: Errors during device probing are fatal
Currently, we silently disable libgomp GCN and nvptx plugins/devices in
presence of certain error conditions during device probing, thus typically
silently resorting to host-fallback execution. Make such errors fatal, similar
as for any other device access later on, so that we early and reliably notice
when things go wrong. (Keep just two cases non-fatal: (a) libgomp GCN or nvptx
plugins are available but 'libhsa-runtime64.so.1' or 'libcuda.so.1' are not,
and (b) those are available, but the corresponding devices are not.)
This resolves the issue that we've got execution test cases unexpectedly
PASSing, despite:
libgomp: GCN fatal error: Run-time could not be initialized
Runtime message: HSA_STATUS_ERROR_OUT_OF_RESOURCES: The runtime failed to allocate the necessary resources. This error may also occur when the core runtime library needs to spawn threads or create internal OS-specific events.
..., and therefore they were not offloaded to the GCN device, but ran in
host-fallback execution mode. What happend in that scenario is that in
'init_hsa_context' during the initial 'GOMP_OFFLOAD_get_num_devices' we ran
into 'HSA_STATUS_ERROR_OUT_OF_RESOURCES', but it wasn't fatal, but just
silently disabled the libgomp plugin/device.
Especially "entertaining" were cases where such unintended host-fallback
execution happened during effective-target checks like
'offload_device_available' (host-fallback execution there meaning: no offload
device available), but actual test cases then were running with an offload
device available, and therefore mis-configured.
include/
* cuda/cuda.h (CUresult): Add 'CUDA_ERROR_NO_DEVICE'.
libgomp/
* plugin/plugin-gcn.c (init_hsa_context): Add and handle
'bool probe' parameter. Adjust all users; errors during device
probing are fatal.
* plugin/plugin-nvptx.c (nvptx_get_num_devices): Aside from
'CUDA_ERROR_NO_DEVICE', errors during device probing are fatal.
Martin Jambor [Mon, 8 Apr 2024 16:53:23 +0000 (18:53 +0200)]
ICF&SRA: Make ICF and SRA agree on padding
PR 113359 shows that (at least with -fno-strict-aliasing) ICF can
unify two functions which copy an aggregate type of the same size but
then SRA, through its total scalarization, can copy the aggregate by
pieces, skipping paddding, but the padding was not the same in the two
original functions that ICF unified.
This patch enhances SRA with the ability to collect padding
information which then can be compared from within ICF. Unfortunately
SRA uses OPTION_SET_P when determining its limits, so ICF needs to
switch cfuns at least once to figure it out too.
gcc/ChangeLog:
2024-03-27 Martin Jambor <mjambor@suse.cz>
PR ipa/113359
* ipa-icf-gimple.h (func_checker): New members
safe_for_total_scalarization_p, m_total_scalarization_limit_known_p
and m_total_scalarization_limit.
(func_checker::func_checker): Initialize new member variables.
* ipa-icf-gimple.cc: Include tree-sra.h.
(func_checker::func_checker): Initialize new member variables.
(func_checker::safe_for_total_scalarization_p): New function.
(func_checker::compare_operand): Use the new function.
* tree-sra.h (sra_get_max_scalarization_size): Declare.
(sra_total_scalarization_would_copy_same_data_p): Likewise.
* tree-sra.cc (prepare_iteration_over_array_elts): New function.
(class sra_padding_collecting): New.
(sra_padding_collecting::record_padding): Likewise.
(scalarizable_type_p): Rename to totally_scalarizable_type_p. Add
ability to record padding when requested.
(totally_scalarize_subtree): Split out gathering information necessary
to iterate over array elements to prepare_iteration_over_array_elts.
Fix errornous early exit.
(analyze_all_variable_accesses): Adjust the call to
totally_scalarizable_type_p. Move determining of total scalariation
size limit...
(sra_get_max_scalarization_size): ...here.
(check_ts_and_push_padding_to_vec): New function.
(sra_total_scalarization_would_copy_same_data_p): Likewise.
projects / thirdparty / gcc.git / log
