Francois-Xavier Coudert [Sun, 4 Sep 2022 16:24:23 +0000 (18:24 +0200)]
Fortran: add IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES
The IEEE_MODES_TYPE type and the two functions that get and set it
were added in Fortran 2018. They can be implemented using the already
existing target-specific functions. A future optimization could, on
some targets, set/get all modes through one or two instructions only,
but that would need a new set of functions in all config/fpu-* files.
2022-09-04 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
libgfortran/
* ieee/ieee_exceptions.F90: Add IEEE_MODES_TYPE, IEEE_GET_MODES
and IEEE_SET_MODES.
* ieee/ieee_arithmetic.F90: Make them public in IEEE_ARITHMETIC
as well.
gcc/testsuite/
* gfortran.dg/ieee/modes_1.f90: New test.
Torbjörn SVENSSON [Thu, 15 Sep 2022 06:59:30 +0000 (08:59 +0200)]
Improve sorry message for -fzero-call-used-regs
When the -fzero-call-used-regs command line option is used with an
unsupported value, indicate that it's a value problem instead of an
option problem.
Without the patch, the error is:
In file included from gcc/testsuite/c-c++-common/zero-scratch-regs-8.c:5:
gcc/testsuite/c-c++-common/zero-scratch-regs-1.c: In function 'foo':
gcc/testsuite/c-c++-common/zero-scratch-regs-1.c:10:1: sorry, unimplemented: '-fzero-call-used-regs' not supported on this target
10 | }
| ^
With the patch, the error would be like this:
In file included from gcc/testsuite/c-c++-common/zero-scratch-regs-8.c:5:
gcc/testsuite/c-c++-common/zero-scratch-regs-1.c: In function 'foo':
gcc/testsuite/c-c++-common/zero-scratch-regs-1.c:10:1: sorry, unimplemented: argument 'all-arg' is not supported for '-fzero-call-used-regs' on this target
10 | }
| ^
2022-09-19 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
gcc/ChangeLog:
* targhooks.cc (default_zero_call_used_regs): Improve sorry
message.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Francois-Xavier Coudert [Wed, 31 Aug 2022 17:15:20 +0000 (19:15 +0200)]
Fortran: F2018 rounding modes changes
Add the new IEEE_AWAY rounding mode. It is unsupported on all known
targets, but could be supported by glibc and AIX as part of the C2x
proposal. Testing for now is minimal.
Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and
IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not
support radices other than 2.
2022-08-31 Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
gcc/fortran/
* libgfortran.h: Declare GFC_FPE_AWAY.
gcc/testsuite/
* gfortran.dg/ieee/rounding_2.f90: New test.
libgfortran/
* ieee/ieee_arithmetic.F90: Add RADIX argument to
IEEE_SET_ROUNDING_MODE and IEEE_GET_ROUNDING_MODE.
* config/fpu-387.h: Add IEEE_AWAY mode.
* config/fpu-aarch64.h: Add IEEE_AWAY mode.
* config/fpu-aix.h: Add IEEE_AWAY mode.
* config/fpu-generic.h: Add IEEE_AWAY mode.
* config/fpu-glibc.h: Add IEEE_AWAY mode.
* config/fpu-sysv.h: Add IEEE_AWAY mode.
Georg-Johann Lay [Mon, 19 Sep 2022 07:46:58 +0000 (09:46 +0200)]
Fix PR target/99184: Wrong cast from double to 16-bit and 32-bit ints
this patch fixed PR target/99184 which incorrectly rounded during 64-bit
(long) double to 16-bit and 32-bit integers.
The patch just removes the respective roundings from
libf7-asm.sx::to_integer and ::to_unsigned. Luckily, LibF7 does nowhere
use respective functions internally, the only user is in libf7.c::f7_exp
which reads
f7_round (qq, qq);
int16_t q = f7_get_s16 (qq);
so that f7_get_s16() operates on an already rounded value, and therefore
this code works unaltered with or without rounding in to_integer.
PR target/99184
libgcc/config/avr/libf7/
* libf7-asm.sx (to_integer, to_unsigned): Don't round 16-bit
and 32-bit integers.
GCC Administrator [Mon, 19 Sep 2022 00:17:27 +0000 (00:17 +0000)]
Daily bump.
Julian Brown [Wed, 7 Sep 2022 21:45:07 +0000 (21:45 +0000)]
OpenMP: Push attaches to end of clause list in "target" regions
This patch moves GOMP_MAP_ATTACH{_ZERO_LENGTH_ARRAY_SECTION} nodes to
the end of the clause list, for offload regions. This ensures that when
we do the attach operation, both the "attachment point" and the target
region have both already been mapped on the target. This avoids a
pathological case that can otherwise happen with struct sibling-list
handling.
This version of the patch moves the attach-node motion to
gimplify_adjust_omp_clauses.
2022-09-15 Julian Brown <julian@codesourcery.com>
gcc/
* gimplify.cc (omp_segregate_mapping_groups): Update comment.
(gimplify_adjust_omp_clauses): Move ATTACH and
ATTACH_ZERO_LENGTH_ARRAY_SECTION nodes to the end of the clause list
for offloaded OpenMP regions.
gcc/testsuite/
* g++.dg/gomp/target-lambda-1.C: Adjust expected scan output.
Thomas Neumann [Sun, 18 Sep 2022 09:31:01 +0000 (11:31 +0200)]
Remove dependency on uintptr_t in libgcc
uintptr_t is no available for all targets, use __UINTPTR_TYPE__
instead.
libgcc/ChangeLog:
* unwind-dw2-fde.c: Replace uintptr_t with typedef
for __UINTPTR_TYPE__.
* unwind-dw2-btree.h: Likewise.
Palmer Dabbelt [Sat, 3 Sep 2022 01:28:10 +0000 (18:28 -0700)]
RISC-V: Don't try to vectorize tree-ssa/gen-vect-34.c
We don't yet support vectorization on RISC-V.
gcc/testsuite/ChangeLog
* gcc.dg/tree-ssa/gen-vect-34.c: Skip RISC-V targets.
Jakub Jelinek [Sat, 17 Sep 2022 06:50:22 +0000 (08:50 +0200)]
[PR106831] Avoid propagating long doubles that may have multiple representations.
Long doubles are tricky when it comes to considering singletons
because small numbers and +-INF can have multiple representations for
the same number. So we need to be very careful not to treat those as
singletons, lest they be incorrectly propagated by VRP. This is
similar to the -0.0 and +0.0 duality.
In long doubles +INF can be represented with +INF in the MSB and
either -0.0 or +0.0 in the LSB. Similarly for numbers that are exactly
representable in DF. For example, 1.0 can be represented as either
(1.0, +0.0) or (1.0, -0.0).
This patch avoids treating these numbers as singletons.
Note that NANs in long double format have a LSB of don't care, but
this is irrelevant for singleton_p, because NANs are never considered
singletons. Also, internally in the frange we store NANs as a pair of
boolean flags indicating whether they are +NAN or -NAN, so we don't need
any special treatment here for comparing range equality etc. We never
see anything but the boolean flags.
PR middle-end/106831
gcc/ChangeLog:
* value-range.cc (frange::singleton_p): Avoid propagating long
doubles that may have multiple representations.
Aldy Hernandez [Wed, 14 Sep 2022 06:32:34 +0000 (08:32 +0200)]
Rewrite NAN and sign handling in frange
The attatched patch rewrites the NAN and sign handling, dropping both
tristates in favor of a pair of boolean flags for NANs, and nothing at
all for signs. The signs are tracked in the range itself, so now it's
possible to describe things like [-0.0, +0.0] +NAN, [+0, +0], [-5, +0],
[+0, 3] -NAN, etc.
Here is an example of the various ranges and how they are displayed:
[frange] float VARYING NAN ;; Varying includes NAN
[frange] UNDEFINED ;; Empty set as always
[frange] float [] +-NAN ;; Unknown sign NAN
[frange] float [] -NAN ;; -NAN
[frange] float [] +NAN ;; +NAN
[frange] float [-0.0, 0.0] ;; All zeros.
[frange] float [-0.0, -0.0] +-NAN ;; -0 or NAN.
[frange] float [-5.0e+0, -1.0e+0] +NAN ;; [-5, -1] or +NAN
[frange] float [-5.0e+0, -0.0] +-NAN ;; [-5, -0] or NAN
[frange] float [-5.0e+0, -0.0] ;; [-5, -0]
[frange] float [5.0e+0, 1.0e+1] ;; [5, 10]
Notice the NAN signs are decoupled from the range, so we can represent
a negative range with a positive NAN. For this range,
frange::signbit_p() would return false, as only when the signs of the
NANs and range agree can we be certain.
There is no longer any pessimization of ranges for intersects
involving NANs. Also, union and intersect work with signed zeros:
// [-0, x] U [+0, x] => [-0, x]
// [ x, -0] U [ x, +0] => [ x, +0]
// [-0, x] ^ [+0, x] => [+0, x]
// [ x, -0] ^ [ x, +0] => [ x, -0]
The special casing for signed zeros in the singleton code is gone in
favor of just making sure the signs in the range agree, that is
[-0, -0] for example.
I have removed the idea that a known NAN is a "range", so a NAN is no
longer in the endpoints itself. Requesting the bound of a known NAN
is a hard fail. For that matter, we don't store the actual NAN in the
range. The only information we have are the set of boolean flags.
This way we make sure nothing seeps into the frange. This also means
it's explicit that we don't track anything but the sign in NANs. We
can revisit this if we desire to track signalling or whatever
concoction y'all can imagine.
Regstrapped with mpfr tests on x86-64 and ppc64le Linux. Selftests
were also run with -ffinite-math-only on x86-64.
At Jakub's suggestion, I built lapack with associated tests. They
pass on x86-64 and ppc64le Linux with no regressions from mainline.
As a sanity check, I also ran them for -ffinite-math-only on x86 which
(as expected) returned:
NaN arithmetic did not perform per the ieee spec
Otherwise, all tests pass for -ffinite-math-only.
gcc/ChangeLog:
* range-op-float.cc (frange_add_zeros): Replace set_signbit with
union of zero.
* value-query.cc (range_query::get_tree_range): Remove set_signbit
use.
* value-range-pretty-print.cc (vrange_printer::print_frange_prop):
Remove.
(vrange_printer::print_frange_nan): New.
* value-range-pretty-print.h (print_frange_prop): Remove.
(print_frange_nan): New.
* value-range-storage.cc (frange_storage_slot::set_frange): Set
kind and NAN fields.
(frange_storage_slot::get_frange): Restore kind and NAN fields.
* value-range-storage.h (class frange_storage_slot): Add kind and
NAN fields.
* value-range.cc (frange::update_nan): Remove.
(frange::set_signbit): Remove.
(frange::set): Adjust for NAN fields.
(frange::normalize_kind): Remove m_props.
(frange::combine_zeros): New.
(frange::union_nans): New.
(frange::union_): Handle new NAN fields.
(frange::intersect_nans): New.
(frange::intersect): Handle new NAN fields.
(frange::operator=): Same.
(frange::operator==): Same.
(frange::contains_p): Same.
(frange::singleton_p): Remove special case for signed zeros.
(frange::verify_range): Adjust for new NAN fields.
(frange::set_zero): Handle signed zeros.
(frange::set_nonnegative): Same.
(range_tests_nan): Adjust tests.
(range_tests_signed_zeros): Same.
(range_tests_signbit): Same.
(range_tests_floats): Same.
* value-range.h (class fp_prop): Remove.
(FP_PROP_ACCESSOR): Remove.
(class frange_props): Remove
(frange::lower_bound): NANs don't have endpoints.
(frange::upper_bound): Same.
(frange_props::operator==): Remove.
(frange_props::union_): Remove.
(frange_props::intersect): Remove.
(frange::update_nan): New.
(frange::clear_nan): New.
(frange::undefined_p): New.
(frange::set_nan): New.
(frange::known_finite): Adjust for new NAN representation.
(frange::maybe_isnan): Same.
(frange::known_isnan): Same.
(frange::signbit_p): Same.
* gimple-range-fold.cc (range_of_builtin_int_call): Rename
known_signbit_p into signbit_p.
GCC Administrator [Sun, 18 Sep 2022 00:17:03 +0000 (00:17 +0000)]
Daily bump.
Jan-Benedict Glaw [Sat, 17 Sep 2022 13:40:28 +0000 (15:40 +0200)]
Fix unsigned comparison warning
When -mfloat-abi=hard support was added, a cast went missing that
used to silence a warning in common code:
/usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o builtins.o -MT builtins.o -MMD -MP -MF ./.deps/builtins.TPo ../../gcc/gcc/builtins.cc
In file included from ./tm.h:21,
from ../../gcc/gcc/backend.h:28,
from ../../gcc/gcc/builtins.cc:27:
../../gcc/gcc/builtins.cc: In function 'int apply_args_size()':
../../gcc/gcc/config/csky/csky.h:421:13: error: comparison of unsigned expression in '>= 0' is always true [-Werror=type-limits]
421 | (((REGNO) >= CSKY_FIRST_PARM_REGNUM \
../../gcc/gcc/builtins.cc:1444:13: note: in expansion of macro 'FUNCTION_ARG_REGNO_P'
1444 | if (FUNCTION_ARG_REGNO_P (regno))
| ^~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1146: builtins.o] Error 1
The needed (int) cast is even mentioned in the comment above, so reinstate
it here.
gcc/ChangeLog:
* config/csky/csky.h (FUNCTION_ARG_REGNO_P): Cast REGNO to (int)
to prevent warning.
Patrick Palka [Sat, 17 Sep 2022 13:16:53 +0000 (09:16 -0400)]
c++: modules ICE with typename friend
A couple of xtreme-header-* modules tests began ICEing in C++23 mode
ever since r13-2650-g5d84a4418aa962 which introduced into <ranges> a
dependently scoped friend declaration:
friend /* typename */ _OuterIter::value_type;
This happens because the streaming code assumes a TYPE_P friend must
be a class type, but here it's a TYPENAME_TYPE, which doesn't have
a TEMPLATE_INFO or CLASSTYPE_BEFRIENDING_CLASSES. This patch tries
to correct this in a minimal way.
gcc/cp/ChangeLog:
* module.cc (friend_from_decl_list): Don't consider
CLASSTYPE_TEMPLATE_INFO for a TYPENAME_TYPE friend.
(trees_in::read_class_def): Don't add to
CLASSTYPE_BEFRIENDING_CLASSES for a TYPENAME_TYPE friend.
gcc/testsuite/ChangeLog:
* g++.dg/modules/typename-friend_a.C: New test.
* g++.dg/modules/typename-friend_b.C: New test.
Jakub Jelinek [Sat, 17 Sep 2022 06:18:24 +0000 (08:18 +0200)]
reassoc: Fix up recent regression in optimize_range_tests_cmp_bitwise [PR106958]
As the following testcase reduced from glibc fmtmsg.c shows
(it doesn't ICE on x86_64/i686 unfortunately, but does on various other
arches), my last optimize_range_tests_cmp_bitwise change wasn't fully
correct. The intent was to let all pointer operands be cast to
pointer_sized_int_node first in addition to the other casts (to type1)
which are done for id >= l cases.
But one spot I've touched used always cast to type1 (note, the (b % 4) == 3
case is impossible for pointer operands because that is for !TYPE_UNSIGNED
operands and pointers are TYPE_UNSIGNED) and in the other spot the cast
would be done only for id >= l if not useless, but for pointers we need
to cast it always.
2022-09-17 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/106958
* tree-ssa-reassoc.cc (optimize_range_tests_cmp_bitwise): If
id >= l, cast op to type1, otherwise to pointer_sized_int_node.
If type has pointer type, cast exp to pointer_sized_int_node
even when id < l.
* gcc.c-torture/compile/pr106958.c: New test.
GCC Administrator [Sat, 17 Sep 2022 00:17:20 +0000 (00:17 +0000)]
Daily bump.
Eugene Rozenfeld [Fri, 16 Sep 2022 23:25:25 +0000 (16:25 -0700)]
Fix for an AutoFDO test.
After https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=
c17975d81aaed49ff759c20c68b31304a6953d58
the expected inlining in indir-call--prof-2.c test happens during afdo phase instead of einline.
This patch adjusts the test accordingly.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-prof/indir-call-prof-2.c: Fix dg-final-use-autofdo.
Thomas Neumann [Tue, 1 Mar 2022 20:57:35 +0000 (21:57 +0100)]
eliminate mutex in fast path of __register_frame
The __register_frame/__deregister_frame functions are used to register
unwinding frames from JITed code in a sorted list. That list itself
is protected by object_mutex, which leads to terrible performance
in multi-threaded code and is somewhat expensive even if single-threaded.
There was already a fast-path that avoided taking the mutex if no
frame was registered at all.
This commit eliminates both the mutex and the sorted list from
the atomic fast path, and replaces it with a btree that uses
optimistic lock coupling during lookup. This allows for fully parallel
unwinding and is essential to scale exception handling to large
core counts.
libgcc/ChangeLog:
* unwind-dw2-fde.c (release_registered_frames): Cleanup at shutdown.
(__register_frame_info_table_bases): Use btree in atomic fast path.
(__deregister_frame_info_bases): Likewise.
(_Unwind_Find_FDE): Likewise.
(base_from_object): Make parameter const.
(classify_object_over_fdes): Add query-only mode.
(get_pc_range): Compute PC range for lookup.
* unwind-dw2-fde.h (last_fde): Make parameter const.
* unwind-dw2-btree.h: New file.
Jonathan Wakely [Thu, 15 Sep 2022 20:02:32 +0000 (21:02 +0100)]
libstdc++: Add preprocessor conditions for freestanding [PR106953]
This adds checks for _GLIBCXX_HOSTED to a number of headers which are
not currently installed for freestanding, but need to be for P1642R11
support. For example, <iterator> needs to be installed for C++23
freestanding mode, but without stream iterators and streambuf iterators.
Similarly, <memory> needs to be installed, but without std::allocator
and std::shared_ptr. This change disables the non-freestanding parts of
those headers.
libstdc++-v3/ChangeLog:
PR libstdc++/106953
* include/backward/auto_ptr.h [!_GLIBCXX_HOSTED]: Do not define
shared_ptr members.
* include/bits/alloc_traits.h [!_GLIBCXX_HOSTED]: Do not declare
std::allocator_traits<std::allocator<T>> specializations for
freestanding.
* include/bits/memoryfwd.h [!_GLIBCXX_HOSTED] (allocator): Do
not declare for freestanding.
* include/bits/stl_algo.h [!_GLIBCXX_HOSTED] (stable_partition):
Do not define for freestanding.
[!_GLIBCXX_HOSTED] (merge, stable_sort): Do not use temporary
buffers for freestanding.
* include/bits/stl_algobase.h [!_GLIBCXX_HOSTED]: Do not declare
streambuf iterators and overloaded algorithms using them.
* include/bits/stl_uninitialized.h [!_GLIBCXX_HOSTED]: Do not
define specialized overloads for std::allocator.
* include/bits/unique_ptr.h [!_GLIBCXX_HOSTED] (make_unique)
(make_unique_for_overwrite, operator<<): Do not define for
freestanding.
* include/c_global/cstdlib [!_GLIBCXX_HOSTED] (_Exit): Declare.
Use _GLIBCXX_NOTHROW instead of throw().
* include/debug/assertions.h [!_GLIBCXX_HOSTED]: Ignore
_GLIBCXX_DEBUG for freestanding.
* include/debug/debug.h [!_GLIBCXX_DEBUG]: Likewise.
* include/std/bit [!_GLIBCXX_HOSTED]: Do not use the custom
__int_traits if <ext/numeric_traits.h> is available.
* include/std/functional [!_GLIBCXX_HOSTED]: Do not include
headers that aren't valid for freestanding.
(boyer_moore_searcher, boyer_moore_horspool_searcher): Do not
define for freestanding.
* include/std/iterator [!_GLIBCXX_HOSTED]: Do not include
headers that aren't valid for freestanding.
* include/std/memory [!_GLIBCXX_HOSTED]: Likewise.
* include/std/ranges [!_GLIBCXX_HOSTED] (istream_view): Do not
define for freestanding.
(views::__detail::__is_basic_string_view) [!_GLIBCXX_HOSTED]:
Do not define partial specialization for freestanding.
Jonathan Wakely [Fri, 16 Sep 2022 20:29:44 +0000 (21:29 +0100)]
libstdc++: Move allocator-related helpers to <bits/alloc_traits.h>
The __alloc_swap and __shrink_to_fit_aux helpers are not specific to
std::allocator, so don't belong in <bits/allocator.h>. This also
simplifies enabling <memory> for freestanding, as now we can just omit
the whole of <bits/allocator.h> for freestanding.
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h (__alloc_swap)
(__shrink_to_fit_aux): Move here, from ...
* include/bits/allocator.h: ... here.
* include/ext/alloc_traits.h: Do not include allocator.h.
Jonathan Wakely [Fri, 16 Sep 2022 09:49:54 +0000 (10:49 +0100)]
libstdc++: Make more internal headers include their own dependencies
This adds required headers to a few internal headers that currently
assume their deps will be included first. It's more robust to make them
include their own dependencies, so that later refactoring or reuse of
those headers in new contexts doesn't break.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h: Include <bits/stl_algobase.h>.
* include/bits/stl_tempbuf.h: Include headers for __try and
__catch macros, std::pair, and __gnu_cxx::__numeric_traits.
* include/bits/stream_iterator.h: Include <iosfwd> and headers
for std::addressof and std::iterator.
* include/bits/streambuf_iterator.h: Include header for
std::iterator.
* include/std/iterator: Do not include <iosfwd>.
Jonathan Wakely [Fri, 16 Sep 2022 16:50:21 +0000 (17:50 +0100)]
libstdc++: Fix compare_exchange_padding.cc test for std::atomic_ref
This test was written assuming that std::atomic_ref clears its target's
padding on construction, but that could introduce data races. Change the
test to store a value after construction and check that its padding is
cleared by the store.
libstdc++-v3/ChangeLog:
* testsuite/29_atomics/atomic_ref/compare_exchange_padding.cc:
Store value with non-zero padding bits after construction.
Patrick Palka [Fri, 16 Sep 2022 15:10:43 +0000 (11:10 -0400)]
c++: 'mutable' member within constexpr [PR92505]
This patch permits accessing 'mutable' members of local objects during
constexpr evaluation, while continuing to reject it for global objects
(as in the last line of cpp0x/constexpr-mutable1.C). To distinguish
between the two cases, it looks like it suffices to just check
CONSTRUCTOR_MUTABLE_POSION in cxx_eval_component_reference before
deciding to reject a DECL_MUTABLE_P member access.
PR c++/92505
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_component_reference): Check non_constant_p
sooner. In C++14 or later, reject a DECL_MUTABLE_P member access
only if CONSTRUCTOR_MUTABLE_POISION is also set.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-mutable3.C: New test.
* g++.dg/cpp1y/constexpr-mutable1.C: New test.
Jonathan Wakely [Fri, 16 Sep 2022 14:40:06 +0000 (15:40 +0100)]
libstdc++: Fix tr1::variate_generator::engine_value_type
The tr1/5_numerical_facilities/random/variate_generator/37986.cc test
fails for strict -std=c++98 mode because _Adaptor(const _Engine&) is
ill-formed in C++98 when _Engine is a reference type.
Rather than attempt to make the _Adaptor handle references and pointers,
just strip references and pointers from the _Engine type before we adapt
it. That removes the need for the _Adaptor<_Engine*> partial
specialization and avoids the reference-to-reference problem for c++98
mode.
While looking into this I noticed that the TR1 spec requires the
variate_generator<E,D>::engine_value_type to be the underlying engine
type, whereas we make it the _Adaptor<E> type that wraps the engine.
libstdc++-v3/ChangeLog:
* include/tr1/random.h (__detail::_Adaptor::_BEngine): Remove.
(__detail::_Adaptor::_M_g): Make public.
(__detail::_Adaptor<_Engine*, _Dist>): Remove partial
specialization.
(variate_generate::_Value): New helper to simplify handling of
_Engine* and _Engine& template arguments.
(variate_generate::engine_value_type): Define to underlying
engine type, not adapted type.
(variate_generate::engine()): Return underlying engine instead
of adaptor.
* testsuite/tr1/5_numerical_facilities/random/variate_generator/37986.cc:
Fix comment.
* testsuite/tr1/5_numerical_facilities/random/variate_generator/requirements/typedefs.cc:
Check member typedefs have the correct types.
Jonathan Wakely [Fri, 16 Sep 2022 13:27:43 +0000 (14:27 +0100)]
libstdc++: Do not use nullptr in C++03-compatible code
This has to be valid as C++98/C++03.
libstdc++-v3/ChangeLog:
* include/debug/formatter.h [_GLIBCXX_DEBUG_BACKTRACE]
(_Error_formatter): Use 0 as null pointer constant.
Jonathan Wakely [Fri, 16 Sep 2022 10:39:41 +0000 (11:39 +0100)]
libstdc++: Remove __alloc_neq helper
This class template and partial specialization were added 15 years ago
to optimize allocator equality comparisons in std::list. I think it's
safe to assume that GCC is now capable of optimizing an inline
operator!= that just returns false at least as well as an inline member
function that just returns false.
libstdc++-v3/ChangeLog:
* include/bits/allocator.h (__alloc_neq): Remove.
* include/bits/stl_list.h (list::_M_check_equal_allocators):
Compare allocators directly, without __alloc_neq.
Jonathan Wakely [Fri, 16 Sep 2022 10:36:41 +0000 (11:36 +0100)]
libstdc++: Fix Doxygen commands
Remove the bogus -D__allocator_base=std::__new_allocator macro
definition for Doxygen, because that's an alias template for C++11 and
later, not a macro.
Fix the @cond/@endcond pair that span the end of an @addtogroup group.
Add another @endcond inside the group, and another @cond after it.
libstdc++-v3/ChangeLog:
* doc/doxygen/user.cfg.in (PREDEFINED): Remove __allocator_base.
* include/bits/allocator.h: Fix nesting of Doxygen commands.
Jason Merrill [Thu, 15 Sep 2022 20:55:50 +0000 (22:55 +0200)]
c++: member fn in omp loc list [PR106858]
this-f names a member function, which isn't an addressable lvalue. Give a
helpful error instead of crashing. The first hunk makes the error range
cover the whole expression.
PR c++/106858
gcc/cp/ChangeLog:
* parser.cc (cp_parser_omp_var_list_no_open): Pass the
initial token location down.
* semantics.cc (finish_omp_clauses): Check
invalid_nonstatic_memfn_p.
* typeck.cc (invalid_nonstatic_memfn_p): Handle null TREE_TYPE.
gcc/testsuite/ChangeLog:
* g++.dg/gomp/map-3.C: New test.
Jonathan Wakely [Fri, 16 Sep 2022 09:16:04 +0000 (10:16 +0100)]
libstdc++: Document new libstdc++.so symbol versions
libstdc++-v3/ChangeLog:
* doc/xml/manual/abi.xml: Document GLIBCXX_3.4.30 and
GLIBCXX_3.4.31 versions.
* doc/html/manual/abi.html: Regenerate.
liuhongt [Thu, 15 Sep 2022 10:43:16 +0000 (18:43 +0800)]
Modernize ix86_builtin_vectorized_function with corresponding expanders.
For ifloor/lfloor/iceil/lceil/irint/lrint/iround/lround when size of
in_mode is not equal out_mode, vectorizer doesn't go to internal fn
way,still left that part in the ix86_builtin_vectorized_function.
Remove others builtins and add corresponding expanders.
gcc/ChangeLog:
PR target/106910
* config/i386/i386-builtins.cc
(ix86_builtin_vectorized_function): Modernized with
corresponding expanders.
* config/i386/sse.md (lrint<mode><sseintvecmodelower>2): New
expander.
(floor<mode>2): Ditto.
(lfloor<mode><sseintvecmodelower>2): Ditto.
(ceil<mode>2): Ditto.
(lceil<mode><sseintvecmodelower>2): Ditto.
(btrunc<mode>2): Ditto.
(lround<mode><sseintvecmodelower>2): Ditto.
(exp2<mode>2): Ditto.
GCC Administrator [Fri, 16 Sep 2022 00:16:53 +0000 (00:16 +0000)]
Daily bump.
Jonathan Wakely [Thu, 15 Sep 2022 17:21:32 +0000 (18:21 +0100)]
libstdc++: Remove unnecessary header from <memory>
Previously <memory> included <bits/stl_algobase.h> so that std::copy,
std::fill etc. could be used by <bits/stl_uninitialized.h>. But that
includes it explicitly now, so that it can be compiled as a header unit.
There's no need to include it in <memory>, where its purpose isn't
obvious.
libstdc++-v3/ChangeLog:
* include/std/memory: Do not include <bits/stl_algobase.h>.
Harald Anlauf [Thu, 15 Sep 2022 20:39:24 +0000 (22:39 +0200)]
Fortran: catch NULL pointer dereferences while simplifying PACK [PR106857]
gcc/fortran/ChangeLog:
PR fortran/106857
* simplify.cc (gfc_simplify_pack): Check for NULL pointer dereferences
while walking through constructors (error recovery).
gcc/testsuite/ChangeLog:
PR fortran/106857
* gfortran.dg/pr106857.f90: New test.
Harald Anlauf [Thu, 15 Sep 2022 20:06:53 +0000 (22:06 +0200)]
Fortran: error recovery for bad deferred character length assignment [PR104314]
gcc/fortran/ChangeLog:
PR fortran/104314
* resolve.cc (deferred_op_assign): Do not try to generate temporary
for deferred character length assignment if types do not agree.
gcc/testsuite/ChangeLog:
PR fortran/104314
* gfortran.dg/pr104314.f90: New test.
Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org>
Joseph Myers [Thu, 15 Sep 2022 20:10:42 +0000 (20:10 +0000)]
float.h: Do not define INFINITY for C2x when infinities not supported
C2x has changed the rules for defining INFINITY in <float.h> so it is
no longer defined when float does not support infinities, instead of
being defined to an expression that overflows at translation time.
Thus, make the definition conditional on __FLT_HAS_INFINITY__ (this is
already inside a C2x-conditional part of <float.h>, because previous C
standard versions only had this macro in <math.h>).
Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also did a
spot test of the case of no infinities supported by building cc1 for
vax-netbsdelf and testing compiling the new c2x-float-11.c test with
it.
gcc/
* ginclude/float.h (INFINITY): Define only if
[__FLT_HAS_INFINITY__].
gcc/testsuite/
* gcc.dg/c2x-float-2.c: Require inff effective-target.
* gcc.dg/c2x-float-11.c: New test.
Jonathan Wakely [Thu, 15 Sep 2022 15:57:30 +0000 (16:57 +0100)]
libstdc++: Tweak TSan annotations for std::atomic<shared_ptr<T>>
Do not use the __tsan_mutex_not_static flag for annotation functions
where it's not a valid flag. Also use the try_lock and try_lock_failed
flags to more precisely annotate the CAS loop used to acquire a lock.
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_atomic.h (_GLIBCXX_TSAN_MUTEX_PRE_LOCK):
Replace with ...
(_GLIBCXX_TSAN_MUTEX_TRY_LOCK): ... this, add try_lock flag.
(_GLIBCXX_TSAN_MUTEX_TRY_LOCK_FAILED): New macro using
try_lock_failed flag
(_GLIBCXX_TSAN_MUTEX_POST_LOCK): Rename to ...
(_GLIBCXX_TSAN_MUTEX_LOCKED): ... this.
(_GLIBCXX_TSAN_MUTEX_PRE_UNLOCK): Remove invalid flag.
(_GLIBCXX_TSAN_MUTEX_POST_UNLOCK): Remove invalid flag.
(_Sp_atomic::_Atomic_count::lock): Use new macros.
Patrick Palka [Thu, 15 Sep 2022 17:16:51 +0000 (13:16 -0400)]
libstdc++: Implement ranges::chunk_by_view from P2443R1
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__adjacent_find_fn, adjacent_find):
Move to ...
* include/bits/ranges_util.h: ... here.
* include/std/ranges (chunk_by_view): Define.
(chunk_by_view::_Iterator): Define.
(__detail::__can_chunk_by_view): Define.
(_ChunkBy, chunk_by): Define.
* testsuite/std/ranges/adaptors/chunk_by/1.cc: New test.
François Dumont [Wed, 14 Sep 2022 17:14:48 +0000 (19:14 +0200)]
libstdc++: [_GLIBCXX_INLINE_VERSION] Fix test dg-prune-output
libstdc++-v3/ChangeLog:
* testsuite/20_util/is_complete_or_unbounded/memoization_neg.cc:
Adapt dg-prune-output to _GLIBCXX_INLINE_VERSION mode.
François Dumont [Wed, 14 Sep 2022 17:11:51 +0000 (19:11 +0200)]
libstdc++: [_GLIBCXX_INLINE_VERSION] Cleanup gnu-versioned-namespace.ver
Remove expressions for symbols in std::__detail::__8 namespace, they are obsolete since
version namespace applies only at std:: level, not at sub-levels.
libstdc++-v3/ChangeLog:
* config/abi/pre/gnu-versioned-namespace.ver: Remove obsolete std::__detail::__8
symbols.
Torbjörn SVENSSON [Thu, 15 Sep 2022 12:42:13 +0000 (14:42 +0200)]
MAINTAINERS: Add myself to Write After Approval
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
Richard Biener [Thu, 15 Sep 2022 11:33:23 +0000 (13:33 +0200)]
tree-optimization/106922 - PRE and virtual operand translation
PRE implicitely keeps virtual operands at the blocks incoming version
but the explicit updating point during PHI translation fails to trigger
when there are no PHIs at all in a block. Later lazy updating then
fails because of a too lose block check. A similar issues plagues
reference invalidation when checking the ANTIC_OUT to ANTIC_IN
translation. The following fixes both and makes the lazy updating
work.
The diagnostic testcase unfortunately requires boost so the
testcase is the one I reduced for a missed optimization in PRE.
The testcase fails with -m32 on x86_64 because we optimize too
much before PRE which causes PRE to not trigger so we fail to
eliminate a full redundancy. I'm going to open a separate bug
for this. Hopefully the !lp64 selector is good enough.
PR tree-optimization/106922
* tree-ssa-pre.cc (translate_vuse_through_block): Only
keep the VUSE if its def dominates PHIBLOCK.
(prune_clobbered_mems): Rewrite logic so we check whether
a value dies in a block when the VUSE def doesn't dominate it.
* g++.dg/tree-ssa/pr106922.C: New testcase.
Richard Biener [Wed, 14 Sep 2022 13:59:37 +0000 (15:59 +0200)]
Move void_list_node init to common code
All frontends replicate this, so move it.
gcc/
* tree.cc (build_common_tree_nodes): Initialize void_list_node
here.
gcc/ada/
* gcc-interface/trans.cc (gigi): Do not initialize void_list_node.
gcc/c-family/
* c-common.h (build_void_list_node): Remove.
* c-common.cc (c_common_nodes_and_builtins): Do not initialize
void_list_node.
gcc/c/
* c-decl.cc (build_void_list_node): Remove.
gcc/cp/
* decl.cc (cxx_init_decl_processing): Inline last
build_void_list_node call.
(build_void_list_node): Remove.
gcc/d/
* d-builtins.cc (d_build_c_type_nodes): Do not initialize
void_list_node.
gcc/fortran/
* f95-lang.cc (gfc_init_decl_processing): Do not initialize
void_list_node.
gcc/go/
* go-lang.cc (go_langhook_init): Do not initialize
void_list_node.
gcc/jit/
* dummy-frontend.cc (jit_langhook_init): Do not initialize
void_list_node.
gcc/lto/
* lto-lang.cc (lto_build_c_type_nodes): Do not initialize
void_list_node.
Julian Brown [Thu, 15 Sep 2022 12:01:28 +0000 (12:01 +0000)]
Fix c-c++-common/gomp/target-50.c test
The expected scan dump output for this test will change after the
following patch is committed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601558.html
But for now, this patch reverts to the old expected pattern so the test
passes. I will apply as obvious.
2022-09-15 Julian Brown <julian@codesourcery.com>
gcc/testsuite/
* c-c++-common/gomp/target-50.c: Modify scan pattern.
Julian Brown [Thu, 15 Sep 2022 11:32:36 +0000 (11:32 +0000)]
Fix c-c++-common/goacc/mdc-2.c and g++.dg/goacc/mdc.C tests
These testsuite hunks got left attached to the wrong patch in the series
I just posted. I will apply as obvious.
2022-09-15 Julian Brown <julian@codesourcery.com>
gcc/testsuite/
* c-c++-common/goacc/mdc-2.c: Update expected errors.
* g++.dg/goacc/mdc.C: Likewise.
Jiufu Guo [Mon, 5 Sep 2022 05:36:10 +0000 (13:36 +0800)]
rs6000: Using pli(paddi) and rotate to build 64bit constants
Hi,
Test cases are updated/added, and code is refined as the comments in the
review for previous version:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600768.html
As mentioned in PR106550, since pli could support 34bits immediate, we could
use less instructions(3insn would be ok) to build 64bits constant with pli.
For example, for constant 0x020805006106003, we could generate it with:
asm code1:
pli 9,
101736451 (0x6106003)
sldi 9,9,32
paddi 9,9, 2130000 (0x0208050)
or asm code2:
pli 10, 2130000
pli 9,
101736451
rldimi 9, 10, 32, 0
The asm code2 would be better.
This patch generates the asm code2 in split1 pass, this patch also supports
to generate asm code1 when splitter is only after RA.
This patch pass boostrap and regtest on ppc64. P10 testing is running.
Thanks for any comments!
BR,
Jeff(Jiufu)
PR target/106550
gcc/ChangeLog:
* config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Use pli.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr106550.c: New test.
* gcc.target/powerpc/pr106550_1.c: New test.
GCC Administrator [Thu, 15 Sep 2022 00:17:35 +0000 (00:17 +0000)]
Daily bump.
Jonathan Wakely [Wed, 14 Sep 2022 18:11:22 +0000 (19:11 +0100)]
libstdc++: Add TSan annotations to std::atomic<shared_ptr<T>>
This adds annotations to std::atomic<shared_ptr<T>> to enable TSan to
understand the custom locking. Without this, TSan reports data races for
accesses to the _M_ptr member, even though those are correctly
synchronized using atomic operations on the tagged pointer.
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_atomic.h (_GLIBCXX_TSAN_MUTEX_DESTROY)
(_GLIBCXX_TSAN_MUTEX_PRE_LOCK, _GLIBCXX_TSAN_MUTEX_POST_LOCK)
(_GLIBCXX_TSAN_MUTEX_PRE_UNLOCK, _GLIBCXX_TSAN_MUTEX_POST_UNLOCK)
(_GLIBCXX_TSAN_MUTEX_PRE_SIGNAL, _GLIBCXX_TSAN_MUTEX_POST_SIGNAL):
Define macros for TSan annotation functions.
(_Sp_atomic::_Atomic_count): Add annotations.
Jonathan Wakely [Wed, 14 Sep 2022 14:52:44 +0000 (15:52 +0100)]
libstdc++: Add missing <new> header to <bits/stl_tempbuf.h>
This is needed for std::nothrow and the nothrow operator new overload,
so should be included explicitly.
libstdc++-v3/ChangeLog:
* include/bits/stl_tempbuf.h: Include <new>.
Jonathan Wakely [Wed, 14 Sep 2022 13:16:25 +0000 (14:16 +0100)]
libstdc++: Add comment to 17_intro/names.cc test
libstdc++-v3/ChangeLog:
* testsuite/17_intro/names.cc: Explain why poison pragma can't
be used.
Jonathan Wakely [Wed, 14 Sep 2022 13:03:19 +0000 (14:03 +0100)]
libstdc++: Add assertion to std::promise::set_exception (LWG 2276)
Without this assertion, the shared state is made ready, but contains
neither a value nor an exception. Add an assertion to prevent users from
accessing a value that was never initialized in the shared state.
libstdc++-v3/ChangeLog:
* include/std/future
(_State_baseV2::__setter(exception_ptr&, promise&)): Add
assertion for LWG 2276 precondition.
* testsuite/30_threads/promise/members/set_exception_neg.cc:
New test.
Jonathan Wakely [Wed, 14 Sep 2022 12:48:25 +0000 (13:48 +0100)]
libstdc++: Document LWG 1203 API change in manual
libstdc++-v3/ChangeLog:
* doc/xml/manual/intro.xml: Document LWG 1203.
* doc/html/*: Regenerate.
Philipp Fent [Tue, 6 Sep 2022 21:24:29 +0000 (23:24 +0200)]
libstdc++: Add pretty printer for std::stringstreams
To display (o-,i-)stringstreams in the common case, we just print the
underlying stringbuf, without the many ios_base members. In the
unconventional case that the underlying streambuf was redirected, we
report the redirected target.
Signed-off-by: Philipp Fent <fent@in.tum.de>
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (access_streambuf_ptrs):
New helper function.
(StdStringBufPrinter, StdStringStreamPrinter): New printers.
(build_libstdcxx_dictionary): Register stringstream printers.
* testsuite/libstdc++-prettyprinters/debug.cc: Check string
streams.
* testsuite/libstdc++-prettyprinters/simple.cc: Likewise.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.
Aldy Hernandez [Wed, 14 Sep 2022 06:11:54 +0000 (08:11 +0200)]
frange: add both zeros to ranges when there's the possiblity of equality.
Every time there's equality at play, we must be careful that any
equality with zero matches both -0.0 and +0.0 when honoring signed
zeros.
We were doing this correctly for the == and != op1_range operators
(albeit inefficiently), but aren't doing it at all when building >=
and <=. This fixes the oversight.
There is change in functionality here for the build_* functions.
This is the last "simple" patch I submit before overhauling NAN and
sign tracking. And that will likely be after Cauldron because it will need
further testing (lapack, ppc64le, -ffinite-math-only, etc).
Regstrapped on x86-64 Linux, plus I ran selftests for
-ffinite-math-only.
gcc/ChangeLog:
* range-op-float.cc (frange_add_zeros): New.
(build_le): Call frange_add_zeros.
(build_ge): Same.
(foperator_equal::op1_range): Same.
(foperator_not_equal::op1_range): Same.
Aldy Hernandez [Wed, 14 Sep 2022 06:01:16 +0000 (08:01 +0200)]
Pass full range to build_* in range-op-float.cc
The build_<relop> helper functions in range-op-float.cc take the
actual value from the operand's endpoint, but this value could be
deduced from the operand itself therefore cleaning up the call site.
This also reduces the potential of mistakenly passing the wrong bound.
No functional changes.
Regstrapped on x86-64 Linux, plus I ran selftests for
-ffinite-math-only.
gcc/ChangeLog:
* range-op-float.cc (build_le): Accept frange instead of number.
(build_lt): Same.
(build_ge): Same.
(build_gt): Same.
(foperator_lt::op1_range): Pass full range to build_*.
(foperator_lt::op2_range): Same.
(foperator_le::op1_range): Same.
(foperator_le::op2_range): Same.
(foperator_gt::op1_range): Same.
(foperator_gt::op2_range): Same.
(foperator_ge::op1_range): Same.
(foperator_ge::op2_range): Same.
Aldy Hernandez [Wed, 14 Sep 2022 06:29:54 +0000 (08:29 +0200)]
Use frange::set_nan() from the generic frange::set().
This patch cleans up the frange::set() code by passing all things NAN
to frange::set_nan().
No functional changes.
Regstrapped on x86-64 Linux, plus I ran selftests for
-ffinite-math-only.
gcc/ChangeLog:
* value-range.cc (frange::set): Use set_nan.
* value-range.h (frange::set_nan): Inline code originally in
set().
Aldy Hernandez [Wed, 14 Sep 2022 04:58:35 +0000 (06:58 +0200)]
Provide cleaner set_nan(), clear_nan(), and update_nan() methods.
set_* has a very specific meaning for irange's and friends. Methods
prefixed with set_* are setters clobbering the existing range. As
such, the current set_nan() method is confusing in that it's not
actually setting a range to a NAN, but twiddling the NAN flags for an
existing frange.
This patch replaces set_nan() with an update_nan() to set the flag,
and clear_nan() to clear it. This makes the code clearer, and though
the confusing tristate is still there, it will be removed in upcoming
patches.
Also, there is now an actual set_nan() method to set the range to a
NAN. This replaces two out of class functions doing the same thing.
In future patches I will also add the ability to create a NAN with a
specific sign, but doing so now would be confusing because we're not
tracking NAN signs.
We should also submit set_signbit to the same fate, but it's about to
get removed.
No functional changes.
Regstrapped on x86-64 Linux, plus I ran selftests for
-ffinite-math-only.
gcc/ChangeLog:
* range-op-float.cc (frange_set_nan): Remove.
(build_lt): Use set_nan, update_nan, clear_nan.
(build_gt): Same.
(foperator_equal::op1_range): Same.
(foperator_not_equal::op1_range): Same.
(foperator_lt::op1_range): Same.
(foperator_lt::op2_range): Same.
(foperator_le::op1_range): Same.
(foperator_le::op2_range): Same.
(foperator_gt::op1_range): Same.
(foperator_gt::op2_range): Same.
(foperator_ge::op1_range): Same.
(foperator_ge::op2_range): Same.
(foperator_unordered::op1_range): Same.
(foperator_ordered::op1_range): Same.
* value-query.cc (range_query::get_tree_range): Same.
* value-range.cc (frange::set_nan): Same.
(frange::update_nan): Same.
(frange::union_): Same.
(frange::intersect): Same.
(range_tests_nan): Same.
(range_tests_signed_zeros): Same.
(range_tests_signbit): Same.
(range_tests_floats): Same.
* value-range.h (class frange): Add update_nan and clear_nan.
(frange::set_nan): New.
Aldy Hernandez [Wed, 14 Sep 2022 05:49:55 +0000 (07:49 +0200)]
Minor fixes to frange.
Following are a series of cleanups to the frange code in preparation
for a much more invasive patch rewriting the NAN and sign tracking
bits. Please be patient, as I'm trying to break everything up into
small chunks instead of dropping a mondo patch removing the NAN and
sign tristate handling.
No functional changes.
Regstrapped on x86-64 Linux, plus I ran selftests for
-ffinite-math-only.
gcc/ChangeLog:
* value-query.cc (range_query::get_tree_range): Remove check for overflow.
* value-range-pretty-print.cc (vrange_printer::visit): Move read
of type until after undefined_p is checked.
* value-range.cc (frange::set): Remove asserts for REAL_CST.
(frange::contains_p): Tidy up.
(range_tests_nan): Add comment.
* value-range.h (frange::type): Check for undefined_p.
(frange::set_undefined): Remove set of endpoints.
Julian Brown [Tue, 6 Sep 2022 22:34:38 +0000 (22:34 +0000)]
OpenMP/OpenACC: mapping group list-handling improvements
This patch adjusts OpenMP/OpenACC clause list handling in a couple of
places, in preparation for the following mapping-clause expansion rework
patch. Firstly mapping groups are removed as a whole in the C and C++
front-ends when an error is detected, which avoids leaving "badly-formed"
mapping clause groups in the list.
Secondly, reindexing of the omp_mapping_group hashmap (during
omp_build_struct_sibling_lists) has been reimplemented, fixing some
tricky corner-cases where mapping groups are removed from a list at the
same time as it is being reordered.
Thirdly, code to check if a different clause on the same directive maps
the whole of a struct that we have a component mapping for (for example)
has been outlined, removing a bit of code duplication.
2022-09-13 Julian Brown <julian@codesourcery.com>
gcc/
* gimplify.cc (omp_group_last): Allow GOMP_MAP_ATTACH_DETACH after
GOMP_MAP_STRUCT (for reindexing).
(omp_gather_mapping_groups): Reimplement using...
(omp_gather_mapping_groups_1): This new function. Stop processing at
GATHER_SENTINEL.
(omp_group_base): Allow GOMP_MAP_TO_PSET without any following node.
(omp_index_mapping_groups): Reimplement using...
(omp_index_mapping_groups_1): This new function. Handle
REINDEX_SENTINEL.
(omp_reindex_mapping_groups, omp_mapped_by_containing_struct): New
functions.
(omp_tsort_mapping_groups_1): Adjust handling of base group being the
same as current group. Use omp_mapped_by_containing_struct.
(omp_build_struct_sibling_lists): Use omp_mapped_by_containing_struct
and omp_reindex_mapping_groups. Robustify group deletion for reordered
lists.
(gimplify_scan_omp_clauses): Update calls to
omp_build_struct_sibling_lists.
gcc/c/
* c-typeck.cc (c_finish_omp_clauses): Remove whole mapping node group
on error.
gcc/cp/
* semantics.cc (finish_omp_clauses): Likewise.
Julian Brown [Wed, 16 Feb 2022 17:15:39 +0000 (09:15 -0800)]
OpenMP/OpenACC struct sibling list gimplification extension and rework
This patch refactors struct sibling-list processing in gimplify.cc, and
adjusts some related mapping-clause processing in the Fortran FE and
omp-low.cc accordingly.
2022-09-13 Julian Brown <julian@codesourcery.com>
gcc/fortran/
* trans-openmp.cc (gfc_trans_omp_clauses): Don't create
GOMP_MAP_TO_PSET mappings for class metadata, nor GOMP_MAP_POINTER
mappings for POINTER_TYPE_P decls.
gcc/
* gimplify.cc (gimplify_omp_var_data): Remove GOVD_MAP_HAS_ATTACHMENTS.
(GOMP_FIRSTPRIVATE_IMPLICIT): Renumber.
(insert_struct_comp_map): Refactor function into...
(build_omp_struct_comp_nodes): This new function. Remove list handling
and improve self-documentation.
(extract_base_bit_offset): Remove BASE_REF, OFFSETP parameters. Move
code to strip outer parts of address out of function, but strip no-op
conversions.
(omp_mapping_group): Add DELETED field for use during reindexing.
(omp_strip_components_and_deref, omp_strip_indirections): New functions.
(omp_group_last, omp_group_base): Add GOMP_MAP_STRUCT handling.
(omp_gather_mapping_groups): Initialise DELETED field for new groups.
(omp_index_mapping_groups): Notice DELETED groups when (re)indexing.
(omp_siblist_insert_node_after, omp_siblist_move_node_after,
omp_siblist_move_nodes_after, omp_siblist_move_concat_nodes_after): New
helper functions.
(omp_accumulate_sibling_list): New function to build up GOMP_MAP_STRUCT
node groups for sibling lists. Outlined from gimplify_scan_omp_clauses.
(omp_build_struct_sibling_lists): New function.
(gimplify_scan_omp_clauses): Remove struct_map_to_clause,
struct_seen_clause, struct_deref_set. Call
omp_build_struct_sibling_lists as pre-pass instead of handling sibling
lists in the function's main processing loop.
(gimplify_adjust_omp_clauses_1): Remove GOVD_MAP_HAS_ATTACHMENTS
handling, unused now.
* omp-low.cc (scan_sharing_clauses): Handle pointer-type indirect
struct references, and references to pointers to structs also.
gcc/testsuite/
* g++.dg/goacc/member-array-acc.C: New test.
* g++.dg/gomp/member-array-omp.C: New test.
* g++.dg/gomp/target-3.C: Update expected output.
* g++.dg/gomp/target-lambda-1.C: Likewise.
* g++.dg/gomp/target-this-2.C: Likewise.
* c-c++-common/goacc/deep-copy-arrayofstruct.c: Move test from here.
* c-c++-common/gomp/target-50.c: New test.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/deep-copy-15.c: New test.
* testsuite/libgomp.oacc-c-c++-common/deep-copy-16.c: New test.
* testsuite/libgomp.oacc-c++/deep-copy-17.C: New test.
* testsuite/libgomp.oacc-c-c++-common/deep-copy-arrayofstruct.c: Move
test to here, make "run" test.
Richard Biener [Wed, 14 Sep 2022 11:53:56 +0000 (13:53 +0200)]
tree-optimization/106938 - cleanup abnormal edges after inlining
After inlining and IPA transforms we run fixup_cfg to fixup CFG
effects in other functions. But that fails to clean abnormal
edges from non-pure/const calls which might no longer be necessary
when ->calls_setjmp is false. The following ensures this happens
and refactors things so we call EH/abnormal cleanup only on the
last stmt in a block.
PR tree-optimization/106938
* tree-cfg.cc (execute_fixup_cfg): Purge dead abnormal
edges for all last stmts in a block. Do EH cleanup
only on the last stmt in a block.
* gcc.dg/pr106938.c: New testcase.
Aldy Hernandez [Wed, 14 Sep 2022 12:48:36 +0000 (14:48 +0200)]
[PR106936] Remove assert from get_value_range.
This assert was put here to make sure that the legacy
get_value_range() wasn't being called on stuff that legacy couldn't
handle (floats, etc), because the result would ultimately be copied
into a value_range_equiv.
In this case, simplify_casted_cond() is calling it on an offset_type
which is neither an integer nor a pointer. However, range_of_expr
happily punted on it, and then the fallthru code set the range to
VARYING. As value_range_equiv can store VARYING types of anything
(including types it can't handle), this is fine.
The easiest thing to do is remove the assert. If someone from the non
legacy world tries to get a non integer/pointer range here, it's going
to blow up anyhow because the temporary in get_value_range is
int_range_max.
PR tree-optimization/106936
gcc/ChangeLog:
* value-query.cc (range_query::get_value_range): Remove assert.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/pr106936.C: New test.
Jan-Benedict Glaw [Wed, 14 Sep 2022 12:16:52 +0000 (14:16 +0200)]
Drop unused variable
With the "STABS: remove -gstabs and -gxcoff functionality" patch, a left-over
`start` variable remained unused:
/usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o mips.o -MT mips.o -MMD -MP -MF ./.deps/mips.TPo ../../gcc/gcc/config/mips/mips.cc
../../gcc/gcc/config/mips/mips.cc: In function 'void mips_option_override()':
../../gcc/gcc/config/mips/mips.cc:20021:10: error: unused variable 'start' [-Werror=unused-variable]
20021 | int i, start, regno, mode;
| ^~~~~
2022-09-14 Jan-Benedict Glaw <jbglaw@lug-owl.de>
gcc/
* config/mips/mips.cc (mips_option_override): Drop unused variable.
Julian Brown [Fri, 30 Jul 2021 16:15:18 +0000 (09:15 -0700)]
OpenMP 5.0: Clause ordering for OpenMP 5.0 (topological sorting by base pointer)
This patch reimplements the omp_target_reorder_clauses function in
anticipation of supporting "deeper" struct mappings (that is, with
several structure dereference operators, or similar).
The idea is that in place of the (possibly quadratic) algorithm in
omp_target_reorder_clauses that greedily moves clauses containing
addresses that are subexpressions of other addresses before those other
addresses, we employ a topological sort algorithm to calculate a proper
order for map clauses. This should run in linear time, and hopefully
handles degenerate cases where multiple "levels" of indirect accesses
are present on a given directive.
The new method also takes care to keep clause groups together, addressing
the concerns raised in:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570501.html
To figure out if some given clause depends on a base pointer in another
clause, we strip off the outer layers of the address expression, and check
(via a tree_operand_hash hash table we have built) if the result is a
"base pointer" as defined in OpenMP 5.0 (1.2.6 Data Terminology). There
are some subtleties involved, however:
- We must treat MEM_REF with zero offset the same as INDIRECT_REF.
This should probably be fixed in the front ends instead so we always
use a canonical form (probably INDIRECT_REF). The following patch
shows one instance of the problem, but there may be others:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571382.html
- Mapping a whole struct implies mapping each of that struct's
elements, which may be base pointers. Because those base pointers
aren't necessarily explicitly referenced in the directive in question,
we treat the whole-struct mapping as a dependency instead.
2022-09-13 Julian Brown <julian@codesourcery.com>
gcc/
* gimplify.cc (is_or_contains_p, omp_target_reorder_clauses): Delete
functions.
(omp_tsort_mark): Add enum.
(omp_mapping_group): Add struct.
(debug_mapping_group, omp_get_base_pointer, omp_get_attachment,
omp_group_last, omp_gather_mapping_groups, omp_group_base,
omp_index_mapping_groups, omp_containing_struct,
omp_tsort_mapping_groups_1, omp_tsort_mapping_groups,
omp_segregate_mapping_groups, omp_reorder_mapping_groups): New
functions.
(gimplify_scan_omp_clauses): Call above functions instead of
omp_target_reorder_clauses, unless we've seen an error.
* omp-low.cc (scan_sharing_clauses): Avoid strict test if we haven't
sorted mapping groups.
gcc/testsuite/
* g++.dg/gomp/target-lambda-1.C: Adjust expected output.
* g++.dg/gomp/target-this-3.C: Likewise.
* g++.dg/gomp/target-this-4.C: Likewise.
Robin Dapp [Tue, 6 Sep 2022 06:56:04 +0000 (08:56 +0200)]
testsuite/s390: Add -mzarch to ifcvt test cases.
Add missing -mzarch to ifcvt test cases.
gcc/testsuite/ChangeLog:
* gcc.target/s390/ifcvt-one-insn-bool.c: Add -mzarch.
* gcc.target/s390/ifcvt-one-insn-char.c: Dito.
* gcc.target/s390/ifcvt-two-insns-bool.c: Dito.
* gcc.target/s390/ifcvt-two-insns-int.c: Dito.
* gcc.target/s390/ifcvt-two-insns-long.c: Add -mzarch and change
long into long long.
Robin Dapp [Wed, 31 Aug 2022 07:21:45 +0000 (09:21 +0200)]
testsuite/s390: Fix vperm-rev testcases.
Add -save-temps and tabs for matching.
gcc/testsuite/ChangeLog:
* gcc.target/s390/vector/vperm-rev-z14.c: Add -save-temps.
* gcc.target/s390/vector/vperm-rev-z15.c: Likewise.
Jakub Jelinek [Wed, 14 Sep 2022 10:36:36 +0000 (12:36 +0200)]
Disallow pointer operands for |, ^ and partly & [PR106878]
My change to match.pd (that added the two simplifications this patch
touches) results in more |/^/& assignments with pointer arguments,
but since r12-1608 we reject pointer operands for BIT_NOT_EXPR.
Disallowing them for BIT_NOT_EXPR and allowing for BIT_{IOR,XOR,AND}_EXPR
leads to a match.pd maintainance nightmare (see one of the patches in the
PR), so either we want to allow pointer operand on BIT_NOT_EXPR (but then
we run into issues e.g. with the ranger which expects it can emulate
BIT_NOT_EXPR ~X as - 1 - X which doesn't work for pointers which don't
support MINUS_EXPR), or the following patch disallows pointer arguments
for all of BIT_{IOR,XOR,AND}_EXPR with the exception of BIT_AND_EXPR
with INTEGER_CST last operand (for simpler pointer realignment).
I had to tweak one reassoc optimization and the two match.pd
simplifications.
2022-09-14 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/106878
* tree-cfg.cc (verify_gimple_assign_binary): Disallow pointer,
reference or OFFSET_TYPE BIT_IOR_EXPR, BIT_XOR_EXPR or, unless
the second argument is INTEGER_CST, BIT_AND_EXPR.
* match.pd ((type) X op CST -> (type) (X op ((type-x) CST)),
(type) (((type2) X) op Y) -> (X op (type) Y)): Punt for
POINTER_TYPE_P or OFFSET_TYPE.
* tree-ssa-reassoc.cc (optimize_range_tests_cmp_bitwise): For
pointers cast them to pointer sized integers first.
* gcc.c-torture/compile/pr106878.c: New test.
Richard Biener [Wed, 14 Sep 2022 07:00:35 +0000 (09:00 +0200)]
tree-optimization/106934 - avoid BIT_FIELD_REF of bitfields
The following avoids creating BIT_FIELD_REF of bitfields in
update-address-taken. The patch doesn't implement punning to
a full precision integer type but leaves a comment according to
that.
PR tree-optimization/106934
* tree-ssa.cc (non_rewritable_mem_ref_base): Avoid BIT_FIELD_REFs
of bitfields.
(maybe_rewrite_mem_ref_base): Likewise.
* gfortran.dg/pr106934.f90: New testcase.
liuhongt [Tue, 13 Sep 2022 05:25:24 +0000 (13:25 +0800)]
Check another epilog variable peeling case in vectorizable_nonlinear_induction.
in vectorizable_nonlinear_induction, r13-2503-gc13223b790bbc5 prevent variable peeling by
only checking LOOP_VINFO_MASK_SKIP_NITERS (loop_vinfo). But when
"!vect_use_loop_mask_for_alignment_p (loop_vinfo) &&
LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0", vectorizer will
still do variable peeling for epilog, and it hits gcc_assert in
vect_peel_nonlinear_iv_init.
gcc/ChangeLog:
PR tree-optimization/106905
* tree-vect-loop.cc (vectorizable_nonlinear_induction): Return
false when !vect_use_loop_mask_for_alignment_p (loop_vinfo) &&
LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr106905.c: New test.
* gcc.target/ia64/pr106905.c: New test.
Torbjörn SVENSSON [Wed, 14 Sep 2022 05:22:27 +0000 (07:22 +0200)]
testsuite: gluefile file need to be prefixed
When the status wrapper is used, the gluefile need to be prefixed with
-Wl, in order for the test cases to have the dump files with the
expected names.
2022-09-14 Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
gcc/testsuite/
PR target/95720
* lib/g++.exp: Moved gluefile block to after flags have been
prefixed for the target_compile call.
* lib/gcc.exp: Likewise.
* lib/wrapper.exp: Reset adjusted state flag.
Co-Authored-By: Yvan ROUX <yvan.roux@foss.st.com>
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
GCC Administrator [Wed, 14 Sep 2022 00:18:07 +0000 (00:18 +0000)]
Daily bump.
Roger Sayle [Tue, 13 Sep 2022 18:49:20 +0000 (19:49 +0100)]
PR target/106877: Robustify reg-stack to malformed asm.
This patch resolves PR target/106877 an ICE-on-invalid inline-asm
regression. An innocent upstream change means that the test case
from PR inline-asm/84683 now hits a different assert in reg-stack.cc's
move_for_stack_reg. Fixed by duplicating Jakub's solution to PR 84683
https://gcc.gnu.org/pipermail/gcc-patches/2018-March/495193.html at
this second (similar) gcc_assert.
2022-09-13 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR target/106877
* reg-stack.cc (move_for_stack_reg): Check for any_malformed_asm
in gcc_assert.
gcc/testsuite/ChangeLog
PR target/106877
* g++.dg/ext/pr106877.C: New test case.
Jakub Jelinek [Tue, 13 Sep 2022 17:00:02 +0000 (19:00 +0200)]
libgomp: Appease some static analyzers [PR106906]
While icv_addr[1] = false; assignments where icv_addr has void *
element type is correct and matches how it is used (in those cases
the void * pointer is then cast to bool and used that way), there is no
reason not to add explicit (void *) casts there which are there already
for (void *) true. And, there is in fact even no point in actually
doing those stores at all because we set that pointer to NULL a few
lines earlier. So, this patch adds the explicit casts and then
comments those out to show intent.
2022-09-13 Jakub Jelinek <jakub@redhat.com>
PR libgomp/106906
* env.c (get_icv_member_addr): Cast false to void * before assigning
it to icv_addr[1], and comment the whole assignment out.
Patrick Palka [Tue, 13 Sep 2022 15:18:16 +0000 (11:18 -0400)]
libstdc++: Implement ranges::slide_view from P2442R1
This also implements the LWG 3711 and 3712 changes to slide_view.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__slide_caches_nothing): Define.
(__detail::__slide_caches_last): Define.
(__detail::__slide_caches_first): Define.
(slide_view): Define.
(enable_borrowed_range<slide_view>): Define.
(slide_view::_Iterator): Define.
(slide_view::_Sentinel): Define.
(views::__detail::__can_slide_view): Define.
(views::_Slide, views::slide): Define.
* testsuite/std/ranges/adaptors/slide/1.cc: New test.
Patrick Palka [Tue, 13 Sep 2022 15:18:14 +0000 (11:18 -0400)]
libstdc++: Implement ranges::chunk_view from P2442R1
This also implements the LWG 3707, 3710 and 3712 changes to chunk_view.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__div_ceil): Define.
(chunk_view): Define.
(chunk_view::_OuterIter): Define.
(chunk_view::_OuterIter::value_type): Define.
(chunk_view::_InnerIter): Define.
(chunk_view<_Vp>): Define partial specialization for forward
ranges.
(enable_borrowed_range<chunk_view>): Define.
(chunk_view<_Vp>::_Iterator): Define.
(views::__detail::__can_chunk_view): Define.
(views::_Chunk, views::chunk): Define.
* testsuite/std/ranges/adaptors/chunk/1.cc: New test.
Patrick Palka [Tue, 13 Sep 2022 15:18:07 +0000 (11:18 -0400)]
libstdc++: Implement LWG 3569 changes to join_view::_Iterator
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::_Iterator::_M_satisfy):
Adjust resetting _M_inner as per LWG 3569.
(join_view::_Iterator::_M_inner): Wrap in std::optional
as per LWG 3569.
(join_view::_Iterator::_Iterator): Relax constraints as
per LWG 3569.
(join_view::_Iterator::operator*): Adjust as per LWG 3569.
(join_view::_Iterator::operator->): Likewise.
(join_view::_Iterator::operator++): Likewise.
(join_view::_Iterator::operator--): Likewise.
(join_view::_Iterator::iter_move): Likewise.
(join_view::_Iterator::iter_swap): Likewise.
* testsuite/std/ranges/adaptors/join.cc (test14): New test.
Patrick Palka [Tue, 13 Sep 2022 14:41:47 +0000 (10:41 -0400)]
libstdc++: Avoid -Wparentheses warning with debug iterators
I noticed compiling e.g. std/ranges/adaptors/join.cc with
-D_GLIBCXX_DEBUG -Wsystem-headers -Wall gives the warning:
gcc/libstdc++-v3/include/debug/safe_iterator.h:477:9: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
libstdc++-v3/ChangeLog:
* include/debug/safe_iterator.h (_GLIBCXX_DEBUG_VERIFY_OPERANDS):
Add parentheses to avoid -Wparentheses warning.
Patrick Palka [Tue, 13 Sep 2022 14:18:58 +0000 (10:18 -0400)]
c++: remove single-parameter version of mark_used
gcc/cp/ChangeLog:
* cp-tree.h (mark_used): Remove single-parameter overload. Add
default argument to the two-parameter overload.
* decl2.cc (mark_used): Likewise.
Patrick Palka [Tue, 13 Sep 2022 14:01:29 +0000 (10:01 -0400)]
c++: two-parameter version of cxx_constant_value
Since some callers need the complain parameter but not the object
parameter, let's introduce and use an overload of cxx_constant_value
that omits the latter.
gcc/cp/ChangeLog:
* cp-tree.h (cxx_constant_value): Define two-parameter version
that omits the object parameter.
* decl.cc (build_explicit_specifier): Omit NULL_TREE object
argument to cxx_constant_value.
* except.cc (build_noexcept_spec): Likewise.
* pt.cc (expand_integer_pack): Likewise.
(fold_targs_r): Likewise.
* semantics.cc (finish_if_stmt_cond): Likewise.
Patrick Palka [Tue, 13 Sep 2022 13:48:04 +0000 (09:48 -0400)]
c++: some missing-SFINAE fixes
It looks like we aren't respecting SFINAE for:
* an invalid/non-constant conditional explicit-specifier
* a non-constant conditional noexcept-specifier
* a non-constant argument to __integer_pack
This patch fixes these in the usual way, by passing complain and
propagating error_mark_node appropriately.
gcc/cp/ChangeLog:
* decl.cc (build_explicit_specifier): Pass complain to
cxx_constant_value.
* except.cc (build_noexcept_spec): Likewise.
* pt.cc (expand_integer_pack): Likewise.
(tsubst_function_decl): Propagate error_mark_node returned
from build_explicit_specifier.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/noexcept-type26.C: New test.
* g++.dg/cpp2a/explicit19.C: New test.
* g++.dg/ext/integer-pack6.C: New test.
Max Filippov [Tue, 13 Sep 2022 11:28:16 +0000 (04:28 -0700)]
Revert "xtensa: Implement new target hook: TARGET_CONSTANT_OK_FOR_CPROP_P"
This reverts commit
936efcac733fe49e5ea9e636403e5941f24ff1b3.
Kewen Lin [Tue, 13 Sep 2022 09:14:23 +0000 (04:14 -0500)]
rs6000: Fix the check of bif argument number [PR104482]
As PR104482 shown, it's one regression about the handlings when
the argument number is more than the one of built-in function
prototype. The new bif support only catches the case that the
argument number is less than the one of function prototype, but
it misses the case that the argument number is more than the one
of function prototype. Because it uses "n != expected_args",
n is updated in
for (n = 0; !VOID_TYPE_P (TREE_VALUE (fnargs)) && n < nargs;
fnargs = TREE_CHAIN (fnargs), n++)
, it's restricted to be less than or equal to expected_args with
the guard !VOID_TYPE_P (TREE_VALUE (fnargs)), so it's wrong.
The fix is to use nargs instead, also move the checking hunk's
location ahead to avoid useless further scanning when the counts
mismatch.
PR target/104482
gcc/ChangeLog:
* config/rs6000/rs6000-c.cc (altivec_resolve_overloaded_builtin): Fix
the equality check for argument number, and move this hunk ahead.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr104482.c: New test.
Kewen.Lin [Tue, 13 Sep 2022 09:13:59 +0000 (04:13 -0500)]
rs6000: Handle unresolved overloaded builtin [PR105485]
PR105485 exposes that new builtin function framework doesn't handle
unresolved overloaded builtin function well. With new builtin
function support, we don't have builtin info for any overloaded
rs6000_gen_builtins enum, since they are expected to be resolved to
one specific instance. So when function rs6000_gimple_fold_builtin
faces one unresolved overloaded builtin, the access for builtin info
becomes out of bound and gets ICE then.
We should not try to fold one unresolved overloaded builtin there
and as the previous support we should emit one error message during
expansion phase like "unresolved overload for builtin ...".
PR target/105485
gcc/ChangeLog:
* config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Add
the handling for unresolved overloaded builtin function.
(rs6000_expand_builtin): Likewise.
gcc/testsuite/ChangeLog:
* g++.target/powerpc/pr105485.C: New test.
Kewen Lin [Tue, 13 Sep 2022 09:13:10 +0000 (04:13 -0500)]
rs6000: Suggest unroll factor for loop vectorization
Commit r12-6679-g7ca1582ca60dc8 made vectorizer accept one
unroll factor to be applied to vectorization factor when
vectorizing the main loop, it would be suggested by target
when doing costing.
This patch introduces function determine_suggested_unroll_factor
for rs6000 port, to make it be able to suggest the unroll factor
for a given loop being vectorized. Referring to aarch64 port
and basing on the analysis on SPEC2017 performance evaluation
results, it mainly considers these aspects:
1) unroll option and pragma which can disable unrolling for the
given loop;
2) simple hardware resource model with issued non memory access
vector insn per cycle;
3) aggressive heuristics when iteration count is unknown:
- reduction case to break cross iteration dependency;
- emulated gather load;
4) estimated iteration count when iteration count is unknown;
With this patch, SPEC2017 performance evaluation results on
Power8/9/10 are listed below (speedup pct.):
* Power10
- O2: all are neutral (excluding some noises);
- Ofast: 510.parest_r +6.67%, the others are neutral
(use ... for the followings);
- Ofast + unroll: 510.parest_r +5.91%, ...
- Ofast + LTO + PGO: 510.parest_r +3.00%, ...
- Ofast + cheap vect cost: 510.parest_r +6.23%, ...
- Ofast + very-cheap vect cost: all are neutral;
* Power9
- Ofast: 510.parest_r +8.73%, 538.imagick_r +11.18%
(likely noise), 500.perlbench_r +1.84%, ...
* Power8
- Ofast: 510.parest_r +5.43%, ...;
This patch also introduces one documented parameter
rs6000-vect-unroll-limit= similar to what aarch64 proposes,
by evaluating on P8/P9/P10, the default value 4 is slightly
better than the other choices like 2 and 8.
It also parameterizes two other values as undocumented
parameters for future tweaking. One parameter is
rs6000-vect-unroll-issue, it's to simply model hardware
resource for non memory access vector instructions to avoid
excessive unrolling, initially I tried to use the value in
the hook rs6000_issue_rate, but the evaluation showed it's
bad, so I evaluated different values 2/4/6/8 on P8/P9/P10 at
Ofast, the results showed the default value 4 is good enough
on these different architectures. For a record, choice 8
could make 510.parest_r's gain become smaller or gone on
P8/P9/P10; choice 6 could make 503.bwaves_r degrade by more
than 1% on P8/P10; and choice 2 could make 538.imagick_r
degrade by 3.8%. The other parameter is
rs6000-vect-unroll-reduc-threshold. It's mainly inspired by
510.parest_r and tweaked as it, evaluating with different
values 0/1/2/3 for the threshold, it showed value 1 is the
best choice. For a record, choice 0 could make 525.x264_r
degrade by 2% and 527.cam4_r degrade by 2.95% on P10,
548.exchange2_r degrade by 1.41% and 527.cam4_r degrade by
2.54% on P8; choice 2 and bigger values could make
510.parest_r's gain become smaller.
gcc/ChangeLog:
* config/rs6000/rs6000.cc (class rs6000_cost_data): Add new members
m_nstores, m_reduc_factor, m_gather_load and member function
determine_suggested_unroll_factor.
(rs6000_cost_data::update_target_cost_per_stmt): Update for m_nstores,
m_reduc_factor and m_gather_load.
(rs6000_cost_data::determine_suggested_unroll_factor): New function.
(rs6000_cost_data::finish_cost): Use determine_suggested_unroll_factor.
* config/rs6000/rs6000.opt (rs6000-vect-unroll-limit): New parameter.
(rs6000-vect-unroll-issue): Likewise.
(rs6000-vect-unroll-reduc-threshold): Likewise.
* doc/invoke.texi (rs6000-vect-unroll-limit): Document new parameter.
Richard Biener [Tue, 13 Sep 2022 06:59:41 +0000 (08:59 +0200)]
middle-end/106909 - CTRL altering flag after folding
The following makes sure to clear the CTRL altering flag when
folding emits a __builitin_unreachable in place of a virtual call
which now might become a trap.
PR middle-end/106909
* gimple-fold.cc (gimple_fold_call): Clear the ctrl-altering
flag of a unreachable call.
Richard Biener [Tue, 13 Sep 2022 06:46:51 +0000 (08:46 +0200)]
tree-optimization/106913 - ICE with -da and -Wuninitialized
The following avoids setting and not clearing an auto_bb_flag
on EXIT_BLOCK which we don't verify for such stale flags but
dump_bb_info still asserts on them.
PR tree-optimization/106913
* tree-ssa-uninit.cc (warn_uninitialized_vars): Do not set
ft_reachable on EXIT_BLOCK.
Richard Sandiford [Tue, 13 Sep 2022 08:28:49 +0000 (09:28 +0100)]
aarch64: Vector move fixes for +nosimd
This patch fixes various issues around the handling of vectors
and (particularly) vector structures with +nosimd. Previously,
passing and returning structures would trigger an ICE, since:
* we didn't allow the structure modes to be stored in FPRs
* we didn't provide +nosimd move patterns
* splitting the moves into word-sized pieces (the default
strategy without move patterns) doesn't work because the
registers are doubleword sized.
The patch is a bit of a hodge-podge since a lot of the handling of
moves, register costs, and register legitimacy is so interconnected.
It didn't seem feasible to split things further.
Some notes:
* The patch recognises vector and tuple modes based on TARGET_FLOAT
rather than TARGET_SIMD, and instead adds TARGET_SIMD to places
that really do need the vector ISA. This is necessary for the
modes to be handled correctly in register arguments and returns.
* The 64-bit (DREG) STP peephole required TARGET_SIMD but the
LDP peephole didn't. I think the LDP one is right, since
DREG moves could involve GPRs as well as FPRs.
* The patch keeps the existing choices of instructions for
TARGET_SIMD, just in case they happen to be better than FMOV
on some uarches.
* Before the patch, +nosimd Q<->Q moves of 128-bit scalars went via
a GPR, thanks to a secondary reload pattern. This approach might
not be ideal, but there's no reason that 128-bit vectors should
behave differently from 128-bit scalars. The patch therefore
extends the current scalar approach to vectors.
* Multi-vector LD1 and ST1 require TARGET_SIMD, so the TARGET_FLOAT
structure moves need to use LDP/STP and LDR/STR combinations
instead. That's also what we do for big-endian even with
TARGET_SIMD, so most of the code was already there. The patterns
for structures of 64-bit vectors are identical, but the patterns
for structures of 128-bit vectors need to cope with the lack of
128-bit Q<->Q moves.
It isn't feasible to move multi-vector tuples via GPRs, so the
patch moves them via memory instead. This contaminates the port
with its first secondary memory reload.
gcc/
* config/aarch64/aarch64.cc (aarch64_classify_vector_mode): Use
TARGET_FLOAT instead of TARGET_SIMD.
(aarch64_vectorize_related_mode): Restrict ADVSIMD handling to
TARGET_SIMD.
(aarch64_hard_regno_mode_ok): Don't allow tuples of 2 64-bit vectors
in GPRs.
(aarch64_classify_address): Treat little-endian structure moves
like big-endian for TARGET_FLOAT && !TARGET_SIMD.
(aarch64_secondary_memory_needed): New function.
(aarch64_secondary_reload): Handle 128-bit Advanced SIMD vectors
in the same way as TF, TI and TD.
(aarch64_rtx_mult_cost): Restrict ADVSIMD handling to TARGET_SIMD.
(aarch64_rtx_costs): Likewise.
(aarch64_register_move_cost): Treat a pair of 64-bit vectors
separately from a single 128-bit vector. Handle the cost implied
by aarch64_secondary_memory_needed.
(aarch64_simd_valid_immediate): Restrict ADVSIMD handling to
TARGET_SIMD.
(aarch64_expand_vec_perm_const_1): Likewise.
(TARGET_SECONDARY_MEMORY_NEEDED): New macro.
* config/aarch64/iterators.md (VTX): New iterator.
* config/aarch64/aarch64.md (arches): Add fp_q as a synonym of simd.
(arch_enabled): Adjust accordingly.
(@aarch64_reload_mov<TX:mode>): Extend to...
(@aarch64_reload_mov<VTX:mode>): ...this.
* config/aarch64/aarch64-simd.md (mov<mode>): Require TARGET_FLOAT
rather than TARGET_SIMD.
(movmisalign<mode>): Likewise.
(load_pair<DREG:mode><DREG2:mode>): Likewise.
(vec_store_pair<DREG:mode><DREG2:mode>): Likewise.
(load_pair<VQ:mode><VQ2:mode>): Likewise.
(vec_store_pair<VQ:mode><VQ2:mode>): Likewise.
(@aarch64_split_simd_mov<mode>): Likewise.
(aarch64_get_low<mode>): Likewise.
(aarch64_get_high<mode>): Likewise.
(aarch64_get_half<mode>): Likewise. Canonicalize to a move for
lowpart extracts.
(*aarch64_simd_mov<VDMOV:mode>): Require TARGET_FLOAT rather than
TARGET_SIMD. Use different w<-w and r<-w instructions for
!TARGET_SIMD. Disable immediate moves for !TARGET_SIMD but
add an alternative specifically for w<-Z.
(*aarch64_simd_mov<VQMOV:mode>): Require TARGET_FLOAT rather than
TARGET_SIMD. Likewise for the associated define_splits. Disable
FPR moves and immediate moves for !TARGET_SIMD but add an alternative
specifically for w<-Z.
(aarch64_simd_mov_from_<mode>high): Require TARGET_FLOAT rather than
TARGET_SIMD. Restrict the existing alternatives to TARGET_SIMD
but add a new r<-w one for !TARGET_SIMD.
(*aarch64_get_high<mode>): New pattern.
(load_pair_lanes<mode>): Require TARGET_FLOAT rather than TARGET_SIMD.
(store_pair_lanes<mode>): Likewise.
(*aarch64_combine_internal<mode>): Likewise. Restrict existing
w<-w, w<-r and w<-m alternatives to TARGET_SIMD but add a new w<-r
alternative for !TARGET_SIMD.
(*aarch64_combine_internal_be<mode>): Likewise.
(aarch64_combinez<mode>): Require TARGET_FLOAT rather than TARGET_SIMD.
Remove bogus arch attribute.
(*aarch64_combinez_be<mode>): Likewise.
(@aarch64_vec_concat<mode>): Require TARGET_FLOAT rather than
TARGET_SIMD.
(aarch64_combine<mode>): Likewise.
(aarch64_rev_reglist<mode>): Likewise.
(mov<mode>): Likewise.
(*aarch64_be_mov<VSTRUCT_2D:mode>): Extend to TARGET_FLOAT &&
!TARGET_SIMD, regardless of endianness. Extend associated
define_splits in the same way, both for this pattern and the
ones below.
(*aarch64_be_mov<VSTRUCT_2Qmode>): Likewise. Restrict w<-w
alternative to TARGET_SIMD.
(*aarch64_be_movoi): Likewise.
(*aarch64_be_movci): Likewise.
(*aarch64_be_movxi): Likewise.
(*aarch64_be_mov<VSTRUCT_4QD:mode>): Extend to TARGET_FLOAT
&& !TARGET_SIMD, regardless of endianness. Restrict w<-w alternative
to TARGET_SIMD for tuples of 128-bit vectors.
(*aarch64_be_mov<VSTRUCT_4QD:mode>): Likewise.
* config/aarch64/aarch64-ldpstp.md: Remove TARGET_SIMD condition
from DREG STP peephole. Change TARGET_SIMD to TARGET_FLOAT in
the VQ and VP_2E LDP and STP peepholes.
gcc/testsuite/
* gcc.target/aarch64/ldp_stp_20.c: New test.
* gcc.target/aarch64/ldp_stp_21.c: Likewise.
* gcc.target/aarch64/ldp_stp_22.c: Likewise.
* gcc.target/aarch64/ldp_stp_23.c: Likewise.
* gcc.target/aarch64/ldp_stp_24.c: Likewise.
* gcc.target/aarch64/movv16qi_1.c (gpr_to_gpr): New function.
* gcc.target/aarch64/movv8qi_1.c (gpr_to_gpr): Likewise.
* gcc.target/aarch64/movv16qi_2.c: New test.
* gcc.target/aarch64/movv16qi_3.c: Likewise.
* gcc.target/aarch64/movv2di_1.c: Likewise.
* gcc.target/aarch64/movv2x16qi_1.c: Likewise.
* gcc.target/aarch64/movv2x8qi_1.c: Likewise.
* gcc.target/aarch64/movv3x16qi_1.c: Likewise.
* gcc.target/aarch64/movv3x8qi_1.c: Likewise.
* gcc.target/aarch64/movv4x16qi_1.c: Likewise.
* gcc.target/aarch64/movv4x8qi_1.c: Likewise.
* gcc.target/aarch64/movv8qi_2.c: Likewise.
* gcc.target/aarch64/movv8qi_3.c: Likewise.
* gcc.target/aarch64/vect_unary_2.c: Likewise.
Richard Sandiford [Tue, 13 Sep 2022 08:28:48 +0000 (09:28 +0100)]
aarch64: Disassociate ls64 from simd
The ls64-related move expanders and splits required TARGET_SIMD.
That isn't necessary, since the 64-byte values are stored entirely
in GPRs. (The associated define_insn was already correct.)
I wondered about moving the patterns to aarch64.md, but it wasn't
clear-cut.
gcc/
* config/aarch64/aarch64-simd.md (movv8di): Remove TARGET_SIMD
condition. Likewise for the related define_split. Tweak formatting.
gcc/testsuite/
* gcc.target/aarch64/acle/ls64_asm_2.c: New test.
Tobias Burnus [Tue, 13 Sep 2022 07:08:57 +0000 (09:08 +0200)]
libgomp.texi: move item from gcn to nvptx
I misplaced one remark into 'gcn' instead of 'nvptx' in
commit r13-2625-g6b43f556f392a7165582aca36a19fe7389d995b2
libgomp/ChangeLog:
* libgomp.texi (gcn): Move misplaced -march=sm_30 remark to ...
(nvptx): ... here.
GCC Administrator [Tue, 13 Sep 2022 00:18:20 +0000 (00:18 +0000)]
Daily bump.
Patrick Palka [Mon, 12 Sep 2022 21:55:53 +0000 (17:55 -0400)]
c++: remove '_sfinae' suffix from functions
The functions
abstract_virtuals_error
cxx_constant_value
get_target_expr
instantiate_non_dependent_expr
require_complete_type
are each just a non-SFINAE-enabled wrapper for the corresponding
SFINAE-enabled version that's suffixed by '_sfinae'. But this suffix is
at best redundant since a 'complain' parameter already broadly conveys
that a function is SFINAE-enabled, and having two such versions of a
function is less concise than just using a default argument for 'complain'
(and arguably no less mistake prone).
So this patch squashes the two versions of each of the above functions
by adding a default 'complain' argument to the SFINAE-enabled version
whose '_sfinae' suffix we then remove.
gcc/cp/ChangeLog:
* call.cc (build_conditional_expr): Adjust calls to
'_sfinae'-suffixed functions.
(build_temp): Likewise.
(convert_like_internal): Likewise.
(convert_arg_to_ellipsis): Likewise.
(build_over_call): Likewise.
(build_cxx_call): Likewise.
(build_new_method_call): Likewise.
* constexpr.cc (cxx_eval_outermost_constant_expr): Likewise.
(cxx_constant_value_sfinae): Rename to ...
(cxx_constant_value): ... this. Document its default arguments.
(fold_non_dependent_expr): Adjust function comment.
* cp-tree.h (instantiate_non_dependent_expr_sfinae): Rename to ...
(instantiate_non_dependent_expr): ... this. Give its 'complain'
parameter a default argument.
(get_target_expr_sfinae, get_target_expr): Likewise.
(require_complete_type_sfinae, require_complete_type): Likewise.
(abstract_virtuals_error_sfinae, abstract_virtuals_error):
Likewise.
(cxx_constant_value_sfinae, cxx_constant_value): Likewise.
* cvt.cc (build_up_reference): Adjust calls to '_sfinae'-suffixed
functions.
(ocp_convert): Likewise.
* decl.cc (build_explicit_specifier): Likewise.
* except.cc (build_noexcept_spec): Likewise.
* init.cc (build_new_1): Likewise.
* pt.cc (expand_integer_pack): Likewise.
(instantiate_non_dependent_expr_internal): Adjust function
comment.
(instantiate_non_dependent_expr): Rename to ...
(instantiate_non_dependent_expr_sfinae): ... this. Document its
default argument.
(tsubst_init): Adjust calls to '_sfinae'-suffixed functions.
(fold_targs_r): Likewise.
* semantics.cc (finish_compound_literal): Likewise.
(finish_decltype_type): Likewise.
(cp_build_bit_cast): Likewise.
* tree.cc (build_cplus_new): Likewise.
(get_target_expr): Rename to ...
(get_target_expr_sfinae): ... this. Document its default
argument.
* typeck.cc (require_complete_type): Rename to ...
(require_complete_type_sfinae): ... this. Document its default
argument.
(cp_build_array_ref): Adjust calls to '_sfinae'-suffixed
functions.
(convert_arguments): Likewise.
(cp_build_binary_op): Likewise.
(build_static_cast_1): Likewise.
(cp_build_modify_expr): Likewise.
(convert_for_initialization): Likewise.
* typeck2.cc (abstract_virtuals_error): Rename to ...
(abstract_virtuals_error_sfinae): ... this. Document its default
argument.
(build_functional_cast_1): Adjust calls to '_sfinae'-suffixed
functions.
Patrick Palka [Tue, 7 Jun 2022 18:19:53 +0000 (14:19 -0400)]
c++: template-id arguments are evaluated [PR101906]
Here we're neglecting to clear cp_unevaluated_operand when substituting
into the arguments of the alias template-id 'skip<(T(), 0), T>' with T=A,
which means cp_unevaluated_operand remains set during mark_used for
A::A() and so we don't synthesize it. Later constant evaluation for
the substituted template argument '(A(), 0)' (from coerce_template_parms)
fails with "'constexpr A::A()' used before its definition" since it was
never synthesized.
This doesn't happen with a class template because tsubst_aggr_type
clears cp_unevaluated_operand during substitution thereof. But since
template arguments are generally manifestly constant-evaluated, which in
turn are evaluated even in an unevaluated operand, we should be clearing
cp_unevaluated_operand more broadly whenever substituting into any set
of template arguments. To that end this patch makes us clear it during
tsubst_template_args.
PR c++/101906
gcc/cp/ChangeLog:
* pt.cc (tsubst_template_args): Set cp_evaluated here.
(tsubst_aggr_type): Not here.
gcc/testsuite/ChangeLog:
* g++.dg/template/evaluated1.C: New test.
* g++.dg/template/evaluated1a.C: New test.
* g++.dg/template/evaluated1b.C: New test.
* g++.dg/template/evaluated1c.C: New test.
Jason Merrill [Mon, 12 Sep 2022 17:47:34 +0000 (13:47 -0400)]
c++: auto member function and auto variable [PR106893]
As with PR105623, we need to call mark_single_function sooner to
resolve the type of a BASELINK.
PR c++/106893
PR c++/90451
gcc/cp/ChangeLog:
* decl.cc (cp_finish_decl): Call mark_single_function.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/auto-fn65.C: New test.
Jason Merrill [Mon, 12 Sep 2022 18:14:24 +0000 (14:14 -0400)]
c++: cast to array of unknown bound [PR93259]
We already know to treat a variable of array-of-unknown-bound type as
dependent, we should do the same for arr{}.
PR c++/93259
gcc/cp/ChangeLog:
* pt.cc (type_dependent_expression_p): Treat a compound
literal of array-of-unknown-bound type like a variable.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array17.C: New test.
Takayuki 'January June' Suwa [Sun, 11 Sep 2022 11:51:15 +0000 (20:51 +0900)]
xtensa: Implement new target hook: TARGET_CONSTANT_OK_FOR_CPROP_P
This patch implements new target hook TARGET_CONSTANT_OK_FOR_CPROP_P in
order to exclude CONST_INTs that cannot fit into a MOVI machine instruction
from cprop.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (TARGET_CONSTANT_OK_FOR_CPROP_P):
New macro definition.
(xtensa_constant_ok_for_cprop_p):
Implement the hook as mentioned above.
Patrick Palka [Mon, 12 Sep 2022 19:05:04 +0000 (15:05 -0400)]
libstdc++: Add already-accepted <ranges> testcase [PR106320]
Although PR106320 affected only the 10 and 11 branches, and the testcase
from there is already correctly accepted on trunk and the 12 branch, we
still should add the testcase to trunk/12 too for inter-branch consistency.
PR libstdc++/106320
libstdc++-v3/ChangeLog:
* testsuite/std/ranges/adaptors/join.cc (test13): New test.
Jason Merrill [Mon, 12 Sep 2022 16:59:46 +0000 (12:59 -0400)]
c++: lambda capture of array with deduced bounds [PR106567]
We can't use the type of an array variable directly if we haven't deduced
its length yet.
PR c++/106567
gcc/cp/ChangeLog:
* lambda.cc (type_deducible_expression_p): Check
array_of_unknown_bound_p.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-array4.C: New test.
Jonathan Wakely [Thu, 30 Jun 2022 16:53:26 +0000 (17:53 +0100)]
c++: Refer to internal linkage for -Wsubobject-linkage [PR86491]
Since C++11 relaxed the requirement for template arguments to have
external linkage, it's possible to get -Wsubobject-linkage warnings
without using any anonymous namespaces. This confuses users when they
get diagnostics that refer to an anonymous namespace that doesn't exist
in their code.
This changes the diagnostic to say "has internal linkage" for C++11 and
later, if the type isn't actually a member of the anonymous namespace.
Making that distinction involved renaming the current decl_anon_ns_mem_p to
something that better expresses its semantics.
For C++98 template arguments declared with 'static' are ill-formed
anyway, so the only way this warning can arise is via anonymous
namespaces. That means the existing wording is accurate for C++98 and so
we can keep it.
PR c++/86491
gcc/cp/ChangeLog:
* decl2.cc (constrain_class_visibility): Adjust wording of
-Wsubobject-linkage for cases where anonymous
namespaces aren't used.
* tree.cc (decl_anon_ns_mem_p): Now only true for actual anonymous
namespace members, rename old semantics to...
(decl_internal_context_p): ...this.
* cp-tree.h, name-lookup.cc, pt.cc: Adjust.
gcc/testsuite/ChangeLog:
* g++.dg/warn/anonymous-namespace-3.C: Use separate dg-warning
directives for C++98 and everything else.
* g++.dg/warn/Wsubobject-linkage-5.C: New test.
Joseph Myers [Mon, 12 Sep 2022 14:34:26 +0000 (14:34 +0000)]
stdatomic.h: Do not define ATOMIC_VAR_INIT for C2x
The <stdatomic.h> macro ATOMIC_VAR_INIT, previously declared obsolete,
is removed completely in C2x; disable it for C2x in GCC's
implementation. (Although ATOMIC_* are reserved names for this
header, disabling the macro for C2x still seems appropriate.)
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/
* ginclude/stdatomic.h [defined __STDC_VERSION__ &&
__STDC_VERSION__ > 201710L] (ATOMIC_VAR_INIT): Do not define.
gcc/testsuite/
* gcc.dg/atomic/c2x-stdatomic-var-init-1.c: New test.
Tobias Burnus [Mon, 12 Sep 2022 13:25:13 +0000 (15:25 +0200)]
nvptx/mkoffload.cc: Warn instead of error when reverse offload is not possible
Reverse offload requests at least -misa=sm_35; with this patch, a warning
instead of an error is shown, still permitting reverse offload for all
other configured device types. This is achieved by not calling
GOMP_offload_register_ver (and stopping generating pointless 'static const char'
variables, once known.)
The tool_name as progname changes adds "nvptx " and "gcn " to the
"mkoffload: warning/error:" diagnostic.
gcc/ChangeLog:
* config/nvptx/mkoffload.cc (process): Replace a fatal_error by
a warning + not enabling offloading if -misa=sm_30 prevents
reverse offload.
(main): Use tool_name as progname for diagnostic.
* config/gcn/mkoffload.cc (main): Likewise.
libgomp/ChangeLog:
* libgomp.texi (Offload-Target Specifics: nvptx): Document
that reverse offload requires >= -march=sm_35.
* testsuite/libgomp.c-c++-common/requires-4.c: Build for nvptx
with -misa=sm_35.
* testsuite/libgomp.c-c++-common/requires-5.c: Likewise.
* testsuite/libgomp.c-c++-common/requires-6.c: Likewise.
* testsuite/libgomp.c-c++-common/reverse-offload-1.c: Likewise.
* testsuite/libgomp.fortran/reverse-offload-1.f90: Likewise.
* testsuite/libgomp.c/reverse-offload-sm30.c: New test.
Aldy Hernandez [Mon, 12 Sep 2022 11:04:02 +0000 (13:04 +0200)]
frange::set_signbit: Avoid changing sign when already in the correct sign.
We should avoid pessimizing the signbit when it's already correct. In
this particular case we were trying to change the signbit to "unknown",
when it was obviously negative.
This test is actually slated for removal with my upcoming revamp of the
signbit and NAN tracking, per the conversations regarding tristate. The
signbit will be removed in favor of keeping track of it in the range
itself, and NAN will just be a pair of boolean flags. However, I don't
plan to disturb the tree until after Cauldron.
Tested on x86-64 Linux including mpfr tests. Also tested selftests with
-ffinite-math-only on x86-64 as well as on a cross to pdp11-aout.
gcc/ChangeLog:
* value-range.cc (frange::set_signbit): Avoid changing sign when
already in the correct sign.
Max Filippov [Sun, 11 Sep 2022 00:31:07 +0000 (17:31 -0700)]
xtensa: gcc: fix builtin_apply return value
xtensa may use up to 4 registers to return a value from a function, but
recognition of only one register in the xtensa_function_value_regno_p
and missing untyped_call pattern result in that only one register is
saved by the __builtin_apply and returned by the __builtin_apply_return.
gcc/
* config/xtensa/xtensa.cc (xtensa_function_value_regno_p):
Recognize all 4 return registers.
* config/xtensa/xtensa.h (GP_RETURN_REG_COUNT): New definition.
* config/xtensa/xtensa.md (untyped_call): New pattern.