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.
Martin Jambor [Mon, 8 Apr 2024 16:53:23 +0000 (18:53 +0200)]
ipa: Compare jump functions in ICF (PR 113907)
In PR 113907 comment #58, Honza found a case where ICF thinks bodies
of functions are equivalent but becaise of difference in aliases in a
memory access, different aggregate jump functions are associated with
supposedly equivalent call statements. This patch adds a way to
compare jump functions and plugs it into ICF to avoid the issue.
gcc/ChangeLog:
2024-03-20 Martin Jambor <mjambor@suse.cz>
PR ipa/113907
* ipa-prop.h (class ipa_vr): Declare new overload of a member function
equal_p.
(ipa_jump_functions_equivalent_p): Declare.
* ipa-prop.cc (ipa_vr::equal_p): New function.
(ipa_agg_pass_through_jf_equivalent_p): Likewise.
(ipa_agg_jump_functions_equivalent_p): Likewise.
(ipa_jump_functions_equivalent_p): Likewise.
* ipa-cp.h (values_equal_for_ipcp_p): Declare.
* ipa-cp.cc (values_equal_for_ipcp_p): Make function public.
* ipa-icf-gimple.cc: Include alloc-pool.h, symbol-summary.h, sreal.h,
ipa-cp.h and ipa-prop.h.
(func_checker::compare_gimple_call): Comapre jump functions.
Jonathan Wakely [Tue, 2 Apr 2024 21:46:55 +0000 (22:46 +0100)]
libstdc++: Use char for _Utf8_view if char8_t isn't available [PR114519]
Instead of just omitting the definition of __unicode::_Utf8_view when
char8_t is disabled, we can make it use char instead.
libstdc++-v3/ChangeLog:
PR libstdc++/114519
* include/bits/unicode.h (_Utf8_view) [!__cpp_char8_t]: Define
using char instead of char8_t.
* testsuite/ext/unicode/view.cc: Use u8""sv literals to create
string views, instead of std::u8string_view.
Jonathan Wakely [Tue, 2 Apr 2024 20:22:01 +0000 (21:22 +0100)]
libstdc++: Combine two std::from_chars tests into one
We don't need separate tests for the C++17 and C++20 cases, we can just
have one test that uses __cpp_char8_t to adjust whether it tests char8_t
or not. This means the C++20 one doesn't fail if -fno-char8_t is used.
libstdc++-v3/ChangeLog:
* testsuite/20_util/from_chars/1_neg.cc: Add char8_t cases,
using a struct of that name if -fno-char8_t is active.
* testsuite/20_util/from_chars/1_c++20_neg.cc: Removed.
Not sure how this happend, but: svsudot is supposed to be expanded
as USDOT with the operands swapped. However, a thinko in the
expansion of svsudot meant that the arguments weren't in fact
swapped; the attempted swap was just a no-op. And the testcases
blithely accepted that.
gcc/
PR target/114607
* config/aarch64/aarch64-sve-builtins-base.cc
(svusdot_impl::expand): Fix botched attempt to swap the operands
for svsudot.
gcc/testsuite/
PR target/114607
* gcc.target/aarch64/sve/acle/asm/sudot_s32.c: New test.
Tatsuyuki Ishi [Fri, 29 Mar 2024 05:52:39 +0000 (14:52 +0900)]
RISC-V: Implement TLS Descriptors.
This implements TLS Descriptors (TLSDESC) as specified in [1].
The 4-instruction sequence is implemented as a single RTX insn for
simplicity, but this can be revisited later if instruction scheduling or
more flexible RA is desired.
The default remains to be the traditional TLS model, but can be configured
with --with-tls={trad,desc}. The choice can be revisited once toolchain
and libc support ships.
Jakub Jelinek [Mon, 8 Apr 2024 14:22:13 +0000 (16:22 +0200)]
s390: Fix s390_const_int_pool_entry_p and movdi peephole2 [PR114605]
The following testcase is miscompiled, because we have initially
a movti which loads the 0x3f8000003f800000ULL TImode constant
from constant pool. Later on we split it into a pair of DImode
loads. Now, for the first load (why just that?, though not stage4
material) we trigger the peephole2 which uses s390_const_int_pool_entry_p.
That function doesn't check at all the constant pool mode though, sees
the constant pool at that address has a CONST_INT value and just assumes
that is the value to return, which is especially wrong for big-endian,
if it is a DImode load from offset 0, it should be loading 0 rather than
0x3f8000003f800000ULL.
The following patch adds checks if we are extracing a MODE_INT mode,
if the constant pool has MODE_INT mode as well, punts if constant pool
has smaller mode size than the extraction one (then it would be UB),
if it has the same mode as before keeps using what it did before,
if constant pool has a larger mode than the one being extracted, uses
simplify_subreg. I'd have used avoid_constant_pool_reference
instead which can handle also offsets into the constant pool constants,
but it can't handle UNSPEC_LTREF.
Another thing is that once that is fixed, we ICE when we extract constant
like 0, ior insn predicate require non-0 constant. So, the patch also
fixes the peephole2 so that if either 32-bit half is zero, it uses a mere
load of the constant into register rather than a pair of such load and ior.
2024-04-08 Jakub Jelinek <jakub@redhat.com>
PR target/114605
* config/s390/s390.cc (s390_const_int_pool_entry_p): Punt
if mem doesn't have MODE_INT mode, or pool constant doesn't
have MODE_INT mode, or if pool constant mode is smaller than
mem mode. If mem mode is different from pool constant mode,
try to simplify subreg. If that doesn't work, punt, if it
does, use the simplified constant instead of the constant pool
constant.
* config/s390/s390.md (movdi from const pool peephole): If
either low or high 32-bit part is zero, just emit move insn
instead of move + ior.
The test for this intrinsic was failing silently and so it failed to
report the bug reported in 114521. This patch modifes the test to
report the result.
Signed-off-by: Jonathan Swinney <jswinney@amazon.com>
gcc/testsuite/
* gcc.target/aarch64/advsimd-intrinsics/vld1x4.c: Exit with a nonzero
code if the test fails.
Pan Li [Mon, 8 Apr 2024 04:33:05 +0000 (12:33 +0800)]
RISC-V: Refine the error msg for RVV intrinisc required ext
The RVV intrinisc API has sorts of required extension from both
the march or target attribute. It will have error message similar
to below:
built-in function '__riscv_vsetvl_e8m4\(vl\)' requires the V ISA extension
However, it is not accurate as we have many additional sub extenstion
besides v extension. For example, zvbb, zvbk, zvbc ... etc. This patch
would like to refine the error message with a friendly hint for the
required extension. For example as below:
When compile with march=rv64gc and target arch=+v, we will have error
message as below:
error: built-in function '__riscv_vclmul_vv_u64m1(op_1, op_2, vl)'
requires the 'zvbc' ISA extension
Then the end-user will get the point that the *zvbc* extension is missing
for the intrinisc API easily.
The below tests are passed for this patch.
* The riscv fully regression tests.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-shapes.cc (build_one): Pass
required_ext arg when invoke add function.
(build_th_loadstore): Ditto.
(struct vcreate_def): Ditto.
(struct read_vl_def): Ditto.
(struct vlenb_def): Ditto.
* config/riscv/riscv-vector-builtins.cc (function_builder::add_function):
Introduce new arg required_ext to fill in the register func.
(function_builder::add_unique_function): Ditto.
(function_builder::add_overloaded_function): Ditto.
(expand_builtin): Leverage required_extensions_specified to
check if the required extension is provided.
* config/riscv/riscv-vector-builtins.h (reqired_ext_to_isa_name): New
func impl to convert the required_ext enum to the extension name.
(required_extensions_specified): New func impl to predicate if
the required extension is well feeded.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-7.c: Adjust
the error message for v extension.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-8.c: Ditto.
* gcc.target/riscv/rvv/base/intrinsic_required_ext-1.c: New test.
* gcc.target/riscv/rvv/base/intrinsic_required_ext-10.c: New test.
* gcc.target/riscv/rvv/base/intrinsic_required_ext-2.c: New test.
* gcc.target/riscv/rvv/base/intrinsic_required_ext-3.c: New test.
* gcc.target/riscv/rvv/base/intrinsic_required_ext-4.c: New test.
* gcc.target/riscv/rvv/base/intrinsic_required_ext-5.c: New test.
* gcc.target/riscv/rvv/base/intrinsic_required_ext-6.c: New test.
* gcc.target/riscv/rvv/base/intrinsic_required_ext-7.c: New test.
* gcc.target/riscv/rvv/base/intrinsic_required_ext-8.c: New test.
* gcc.target/riscv/rvv/base/intrinsic_required_ext-9.c: New test.
Pan Li [Tue, 2 Apr 2024 14:22:29 +0000 (22:22 +0800)]
RISC-V: Allow RVV intrinsic for more function target
In previous, we allowed the target(("arch=+v")) for a function with
rv64gc build. This patch would like to support more arch options as
below:
* zve32x
* zve32f
* zve64x
* zve64f
* zve64d
* zvfhmin
* zvfh
* zvk*
* zvbb
For example, we have sample code as below.
vfloat32m1_t
__attribute__((target("arch=+zve64f")))
test_9 (vfloat32m1_t a, vfloat32m1_t b, size_t vl)
{
return __riscv_vfadd_vv_f32m1 (a, b, vl);
}
It will generate the asm code when build with -O3 -march=rv64gc
test_9:
vsetvli zero,a0,e32,m1,ta,ma
vfadd.vv v8,v8,v9
ret
Meanwhile, this patch introduces more error handling for the target
attribute. Take arch=+zve32x with vfloat32m1_t will have error message
"'vfloat32m1_t' requires the zve32f, zve64f or zve64d ISA extension".
And take arch=+zve32f with vfloat16m1_t will have error message
"'vfloat16m1_t' requires the zvfhmin or zvfh ISA extension".
By default, all the RVV types includes the cmdline march will be
registered when include the riscv_vector.h. And we have sorts of check
during args and return types.
Below test are passed for this patch:
* The riscv fully regression test.
gcc/ChangeLog:
* config/riscv/riscv-c.cc (struct pragma_intrinsic_flags): New
struct to hold all intrinisc related flags.
(riscv_pragma_intrinsic_flags_pollute): New func to pollute
the intrinsic flags and backup original flags.
(riscv_pragma_intrinsic_flags_restore): New func to restore
the flags from the backup intrinsic flags.
(riscv_pragma_intrinsic): Pollute the flags and register all
possible builtin types and functions, then restore and reinit.
* config/riscv/riscv-protos.h (reinit_builtins): New func
decl to reinit after flags pollution.
(riscv_option_override): New extern func decl.
* config/riscv/riscv-vector-builtins.cc (register_builtin_types_on_null):
New func to register builtin types if null.
(DEF_RVV_TYPE): Ditto.
(DEF_RVV_TUPLE_TYPE): Ditto.
(reinit_builtins): New func impl to reinit after flags pollution.
(expand_builtin): Return
target rtx after error_at.
* config/riscv/riscv.cc (riscv_vector_int_type_p): New predicate
func to tell one tree type is integer or not.
(riscv_vector_float_type_p): New predicate func to tell one tree
type is float or not.
(riscv_vector_element_bitsize): New func to get the element bitsize
of a vector tree type.
(riscv_vector_required_min_vlen): New func to get the required min vlen
of a vector tree type.
(riscv_validate_vector_type): New func to validate the tree type
is valid on flags.
(riscv_return_value_is_vector_type_p): Leverage the func
riscv_validate_vector_type to do the tree type validation.
(riscv_arguments_is_vector_type_p): Ditto.
(riscv_override_options_internal): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr109479-1.c: Adjust the existing test
scenarios and add new error check tests.
* gcc.target/riscv/rvv/base/pr109479-2.c: Ditto.
* gcc.target/riscv/rvv/base/pr109479-3.c: Ditto.
* gcc.target/riscv/rvv/base/pr109479-4.c: Diito.
* gcc.target/riscv/rvv/base/pr109479-5.c: Diito.
* gcc.target/riscv/rvv/base/pr109479-6.c: Diito.
* gcc.target/riscv/rvv/base/user-10.c: Ditto.
* gcc.target/riscv/rvv/base/user-12.c: Ditto.
* gcc.target/riscv/rvv/base/user-13.c: Ditto.
* gcc.target/riscv/rvv/base/user-14.c: Ditto.
* gcc.target/riscv/rvv/base/user-15.c: Ditto.
* gcc.target/riscv/rvv/base/user-2.c: Ditto.
* gcc.target/riscv/rvv/base/user-3.c: Ditto.
* gcc.target/riscv/rvv/base/user-5.c: Ditto.
* gcc.target/riscv/rvv/base/user-6.c: Ditto.
* gcc.target/riscv/rvv/base/user-9.c: Ditto.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-10.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-11.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-12.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-13.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-14.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-15.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-16.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-17.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-18.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-19.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-20.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-21.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-22.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-23.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-24.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-25.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-26.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-27.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-28.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-29.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-30.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-31.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-32.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-33.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-34.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-35.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-36.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-37.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-38.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-39.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-40.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-41.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-42.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-43.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-44.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-45.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-46.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-47.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-48.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-49.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-50.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-51.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-52.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-53.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-9.c: New test.
LoongArch: Set default alignment for functions jumps and loops [PR112919].
Xi Ruoyao set the alignment rules under LA464 in commit r14-1839,
but the macro ASM_OUTPUT_ALIGN_WITH_NOP was removed in R14-4674,
which affected the alignment rules.
So I set different aligns on LA464 and LA664 again to test the
performance of spec2006, and modify the alignment based on the test
results.
gcc/ChangeLog:
PR target/112919
* config/loongarch/loongarch-def.cc (la664_align): Newly defined
function that sets alignment rules under the LA664 microarchitecture.
* config/loongarch/loongarch-opts.cc
(loongarch_target_option_override): If not optimizing for size, set
the default alignment to what the target wants.
* config/loongarch/loongarch-tune.h (struct loongarch_align): Add
new member variables jump and loop.
Gaius Mulley [Sat, 6 Apr 2024 22:45:35 +0000 (23:45 +0100)]
PR modula2/114617 gm2 unable to resolve const expressions using relop ICE
This patch allows cc1gm2 to resolve constant expressions which use
relative operators. Previous to the patch the result of a relop
was stored in a temporary variable set by an if then else quadruple
sequence. This patch marks a const expression in the quadruples
and then reduces this sequence of quadruples into a single
assignment to an internal constant.
gcc/m2/ChangeLog:
PR modula2/114617
* gm2-compiler/M2GenGCC.mod (CodeStatememt): Add quad trace.
(ResolveConstantExpressions): Add parameter p to FoldIfLess,
FoldIfGre, FoldIfLessEqu, FoldIfGreEqu, FoldIfEqu, FoldIfNotEqu,
FoldIfIn and FoldIfNotIn.
(CodeInline): Add constExpr variable and pass it to GetQuadOtok.
(CodeReturnValue): Ditto.
(CodeParam): Ditto.
(FoldStringLength): Ditto.
(FoldStringConvertM2nul): Ditto.
(FoldStringConvertCnul): Ditto.
(DeclaredOperandsBecomes): Ditto.
(TypeCheckBecomes): Ditto.
(PerformFoldBecomes): Ditto.
(CodeBecomes): Ditto.
(CheckElementSetTypes): Ditto.
(CodeBinarySet): Ditto.
(PerformCodeIfLess): Ditto.
(PerformCodeIfGre): Ditto.
(PerformCodeIfLessEqu): Ditto.
(PerformCodeIfGreEqu): Ditto.
(PerformCodeIfEqu): Ditto.
(PerformCodeIfNotEqu): Ditto.
(IsValidExpressionRelOp): Ditto.
(PerformCodeIfIn): Ditto.
(PerformCodeIfNotIn): Ditto.
(CodeXIndr): Ditto.
(QuadCondition): New procedure function.
(IsBooleanRelOpPattern): Ditto.
(FoldBooleanRelopPattern): Ditto.
(FoldIfGre): Check for boolean relop constant expression and
add parameter p.
(FoldIfLessEqu): Ditto.
(FoldIfIn): Ditto.
(FoldIfEqu): Ditto.
(FoldIfNotIn): Ditto.
(FoldIfGreEqu): New procedure.
(FoldIfNotEqu): Ditto.
* gm2-compiler/M2Optimize.mod (ReduceBranch): Add constExpr
variable and pass it to GetQuadOtok.
* gm2-compiler/M2Quads.def (IsBecomes): New procedure function.
(IsDummy): Ditto.
(IsQuadConstExpr): Ditto.
(SetQuadConstExpr): Ditto.
(GetQuadDest): New procedure.
(GetQuadOp1): New procedure.
(GetQuadOp2): New procedure.
(GetQuadOp3): New procedure.
(GetQuadOtok): New procedure.
(GetQuadOTypetok): New procedure.
(PutQuadOtok): New procedure.
(IsInConstParameters): New procedure function.
* gm2-compiler/M2Quads.mod (IsBecomes): New procedure function.
(IsDummy): Ditto.
(IsQuadConstExpr): Ditto.
(SetQuadConstExpr): Ditto.
(GetQuadDest): New procedure.
(GetQuadOp1): New procedure.
(GetQuadOp2): New procedure.
(GetQuadOp3): New procedure.
(GetQuadOtok): New procedure.
(GetQuadOTypetok): New procedure.
(PutQuadOtok): New procedure.
(IsInConstParameters): New procedure function.
(ConstStack): Remove to ...
(ConstExprStack): ... this.
(ConstParamStack): New variable and initialize.
(QuadFrame): New field ConstExpr.
(GetQuadOtok): Add parameter constExpr and assign.
(PutQuadOtok): Add constExpr parameter and assign.
(PutQuadOType): Ditto.
(GetQuadOTypetok): Ditto.
(EraseQuad): Assign ConstExpr to FALSE.
(FoldSubrange): Set ConstExpr to FALSE in BecomesOp.
(PushInConstParameters): New procedure.
(PopInConstParameters): New procedure.
(IsInConstParameters): New procedure function.
* gm2-compiler/M2SymInit.mod (IssueConditional): Add
constExpr boolean variable.
(CheckReadBeforeInitQuad): Ditto.
(trashParam): Ditto.
* gm2-compiler/P3Build.bnf (ConstExpression): Call
PushInConstExpression and PopInConstExpression.
(ConstSetOrQualidentOrFunction): Call
PushInConstParameters and PopInConstParameters.
* gm2-compiler/PCBuild.bnf (ConstExpression): Call
PushInConstExpression and PopInConstExpression.
* gm2-compiler/PHBuild.bnf: Ditto
* gm2-gcc/m2expr.cc (m2expr_BuildCondIfExpression): New
function.
* gm2-gcc/m2expr.def (BuildCondIfExpression): New prototype.
* gm2-gcc/m2expr.h (m2expr_BuildCondIfExpression): New function.
gcc/testsuite/ChangeLog:
PR modula2/114617
* gm2/iso/const/pass/iso-const-pass.exp: New test.
Jerry DeLisle [Sat, 6 Apr 2024 02:25:13 +0000 (19:25 -0700)]
libfortran: Fix handling of formatted separators.
PR libfortran/114304
PR libfortran/105473
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Add logic to handle spaces
preceding a comma or semicolon such that that a 'null' read
occurs without error at the end of comma or semicolon
terminated input lines. Add check and error message for ';'.
(list_formatted_read_scalar): Treat comma as a decimal point
when specified by the decimal mode on the first item.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105473.f90: Modify to verify new error message.
* gfortran.dg/pr114304.f90: New test.
H.J. Lu [Fri, 5 Apr 2024 15:56:15 +0000 (08:56 -0700)]
x86: Use explicit shift count in double-precision shifts
Don't use implicit shift count in double-precision shifts in AT&T syntax
since they aren't in Intel SDM. Keep the 's' modifier for backward
compatibility with inline asm statements.
When a function is tree-inlined, copy the condition -> expression mapping
from the inlined function into the caller, shifted so uids are not
mixed. Tree inlining was always problematic under condition coverage -
either through a nullptr dereference (triggered by the test case), or
through quietly mixing caller conditions with the callee conditions.
The __sigsetjmp test was added as a regression test in an early
iteration of the MC/DC support, as it caused an internal compiler error.
This was triggered by a code path which did not make it through to the
final revision. Since this test really only worked on systems with
__sigsetjmp, and does not serve a purpose any more it can be removed.
David Malcolm [Fri, 5 Apr 2024 18:49:53 +0000 (14:49 -0400)]
analyzer: respect GCC_COLORS in out-of-bounds diagrams [PR114588]
gcc/analyzer/ChangeLog:
PR analyzer/114588
* access-diagram.cc (access_diagram_impl::access_diagram_impl):
Replace hardcoded colors for valid_style and invalid_style with
calls to text_art::get_style_from_color_cap_name.
gcc/ChangeLog:
PR analyzer/114588
* diagnostic-color.cc (color_dict): Add "valid" and "invalid" as
color capability names.
* doc/invoke.texi: Document them in description of GCC_COLORS.
* text-art/style.cc: Include "diagnostic-color.h".
(text_art::get_style_from_color_cap_name): New.
* text-art/types.h (get_style_from_color_cap_name): New decl.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Martin Jambor [Fri, 5 Apr 2024 16:18:39 +0000 (18:18 +0200)]
ipa: Force args obtined through pass-through maps to the expected type (PR 113964)
Interactions of IPA-CP and IPA-SRA on the same data is a rather big
source of issues, I'm afraid. PR 113964 is a situation where IPA-CP
propagates an unsigned short in a union parameter into a function
which itself calls a different function which has a same union
parameter and both these union parameters are split with IPA-SRA. The
leaf function however uses a signed short member of the union.
In the calling function, we get the unsigned constant as the
replacement for the union and it is then passed in the call without
any type compatibility checks. Apparently on riscv64 it matters
whether the parameter is signed or unsigned short and so the leaf
function can see different values.
Fixed by using useless_type_conversion_p at the appropriate place and
if it fails, use force_value_to type as elsewhere in similar
situations.
gcc/ChangeLog:
2024-04-04 Martin Jambor <mjambor@suse.cz>
PR ipa/113964
* ipa-param-manipulation.cc (ipa_param_adjustments::modify_call):
Force values obtined through pass-through maps to the expected
split type.
gcc/testsuite/ChangeLog:
2024-04-04 Patrick O'Neill <patrick@rivosinc.com>
Martin Jambor <mjambor@suse.cz>
Mark Wielaard [Fri, 5 Apr 2024 15:22:16 +0000 (17:22 +0200)]
Regenerate common.opt.urls
The new support for gcov modified condition/decision coverage
introduced two new flags for gcc, -Wcoverage-too-many-conditions and
-fcondition-coverage. But didn't regenerate the gcc/common.opt.urls.
But this is only valid if pa.T is a ptrue. In other cases, the
original would set inactive elements of zd.T to 0, whereas the
combined form would copy elements from zc.T.
gcc/
PR target/114603
* config/aarch64/aarch64-sve.md (@aarch64_pred_cnot<mode>): Replace
with...
(@aarch64_ptrue_cnot<mode>): ...this, requiring operand 1 to be
a ptrue.
(*cnot<mode>): Require operand 1 to be a ptrue.
* config/aarch64/aarch64-sve-builtins-base.cc (svcnot_impl::expand):
Use aarch64_ptrue_cnot<mode> for _x operations that are predicated
with a ptrue. Represent other _x operations as fully-defined _m
operations.
gcc/testsuite/
PR target/114603
* gcc.target/aarch64/sve/acle/general/cnot_1.c: New test.
Marek Polacek [Tue, 2 Apr 2024 16:59:38 +0000 (12:59 -0400)]
c++: constexpr error with fn redecl in local scope [PR111132]
We evaluate constexpr functions on the original, pre-genericization bodies.
That means that the function body we're evaluating will not have gone
through cp_genericize_r's "Map block scope extern declarations to visible
declarations with the same name and type in outer scopes if any". Here:
it means that we:
1) register_constexpr_fundef (#1)
2) cp_genericize (#1)
nothing interesting happens
3) register_constexpr_fundef (foo)
does copy_fn, so we have two copies of the BIND_EXPR
4) cp_genericize (foo)
this remaps #2 to #1, but only on one copy of the BIND_EXPR
5) retrieve_constexpr_fundef (foo)
we find it, no problem
6) retrieve_constexpr_fundef (#2)
and here #2 isn't found in constexpr_fundef_table, because
we're working on the BIND_EXPR copy where #2 wasn't mapped to #1
so we fail. We've only registered #1.
It should work to use DECL_LOCAL_DECL_ALIAS (which used to be
extern_decl_map). We evaluate constexpr functions on pre-cp_fold
bodies to avoid diagnostic problems, but the remapping I'm proposing
should not interfere with diagnostics.
This is not a problem for a global scope redeclaration; there we go
through duplicate_decls which keeps the DECL_UID:
DECL_UID (olddecl) = olddecl_uid;
and DECL_UID is what constexpr_fundef_hasher::hash uses.
PR c++/111132
gcc/cp/ChangeLog:
* constexpr.cc (get_function_named_in_call): Use
cp_get_fndecl_from_callee.
* cvt.cc (cp_get_fndecl_from_callee): If there's a
DECL_LOCAL_DECL_ALIAS, use it.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-redeclaration3.C: New test.
* g++.dg/cpp0x/constexpr-redeclaration4.C: New test.
Jakub Jelinek [Fri, 5 Apr 2024 12:56:14 +0000 (14:56 +0200)]
vect: Don't clear base_misaligned in update_epilogue_loop_vinfo [PR114566]
The following testcase is miscompiled, because in the vectorized
epilogue the vectorizer assumes it can use aligned loads/stores
(if the base decl gets alignment increased), but it actually doesn't
increase that.
This is because r10-4203-g97c1460367 added the hunk following
patch removes. The explanation feels reasonable, but actually it
is not true as the testcase proves.
The thing is, we vectorize the main loop with 64-byte vectors
and the corresponding data refs have base_alignment 16 (the
a array has DECL_ALIGN 128) and offset_alignment 32. Now, because
of the offset_alignment 32 rather than 64, we need to use unaligned
loads/stores in the main loop (and ditto in the first load/store
in vectorized epilogue). But the second load/store in the vectorized
epilogue uses only 32-byte vectors and because it is a multiple
of offset_alignment, it checks if we could increase alignment of the
a VAR_DECL, the function returns true, sets base_misaligned = true
and says the access is then aligned.
But when update_epilogue_loop_vinfo clears base_misaligned with the
assumption that the var had to have the alignment increased already,
the update of DECL_ALIGN doesn't happen anymore.
Now, I'd think this base_alignment = false was needed before r10-4030-gd2db7f7901 change was committed where it incorrectly
overwrote DECL_ALIGN even if it was already larger, rather than
just always increasing it. But with that change in, it doesn't
make sense to me anymore.
Note, the testcase is latent on the trunk, but reproduces on the 13
branch.
[-PASS:-]{+FAIL:+} libgomp.c/reverse-offload-sm30.c at line 15 (test for warnings, line )
[-PASS:-]{+FAIL:+} libgomp.c/reverse-offload-sm30.c (test for excess errors)
libgomp/
* testsuite/libgomp.c/reverse-offload-sm30.c: Set 'GCC_COLORS' to the empty string.
Jakub Jelinek [Fri, 5 Apr 2024 09:05:01 +0000 (11:05 +0200)]
testsuite: Fix up error on gcov1.d
On Fri, Feb 23, 2024 at 12:18:00PM +0100, Jørgen Kvalsvik wrote:
> This is a mostly straight port from the gcov-19.c tests from the C test
> suite. The only notable differences from C to D are that D flips the
> true/false outcomes for loop headers, and the D front end ties loop and
> ternary conditions to slightly different locus.
>
> The test for >64 conditions warning is disabled as it either needs
> support from the testing framework or a something similar to #pragma GCC
> diagnostic push to not cause a test failure from detecting a warning.
>
> gcc/testsuite/ChangeLog:
>
> * gdc.dg/gcov.exp: New test.
> * gdc.dg/gcov1.d: New test.
Unfortunately, this doesn't work.
I see
PASS: gdc.dg/gcov1.d execution test
ERROR: (DejaGnu) proc "run-gcov conditions { --conditions gcov1.d }" does not exist.
The error code is TCL LOOKUP COMMAND run-gcov
The info on the error is:
invalid command name "run-gcov"
while executing
"::tcl_unknown run-gcov conditions { --conditions gcov1.d }"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::tcl_unknown $args"
ERROR: gdc.dg/gcov1.d : error executing dg-final: invalid command name "run-gcov"
both on x86_64-linux and i686-linux.
The problem is that the test hasn't been added to a new directory, but
to a directory already covered by a different *.exp file - dg.exp.
Now, usually either one has a test directory like gcc.misc-tests where
there are many *.exp files but each *.exp file globs for its own tests,
or there is one *.exp per directory and covers everything in there.
By having both dg.exp and gcov.exp in the same directory with dg.exp
covering all *.d files in there and gcov gcov*.d in there, the gcov*.d
tests are tested twice, once using the dg.exp driver and once using gcov.exp
driver. With the latter, they do work properly, with the former they don't
because gcov.exp lib file isn't loaded and so run-gcov isn't available.
The following patch fixes that similarly how g++.dg/modules/modules.exp,
gcc.target/s390/s390.exp or gcc.target/i386/i386.exp deal with that,
by pruning some tests based on glob patterns from the list.
2024-04-05 Jakub Jelinek <jakub@redhat.com>
* gdc.dg/dg.exp: Prune gcov*.d from the list of tests to run.
* gdc.dg/gcov.exp: Update copyright years.
Jakub Jelinek [Fri, 5 Apr 2024 07:31:28 +0000 (09:31 +0200)]
c++: Fix ICE with weird copy assignment operator [PR114572]
While ctors/dtors don't return anything (undeclared void or this pointer
on arm) and copy assignment operators normally return a reference to *this,
it isn't invalid to return uselessly some class object which might need
destructing, but the OpenMP clause handling code wasn't expecting that.
The following patch fixes that.
2024-04-05 Jakub Jelinek <jakub@redhat.com>
PR c++/114572
* cp-gimplify.cc (cxx_omp_clause_apply_fn): Call build_cplus_new
on build_call_a result if it has class type.
testsuite/gcc.target/cris/pr93372-2.c: Handle xpass from combine improvement
After r14-9692-g839bc42772ba7a, a sequence that actually
looks optimal is now emitted, observed at r14-9788-gb7bd2ec73d66f7. This caused an XPASS for this
test. While adjusting the test, better also guard it
against regressions by checking that there are no redundant
move insns.
That's the only test that's improved to the point of
affecting test-patterns. E.g. pr93372-5.c (which references
pr93372-2.c) is also improved, though it retains a redundant
compare insn. (PR 93372 was about regressions from the cc0
representation; not further improvement like here, thus it's
not tagged. Though, I did not double-check whether this
actually *was* a regression from cc0.)
* gcc.target/cris/pr93372-2.c: Tweak scan-assembler
checks to cover recent combine improvement.
Wilco Dijkstra [Tue, 26 Mar 2024 15:08:02 +0000 (15:08 +0000)]
libatomic: Fix build for --disable-gnu-indirect-function [PR113986]
Fix libatomic build to support --disable-gnu-indirect-function on AArch64.
Always build atomic_16.S, add aliases to the __atomic_ functions if !HAVE_IFUNC.
Include auto-config.h in atomic_16.S to avoid having to pass defines via
makefiles. Fix build if HWCAP_ATOMICS/CPUID are not defined.
libatomic:
PR target/113986
* Makefile.in: Regenerated.
* Makefile.am: Make atomic_16.S not depend on HAVE_IFUNC.
Remove predefine of HAVE_FEAT_LSE128.
* acinclude.m4: Remove ARCH_AARCH64_HAVE_LSE128.
* configure: Regenerated.
* config/linux/aarch64/atomic_16.S: Add __atomic_ alias if !HAVE_IFUNC.
* config/linux/aarch64/host-config.h: Correctly handle !HAVE_IFUNC.
Add defines for HWCAP_ATOMICS and HWCAP_CPUID.
Martin Jambor [Thu, 4 Apr 2024 20:46:16 +0000 (22:46 +0200)]
ipa: Avoid duplicate replacements in IPA-SRA transformation phase
When the analysis part of IPA-SRA figures out that it would split out
a scalar part of an aggregate which is known by IPA-CP to contain a
known constant, it skips it knowing that the transformation part looks
at IPA-CP aggregate results too and does the right thing (which can
include doing the propagation in GIMPLE because that is the last
moment the parameter exists).
However, when IPA-SRA wants to split out a smaller aggregate out
of an aggregate, which happens to be of the same size as a known
scalar constant at the same offset, the transformation bit fails to
recognize the situation, tries to do both splitting and constant
propagation and in PR 111571 testcase creates a nonsensical call
statement on which the call redirection then ICEs.
Fixed by making sure we don't try to do two replacements of the same
part of the same parameter.
The look-up among replacements requires these are sorted and this
patch just sorts them if they are not already sorted before each new
look-up. The worst number of sortings that can happen is number of
parameters which are both split and have aggregate constants times
param_ipa_max_agg_items (default 16). I don't think complicating the
source code to optimize for this unlikely case is worth it but if need
be, it can of course be done.
git://gcc.gnu.org / gcc.git / log