Thomas Schwinge [Tue, 13 Oct 2020 12:56:59 +0000 (14:56 +0200)]
More explicit checking of which OMP constructs we're expecting
In particular, more precisely highlight what applies generally vs. the special
handling for the current 'parloops'-based OpenACC 'kernels' implementation.
gcc/
* omp-low.c (scan_sharing_clauses, scan_omp_for)
(lower_oacc_reductions, lower_omp_target): More explicit checking
of which OMP constructs we're expecting.
The expression used to calculate the maximum value for an integer type
assumes that the number of bits in the value representation is always
sizeof(T) * CHAR_BIT. This is not true for the __int20 type on msp430,
which has only 20 bits in the value representation but 32 bits in the
object representation. This causes an integer overflow in a constant
expression, which is ill-formed.
This problem was already solved by DJ for std::numeric_limits<__int20>
by generalizing the helper macros to use a specified number of bits
instead of assuming sizeof(T) * CHAR_BIT. Then the INT_N_n types can
specify the number of bits using the __GLIBCXX_BITSIZE_INT_N_n macros
that the compiler defines.
I'm using a slightly different approach here. I've replaced the helper
macros entirely, and just expanded the calculations in the initializers
for the static data members. By reordering the data members we can reuse
__is_signed and __digits in the other initializers. This removes the
repetition of expanding __glibcxx_signed(T) and __glibcxx_digits(T)
multiple times in each initializer.
The __is_integer_nonstrict trait now defines a new constant, __width,
which is sizeof(T) * CHAR_BIT by default (defined as an enumerator so
that no storage is needed for a static data member). By specializing
__is_integer_nonstrict for the INT_N types that have padding bits, we
can provide the correct width via the __GLIBCXX_BITSIZE_INT_N_n macros.
libstdc++-v3/ChangeLog:
PR libstdc++/97798
* include/ext/numeric_traits.h (__glibcxx_signed)
(__glibcxx_digits, __glibcxx_min, __glibcxx_max): Remove
macros.
(__is_integer_nonstrict::__width): Define new constant.
(__numeric_traits_integer): Define constants in terms of each
other and __is_integer_nonstrict::__width, rather than the
removed macros.
(_GLIBCXX_INT_N_TRAITS): Macro to define explicit
specializations for non-standard integer types.
Jonathan Wakely [Fri, 13 Nov 2020 13:04:10 +0000 (13:04 +0000)]
libstdc++: Fix test that fails for targets without __int128 [PR 96042]
When backporting this test (and the changes it depends on) I forgot that
the __max_diff_type and __max_size_type classes are only present on
trunk, not the gcc-10 branch. That using iota_view<long long, long long>
oonly works correctly when __int128 is available, so the test fails on
32-bit targets.
This just skips the failing check.
PR libstdc++/96042
* testsuite/std/ranges/iota/96042.cc: Only assert that the
difference type is wider than long long if __int128 is
supported.
Peter Bergner [Fri, 6 Nov 2020 23:00:49 +0000 (17:00 -0600)]
rs6000: Fix default alignment ABI break caused by MMA base support
As part of the MMA base support, we incremented BIGGEST_ALIGNMENT in
order to align the __vector_pair and __vector_quad types to 256 and 512
bytes respectively. This had the unintended effect of changing the
default alignment used by __attribute__ ((__aligned__)) which causes
an ABI break because of some dodgy code in GLIBC's struct pthread.
The fix is to revert the BIGGEST_ALIGNMENT change and to force the
alignment on the type itself rather than the mode used by the type.
2020-11-06 Peter Bergner <bergner@linux.ibm.com>
gcc/
* config/rs6000/rs6000.h (BIGGEST_ALIGNMENT): Revert previous commit
so as not to break the ABI.
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Set the ABI
mandated alignment for __vector_pair and __vector_quad types.
gcc/testsuite/
* gcc.target/powerpc/mma-alignment.c: New test.
Tobias Burnus [Tue, 10 Nov 2020 09:31:33 +0000 (10:31 +0100)]
Fortran: Fix function decl's location [PR95847]
gcc/fortran/ChangeLog:
PR fortran/95847
* trans-decl.c (gfc_get_symbol_decl): Do not (re)set the location
of an external procedure.
(build_entry_thunks, generate_coarray_init, create_main_function,
gfc_generate_function_code): Use fndecl's location in BIND_EXPR.
gcc/testsuite/ChangeLog:
PR fortran/95847
* gfortran.dg/coverage.f90: New test.
Jonathan Wakely [Thu, 20 Aug 2020 18:41:15 +0000 (19:41 +0100)]
libstdc++: Make incrementable<__int128> satisfied in strict mode
This adds specializations of std::incrementable_traits so that 128-bit
integers are always considered incrementable (and therefore usable with
std::ranges::iota_view) even when they don't satisfy std::integral.
libstdc++-v3/ChangeLog:
* include/bits/iterator_concepts.h [__STRICT_ANSI__]
(incrementable_traits<__int128>): Define specialization.
(incrementable_traits<unsigned __int128>): Likewise.
* testsuite/std/ranges/iota/96042.cc: Test iota_view with
__int128.
Jonathan Wakely [Wed, 19 Aug 2020 19:36:10 +0000 (20:36 +0100)]
libstdc++: Make make-unsigned-like-t<__int128> work [PR 96042]
As well as ensuring that numeric_limits<__int128> is defined, we need to
ensure that make-unsigned-like-t and to-unsigned-like work correctly for
128-bit integers in strict mode. This ensures that a subrange created
from an iota_view's iterator and sentinel can represent its size.
Co-authored-by: Patrick Palka <ppalka@redhat.com>
libstdc++-v3/ChangeLog:
2020-08-19 Jonathan Wakely <jwakely@redhat.com>
Patrick Palka <ppalka@redhat.com>
PR libstdc++/96042
* include/bits/range_access.h (__detail::__to_unsigned_like):
Do not use make_unsigned_t<T> in the return type, as it can
result in an error before the integral<T> constraint is checked.
[__STRICT_ANSI__]: Add overloads for 128-bit integer types.
(__detail::__make_unsigned_like_t): Define as the return type
of __to_unsigned_like.
* testsuite/std/ranges/subrange/96042.cc: New test.
Jonathan Wakely [Wed, 19 Aug 2020 15:27:25 +0000 (16:27 +0100)]
libstdc++: Make __int128 meet integer-class requirements [PR 96042]
Because __int128 can be used as the difference type for iota_view, we
need to ensure that it meets the requirements of an integer-class type.
The requirements in [iterator.concept.winc] p10 include numeric_limits
being specialized and giving meaningful answers. Currently we only
specialize numeric_limits for non-standard integer types in non-strict
modes. However, nothing prevents us from defining an explicit
specialization for any implementation-defined type, so it doesn't matter
whether std::is_integral<__int128> is true or not.
This patch ensures that the numeric_limits specializations for signed
and unsigned __int128 are defined whenever __int128 is available. It
also makes the __numeric_traits and __int_limits helpers work for
__int128, via a new __gnu_cxx::__is_integer_nonstrict trait.
libstdc++-v3/ChangeLog:
PR libstdc++/96042
* include/ext/numeric_traits.h (__is_integer_nonstrict): New
trait which is true for 128-bit integers even in strict modes.
(__numeric_traits_integer, __numeric_traits): Use
__is_integer_nonstrict instead of __is_integer.
* include/std/limits [__STRICT_ANSI__ && __SIZEOF_INT128__]
(numeric_limits<__int128>, (numeric_limits<unsigned __int128>):
Define.
* testsuite/std/ranges/iota/96042.cc: New test.
Jakub Jelinek [Thu, 12 Nov 2020 09:46:04 +0000 (10:46 +0100)]
c++: Fix up constexpr CLEANUP_POINT_EXPR and TRY_FINALLY_EXPR handling [PR97790]
As the testcase shows, CLEANUP_POINT_EXPR (and I think TRY_FINALLY_EXPR too)
suffer from the same problem that I was trying to fix in r10-3597-g1006c9d4395a939820df76f37c7b085a4a1a003f
for CLEANUP_STMT, namely that if in the middle of the body expression of
those stmts is e.g. return stmt, goto, break or continue (something that
changes *jump_target and makes it start skipping stmts), we then skip the
cleanups too, which is not appropriate - the cleanups were either queued up
during the non-skipping execution of the body (for CLEANUP_POINT_EXPR), or
for TRY_FINALLY_EXPR are relevant already after entering the body block.
> Would it make sense to always use a NULL jump_target when evaluating
> cleanups?
I was afraid of that, especially for TRY_FINALLY_EXPR, but it seems that
during constexpr evaluation the cleanups will most often be just very simple
destructor calls (or calls to cleanup attribute functions).
Furthermore, for neither of these 3 tree codes we'll reach that code if
jump_target && *jump_target initially (there is a return NULL_TREE much
earlier for those except for trees that could embed labels etc. in it and
clearly these 3 don't count in that).
2020-11-12 Jakub Jelinek <jakub@redhat.com>
PR c++/97790
* constexpr.c (cxx_eval_constant_expression) <case CLEANUP_POINT_EXPR,
case TRY_FINALLY_EXPR, case CLEANUP_STMT>: Don't pass jump_target to
cxx_eval_constant_expression when evaluating the cleanups.
Jakub Jelinek [Tue, 10 Nov 2020 14:56:20 +0000 (15:56 +0100)]
c, c++: Fix up -Wunused-value on COMPLEX_EXPRs [PR97748]
The -Wunused-value warning in both C and C++ FEs (implemented
significantly differently between the two) sees the COMPLEX_EXPRs created
e.g. for complex pre/post increment and many other expressions as useless
and warns about it.
For the C warning implementation, on e.g.
COMPLEX_EXPR < ++REALPART_EXPR <x>, IMAGPART_EXPR <x>>;
would warn even on the IMAGPART_EXPR <x> there alone etc., so what works
is check if we'd warn about both operands of COMPLEX_EXPR and if yes,
warn on the whole COMPLEX_EXPR, otherwise don't warn.
The C++ warning implementation is significantly different and for that one
the only warn if both would be warned about doesn't really work,
we then miss warnings e.g. about
COMPLEX_EXPR <REALPART_EXPR <SAVE_EXPR <x>> + 1.0e+0, IMAGPART_EXPR <SAVE_EXPR <x>>> >>>>>
The patch replaces the warning_at call with call to the c-family
warn_if_unused_value function.
On the testcase which after the initial new tests contains pretty much
everything from gcc.dg/Wunused-value-1.c both approaches seem to work
nicely.
2020-11-10 Jakub Jelinek <jakub@redhat.com>
PR c/97748
gcc/c-family/
* c-common.h (warn_if_unused_value): Add quiet argument defaulted
to false.
* c-warn.c (warn_if_unused_value): Likewise. Pass it down
recursively and just return true instead of warning if it is true.
Handle COMPLEX_EXPR.
gcc/cp/
* cvt.c (convert_to_void): Check (complain & tf_warning) in the outer
if rather than twice times in the inner one. Use warn_if_unused_value.
Formatting fix.
gcc/testsuite/
* c-c++-common/Wunused-value-1.c: New test.
Jakub Jelinek [Fri, 6 Nov 2020 19:33:39 +0000 (20:33 +0100)]
c++: Propagate attributes to clones in duplicate_decls [PR67453]
On the following testcase where the cdtor attributes aren't on the
in-class declaration but on an out-of-class definition, the cdtors
have their clones created from the in-class declaration, and later on
duplicate_decls updates attributes on the abstract cdtors, but nothing
propagates them to the clones.
2020-11-06 Jakub Jelinek <jakub@redhat.com>
PR c++/67453
* decl.c (duplicate_decls): Propagate DECL_ATTRIBUTES and
DECL_PRESERVE_P from olddecl to its clones if any.
Jakub Jelinek [Fri, 6 Nov 2020 08:52:59 +0000 (09:52 +0100)]
c-common: Remove DEBUG_FUNCTION from verify_sequence_points
While perhaps the function name might suggest that it is a verification/debugging
only routine, it is actually implementation of the -Wsequence-point warning
and so doesn't need the DEBUG_FUNCTION macro on it.
Jakub Jelinek [Tue, 3 Nov 2020 20:42:51 +0000 (21:42 +0100)]
c++: Don't try to parse a function declaration as deduction guide [PR97663]
While these function declarations have NULL decl_specifiers->type,
they have still type specifiers specified from which the default int
in the return type is added, so we shouldn't try to parse those as
deduction guides.
2020-11-03 Jakub Jelinek <jakub@redhat.com>
PR c++/97663
* parser.c (cp_parser_init_declarator): Don't try to parse
C++17 deduction guides if there are any type specifiers even when
type is NULL.
Eric Botcazou [Wed, 11 Nov 2020 13:52:45 +0000 (14:52 +0100)]
Fix segfault on elaboration of empty 1-element array at -O
This is a rather obscure case where the elaboration of an empty array
whose base type is an array type of length at most 1 goes awry when
the code is compiled with optimization.
gcc/ada/ChangeLog:
* gcc-interface/trans.c (can_be_lower_p): Remove.
(Regular_Loop_to_gnu): Add ENTRY_COND unconditionally if
BOTTOM_COND is non-zero.
gcc/testsuite/ChangeLog:
* gnat.dg/opt89.adb: New test.
Eric Botcazou [Wed, 11 Nov 2020 12:53:01 +0000 (13:53 +0100)]
Fix internal error with Shift_Right operator on signed type
This is a regression present on the mainline and 10 branch in the form
of an ICE with a shift operator applied to a variable of a signed type,
and which is caused by a type mismatch.
gcc/ada/ChangeLog:
* gcc-interface/trans.c (gnat_to_gnu) <N_Op_Shift>: Also convert
GNU_MAX_SHIFT if the type of the operation has been changed.
* gcc-interface/utils.c (can_materialize_object_renaming_p): Add
pair of missing parentheses.
gcc/testsuite/ChangeLog:
* gnat.dg/shift1.adb: New test.
Paul Scharnofske [Wed, 11 Nov 2020 09:29:37 +0000 (09:29 +0000)]
libstdc++: Assigning to a joinable std::jthread calls std::terminate
Move assigning to a std::jthread that represents a thread of execution
needs to send a stop request and join that running thread. Otherwise the
std::thread data member will terminate in its assignment operator.
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/std/thread (jthread::operator=(jthread&&)): Transfer
any existing state to a temporary that will request a stop and
then join.
* testsuite/30_threads/jthread/jthread.cc: Test move assignment.
Jakub Jelinek [Wed, 11 Nov 2020 07:27:38 +0000 (08:27 +0100)]
fortran: Fix up gfc_typename CHARACTER length handling [PR97768]
The first testcase below ICEs when f951 is 32-bit (or 64-bit big-endian).
The problem is that ex->ts.u.cl && ex->ts.u.cl->length are both non-NULL,
but ex->ts.u.cl->length->expr_type is not EXPR_CONSTANT, but EXPR_FUNCTION.
value.function.actual and value.function.name are in that case pointers,
but value._mp_alloc and value._mp_size are 4 byte integers no matter what.
So, in 64-bit little-endian the function returns most of the time incorrect
CHARACTER(0) because the most significant 32 bits of the
value.function.actual pointer are likely 0.
Anyway, the following patch is an attempt to get all the cases right.
Uses ex->value.character.length only for ex->expr_type == EXPR_CONSTANT
(i.e. CHARACTER literals), handles the deferred lengths, assumed lengths,
known constant lengths and finally if the length is something other,
just doesn't print it, i.e. prints just CHARACTER (for default kind)
or CHARACTER(KIND=4) (for e.g. kind 4).
2020-11-11 Jakub Jelinek <jakub@redhat.com>
PR fortran/97768
gcc/fortran/
* misc.c (gfc_typename): Use ex->value.character.length only if
ex->expr_type == EXPR_CONSTANT. If ex->ts.deferred, print : instead
of length. If ex->ts.u.cl && ex->ts.u.cl->length == NULL, print *
instead of length. Otherwise if character length is non-constant,
print just CHARACTER or CHARACTER(KIND=N).
gcc/testsuite/
* gfortran.dg/pr97768_1.f90: New test.
* gfortran.dg/pr97768_2.f90: New test.
Jakub Jelinek [Tue, 10 Nov 2020 10:17:46 +0000 (11:17 +0100)]
sccvn: Fix up push_partial_def little-endian bitfield handling [PR97764]
This patch fixes a thinko in the left-endian push_partial_def path.
As the testcase shows, we have 3 bitfields in the struct,
bitoff bitsize
0 3
3 28
31 1
the corresponding read is the byte at offset 3 (i.e. 24 bits)
and push_partial_def first handles the full store ({}) to all bits
and then is processing the store to the middle bitfield with value of -1.
Here are the interesting spots:
pd.offset -= offseti;
this adjusts the pd to { -21, 28 }, the (for little-endian lowest) 21
bits aren't interesting to us, we only care about the upper 7.
len = native_encode_expr (pd.rhs, this_buffer, bufsize,
MAX (0, -pd.offset) / BITS_PER_UNIT);
native_encode_expr has the offset parameter in bytes and we tell it
that we aren't interested in the first (lowest) two bytes of the number.
It encodes 0xff, 0xff with len == 2 then.
HOST_WIDE_INT size = pd.size;
if (pd.offset < 0)
size -= ROUND_DOWN (-pd.offset, BITS_PER_UNIT);
we get 28 - 16, i.e. 12 - the 16 is subtracting those 2 bytes that we
omitted in native_encode_expr.
size = MIN (size, (HOST_WIDE_INT) needed_len * BITS_PER_UNIT);
needed_len is how many bytes the read at most needs, and that is 1,
so we get size 8 and copy all 8 bits (i.e. a single byte plus nothing)
from the native_encode_expr filled this_buffer; this incorrectly sets
the byte to 0xff when we want 0x7f. The above line is correct for the
pd.offset >= 0 case when we don't skip anything, but for the pd.offset < 0
case we need to subtract also the remainder of the bits we aren't interested
in (the code shifts the bytes by that number of bits).
If it weren't for the big-endian path, we could as well do
if (pd.offset < 0)
size += pd.offset;
but the big-endian path needs it differently.
With the following patch, amnt is 3 and we subtract from 12 the (8 - 3)
bits and thus get the 7 which is the value we want.
2020-11-10 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/97764
* tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): For
little-endian stores with negative pd.offset, subtract
BITS_PER_UNIT - amnt from size if amnt is non-zero.
Sudakshina Das [Mon, 2 Nov 2020 15:52:22 +0000 (15:52 +0000)]
[PATCH] aarch64: Fix PR97638
Currently the testcase in the patch was failing to produce
a 'bti c' at the beginning of the function. This was because
in aarch64_pac_insn_p, we were wrongly returning at the first
check!
2020-10-30 Sudakshina Das <sudi.das@arm.com>
gcc/ChangeLog:
PR target/97638
* config/aarch64/aarch64-bti-insert.c (aarch64_pac_insn_p): Update
return value on INSN_P check.
gcc/testsuite/ChangeLog:
PR target/97638
* gcc.target/aarch64/pr97638.c: New test.a
Cui,Lili [Wed, 4 Nov 2020 06:20:31 +0000 (14:20 +0800)]
Enable MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG for march=tremont
1. Enable MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG for march=tremont
2. Move PREFETCHW from march=broadwell to march=silvermont.
3. Add PREFETCHWT1 to march=knl
gcc/ChangeLog:
2020-11-09 Lili Cui <lili.cui@intel.com>
PR target/97685
* config/i386/i386.h:
(PTA_BROADWELL): Delete PTA_PRFCHW.
(PTA_SILVERMONT): Add PTA_PRFCHW.
(PTA_KNL): Add PTA_PREFETCHWT1.
(PTA_TREMONT): Add PTA_MOVDIRI, PTA_MOVDIR64B, PTA_CLDEMOTE and PTA_WAITPKG.
* doc/invoke.texi: Delete PREFETCHW for broadwell, skylake, knl, knm,
skylake-avx512, cannonlake, icelake-client, icelake-server, cascadelake,
cooperlake, tigerlake and sapphirerapids.
Add PREFETCHW for silvermont, goldmont, goldmont-plus and tremont.
Add XSAVEC and XSAVES for goldmont, goldmont-plus and tremont.
Add MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG for tremont.
Add KEYLOCKER and HREST for alderlake.
Add AMX-BF16, AMX-TILE, AMX-INT8 and UINTR for sapphirerapids.
Add KEYLOCKER for tigerlake.
Richard Biener [Wed, 21 Oct 2020 19:28:45 +0000 (14:28 -0500)]
rs6000: MMA type causes an ICE in ranger pass due to incompatible types
PR97360 shows a problem in how we create our PXI and POI modes that cause
an ICE in the ranger pass. The problem seems to be that the extra call
to build_distinct_type_copy() also creates new TYPE_{MIN,MAX}_VALUEs that
are not compatible/the same as the base type itself. The simple "fix" is
to actually remove the unneeded build_distinct_type_copy(), since according
to richi, the types returned from make_unsigned_type() are already distinct.
gcc/
2020-10-21 Richard Biener <rguenther@suse.de>
PR target/97360
* config/rs6000/rs6000-call.c (rs6000_init_builtins): Remove call to
build_distinct_type_copy().
gcc/testsuite/
2020-10-21 Martin Liska <mliska@suse.cz>
PR target/97360
* gcc.target/powerpc/pr97360.c: New test.
Co-authored-by: Andrew MacLeod <amacleod@redhat.com> Co-authored-by: Martin Liska <mliska@suse.cz>
(cherry picked from commit 84cc3370d6d5972fe495b2114fb32f7b4a49a98d)
Tobias Burnus [Fri, 6 Nov 2020 07:26:51 +0000 (08:26 +0100)]
Fortran: Fix type-decl for PDT / wrong-code pdt_14.f03 issue [PR97652]
Parameterized derived types are handled in a special way and start with 'Pdt'.
If the 'P' is not uppercase, gfc_get_derived_type (which calls
gfc_get_module_backend_decl) does not find the existing declaration and
builds a new type. The middle end then sees those types as being different
and nonalising, creating an endless loop for pdt_14.f03.
gcc/fortran/ChangeLog:
PR fortran/97652
* module.c (mio_symbol): Fix symbol name for pdt_type.
Instead, use the generic middle-end code, like already used for Fortran OpenACC
'loop' inside other compute constructs, orphaned 'loop' constructs, and C, C++
generally.
Jonathan Wakely [Thu, 5 Nov 2020 18:36:19 +0000 (18:36 +0000)]
libstdc++: Fix constraints on std::optional comparisons [PR 96269]
The relational operators for std::optional were using the wrong types
in the declval expressions used to constrain them. Instead of using
const lvalues they were using non-const rvalues, which meant that a type
might satisfy the constraints but then give an error when the function
body was instantiated.
libstdc++-v3/ChangeLog:
PR libstdc++/96269
* include/std/optional (operator==, operator!=, operator<)
(operator>, operator<=, operator>=): Fix types used in
SFINAE constraints.
* testsuite/20_util/optional/relops/96269.cc: New test.
Jonathan Wakely [Thu, 5 Nov 2020 17:26:13 +0000 (17:26 +0000)]
libstdc++: Use non-throwing increment in recursive_directory_iterator [PR 97731]
As described in the PR, the recursive_directory_iterator constructor
calls advance(ec), but ec is a pointer so it calls _Dir::advance(bool).
The intention was to either call advance() or advance(*ec) depending
whether the pointer is null or not.
This fixes the bug and renames the parameter to ecptr to make similar
mistakes less likely in future.
libstdc++-v3/ChangeLog:
PR libstdc++/97731
* src/filesystem/dir.cc (recursive_directory_iterator): Call the
right overload of _Dir::advance.
* testsuite/experimental/filesystem/iterators/97731.cc: New test.
Jonathan Wakely [Sat, 10 Oct 2020 20:22:12 +0000 (21:22 +0100)]
libstdc++: Replace use of reserved name that clashes [PR 97362]
The name __deref is defined as a macro by Windows headers.
This renames the __deref() helper function to __ref. It doesn't actually
dereference an iterator. it just has the same type as the iterator's
reference type.
Jonathan Wakely [Mon, 1 Jun 2020 15:40:13 +0000 (16:40 +0100)]
libstdc++: Fix incorrect Docbook links
The <xref> element creates the link text automatically from the link
target, rather than using the text node child of the element. This can
be changed by using an endterm attribute, but it's simpler to just use
the <link> element instead.
2020-10-19 Andrea Corallo <andrea.corallo@arm.com>
* config/aarch64/arm_neon.h (__ST2_LANE_FUNC, __ST3_LANE_FUNC)
(__ST4_LANE_FUNC): Rename the macro generating the 'q' variants
into __ST2Q_LANE_FUNC, __ST2Q_LANE_FUNC, __ST2Q_LANE_FUNC so they
all can be undefed at the and of the file.
(vst2_lane_bf16, vst2q_lane_bf16, vst3_lane_bf16, vst3q_lane_bf16)
(vst4_lane_bf16, vst4q_lane_bf16): Add new intrinsics.
gcc/testsuite/ChangeLog
2020-10-19 Andrea Corallo <andrea.corallo@arm.com>
* gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h
(hbfloat16_t): Define type.
(CHECK_FP): Make it working for bfloat types.
* gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_1.c: New file.
* gcc.target/aarch64/advsimd-intrinsics/bf16_vstN_lane_2.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst2_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst2q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst3_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst3q_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst4_lane_bf16_indices_1.c:
Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vst4q_lane_bf16_indices_1.c:
Likewise.
2020-10-15 Andrea Corallo <andrea.corallo@arm.com>
* config/aarch64/arm_neon.h (__LD2_LANE_FUNC, __LD3_LANE_FUNC)
(__LD4_LANE_FUNC): Rename the macro geneating the 'q' variants
into __LD2Q_LANE_FUNC, __LD2Q_LANE_FUNC, __LD2Q_LANE_FUNC so they
all can be undefed at the and of the file.
(vld2_lane_bf16, vld2q_lane_bf16, vld3_lane_bf16, vld3q_lane_bf16)
(vld4_lane_bf16, vld4q_lane_bf16): Add new intrinsics.
gcc/testsuite/ChangeLog
2020-10-15 Andrea Corallo <andrea.corallo@arm.com>
Thomas Schwinge [Tue, 3 Nov 2020 21:06:29 +0000 (22:06 +0100)]
[OpenACC] Use proper location to 'inform' of enclosing parent compute construct
Bug fix for recent commit beddd1762ad2bbe84dd776c54489153f83f21e56 "[OpenACC]
More precise diagnostics for 'gang', 'worker', 'vector' clauses with arguments
on 'loop' only allowed in 'kernels' regions":
> [...], and 'inform' at the location of the enclosing parent
> compute construct/[...].
Now really.
gcc/
* omp-low.c (scan_omp_for) <OpenACC>: Use proper location to
'inform' of enclosing parent compute construct.
gcc/testsuite/
* c-c++-common/goacc/pr92793-1.c: Extend.
* gfortran.dg/goacc/pr92793-1.f90: Likewise.
Richard Biener [Tue, 3 Nov 2020 09:24:02 +0000 (10:24 +0100)]
testsuite/97688 - fix check_vect () with __AVX2__
This fixes the cpuid check to always specify a subleaf zero
which is required to detect AVX2 and doesn't hurt for level one.
Without this fix we get zero runtime coverage when -mavx2 is
specified.
2020-11-03 Richard Biener <rguenther@suse.de>
PR testsuite/97688
* gcc.dg/vect/tree-vect.h (check_vect): Fix the x86 cpuid
check to always specify subleaf zero.
Thomas Schwinge [Tue, 27 Oct 2020 16:13:16 +0000 (17:13 +0100)]
[OpenACC] More precise diagnostics for 'gang', 'worker', 'vector' clauses with arguments on 'loop' only allowed in 'kernels' regions
Instead of at the location of the 'loop' directive, 'error_at' the location of
the improper clause, and 'inform' at the location of the enclosing parent
compute construct/routine.
The Fortran testcases come with some XFAILing, to be resolved later.
gcc/
* omp-low.c (scan_omp_for) <OpenACC>: More precise diagnostics for
'gang', 'worker', 'vector' clauses with arguments only allowed in
'kernels' regions.
gcc/testsuite/
* c-c++-common/goacc/pr92793-1.c: Extend.
* gfortran.dg/goacc/pr92793-1.f90: Likewise.
Thomas Schwinge [Fri, 30 Oct 2020 12:13:51 +0000 (13:13 +0100)]
Further improve Fortran column location information [PR92793]
Building on top of commit 9c81750c5bedd7883182ee2684a012c6210ebe1d "Fortran] PR
92793 - fix column used for error diagnostic", there is another place where we
have to use 'gfc_get_location' returning column-corrected locations.
For example, this improves column location information for OMP constructs.
Thomas Schwinge [Thu, 29 Oct 2020 09:29:19 +0000 (10:29 +0100)]
libgomp testsuite: tell warning from error diagnostics, etc. [PR80219, PR85303]
This changes makes 'dg-warning', 'dg-error', 'dg-bogus', 'dg-message' behave as
expected, and also enables use of relative line numbers as well as 'dg-line'.
Jakub Jelinek [Wed, 28 Oct 2020 09:24:20 +0000 (10:24 +0100)]
wide-int: Fix up set_bit_large
> >> wide_int new_lb = wi::set_bit (r.lower_bound (0), 127)
> >>
> >> and creates the value:
> >>
> >> p new_lb
> >> {<wide_int_storage> = {val = {-65535, -1, 0}, len = 2, precision = 128},
> >> static is_sign_extended = true}
> >
> > This is non-canonical and so invalid, if the low HWI has the MSB set
> > and the high HWI is -1, it should have been just
> > val = {-65535}, len = 1, precision = 128}
> >
> > I guess the bug is that wi::set_bit_large doesn't call canonize.
>
> Yeah, looks like a micro-optimisation gone wrong.
2020-10-28 Jakub Jelinek <jakub@redhat.com>
* wide-int.cc (wi::set_bit_large): Call canonize unless setting
msb bit and clearing bits above it.
Patrick Palka [Thu, 29 Oct 2020 18:02:59 +0000 (14:02 -0400)]
c++: Tolerate empty initial args during normalization [PR97412]
When normalizing the constraint-expression of a nested-requirement, we
pass NULL_TREE as the initial template arguments for normalization, but
tsubst_argument_pack is not prepared to handle a NULL_TREE args vector.
This causes us to ICE when normalizing a variadic concept as part of a
nested-requirement.
This patch fixes the ICE by guarding the call to tsubst_template_args in
normalize_concept_check appropriately. This will also enable us to
simplify many of the normalization routines to just pass NULL_TREE
(instead of a set of generic template arguments) as the initial template
arguments.
gcc/cp/ChangeLog:
PR c++/97412
* constraint.cc (normalize_concept_check): Don't call
tsubst_template_args when 'args' is NULL.
gcc/testsuite/ChangeLog:
PR c++/97412
* g++.dg/cpp2a/concepts-variadic2.C: New test.
Patrick Palka [Wed, 28 Oct 2020 15:47:26 +0000 (11:47 -0400)]
c++: Check constraints before instantiation from mark_used [PR95132]
This makes mark_used check constraints of a function _before_ calling
maybe_instantiate_decl, so that we don't try instantiating a function
(as part of return type deduction) with unsatisfied constraints.
gcc/cp/ChangeLog:
PR c++/95132
* decl2.c (mark_used): Move up the constraints_satisfied_p check
so that we check constraints before calling maybe_instantiate_decl.
gcc/testsuite/ChangeLog:
PR c++/95132
* g++.dg/cpp2a/concepts-fn7.C: New test.
Patrick Palka [Fri, 23 Oct 2020 13:03:25 +0000 (09:03 -0400)]
libstdc++: Apply proposed resolutions for LWG 3428, 3447
libstdc++-v3/ChangeLog:
* include/std/ranges (single_view::single_view): Mark the
in place constructor explicit as per LWG 3428.
(take_view): Remove the constraint on the deduction guide's
template parameter as per LWG 3447.
i.e. it replaces two uses of the parameter default-def with two
uninitialized default-defs of a new variable - all in hope to produce
code with better debug info.
This patch fixes it by avoiding the transform when the SSA_NAME to be
replaced is a default definition.
gcc/ChangeLog:
2020-10-19 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/97456
* tree-complex.c (set_component_ssa_name): Do not replace ignored decl
default definitions with new component vars. Reorder if conditions.
gcc/testsuite/ChangeLog:
2020-10-19 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/97456
* gcc.dg/tree-ssa/pr97456.c: New test.
Marek Polacek [Thu, 15 Oct 2020 20:10:45 +0000 (16:10 -0400)]
c++: Fix verify_ctor_sanity ICE [PR96241]
The code added in r10-6437 caused us to create a CONSTRUCTOR when we're
{}-initializing an aggregate. Then we pass this new CONSTRUCTOR down to
cxx_eval_constant_expression which, if the CONSTRUCTOR isn't TREE_CONSTANT
or reduced_constant_expression_p, calls cxx_eval_bare_aggregate. In
this case the CONSTRUCTOR wasn't reduced_constant_expression_p because
for r_c_e_p a CONST_DECL isn't good enough so it returns false. So we
go to cxx_eval_bare_aggregate where we crash, because ctx->ctor wasn't
set up properly. So my fix is to do so. Since we're value-initializing,
I'm not setting CONSTRUCTOR_NO_CLEARING. To avoid keeping a garbage
constructor around, I call free_constructor in case the evaluation did
not use it.
gcc/cp/ChangeLog:
PR c++/96241
* constexpr.c (cxx_eval_array_reference): Set up ctx->ctor if we
are initializing an aggregate. Call free_constructor on the new
CONSTRUCTOR if it isn't returned from cxx_eval_constant_expression.
gcc/testsuite/ChangeLog:
PR c++/96241
* g++.dg/cpp0x/constexpr-96241.C: New test.
* g++.dg/cpp1y/constexpr-96241.C: New test.
Harald Anlauf [Fri, 16 Oct 2020 20:17:46 +0000 (22:17 +0200)]
PR fortran/95979 - ICE in get_kind, at fortran/simplify.c:129
Simplification of the elemental intrinsic INDEX with constant array-valued
arguments failed with an ICE or did not reduce to a constant array, depending
also on the presence of the optional KIND argument. Add a further attempt of
simplification in the case of elemental intrinsics, and make sure the KIND
argument is not removed prematurely during simplification of INDEX.
gcc/fortran/ChangeLog:
PR fortran/95979
* expr.c (gfc_check_init_expr): Fix check of return code from
gfc_intrinsic_func_interface.
* intrinsic.c (gfc_intrinsic_func_interface): Add further attempt
of simplification of elemental intrinsics with array arguments.
* iresolve.c (gfc_resolve_index_func): Keep optional KIND argument
for simplification of elemental use of INDEX.
gcc/testsuite/ChangeLog:
PR fortran/95979
* gfortran.dg/index_4.f90: New test.
Patrick Palka [Thu, 22 Oct 2020 11:40:40 +0000 (07:40 -0400)]
c++: Handle RANGE_EXPR index in init_subob_ctx [PR97328]
In the testcase below, we're ICEing during constexpr evaluation of the
CONSTRUCTOR {.data={{}, [1 ... 7]={}}} of type 'vector'. The interesting
thing about this CONSTRUCTOR is that it has a RANGE_EXPR index for an
element initializer which doesn't satisfy reduced_constant_expression_p
(because the field 't' is uninitialized).
This is a problem because init_subob_ctx currently punts on setting up a
sub-aggregate initialization context when given a RANGE_EXPR index, so
we later trip over the asserts in verify_ctor_sanity when recursing into
cxx_eval_bare_aggregate on this element initializer.
Fix this by making init_subob_ctx set up an appropriate initialization
context when supplied a RANGE_EXPR index.
gcc/cp/ChangeLog:
PR c++/97328
* constexpr.c (init_subob_ctx): Don't punt on RANGE_EXPR
indexes, instead build a sub-aggregate initialization context
with no subobject.
gcc/testsuite/ChangeLog:
PR c++/97328
* g++.dg/cpp2a/constexpr-init19.C: New test.
* g++.dg/cpp2a/constexpr-init20.C: New test.
Kito Cheng [Wed, 2 Sep 2020 06:26:15 +0000 (14:26 +0800)]
PR target/96759 - Handle global variable assignment from misaligned structure/PARALLEL return values.
In g:70cdb21e579191fe9f0f1d45e328908e59c0179e, DECL/global variable has handled
misaligned stores, but it didn't handle PARALLEL values, and I refer the
other part of this function, I found the PARALLEL need handled by
emit_group_* functions, so I add a check, and using emit_group_store if
storing a PARALLEL value, also checked this change didn't break the
testcase(gcc.target/arm/unaligned-argument-3.c) added by the orginal changes.
For riscv64 target, struct S {int a; double b;} will pack into a parallel
value to return and it has TImode when misaligned access is supported,
however TImode required 16-byte align, but it only 8-byte align, so it go to
the misaligned stores handling, then it will try to generate move
instruction from a PARALLEL value.
Tested on following target without introduced new reguression:
- riscv32/riscv64 elf
- x86_64-linux
- arm-eabi
v2 changes:
- Use maybe_emit_group_store instead of emit_group_store.
- Remove push_temp_slots/pop_temp_slots, emit_group_store only require
stack temp slot when dst is CONCAT or PARALLEL, however
maybe_emit_group_store will always use REG for dst if needed.
Patrick Palka [Tue, 22 Sep 2020 00:53:17 +0000 (20:53 -0400)]
libstdc++: Remove overzealous static_asserts from std::span
For a span with statically empty extent, we currently model the
preconditions of front(), back(), and operator[] as if they are
mandates, by using a static_assert to verify that extent != 0. This
causes us to reject valid programs that would instantiate these member
functions and at runtime never call them.
Since they are already followed by more general runtime asserts, this
patch just removes these static_asserts altogether,
libstdc++-v3/ChangeLog:
* include/std/span (span::front): Remove static_assert.
(span::back): Likewise.
(span::operator[]): Likewise.
* testsuite/23_containers/span/back_neg.cc: Rewrite to verify
that we check the preconditions of back() only when it's called.
* testsuite/23_containers/span/front_neg.cc: Likewise for
front().
* testsuite/23_containers/span/index_op_neg.cc: Likewise for
operator[].
Patrick Palka [Mon, 12 Oct 2020 17:46:24 +0000 (13:46 -0400)]
libstdc++: Apply proposed resolution for LWG 3450
libstdc++-v3/ChangeLog:
* include/std/ranges (take_while_view::begin): Constrain the
const overload further as per LWG 3450.
(take_while_view::end): Likewise.
* testsuite/std/ranges/adaptors/take_while.cc: Add test for LWG
3450.
Patrick Palka [Tue, 22 Sep 2020 00:48:17 +0000 (20:48 -0400)]
libstdc++: Mark some more algorithms constexpr for C++20
As per P0202.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (for_each_n): Mark constexpr for C++20.
(search): Likewise for the overload that takes a searcher.
* testsuite/25_algorithms/for_each/constexpr.cc: Test constexpr
std::for_each_n.
* testsuite/25_algorithms/search/constexpr.cc: Test constexpr
std::search overload that takes a searcher.
Patrick Palka [Thu, 27 Aug 2020 01:51:48 +0000 (21:51 -0400)]
libstdc++: Implement remaining piece of LWG 3448
Almost all of the proposed resolution for LWG 3448 is already
implemented; the only part left is to adjust the return type of
transform_view::sentinel::operator-.
libstdc++-v3/ChangeLog:
PR libstdc++/95322
* include/std/ranges (transform_view::sentinel::__distance_from):
Give this a deduced return type.
(transform_view::sentinel::operator-): Adjust the return type so
that it's based on the constness of the iterator rather than
that of the sentinel.
* testsuite/std/ranges/adaptors/95322.cc: Refer to LWG 3488.
Patrick Palka [Thu, 27 Aug 2020 01:52:58 +0000 (21:52 -0400)]
libstdc++: elements_view's sentinel and iterator not comparable [LWG 3406]
This implements the proposed resolution for LWG 3406, and adds a
testcase for the example from P1994R1.
libstdc++-v3/ChangeLog:
* include/std/ranges (elements_view::begin): Adjust constraints.
(elements_view::end): Likewise.
(elements_view::_Sentinel::operator==): Templatize to take both
_Iterator<true> and _Iterator<false>.
(elements_view::_Sentinel::operator-): Likewise.
* testsuite/std/ranges/adaptors/elements.cc: Add testcase for
the example from P1994R1.
* testsuite/std/ranges/adaptors/lwg3406.cc: New test.
git://gcc.gnu.org / gcc.git / log