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.
Iain Buclaw [Mon, 13 Mar 2023 21:04:24 +0000 (22:04 +0100)]
d: Delay removing DECL_EXTERNAL from thunks until funcion has finished
Second part to fixing PR109108, don't blindly generate the associated
function definition of all referenced thunks in the compilation. Just
delay finishing a thunk until the function gets codegen itself. If the
function never gets a definition, then the thunk is left as "extern".
gcc/d/ChangeLog:
* decl.cc (finish_thunk): Unset DECL_EXTERNAL on thunk.
(make_thunk): Set DECL_EXTERNAL on thunk, don't call build_decl_tree.
(finish_function): Call finish_thunk on forward referenced thunks.
Iain Buclaw [Sun, 12 Mar 2023 20:43:31 +0000 (21:43 +0100)]
d: Refactor DECL_ARGUMENT and DECL_RESULT generation to own function
When looking into PR109108, the reason why things go awry is because
of the logic around functions with thunks - they have their definitions
generated even when they are external. This subsequently then relied on
the detection of whether a function receiving codegen really is extern
or not, and this check ultimately prunes too much.
This is a first step to both removing the call to `build_decl_tree' from
`make_thunk' and the pruning of symbols within the `build_decl_tree'
visitor method for functions. Move the generation of DECL_ARGUMENT and
DECL_RESULT out of `build_decl_tree' and into their own functions.
gcc/d/ChangeLog:
* decl.cc (get_fndecl_result): New function.
(get_fndecl_arguments): New function.
(DeclVisitor::visit (FuncDeclaration *)): Adjust to call
get_fndecl_arguments.
(make_thunk): Adjust to call get_fndecl_arguments and
get_fndecl_result.
(start_function): Adjust to call get_fndecl_result.
Mikael Morin [Sat, 25 Feb 2023 20:37:46 +0000 (21:37 +0100)]
fortran: Reuse associated_dummy memory if previously allocated [PR108923]
This avoids making the associted_dummy field point to a new memory chunk
if it's already pointing somewhere, in which case doing so would leak the
previously allocated chunk.
PR fortran/108923
gcc/fortran/ChangeLog:
* intrinsic.cc (get_intrinsic_dummy_arg,
set_intrinsic_dummy_arg): Rename the former to the latter.
Remove the return value, add a reference to the lhs as argument,
and do the pointer assignment inside the function. Don't do
it if the pointer is already non-NULL.
(sort_actual): Update caller.
Mikael Morin [Fri, 24 Feb 2023 21:11:17 +0000 (22:11 +0100)]
fortran: Plug leak of associated_dummy memory. [PR108923]
This fixes a memory leak by accompanying the release of
gfc_actual_arglist elements' memory with a release of the
associated_dummy field memory (if allocated).
Actual argument copy is adjusted as well so that each copy can free
its field independently.
PR fortran/108923
gcc/fortran/ChangeLog:
* expr.cc (gfc_free_actual_arglist): Free associated_dummy
memory.
(gfc_copy_actual_arglist): Make a copy of the associated_dummy
field if it is set in the original element.
Andrew Pinski [Wed, 2 Nov 2022 15:56:31 +0000 (15:56 +0000)]
Fix PR 105532: match.pd patterns calling tree_nonzero_bits with vector types
Even though this PR was reported with an ubsan issue, the problem is
tree_nonzero_bits is being called with an expression which is a vector type.
This fixes three patterns I noticed which does that.
And adds a testcase for one of the patterns.
Committed after a bootstrapped and tested on x86_64-linux-gnu with no regressions
gcc/ChangeLog:
PR tree-optimization/105532
* match.pd (~(X >> Y) -> ~X >> Y): Check if it is an integral
type before calling tree_nonzero_bits.
(popcount(X) + popcount(Y)): Likewise.
(popcount(X&C1)): Likewise.
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/vector-shift-1.c: New test.
Andrew Pinski [Tue, 7 Feb 2023 23:09:40 +0000 (23:09 +0000)]
tree-optimization: [PR108684] ICE in verify_ssa due to simple_dce_from_worklist
In simple_dce_from_worklist, we were removing an inline-asm which had a vdef.
We should not be removing inline-asm which have a vdef as this code
does not check to the store.
This fixes that oversight. This was a latent bug exposed recently
by both VRP and removal of stores to static starting to use
simple_dce_from_worklist.
Backported after bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/108684
gcc/ChangeLog:
* tree-ssa-dce.cc (simple_dce_from_worklist):
Check all ssa names and not just non-vdef ones
before accepting the inline-asm.
Call unlink_stmt_vdef on the statement before
removing it.
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/dce-inline-asm-1.c: New test.
* gcc.c-torture/compile/dce-inline-asm-2.c: New test.
* gcc.dg/tree-ssa/pr108684-1.c: New test.
Tobias Burnus [Wed, 1 Mar 2023 12:53:09 +0000 (13:53 +0100)]
OpenMP/Fortran: Fix handling of optional is_device_ptr + bind(C) [PR108546]
For is_device_ptr, optional checks should only be done before calling
libgomp, afterwards they are NULL either because of absent or, by
chance, because it is unallocated or unassociated (for pointers/allocatables).
Additionally, it fixes an issue with explicit mapping for 'type(c_ptr)'.
PR middle-end/108546
gcc/fortran/ChangeLog:
* trans-openmp.cc (gfc_trans_omp_clauses): Fix mapping of
type(C_ptr) variables.
gcc/ChangeLog:
* omp-low.cc (lower_omp_target): Remove optional handling
on the receiver side, i.e. inside target (data), for
use_device_ptr.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/is_device_ptr-3.f90: New test.
* testsuite/libgomp.fortran/use_device_ptr-optional-4.f90: New test.
Marek Polacek [Wed, 8 Feb 2023 19:02:48 +0000 (14:02 -0500)]
c++: ICE initing lifetime-extended constexpr var [PR107079]
We ICE on the simple:
struct X { const X* x = this; };
constexpr const X& x = X{};
where store_init_value initializes 'x' with
&TARGET_EXPR <D.2768, {.x=(const struct X *) &<PLACEHOLDER_EXPR struct X>}>
but we must lifetime-extend via extend_ref_init_temps and we get
_ZGR1x_.x = (const struct X *) &<PLACEHOLDER_EXPR struct X> >>>;, (const struct X &) &_ZGR1x_;
Since 'x' was declared constexpr, we do cxx_constant_init and we hit
the preeval code added in r269003 while evaluating the INIT_EXPR:
_ZGR1x_.x = (const struct X *) &<PLACEHOLDER_EXPR struct X> >>>
but we have no ctx.ctor or ctx.object here so lookup_placeholder won't
find anything that could replace X and we ICE on
7861 /* A placeholder without a referent. We can get here when
7862 checking whether NSDMIs are noexcept, or in massage_init_elt;
7863 just say it's non-constant for now. */
7864 gcc_assert (ctx->quiet);
because cxx_constant_init means !ctx->quiet. It's not correct that
there isn't a referent. I think the following patch is a pretty
straightforward fix: pass the _ZGR var down to maybe_constant_init so
that it can replace the PLACEHOLDER_EXPR with _ZGR1x_.
The commented assert in the test doesn't pass: we complain that _ZGR1x_
isn't a constexpr variable because we don't implement DR2126 (PR101588).
PR c++/107079
gcc/cp/ChangeLog:
* call.cc (set_up_extended_ref_temp): Pass var to maybe_constant_init.
Marek Polacek [Fri, 3 Mar 2023 16:24:24 +0000 (11:24 -0500)]
c++: error with constexpr operator() [PR107939]
Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl
can call check_initializer even in a template for a constexpr initializer.
Here we are rejecting
extern const Q q;
template<int>
constexpr auto p = q(0);
even though q has a constexpr operator(). It's deemed non-const by
decl_maybe_constant_var_p because even though 'q' is const it is not
of integral/enum type.
If fun is not a function pointer, we don't know if we're using it as an
lvalue or rvalue, so with this patch we pass 'any' for want_rval. With
that, p_c_e/VAR_DECL doesn't flat out reject the underlying VAR_DECL.
PR c++/107939
gcc/cp/ChangeLog:
* constexpr.cc (potential_constant_expression_1) <case CALL_EXPR>: Pass
'any' when recursing on a VAR_DECL and not a pointer to function.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/var-templ74.C: Remove dg-error.
* g++.dg/cpp1y/var-templ77.C: New test.
Patrick Palka [Fri, 3 Mar 2023 16:37:02 +0000 (11:37 -0500)]
c++: thinko in extract_local_specs [PR108998]
In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appears in one (we process
each local specialization once even if it appears multiple times in the
pattern).
But there's a thinko in the patch, namely that we don't actually walk
the pattern twice since we don't clear the visited set for the second
walk (to avoid processing a local specialization twice) and so the root
node (and any node leading up to an unevaluated operand) is considered
visited already. So the patch effectively made extract_local_specs
ignore unevaluated operands altogether, which this testcase demonstrates
isn't quite safe (extract_local_specs never sees 'aa' and we don't record
its local specialization, so later we try to specialize 'aa' on the spot
with the args {{int},{17}} which causes us to nonsensically substitute
its auto with 17.)
This patch fixes this by refining the second walk to start from the
trees we skipped over during the first walk.
PR c++/108998
gcc/cp/ChangeLog:
* pt.cc (el_data::skipped_trees): New data member.
(extract_locals_r): Push to skipped_trees any unevaluated
contexts that we skipped over.
(extract_local_specs): For the second walk, start from each
tree in skipped_trees.
Patrick Palka [Fri, 23 Dec 2022 16:17:45 +0000 (11:17 -0500)]
c++: get_nsdmi in template context [PR108116]
Here during ahead of time checking of C{}, we indirectly call get_nsdmi
for C::m from finish_compound_literal, which in turn calls
break_out_target_exprs for C::m's (non-templated) initializer, during
which we build a call to A::~A and check expr_noexcept_p for it (from
build_vec_delete_1). But this is all done with processing_template_decl
set, so the built A::~A call is templated (whose form was recently
changed by r12-6897-gdec8d0e5fa00ceb2) which expr_noexcept_p doesn't
expect, and we crash.
This patch fixes this by clearing processing_template_decl before
the call to break_out_target_exprs from get_nsdmi. And since it more
generally seems we shouldn't be seeing (or producing) non-templated
trees in break_out_target_exprs, this patch also adds an assert to
that effect.
PR c++/108116
gcc/cp/ChangeLog:
* constexpr.cc (maybe_constant_value): Clear
processing_template_decl before calling break_out_target_exprs.
* init.cc (get_nsdmi): Likewise.
* tree.cc (break_out_target_exprs): Assert processing_template_decl
is cleared.
Patrick Palka [Fri, 23 Dec 2022 14:18:37 +0000 (09:18 -0500)]
c++: template friend with variadic constraints [PR107853]
When instantiating a constrained hidden template friend, we substitute
into its template-head requirements in tsubst_friend_function. For this
substitution we use the template's full argument vector whose outer
levels correspond to the instantiated class's arguments and innermost
level corresponds to the template's own level-lowered generic arguments.
But for A<int>::f here, for which the relevant argument vector is
{{int}, {Us...}}, the substitution into (C<Ts, Us> && ...) triggers the
assert in use_pack_expansion_extra_args_p since one argument is a pack
expansion and the other isn't.
And for A<int, int>::f, for which the relevant argument vector is
{{int, int}, {Us...}}, the use_pack_expansion_extra_args_p assert would
also trigger but we first get a bogus "mismatched argument pack lengths"
error from tsubst_pack_expansion.
Sidestepping the question of whether tsubst_pack_expansion should be
able to handle such substitutions, it seems we can work around this by
using only the instantiated class's arguments and not also the template
friend's own generic arguments, which is consistent with how we normally
substitute into the signature of a member template.
PR c++/107853
gcc/cp/ChangeLog:
* constraint.cc (maybe_substitute_reqs_for): Substitute into
the template-head requirements of a template friend using only
its outer arguments via outer_template_args.
* cp-tree.h (outer_template_args): Declare.
* pt.cc (outer_template_args): Define, factored out and
generalized from ...
(ctor_deduction_guides_for): ... here.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-friend12.C: New test.
* g++.dg/cpp2a/concepts-friend13.C: New test.
Patrick Palka [Tue, 29 Nov 2022 14:55:21 +0000 (09:55 -0500)]
c++: explicit specialization and trailing requirements [PR107864]
Here we're crashing when using the explicit specialization of the
function template g with trailing requirements ultimately because
earlier decls_match (called indirectly from register_specialization) for
for the explicit specialization returned false since the template has
trailing requirements whereas the specialization doesn't.
In r12-2230-gddd25bd1a7c8f4, we fixed a similar issue concerning template
requirements instead of trailing requirements. We could extend that fix
to ignore trailing requirement mismatches for explicit specializations
as well, but it seems cleaner to just propagate constraints from the
specialized template to the specialization when declaring an explicit
specialization so that decls_match will naturally return true in this
case. And it looks like determine_specialization already does this,
albeit inconsistently (only when specializing a non-template member
function of a class template as in cpp2a/concepts-explicit-spec4.C).
So this patch makes determine_specialization consistently propagate
constraints from the specialized template to the specialization, which
in turn lets us get rid of the function_requirements_equivalent_p special
case added by r12-2230.
PR c++/107864
gcc/cp/ChangeLog:
* decl.cc (function_requirements_equivalent_p): Don't check
DECL_TEMPLATE_SPECIALIZATION.
* pt.cc (determine_specialization): Propagate constraints when
specializing a function template too. Simplify by using
add_outermost_template_args.
Patrick Palka [Thu, 3 Nov 2022 19:35:18 +0000 (15:35 -0400)]
c++: requires-expr and access checking [PR107179]
Like during satisfaction, we also need to avoid deferring access checks
during substitution of a requires-expr because the outcome of an access
check can determine the value of the requires-expr. Otherwise (in
deferred access checking contexts such as within a base-clause), the
requires-expr may evaluate to the wrong result, and along the way a
failed access check may leak out from it into a non-SFINAE context and
cause a hard error (as in the below testcase).
PR c++/107179
gcc/cp/ChangeLog:
* constraint.cc (tsubst_requires_expr): Make sure we're not
deferring access checks.
Xi Ruoyao [Thu, 2 Mar 2023 10:05:23 +0000 (18:05 +0800)]
LoongArch: Stop -mfpu from silently breaking ABI [PR109000]
In the toolchain convention, we describe -mfpu= as:
"Selects the allowed set of basic floating-point instructions and
registers. This option should not change the FP calling convention
unless it's necessary."
Though not explicitly stated, the rationale of this rule is to allow
combinations like "-mabi=lp64s -mfpu=64". This will be useful for
running applications with LP64S/F ABI on a double-float-capable
LoongArch hardware and using a math library with LP64S/F ABI but native
double float HW instructions, for a better performance.
And now a case in Linux kernel has again proven the usefulness of this
kind of combination. The AMDGPU DCN kernel driver needs to perform some
floating-point operation, but the entire kernel uses LP64S ABI. So the
translation units of the AMDGPU DCN driver need to be compiled with
-mfpu=64 (the kernel lacks soft-FP routines in libgcc), but -mabi=lp64s
(or you can't link it with the other part of the kernel).
Unfortunately, currently GCC uses TARGET_{HARD,SOFT,DOUBLE}_FLOAT to
determine the floating calling convention. This causes "-mfpu=64"
silently allow using $fa* to pass parameters and return values EVEN IF
-mabi=lp64s is used. To make things worse, the generated object file
has SOFT-FLOAT set in the eflags field so the linker will happily link
it with other LP64S ABI object files, but obviously this will lead to
bad results at runtime. And for now all loongarch64 CPU models (-march
settings) implies -mfpu=64 on by default, so the issue makes a single
"-mabi=lp64s" option basically broken (fortunately most projects for eg
the Linux kernel have used -msoft-float which implies both -mabi=lp64s
and -mfpu=none as we've recommended in the toolchain convention doc).
The fix is simple: use TARGET_*_FLOAT_ABI instead.
I consider this a bug fix: the behavior difference from the toolchain
convention doc is a bug, and generating object files with SOFT-FLOAT
flag but parameters/return values passed through FPRs is definitely a
bug.
Bootstrapped and regtested on loongarch64-linux-gnu. Ok for trunk and
release/gcc-12 branch?
gcc/ChangeLog:
PR target/109000
* config/loongarch/loongarch.h (FP_RETURN): Use
TARGET_*_FLOAT_ABI instead of TARGET_*_FLOAT.
(UNITS_PER_FP_ARG): Likewise.
gcc/testsuite/ChangeLog:
PR target/109000
* gcc.target/loongarch/flt-abi-isa-1.c: New test.
* gcc.target/loongarch/flt-abi-isa-2.c: New test.
* gcc.target/loongarch/flt-abi-isa-3.c: New test.
* gcc.target/loongarch/flt-abi-isa-4.c: New test.
Harald Anlauf [Mon, 20 Feb 2023 20:28:09 +0000 (21:28 +0100)]
Fortran: improve checking of character length specification [PR96025]
gcc/fortran/ChangeLog:
PR fortran/96025
* parse.cc (check_function_result_typed): Improve type check of
specification expression for character length and return status.
(parse_spec): Use status from above.
* resolve.cc (resolve_fntype): Prevent use of invalid specification
expression for character length.
gcc/testsuite/ChangeLog:
PR fortran/96025
* gfortran.dg/pr96025.f90: New test.
Marek Polacek [Sat, 4 Mar 2023 18:14:01 +0000 (13:14 -0500)]
c++: variable template and targ deduction [PR108550]
In this test, we get a bogus error because we failed to deduce the auto in
constexpr auto is_pointer_v = is_pointer<Tp>::value;
to bool. Then ensure_literal_type_for_constexpr_object thinks the object
isn't literal and an error is reported.
This is another case of the interaction between tf_partial and 'auto',
where the auto was not reduced so the deduction failed. In more detail:
we have
Wrap1<int>()
in the code and we need to perform OR -> fn_type_unification. The targ
list is incomplete, so we do
tsubst_flags_t ecomplain = complain | tf_partial | tf_fndecl_type;
fntype = tsubst (TREE_TYPE (fn), explicit_targs, ecomplain, NULL_TREE);
where TREE_TYPE (fn) is struct integral_constant <T402> (void). Then
we substitute the return type, which results in tsubsting is_pointer_v<int>.
is_pointer_v is a variable template with a placeholder type:
template <class Tp>
constexpr auto is_pointer_v = is_pointer<Tp>::value;
so we find ourselves in lookup_and_finish_template_variable. tf_partial is
still set, so finish_template_variable -> instantiate_template -> tsubst
won't reduce the level of auto. But then we do mark_used which eventually
calls do_auto_deduction which clears tf_partial, because we want to replace
the auto now. But we hadn't reduced auto's level so this fails. And
since we're not in an immediate context, we emit a hard error.
I suppose that when we reach lookup_and_finish_template_variable it's
probably time to clear tf_partial. (I added an assert and our testsuite
doesn't have a test whereby we get to lookup_and_finish_template_variable
while tf_partial is still active.)
Marek Polacek [Wed, 22 Feb 2023 20:17:03 +0000 (15:17 -0500)]
c-family: avoid compile-time-hog in c_genericize [PR108880]
This fixes a compile-time hog with UBSan. This only happened in cc1 but
not cc1plus. The problem is ultimately that c_genericize_control_stmt/
STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited
nodes, so it kept on recursing for a long time. We should be able to
use the pset that c_genericize created. We just need to use walk_tree
instead of walk_tree_w_d so that the pset is explicit.
PR c/108880
gcc/c-family/ChangeLog:
* c-gimplify.cc (c_genericize_control_stmt) <case STATEMENT_LIST>: Pass
pset to walk_tree_1.
(c_genericize): Call walk_tree with an explicit pset.
Marek Polacek [Wed, 1 Mar 2023 19:28:46 +0000 (14:28 -0500)]
c++: ICE with -Wmismatched-tags and member template [PR106259]
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template<typename T> struct A { };
class A<int> a;
it works by adding A<T> to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add A<int>. At the end of c_parse_file we go through the table and
warn about the class-key mismatches. In this PR we crash though; we
have
template<typename T> struct A {
template<typename U> struct W { };
};
struct A<int>::W<int> w; // #1
where while parsing A and #1 we've stashed
A<T>
A<T>::W<U>
A<int>::W<int>
into class2loc. Then in class_decl_loc_t::diag_mismatched_tags TYPE
is A<int>::W<int>, and specialization_of gets us A<int>::W<U>, which
is not in class2loc, so we crash on gcc_assert (cdlguide). But it's
OK not to have found A<int>::W<U>, we should just look one "level" up,
that is, A<T>::W<U>.
It's important to handle class specializations, so e.g.
template<>
struct A<char> {
template<typename U>
class W { };
};
where W's class-key is different than in the primary template above,
so we should warn depending on whether we're looking into A<char>
or into a different instantiation.
PR c++/106259
gcc/cp/ChangeLog:
* parser.cc (class_decl_loc_t::diag_mismatched_tags): If the first
lookup of SPEC didn't find anything, try to look for
most_general_template.
where TYPE_PTRMEM_CLASS_TYPE (type) is going to crash since the type
is ptrdiff_type_node. We could just add a TYPE_PTRMEM_P check before
accessing TYPE_PTRMEM_CLASS_TYPE but I think it's nicer to explain why
we couldn't evaluate the expression.
PR c++/107574
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Emit an error when
a PTRMEM_CST cannot be evaluated.
Marek Polacek [Thu, 23 Feb 2023 22:54:47 +0000 (17:54 -0500)]
c++: ICE with constexpr variable template [PR107938]
Since r11-557, cp_finish_decl can call check_initializer even in
a template for a constexpr initializer. That ultimately leads to
convert_for_assignment and check_address_or_pointer_of_packed_member,
where we crash, because it doesn't expect that the CALL_EXPR is
a function object. Q has a constexpr operator(), but since we're
in a template, q(0) is a CALL_EXPR whose CALL_EXPR_FN is just
a VAR_DECL; it hasn't been converted to Q::operator<int>(&q, 0) yet.
I propose to robustify check_address_or_pointer_of_packed_member.
var-templ74.C has an XFAIL, subject to 107939.
I noticed that our -Waddress-of-packed-member tests weren't testing
member functions, added thus. (I was tempted to check
FUNCTION_POINTER_TYPE_P but that doesn't include METHOD_TYPE.)
This is a follow-up to commit a4c6bd0821099f6b8c0f64a96ffd9d01a025c413
introducing a runtime check for alignment for 16 byte atomic
compare-exchange, load, and store.
libatomic/ChangeLog:
* config/s390/cas_n.c: New file.
* config/s390/load_n.c: New file.
* config/s390/store_n.c: New file.
Martin Liska [Fri, 17 Feb 2023 14:11:02 +0000 (15:11 +0100)]
asan: adjust module name for global variables
As mentioned in the PR, when we use LTO, we wrongly use ltrans output
file name as a module name of a global variable. That leads to a
non-reproducible output.
After the suggested change, we emit context name of normal global
variables. And for artificial variables (like .Lubsan_data3), we use
aux_base_name (e.g. "./a.ltrans0.ltrans").
PR sanitizer/108834
gcc/ChangeLog:
* asan.cc (asan_add_global): Use proper TU name for normal
global variables (and aux_base_name for the artificial one).
gcc/testsuite/ChangeLog:
* c-c++-common/asan/global-overflow-1.c: Test line and column
info for a global variable.
git://gcc.gnu.org / gcc.git / log