Jonathan Wakely [Fri, 2 Dec 2022 16:18:43 +0000 (16:18 +0000)]
libstdc++: Change class-key for duration and time_point to class
We define these with the 'struct' keyword, but the standard uses
'class'. This results in warnings if users try to refer to them using
elaborated type specifiers.
libstdc++-v3/ChangeLog:
* include/bits/chrono.h (duration, time_point): Change 'struct'
to 'class'.
Jonathan Wakely [Thu, 26 Jan 2023 10:55:28 +0000 (10:55 +0000)]
libstdc++: Add returns_nonnull to non-inline std::map detail [PR108554]
std::map uses a non-inline function to rebalance its tree and the
compiler can't see that it always returns a valid pointer (assuming
valid inputs, which is a precondition anyway). This can result in
-Wnull-derefernce warnings for valid code, because the compiler thinks
there is a path where the function returns null.
Adding the returns_nonnull attribute tells the compiler that is can't
happen. While we're doing that, we might as well also add a nonnull
attribute to the rebalancing functions too.
libstdc++-v3/ChangeLog:
PR libstdc++/108554
* include/bits/stl_tree.h (_Rb_tree_insert_and_rebalance): Add
nonnull attribute.
(_Rb_tree_rebalance_for_erase): Add nonnull and returns_nonnull
attributes.
* testsuite/23_containers/map/modifiers/108554.cc: New test.
Jonathan Wakely [Thu, 22 Sep 2022 17:36:04 +0000 (18:36 +0100)]
libstdc++: Optimize std::bitset<N>::to_string
This makes to_string approximately twice as fast at any optimization
level. Instead of iterating through every bit, jump straight to the next
bit that is set, by using _Find_first and _Find_next.
libstdc++-v3/ChangeLog:
* include/std/bitset (bitset::_M_copy_to_string): Find set bits
instead of iterating over individual bits.
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.
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.
Jonathan Wakely [Tue, 17 May 2022 14:14:39 +0000 (15:14 +0100)]
libstdc++: Add attributes to functions in <memory_resource>
Add attributes to the accessors for the global memory resource objects,
to allow the compiler to eliminate redundant calls to them. For example,
multiple calls to std::pmr::new_delete_resource() will always return the
same object, and so the compiler can replace them with a single call.
Ideally we would like adjacent calls to std::pmr::get_default_resource()
to be combined into a single call by the CSE pass. The 'pure' attribute
would permit that. However, the standard requires that calls to
std::pmr::set_default_resource() synchronize with subsequent calls to
std::pmr::get_default_resource(). With 'pure' the DCE pass might
eliminate seemingly redundant calls to std::pmr::get_default_resource().
That might be unsafe, because the caller might be relying on the
associated synchronization. We could use a hypothetical attribute that
allows CSE but not DCE, but we don't have one. So it can't be 'pure'.
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, 7 Sep 2022 19:17:04 +0000 (20:17 +0100)]
libstdc++: Find make_error_code and make_error_condition via ADL only
The new proposed resolution for LWG 3629 says that std::error_code and
std::error_condition should only use ADL to find their customization
points. This means we need to use a poison pill to prevent lookup from
finding overloads in the enclosing namespaces.
We can also remove the forward declarations of std::make_error_code and
std::make_error_condition, because they aren't needed now. ADL can find
them anyway (when std is an associated namespace), and unqualified name
lookup will not (and should not) find them.
libstdc++-v3/ChangeLog:
* include/std/system_error (__adl_only::make_error_code): Add
deleted function.
(__adl_only::make_error_condition): Likewise.
(error_code::error_code(ErrorCodeEnum)): Add using-declaration
for deleted function.
(error_condition::error_condition(ErrorConditionEnum)):
Likewise.
* testsuite/19_diagnostics/error_code/cons/lwg3629.cc: New test.
* testsuite/19_diagnostics/error_condition/cons/lwg3629.cc: New test.
Jonathan Wakely [Tue, 17 May 2022 13:50:32 +0000 (14:50 +0100)]
libstdc++: Add attributes to <system_error> and related
Add the const attribute to std::future_category() and
std::iostream_category(), to match the existing attributes on
std::generic_category() and std::system_category().
Also add [[nodiscard]] to those functions and to the comparison
operators for std::error_code and std::error_condition, and to
std::make_error_code and std::make_error_condition overloads.
Jonathan Wakely [Fri, 25 Nov 2022 11:40:37 +0000 (11:40 +0000)]
libstdc++: Fix orphaned/nested output of configure checks
This moves two AC_MSG_RESULT lines for <uchar.h> features so that they
are only printed when the corresponding AC_MSG_CHECKING actually
happened. This fixes configure output like:
checking for uchar.h... no
no
checking for int64_t... yes
Also move the AC_MSG_CHECKING for libbacktrace support so it doesn't
come after AC_CHECK_HEADERS output. This fixes:
checking whether to build libbacktrace support... checking for sys/mman.h... (cached) yes
yes
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_CHECK_UCHAR_H): Don't use AC_MSG_RESULT
unless the AC_MSG_CHECKING happened.
* configure: Regenerate.
Jonathan Wakely [Tue, 28 Mar 2023 10:12:58 +0000 (11:12 +0100)]
libstdc++: More fixes for null pointers used with std::char_traits
The std::char_traits member functions require that [p,p+n) is a valid
range, which is true for p==nullptr iff n==0. But we must not call
memcpy, memset etc, in that case, as they require non-null pointers even
when n==0.
This std::char_traits<char> and std::char_traits<wchar_t> explicit
specializations are already correct, but the primary template has some
bugs.
libstdc++-v3/ChangeLog:
* include/bits/char_traits.h (char_traits::copy): Return without
using memcpy if n==0.
(char_traits::assign): Likewise for memset.
Jonathan Wakely [Tue, 28 Mar 2023 09:50:40 +0000 (10:50 +0100)]
libstdc++: Tell GCC what basic_string::_M_is_local() means [PR109299]
This avoids a bogus warning about overflowing a buffer, because GCC
can't tell that we don't copy into the buffer unless it fits. By adding
a __builtin_unreachable() hint we inform the compiler about the
invariant that the buffer is only used when it's big enough.
This can also improve codegen, by eliminating dead code that GCC
couldn't tell was unreachable.
libstdc++-v3/ChangeLog:
PR libstdc++/109299
* include/bits/basic_string.h (basic_string::_M_is_local()): Add
hint for compiler that local strings fit in the local buffer.
Jonathan Wakely [Mon, 16 Jan 2023 10:15:41 +0000 (10:15 +0000)]
libstdc++: Fix copyright notice to use usual form [PR108413]
libstdc++-v3/ChangeLog:
PR libstdc++/108413
* include/c_compatibility/stdatomic.h: Change copyright line to
be consistent with other headers contributed under DCO terms.
* include/std/expected: Add full stop to copyright line.
Xi Ruoyao [Mon, 27 Mar 2023 17:48:02 +0000 (01:48 +0800)]
fixincludes: Declare memmem if it's not declared in system headers [PR109293]
memmem is not POSIX so the system may lack it. Then libiberty will
provide an implementation, but it's a "supplemental function" and not
declared in libiberty.h. We need to declare the prototype to use it
then.
See libiberty doc at
https://gcc.gnu.org/onlinedocs/libiberty/Supplemental-Functions.html.
Tested by bootstrapping GCC in the following container environments on
x86_64-linux-gnu:
1. "Vanilla" system with memmem in Glibc.
2. memmem removed from string.h.
3. memmem removed from both string.h and libc.so.
For 3, also verified that memmem from libiberty is linked into fixincl
executable.
Note that the backport does not contain a complete regeneration of
configure and config.h.in (attempting such regeneration resulted in all
the USED_FOR_TARGET conditional disappearing; this already happened in
trunk at r13-2200).
Eric Botcazou [Tue, 28 Mar 2023 08:13:24 +0000 (10:13 +0200)]
Fix PR target/109140
This is a regression present on the mainline and 12 branch at -O2, but the
issue is related to vectorization so was present at -O3 in earlier versions.
The vcondu expander that was added for VIS 3 more than a decade ago does not
fully work, because it does not filter out the unsigned condition codes (the
instruction is an UNSPEC that accepts only signed condition codes).
While I was at it, I also added the missing vcond and vcondu expanders for
the new comparison instructions that were added in VIS 4.
gcc/
PR target/109140
* config/sparc/sparc.cc (sparc_expand_vcond): Call signed_condition
on operand #3 to get the final condition code. Use std::swap.
* config/sparc/sparc.md (vcondv8qiv8qi): New VIS 4 expander.
(fucmp<gcond:code>8<P:mode>_vis): Move around.
(fpcmpu<gcond:code><GCM:gcm_name><P:mode>_vis): Likewise.
(vcondu<GCM:mode><GCM:mode>): New VIS 4 expander.
Harald Anlauf [Thu, 2 Mar 2023 21:37:14 +0000 (22:37 +0100)]
Fortran: fix CLASS attribute handling [PR106856]
gcc/fortran/ChangeLog:
PR fortran/106856
* class.cc (gfc_build_class_symbol): Handle update of attributes of
existing class container.
(gfc_find_derived_vtab): Fix several memory leaks.
(find_intrinsic_vtab): Ditto.
* decl.cc (attr_decl1): Manage update of symbol attributes from
CLASS attributes.
* primary.cc (gfc_variable_attr): OPTIONAL shall not be taken or
updated from the class container.
* symbol.cc (free_old_symbol): Adjust management of symbol versions
to not prematurely free array specs while working on the declation
of CLASS variables.
gcc/testsuite/ChangeLog:
PR fortran/106856
* gfortran.dg/interface_41.f90: Remove dg-pattern from valid testcase.
* gfortran.dg/class_74.f90: New test.
* gfortran.dg/class_75.f90: New test.
Jerry DeLisle [Mon, 27 Mar 2023 01:44:35 +0000 (18:44 -0700)]
Fortran: Modify checks to avoid referencing NULL pointer.
Backport from mainline.
gcc/fortran/ChangeLog:
PR fortran/102331
* decl.cc (attr_decl1): Guard against NULL pointer.
* parse.cc (match_deferred_characteristics): Include BT_CLASS in check
for derived being undefined.
Martin Jambor [Wed, 22 Mar 2023 15:59:45 +0000 (16:59 +0100)]
ipa-cp: Fix various issues in update_specialized_profile (PR 107925)
The patch below fixes various issues in function
update_specialized_profile. The main is removal of the assert which
is bogus in the case of recursive cloning. The division of
unexplained counts is guesswork, which then leads to updates of counts
of recursive edges, which then can be redirected to the new clone and
their count subtracted from the count and there simply may not be
enough left in the count of the original node - especially when we
clone a lot because of using --param ipa-cp-eval-threshold=1.
The other issue was omission to drop the count of the original node to
ipa count. And when calculating the remainder, we should use
lenient_count_portion_handling to account for partial train runs.
Finally, the patch adds dumping of the original count which I think
is useful.
gcc/ChangeLog:
2023-02-17 Martin Jambor <mjambor@suse.cz>
PR ipa/107925
* ipa-cp.cc (update_specialized_profile): Drop orig_node_count to
ipa count, remove assert, lenient_count_portion_handling, dump
also orig_node_count.
Matthias Kretz [Tue, 21 Mar 2023 13:20:52 +0000 (14:20 +0100)]
libstdc++: Skip integer division optimization for Clang
Clang ICEs on _SimdImplX86::_S_divides. The function is only working
around a missed optimization and not necessary for correctness.
Therefore, don't use it for Clang.
Peter Bergner [Mon, 20 Mar 2023 14:12:47 +0000 (09:12 -0500)]
rs6000: Don't ICE when compiling the __builtin_vec_xst_trunc built-in [PR109178]
When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
for the MEM operand which causes an unrecognizable insn ICE. The solution
is to use the correct TMODE mode.
2023-03-20 Peter Bergner <bergner@linux.ibm.com>
gcc/
PR target/109178
* config/rs6000/rs6000-builtin.cc (stv_expand_builtin): Use tmode.
gcc/testsuite/
PR target/109178
* gcc.target/powerpc/pr109178.c: New test.
François Dumont [Wed, 5 Oct 2022 17:24:55 +0000 (19:24 +0200)]
libstdc++: Fix gdb FilteringTypePrinter
Once we found a matching FilteringTypePrinter instance we look for the associated
typedef and check that the returned Python Type is equal to the Type to recognize.
But gdb Python Type includes properties to distinguish a typedef from the actual
type. So use gdb.types.get_basic_type to check if we are indeed on the same type.
Additionnaly enhance FilteringTypePrinter matching mecanism by introducing targ1 that,
if not None, will be used as the 1st template parameter.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (FilteringTypePrinter): Rename 'match' field
'template'. Add self.targ1 to specify the first template parameter of the instantiation
to match.
(add_one_type_printer): Add targ1 optional parameter, default to None.
Use gdb.types.get_basic_type to compare the type to recognize and the type
returned from the typedef lookup.
(register_type_printers): Adapt calls to add_one_type_printers.
François Dumont [Mon, 26 Sep 2022 17:14:54 +0000 (19:14 +0200)]
libstdc++: Fix gdb pretty printers when dealing with std::string
Since revision 33b43b0d8cd2de722d177ef823930500948a7487 std::string and other
similar typedef are ambiguous from a gdb point of view because it matches both
std::basic_string<char> and std::__cxx11::basic_string<char> symbols. For those
typedef add a workaround to accept the substitution as long as the same regardless
of __cxx11 namespace.
Also avoid to register printers for types in std::__cxx11::__8:: namespace, there is
no such symbols.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (Printer.add_version): Do not add version
namespace for __cxx11 symbols.
(add_one_template_type_printer): Likewise.
(add_one_type_printer): Likewise.
(FilteringTypePrinter._recognizer.recognize): Add a workaround for std::string & al
ambiguous typedef matching both std:: and std::__cxx11:: symbols.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Remove obsolete
\#define _GLIBCXX_USE_CXX11_ABI 0.
* testsuite/libstdc++-prettyprinters/simple.cc: Likewise. Adapt test to accept
std::__cxx11::list.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.
* testsuite/libstdc++-prettyprinters/whatis.cc: Likewise.
* testsuite/libstdc++-prettyprinters/80276.cc: Likewise and remove xfail for c++20
and debug mode.
* testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
Paul Thomas [Mon, 20 Mar 2023 06:23:29 +0000 (06:23 +0000)]
Fortran: Allow external function from in an associate block [PR87127]
2023-03-20 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/87127
* resolve.cc (check_host_association): If an external function
is typed but not declared explicitly to be external, change the
old symbol from a variable to an external function.
gcc/testsuite/
PR fortran/87127
* gfortran.dg/external_procedures_4.f90: New test.
Jakub Jelinek [Fri, 17 Mar 2023 17:59:56 +0000 (18:59 +0100)]
tree-inline: Fix up multiversioning with vector arguments [PR105554]
The following testcase ICEs, because we call tree_function_versioning from
old_decl which has target attributes not supporting V4DImode and so
DECL_MODE of DECL_ARGUMENTS is BLKmode, while new_decl supports those.
tree_function_versioning initially copies DECL_RESULT and DECL_ARGUMENTS
from old_decl to new_decl, then calls initialize_cfun to create cfun
and only when the cfun is created it can later actually remap_decl
DECL_RESULT and DECL_ARGUMENTS etc.
The problem is that initialize_cfun -> push_struct_function ->
allocate_struct_function calls relayout_decl on DECL_RESULT and
DECL_ARGUMENTS, which clobbers DECL_MODE of old_decl and we then ICE because
of it.
In particular, allocate_struct_function does:
if (!abstract_p)
{
/* Now that we have activated any function-specific attributes
that might affect layout, particularly vector modes, relayout
each of the parameters and the result. */
relayout_decl (result);
for (tree parm = DECL_ARGUMENTS (fndecl); parm;
parm = DECL_CHAIN (parm))
relayout_decl (parm);
/* Similarly relayout the function decl. */
targetm.target_option.relayout_function (fndecl);
}
if (!abstract_p && aggregate_value_p (result, fndecl))
{
#ifdef PCC_STATIC_STRUCT_RETURN
cfun->returns_pcc_struct = 1;
#endif
cfun->returns_struct = 1;
}
Now, in the case of tree_function_versioning, I believe all that we need
from these is possibly the
targetm.target_option.relayout_function (fndecl);
call (arm only), we will remap DECL_RESULT and DECL_ARGUMENTS later on
and copy_decl_for_dup_finish in that case will handle all we need:
/* For vector typed decls make sure to update DECL_MODE according
to the new function context. */
if (VECTOR_TYPE_P (TREE_TYPE (copy)))
SET_DECL_MODE (copy, TYPE_MODE (TREE_TYPE (copy)));
We don't need the cfun->returns_*struct either, because we override it
in initialize_cfun a few lines later:
/* Copy items we preserve during cloning. */
...
cfun->returns_struct = src_cfun->returns_struct;
cfun->returns_pcc_struct = src_cfun->returns_pcc_struct;
So, to avoid the clobbering of DECL_RESULT/DECL_ARGUMENTS of old_decl,
the following patch arranges allocate_struct_function to be called with
abstract_p true and calls targetm.target_option.relayout_function (fndecl);
by hand.
The removal of DECL_RESULT/DECL_ARGUMENTS copying at the start of
initialize_cfun is removed because the only caller -
tree_function_versioning, does that unconditionally before.
2023-03-17 Jakub Jelinek <jakub@redhat.com>
PR target/105554
* function.h (push_struct_function): Add ABSTRACT_P argument defaulted
to false.
* function.cc (push_struct_function): Add ABSTRACT_P argument, pass it
to allocate_struct_function instead of false.
* tree-inline.cc (initialize_cfun): Don't copy DECL_ARGUMENTS
nor DECL_RESULT here. Pass true as ABSTRACT_P to
push_struct_function. Call targetm.target_option.relayout_function
after it.
(tree_function_versioning): Formatting fix.
Jakub Jelinek [Fri, 17 Mar 2023 15:10:14 +0000 (16:10 +0100)]
c, ubsan: Instrument even shortened divisions [PR109151]
On the following testcase, the C FE decides to shorten the division because
it has a guarantee that INT_MIN / -1 division won't be encountered, the
first operand is widened from narrower unsigned and/or the second operand is
a constant other than all ones (in this case both are true).
The problem is that the narrower type in this case is _Bool and
ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE
or REAL_TYPE. Strangely this doesn't happen in C++ FE.
Anyway, we only shorten divisions if the INT_MIN / -1 case is impossible,
so I think we should be fine even with -fstrict-enums in C++ in case it
shortened to ENUMERAL_TYPEs.
The following patch just instruments those on the ubsan_instrument_division
side. Perhaps only the first hunk and testcase might be needed because
we shouldn't shorten if the other case could be triggered.
2023-03-17 Jakub Jelinek <jakub@redhat.com>
PR c/109151
* c-ubsan.cc (ubsan_instrument_division): Handle all scalar integral
types rather than just INTEGER_TYPE.
Jakub Jelinek [Fri, 17 Mar 2023 07:46:28 +0000 (08:46 +0100)]
openmp: Fix up handling of doacross loops with noreturn body in loops [PR108685]
The following patch fixes an ICE with doacross loops which have a single entry
no exit body, at least one of the ordered > collapse loops isn't guaranteed to
have at least one iteration and the whole doacross loop is inside some other loop.
The OpenMP constructs aren't represented by struct loop until the omp expansions,
so for a normal doacross loop which doesn't have a noreturn body the entry_bb
with the GOMP_FOR statement and the first bb of the body typically have the
same loop_father, and if the doacross loop isn't inside of some other loop
and the body is noreturn as well, both are part of loop 0. The problematic
case is when the entry_bb is inside of some deeper loop, but the body, because
it falls through into EXIT, has loop 0 as loop_father. l0_bb is created by
splitting the entry_bb fallthru edge into l1_bb, and because the two basic blocks
have different loop_father, a common loop is found for those (which is loop 0).
Now, if the doacross loop has collapse == ordered or all the ordered > collapse
loops are guaranteed to iterate at least once, all is still fine, because all
enter the l1_bb (body), which doesn't return and so doesn't loop further either.
But, if one of those loops could loop 0 times, the user written body wouldn't be
reached at all, so unlike the expectations the whole construct actually wouldn't
be noreturn if entry_bb is encountered and decides to handle at least one
iteration.
In this case, we need to fix up, move the l0_bb into the same loop as entry_bb
(initially) and for the extra added loops put them as children of that same
loop, rather than of loop 0.
2023-03-17 Jakub Jelinek <jakub@redhat.com>
PR middle-end/108685
* omp-expand.cc (expand_omp_for_ordered_loops): Add L0_BB argument,
use its loop_father rather than BODY_BB's loop_father.
(expand_omp_for_generic): Adjust expand_omp_for_ordered_loops caller.
If broken_loop with ordered > collapse and at least one of those
extra loops aren't guaranteed to have at least one iteration, change
l0_bb's loop_father to entry_bb's loop_father. Set cont_bb's
loop_father to l0_bb's loop_father rather than l1_bb's.
Jakub Jelinek [Tue, 14 Mar 2023 15:17:32 +0000 (16:17 +0100)]
c++: Treat unnamed bitfields as padding for __has_unique_object_representations [PR109096]
As reported in the PR, for __has_unique_object_representations we
were treating unnamed bitfields as named ones, which is wrong, they
are actually padding.
Jakub Jelinek [Fri, 10 Mar 2023 19:38:13 +0000 (20:38 +0100)]
c++: Don't clear TREE_READONLY for -fmerge-all-constants for non-aggregates [PR107558]
The following testcase ICEs, because OpenMP lowering for shared clause
on l variable with REFERENCE_TYPE creates POINTER_TYPE to REFERENCE_TYPE.
The reason is that the automatic variable has non-trivial construction
(reference to a lambda) and -fmerge-all-constants is on and so TREE_READONLY
isn't set - omp-low will handle automatic TREE_READONLY vars in shared
specially and only copy to the construct and not back, while !TREE_READONLY
are assumed to be changeable.
The PR91529 change rationale was that the gimplification can change
some non-addressable automatic variables to TREE_STATIC with
-fmerge-all-constants and therefore TREE_READONLY on them is undesirable.
But, the gimplifier does that only for aggregate variables:
switch (TREE_CODE (type))
{
case RECORD_TYPE:
case UNION_TYPE:
case QUAL_UNION_TYPE:
case ARRAY_TYPE:
and not for anything else. So, I think clearing TREE_READONLY for
automatic integral or reference or pointer etc. vars for
-fmerge-all-constants only is unnecessary.
2023-03-10 Jakub Jelinek <jakub@redhat.com>
PR c++/107558
* decl.cc (cp_finish_decl): Don't clear TREE_READONLY on
automatic non-aggregate variables just because of
-fmerge-all-constants.
Jakub Jelinek [Fri, 10 Mar 2023 19:36:33 +0000 (20:36 +0100)]
c++, abi: Fix up class layout with bitfields [PR109039]
The following testcase FAILs, because starting with r12-6028
the S class has only 2 bytes, not enough to hold one 7-bit bitfield, one 8-bit
bitfield and one 8-bit char field.
The reason is that when end_of_class attempts to compute dsize, it simply
adds byte_position of the field and DECL_SIZE_UNIT (and uses maximum from
those offsets).
The problematic bit-field in question has bit_position 7, byte_position 0,
DECL_SIZE 8 and DECL_SIZE_UNIT 1. So, byte_position + DECL_SIZE_UNIT is
1, even when the bitfield only has a single bit in the first byte and 7
further bits in the second byte, so per the Itanium ABI it should be 2:
"In either case, update dsize(C) to include the last byte
containing (part of) the bit-field, and update sizeof(C) to
max(sizeof(C),dsize(C))."
The following patch fixes it by computing bitsize of the end and using
CEIL_DIV_EXPR division to round it to next byte boundary and convert
from bits to bytes.
While this is an ABI change, classes with such incorrect layout couldn't
have worked properly, so I doubt anybody is actually running it often
in the wild. Thus I think adding some ABI warning for it is unnecessary.
2023-03-10 Jakub Jelinek <jakub@redhat.com>
PR c++/109039
* class.cc (end_of_class): For bit-fields, instead of computing
offset as sum of byte_position (field) and DECL_SIZE_UNIT (field),
compute it as sum of bit_position (field) and DECL_SIZE (field)
divided by BITS_PER_UNIT rounded up.
Jakub Jelinek [Sat, 4 Mar 2023 09:21:45 +0000 (10:21 +0100)]
c-family: Incremental fix for -Wsign-compare BIT_NOT_EXPR handling [PR107465]
There can be too many extensions and seems I didn't get everything right in
the previously posted patch.
The following incremental patch ought to fix that.
The code can deal with quite a few sign/zero extensions at various spots
and it is important to deal with all of them right.
On the argument that contains BIT_NOT_EXPR we have:
MSB bits#4 bits#3 BIT_NOT_EXPR bits#2 bits#1 LSB
where bits#1 is one or more bits (TYPE_PRECISION (TREE_TYPE (arg0))
at the end of the function) we don't know anything about, for the purposes
of this warning it is VARYING that is inverted with BIT_NOT_EXPR to some other
VARYING bits;
bits#2 is one or more bits (TYPE_PRECISION (TREE_TYPE (op0)) -
TYPE_PRECISION (TREE_TYPE (arg0)) at the end of the function)
which are known to be 0 before the BIT_NOT_EXPR and 1 after it.
bits#3 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0))
at the end of function to the TYPE_PRECISION (TREE_TYPE (op0)) at the
end of the function to TYPE_PRECISION (TREE_TYPE (op0)) at the start
of the function, which are either zero extension or sign extension.
And bits#4 is zero or more bits from the TYPE_PRECISION (TREE_TYPE (op0))
at the start of the function to TYPE_PRECISION (result_type), which
again can be zero or sign extension.
Now, vanilla trunk as well as the previously posted patch mishandles the
case where bits#3 are sign extended (as bits#2 are known to be all set,
that means bits#3 are all set too) but bits#4 are zero extended and are
thus all 0.
The patch fixes it by tracking the lowest bit which is known to be clear
above the known to be set bits (if any, otherwise it is precision of
result_type).
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR c/107465
* c-warn.cc (warn_for_sign_compare): Don't warn for unset bits
above innermost zero extension of BIT_NOT_EXPR result.
Jakub Jelinek [Sat, 4 Mar 2023 09:18:37 +0000 (10:18 +0100)]
c-family: Fix up -Wsign-compare BIT_NOT_EXPR handling [PR107465]
The following patch fixes multiple bugs in warn_for_sign_compare related to
the BIT_NOT_EXPR related warnings.
My understanding is that what those 3 warnings are meant to warn (since 1995
apparently) is the case where we have BIT_NOT_EXPR of a zero-extended
value, so in result_type the value is something like:
0b11111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension)
0b000000000000000011111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension
then zero extended to 32 bits)
0b111111111111111111111111XXXXXXXX (e.g. ~ of a 8->16 bit zero extension
then sign extended to 32 bits)
and the intention of the warning is to warn when this is compared against
something that has some 0 bits at the place where the above has guaranteed
1 bits, either ensured through comparison against constant where we know
the bits exactly, or through zero extension from some narrower type where
again we know at least some upper bits are zero extended.
The bugs in the warning code are:
1) misunderstanding of the {,c_common_}get_narrower APIs - the unsignedp
it sets is only meaningful if the function actually returns something
narrower (in that case it says whether the narrower value is then
sign (0) or zero (1) extended to the originally passed value.
Though op0 or op1 at this point might be already narrower than
result_type, and if the function doesn't return anything narrower,
it all depends on whether the passed in op{0,1} had TYPE_UNSIGNED
type or not
2) the code didn't check at all whether the BIT_NOT_EXPR operand
was actually zero extended (i.e. that it was narrower and unsignedp
was set to 1 for it), all it did is check that unsignedp from the
call was 1. But that isn't well defined thing, if the argument
is returned as is, the function sets unsignedp to 0, but if there
is e.g. a useless cast to the same or compatible type in between,
it can return 1 if the cast is unsigned; now, if BIT_NOT_EXPR
operand is not zero extended, we know nothing at all about any bits
in the operand containing BIT_NOT_EXPR, so there is nothing to warn
about
3) the code was actually testing both operands after calling
c_common_get_narrower on them and on the one with BIT_NOT_EXPR
again for constants; I think that is just wrong in case the BIT_NOT_EXPR
operand wouldn't be fully folded, the warning makes sense only if the
other operand not having BIT_NOT_EXPR in it is constant
4) as can be seen from the above bit pattern examples, the upper bits above
(in the patch arg0) aren't always all 1s, there could be some zero extension
above it and from it one would have 0s, so that needs to be taken into
account for the choice which constant bits to test for being always set
otherwise warning is emitted, or for the zero extension guaranteed zero
bits
5) the patch also simplifies the handling, we only do it if one but not
both operands are BIT_NOT_EXPR after first {,c_common_}get_narrower,
so we can just use std::swap to ensure it is the first one
6) the code compared bits against HOST_BITS_PER_LONG, which made sense
back in 1995 when the values were stored into long, but now that they
are HOST_WIDE_INT should test HOST_BITS_PER_WIDE_INT (or we could rewrite
the stuff to wide_int, not done in the patch)
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR c/107465
* c-warn.cc (warn_for_sign_compare): If c_common_get_narrower
doesn't return a narrower result, use TYPE_UNSIGNED to set unsignedp0
and unsignedp1. For the one BIT_NOT_EXPR case vs. one without,
only check for constant in the non-BIT_NOT_EXPR operand, use std::swap
to simplify the code, only warn if BIT_NOT_EXPR operand is extended
from narrower unsigned, fix up computation of mask for the constant
cases and for unsigned other operand case handle differently
BIT_NOT_EXPR result being sign vs. zero extended.
* c-c++-common/Wsign-compare-2.c: New test.
* c-c++-common/pr107465.c: New test.
Jakub Jelinek [Sat, 4 Mar 2023 08:48:17 +0000 (09:48 +0100)]
diagnostics: Fix up selftests with $COLUMNS < 42 [PR108973]
As mentioned in the PR, GCC's diagnostics self-tests fail if $COLUMNS < 42.
Guarding each self-test with if (get_terminal_width () > 41) or similar
would be a maintainance nightmare (PR has a patch to do so without
reformatting to make it work for $COLUMNS in [30, 41] inclusive, but
I'm afraid going down to $COLUMNS 1 would mean marking everything).
Furthermore, the self-tests don't really emit stuff to the terminal,
but into a buffer, so using get_terminal_width () for it seems
inappropriate. The following patch makes sure test_diagnostic_context
constructor uses exactly 80 columns wide caret max width, of course
some tests override it already if they want to test for behavior in narrower
cases.
2023-03-04 Jakub Jelinek <jakub@redhat.com>
PR testsuite/108973
* selftest-diagnostic.cc
(test_diagnostic_context::test_diagnostic_context): Set
caret_max_width to 80.
Jakub Jelinek [Fri, 3 Mar 2023 15:11:11 +0000 (16:11 +0100)]
waccess: Fix two -Wnonnull warning issues [PR108986]
The following patch fixes 2 issues with the -Wnonnull warning.
One, fixed by the second hunk, is that the warning wording is bogus
since r11-3305, instead of printing
warning: argument 1 to ‘int[static 7]’ is null where non-null expected [-Wnonnull]
it prints
warning: argument 1 to ‘int[static 28]’ is null where non-null expected [-Wnonnull]
access_size is measured in bytes, so obviously will be correct as array
number of elements only if it is 1 byte element array.
In the function, access_nelts is either constant (if sizidx == -1) or
when the array size is determined by some other parameter, I believe a value
passed to that argument.
Later on we query the range of it:
if (get_size_range (m_ptr_qry.rvals, access_nelts, stmt, sizrng, 1))
which I bet must just return accesS_nelts in sizrng[0] and [1] if it is
constant. access_size is later computed as:
tree access_size = NULL_TREE;
if (tree_int_cst_sgn (sizrng[0]) >= 0)
{
if (COMPLETE_TYPE_P (argtype))
{
...
wide_int minsize = wi::to_wide (sizrng[0], prec);
minsize *= wi::to_wide (argsize, prec);
access_size = wide_int_to_tree (sizetype, minsize);
}
}
else
access_size = access_nelts;
}
and immediately after this the code does:
if (integer_zerop (ptr))
{
if (sizidx >= 0 && tree_int_cst_sgn (sizrng[0]) > 0)
{
some other warning wording
}
else if (access_size && access.second.static_p)
{
this spot
}
}
So, because argtype is complete, access_size has been multiplied by
argsize, but in case of this exact warning ("this spot" above)
I believe access_nelts must be really constant, otherwise
"some other warning wording" would handle it. So, I think access_nelts
is exactly what we want to print there.
The other problem is that since the introduction of -Wdangling-pointer
in r12-6606, the pass has early and late instances and while lots of
stuff in the pass is guarded on being done in the late pass only,
this particular function is not, furthermore it is emitting two different
warnings in a loop and already messes up with stuff like clearing
warning suppression for one of the warning (ugh!). The end effect is
that we warn twice about the same problem, once in the early and once in
the late pass. Now, e.g. with -O2 -Wall we warn just once, during the
early pass, as it is then optimized away, so I think just making this
late warning only wouldn't be best. This patch instead returns early
if either of the warnings is suppressed on the call stmt already.
I think if one of the passes warned on it already (even if say on some other
argument), then warning again (even on some other argument) is unnecessary,
if both problems are visible in the same pass we'll still warn about both.
2023-03-03 Jakub Jelinek <jakub@redhat.com>
PR c/108986
* gimple-ssa-warn-access.cc (pass_waccess::maybe_check_access_sizes):
Return immediately if OPT_Wnonnull or OPT_Wstringop_overflow_ is
suppressed on stmt. For [static %E] warning, print access_nelts
rather than access_size. Fix up comment wording.
Jakub Jelinek [Thu, 2 Mar 2023 18:17:52 +0000 (19:17 +0100)]
c++, debug: Fix up locus of DW_TAG_imported_module [PR108716]
Before IMPORTED_DECL has been introduced in PR37410, we used to emit correct
DW_AT_decl_line on DW_TAG_imported_module on the testcase below, after that
change we haven't emitted it at all for a while and after some time
started emitting incorrect locus, in particular the location of } closing
the function.
The problem is that while we have correct EXPR_LOCATION on the USING_STMT,
when genericizing that USING_STMT into IMPORTED_DECL we don't copy the
location to DECL_SOURCE_LOCATION, so it gets whatever input_location happens
to be when it is created.
2023-03-02 Jakub Jelinek <jakub@redhat.com>
PR debug/108716
* cp-gimplify.cc (cp_genericize_r) <case USING_STMT>: Set
DECL_SOURCE_LOCATION on IMPORTED_DECL to expression location
of USING_STMT or input_location.
Jakub Jelinek [Thu, 2 Mar 2023 08:27:40 +0000 (09:27 +0100)]
fold-const: Ignore padding bits in native_interpret_expr REAL_CST reverse verification [PR108934]
In the following testcase we try to std::bit_cast a (pair of) integral
value(s) which has some non-zero bits in the place of x86 long double
(for 64-bit 16 byte type with 10 bytes actually loaded/stored by hw,
for 32-bit 12 byte) and starting with my PR104522 change we reject that
as native_interpret_expr fails on it. The PR104522 change extends what
has been done before for MODE_COMPOSITE_P (but those don't have any padding
bits) to all floating point types, because e.g. the exact x86 long double
has various bit combinations we don't support, like
pseudo-(denormals,infinities,NaNs) or unnormals. The HW handles some of
those as exceptional cases and others similarly to the non-pseudo ones.
But for the padding bits it actually doesn't load/store those bits at all,
it loads/stores 10 bytes. So, I think we should exempt the padding bits
from the reverse comparison (the native_encode_expr bits for the padding
will be all zeros), which the following patch does. For bit_cast it is
similar to e.g. ignoring padding bits if the destination is a structure
which has padding bits in there.
The change changed auto-init-4.c to how it has been behaving before the
PR105259 change, where some more VCEs can be now done.
2023-03-02 Jakub Jelinek <jakub@redhat.com>
PR c++/108934
* fold-const.cc (native_interpret_expr) <case REAL_CST>: Before memcmp
comparison copy the bytes from ptr to a temporary buffer and clearing
padding bits in there.
* gcc.target/i386/auto-init-4.c: Revert PR105259 change.
* g++.target/i386/pr108934.C: New test.
Jakub Jelinek [Wed, 1 Mar 2023 09:26:46 +0000 (10:26 +0100)]
cfgexpand: Handle WIDEN_{PLUS,MINUS}_EXPR and VEC_WIDEN_{PLUS,MINUS}_{HI,LO}_EXPR in expand_debug_expr [PR108967]
When these tree codes were introduced, expand_debug_expr hasn't been
updated to handle them. For the VEC_*_EXPR we currently mostly punt, the
non-vector ones can be handled easily. In release compilers this doesn't
ICE, but with checking we ICE so that we make sure to handle all the needed
tree codes there.
2023-03-01 Jakub Jelinek <jakub@redhat.com>
PR debug/108967
* cfgexpand.cc (expand_debug_expr): Handle WIDEN_{PLUS,MINUS}_EXPR
and VEC_WIDEN_{PLUS,MINUS}_{HI,LO}_EXPR.
Jakub Jelinek [Wed, 1 Mar 2023 08:54:52 +0000 (09:54 +0100)]
lto: Fix up lto_fixup_prevailing_type [PR108910]
Without LTO, TYPE_POINTER_TO/TYPE_REFERENCE_TO chains are only maintained
inside of build_{pointer,reference}_type_for_mode and those routines
ensure that the pointer/reference type added to the chain is really
without any user attributes (unless something would modify the types
in place, but that would be wrong).
Now, LTO adds stuff to these chains in lto_fixup_prevailing_type but
doesn't guarantee that. The testcase in the PR (which I'm not including
for testsuite because when (I hope) the aarch64 backend bug will be fixed,
the testcase would work either way) shows a case where user has
TYPE_USER_ALIGN type with very high alignment, as there aren't enough
pointers to float in the code left that one becomes the prevailing one
(because types with attributes are created with build_distinct_type_copy
and thus their own TYPE_MAIN_VARIANTs), lto_fixup_prevailing_type puts
it into the TYPE_POINTER_TO chain of float and later on during expansion
of __builtin_cexpif expander uses build_pointer_type (float_type_node)
to emit a sincosf call and instead of getting a normal pointer type gets
this non-standard one.
The following patch fixes that by not adding into those chains
types with TYPE_ATTRIBUTES, and for REFERENCE_TYPEs not even with
TYPE_REF_IS_RVALUE - while the C++ FE adds those into those chains,
it always ensures such a type goes immediately after the corresponding
non-TYPE_REF_IS_RVALUE REFERENCE_TYPE with the same
mode/TYPE_REF_CAN_ALIAS_ALL, so LTO would need to ensure that too, but
TYPE_REF_IS_RVALUE types are looked that way only in the C++ FE.
2023-03-01 Jakub Jelinek <jakub@redhat.com>
PR target/108910
* lto-common.cc (lto_fixup_prevailing_type): Don't add t to
TYPE_POINTER_TO or TYPE_REFERENCE_TO chain if it has
TYPE_ATTRIBUTES or is TYPE_REF_IS_RVALUE.
Jakub Jelinek [Fri, 24 Feb 2023 10:05:27 +0000 (11:05 +0100)]
cgraphclones: Don't share DECL_ARGUMENTS between thunk and its artificial thunk [PR108854]
The following testcase ICEs on x86_64-linux with -m32. The problem is
we create an artificial thunk and because of -fPIC, ia32 and thunk
destination which doesn't bind locally can't use a mi thunk.
The ICE is because during expansion to RTL we see SSA_NAME for a PARM_DECL,
but the PARM_DECL doesn't have DECL_CONTEXT of the current function.
This is because duplicate_thunk_for_node creates a new DECL_ARGUMENTS chain
only if some arguments need modification.
The following patch fixes it by copying the DECL_ARGUMENTS list even if
the arguments can stay as is, to update DECL_CONTEXT on them. While for
mi thunks it doesn't really matter because we don't use those arguments
in any way, for other thunks it is important.
2023-02-23 Jakub Jelinek <jakub@redhat.com>
PR middle-end/108854
* cgraphclones.cc (duplicate_thunk_for_node): If no parameter
changes are needed, copy at least DECL_ARGUMENTS PARM_DECL
nodes and adjust their DECL_CONTEXT.
Jakub Jelinek [Fri, 24 Feb 2023 09:12:44 +0000 (10:12 +0100)]
i386: Fix up builtins used in avx512bf16vlintrin.h [PR108881]
The builtins used in avx512bf16vlintrin.h implementation need both
avx512bf16 and avx512vl ISAs, which the header ensures for them, but
the builtins weren't actually requiring avx512vl, so when used by hand
with just -mavx512bf16 -mno-avx512vl it resulted in ICEs.
Fixed by adding OPTION_MASK_ISA_AVX512VL to their BDESC.
Jakub Jelinek [Sat, 18 Feb 2023 11:40:49 +0000 (12:40 +0100)]
reassoc: Fold some statements [PR108819]
This spot in update_ops can replace one or both of the assign operands with
constants, creating 1 & 1 and similar expressions which can confuse later
passes until they are folded. Rather than folding both constants by hand
and also handling swapping of operands for commutative ops if the first one
is constant and second one is not, the following patch just uses
fold_stmt_inplace to do that. I think we shouldn't fold more than the
single statement because that could screw up the rest of the pass, we'd have
to mark all those with uids, visited and the like.
2023-02-18 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/108819
* tree-ssa-reassoc.cc (update_ops): Fold new stmt in place.
Jakub Jelinek [Thu, 9 Feb 2023 16:43:19 +0000 (17:43 +0100)]
i386: Call get_available_features for all CPUs with max_level >= 1 [PR100758]
get_available_features doesn't depend on cpu_model2->__cpu_{family,model}
and just sets stuff up based on CPUID leaf 1, or some extended ones,
so I wonder why are we calling it separately for Intel, AMD and Zhaoxin
and not for all other CPUs too? I think various programs in the wild
which aren't using __builtin_cpu_{is,supports} just check the various CPUID
leafs and query bits in there, without blacklisting unknown CPU vendors,
so I think even __builtin_cpu_supports ("sse2") etc. should be reliable
if those VENDOR_{CENTAUR,CYRIX,NSC,OTHER} CPUs set those bits in CPUID leaf
1 or some extended ones. Calling it for all CPUs also means it can be
inlined because there will be just a single caller.
I have tested it on Intel and Martin tested it on AMD, but can't test it
on non-Intel/AMD; for Intel/AMD/Zhaoxin it should be really no change in
behavior.
2023-02-09 Jakub Jelinek <jakub@redhat.com>
PR target/100758
* common/config/i386/cpuinfo.h (cpu_indicator_init): Call
get_available_features for all CPUs with max_level >= 1, rather
than just Intel or AMD.
Iain Buclaw [Thu, 16 Mar 2023 00:07:02 +0000 (01:07 +0100)]
d: Fix closure fields don't get same alignment as local variable [PR109144]
Local variables with both non-local references and explicit alignment
did not propagate their alignment to either the closure field or closure
frame type, resulting in the closure being misaligned. This is now
correctly set-up when building the frame type.
PR d/109144
gcc/d/ChangeLog:
* d-codegen.cc (build_frame_type): Set frame field and type alignment.
Harald Anlauf [Sat, 11 Mar 2023 14:37:37 +0000 (15:37 +0100)]
Fortran: fix bounds check for copying of class expressions [PR106945]
In the bounds check for copying of class expressions, the number of elements
determined from a descriptor, returned as type gfc_array_index_type (i.e. a
signed type), should be converted to the type of the passed element count,
which is of type size_type_node (i.e. unsigned), for use in comparisons.
gcc/fortran/ChangeLog:
PR fortran/106945
* trans-expr.cc (gfc_copy_class_to_class): Convert element counts in
bounds check to common type for comparison.
gcc/testsuite/ChangeLog:
PR fortran/106945
* gfortran.dg/pr106945.f90: New test.
Marek Polacek [Wed, 8 Mar 2023 14:15:07 +0000 (09:15 -0500)]
ubsan: missed -fsanitize=bounds for compound ops [PR108060]
In this PR we are dealing with a missing .UBSAN_BOUNDS, so the
out-of-bounds access in the test makes the program crash before
a UBSan diagnostic was emitted. In C and C++, c_genericize gets
a[b] = a[b] | c;
but in C, both a[b] are one identical shared tree (not in C++ because
cp_fold/ARRAY_REF created two same but not identical trees). Since
ubsan_walk_array_refs_r keeps a pset, in C we produce
therefore we emit a runtime error before making the bad array access.
I think it's OK that only the RHS gets a .UBSAN_BOUNDS, as in few lines
above: the instrumented array access dominates the array access on the
LHS, and I've verified that
b = 0;
a[b] = (a[b], b = -32768, a[0] | c);
works as expected: the inner a[b] is OK but we do emit an error for the
a[b] on the LHS.
For GCC 14, we could apply
<https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613687.html>
since the copy_node doesn't seem to be needed.
PR sanitizer/108060
PR sanitizer/109050
gcc/c-family/ChangeLog:
* c-gimplify.cc (ubsan_walk_array_refs_r): For a MODIFY_EXPR, instrument
the RHS before the LHS.
gcc/testsuite/ChangeLog:
* c-c++-common/ubsan/bounds-17.c: New test.
* c-c++-common/ubsan/bounds-18.c: New test.
* c-c++-common/ubsan/bounds-19.c: New test.
* c-c++-common/ubsan/bounds-20.c: New test.
* c-c++-common/ubsan/bounds-21.c: New test.
Marek Polacek [Fri, 10 Mar 2023 15:14:20 +0000 (10:14 -0500)]
c++: ICE with constexpr lambda [PR107280]
We crash here since r10-3661, the store_init_value hunk in particular.
Before, we called cp_fully_fold_init, so e.g.
{.str=VIEW_CONVERT_EXPR<char[8]>("")}
was folded into
{.str=""}
but now we don't fold and keep the VCE around, and it causes trouble in
cxx_eval_store_expression: in the !refs->is_empty () loop we descend on
.str's initializer but since it's wrapped in a VCE, we skip the STRING_CST
check and then crash on the CONSTRUCTOR_NO_CLEARING.
When we end up with a widen-sum with an invariant smaller operand
the reduction code uses a wrong vector type for it, causing
IL checking ICEs. The following fixes that and the inefficiency
of using a widen-sum with a widenend invariant operand as well
by actually performing the check the following comment wants.
PR tree-optimization/108950
* tree-vect-patterns.cc (vect_recog_widen_sum_pattern):
Check oprnd0 is defined in the loop.
* tree-vect-loop.cc (vectorizable_reduction): Record all
operands vector types, compute that of invariants and
properly update their SLP nodes.
Richard Biener [Fri, 17 Feb 2023 11:36:44 +0000 (12:36 +0100)]
tree-optimization/108821 - store motion and volatiles
The following fixes store motion to not re-issue volatile stores
to preserve TBAA behavior since that will result in the number
of volatile accesses changing.
PR tree-optimization/108821
* tree-ssa-loop-im.cc (sm_seq_valid_bb): We can also not
move volatile accesses.
The split of the versioning condition assumes the definition is
in the condition block which is ensured by the versioning code.
But that only works when we actually have to insert any statements
for the versioning condition. The following adjusts the guard
accordingly and asserts this condition.
Richard Biener [Mon, 20 Feb 2023 11:58:50 +0000 (12:58 +0100)]
tree-optimization/108793 - niter compute type mismatch
When computing the number of iterations until wrap types are mixed up,
eventually leading to checking ICEs with a pointer bitwise inversion.
The following uses niter_type for the calculation.
PR tree-optimization/108793
* tree-ssa-loop-niter.cc (number_of_iterations_until_wrap):
Use convert operands to niter_type when computing num.
This fixes an oversight to when removing the hard limits on using
generic vectors for the vectorizer to enable both SLP and BB
vectorization to use those. The vectorizer relies on vector lowering
to expand plus, minus and negate to bit operations but vector
lowering has a hard limit on the minimum number of elements per
work item. Vectorizer costs for the testcase at hand work out
to vectorize a loop with just two work items per vector and that
causes element wise expansion and spilling.
The fix for now is to re-instantiate the hard limit, matching what
vector lowering does. For the future the way to go is to emit the
lowered sequence directly from the vectorizer instead.
PR tree-optimization/108724
* tree-vect-stmts.cc (vectorizable_operation): Avoid
using word_mode vectors when vector lowering will
decompose them to elementwise operations.
Richard Biener [Thu, 2 Feb 2023 10:09:26 +0000 (11:09 +0100)]
middle-end/108625 - wrong folding due to misinterpreted !
The following fixes a problem with ! handling in genmatch which isn't
conservative enough when intermediate simplifications push to the
sequence but the final operation appears to just pick an existing
(but in this case newly defined in the sequence) operand. The easiest
fix is to disallow adding to the sequence when processing !.
PR middle-end/108625
* genmatch.cc (expr::gen_transform): Also disallow resimplification
from pushing to lseq with force_leaf.
(dt_simplify::gen_1): Likewise.
The following replaces the recursive DFS traversal of the dominator
tree in assign_dfs_numbers with a tree traversal using the fact
that we have recorded parents.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
This makes r13-5325 somewhat obsolete, though not computing the
DFS numbers at all is beneficial in the cases where we perform
immediate CFG manipulations.
OK for trunk and later branch(es)?
Thanks,
Richard.
PR middle-end/108500
* dominance.cc (assign_dfs_numbers): Replace recursive DFS
with tree traversal algorithm.
When vectorizing SLP loads with permutations we can access excess
elements when the load vector type is bigger than the group size
and the vectorization factor covers less groups than necessary
to fill it. Since we know the code will only access up to
group_size * VF elements in the unpermuted vector we can simply
fill the rest of the vector with whatever we want. For simplicity
this patch chooses to repeat the last group.
PR tree-optimization/107451
* tree-vect-stmts.cc (vectorizable_load): Avoid loading
SLP group members from group numbers in excess of the
vectorization factor.
Richard Biener [Wed, 7 Dec 2022 13:42:24 +0000 (14:42 +0100)]
tree-optimization/106904 - bogus -Wstringopt-overflow with vectors
The following avoids CSE of &ps->wp to &ps->wp.hwnd confusing
-Wstringopt-overflow by making sure to produce addresses to the
biggest container from vectorization. For this I introduce
strip_zero_offset_components which turns &ps->wp.hwnd into
&(*ps) and use that to base the vector data references on.
That will also work for addresses with variable components,
alternatively emitting pointer arithmetic via calling
get_inner_reference and gimplifying that would be possible
but likely more intrusive.
This is by no means a complete fix for all of those issues
(avoiding ADDR_EXPRs in favor of pointer arithmetic might be).
Other passes will have similar issues.
In theory that might now cause false negatives.
PR tree-optimization/106904
* tree.h (strip_zero_offset_components): Declare.
* tree.cc (strip_zero_offset_components): Define.
* tree-vect-data-refs.cc (vect_create_addr_base_for_vector_ref):
Strip zero offset components before building the address.
* gcc.dg/Wstringop-overflow-pr106904.c: New testcase.
Iain Buclaw [Tue, 14 Mar 2023 12:16:11 +0000 (13:16 +0100)]
d: Fix undefined reference to lambda defined in private enum [PR109108]
Previously lambdas were connected to the module they were defined in.
Now they are emitted into every referencing compilation unit, and are
given one-only linkage.
PR d/109108
gcc/d/ChangeLog:
* decl.cc (function_defined_in_root_p): Remove.
(get_symbol_decl): Set DECL_LAMBDA_FUNCTION_P on function literals.
(start_function): Unconditionally unset DECL_EXTERNAL
(set_linkage_for_decl): Give lambda functions one-only linkage.
gcc/testsuite/ChangeLog:
* gdc.dg/torture/imports/pr109108.d: New test.
* gdc.dg/torture/pr109108.d: New test.
Jan Hubicka [Tue, 7 Feb 2023 04:23:00 +0000 (05:23 +0100)]
Enable 512 bit vector for zen4
While internally 512 registers are splits into two 256 halves, 512 bit vectors
reduces number of instructions to retire and has chance to improve paralelism.
There are few tsvc benchmarks that improves significantly:
And there are no benchmarks with off-noise regression. The basic matrix
multiplication loop improves by 32%. It is also expected that 512 bit
vectors are more power effecient (I can't masure that).
The down side is that loops with low trip counts may get slower when the
unvectorized prologue and epilogue is hit more often. With SPECfp this
problem happens with x264 (12% regression) and bwaves (6% regression)
and this is tracked in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410
and will need more work on vectorizer to support masked epilogues.
After some additional testing it seems that using 512 bit vectors by
default is now overall better choice.
Bootstrapped/regtested x86_64-linux. Plan to commit it tomorrow.
* config/i386/x86-tune.def (X86_TUNE_AVX256_OPTIMAL): Turn off
for znver4.
c++: top level bind when rewriting coroutines [PR106188]
In the edge case of a coroutine not containing any locals, the ifcd/switch
temporaries would get added to the coroutine frame, corrupting its
layout. To prevent this, we can make sure there is always a BIND_EXPR at
the top of the function body, and thus, always a place for our new
temporaries to go without interfering with the coroutine frame.
PR c++/106188 - Incorrect frame layout after transforming conditional statement without top-level bind expression
PR c++/106713 - if (co_await ...) crashes with a jump to ud2
PR c++/106188
PR c++/106713
gcc/cp/ChangeLog:
* coroutines.cc (coro_rewrite_function_body): Ensure we have a
BIND_EXPR wrapping the function body.
projects / thirdparty / gcc.git / log
