Jakub Jelinek [Wed, 12 May 2021 08:38:35 +0000 (10:38 +0200)]
expand: Don't reuse DEBUG_EXPRs with vector type if they have different modes [PR100508]
The inliner doesn't remap DEBUG_EXPR_DECLs, so the same decls can appear
in multiple functions.
Furthermore, expansion reuses corresponding DEBUG_EXPRs too, so they again
can be reused in multiple functions.
Neither of that is a major problem, DEBUG_EXPRs are just magic value holders
and what value they stand for is independent in each function and driven by
what debug stmts or DEBUG_INSNs they are bound to.
Except for DEBUG_EXPR*s with vector types, TYPE_MODE can be either BLKmode
or some vector mode depending on whether current function's enabled ISAs
support that vector mode or not. On the following testcase, we expand it
first in foo function without AVX2 enabled and so the DEBUG_EXPR is
BLKmode, but later the same DEBUG_EXPR_DECL is used in a simd clone with
AVX2 enabled and expansion ICEs because of a mode mismatch.
The following patch fixes that by forcing recreation of a DEBUG_EXPR if
there is a mode mismatch for vector typed DEBUG_EXPR_DECL, DEBUG_EXPRs
will be still reused in between functions otherwise and within the same
function the mode should be always the same.
2021-05-12 Jakub Jelinek <jakub@redhat.com>
PR middle-end/100508
* cfgexpand.c (expand_debug_expr): For DEBUG_EXPR_DECL with vector
type, don't reuse DECL_RTL if it has different mode, instead force
creation of a new DEBUG_EXPR.
Jakub Jelinek [Tue, 11 May 2021 07:07:47 +0000 (09:07 +0200)]
openmp: Fix up taskloop reduction ICE if taskloop has no iterations [PR100471]
When a taskloop doesn't have any iterations, GOMP_taskloop* takes an early
return, doesn't create any tasks and more importantly, doesn't create
a taskgroup and doesn't register task reductions. But, the code emitted
in the callers assumes task reductions have been registered and performs
the reduction handling and task reduction unregistration. The pointer
to the task reduction private variables is reused, on input it is the alignment
and only on output it is the pointer, so in the case taskloop with no iterations
the caller attempts to dereference the alignment value as if it was a pointer
and crashes. We could in the early returns register the task reductions
only to have them looped over and unregistered in the caller, but I think
it is better to tell the caller there is nothing to task reduce and bypass
all that.
2021-05-11 Jakub Jelinek <jakub@redhat.com>
PR middle-end/100471
* omp-low.c (lower_omp_task_reductions): For OMP_TASKLOOP, if data
is 0, bypass the reduction loop including
GOMP_taskgroup_reduction_unregister call.
* taskloop.c (GOMP_taskloop): If GOMP_TASK_FLAG_REDUCTION and not
GOMP_TASK_FLAG_NOGROUP, when doing early return clear the task
reduction pointer.
* testsuite/libgomp.c/task-reduction-4.c: New test.
RISC-V: For '-march' and '-mabi' options, add 'Negative' property mentions itself.
When use multi-lib riscv-tool-chain. A bug is triggered when there are two
'-march' at command line.
riscv64-unknown-elf-gcc -march=rv32gcp -mabi=ilp32f -march=rv32gcpzp64 HelloWorld.c
/lhome/gengq/riscv64-linux-ptest/lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld: /lhome/gengq/riscv64-linux-ptest/lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/lib/crt0.o: ABI is incompatible with that of the selected emulation:
target emulation `elf64-littleriscv' does not match `elf32-littleriscv'
/lhome/gengq/riscv64-linux-ptest/lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld: failed to merge target specific data of file /lhome/gengq/riscv64-linux-ptest/lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/lib/crt0.o
/lhome/gengq/riscv64-linux-ptest/lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld: /lhome/gengq/riscv64-linux-ptest/lib/gcc/riscv64-unknown-elf/10.2.0/crtbegin.o: ABI is incompatible with that of the selected emulation:
target emulation `elf64-littleriscv' does not match `elf32-littleriscv'
/lhome/gengq/riscv64-linux-ptest/lib/gcc/riscv64-unknown-elf/10.2.0/../../../../riscv64-unknown-elf/bin/ld: failed to merge target specific data of file /lhome/gengq/riscv64-linux-ptest/lib/gcc/riscv64-unknown-elf/10.2.0/crtbegin.o
......
This patch fix it. And the DRIVER would prune the extra '-march' and '-mabi'
options and keep only the last one valid.
Jonathan Wakely [Tue, 11 May 2021 14:01:01 +0000 (15:01 +0100)]
libstdc++: Fix missing members in std::allocator<void>
The changes in 75c6a925dab5b7af9ab47c10906cb0e140261cc2 were slightly
incorrect, because the converting constructor should be noexcept, and
the POCMA and is_always_equal traits should still be present in C++20.
This fixes it, and slightly refactors the preprocessor conditions and
order of members. Also add comments explaining things.
The non-standard construct and destroy members added for PR 78052 can be
private if allocator_traits<allocator<void>> is made a friend.
libstdc++-v3/ChangeLog:
* include/bits/allocator.h (allocator<void>) [C++20]: Add
missing noexcept to constructor. Restore missing POCMA and
is_always_equal_traits.
[C++17]: Make construct and destroy members private and
declare allocator_traits as a friend.
* include/bits/memoryfwd.h (allocator_traits): Declare.
* include/ext/malloc_allocator.h (malloc_allocator::allocate):
Add nodiscard attribute. Add static assertion for LWG 3307.
* include/ext/new_allocator.h (new_allocator::allocate): Add
static assertion for LWG 3307.
* testsuite/20_util/allocator/void.cc: Check that converting
constructor is noexcept. Check for propagation traits and
size_type and difference_type. Check that pointer and
const_pointer are gone in C++20.
Jonathan Wakely [Mon, 10 May 2021 20:06:22 +0000 (21:06 +0100)]
libstdc++: Remove TODO comment
We have a comment saying to replace the simple binary_semaphore type
with std::binary_semaphore, which has been done. However, that isn't
defined on all targets. So keep the simple one here that just implements
the parts of the API needed by <stop_token>, and remove the comment
suggesting it should be replaced.
Jonathan Wakely [Mon, 10 May 2021 19:46:38 +0000 (20:46 +0100)]
libstdc++: Implement proposed resolution to LWG 3548
This has been tentatively approved by LWG. The deleter from a unique_ptr
can be moved into the shared_ptr (at least, since LWG 2802). This uses
std::forward<_Del>(__r.get_deleter()) not std::move(__r.get_deleter())
because we don't want to convert the deleter to an rvalue when _Del is
an lvalue reference type.
This also adds a missing is_move_constructible_v<D> constraint to the
shared_ptr(unique_ptr<Y, D>&&) constructor, which is inherited from the
shared_ptr(Y*, D) constructor due to the use of "equivalent to" in the
specified effects.
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_base.h (__shared_count(unique_ptr&&)):
Initialize a non-reference deleter from an rvalue, as per LWG
3548.
(__shared_ptr::_UniqCompatible): Add missing constraint.
* testsuite/20_util/shared_ptr/cons/lwg3548.cc: New test.
* testsuite/20_util/shared_ptr/cons/unique_ptr_deleter.cc: Check
constraints.
Jonathan Wakely [Mon, 10 May 2021 15:22:54 +0000 (16:22 +0100)]
libstdc++: Remove redundant -std=gnu++17 option from remaining tests
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Jonathan Wakely [Mon, 10 May 2021 15:22:54 +0000 (16:22 +0100)]
libstdc++: Remove redundant -std=gnu++17 option from algorithm tests
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Jonathan Wakely [Mon, 10 May 2021 15:22:53 +0000 (16:22 +0100)]
libstdc++: Remove redundant -std=gnu++17 option from containers tests
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Jonathan Wakely [Mon, 10 May 2021 15:22:53 +0000 (16:22 +0100)]
libstdc++: Remove redundant -std=gnu++17 option from strings tests
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Jonathan Wakely [Mon, 10 May 2021 15:22:53 +0000 (16:22 +0100)]
libstdc++: Remove redundant -std=gnu++17 option from PMR tests
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Jonathan Wakely [Mon, 10 May 2021 15:22:53 +0000 (16:22 +0100)]
libstdc++: Remove redundant -std=gnu++17 option from concurrency tests
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Jonathan Wakely [Mon, 10 May 2021 15:22:53 +0000 (16:22 +0100)]
libstdc++: Remove redundant -std=gnu++17 option from any/optional/variant tests
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Jonathan Wakely [Mon, 10 May 2021 15:22:53 +0000 (16:22 +0100)]
libstdc++: Remove redundant -std=gnu++17 options from filesystem tests
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Jonathan Wakely [Mon, 10 May 2021 15:22:53 +0000 (16:22 +0100)]
libstdc++: Remove redundant -std=gnu++17 options from PSTL tests
GCC defaults to -std=gnu++17 now anyway, and using it explicitly in the
dg-options directive prevents running these tests with different modes
such as -std=c++17 or -std=gnu++20.
Jonathan Wakely [Mon, 10 May 2021 12:57:49 +0000 (13:57 +0100)]
libstdc++: Rename test type to avoid clashing with std::any
When PCH are enabled this test file includes <any> and so the
using-directive brings std::any into the global scope. It isn't
currently a problem, because the -std option in the dg-options means
that PCH is not used. If that option is removed, the test fails with PCH
and passes without.
This just renames the type to avoid the name classh (and also the 'none'
type for consistency).
libstdc++-v3/ChangeLog:
* testsuite/20_util/variant/compile.cc: Rename 'any' to avoid
clash with std::any.
Jonathan Wakely [Thu, 6 May 2021 12:40:53 +0000 (13:40 +0100)]
libstdc++: Fix definition of std::remove_cvref_t
I originally defined std::remove_cvref_t in terms of the internal
__remove_cvref_t trait, to avoid instantiating the remove_cvref class
template. However, as described in P1715R0 that is observable by users
and is thus non-conforming.
This defines remove_cvref_t as specified in the standard.
libstdc++-v3/ChangeLog:
* include/std/type_traits (remove_cvref_t): Define in terms of
remove_cvref.
* testsuite/20_util/remove_cvref/value.cc: Check alias.
Prior to C++20 it should be ill-formed to use std::make_shared with an
array type (and we don't support the C++20 feature to make it valid yet
anyway).
libstdc++-v3/ChangeLog:
PR libstdc++/99006
* include/bits/shared_ptr.h (allocate_shared): Assert that _Tp
is not an array type.
* include/bits/shared_ptr_base.h (__allocate_shared): Likewise.
* testsuite/20_util/shared_ptr/creation/99006.cc: New test.
Philippe Blain [Sat, 13 Mar 2021 00:26:46 +0000 (19:26 -0500)]
libstdc++: Install libstdc++*-gdb.py more robustly [PR 99453]
In order for GDB to auto-load the pretty printers, they must be installed
as "libstdc++.$ext-gdb.py", where 'libstdc++.$ext' is the name of the
object file that is loaded by GDB [1], i.e. the libstdc++ shared library.
The approach taken in libstdc++-v3/python/Makefile.am is to loop over
files matching 'libstdc++*' in $(DESTDIR)$(toolexeclibdir) and choose
the last file matching that glob that is not a symlink, the Libtool
'*.la' file or a Python file.
That works fine for ELF targets where the matching names are:
Try to make a better job at installing the pretty printers with the
correct name by copying the approach taken by isl [2], that is, using
a sed invocation on the Libtool-generated 'libstdc++.la' to read the
correct name for the current platform.
Patrick Palka [Tue, 11 May 2021 17:19:46 +0000 (13:19 -0400)]
libstdc++: Remove extern "C" from Ryu sources
floating_to_chars.cc includes the Ryu sources into an anonymous
namespace as a convenient way to give all its symbols internal linkage.
But an entity declared extern "C" always has external linkage even
from within an anonymous namespace, so this trick doesn't work in the
presence of extern "C", and it causes the Ryu function generic_to_chars
to be visible from libstdc++.a.
This patch removes the only use of extern "C" from our local copy of
Ryu along with some declarations for never-defined functions that GCC
now warns about.
libstdc++-v3/ChangeLog:
* src/c++17/ryu/LOCAL_PATCHES: Update.
* src/c++17/ryu/ryu_generic_128.h: Remove extern "C".
Remove declarations for never-defined functions.
* testsuite/20_util/to_chars/4.cc: New test.
Jonathan Wakely [Thu, 6 May 2021 18:14:42 +0000 (19:14 +0100)]
libstdc++: Fix constraints for rvalue stream insertion/extraction
The __rval_streamable() function was an attempt to test for
convertibility cheaply and without confusing diagnostics. It doesn't
work with Clang though, and is probably ill-formed.
Replace that helper function with a check for derivation from ios_base,
and use that in the alias templates __rvalue_stream_insertion_t and
__rvalue_stream_extraction_t. Use concepts for the constraints when
available.
libstdc++-v3/ChangeLog:
* include/std/istream (__rvalue_stream_extraction_t): Replace
use of __rval_streamable.
* include/std/ostream (__rvalue_stream_insertion_t): Likewise.
(__rval_streamable): Remove.
(_Require_derived_from_ios_base, __derived_from_ios_base): New
helper for checking constraints.
* testsuite/27_io/basic_istream/extractors_other/char/4.cc: Fix
reference to the wrong subclause of the standard.
* testsuite/27_io/basic_istream/extractors_other/wchar_t/4.cc:
Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/6.cc:
Likewise.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/6.cc:
Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/99692.cc:
New test.
* testsuite/27_io/filesystem/path/io/dr2989.cc: Adjust pruned
errors.
Jakub Jelinek [Fri, 7 May 2021 15:48:37 +0000 (17:48 +0200)]
libcpp: Fix up pragma preprocessing [PR100450]
Since the r0-85991-ga25a8f3be322fe0f838947b679f73d6efc2a412c
https://gcc.gnu.org/legacy-ml/gcc-patches/2008-02/msg01329.html
changes, so that we handle macros inside of pragmas that should expand
macros, during preprocessing we print those pragmas token by token,
with CPP_PRAGMA printed as
fputs ("#pragma ", print.outf);
if (space)
fprintf (print.outf, "%s %s", space, name);
else
fprintf (print.outf, "%s", name);
where name is some identifier (so e.g. print
#pragma omp parallel
or
#pragma omp for
etc.). Because it ends in an identifier, we need to handle it like
an identifier (i.e. CPP_NAME) for the decision whether a space needs
to be emitted in between that #pragma whatever or #pragma whatever whatever
and following token, otherwise the attached testcase is preprocessed as
#pragma omp forreduction(+:red)
rather than
#pragma omp for reduction(+:red)
The cpp_avoid_paste function is only called for this purpose.
2021-05-07 Jakub Jelinek <jakub@redhat.com>
PR c/100450
* lex.c (cpp_avoid_paste): Handle token1 CPP_PRAGMA like CPP_NAME.
Jonathan Wakely [Fri, 30 Apr 2021 13:07:28 +0000 (14:07 +0100)]
libstdc++: Implement LWG 1203 for rvalue iostreams
This implements the resolution of LWG 1203 so that the constraints for
rvalue stream insertion/extraction are simpler, and the return type is
the original rvalue stream type not its base class.
Signed-off-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/std/istream (operator>>(Istream&&, x&)): Simplify, as
per LWG 1203.
* include/std/ostream (operator<<(Ostream&&, const x&)):
Likewise.
* testsuite/27_io/basic_istream/extractors_character/char/lwg2499_neg.cc:
Adjust dg-error pattern.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/lwg2499_neg.cc:
Likewise.
* testsuite/27_io/basic_istream/extractors_other/char/4.cc: Define
is_extractable trait to replace std::__is_extractable. Make it
work with rvalue streams as well as lvalues, to replace f() and
g() helper functions.
* testsuite/27_io/basic_istream/extractors_other/wchar_t/4.cc:
Likewise.
* testsuite/27_io/basic_ostream/inserters_other/char/6.cc:
Define is_insertable trait to replace std::__is_insertable. Make
it work with rvalue streams as well as lvalues, to replace f()
and g() helper functions.
* testsuite/27_io/basic_ostream/inserters_other/wchar_t/6.cc:
Likewise.
* testsuite/27_io/filesystem/path/io/dr2989.cc: Prune additional
errors from new constraints.
* testsuite/27_io/rvalue_streams-2.cc: Remove PR 80675 checks,
which are no longer expected to compile.
* testsuite/27_io/rvalue_streams.cc: Adjust existing test.
Verify LWG 1203 changes.
Jonathan Wakely [Tue, 4 May 2021 15:28:57 +0000 (16:28 +0100)]
libstdc++: Fix null dereferences in std::promise
This fixes some ubsan errors in std::promise:
future:1153:34: runtime error: member call on null pointer of type 'struct element_type'
future:1153:34: runtime error: member access within null pointer of type 'struct element_type'
The problem is that the check for a null pointer is done inside the
_State::__Setter function, which is only evaluated after evaluating the
_M_future->_M_set_result postfix-expression.
This change adds a new promise::_M_state() helper for accessing
_M_future, and moves the check for no shared state into there, instead
of inside the __setter functions. The __setter functions are made
always_inline, to avoid the situation where the linker selects the old
version of set_value (without the _S_check call) and the new version of
__setter (without the _S_check call) and so there is no check. With the
always_inline attribute the old version of set_value will either inline
the old __setter or call an extern definition of it, and the new
set_value will do the check itself, so both versions do the check.
libstdc++-v3/ChangeLog:
* include/std/future (promise::set_value): Check for existence
of shared state before dereferncing it.
(promise::set_exception, promise::set_value_at_thread_exit)
(promise::set_exception_at_thread_exit): Likewise.
(promise<R&>::set_value, promise<R&>::set_exception)
(promise<R&>::set_value_at_thread_exit)
(promise<R&>::set_exception_at_thread_exit): Likewise.
(promise<void>::set_value, promise<void>::set_exception)
(promise<void>::set_value_at_thread_exit)
(promise<void>::set_exception_at_thread_exit): Likewise.
* testsuite/30_threads/promise/members/at_thread_exit2.cc:
Remove unused variable.
Jonathan Wakely [Tue, 4 May 2021 14:49:38 +0000 (15:49 +0100)]
libstdc++: Fix undefined behaviour in std::string
This fixes a ubsan error when constructing a string with a null pointer:
bits/basic_string.h:534:21: runtime error: applying non-zero offset 18446744073709551615 to null pointer
The _M_construct function only cares whether the second pointer is
non-null, so create a non-null value without undefined arithmetic.
We can also pass the random_access_iterator_tag directly to the
_M_construct function, to avoid going via the tag dispatching
_M_construct_aux, because we know we have pointers not integers here.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (basic_string(const CharT*, const A&)):
Do not do arithmetic on null pointer.
Jonathan Wakely [Tue, 4 May 2021 14:28:39 +0000 (15:28 +0100)]
libstdc++: Fix undefined behaviour in testsuite
Fix some test bugs found by ubsan.
libstdc++-v3/ChangeLog:
* testsuite/20_util/from_chars/3.cc: Use unsigned type to avoid
overflow.
* testsuite/24_iterators/reverse_iterator/2.cc: Do not add
non-zero value to null pointer.
* testsuite/25_algorithms/copy_backward/move_iterators/69478.cc:
Use past-the-end iterator for result.
* testsuite/25_algorithms/move_backward/69478.cc: Likewise.
* testsuite/25_algorithms/move_backward/93872.cc: Likewise.
Jonathan Wakely [Tue, 4 May 2021 11:16:46 +0000 (12:16 +0100)]
libstdc++: Do not use deduced return type for std::visit [PR 100384]
This avoids errors outside the immediate context when std::visit is an
overload candidate because of ADL, but not actually viable.
The solution is to give std::visit a non-deduced return type. New
helpers are introduced for that, and existing ones refactored slightly.
libstdc++-v3/ChangeLog:
PR libstdc++/100384
* include/std/variant (__get_t): New alias template yielding the
return type of std::get<N> on a variant.
(__visit_result_t): New alias template yielding the result of
std::visit.
(__same_types): Move into namespace __detail::__variant.
(__check_visitor_results): Likewise. Use __invoke_result_t and
__get_t.
(__check_visitor_result): Remove.
(visit): Use __visit_result_t for return type.
* testsuite/20_util/variant/100384.cc: New test.
The builtin vec_permi is peculiar in that its immediate operand is
encoded differently than the immediate operand that is backing the
builtin. This fixes the check for the immediate operand, adding a
regression test in the process.
2021-05-06 Marius Hillenbrand <mhillen@linux.ibm.com>
gcc/ChangeLog:
* config/s390/s390-builtins.def (O_M5, O1_M5, ...): Remove unused macros.
(s390_vec_permi_s64, s390_vec_permi_b64, s390_vec_permi_u64)
(s390_vec_permi_dbl, s390_vpdi): Use the O3_U2 type for the immediate
operand.
* config/s390/s390.c (s390_const_operand_ok): Remove unused
values.
gcc/testsuite/ChangeLog:
* gcc.target/s390/zvector/imm-range-error-1.c: Fix test for
__builtin_s390_vpdi.
* gcc.target/s390/zvector/vec-permi.c: New test for builtin
vec_permi.
Roman Zhuykov [Thu, 6 May 2021 11:55:26 +0000 (14:55 +0300)]
modulo-sched: skip loops with strange register defs [PR100225]
PR84878 fix adds an assertion which can fail, e.g. when stack pointer
is adjusted inside the loop. We have to prevent it and search earlier
for any 'strange' instruction. The solution is to skip the whole loop
if using 'note_stores' we found that one of hard registers is in
'df->regular_block_artificial_uses' set.
Also patch properly prohibit not single-set instruction in loop body.
gcc/ChangeLog:
PR rtl-optimization/100225
PR rtl-optimization/84878
* modulo-sched.c (sms_schedule): Use note_stores to skip loops
where we have an instruction which touches (writes) any hard
register from df->regular_block_artificial_uses set.
Allow not-single-set instruction only right before basic block
tail.
gcc/testsuite/ChangeLog:
PR rtl-optimization/100225
PR rtl-optimization/84878
* gcc.dg/pr100225.c: New test.
libgomp/ChangeLog:
* testsuite/libgomp.oacc-c-c++-common/atomic_capture-3.c: New test.
IBM Z: Handle hard registers in s390_md_asm_adjust()
gen_fprx2_to_tf() and gen_tf_to_fprx2() cannot handle hard registers,
since the subregs they create do not pass validation. Change
s390_md_asm_adjust() to manually copy between hard VRs and FPRs instead
of using these two functions.
gcc/ChangeLog:
PR target/100217
* config/s390/s390.c (s390_hard_fp_reg_p): New function.
(s390_md_asm_adjust): Handle hard registers.
gcc/testsuite/ChangeLog:
PR target/100217
* gcc.target/s390/vector/long-double-asm-in-out-hard-fp-reg.c: New test.
* gcc.target/s390/vector/long-double-asm-inout-hard-fp-reg.c: New test.
Eric Botcazou [Wed, 5 May 2021 20:48:51 +0000 (22:48 +0200)]
Fix PR target/100402
This is a regression for 64-bit Windows present from mainline down to the 9
branch and introduced by the fix for PR target/99234. Again SEH, but with
a twist related to the way MinGW implements setjmp/longjmp, which turns out
to be piggybacked on SEH with recent versions of MinGW, i.e. the longjmp
performs a bona-fide unwinding of the stack, because it calls RtlUnwindEx
with the second argument initially passed to setjmp, which is the result of
__builtin_frame_address (0) in the MinGW header file:
This means that we directly expose the frame pointer to the SEH machinery
here (unlike with regular exception handling where we use an intermediate
CFA) and thus that we cannot do whatever we want with it. The old code
would leave it unaligned, i.e. not multiple of 16, whereas the new code
aligns it, but this breaks for some reason; at least it appears that a
.seh_setframe directive with 0 as second argument always works, so the
fix aligns it this way.
gcc/
PR target/100402
* config/i386/i386.c (ix86_compute_frame_layout): For a SEH target,
always return the establisher frame for __builtin_frame_address (0).
gcc/testsuite/
* gcc.c-torture/execute/20210505-1.c: New test.
Harald Anlauf [Wed, 5 May 2021 13:25:50 +0000 (15:25 +0200)]
PR fortran/100274 - ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
When the check for the length of formal and actual character arguments
found a mismatch and emitted a warning, it would skip further checks
like that could lead to errors. Fix that by continuing the checking.
Also catch a NULL pointer dereference.
gcc/fortran/ChangeLog:
PR fortran/100274
* interface.c (gfc_compare_actual_formal): Continue checks after
emitting warning for argument length mismatch.
* trans-expr.c (gfc_conv_procedure_call): Check for NULL pointer
dereference.
gcc/testsuite/ChangeLog:
PR fortran/100274
* gfortran.dg/argument_checking_25.f90: New test.
Patrick Palka [Wed, 5 May 2021 16:07:32 +0000 (12:07 -0400)]
libstdc++: Implement LWG 3517/3520 for join_view/transform_view
libstdc++-v3/ChangeLog:
* include/std/ranges (transform_view::_Iterator::iter_swap):
Remove as per LWG 3520.
(join_view::_Iterator::iter_swap): Add indirectly_swappable
constraint as per LWG 3517.
Eric Botcazou [Wed, 5 May 2021 14:50:55 +0000 (16:50 +0200)]
Fix PR rtl-optimization/100411
This is the bootstrap failure of GCC 11 on MinGW64 configured with --enable-
tune=nocona. The bottom line is that SEH does not support CFI for epilogues
but the x86 back-end nevertheless attaches it to instructions, so we have to
filter it out and this is done by detecting the end of the prologue by means
of the NOTE_INSN_PROLOGUE_END note.
But the compiler manages to generate a second epilogue before this note in
the RTL stream and this fools the aforementioned logic. The root cause is
cross-jumping, which inserts a jump before the end of the prologue, in fact
just before the note; the rest (CFG cleanup, BB reordering, etc) is downhill
from there.
gcc/
PR rtl-optimization/100411
* cfgcleanup.c (try_crossjump_to_edge): Also skip end of prologue
and beginning of function markers.
At some point DR_MISALIGNMENT was supposed to be -1 when the
access was not element aligned. That's obviously not true at this
point so this adjusts both store and load vectorizing to no longer
assume this which in turn allows simplifying the code.
2021-04-29 Richard Biener <rguenther@suse.de>
PR tree-optimization/100253
* tree-vect-stmts.c (vectorizable_load): Do not assume
element alignment when DR_MISALIGNMENT is -1.
(vectorizable_store): Likewise.
Richard Biener [Tue, 27 Apr 2021 07:41:38 +0000 (09:41 +0200)]
tree-optimization/100278 - handle mismatched code in TBAA adjust of PRE
PRE has code to adjust TBAA behavior for refs that expects the base
operation code to match. The testcase shows a case where we have
a VAR_DECL vs. a MEM_REF so add code to give up in such cases.
2021-04-27 Richard Biener <rguenther@suse.de>
PR tree-optimization/100278
* tree-ssa-pre.c (compute_avail): Give up when we cannot
adjust TBAA beacuse of mismatching bases.
Richard Biener [Wed, 28 Apr 2021 07:34:03 +0000 (09:34 +0200)]
ipa/100308 - properly update the callgraph when pruning EH in IPA CP
This makes sure to fall into the delete_unreachable_blocks_update_callgraph
handling to remove blocks becoming unreachable when removing EH edges
by tracking blocks to need EH cleanup and doing that after releasing
dominance info.
This fixes an ICE seen with gfortran.dg/gomp/pr88933.f90 when enhancing
DSE.
2021-04-28 Richard Biener <rguenther@suse.de>
PR ipa/100308
* ipa-prop.c (ipcp_modif_dom_walker::before_dom_children):
Track blocks to cleanup EH in new m_need_eh_cleanup.
(ipcp_modif_dom_walker::cleanup_eh): New.
(ipcp_transform_function): Release dominator info before
doing EH cleanup.
Richard Biener [Tue, 4 May 2021 11:39:14 +0000 (13:39 +0200)]
tree-optimization/100414 - compute dominance info in phiopt
phiopt now has dominator queries but fails to compute dominance
info.
2021-05-04 Richard Biener <rguenther@suse.de>
PR tree-optimization/100414
* tree-ssa-phiopt.c (get_non_trapping): Do not compute dominance
info here.
(tree_ssa_phiopt_worker): But unconditionally here.
This avoids reassociating asm goto defs because we have no idea
on which outgoing edge to insert defs.
2021-05-04 Richard Biener <rguenther@suse.de>
PR tree-optimization/100329
* tree-ssa-reassoc.c (can_reassociate_p): Do not reassociate
asm goto defs.
(insert_stmt_after): Assert we're not running into asm goto.
Jakub Jelinek [Sun, 2 May 2021 12:17:23 +0000 (14:17 +0200)]
nvptx: Fix up nvptx build against latest libstdc++ [PR100375]
The r12-220-gd96db15967e78d7cecea3b1cf3169ceb924678ac change
deprecated some non-standard std::pair constructors and that apparently
broke nvptx.c build, where pseudo_node_t is std::pair<struct basic_block_def *, int>
and so nullptr (or NULL) needs to be used for the first argument of the
ctors instead of 0.
2021-05-02 Jakub Jelinek <jakub@redhat.com>
PR target/100375
* config/nvptx/nvptx.c (nvptx_sese_pseudo): Use nullptr instead of 0
as first argument of pseudo_node_t constructors.
Patrick Palka [Mon, 3 May 2021 17:35:37 +0000 (13:35 -0400)]
c++: base-clause parsing and implicit 'this' [PR100362]
My r11-6815 change to defer access checking when processing a
base-clause removed a pair of pushclass / popclass calls that seemed to
be unnecessary now that we'd also defer access checking while parsing
the base-clause.
But it turns out these calls make a difference in the below testcase,
where we have a local class whose base-clause implicitly uses the 'this'
of the enclosing class. Before r11-6815, while parsing the base-clause
of the local class, maybe_resolve_dummy would fail to resolve the dummy
'this' object because the current scope would be the local class. Now,
since the current scope is the lambda, maybe_resolve_dummy succeeds and
returns the 'this' for the enclosing class Qux. Later, during deferred
instantiation of the local class, we get confused trying to resolve the
access of 'a_' through this non-dummy 'this'.
So this patch just reinstates the calls to pushclass / popclass that
were removed in r11-6815.
gcc/cp/ChangeLog:
PR c++/100362
* parser.c (cp_parser_class_head): Reinstate calls to pushclass
and popclass when parsing the base-clause that were removed in
r11-6815.
gcc/testsuite/ChangeLog:
PR c++/100362
* g++.dg/cpp1y/lambda-generic-100362.C: New test.
Follow up to PR100352, which moved unit unlocking to st_*_done_worker to
avoid lock order reversal; however, as async_io uses a different lock,
the (unlocked locked) unit lock shall not be unlocked there.
libgfortran/ChangeLog:
PR libgomp/100352
* io/transfer.c (st_read_done_worker, st_write_done_worker): Add new
arg whether to unlock unit.
(st_read_done, st_write_done): Call it with true.
* io/async.c (async_io): Call it with false.
* io/io.h (st_write_done_worker, st_read_done_worker): Update prototype.
which is an rtx the VAX backend currently does not recognize as a valid
machine address, although apparently it is only inside MEM rtx's that
indexed addressing is supposed to be canonicalized to a MULT rather than
ASHIFT form. Handle the ASHIFT form too throughout the backend then.
The change appears to also improve code generation with old reload and
code size stats are as follows, collected from 18153 executables built
in `check-c' GCC testing:
samples average median
--------------------------------------
regressions 47 0.702% 0.521%
unchanged 17503 0.000% 0.000%
progressions 603 -0.920% -0.403%
--------------------------------------
total 18153 -0.029% 0.000%
with a small number of outliers (over 5% size change):
Jonathan Wakely [Fri, 30 Apr 2021 19:32:05 +0000 (20:32 +0100)]
libstdc++: Fix inconsistent feature test macros
The __cpp_lib_constexpr_string and __cpp_lib_semaphore feature test
macros are not defined consistently in <version> and the relevant header
for the feature.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (__cpp_lib_constexpr_string):
Only define for C++17 and later.
* include/std/version (__cpp_lib_semaphore): Fix condition
to match the one in <semaphore>.
David Edelsohn [Fri, 30 Apr 2021 18:09:13 +0000 (14:09 -0400)]
aix: Alias -m64 to -maix64 and -m32 to -maix32.
GCC on AIX historically has used -maix64 and -maix32 to switch to 64 bit mode
or 32 bit mode, unlike other ports that use -m64 and -m32. The Alias()
directive for options cannot be used because aix64 is expected in multiple
parts of the compiler infrastructure and one cannot switch to -m64 due to
backward compatibility.
This patch defines DRIVER_SELF_SPECS to translate -m64 to -maix64 and
-m32 to -maix32 so that the command line option compatible with other
targets can be used while continuing to allow the historical options.
As noted in r11-1339-gb6ab9ecd550227684643b41e9e33a4d3466724d8 we define
a non-standard __cpp_lib_constexpr_char_traits feature test macro to
indicate support for P0426R1 and P1032R1. At some point last year the
__cpp_lib_constexpr_string macro was retconned to indicate support for
those papers. This adds the new macro (which we didn't previously
define, because it referred to P0980R1 "Making std::string constexpr"
which we don't support).
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (__cpp_lib_constexpr_string): Define.
* include/std/version (__cpp_lib_constexpr_string): Define.
* testsuite/21_strings/char_traits/requirements/constexpr_functions_c++17.cc:
Check for __cpp_lib_constexpr_string.
* testsuite/21_strings/char_traits/requirements/constexpr_functions_c++20.cc:
Likewise.
* testsuite/21_strings/char_traits/requirements/version.cc: New test.
Richard Earnshaw [Wed, 28 Apr 2021 16:56:38 +0000 (17:56 +0100)]
arm: fix UB due to missing mode check [PR100311]
Some places in the compiler iterate over all the fixed registers to
check if that register can be used in a particular mode. The idiom is
to iterate over the register and then for that register, if it
supports the current mode to check all that register and any
additional registers needed (HARD_REGNO_NREGS). If these two checks
are not fully aligned then it is possible to generate a buffer overrun
when testing data objects that are sized by the number of hard regs in
the machine.
The VPR register is a case where these checks were not consistent and
because this is the last HARD register the result was that we ended up
overflowing the fixed_regs array.
gcc:
PR target/100311
* config/arm/arm.c (arm_hard_regno_mode_ok): Only allow VPR to be
used in HImode.
(cherry picked from commit 59f5d16f2c5db4d9592c8ce6453afe81334bb012)
Jakub Jelinek [Thu, 29 Apr 2021 09:42:08 +0000 (11:42 +0200)]
testsuite: Remove dg-options from pr100305.c [PR100305]
The test FAILs on i?86-linux (due to -Wpsabi warnings). But, on closer
inspection it seems there is another problem, the dg-options in the testcase
means that the test is compiled with -O0 -O, -O1 -O, -O2 -O, -O3 -O, -Os -O
etc. options, so effectively is tested multiple times with the same options.
Fixed by dropping the dg-options line, then we have -w by default and iterate
over all the optimization levels (including the -O).
Jakub Jelinek [Thu, 29 Apr 2021 09:34:50 +0000 (11:34 +0200)]
aarch64: Fix ICE in aarch64_add_offset_1_temporaries [PR100302]
In PR94121 I've changed aarch64_add_offset_1 to use absu_hwi instead of
abs_hwi because offset can be HOST_WIDE_INT_MIN. As can be seen with
the testcase below, aarch64_add_offset_1_temporaries suffers from the same
problem and should be in sync with aarch64_add_offset_1, i.e. for
HOST_WIDE_INT_MIN it needs a temporary.
2021-04-29 Jakub Jelinek <jakub@redhat.com>
PR target/100302
* config/aarch64/aarch64.c (aarch64_add_offset_1_temporaries): Use
absu_hwi instead of abs_hwi.
Jakub Jelinek [Thu, 29 Apr 2021 09:11:37 +0000 (11:11 +0200)]
c++: Fix up detach clause vs. data-sharing clause checking [PR100319]
The standard says that "The event-handle will be considered as if it
was specified on a firstprivate clause." which means that it can't
be explicitly specified in some other data-sharing clause.
The checking is implemented correctly for C, but for C++ when detach_seen
is true (i.e. the construct had detach clause) we were comparing
OMP_CLAUSE_DECL (c) with t, which was previously initialized to
OMP_CLAUSE_DECL (c), which means it complained about any explicit
data-sharing clause on the same construct with a detach clause.
Fixed by remembering the detach clause in detach_seen (instead of a boolean
flag) and comparing against its OMP_CLAUSE_DECL.
2021-04-29 Jakub Jelinek <jakub@redhat.com>
PR c++/100319
* semantics.c (finish_omp_clauses): Fix up check that variable
mentioned in detach clause doesn't appear in data-sharing clauses.
Tom de Vries [Wed, 28 Apr 2021 14:00:01 +0000 (16:00 +0200)]
[omp, simt] Fix expand_GOMP_SIMT_*
When running the test-case included in this patch using an
nvptx accelerator, it fails in execution.
The problem is that the expansion of GOMP_SIMT_XCHG_BFLY is optimized away
during pass_jump as "trivially dead insns".
This is caused by this code in expand_GOMP_SIMT_XCHG_BFLY:
...
class expand_operand ops[3];
create_output_operand (&ops[0], target, mode);
...
expand_insn (targetm.code_for_omp_simt_xchg_bfly, 3, ops);
...
which doesn't guarantee that target is assigned to by the expanded insn.
F.i., if target is:
...
(gdb) call debug_rtx ( target )
(subreg/s/u:QI (reg:SI 40 [ _61 ]) 0)
...
then after expand_insn, we have:
...
(gdb) call debug_rtx ( ops[0].value )
(reg:QI 57)
...
See commit 3af3bec2e4d "internal-fn: Avoid dropping the lhs of some
calls [PR94941]" for a similar problem.
Fix this in the same way, by adding:
...
if (!rtx_equal_p (target, ops[0].value))
emit_move_insn (target, ops[0].value);
...
where applicable in the expand_GOMP_SIMT_* functions.
Tested libgomp on x86_64 with nvptx accelerator.
gcc/ChangeLog:
2021-04-28 Tom de Vries <tdevries@suse.de>
PR target/100232
* internal-fn.c (expand_GOMP_SIMT_ENTER_ALLOC)
(expand_GOMP_SIMT_LAST_LANE, expand_GOMP_SIMT_ORDERED_PRED)
(expand_GOMP_SIMT_VOTE_ANY, expand_GOMP_SIMT_XCHG_BFLY)
(expand_GOMP_SIMT_XCHG_IDX): Ensure target is assigned to.
aarch64: Fix address mode for vec_concat pattern [PR100305]
The load_pair_lanes<mode> patterns match a vec_concat of two
adjacent 64-bit memory locations as a single 128-bit load.
The Utq constraint made sure that the address was suitable
for a 128-bit vector, but this meant that it allowed some
addresses that aren't valid for the 64-bit element mode.
Two obvious fixes were:
(1) Continue to accept addresses that aren't valid for the element
modes. This would mean changing the mode of operands[1] before
printing it. It would also mean using a custom predicate instead
of the current memory_operand.
(2) Restrict addresses to the intersection of those that are valid
element and vector addresses.
The problem with (1) is that, as well as being more complicated,
it doesn't deal with the fact that we still have a memory_operand
for the second element. If we encourage the first operand to be
outside the range of a normal element memory_operand, we'll have
to reload the second operand to make it valid. This reload will
often be dead code, but will be kept around because the RTL
pattern makes it look as though the second element address
is still needed.
This patch therefore does (2) instead.
As mentioned in the PR notes, I think we have a general problem
with the way that the aarch64 port deals with paired addresses.
There's nothing to guarantee that the two addresses will be
reloaded in a way that keeps them “obviously” adjacent, so the
rtx_equal_p conditions could fail if something rechecked them
later.
For this particular pattern, I think it would be better to teach
simplify-rtx.c to fold the vec_concat to a normal vector memory
reference, to remove any suggestion that targets should try to
match the unsimplified form. That obviously wouldn't be suitable
for backports though.
gcc/
PR target/100305
* config/aarch64/constraints.md (Utq): Require the address to
be valid for both the element mode and for V2DImode.
gcc/testsuite/
PR target/100305
* gcc.c-torture/compile/pr100305.c: New test.
aarch64: Handle SVE attributes in comp_type_attributes [PR100270]
Even though "SVE type" and "SVE sizeless type" are marked as
affecting type identity, the middle end doesn't truly believe
it unless we also handle them in comp_type_attributes.
gcc/
PR target/100270
* config/aarch64/aarch64.c (aarch64_comp_type_attributes): Handle
SVE attributes.
gcc/testsuite/
PR target/100270
* gcc.target/aarch64/sve/acle/general-c/pr100270_1.c: New test.
* gcc.target/aarch64/sve/acle/general-c/sizeless-2.c: Change
expected error message when subtracting pointers to different
vector types. Expect warnings when mixing them elsewhere.
* gcc.target/aarch64/sve/acle/general/attributes_7.c: Remove
XFAILs. Tweak error messages for some cases.
Both symbols are local. However, libbpf bpf_object__variable_offset
rquires symbols to be STB_GLOBAL & STT_OBJECT for data section lookup.
This patch makes the same declaration generate:
Jonathan Wakely [Wed, 28 Apr 2021 11:45:49 +0000 (12:45 +0100)]
libstdc++: Add missing noexcept on std::thread member function [PR 100298]
The new inline definition of std::thread::hardware_concurrency() for
non-gthreads targets is missing the noexcept-specifier that is on the
declaration.
libstdc++-v3/ChangeLog:
PR libstdc++/100298
* include/bits/std_thread.h (thread::hardware_concurrency): Add
missing noexcept to inline definition for non-gthreads targets.
Richard Earnshaw [Tue, 27 Apr 2021 11:25:30 +0000 (12:25 +0100)]
arm: fix UB when compiling thumb2 with PIC [PR100236]
arm_compute_save_core_reg_mask contains UB in that the saved PIC
register number is used to create a bit mask. However, for some target
options this register is undefined and we end up with a shift of ~0.
On native compilations this is benign since the shift will still be
large enough to move the bit outside of the range of the mask, but if
cross compiling from a system that truncates out-of-range shifts to
zero (or worse, raises a trap for such values) we'll get potentially
wrong code (or a fault).
gcc:
PR target/100236
* config/arm/arm.c (THUMB2_WORK_REGS): Check PIC_OFFSET_TABLE_REGNUM
is valid before including it in the mask.
(cherry picked from commit 01d0bda8bdf3cd804e1e00915d432ad0cdc49399)
64bit loads to/stores from x87 and SSE registers are atomic also on 32-bit
targets, so there is no need for additional atomic moves to a temporary
register.
Introduced load peephole2 patterns assume that there won't be any additional
loads from the load location outside the peepholed sequence and wrongly
removed the source location initialization.
OTOH, introduced store peephole2 patterns assume there won't be any additional
loads from the stored location outside the peepholed sequence and wrongly
removed the destination location initialization. Note that we can't use plain
x87 FST instruction to initialize destination location because FST converts
the value to the double-precision format, changing bits during move.
The patch restores removed initializations in load and store patterns.
Additionally, plain x87 FST in store peephole2 patterns is prevented by
limiting the store operand source to SSE registers.
2021-04-27 Uroš Bizjak <ubizjak@gmail.com>
gcc/
PR target/100182
* config/i386/sync.md (FILD_ATOMIC/FIST_ATOMIC FP load peephole2):
Copy operand 3 to operand 4. Use sse_reg_operand
as operand 3 predicate.
(FILD_ATOMIC/FIST_ATOMIC FP load peephole2 with mem blockage): Ditto.
(LDX_ATOMIC/STX_ATOMIC FP load peephole2): Ditto.
(LDX_ATOMIC/LDX_ATOMIC FP load peephole2 with mem blockage): Ditto.
(FILD_ATOMIC/FIST_ATOMIC FP store peephole2):
Copy operand 1 to operand 0.
(FILD_ATOMIC/FIST_ATOMIC FP store peephole2 with mem blockage): Ditto.
(LDX_ATOMIC/STX_ATOMIC FP store peephole2): Ditto.
(LDX_ATOMIC/LDX_ATOMIC FP store peephole2 with mem blockage): Ditto.
Patrick Palka [Tue, 27 Apr 2021 18:07:46 +0000 (14:07 -0400)]
libstdc++: Fix up lambda in join_view::_Iterator::operator++ [PR100290]
Currently, the return type of this lambda is decltype(auto), so the
lambda ends up returning a copy of _M_parent->_M_inner rather than a
reference to it when _S_ref_glvalue is false. This means _M_inner and
ranges::end(__inner_range) are respectively an iterator and sentinel for
different ranges, so comparing them is undefined.
libstdc++-v3/ChangeLog:
PR libstdc++/100290
* include/std/ranges (join_view::_Iterator::operator++): Correct
the return type of the lambda to avoid returning a copy of
_M_parent->_M_inner.
* testsuite/std/ranges/adaptors/join.cc (test10): New test.
Patrick Palka [Sat, 24 Apr 2021 04:14:29 +0000 (00:14 -0400)]
c++: do_class_deduction and dependent init [PR93383]
Here we're crashing during CTAD with a dependent initializer (performed
from convert_template_argument) because one of the initializer's
elements has an empty TREE_TYPE, which ends up making resolve_args
unhappy.
Besides the case where we're initializing one template placeholder
from another, which is already specifically handled earlier in
do_class_deduction, it seems we can't in general correctly resolve a
template placeholder using a dependent initializer, so this patch makes
the function just punt until instantiation time instead.
gcc/cp/ChangeLog:
PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* pt.c (do_class_deduction): Punt if the initializer is
type-dependent.
gcc/testsuite/ChangeLog:
PR c++/89565
PR c++/93383
PR c++/95291
PR c++/99200
PR c++/99683
* g++.dg/cpp2a/nontype-class39.C: Remove dg-ice directive.
* g++.dg/cpp2a/nontype-class45.C: New test.
* g++.dg/cpp2a/nontype-class46.C: New test.
* g++.dg/cpp2a/nontype-class47.C: New test.
* g++.dg/cpp2a/nontype-class48.C: New test.
Harald Anlauf [Sat, 24 Apr 2021 18:51:41 +0000 (20:51 +0200)]
PR fortran/100154 - ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
Add appropriate static checks for the character and status arguments to
the GNU Fortran intrinsic extensions fget[c], fput[c]. Extend variable
check to allow a function reference having a data pointer result.
gcc/fortran/ChangeLog:
PR fortran/100154
* check.c (variable_check): Allow function reference having a data
pointer result.
(arg_strlen_is_zero): New function.
(gfc_check_fgetputc_sub): Add static check of character and status
arguments.
(gfc_check_fgetput_sub): Likewise.
* intrinsic.c (add_subroutines): Fix argument name for the
character argument to intrinsic subroutines fget[c], fput[c].
gcc/testsuite/ChangeLog:
PR fortran/100154
* gfortran.dg/pr100154.f90: New test.
Marek Polacek [Wed, 21 Apr 2021 00:24:09 +0000 (20:24 -0400)]
c++: Prevent bogus -Wtype-limits warning with NTTP [PR100161]
Recently, we made sure that we never call value_dependent_expression_p
on an expression that isn't potential_constant_expression. That caused
this bogus warning with a non-type template parameter, something that
users don't want to see.
The problem is that in tsubst_copy_and_build/LE_EXPR 't' is "i < n",
which, due to 'i', is not p_c_e, therefore we call t_d_e_p. But the
type of 'n' isn't dependent, so we think the whole 't' expression is
not dependent. It seems we need to test both op0 and op1 separately
to suppress this warning.
gcc/cp/ChangeLog:
PR c++/100161
* pt.c (tsubst_copy_and_build) <case PLUS_EXPR>: Test op0 and
op1 separately for value- or type-dependence.
gcc/testsuite/ChangeLog:
PR c++/100161
* g++.dg/warn/Wtype-limits6.C: New test.
Marek Polacek [Tue, 20 Apr 2021 16:16:04 +0000 (12:16 -0400)]
c++: Don't allow defining types in enum-base [PR96380]
In r11-2064 I made cp_parser_enum_specifier commit to tentative parse
when seeing a '{'. That still looks like the correct thing to do, but
it caused an ICE-on-invalid as well as accepts-invalid.
When we have something sneaky like this, which is broken in multiple
ways:
template <class>
enum struct c : union enum struct c { e = b, f = a };
we parse the "enum struct c" part (that's OK) and then we see that
we have an enum-base, so we consume ':' and then parse the type-specifier
that follows the :. "union enum" is clearly invalid, but we're still
parsing tentatively and we parse everything up to the ;, and then
throw away the underlying type. We parsed everything because we were
tricked into parsing an enum-specifier in an enum-base of another
enum-specifier! Not good.
Since the grammar for enum-base doesn't allow a defining-type-specifier,
only a type-specifier, we should set type_definition_forbidden_message
which fixes all the problems in this PR.
libgomp/testsuite: Fix checks for dg-excess-errors
For the tests modified below, the effective target line has to be effective
when compiling for an offload target, except that variable-not-offloaded.c
would compile with unified-share memory and pr86416-*.c if long double/float128
is supported.
The previous check used a run-time device ability check. This new variant
now enables those dg- lines when _compiling_ for nvptx or gcn.
libgomp/ChangeLog:
* testsuite/lib/libgomp.exp (offload_target_to_openacc_device_type):
New, based on check_effective_target_offload_target_nvptx.
(check_effective_target_offload_target_nvptx): Call it.
(check_effective_target_offload_target_amdgcn): New.
* testsuite/libgomp.c-c++-common/function-not-offloaded.c:
Require target offload_target_nvptx || offload_target_amdgcn.
* testsuite/libgomp.c-c++-common/variable-not-offloaded.c: Likewise.
* testsuite/libgomp.c/pr86416-1.c: Likewise.
* testsuite/libgomp.c/pr86416-2.c: Likewise.
projects / thirdparty / gcc.git / log
