Paul Thomas [Wed, 27 Jan 2021 11:34:02 +0000 (11:34 +0000)]
Fortran: Fix ICE due to elemental procedure pointers [PR93924/5].
2021-01-27 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/93924
PR fortran/93925
* trans-expr.c (gfc_conv_procedure_call): Suppress the call to
gfc_conv_intrinsic_to_class for unlimited polymorphic procedure
pointers.
(gfc_trans_assignment_1): Similarly suppress class assignment
for class valued procedure pointers.
gcc/testsuite/
PR fortran/93924
PR fortran/93925
* gfortran.dg/proc_ptr_52.f90 : New test.
gcc/fortran
PR fortran/93794
* trans-expr.c (gfc_conv_component_ref): Remove the condition
that deferred character length components only be allocatable.
gcc/testsuite/
PR fortran/93794
* gfortran.dg/deferred_character_35.f90 : New test.
Thomas Schwinge [Fri, 27 Aug 2021 05:49:35 +0000 (07:49 +0200)]
Fix 'OMP_CLAUSE_TILE' operands handling in 'gcc/tree.c:walk_tree_1'
In r245300 (commit 02889d23ee3b02854dff203dd87b9a25e30b61b4)
"OpenACC tile clause support" that one had changed to three operands,
similar to 'OMP_CLAUSE_COLLAPSE'.
There is no (existing) test case where this seems to matter (likewise
for 'OMP_CLAUSE_COLLAPSE'), but it's good to be consistent.
gcc/
* tree.c (walk_tree_1) <OMP_CLAUSE_TILE>: Handle three operands.
Quoting from https://gcc.gnu.org/pipermail/gcc/2021-July/236716.html:
--------------------------------------------------------------------
It was pointed out to me off-list that config/aarch64/value-unwind.h
is missing the runtime exception. It looks like a few other files
are too; a fuller list is:
Certainly for the aarch64 file this was simply a mistake;
it seems to have been copied from the i386 version, both of which
reference the runtime exception but don't actually include it.
--------------------------------------------------------------------
Similarly, frv-abi.h referenced the exception but didn't include it.
pa64-hpux-lib.h was missing any reference to the exception.
The decision was that this was simply a mistake
[https://gcc.gnu.org/pipermail/gcc/2021-July/236717.html]:
--------------------------------------------------------------------
[…] It generally is
considered a textual omission. The runtime library components of GCC
are intended to be licensed under the runtime exception, which was
granted and approved at the time of introduction.
--------------------------------------------------------------------
and that we should simply change all of the files above
[https://gcc.gnu.org/pipermail/gcc/2021-July/236719.html]:
--------------------------------------------------------------------
Please correct the text in the files. The files in libgcc used in the
GCC runtime are intended to be licensed with the runtime exception and
GCC previously was granted approval for that licensing and purpose.
[…]
The runtime exception explicitly was intended for this purpose and
usage at the time that GCC received approval to apply the exception.
--------------------------------------------------------------------
A change to the way gas interprets the .fpu directive in binutils-2.34
means that issuing .fpu will clear any features set by .arch_extension
that apply to the floating point or simd units. This unfortunately
causes problems for more recent versions of the architecture because
we currently emit .arch, .arch_extension and .fpu directives at
different times and try to suppress redundant changes.
This change addresses this by firstly unifying all the places where we
emit these directives to a single block of code and secondly
(re)emitting all the directives if any changes have been made to the
target options. Whilst this is slightly more than the strict minimum
it should be enough to catch all cases where a change could have
happened. The new code also emits the directives in the order: .arch,
.fpu, .arch_extension. This ensures that the additional architectural
extensions are not removed by a later .fpu directive.
Whilst writing this patch I also noticed that in the corner case where
the last function to be compiled had a non-standard set of
architecture flags, the assembler would add an incorrect set of
derived attributes for the file as a whole. Instead of reflecting the
command-line options it would reflect the flags from the last file in
the function. To address this I've also added a call to re-emit the
flags from the asm_file_end callback so the assembler will be in the
correct state when it finishes processing the intput.
There's some slight churn to the testsuite as a consequence of this,
because previously we had a hack to suppress emitting a .fpu directive
for one specific case, but with the new order this is no-longer
necessary.
gcc/ChangeLog:
PR target/101723
* config/arm/arm-cpus.in (quirk_no_asmcpu): New feature bit.
(ALL_QUIRKS): Add it.
(generic-armv7-a): Add quirk to suppress writing .cpu directive in
asm output.
* config/arm/arm.c (arm_identify_fpu_from_isa): New variable.
(arm_last_printed_arch_string): Delete.
(arm_last-printed_fpu_string): Delete.
(arm_configure_build_target): If use of floating-point/SIMD is
disabled, remove all fp/simd related features from the target ISA.
(last_arm_targ_options): New variable.
(arm_print_asm_arch_directives): Add new parameters. Change order
of emitted directives and handle all cases here.
(arm_file_start): Always call arm_print_asm_arch_directives, move
all generation of .arch/.arch_extension here.
(arm_file_end): Call arm_print_asm_arch.
(arm_declare_function_name): Call arm_print_asm_arch_directives
instead of printing .arch/.fpu directives directly.
Richard Earnshaw [Tue, 27 Jul 2021 14:44:57 +0000 (15:44 +0100)]
arm: Don't reconfigure globals in arm_configure_build_target
arm_configure_build_target is usually used to reconfigure the
arm_active_target structure, which is then used to reconfigure a
number of other global variables describing the current target.
Occasionally, however, we need to use arm_configure_build_target to
construct a temporary target structure and in that case it is wrong to
try to reconfigure the global variables (although probably harmless,
since arm_option_reconfigure_globals() only looks at
arm_active_target). At the very least, however, this is wasted work,
so it is best not to do it unless needed. What's more, several
callers of arm_configure_build target call
arm_option_reconfigure_globals themselves within a few lines, making
the call from within arm_configure_build_target completely redundant.
So this patch moves the responsibility of calling of
arm_configure_build_target to its callers (only two places needed
updating).
gcc:
* config/arm/arm.c (arm_configure_build_target): Don't call
arm_option_reconfigure_globals.
(arm_option_restore): Call arm_option_reconfigure_globals after
reconfiguring the target.
* config/arm/arm-c.c (arm_pragma_target_parse): Likewise.
(cherry picked from commit 6a37d0331c25f23628d4308e5a75624005c223b2)
Richard Earnshaw [Mon, 26 Jul 2021 16:07:14 +0000 (17:07 +0100)]
arm: ensure the arch_name is always set for the build target
This should never happen now if GCC is invoked by the driver, but in
the unusual case of calling cc1 (or its ilk) directly from the command
line the build target's arch_name string can remain NULL. This can
complicate later processing meaning that we need to check for this
case explicitly in some circumstances. Nothing should rely on this
behaviour, so it's simpler to always set the arch_name when
configuring the build target and be done with it.
gcc:
* config/arm/arm.c (arm_configure_build_target): Ensure the target's
arch_name is always set.
Richard Earnshaw [Wed, 11 Dec 2019 11:59:04 +0000 (11:59 +0000)]
arm: Fix an incorrect warning when -mcpu=cortex-a55 is used with -mfloat-abi=soft
When a CPU such as cortex-a55 is used with the soft-float ABI variant,
the compiler is incorrectly issuing a warning about a mismatch between
the architecture (generated internally) and the CPU. This is not
expected or intended.
The problem stems from the fact that we generate (correctly) an
architecture for a soft-float compilation, but then try to compare it
against the one recorded for the CPU. Normally we strip out the
floating point information before doing that comparison, but we
currently only do that for the features that can be affected by the
-mfpu option. For a soft-float environment we also need to strip out
any bits that depend on having floating-point present.
So this patch implements that and does a bit of housekeeping at the
same time:
- in arm-cpus.in it is not necessary for a CPU to specify both
+dotprod and +simd in its architecture specification, since +dotprod
implies +simd.
- I've refactored the ALL_SIMD fgroup in arm-cpus.in to create a new
subgroup ALL_SIMD_EXTERNAL and containing the bits that were
previously added directly to ALL_SIMD. Similarly, I've added an
ALL_FPU_EXTERNAL subgroup.
- in arm.c rename fpu_bitlist and all_fpubits to fpu_bitlist_internal
and all_fpubits_internal for consistency with the fgroup bits which
they contain.
* config/arm/arm-cpus.in (ALL_SIMD_EXTERNAL): New fgroup.
(ALL_SIMD): Use it.
(ALL_FPU_EXTERNAL): New fgroup.
(ALL_FP): Use it.
(cortex-a55, cortex-a75, cortex-a76): Remove redundant
+simd from architecture specification.
(neoverse-n1, cortex-a75.cortex-a55): Likewise.
* config/arm/arm.c (isa_all_fpubits, fpu_bitlist): Rename to ...
(isa_all_fpubits_internal, fpu_bitlist_internal): ... these.
(isa_all_fpbits): New bitmap.
(arm_option_override): Initialize it.
(arm_configure_build_target): If the target isa does not have any
FP enabled, do not warn about mismatches in FP-related feature bits.
Richard Earnshaw [Thu, 27 May 2021 09:25:37 +0000 (10:25 +0100)]
arm: Remove use of opts_set in arm_configure_build_target [PR100767]
The variable global_options_set is a reflection of which options have
been explicitly set from the command line in the structure
global_options. But it doesn't describe the contents of a
cl_target_option. cl_target_option is a set of options to apply and
once configured should represent a viable set of options without
needing to know which were explicitly set by the user.
Unfortunately arm_configure_build_target was incorrectly conflating
the two. Fortunately, however, we do not really need to know this
since the various override_options functions should have sanitized the
target_options values before constructing a cl_target_option
structure. It is safe, therefore, to simply drop this parameter to
arm_configure_build_target and rely on checking that various string
parameters are non-null before dereferencing them.
This patch adds an option to tune for Neoverse cores that have
a total vector bandwidth of 512 bits (4x128 for Advanced SIMD
and a vector-length-dependent equivalent for SVE). This is intended
to be a compromise between tuning aggressively for a single core like
Neoverse V1 (which can be too narrow) and tuning for AArch64 cores
in general (which can be too wide).
-mcpu=neoverse-512tvb is equivalent to -mcpu=neoverse-v1
-mtune=neoverse-512tvb.
gcc/
* doc/invoke.texi: Document -mtune=neoverse-512tvb and
-mcpu=neoverse-512tvb.
* config/aarch64/aarch64-cores.def (neoverse-512tvb): New entry.
* config/aarch64/aarch64-tune.md: Regenerate.
Jonathan Wakely [Wed, 11 Aug 2021 21:11:19 +0000 (22:11 +0100)]
libstdc++: Fix test that fails randomly [PR101866]
This test assumes that the same sequence of three values cannot occur,
which is incorect. It's unlikely, but not impossible.
Perform the check in a loop, so that in the unlikely event of an
identical sequence, we retry. If the library code is buggy it will keep
producing the same sequence and the test will time out. If the code is
working correctly then we will usually break out of the loop after one
iteration, or very rarely after two or three.
libstdc++-v3/ChangeLog:
PR libstdc++/101866
* testsuite/experimental/random/randint.cc: Loop and retry if
reseed() produces the same sequence.
Jonathan Wakely [Tue, 20 Jul 2021 17:15:48 +0000 (18:15 +0100)]
libstdc++: Fix create_directories to resolve symlinks [PR101510]
When filesystem__create_directories checks to see if the path already
exists and resolves to a directory, it uses filesystem::symlink_status,
which means it reports an error if the path is a symlink. It should use
filesystem::status, so that the target directory is detected, and no
error is reported.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/101510
* src/c++17/fs_ops.cc (fs::create_directories): Use status
instead of symlink_status.
* src/filesystem/ops.cc (fs::create_directories): Likewise.
* testsuite/27_io/filesystem/operations/create_directories.cc:
Check symlink to existing directory.
* testsuite/27_io/filesystem/operations/create_directory.cc: Do
not test with symlinks on Windows.
* testsuite/experimental/filesystem/operations/create_directories.cc:
Check symlink to existing directory.
* testsuite/experimental/filesystem/operations/create_directory.cc:
Do not test with symlinks on Windows.
Jonathan Wakely [Tue, 20 Jul 2021 11:35:37 +0000 (12:35 +0100)]
libstdc++: Add more tests for filesystem::create_directory [PR101510]
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/101510
* src/c++17/fs_ops.cc (create_dir): Adjust whitespace.
* testsuite/27_io/filesystem/operations/create_directory.cc:
Test creating directory with name of existing symlink to
directory.
* testsuite/experimental/filesystem/operations/create_directory.cc:
Likewise.
Xi Ruoyao [Fri, 30 Jul 2021 15:44:14 +0000 (23:44 +0800)]
mips: Fix up mips_atomic_assign_expand_fenv [PR94780]
Commit message shamelessly copied from 1777beb6b129 by jakub:
This function, because it is sometimes called even outside of function
bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order
for that to work, when first referenced, the VAR_DECLs need to appear in a
TARGET_EXPR so that during gimplification the var gets the right
DECL_CONTEXT and is added to local decls.
gcc/
PR target/94780
* config/mips/mips.c (mips_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR.
d: Wrong evaluation order of binary expressions (PR101640)
The use of fold_build2 can in some cases swap the order of its operands
if that is the more optimal thing to do. However this breaks semantic
guarantee of left-to-right evaluation in D.
PR d/101640
gcc/d/ChangeLog:
* expr.cc (binary_op): Use build2 instead of fold_build2.
d: Compile-time reflection for supported built-ins (PR101127)
In order to allow user-code to determine whether a back-end builtin is
available without error, LANG_HOOKS_BUILTIN_FUNCTION_EXT_SCOPE has been
defined to delay putting back-end builtin functions until the ISA that
defines them has been declared.
However in D, there is no global namespace. All builtins get pushed
into the `gcc.builtins' module, which is constructed during the semantic
analysis pass, which has already finished by the time target attributes
are evaluated. So builtins are not pushed by the new langhook because
they would be ultimately ignored. Builtins exposed to D code then can
now only be altered by the command-line.
Jonathan Wakely [Thu, 22 Jul 2021 21:26:30 +0000 (22:26 +0100)]
libstdc++: Fix test failure in C++20 mode
Because the container types are ambiguous in this test, the declarations
of the C++20 uniform container erasure function template produce
additional errors. They can be ignored.
libstdc++-v3/ChangeLog:
* testsuite/ext/profile/mutex_extensions_neg.cc: Prune
additional errors in C++20 mode.
Jonathan Wakely [Wed, 14 Apr 2021 19:48:54 +0000 (20:48 +0100)]
libstdc++: Move atomic functions to libsupc++ [PR 96657]
The changes for PR libstdc++/64735 mean that libsupc++ function might
now depend on the __exchange_and_add and __atomic_add functions defined
in config/cpu/*/atomicity.h which is not compiled into libsupc++. This
causes a link failure for some targets when trying to use libsupc++
without the rest of libstdc++.
This patch simply moves the definitions of those functions into
libsupc++ so that they are available there.
libstdc++-v3/ChangeLog:
PR libstdc++/96657
* libsupc++/Makefile.am: Add atomicity.cc here.
* src/c++98/Makefile.am: Remove it from here.
* libsupc++/Makefile.in: Regenerate.
* src/c++98/Makefile.in: Regenerate.
* testsuite/18_support/exception_ptr/96657.cc: New test.
Jonathan Wakely [Thu, 23 Apr 2020 23:54:20 +0000 (00:54 +0100)]
libstdc++: Fix constructor constraints for std::any (PR 90415)
This removes a non-standard extension to std::any which causes errors
for valid code, due to recursive instantiation of a trait that isn't
supposed to be in the constraints.
It also removes some incorrect constraints on the in_place_type<T>
constructors and emplace members, which were preventing creating a
std::any object with another std::any as the contained value.
2020-04-24 Kamlesh Kumar <kamleshbhalui@gmail.com>
Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/90415
PR libstdc++/92156
* include/std/any (any): Rename template parameters for consistency
with the standard.
(any::_Decay): Rename to _Decay_if_not_any.
(any::any(T&&)): Remove is_constructible from constraints. Remove
non-standard overload.
(any::any(in_place_type_t<T>, Args&&...))
(any::any(in_place_type_t<T>, initializer_list<U>, Args&&...))
(any::emplace(Args&&...))
(any::emplace(initializer_list<U>, Args&&...)):
Use decay_t instead of _Decay.
* testsuite/20_util/any/cons/90415.cc: New test.
* testsuite/20_util/any/cons/92156.cc: New Test.
* testsuite/20_util/any/misc/any_cast_neg.cc: Make dg-error directives
more robust.
* testsuite/20_util/any/modifiers/92156.cc: New test.
Jonathan Wakely [Wed, 9 Jun 2021 10:03:15 +0000 (11:03 +0100)]
libstdc++: Fix constraint on std::optional assignment [PR 100982]
libstdc++-v3/ChangeLog:
PR libstdc++/100982
* include/std/optional (optional::operator=(const optional<U>&)):
Fix value category used in is_assignable check.
* testsuite/20_util/optional/assignment/100982.cc: New test.
Bill Schmidt [Mon, 19 Jul 2021 21:14:36 +0000 (16:14 -0500)]
rs6000: Don't let swaps pass break multiply low-part (PR101129)
Backport from mainline.
2021-07-15 Bill Schmidt <wschmidt@linux.ibm.com>
gcc/
PR target/101129
* config/rs6000/rs6000-p8swap.c (has_part_mult): New.
(rs6000_analyze_swaps): Insns containing a subreg of a mult are
not swappable.
git://gcc.gnu.org / gcc.git / log