Jonathan Wakely [Mon, 17 May 2021 10:54:06 +0000 (11:54 +0100)]
libstdc++: Fix filesystem::path constraints for volatile [PR 100630]
The constraint check for filesystem::path construction uses
decltype(__is_path_src(declval<Source>())) which mean it considers
conversion from an rvalue. When Source is a volatile-qualified type
it cannot use is_path_src(const Unknown&) because a const lvalue
reference can only bind to a non-volatile rvalue.
Since the relevant path members all have a const Source& parameter,
the constraint should be defined in terms of declval<const Source&>(),
not declval<Source>(). This avoids the problem of volatile-qualified
rvalues, because we no longer use an rvalue at all.
libstdc++-v3/ChangeLog:
PR libstdc++/100630
* include/experimental/bits/fs_path.h (__is_constructible_from):
Test construction from a const lvalue, not an rvalue.
* testsuite/27_io/filesystem/path/construct/100630.cc: New test.
* testsuite/experimental/filesystem/path/construct/100630.cc:
New test.
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h (__waiter::_M_do_wait_v): loop
until value change observed.
(__waiter_base::_M_laundered): New member.
(__waiter_base::_M_notify): Check _M_laundered to determine
whether to wake one or all.
(__detail::__atomic_compare): Return true if call to
__builtin_memcmp() == 0.
(__waiter_base::_S_do_spin_v): Adjust predicate.
* testsuite/29_atomics/atomic/wait_notify/100334.cc: New
test.
Alex Coplan [Tue, 27 Apr 2021 13:56:15 +0000 (14:56 +0100)]
arm: Fix ICEs with compare-and-swap and -march=armv8-m.base [PR99977]
The PR shows two ICEs with __sync_bool_compare_and_swap and
-mcpu=cortex-m23 (equivalently, -march=armv8-m.base): one in LRA and one
later on, after the CAS insn is split.
The LRA ICE occurs because the
@atomic_compare_and_swap<CCSI:arch><SIDI:mode>_1 pattern attempts to tie
two output operands together (operands 0 and 1 in the third
alternative). LRA can't handle this, since it doesn't make sense for an
insn to assign to the same operand twice.
The later (post-splitting) ICE occurs because the expansion of the
cbranchsi4_scratch insn doesn't quite go according to plan. As it
stands, arm_split_compare_and_swap calls gen_cbranchsi4_scratch,
attempting to pass a register (neg_bval) to use as a scratch register.
However, since the RTL template has a match_scratch here,
gen_cbranchsi4_scratch ignores this argument and produces a scratch rtx.
Since this is all happening after RA, this is doomed to fail (and we get
an ICE about the insn not matching its constraints).
It seems that the motivation for the choice of constraints in the
atomic_compare_and_swap pattern comes from an attempt to satisfy the
constraints of the cbranchsi4_scratch insn. This insn requires the
scratch register to be the same as the input register in the case that
we use a larger negative immediate (one that satisfies J, but not L).
Of course, as noted above, LRA refuses to assign two output operands to
the same register, so this was never going to work.
The solution I'm proposing here is to collapse the alternatives to the
CAS insn (allowing the two output register operands to be matched to
different registers) and to ensure that the constraints for
cbranchsi4_scratch are met in arm_split_compare_and_swap. We do this by
inserting a move to ensure the source and destination registers match if
necessary (i.e. in the case of large negative immediates).
Another notable change here is that we only do:
emit_move_insn (neg_bval, const1_rtx);
for non-negative immediates. This is because the ADDS instruction used in
the negative case suffices to leave a suitable value in neg_bval: if the
operands compare equal, we don't take the branch (so neg_bval will be
set by the load exclusive). Otherwise, the ADDS will leave a nonzero
value in neg_bval, which will correctly signal that the CAS has failed
when it is later negated.
gcc/ChangeLog:
PR target/99977
* config/arm/arm.c (arm_split_compare_and_swap): Fix up codegen
with negative immediates: ensure we expand cbranchsi4_scratch
correctly and ensure we satisfy its constraints.
* config/arm/sync.md
(@atomic_compare_and_swap<CCSI:arch><NARROW:mode>_1): Don't
attempt to tie two output operands together with constraints;
collapse two alternatives.
(@atomic_compare_and_swap<CCSI:arch><SIDI:mode>_1): Likewise.
* config/arm/thumb1.md (cbranchsi4_neg_late): New.
gcc/testsuite/ChangeLog:
PR target/99977
* gcc.target/arm/pr99977.c: New test.
Richard Biener [Mon, 17 May 2021 06:51:03 +0000 (08:51 +0200)]
Update mpfr version to 3.1.6
This updates the mpfr version to 3.1.6 which is the last bugfix
release from the 3.1.x series and avoids printing the version
is buggy but acceptable from our configury.
2021-05-17 Richard Biener <rguenther@suse.de>
contrib/ChangeLog:
* download_prerequisites: Update mpfr version to 3.1.6.
* prerequisites.md5: Update.
* prerequisites.sha512: Likewise.
arm: Remove duplicate definitions from arm_mve.h (pr100419).
This patch removes several duplicated intrinsic definitions from
arm_mve.h mentioned in PR100419 and also fixes the wrong arguments
in few of intrinsics polymorphic variants.
Richard Earnshaw [Thu, 13 May 2021 10:42:58 +0000 (11:42 +0100)]
arm: correctly handle inequality comparisons against max constants [PR100563]
Normally we expect the gimple optimizers to fold away comparisons that
are always true, but at some lower optimization levels this is not
always the case, so the back-end has to be able to generate correct
code in these cases.
In this example, we have a comparison of the form
(unsigned long long) op <= ~0ULL
which, of course is always true.
Normally, in the arm back-end we handle these expansions where the
immediate cannot be handled directly by adding 1 to the constant and
then adjusting the comparison operator:
(unsigned long long) op < CONST + 1
but we cannot do that when the constant is already the largest value.
Fortunately, we observe that the comparisons we need to handle this
way are either always true or always false, so instead of forming a
comparison against the maximum value, we can replace it with a
comparison against the minimum value (which just happens to also be a
constant we can handle. So
gcc:
PR target/100563
* config/arm/arm.c (arm_canonicalize_comparison): Correctly
canonicalize DImode inequality comparisons against the
maximum integral value.
Patrick Palka [Fri, 30 Apr 2021 14:59:20 +0000 (10:59 -0400)]
libstdc++: Implement P2367 changes to avoid some list-initialization
This implements the wording changes of P2367R0 "Remove misuses of
list-initialization from Clause 24", modulo the parts that depend
on P1739R4 which we don't yet implement (due to LWG 3407).
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (subrange::subrange): Avoid
list-initialization in delegating constructor.
* include/std/ranges (single_view): Replace implicit guide
with explicit deduction guide that decays its argument.
(_Single::operator()): Avoid CTAD when constructing the
single_view object.
(_Iota::operator()): Avoid list-initialization.
(__detail::__can_filter_view, _Filter::operator()): Likewise.
(__detail::__can_transform_view, _Transform::operator()): Likewise.
(take_view::begin): Likewise.
(__detail::__can_take_view, _Take::operator()): Likewise.
(__detail::__can_take_while_view, _TakeWhile::operator()): Likewise.
(__detail::__can_drop_view, _Drop::operator()): Likewise.
(__detail::__can_drop_while_view, _DropWhile::operator()): Likewise.
(split_view::split_view): Use views::single when initializing
_M_pattern.
(__detail::__can_split_view, _Split::operator()): Avoid
list-initialization.
(_Counted::operator()): Likewise.
* testsuite/std/ranges/p2367.cc: New test.
Jakub Jelinek [Wed, 12 May 2021 13:14:35 +0000 (15:14 +0200)]
libcpp: Fix up -fdirectives-only preprocessing of includes not ending with newline [PR100392]
If a header doesn't end with a new-line, with -fdirectives-only we right now
preprocess it as
int i = 1;# 2 "pr100392.c" 2
i.e. the line directive isn't on the next line, which means we fail to parse
it when compiling.
GCC 10 and earlier libcpp/directives-only.c had for this:
if (!pfile->state.skipping && cur != base)
{
/* If the file was not newline terminated, add rlimit, which is
guaranteed to point to a newline, to the end of our range. */
if (cur[-1] != '\n')
{
cur++;
CPP_INCREMENT_LINE (pfile, 0);
lines++;
}
cb->print_lines (lines, base, cur - base);
}
and we have the assertion
/* Files always end in a newline or carriage return. We rely on this for
character peeking safety. */
gcc_assert (buffer->rlimit[0] == '\n' || buffer->rlimit[0] == '\r');
So, this patch just does readd the more less same thing, so that we emit
a newline after the inline even when it wasn't there before.
2021-05-12 Jakub Jelinek <jakub@redhat.com>
PR preprocessor/100392
* lex.c (cpp_directive_only_process): If buffer doesn't end with '\n',
add buffer->rlimit[0] character to the printed range and
CPP_INCREMENT_LINE and increment line_count.
* gcc.dg/cpp/pr100392.c: New test.
* gcc.dg/cpp/pr100392.h: New file.
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.
git://gcc.gnu.org / gcc.git / log