into the proper location for OpenACC testing (thanks to Thomas for
spotting my mistake!), and also fixes a few additional problems --
missing diagnostics for non-pointer attaches, and a case where a pointer
was incorrectly dereferenced. Tests are also adjusted for vector-length
warnings on nvidia accelerators.
2023-04-29 Julian Brown <julian@codesourcery.com>
PR fortran/109622
gcc/fortran/
* openmp.cc (resolve_omp_clauses): Add diagnostic for
non-pointer/non-allocatable attach/detach.
* trans-openmp.cc (gfc_trans_omp_clauses): Remove dereference for
pointer-to-scalar derived type component attach/detach. Fix
attach/detach handling for descriptors.
gcc/testsuite/
* gfortran.dg/goacc/pr109622-5.f90: New test.
* gfortran.dg/goacc/pr109622-6.f90: New test.
Julian Brown [Wed, 26 Apr 2023 14:31:53 +0000 (14:31 +0000)]
OpenACC: Stand-alone attach/detach clause fixes for Fortran [PR109622]
This patch fixes several cases where multiple attach or detach mapping
nodes were being created for stand-alone attach or detach clauses
in Fortran. After the introduction of stricter checking later during
compilation, these extra nodes could cause ICEs, as seen in the PR.
The patch also fixes cases that "happened to work" previously where
the user attaches/detaches a pointer to array using a descriptor, and
(I think!) the "_data" field has offset zero, hence the same address as
the descriptor as a whole.
libgomp/
* testsuite/libgomp.fortran/pr109622.f90: New test.
* testsuite/libgomp.fortran/pr109622-2.f90: New test.
* testsuite/libgomp.fortran/pr109622-3.f90: New test.
Alexandre Oliva [Fri, 5 May 2023 11:34:23 +0000 (08:34 -0300)]
[libstdc++] [testsuite] xfail double-prec from_chars for ldbl
When long double is wider than double, but from_chars is implemented
in terms of double, tests that involve the full precision of long
double are expected to fail. Mark them as such on aarch64-*-vxworks.
for libstdc++-v3/ChangeLog
* testsuite/20_util/from_chars/4.cc: Skip long double test06
on aarch64-vxworks.
* testsuite/20_util/to_chars/long_double.cc: Xfail run on
aarch64-vxworks.
Jakub Jelinek [Thu, 4 May 2023 07:36:05 +0000 (09:36 +0200)]
i386: Fix up handling of debug insns in STV [PR109676]
The following testcase ICEs because STV replaces there
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1
(nil))
with
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:V1TI 91 [ p ])) -1
(nil))
which is invalid because of the mode mismatch.
STV has fix_debug_reg_uses function which is supposed to fix this up
and adjust such debug insns into
(debug_insn 114 47 51 8 (var_location:TI D#3 (subreg:TI (reg:V1TI 91 [ p ]) 0)) -1
(nil))
but it doesn't trigger here.
The IL before stv1 has:
(debug_insn 114 47 51 8 (var_location:TI D#3 (reg:TI 91 [ p ])) -1
(nil))
...
(insn 63 62 64 8 (set (mem/c:TI (reg/f:DI 89 [ .result_ptr ]) [0 <retval>.mStorage+0 S16 A32])
(reg:TI 91 [ p ])) "pr109676.C":4:48 87 {*movti_internal}
(expr_list:REG_DEAD (reg:TI 91 [ p ])
(nil)))
in bb 8 and
(insn 97 96 98 9 (set (reg:TI 91 [ p ])
(mem/c:TI (plus:DI (reg/f:DI 19 frame)
(const_int -32 [0xffffffffffffffe0])) [0 p+0 S16 A128])) "pr109676.C":26:12 87 {*movti_internal}
(nil))
(insn 98 97 99 9 (set (mem/c:TI (plus:DI (reg/f:DI 19 frame)
(const_int -64 [0xffffffffffffffc0])) [0 tmp+0 S16 A128])
(reg:TI 91 [ p ])) "pr109676.C":26:12 87 {*movti_internal}
(nil))
in bb9.
PUT_MODE on a REG is done in two spots in timode_scalar_chain::convert_insn,
one is:
switch (GET_CODE (dst))
{
case REG:
if (GET_MODE (dst) == TImode)
{
PUT_MODE (dst, V1TImode);
fix_debug_reg_uses (dst);
}
if (GET_MODE (dst) == V1TImode)
when seeing the REG in SET_DEST and another one the hunk the patch adjusts.
Because bb 8 comes first in the order the pass walks the bbs, we first
notice the TImode pseudo on insn 63 where it is SET_SRC, use PUT_MODE there
unconditionally, so for a shared REG it changes all other uses in the IL,
and then don't call fix_debug_reg_uses because DF_REG_DEF_CHAIN (REGNO (src))
is non-NULL - the REG is set in insn 97 but we haven't processed it yet.
Later on we process insn 97, but because the REG in SET_DEST already has
V1TImode, we don't do anything, even when the src handling code earlier
relied on it being done.
The following patch fixes this by using similar code for both dst and src,
in particular calling fix_debug_reg_uses once when we actually change REG
mode from TImode to V1TImode, and not later on.
2023-05-04 Jakub Jelinek <jakub@redhat.com>
PR debug/109676
* config/i386/i386-features.cc (timode_scalar_chain::convert_insn):
If src is REG, change its mode to V1TImode and call fix_debug_reg_uses
for it only if it still has TImode. Don't decide whether to call
fix_debug_reg_uses based on whether SRC is ever set or not.
Jakub Jelinek [Wed, 3 May 2023 20:32:50 +0000 (22:32 +0200)]
libstdc++: Fix up abi.exp FAILs on powerpc64le-linux
This is an ABI problem on powerpc64le-linux, introduced in 13.1.
When libstdc++ is configured against old glibc, the
_ZSt10from_charsPKcS0_RDF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_St12chars_format@@GLIBCXX_3.4.31
_ZSt8to_charsPcS_DF128_St12chars_formati@@GLIBCXX_3.4.31
symbols are exported from the library, while when it is configured against
new enough glibc, those symbols aren't exported and we export instead
_ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128St12chars_format@@GLIBCXX_IEEE128_3.4.29
_ZSt8to_charsPcS_u9__ieee128St12chars_formati@@GLIBCXX_IEEE128_3.4.29
together with various other @@GLIBCXX_IEEE128_3.4.{29,30,31} and
@@CXXABI_IEEE128_1.3.13 symbols. The idea was that those *IEEE128* symbol
versions (similarly to *LDBL* symbol versions) are optional (but if it
appears, all symbols from it up to the version of the library appears),
but the base appears always.
My _Float128 from_chars/to_chars changes unfortunately broke this.
I believe nothing really uses those symbols if libstdc++ has been
configured against old glibc, so if 13.1 wasn't already released, it might
be best to make sure they aren't exported on powerpc64le-linux.
But as they were exported, I think the best resolution for this ABI
difference is to add those 4 symbols as aliases to the
GLIBCXX_IEEE128_3.4.29 *u9__ieee128* symbols, which the following patch
does.
2023-05-03 Jakub Jelinek <jakub@redhat.com>
* src/c++17/floating_from_chars.cc
(_ZSt10from_charsPKcS0_RDF128_St12chars_format): New alias to
_ZSt10from_charsPKcS0_Ru9__ieee128St12chars_format.
* src/c++17/floating_to_chars.cc (_ZSt8to_charsPcS_DF128_): New alias to
_ZSt8to_charsPcS_u9__ieee128.
(_ZSt8to_charsPcS_DF128_St12chars_format): New alias to
_ZSt8to_charsPcS_u9__ieee128St12chars_format.
(_ZSt8to_charsPcS_DF128_St12chars_formati): New alias to
_ZSt8to_charsPcS_u9__ieee128St12chars_formati.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: Updated.
Jakub Jelinek [Wed, 3 May 2023 20:31:40 +0000 (22:31 +0200)]
libstdc++: Fix up abi.exp FAILs on powerpc64-linux
As discussed on IRC, my _Float128/_Float64x support changes broke
abi.exp testing on powerpc64-linux.
The
_ZTIDF128_@@CXXABI_1.3.14
_ZTIDF64x@@CXXABI_1.3.14
_ZTIPDF128_@@CXXABI_1.3.14
_ZTIPDF64x@@CXXABI_1.3.14
_ZTIPKDF128_@@CXXABI_1.3.14
_ZTIPKDF64x@@CXXABI_1.3.14
symbols only appear on powerpc64le-linux (both when building against
very old glibcs as well as contemporary glibcs), while they don't
appear on powerpc64-linux, because the latter never has _Float128 or
_Float64x support.
But we were using the same baseline_symbols.txt file for both
powerpc64-linux and powerpc64le-linux, even when it contained quite a lot
of stuff specific to the latter; but that was just the IEEE128 related
stuff that appears only when configured against not very old glibc.
The following patch keeps those exports as is and just splits the
config/abi/post/ files, copies the current one to powerpc64le-linux
unmodified and removes the above mentioned symbols plus all
GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbols
from the powerpc64-linux version.
2023-05-03 Jakub Jelinek <jakub@redhat.com>
* configure.host (abi_baseline_pair): Use powerpc64le-linux-gnu
rather than powerpc64-linux-gnu for powerpc64le*-linux*.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Remove
_ZTI*DF128_, _ZTI*DF64x symbols and symbols in
GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbol
versions.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: New
file.
Jakub Jelinek [Tue, 2 May 2023 08:58:19 +0000 (10:58 +0200)]
ibstdc++: Shut up -Wattribute-alias warning [PR109694]
I've followed what other files do, using attribute alias with not really
matching function type (after all, it isn't really possible when it is a
constructor), but seems I've missed it warns:
../../../../../libstdc++-v3/src/c++98/ios_init.cc:203:8: warning: ‘void std::ios_base_library_init()’ alias between functions of incompatible types ‘void()’ and ‘void
+(std::ios_base::Init::)()’ [-Wattribute-alias=]
203 | void ios_base_library_init (void)
| ^~~~~~~~~~~~~~~~~~~~~
../../../../../libstdc++-v3/src/c++98/ios_init.cc:78:3: note: aliased declaration here
78 | ios_base::Init::Init()
| ^~~~~~~~
The PR talks about clang++ warning there (which I think isn't really
supported, libstdc++ sources ought to be built by GCC), but it warns
when built with GCC too.
The following patch fixes it by doing what other libstdc++ sources do in
those cases.
Jakub Jelinek [Fri, 28 Apr 2023 08:49:40 +0000 (10:49 +0200)]
libstdc++: Another attempt to ensure g++ 13+ compiled programs enforce gcc 13.2+ libstdc++.so.6 [PR108969]
GCC used to emit an instance of an empty ios_base::Init class in
every TU which included <iostream> to ensure it is std::cout etc.
is initialized, but thanks to Patrick work on some targets (which have
init_priority attribute support) it is now initialized only inside of
libstdc++.so.6/libstdc++.a.
This causes a problem if people do something that has never been supported,
try to run GCC 13 compiled C++ code against GCC 12 or earlier
libstdc++.so.6 - std::cout etc. are then never initialized because code
including <iostream> expects the library to initialize it and the library
expects code including <iostream> to do that.
The following patch is second attempt to make this work cheaply as the
earlier attempt of aliasing the std::cout etc. symbols with another symbol
version didn't work out due to copy relocation breaking the aliases appart.
The patch forces just a _ZSt21ios_base_library_initv undefined symbol
into all *.o files which include <iostream> and while there is no runtime
relocation against that, it seems to enforce the right version of
libstdc++.so.6. /home/jakub/src/gcc/obj08i/usr/local/ is the install
directory of trunk patched with this patch, /home/jakub/src/gcc/obj06/
is builddir of trunk without this patch, system g++ is GCC 12.1.1.
$ cat /tmp/hw.C
#include <iostream>
int
main ()
{
std::cout << "Hello, world!" << std::endl;
}
$ cd /home/jakub/src/gcc/obj08i/usr/local/bin
$ ./g++ -o /tmp/hw /tmp/hw.C
$ readelf -Wa /tmp/hw 2>/dev/null | grep initv
4: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZSt21ios_base_library_initv@GLIBCXX_3.4.32 (4)
71: 0000000000000000 0 FUNC GLOBAL DEFAULT UND _ZSt21ios_base_library_initv@GLIBCXX_3.4.32
$ /tmp/hw
/tmp/hw: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/hw)
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ /tmp/hw
/tmp/hw: /home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/hw)
$ g++ -o /tmp/hw /tmp/hw.C
$ /tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj06/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ /tmp/hw
Hello, world!
$ LD_LIBRARY_PATH=/home/jakub/src/gcc/obj08i/usr/local/lib64/ /tmp/hw
Hello, world!
On sparc-sun-solaris2.11 one I've actually checked a version which had
defined(_GLIBCXX_SYMVER_SUN) next to defined(_GLIBCXX_SYMVER_GNU), but
init_priority attribute doesn't seem to be supported there and so I couldn't
actually test how this works there. Using gas and Sun ld, Rainer, does one
need to use gas + gld for init_priority or something else?
2023-04-28 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/108969
* config/abi/pre/gnu.ver (GLIBCXX_3.4.32): Export
_ZSt21ios_base_library_initv.
* testsuite/util/testsuite_abi.cc (check_version): Add GLIBCXX_3.4.32
symver and make it the latestp.
* src/c++98/ios_init.cc (ios_base_library_init): New alias.
* acinclude.m4 (libtool_VERSION): Change to 6:32:0.
* include/std/iostream: If init_priority attribute is supported
and _GLIBCXX_SYMVER_GNU, force undefined _ZSt21ios_base_library_initv
symbol into the object.
* configure: Regenerated.
RISC-V: Fix wrong check of register occurrences [PR109535]
count_occurrences will conly count same RTX (same code and same mode),
but what we want to track is the occurrence of a register, a register
might appeared in the insn with different mode or contain in SUBREG.
Testcase coming from Kito.
gcc/ChangeLog:
PR target/109535
* config/riscv/riscv-vsetvl.cc (count_regno_occurrences): New function.
(pass_vsetvl::cleanup_insns): Fix bug.
gcc/testsuite/ChangeLog:
PR target/109535
* g++.target/riscv/rvv/base/pr109535.C: New test.
* gcc.target/riscv/rvv/base/pr109535.c: New test.
Kefu Chai [Mon, 1 May 2023 20:24:26 +0000 (21:24 +0100)]
libstdc++: Set _M_string_length before calling _M_dispose() [PR109703]
This always sets _M_string_length in the constructor for ranges of input
iterators, such as stream iterators.
We copy from the source range to the local buffer, and then repeatedly
reallocate a larger one if necessary. When disposing the old buffer,
_M_is_local() is used to tell if the buffer is the local one or not (and
so must be deallocated). In addition to comparing the buffer address
with the local buffer, _M_is_local() has an optimization hint so that
the compiler knows that for a string using the local buffer, there is an
invariant that _M_string_length <= _S_local_capacity (added for PR109299
via r13-6915-gbf78b43873b0b7). But we failed to set _M_string_length in
the constructor taking a pair of iterators, so the invariant might not
hold, and __builtin_unreachable() is reached. This causes UBsan errors,
and potentially misoptimization.
To ensure the invariant holds, _M_string_length is initialized to zero
before doing anything else, so that _M_is_local() doesn't see an
uninitialized value.
This issue only surfaces when constructing a string with a range of
input iterator, and the uninitialized _M_string_length happens to be
greater than _S_local_capacity, i.e., 15 for the std::string
specialization.
Jakub Jelinek [Wed, 3 May 2023 08:38:04 +0000 (10:38 +0200)]
c++: Fix up VEC_INIT_EXPR gimplification after r12-7069
During patch backporting, I've noticed that while most cp_walk_tree calls
with cp_fold_r callback callers were changed from &pset to cp_fold_data
&data, the VEC_INIT_EXPR gimplifications has not, so it still passes just
address of a hash_set<tree> and so if during the folding we ever touch
data->flags, we use uninitialized data there.
The following patch changes it to do the same thing as cp_fold_function
because the VEC_INIT_EXPR gimplifications will happen on function bodies
only.
2023-05-03 Jakub Jelinek <jakub@redhat.com>
* cp-gimplify.cc (cp_fold_data): Move definition earlier.
(cp_gimplify_expr): Pass address of ff_genericize | ff_mce_false
constructed data rather than &pset to cp_walk_tree with cp_fold_r.
Jason Merrill [Mon, 1 May 2023 14:57:20 +0000 (10:57 -0400)]
c++: array DMI and member fn [PR109666]
Here it turns out I also needed to adjust cfun when stepping out of the
member function to instantiate the DMI. But instead of adding that tweak,
let's unify with instantiate_body and just push_to_top_level instead of
trying to do the minimum subset of it. There was no measurable change in
compile time on stdc++.h.
This should also resolve 109506 without yet another tweak.
In the comments for PR108099 Jakub provided some testcases that demonstrated
that even before the regression noted in the patch we were getting the
semantics of this extension wrong: in the unsigned case we weren't producing
the corresponding standard unsigned type but another distinct one of the
same size, and in the signed case we were just dropping it on the floor and
not actually returning a signed type at all.
The former issue is fixed by using c_common_signed_or_unsigned_type instead
of unsigned_type_for, and the latter issue by adding a (signed_p &&
typedef_decl) case.
This patch introduces a failure on std/ranges/iota/max_size_type.cc due to
the latter issue, since the testcase expects 'signed rep_t' to do something
sensible, and previously we didn't. Now that we do, it exposes a bug in the
__max_diff_type::operator>>= handling of sign extension: when we evaluate
-1000 >> 2 in __max_diff_type we keep the MSB set, but leave the
second-most-significant bit cleared.
PR c++/108099
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Don't clear typedef_decl after 'unsigned
typedef' pedwarn. Use c_common_signed_or_unsigned_type. Also
handle 'signed typedef'.
gcc/testsuite/ChangeLog:
* g++.dg/ext/int128-8.C: New test.
* g++.dg/ext/unsigned-typedef2.C: New test.
* g++.dg/ext/unsigned-typedef3.C: New test.
Marek Polacek [Tue, 2 May 2023 19:48:40 +0000 (15:48 -0400)]
c++: Move -Wdangling-reference to -Wextra [PR109642]
Sadly, -Wdangling-reference generates false positives for std::span-like
user classes, and it seems imprudent to attempt to improve the heuristic
in GCC 13. Let's move the warning to -Wextra, that will hopefully
reduce the number of false positives the users have been seeing with 13.
I'm leaving the warning in -Wall in 14 where I think I can write code
to detect std::span-like classes.
PR c++/109642
PR c++/109640
PR c++/109671
gcc/c-family/ChangeLog:
* c.opt (Wdangling-reference): Move from -Wall to -Wextra.
gcc/ChangeLog:
* doc/invoke.texi: Document that -Wdangling-reference is
enabled by -Wextra.
Patrick Palka [Mon, 24 Apr 2023 17:39:54 +0000 (13:39 -0400)]
libstdc++: Fix __max_diff_type::operator>>= for negative values
This patch fixes sign bit propagation when right-shifting a negative
__max_diff_type value by more than one, a bug that our existing test
coverage didn't expose until r14-159-g03cebd304955a6 fixed the front
end's 'signed typedef-name' handling that the test relies on (which is
a non-standard extension to the language grammar).
libstdc++-v3/ChangeLog:
* include/bits/max_size_type.h (__max_diff_type::operator>>=):
Fix propagation of sign bit.
* testsuite/std/ranges/iota/max_size_type.cc: Avoid using the
non-standard 'signed typedef-name'. Add some compile-time tests
for right-shifting a negative __max_diff_type value by more than
one.
Jonathan Wakely [Fri, 28 Apr 2023 11:01:58 +0000 (12:01 +0100)]
libstdc++: Improve doxygen docs for <random>
Add @headerfile and @since tags. Add gamma_distribution to the correct
group (poisson distributions). Add a group for the sampling
distributions and add the missing definitions of their probability
functions. Add uniform_int_distribution back to the uniform
distributions group.
libstdc++-v3/ChangeLog:
* include/bits/random.h (gamma_distribution): Add to the right
doxygen group.
(discrete_distribution, piecewise_constant_distribution)
(piecewise_linear_distribution): Create a new doxygen group and
fix the incomplete doxygen comments.
* include/bits/uniform_int_dist.h (uniform_int_distribution):
Add to doxygen group.
Andrew Stubbs [Wed, 26 Apr 2023 14:23:48 +0000 (15:23 +0100)]
amdgcn: Fix addsub bug
The vec_fmsubadd instuction actually had add twice, by mistake.
Also improve code-gen for all the complex patterns by using properly
undefined values. Mostly this just prevents the compiler reserving space
in the stack frame.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (cmul<conj_op><mode>3): Use gcn_gen_undef.
(cml<addsub_as><mode>4): Likewise.
(vec_addsub<mode>3): Likewise.
(cadd<rot><mode>3): Likewise.
(vec_fmaddsub<mode>4): Likewise.
(vec_fmsubadd<mode>4): Likewise, and use sub for the odd lanes.
Jonathan Wakely [Wed, 26 Apr 2023 11:27:59 +0000 (12:27 +0100)]
libstdc++: Reduce Doxygen output for PDF
Including the header source code in the doxygen-generated PDF file makes
it too large, and causes pdflatex to run out of memory. If we only set
SOURCE_BROWSER=YES for the HTML docs then we won't include the sources
in the PDF file.
There are several macros defined for std::valarray that are only used to
generate repetitive code and then #undef'd. Those aren't useful in the
doxygen docs, especially the ones that reuse the same name in different
files. Omitting them avoids warnings about duplicate labels in the
refman.tex file.
libstdc++-v3/ChangeLog:
* doc/doxygen/user.cfg.in (SOURCE_BROWSER): Only set to YES for
HTML docs.
* include/bits/gslice_array.h (_DEFINE_VALARRAY_OPERATOR): Omit
from doxygen docs.
* include/bits/indirect_array.h (_DEFINE_VALARRAY_OPERATOR):
Likewise.
* include/bits/mask_array.h (_DEFINE_VALARRAY_OPERATOR):
Likewise.
* include/bits/slice_array.h (_DEFINE_VALARRAY_OPERATOR):
Likewise.
* include/std/valarray (_DEFINE_VALARRAY_UNARY_OPERATOR)
(_DEFINE_VALARRAY_AUGMENTED_ASSIGNMENT)
(_DEFINE_VALARRAY_EXPR_AUGMENTED_ASSIGNMENT)
(_DEFINE_BINARY_OPERATOR): Likewise.
Jakub Jelinek [Thu, 27 Apr 2023 09:36:54 +0000 (11:36 +0200)]
c: Fix up error-recovery on non-empty VLA initializers [PR109409]
On the following testcase we ICE, because after we emit the
variable-sized object may not be initialized except with an empty initializer
error we don't really reset the initializer to error_mark_node and then at
-Wformat checking time we ICE on seeing STRING_CST initializer for a VLA.
The following patch just arranges for error_mark_node to be returned after
the error diagnostics.
2023-04-27 Jakub Jelinek <jakub@redhat.com>
PR c/109409
* c-parser.cc (c_parser_initializer): Move diagnostics about
initialization of variable sized object with non-empty initializer
after c_parser_expr_no_commas call and ret.set_error (); after it.
Jakub Jelinek [Thu, 27 Apr 2023 09:35:55 +0000 (11:35 +0200)]
c: Fix up error-recovery on functions initialized as variables [PR109412]
The change to allow empty initializers in C broke error-recovery on the
following testcase. We are emitting function %qD is initialized like a
variable error early; if the initializer is non-empty, we just emit
another error that the initializer is invalid. Previously if it was empty,
we'd emit another error that scalar is being initialized by empty
initializer (not really correct), but now we instead just try to
build_zero_cst for the FUNCTION_TYPE and ICE on it.
The following patch just emits the same diagnostics for the empty
initializers as we emit for the non-empty ones.
2023-04-27 Jakub Jelinek <jakub@redhat.com>
PR c/107682
PR c/109412
* c-typeck.cc (pop_init_level): If constructor_type is FUNCTION_TYPE,
reject empty initializer as invalid.
Andrew Stubbs [Fri, 14 Apr 2023 16:05:15 +0000 (17:05 +0100)]
amdgcn: HardFP divide
Implement FP division using hardware instructions. This replaces both the
softfp library calls, and the --fast-math inaccurate divsion we had previously.
The GCN architecture does not have a single divide instruction, but it does
have a number of support instructions designed to make multiply-by-reciprocal
sufficiently accurate for non-fast-math usage.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (SV_SFDF): New iterator.
(SV_FP): New iterator.
(scalar_mode, SCALAR_MODE): Add identity mappings for scalar modes.
(recip<mode>2): Unify the two patterns using SV_FP.
(div_scale<mode><exec_vcc>): New insn.
(div_fmas<mode><exec>): New insn.
(div_fixup<mode><exec>): New insn.
(div<mode>3): Unify the two expanders and rewrite using hardfp.
* config/gcn/gcn.cc (gcn_md_reorg): Support "vccwait" attribute.
* config/gcn/gcn.md (unspec): Add UNSPEC_DIV_SCALE, UNSPEC_DIV_FMAS,
and UNSPEC_DIV_FIXUP.
(vccwait): New attribute.
gcc/testsuite/ChangeLog:
* gcc.target/gcn/fpdiv.c: Remove the -ffast-math requirement.
Richard Biener [Tue, 25 Apr 2023 12:56:44 +0000 (14:56 +0200)]
tree-optimization/109609 - correctly interpret arg size in fnspec
By majority vote and a hint from the API name which is
arg_max_access_size_given_by_arg_p this interprets a memory access
size specified as given as other argument such as for strncpy
in the testcase which has "1cO313" as specifying the _maximum_
size read/written rather than the exact size. There are two
uses interpreting it that way already and one differing. The
following adjusts the differing and clarifies the documentation.
PR tree-optimization/109609
* attr-fnspec.h (arg_max_access_size_given_by_arg_p):
Clarify semantics.
* tree-ssa-alias.cc (check_fnspec): Correctly interpret
the size given by arg_max_access_size_given_by_arg_p as
maximum, not exact, size.
Richard Biener [Mon, 24 Apr 2023 11:31:07 +0000 (13:31 +0200)]
rtl-optimization/109585 - alias analysis typo
When r10-514-gc6b84edb6110dd2b4fb improved access path analysis
it introduced a typo that triggers when there's an access to a
trailing array in the first access path leading to false
disambiguation.
Richard Biener [Fri, 21 Apr 2023 10:57:17 +0000 (12:57 +0200)]
tree-optimization/109573 - avoid ICEing on unexpected live def
The following relaxes the assert in vectorizable_live_operation
where we catch currently unhandled cases to also allow an
intermediate copy as it happens here but also relax the assert
to checking only.
PR tree-optimization/109573
* tree-vect-loop.cc (vectorizable_live_operation): Allow
unhandled SSA copy as well. Demote assert to checking only.
Eric Botcazou [Tue, 25 Apr 2023 08:46:16 +0000 (10:46 +0200)]
Remove obsolete configure code in gnattools
It was recently pointed out that we generate symbolic links to ghost files
when building the GNAT tools, as the mlib-tgt-specific-*.adb files are gone.
Jakub Jelinek [Tue, 25 Apr 2023 14:00:48 +0000 (16:00 +0200)]
testsuite: Fix up ext-floating2.C on powerpc64-linux
Another testcase that is failing on powerpc64-linux. The test expects
a diagnostics when float64 && float128 or in another spot when
float32 && float128. Now, float128 effective target is satisfied on
powerpc64-linux, despite __CPP_FLOAT128_T__ not being defined, because
one needs to add some extra options for it. I think 32-bit arm has
similar case for float16.
2023-04-25 Jakub Jelinek <jakub@redhat.com>
* g++.dg/cpp23/ext-floating2.C: Add dg-add-options for
float16, float32, float64 and float128.
Jakub Jelinek [Tue, 25 Apr 2023 12:38:01 +0000 (14:38 +0200)]
testsuite: Fix up ext-floating15.C tests on powerpc64-linux [PR109278]
I've noticed this test FAILs on powerpc64-linux, with
FAIL: g++.dg/cpp23/ext-floating15.C -std=gnu++98 (test for excess errors)
Excess errors:
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error: '_Float128' is not supported on this target
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error: '_Float128' is not supported on this target
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:1: error: variable or field 'bar' declared void
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:5: error: '_Float128' is not supported on this target
/home/jakub/gcc/gcc/testsuite/g++.dg/cpp23/ext-floating15.C:8:6: error: expected primary-expression before '_Float128'
and similarly other std versions.
powerpc64-linux is float128 target, but needs to add some options for it.
Jakub Jelinek [Thu, 20 Apr 2023 17:26:17 +0000 (19:26 +0200)]
c: Avoid -Wenum-int-mismatch warning for redeclaration of builtin acc_on_device [PR107041]
The new -Wenum-int-mismatch warning triggers with -Wsystem-headers in
<openacc.h>, for obvious reasons the builtin acc_on_device uses int
type argument rather than enum which isn't defined yet when the builtin
is created, while the OpenACC spec requires it to have acc_device_t
enum argument. The header makes sure it has int underlying type by using
negative and __INT_MAX__ enumerators.
I've tried to make the builtin typegeneric or just varargs, but that
changes behavior e.g. when one calls it with some C++ class which has
cast operator to acc_device_t, so the following patch instead disables
the warning for this builtin.
Jakub Jelinek [Tue, 25 Apr 2023 12:20:51 +0000 (14:20 +0200)]
powerpc: Fix up *branch_anddi3_dot for -m32 -mpowerpc64 [PR109566]
The following testcase reduced from newlib ICEs on powerpc-linux,
with -O2 -m32 -mpowerpc64 since r12-6433 PR102239 optimization was
added and on the original testcase since some ranger improvements in
GCC 13 made it no longer latent on newlib.
The problem is that the *branch_anddi3_dot define_insn_and_split
relies on the *rotldi3_mask_dot define_insn_and_split being recognized
during splitting. The rs6000_is_valid_rotate_dot_mask function checks whether
the mask is a CONST_INT which is a valid mask, but *rotl<mode>3_mask_dot in
addition to checking that it is a valid mask also has
(<MODE>mode == Pmode || UINTVAL (operands[3]) <= 0x7fffffff)
test in the condition. For TARGET_64BIT that doesn't add any further
requirements, but for !TARGET_64BIT && TARGET_POWERPC64 if the AND
second operand is larger than INT_MAX it will not be recognized.
The rs6000_is_valid_rotate_dot_mask function is used solely in one spot,
condition of *branch_anddi3_dot, so the following patch adjusts it
to check for that as well.
2023-04-25 Jakub Jelinek <jakub@redhat.com>
PR target/109566
* config/rs6000/rs6000.cc (rs6000_is_valid_rotate_dot_mask): For
!TARGET_64BIT, don't return true if UINTVAL (mask) << (63 - nb)
is larger than signed int maximum.
install.texi needs some updates for GCC 13 and trunk:
* We used a mixture of Solaris 2 and Solaris references. Since Solaris
1/SunOS 4 is ancient history by now, consistently use Solaris
everywhere. Likewise, explicit references to Solaris 11 can go in
many places since Solaris 11.3 and 11.4 is all GCC supports.
* Some caveats apply to both Solaris/SPARC and x86, like the difference
between as and gas.
* Some specifics are obsolete, like the /usr/ccs/bin path whose contents
was merged into /usr/bin in Solaris 11.0 already. Likewise, /bin/sh
is ksh93 since Solaris 11.0, so there's no need to explicitly use
/bin/ksh.
* I've removed the reference to OpenCSW: there's barely a need for external
sites to get additional packages. OpenCSW is mostly unmaintained these
days and has been found to be rather harmful then helping.
* The section on assembler and linker to use was partially duplicated.
Better keep the info in one place.
* GNAT is bundled in recent Solaris 11.4 updates, so recommend that.
Tested on i386-pc-solaris2.11 with make doc/gccinstall.{info,pdf} and
inspection of the latter.
Jakub Jelinek [Sat, 22 Apr 2023 08:24:29 +0000 (10:24 +0200)]
match.pd: Fix fneg/fadd optimization [PR109583]
The following testcase ICEs on x86, foo function since my r14-22
improvement, but bar already since r13-4122. The problem is the same,
in the if expression related_vector_mode is called and that starts with
gcc_assert (VECTOR_MODE_P (vector_mode));
but nothing in the fneg/fadd match.pd pattern actually checks if the
VEC_PERM type has VECTOR_MODE_P (vec_mode). In this case it has BLKmode
and so it ICEs.
The following patch makes sure we don't ICE on it.
2023-04-22 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/109583
* match.pd (fneg/fadd simplify): Don't call related_vector_mode
if vec_mode is not VECTOR_MODE_P.
Andrew MacLeod [Thu, 20 Apr 2023 17:10:40 +0000 (13:10 -0400)]
Do not ignore UNDEFINED ranges when determining PHI equivalences.
Do not ignore UNDEFINED name arguments when registering two-way equivalences
from PHIs.
PR tree-optimization/109564
gcc/
* gimple-range-fold.cc (fold_using_range::range_of_phi): Do no ignore
UNDEFINED range names when deciding if all PHI arguments are the same,
Patrick Palka [Wed, 19 Apr 2023 17:07:46 +0000 (13:07 -0400)]
c++: bad ggc_free in try_class_unification [PR109556]
Aside from correcting how try_class_unification copies multi-dimensional
'targs', r13-377-g3e948d645bc908 also made it ggc_free this copy as an
optimization. But this is wrong since the call to unify within might've
captured the args in persistent memory such as the satisfaction cache
(as part of constrained auto deduction).
PR c++/109556
gcc/cp/ChangeLog:
* pt.cc (try_class_unification): Don't ggc_free the copy of
'targs'.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-placeholder13.C: New test.
Jakub Jelinek [Wed, 19 Apr 2023 08:01:04 +0000 (10:01 +0200)]
testsuite: Fix up pr109524.C for -std=c++23 [PR109524]
This testcase was reduced such that it isn't valid C++23, so with my
usual testing with GXX_TESTSUITE_STDS=98,11,14,17,20,2b it fails:
FAIL: g++.dg/pr109524.C -std=gnu++2b (test for excess errors)
.../gcc/testsuite/g++.dg/pr109524.C: In function 'nn hh(nn)':
.../gcc/testsuite/g++.dg/pr109524.C:35:12: error: cannot bind non-const lvalue reference of type 'nn&' to an rvalue of type 'nn'
.../gcc/testsuite/g++.dg/pr109524.C:17:6: note: initializing argument 1 of 'nn::nn(nn&)'
The following patch fixes that and I've verified it doesn't change
anything on what the test was testing, it still ICEs in r13-7198 and
passes in r13-7203, now in all language modes (except for 98 where
it is intentionally UNSUPPORTED).
2023-04-19 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/109524
* g++.dg/pr109524.C (nn::nn): Change argument type from nn & to
const nn &.
The RVV test harness currently sets the ISA according to the target
tuple, but doesn't also set the ABI. This just sets the ABI to match
the ISA, though we should really also be respecting the user's specific
ISA to test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/rvv.exp (gcc_mabi): New variable.
The test case that was added is rv64i-specific, as there's better ways
to generate this code on rv32i (where the long/int cast is a NOP) and on
rv64i_zba (where we have word shifts). This renames the original test
case and adds two more for those targets.
gcc/testsuite/ChangeLog:
PR target/106602
* gcc.target/riscv/pr106602.c: Moved to...
* gcc.target/riscv/pr106602-rv64i.c: ...here.
* gcc.target/riscv/pr106602-rv32i.c: New test.
* gcc.target/riscv/pr106602-rv64i_zba.c: New test.
Jonathan Wakely [Tue, 18 Apr 2023 16:22:40 +0000 (17:22 +0100)]
libstdc++: Fix preprocessor condition in linker script [PR108969]
The linker script is preprocessed with $(top_builddir)/config.h not the
include/$target/bits/c++config.h version, which means that configure
macros do not have the _GLIBCXX_ prefix yet.
The _GLIBCXX_SYMVER_GNU and _GLIBCXX_SHARED checks are redundant,
because the gnu.ver file is only used for _GLIBCXX_SYMVER_GNU and the
linker script is only used for the shared library. Remove those.
Jonathan Wakely [Tue, 18 Apr 2023 13:37:38 +0000 (14:37 +0100)]
libstdc++: Export global iostreams with GLIBCXX_3.4.31 symver [PR108969]
Since GCC 13 the global iostream objects are only initialized once in
libstdc++, and not by a std::ios::Init object in every translation unit
that includes <iostream>. To avoid using uninitialized streams defined
in an older libstdc++.so, translation units using the global iostreams
should depend on the GLIBCXX_3.4.31 symver.
Define std::cin as std::__io::cin and then export it as
std::cin@@GLIBCXX_3.4.31 so that references to std::cin bind to the new
symver. Also export it as @GLIBCXX_3.4 for backwards compatibility
libstdc++-v3/ChangeLog:
PR libstdc++/108969
* src/Makefile.am: Move globals_io.cc to here.
* src/Makefile.in: Regenerate.
* src/c++98/Makefile.am: Remove globals_io.cc from here.
* src/c++98/Makefile.in: Regenerate.
* src/c++98/globals_io.cc [_GLIBCXX_SYMVER_GNU] (cin): Adjust
symbol name and then export with GLIBCXX_3.4.31 symver.
(cout, cerr, clog, wcin, wcout, wcerr, wclog): Likewise.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/m68k-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/riscv64-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt:
Regenerate.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt:
Regenerate.
* config/abi/pre/gnu.ver: Add iostream objects to new symver.
Kito Cheng [Tue, 18 Apr 2023 10:07:06 +0000 (18:07 +0800)]
Docs: Add doc for RISC-V vector intrinsics
Document which version of RISC-V vector intrinsics has implemented in
GCC.
gcc/ChangeLog:
* doc/extend.texi (Target Builtins): Add RISC-V Vector
Intrinsics.
(RISC-V Vector Intrinsics): Document GCC implemented which
version of RISC-V vector intrinsics and its reference.
Richard Biener [Tue, 18 Apr 2023 09:49:48 +0000 (11:49 +0200)]
tree-optimization/109539 - restrict PHI handling in access diagnostics
Access diagnostics visits the SSA def-use chains to diagnose things like
dangling pointer uses. When that runs into PHIs it tries to prove
all incoming pointers of which one is the currently visited use are
related to decide whether to keep looking for the PHI def uses.
That turns out to be overly optimistic and thus costly. The following
scraps the existing handling for simply requiring that we eventually
visit all incoming pointers of the PHI during the def-use chain
analysis and only then process uses of the PHI def.
Note this handles backedges of natural loops optimistically, diagnosing
the first iteration. There's gcc.dg/Wuse-after-free-2.c containing
a testcase requiring this.
PR tree-optimization/109539
* gimple-ssa-warn-access.cc (pass_waccess::check_pointer_uses):
Re-implement pointer relatedness for PHIs.
Patrick Palka [Tue, 18 Apr 2023 11:21:13 +0000 (07:21 -0400)]
libstdc++: Implement range_adaptor_closure from P2387R3 [PR108827]
PR libstdc++/108827
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (__cpp_lib_ranges): Bump value
for C++23.
* include/std/ranges (range_adaptor_closure): Define for C++23.
* include/std/version (__cpp_lib_ranges): Bump value for
C++23.
* testsuite/std/ranges/version_c++23.cc: Bump expected value
of __cpp_lib_ranges.
* testsuite/std/ranges/range_adaptor_closure.cc: New test.
Jakub Jelinek [Tue, 18 Apr 2023 10:18:13 +0000 (12:18 +0200)]
rust: Disable --enable-languages=rust and silently exclude it from --enable-languages=all for GCC 13
As discussed on IRC, gccrs can't compile the standard libraries yet
and requires annoying -frust-incomplete-and-experimental-compiler-do-not-use
option to compile anything.
As such it is better to disable this at least for GCC 13.1, we'd keep
it allowed on the trunk where hopefully support to compile at least
some standard libraries will land soon and eventually a borrow checker.
If enough Rust support is backported from trunk to 13 branch before
13.2, we could revert this change then.
Tested on x86_64-linux with --enable-languages=c,c++,rust and
--enable-languages=c,c++,all , ok for 13 branch?
2023-04-18 Jakub Jelinek <jakub@redhat.com>
* configure.ac: For --enable-languages= mentioning explicitly
rust emit an error, if included in all etc., silently disable
rust.
* configure: Regenerated.
libsanitizer, darwin: Unsupport Darwin >= 22 for now.
The mechanism for location dyld has altered from Darwin22 since dyld is now
in the shared cache. The implemented mechanism for walking the cache uses
Apple Blocks which GCC does not yet support, and the fallback to the original
mechanism does not work there.
Until a suitable work-around can be found, unsupport Darwin22+.
Patrick Palka [Mon, 17 Apr 2023 22:52:07 +0000 (18:52 -0400)]
c++: bound ttp level lowering [PR109531]
Here when level lowering the bound ttp TT<typename T::type> via the
substitution T=C, we're neglecting to canonicalize (and thereby strip
of simple typedefs) the substituted template arguments {A<int>} before
determining the new canonical type via hash table lookup. This leads to
a hash mismatch ICE for the two equivalent types TT<int> and TT<A<int>>
since iterative_hash_template_arg assumes type arguments are already
canonicalized.
We can fix this by canonicalizing or coercing the substituted arguments
directly, but seeing as creation and ordinary substitution of bound ttps
both go through lookup_template_class, which in turn performs the desired
coercion/canonicalization, it seems preferable to make this code path go
through lookup_template_class as well.
PR c++/109531
gcc/cp/ChangeLog:
* pt.cc (tsubst) <case BOUND_TEMPLATE_TEMPLATE_PARM>:
In the level-lowering case just use lookup_template_class
to rebuild the bound ttp.
gcc/testsuite/ChangeLog:
* g++.dg/template/canon-type-20.C: New test.
* g++.dg/template/ttp36.C: New test.
Martin Jambor [Mon, 17 Apr 2023 10:59:51 +0000 (12:59 +0200)]
ipa: Fix double reference-count decrements for the same edge (PR 107769, PR 109318)
It turns out that since addition of the code that can identify globals
which are only read from, the code that keeps track of the references
can decrement their count for the same calls, once during IPA-CP and
then again during inlining. Fixed by adding a special flag to the
pass-through variant and simply wiping out the reference to the
refdesc structure from the constant ones.
Moreover, during debugging of the issue I have discovered that the
code removing references could remove a reference associated with the
same statement but of a wrong type. In all cases it wanted to remove
an IPA_REF_ADDR reference so removing a lesser one instead should do
no harm in practice, but we should try to be consistent and so this
patch extends symtab_node::find_reference so that it searches for a
reference of a given type only.
gcc/ChangeLog:
2023-04-14 Martin Jambor <mjambor@suse.cz>
PR ipa/107769
PR ipa/109318
* cgraph.h (symtab_node::find_reference): Add parameter use_type.
* ipa-prop.h (ipa_pass_through_data): New flag refdesc_decremented.
(ipa_zap_jf_refdesc): New function.
(ipa_get_jf_pass_through_refdesc_decremented): Likewise.
(ipa_set_jf_pass_through_refdesc_decremented): Likewise.
* ipa-cp.cc (ipcp_discover_new_direct_edges): Provide a value for
the new parameter of find_reference.
(adjust_references_in_caller): Likewise. Make sure the constant jump
function is not used to decrement a refdec counter again. Only
decrement refdesc counters when the pass_through jump function allows
it. Added a detailed dump when decrementing refdesc counters.
* ipa-prop.cc (ipa_print_node_jump_functions_for_edge): Dump new flag.
(ipa_set_jf_simple_pass_through): Initialize the new flag.
(ipa_set_jf_unary_pass_through): Likewise.
(ipa_set_jf_arith_pass_through): Likewise.
(remove_described_reference): Provide a value for the new parameter of
find_reference.
(update_jump_functions_after_inlining): Zap refdesc of new jfunc if
the previous pass_through had a flag mandating that we do so.
(propagate_controlled_uses): Likewise. Only decrement refdesc
counters when the pass_through jump function allows it.
(ipa_edge_args_sum_t::duplicate): Provide a value for the new
parameter of find_reference.
(ipa_write_jump_function): Assert the new flag does not have to be
streamed.
* symtab.cc (symtab_node::find_reference): Add parameter use_type, use
it in searching.
Philipp Tomsich [Thu, 23 Mar 2023 18:47:57 +0000 (19:47 +0100)]
aarch64: disable LDP via tuning structure for -mcpu=ampere1
AmpereOne (-mcpu=ampere1) breaks LDP instructions into two uops.
Given the chance that this causes instructions to slip into the next
decoding cycle and the additional overheads when handling
cacheline-crossing LDP instructions, we disable the generation of LDP
isntructions through the tuning structure from instruction combining
(such as in peephole2).
Given the code-density benefits in builtins and prologue/epilogue
expansion, we allow LDPs there.
This commit:
* adds a new tuning option AARCH64_EXTRA_TUNE_NO_LDP_COMBINE
* allows -moverride=tune=... to override this
These changes are benchmark-driven, yielding the following changes
(with a net-overall improvement):
503.bwaves_r. -0.88%
507.cactuBSSN_r 0.35%
508.namd_r 3.09%
510.parest_r -2.99%
511.povray_r 5.54%
519.lbm_r 15.83%
521.wrf_r 0.56%
526.blender_r 2.47%
527.cam4_r 0.70%
538.imagick_r 0.00%
544.nab_r -0.33%
549.fotonik3d_r. -0.42%
554.roms_r 0.00%
-------------------------
= total 1.79%
Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Co-Authored-By: Di Zhao <di.zhao@amperecomputing.com>
gcc/ChangeLog:
* config/aarch64/aarch64-tuning-flags.def (AARCH64_EXTRA_TUNING_OPTION):
Add AARCH64_EXTRA_TUNE_NO_LDP_COMBINE.
* config/aarch64/aarch64.cc (aarch64_operands_ok_for_ldpstp):
Check for the above tuning option when processing loads.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/ampere1-no_ldp_combine.c: New test.
Jakub Jelinek [Mon, 17 Apr 2023 09:45:53 +0000 (11:45 +0200)]
testsuite: Fix up vect-simd-clone-1[678]f.c tests some more
With
make check-gcc check-g++ -j32 -k RUNTESTFLAGS='--target_board=unix\{-m32,-m32/-mavx,-m32/-mavx512f,-m32/-march=cascadelake,-m64,-m64/-mavx,-m64/-mavx512f,-m64/-march=cascadelake\}
+vect.exp=vect-simd-clone*'
the vect-simd-clone-1[678]f.c tests fail with -m32/-mavx512f and -m32/-march=cascadelake,
in that case there are zero matches rather than the 4 expected for ia32.
-m64/-mavx512f and -m64/-march=cascadelake works fine though (2 expected
matches).
So, the following patch just adds -mno-avx512f for x86 non-lp64.
Richard Biener [Mon, 17 Apr 2023 07:22:57 +0000 (09:22 +0200)]
tree-optimization/109524 - ICE with VRP edge removal
VRP queues edges to process late for updating global ranges for
__builtin_unreachable. But this interferes with edge removal
from substitute_and_fold. The following deals with this by
looking up the edge with source/dest block indices which do not
become stale.
PR tree-optimization/109524
* tree-vrp.cc (remove_unreachable::m_list): Change to a
vector of pairs of block indices.
(remove_unreachable::maybe_register_block): Adjust.
(remove_unreachable::remove_and_update_globals): Likewise.
Deal with removed blocks.
As PR108809 mentioned, vec_xl_len_r and vec_xst_len_r are tested
in gcc.target/powerpc/builtins-5-p9-runnable.c.
The vector operand of these two bifs are different from the view
of v16_int8 between BE and LE, even it is same from the view of
128bits(uint128/V1TI).
The test case gcc.target/powerpc/builtins-5-p9-runnable.c was
written for LE environment, this patch updates it for BE.
Tested on ppc64 BE and LE.
Is this ok for trunk?
BR,
Jeff (Jiufu)
gcc/testsuite/ChangeLog:
PR testsuite/108809
* gcc.target/powerpc/builtins-5-p9-runnable.c: Update for BE.
git://gcc.gnu.org / gcc.git / log