Tobias Burnus [Fri, 14 May 2021 07:30:01 +0000 (09:30 +0200)]
OpenMP: Support complex/float in && and || reduction
C/C++ permit logical AND and logical OR also with floating-point or complex
arguments by doing an unequal zero comparison; the result is an 'int' with
value one or zero. Hence, those are also permitted as reduction variable,
even though it is not the most sensible thing to do.
gcc/c/ChangeLog:
* c-typeck.c (c_finish_omp_clauses): Accept float + complex
for || and && reductions.
gcc/cp/ChangeLog:
* semantics.c (finish_omp_reduction_clause): Accept float + complex
for || and && reductions.
gcc/ChangeLog:
* omp-low.c (lower_rec_input_clauses, lower_reduction_clauses): Handle
&& and || with floating-point and complex arguments.
gcc/testsuite/ChangeLog:
* gcc.dg/gomp/clause-1.c: Use 'reduction(&:..)' instead of '...(&&:..)'.
libgomp/ChangeLog:
* testsuite/libgomp.c-c++-common/reduction-1.c: New test.
* testsuite/libgomp.c-c++-common/reduction-2.c: New test.
* testsuite/libgomp.c-c++-common/reduction-3.c: New test.
Tom de Vries [Fri, 14 May 2021 07:24:47 +0000 (09:24 +0200)]
Disable SIMT for user-defined reduction
The test-case included in this patch contains this target region:
...
for (int i0 = 0 ; i0 < N0 ; i0++ )
counter_N0.i += 1;
...
When running with nvptx accelerator, the counter variable is expected to
be N0 after the region, but instead is N0 / 32. The problem is that rather
than getting the result for all warp lanes, we get it for just one lane.
This is caused by the implementation of SIMT being incomplete. It handles
regular reductions, but appearantly not user-defined reductions.
For now, handle this by disabling SIMT in this case, specifically by setting
sctx->max_vf to 1.
Tested libgomp on x86_64-linux with nvptx accelerator.
gcc/ChangeLog:
2021-05-03 Tom de Vries <tdevries@suse.de>
PR target/100321
* omp-low.c (lower_rec_input_clauses): Disable SIMT for user-defined
reduction.
libgomp/ChangeLog:
2021-05-03 Tom de Vries <tdevries@suse.de>
PR target/100321
* testsuite/libgomp.c/target-44.c: New test.
Tom de Vries [Fri, 14 May 2021 07:21:36 +0000 (09:21 +0200)]
Handle alternative IV
Consider the test-case libgomp.c/pr81778.c added in this commit, with
this core loop (note: CANARY_SIZE set to 0 for simplicity):
...
int s = 1;
#pragma omp target simd
for (int i = N - 1; i > -1; i -= s)
a[i] = 1;
...
which, given that N is 32, sets a[0..31] to 1.
On nvptx, the first time bb6 is executed, i is in the 0..31 range (depending
on the lane that is executing) at bb entry.
So we have the following sequence:
- a[0..31] is set to 1
- i is updated to -32..-1
- D.3209 is updated to 1 (being 0 initially)
- bb19 is executed, and if condition (D.3209 < D.3213) == (1 < 32) evaluates
to true
- bb6 is once more executed, which should not happen because all the elements
that needed to be handled were already handled.
- consequently, elements that should not be written are written
- with CANARY_SIZE == 0, we may run into a libgomp error:
...
libgomp: cuCtxSynchronize error: an illegal memory access was encountered
...
and with CANARY_SIZE unmodified, we run into:
...
Expected 0, got 1 at base[-961]
Aborted (core dumped)
...
The cause of this is as follows:
- because the step s is a variable rather than a constant, an alternative
IV (D.3209 in our example) is generated in expand_omp_simd, and the
loop condition is tested in terms of the alternative IV rather than
the original IV (i in our example).
- the SIMT code in expand_omp_simd works by modifying step and initial value.
- The initial value fd->loop.n1 is loaded into a variable n1, which is
modified by the SIMT code and then used there-after.
- The step fd->loop.step is loaded into a variable step, which is modified
by the SIMT code, but afterwards there are uses of both step and
fd->loop.step.
- There are uses of fd->loop.step in the alternative IV handling code,
which should use step instead.
Fix this by introducing an additional variable orig_step, which is not
modified by the SIMT code and replacing all remaining uses of fd->loop.step
by either step or orig_step.
Build on x86_64-linux with nvptx accelerator, tested libgomp.
This fixes for-5.c and for-6.c FAILs I'm currently seeing on a quadro m1200
with driver 450.66.
gcc/ChangeLog:
2020-10-02 Tom de Vries <tdevries@suse.de>
* omp-expand.c (expand_omp_simd): Add step_orig, and replace uses of
fd->loop.step by either step or orig_step.
Tobias Burnus [Fri, 14 May 2021 07:44:19 +0000 (09:44 +0200)]
Fix fallout from merge from releases/gcc-11
Re-apply commit f963d6c79b1d52ce565c772166c3c3e1b1d0aa78 on nvptx.c:
"Remove duplicate SESE code in NVPTX backend"
The code got readded by a wrongly resolved merge conflict.
Apply to the OG11 code the change of the merge-conflict causing change:
commit da9c085ddbfe61e5954c8ec4e996240fa3a994c0
"nvptx: Fix up nvptx build against latest libstdc++ [PR100375]"
gcc/ChangeLog
* omp-sese.c (omp_sese_pseudo): Use nullptr instead of 0
as first argument of pseudo_node_t constructors.
* config/nvptx/nvptx.c (bb_pair_t, bb_pair_vec_t,
pseudo_node_t, bracket, bracket_vec_t,
bb_sese, bb_sese::~bb_sese, bb_sese::append, bb_sese::remove,
BB_SET_SESE, BB_GET_SESE, nvptx_sese_number, nvptx_sese_pseudo,
nvptx_sese_color, nvptx_find_sese): Remove again.
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.
Chung-Lin Tang [Wed, 5 May 2021 15:11:19 +0000 (08:11 -0700)]
OpenMP 5.0: Implement relaxation of implicit map vs. existing device mappings
This patch implements relaxing the requirements when a map with the implicit
attribute encounters an overlapping existing map. As the OpenMP 5.0 spec
describes on page 320, lines 18-27 (and 5.1 spec, page 352, lines 13-22):
"If a single contiguous part of the original storage of a list item with an
implicit data-mapping attribute has corresponding storage in the device data
environment prior to a task encountering the construct that is associated with
the map clause, only that part of the original storage will have corresponding
storage in the device data environment as a result of the map clause."
Also tracked in the OpenMP spec context as issue #1463:
https://github.com/OpenMP/spec/issues/1463
* gomp-constants.h (GOMP_MAP_IMPLICIT): New special map kind bits value.
(GOMP_MAP_FLAG_SPECIAL_BITS): Define helper mask for whole set of
special map kind bits.
(GOMP_MAP_NONCONTIG_ARRAY_P): Adjust test for non-contiguous array map
kind bits to be more specific.
(GOMP_MAP_IMPLICIT_P): New predicate macro for implicit map kinds.
gcc/ChangeLog:
* tree.h (OMP_CLAUSE_MAP_IMPLICIT_P): New access macro for 'implicit'
bit, using 'base.deprecated_flag' field of tree_node.
* tree-pretty-print.c (dump_omp_clause): Add support for printing
implicit attribute in tree dumping.
* gimplify.c (gimplify_adjust_omp_clauses_1):
Set OMP_CLAUSE_MAP_IMPLICIT_P to 1 if map clause is implicitly created.
(gimplify_adjust_omp_clauses): Adjust place of adding implicitly created
clauses, from simple append, to starting of list, after non-map clauses.
* omp-low.c (lower_omp_target): Add GOMP_MAP_IMPLICIT bits into kind
values passed to libgomp for implicit maps.
* target.c (gomp_map_vars_existing): Add 'bool implicit' parameter, add
implicit map handling to allow a "superset" existing map as valid case.
(get_kind): Adjust to filter out GOMP_MAP_IMPLICIT bits in return value.
(get_implicit): New function to extract implicit status.
(gomp_map_fields_existing): Adjust arguments in calls to
gomp_map_vars_existing, and add uses of get_implicit.
(gomp_map_vars_internal): Likewise.
* testsuite/libgomp.c-c++-common/target-implicit-map-1.c: New test.
OpenACC: Fix pattern in dg-bogus in Fortran testcases again
It turned out that a compiler built without offloading support
and one with can produce slightly different diagnostic.
Offloading support implies ENABLE_OFFLOAD which implies that
g->have_offload is set when offloading is actually needed.
In cgraphunit.c, the latter causes flag_generate_offload = 1,
which in turn affects tree.c's free_lang_data.
The result is that the front-end specific diagnostic gets reset
('tree_diagnostics_defaults (global_dc)'), which affects in this
case 'Warning' vs. 'warning' via the Fortran frontend.
Result: 'Warning:' vs. 'warning:'.
Side note: Other FE also override the diagnostic, leading to
similar differences, e.g. the C++ FE outputs mangled function
names differently, cf. patch thread.
libgomp/ChangeLog:
* testsuite/libgomp.oacc-fortran/par-reduction-2-1.f:
Use [Ww]arning in dg-bogus as FE diagnostic and default
diagnostic differ and the result depends on ENABLE_OFFLOAD.
* testsuite/libgomp.oacc-fortran/par-reduction-2-2.f: Likewise.
* testsuite/libgomp.oacc-fortran/parallel-dims.f90: Likewise.
* testsuite/libgomp.oacc-fortran/parallel-reduction.f90: Likewise.
gcc/testsuite/ChangeLog:
* gfortran.dg/goacc/classify-serial.f95:
Use [Ww]arning in dg-bogus as FE diagnostic and default
diagnostic differ and the result depends on ENABLE_OFFLOAD.
* gfortran.dg/goacc/kernels-decompose-2.f95: Likewise.
* gfortran.dg/goacc/routine-module-mod-1.f90: Likewise.
OpenACC: Fix pattern in dg-bogus in Fortran testcases
libgomp/ChangeLog:
* testsuite/libgomp.oacc-fortran/par-reduction-2-1.f:
Correct spelling in dg-bogus to match -Wopenacc-parallelism.
* testsuite/libgomp.oacc-fortran/par-reduction-2-2.f: Likewise.
* testsuite/libgomp.oacc-fortran/parallel-dims.f90: Likewise.
* testsuite/libgomp.oacc-fortran/parallel-reduction.f90: Likewise.
gcc/testsuite/ChangeLog:
* gfortran.dg/goacc/classify-serial.f95:
Correct spelling in dg-bogus to match -Wopenacc-parallelism.
* gfortran.dg/goacc/kernels-decompose-2.f95: Likewise.
* gfortran.dg/goacc/routine-module-mod-1.f90: Likewise.
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.
OG11 has additional warnings compared to mainline, which are not expected by
tests newly introduced in GCC 11. Also, some of the dump messages are now
emitted in the oaccloops pass rather than oaccdevlow.
projects / thirdparty / gcc.git / log
