gcc/testsuite/
* gcc.target/aarch64/advsimd-intrinsics/vld1x3.c: New test for
vld1x3 intrinsics for aarch64.
* gcc.target/aarch64/advsimd-intrinsics/vst1x2.c: New test for
vst1x2 intrinsics for aarch64.
* gcc.target/aarch64/advsimd-intrinsics/vst1x3.c: New test for
vst1x3 intrinsics for aarch64.
This attempts to make is_nothrow_constructible more robust (and
efficient to compile) by not depending on is_constructible. Instead the
__is_constructible intrinsic is used directly. The helper class
__is_nt_constructible_impl which checks whether the construction is
non-throwing now takes a bool template parameter that is substituted by
the result of the instrinsic. This fixes the reported bug by not using
the already-instantiated (and incorrect) value of std::is_constructible.
I don't think it really fixes the problem in general, because
std::is_nothrow_constructible itself could already have been
instantiated in a context where it gives the wrong result. A proper fix
needs to be done in the compiler.
Backported to the gcc-8 and gcc-9 branches to fix PR 96999.
PR libstdc++/94033
* include/std/type_traits (__is_nt_default_constructible_atom): Remove.
(__is_nt_default_constructible_impl): Remove.
(__is_nothrow_default_constructible_impl): Remove.
(__is_nt_constructible_impl): Add bool template parameter. Adjust
partial specializations.
(__is_nothrow_constructible_impl): Replace class template with alias
template.
(is_nothrow_default_constructible): Derive from alias template
__is_nothrow_constructible_impl instead of
__is_nothrow_default_constructible_impl.
* testsuite/20_util/is_nothrow_constructible/94003.cc: New test.
Jonathan Wakely [Thu, 10 Sep 2020 14:49:26 +0000 (15:49 +0100)]
libstdc++: Enable assertions in constexpr string_view members [PR 71960]
There is no longer any reason we can't just use __glibcxx_assert in
constexpr functions. As long as the condition is true, there will be no
call to std::__replacement_assert that would make the function
ineligible for constant evaluation.
Harald Anlauf [Thu, 3 Sep 2020 18:33:14 +0000 (20:33 +0200)]
PR fortran/96890 - Wrong answer with intrinsic IALL
The IALL intrinsic would always return 0 when the DIM and MASK arguments
were present since the initial value of repeated BIT-AND operations was
set to 0 instead of -1.
libgfortran/ChangeLog:
* m4/iall.m4: Initial value for result should be -1.
* generated/iall_i1.c (miall_i1): Generated.
* generated/iall_i16.c (miall_i16): Likewise.
* generated/iall_i2.c (miall_i2): Likewise.
* generated/iall_i4.c (miall_i4): Likewise.
* generated/iall_i8.c (miall_i8): Likewise.
Tamar Christina [Mon, 3 Aug 2020 11:03:17 +0000 (12:03 +0100)]
AArch64: Fix hwasan failure in readline.
My previous fix added an unchecked call to fgets in the new function readline.
fgets can fail when there's an error reading the file in which case it returns
NULL. It also returns NULL when the next character is EOF.
The EOF case is already covered by the existing code but the error case isn't.
This fixes it by returning the empty string on error.
Also I now use strnlen instead of strlen to make sure we never read outside the
buffer.
This was flagged by Matthew Malcomson during his hwasan work.
gcc/ChangeLog:
* config/aarch64/driver-aarch64.c (readline): Check return value fgets.
Tamar Christina [Wed, 8 Jul 2020 13:32:34 +0000 (14:32 +0100)]
AArch64: Add test for -mcpu=native
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/cpunative/aarch64-cpunative.exp: New file.
* gcc.target/aarch64/cpunative/info_0: New test.
* gcc.target/aarch64/cpunative/info_1: New test.
* gcc.target/aarch64/cpunative/info_10: New test.
* gcc.target/aarch64/cpunative/info_11: New test.
* gcc.target/aarch64/cpunative/info_12: New test.
* gcc.target/aarch64/cpunative/info_13: New test.
* gcc.target/aarch64/cpunative/info_14: New test.
* gcc.target/aarch64/cpunative/info_15: New test.
* gcc.target/aarch64/cpunative/info_2: New test.
* gcc.target/aarch64/cpunative/info_3: New test.
* gcc.target/aarch64/cpunative/info_4: New test.
* gcc.target/aarch64/cpunative/info_5: New test.
* gcc.target/aarch64/cpunative/info_6: New test.
* gcc.target/aarch64/cpunative/info_7: New test.
* gcc.target/aarch64/cpunative/info_8: New test.
* gcc.target/aarch64/cpunative/info_9: New test.
* gcc.target/aarch64/cpunative/native_cpu_0.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_1.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_10.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_13.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_14.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_2.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_3.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_4.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_5.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_6.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_7.c: New test.
* gcc.target/aarch64/cpunative/native_cpu_8.c: New test.
Tamar Christina [Fri, 17 Jul 2020 12:10:28 +0000 (13:10 +0100)]
AArch64: Fix bugs in -mcpu=native detection.
This patch fixes a couple of issues in AArch64's -mcpu=native processing:
The buffer used to read the lines from /proc/cpuinfo is 128 bytes long. While
this was enough in the past with the increase in architecture extensions it is
no longer enough. It results in two bugs:
1) No option string longer than 127 characters is correctly parsed. Features
that are supported are silently ignored.
2) It incorrectly enables features that are not present on the machine:
a) It checks for substring matching instead of full word matching. This makes
it incorrectly detect sb support when ssbs is provided instead.
b) Due to the truncation at the 127 char border it also incorrectly enables
features due to the full feature being cut off and the part that is left
accidentally enables something else.
This breaks -mcpu=native detection on some of our newer system.
The patch fixes these issues by reading full lines up to the \n in a string.
This gives us the full feature line. Secondly it creates a set from this string
to:
1) Reduce matching complexity from O(n*m) to O(n*logm).
2) Perform whole word matching instead of substring matching.
To make this code somewhat cleaner I also changed from using char* to using
std::string and std::set.
Note that I have intentionally avoided the use of ifstream and stringstream
to make it easier to backport. I have also not change the substring matching
for the initial line classification as I cannot find a documented cpuinfo format
which leads me to believe there may be kernels out there that require this which
may be why the original code does this.
I also do not want this to break if the kernel adds a new line that is long and
indents the file by two tabs to keep everything aligned. In short I think an
imprecise match is the right thing here.
Test for this is added as the last thing in this series as it requires some
changes to be made to be able to test this.
Kewen Lin [Wed, 12 Aug 2020 09:19:16 +0000 (04:19 -0500)]
testsuite: Add -fno-common to pr82374.c [PR94077]
As the PR comments show, the case gcc.dg/gomp/pr82374.c fails on
Power7 since gcc8. But it passes from gcc10. By looking into
the difference, it's due to that gcc10 sets -fno-common as default,
which makes vectorizer force the alignment and be able to use
aligned vector load/store on those targets which doesn't support
unaligned vector load/store (here it's Power7).
As Jakub suggested in the PR, this patch is to append -fno-common
into dg-options.
Verified with gcc8/gcc9 releases on ppc64-redhat-linux (Power7).
Jakub Jelinek [Mon, 3 Aug 2020 20:55:28 +0000 (22:55 +0200)]
aarch64: Fix up __aarch64_cas16_acq_rel fallback
As mentioned in the PR, the fallback path when LSE is unavailable writes
incorrect registers to the memory if the previous content compares equal
to x0, x1 - it writes copy of x0, x1 from the start of function, but it
should write x2, x3.
2020-08-03 Jakub Jelinek <jakub@redhat.com>
PR target/96402
* config/aarch64/lse.S (__aarch64_cas16_acq_rel): Use x2, x3 instead
of x(tmp0), x(tmp1) in STXP arguments.
Jonathan Wakely [Thu, 12 Mar 2020 17:39:04 +0000 (17:39 +0000)]
libstdc++: Fix FS-dependent filesystem tests
These tests were failing on XFS because it doesn't support setting file
timestamps past 2038, so the expected overflow when reading back a huge
timestamp into a file_time_type didn't happen.
Additionally, the std::filesystem::file_time_type::clock has an
epoch that is out of range of 32-bit time_t so testing times around that
epoch may also fail.
This fixes the tests to give up gracefully if the filesystem doesn't
support times that can't be represented in 32-bit time_t.
Backport from mainline
2020-02-28 Jonathan Wakely <jwakely@redhat.com>
* testsuite/27_io/filesystem/operations/last_write_time.cc: Fixes for
filesystems that silently truncate timestamps.
* testsuite/experimental/filesystem/operations/last_write_time.cc:
Likewise.
This function was unimplemented, simply returning the native format
string instead.
PR libstdc++/93245
* include/experimental/bits/fs_path.h (path::generic_string<C,T,A>()):
Return the generic format not the native format.
* testsuite/experimental/filesystem/path/generic/generic_string.cc:
Improve test coverage.
It's not possible to construct a path::string_type from an allocator of
a different type. Create the correct specialization of basic_string, and
adjust path::_S_str_convert to use a basic_string_view so that it is
independent of the allocator type.
PR libstdc++/94242
* include/bits/fs_path.h (path::_S_str_convert): Replace first
parameter with basic_string_view so that strings with different
allocators can be accepted.
(path::generic_string<C,T,A>()): Use basic_string object that uses the
right allocator type.
* testsuite/27_io/filesystem/path/generic/94242.cc: New test.
* testsuite/27_io/filesystem/path/generic/generic_string.cc: Improve
test coverage.
Will Schmidt [Mon, 13 Jul 2020 18:38:17 +0000 (13:38 -0500)]
[PATCH] rs6000 improve handling of built-in initialization [PR95952]
Handle a scenario with a combination of old hardware, gcc-8 and
binutils where gcc will ICE during it's selftest. This ICE was exposed
when the builtin processing for better #pragma support was added, where
we no longer skip builtin initialization based on the current mask.
Per the bug report and assorted debug, the ICE occurrs when building
the gcc-8 branch on a 970* based system with an old binutils. (gcc-9 and
newer is OK. binutils 2.34 is reported to allow success).
The attached patch adds a clause to the builtin initialization to skip
initialization of a builtin when the builtin mask is set but the icode
value is zero. The subsequent assert check remains in place.
2020-07-13 Will Schmidt <will_schmidt@vnet.ibm.com>
gcc/ChangeLog:
PR target/95952
* config/rs6000/rs6000.c (altivec_init_builtins): Add continue clause to
predicate builtin handling.
Andreas Krebbel [Wed, 21 Nov 2018 07:48:49 +0000 (07:48 +0000)]
S/390: Support vector load/store alignment hints
The IBM z14 POP adds an optional alignment operand to the vl, vst,
vlm, and vstm instruction (vector loads and stores). Vectors residing
on 8 or 16 byte boundaries might get loaded or stored faster on some
models given the instruction uses the proper hint operand. A wrong
hint will hurt performance though.
The attached testcase align-1 currently fails due to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085
gcc/ChangeLog:
2018-11-21 Andreas Krebbel <krebbel@linux.ibm.com>
* configure.ac: Add check for Binutils to determine whether vector
load/store alignments hints are being supported.
* config.in: Regenerate.
* configure: Regenerate.
* config/s390/s390.c (print_operand): Support new output
modifier A.
* config/s390/s390.md ("movti"): Append alignment hint output
using the new output modifier 'A'.
* config/s390/vector.md ("mov<mode>", "*vec_tf_to_v1tf")
("*vec_ti_to_v1ti"): Likewise.
gcc/testsuite/ChangeLog:
2018-11-21 Andreas Krebbel <krebbel@linux.ibm.com>
* gcc.target/s390/vector/align-1.c: New test.
* gcc.target/s390/vector/align-2.c: New test.
git://gcc.gnu.org / gcc.git / log