This patch fixes the other half of the PR, where we were crashing on the
UNSIGNED widest_int modulo of 1 % -128 (where the -128 in UNSIGNED is
131072 bit 0xfffff...fffff80).
The patch actually has 2 independent parts.
The fix for the divmod buffer overflow is in the 2nd-5th and 7th-8th hunks of
the patch. abs (remainder) <= min (abs (dividend), abs (divisor)) and the
wide-int.h callers estimate the remainder size to be the same as the
quotient size, i.e. for UNSIGNED dividend with msb set quotient (same as
remainder) precision based estimation, for SIGNED or dividend with msb
clear estimate based on divident len (+ 1).
For quotient (if any), wi_pack is called as
quotient_len = wi_pack (quotient, b_quotient, m, dividend_prec);
where m is
m = dividend_blocks_needed;
while (m > 1 && b_dividend[m - 1] == 0)
m--;
and
dividend_blocks_needed = 2 * BLOCKS_NEEDED (dividend_prec);
where wi_pack stores to result (in_len + 1) / 2 limbs (or one more
if (in_len & 1) == 0 and in_len / 2 < BLOCKS_NEEDED (dividend_prec)).
In any case, that is never more than BLOCKS_NEEDED (dividend_prec) and
matches caller's estimations (then it is canonicalized and perhaps shrunk
that way).
The problematic case is the remainder, where wi_pack is called as
*remainder_len = wi_pack (remainder, b_remainder, n, dividend_prec);
The last argument is again based on the dividend precision like for
quotient, but n is instead:
n = divisor_blocks_needed;
while (n > 1 && b_divisor[n - 1] == 0)
n--;
so based on the divisor rather than dividend. Now, in the
wi::multiple_of_p (1, -128, UNSIGNED) widest_int precision case,
dividend_prec is very small, the dividend is 1 and while the official
precision is 131072 bits, dividend_len is 1 and
if (sgn == SIGNED || dividend_val[dividend_len - 1] >= 0)
dividend_prec = MIN ((dividend_len + 1) * HOST_BITS_PER_WIDE_INT,
dividend_prec);
shrinks the estimate to 128 bits in this case; but divisor_prec
is huge, because the divisor is negative UNSIGNED, so 131072 bits,
2048 limbs, 4096 half-limbs (so divisor_blocks_needed and n are 4096).
Now, wi_pack relies on the penultimate argument to be smaller or equal
to 2 * BLOCKS_NEEDED of the last argument and that is not the case here,
4096 is certainly larger than 2 * BLOCKS_NEEDED (128) aka 4 and so
wi_pack overflows the array.
Unfortunately looking around, this isn't the only overflow, already
in divmod_internal_2 we have an overflow, though there not overflowing
a buffer during writing, but during reading. When divmod_internal_2
is called with the last 2 arguments like m=1, n=4096 as in this case
(but generally any where m < n), it has a special case for n == 1 (which
won't be the problem, we never have m or n 0), then decides based on
msb of divisor whether there should be some shift canonicalization, then
performs a
for (j = m - n; j >= 0; j--)
main loop and finally initializes b_remainder:
if (s)
for (i = 0; i < n; i++)
b_remainder[i] = (b_dividend[i] >> s)
| (b_dividend[i+1] << (HOST_BITS_PER_HALF_WIDE_INT - s));
else
for (i = 0; i < n; i++)
b_remainder[i] = b_dividend[i];
In the usual case of m >= n, the main loop will iterate at least once,
b_dividend has m + 1 valid elements and the copying to b_remainder
is correct. But for the m < n unusual case, the main loop never iterates
and we want to copy the b_dividend right into b_remainder (possibly with
shifts). Except when it copies n elements, it copies garbage which isn't
there at all for the last n - m elements.
Because the decision whether the main loop should iterate at all or not
and the s computation should be based on the original n, the following
patch sets n to MIN (n, m) only after the main loop, such that we copy
to b_remainder at most what is initialized in b_dividend, and returns
that adjusted value to the caller which then passes it to wi_pack and
so satisfies again the requirement there, rather than trying to
do the n = MIN (n, m) before calling divmod_internal_2 or after it.
I believe the bug is mostly something I've only introduced myself in the
> 576 bit wide_int/widest_int support changes, before that there was
no attempt to decrease the precisions and so I think dividend_prec
and divisor_prec were pretty much always the same (or always?),
and even the copying of garbage wasn't the case because the only time
m or n was decreased from the same precision was if there were 0s in the
upper half-limbs.
The 1st and 6th hunks in the patch is just that while looking at the
code, I've noticed I computed wrong the sizes in the XALLOCAVEC case,
somehow the 4 * in the static arrays led me believe I need to make the
alloced buffers twice (in the multiplication) or 4 times (in the
division/modulo cases) larger than needed.
2023-11-30 Jakub Jelinek <jakub@redhat.com>
PR middle-end/112733
* wide-int.cc (wi::mul_internal): Don't allocate twice as much
space for u, v and r as needed.
(divmod_internal_2): Change return type from void to int, for n == 1
return 1, otherwise before writing b_dividend into b_remainder set
n to MIN (n, m) and at the end return it.
(wi::divmod_internal): Don't allocate 4 times as much space for
b_quotient, b_remainder, b_dividend and b_divisor. Set n to
result of divmod_internal_2.
(wide_int_cc_tests): Add test for unsigned widest_int
wi::multiple_of_p of 1 and -128.
Jakub Jelinek [Thu, 30 Nov 2023 08:09:21 +0000 (09:09 +0100)]
c++: Implement C++26 P2169R4 - Placeholder variables with no name [PR110349]
The following patch implements the C++26 P2169R4 paper.
As written in the PR, the patch expects that:
1) https://eel.is/c++draft/expr.prim.lambda.capture#2
"Ignoring appearances in initializers of init-captures, an identifier
or this shall not appear more than once in a lambda-capture."
is adjusted such that name-independent lambda captures with initializers
can violate this rule (but lambda captures which aren't name-independent
can't appear after name-independent ones)
2) https://eel.is/c++draft/class.mem#general-5
"A member shall not be declared twice in the member-specification,
except that"
having an exception that name-independent non-static data member
declarations can appear multiple times (but again, if there is
a member which isn't name-independent, it can't appear after
name-independent ones)
3) it assumes that any name-independent declarations which weren't
previously valid result in the _ lookups being ambiguous, not just
if there are 2 _ declarations in the same scope, in particular the
https://eel.is/c++draft/basic.scope#block-2 mentioned cases
4) it assumes that _ in static function/block scope structured bindings
is never name-independent like in namespace scope structured bindings;
it matches clang behavior and is consistent with e.g. static type _;
not being name-independent both at namespace scope and at function/block
scope
As you preferred in the PR, for local scope bindings, the ambiguous cases
use a TREE_LIST with the ambiguous cases which can often be directly fed
into print_candidates. For member_vec after sorting/deduping, I chose to use
instead OVERLOAD with a new flag but only internally inside of the
member_vec, get_class_binding_direct turns it into a TREE_LIST. There are
2 reasons for that, in order to keep the member_vec binary search fast, I
think it is better to keep OVL_NAME usable on all elements because having
to special case TREE_LIST would slow everything down, and the callers need
to be able to chain the results anyway and so need an unshared TREE_LIST
they can tweak/destroy anyway.
name-independent declarations (even in older standards) will not have
-Wunused{,-variable,-but-set-variable} or -Wshadow* warnings diagnosed, but
unlike e.g. the clang implementation, this patch does diagnose
-Wunused-parameter for parameters with _ names because they aren't
name-independent and one can just omit their name instead.
2023-11-30 Jakub Jelinek <jakub@redhat.com>
PR c++/110349
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_placeholder_variables=202306L for C++26.
gcc/cp/
* cp-tree.h: Implement C++26 P2169R4 - Placeholder variables with no
name.
(OVL_NAME_INDEPENDENT_DECL_P): Define.
(add_capture): Add unsigned * argument.
(name_independent_decl_p): New inline function.
* name-lookup.cc (class name_lookup): Make ambiguous and
add_value members public.
(name_independent_linear_search): New function.
(get_class_binding_direct): Handle member_vec_binary_search
returning OVL_NAME_INDEPENDENT_DECL_P OVERLOAD. Use
name_independent_linear_search rather than fields_linear_search
for linear lookup of _ name if !want_type.
(member_name_cmp): Sort name-independent declarations first.
(member_vec_dedup): Handle name-independent declarations.
(pop_local_binding): Handle binding->value being a TREE_LIST for
ambiguous name-independent declarations.
(supplement_binding): Handle name-independent declarations.
(update_binding): Likewise.
(check_local_shadow): Return tree rather than void, normally
NULL_TREE but old for name-independent declarations which used
to conflict with outer scope declaration. Don't emit -Wshadow*
warnings for name-independent declarations.
(pushdecl): Handle name-independent declarations.
* search.cc (lookup_field_r): Handle nval being a TREE_LIST.
* lambda.cc (build_capture_proxy): Adjust for ___.<number>
names of members.
(add_capture): Add NAME_INDEPENDENT_CNT argument. Use ___.<number>
name rather than ___ for second and following capture with
_ name.
(add_default_capture): Adjust add_capture caller.
* decl.cc (poplevel): Don't warn about name-independent declarations.
(duplicate_decls): If in C++26 a _ named declaration conflicts with
earlier declarations, emit explaining note why the new declaration
is not name-independent.
(reshape_init_class): If field is a TREE_LIST, emit an ambiguity
error with list of candidates rather than error about non-existing
non-static data member.
* parser.cc (cp_parser_lambda_introducer): Adjust add_capture callers.
Allow name-independent capture redeclarations.
(cp_parser_decomposition_declaration): Set decl_specs.storage_class
to sc_static for static structured bindings.
* pt.cc (tsubst_lambda_expr): Adjust add_capture caller.
gcc/testsuite/
* g++.dg/cpp26/name-independent-decl1.C: New test.
* g++.dg/cpp26/name-independent-decl2.C: New test.
* g++.dg/cpp26/name-independent-decl3.C: New test.
* g++.dg/cpp26/name-independent-decl4.C: New test.
* g++.dg/cpp26/name-independent-decl5.C: New test.
* g++.dg/cpp26/name-independent-decl6.C: New test.
* g++.dg/cpp26/feat-cxx26.C: Add __cpp_placeholder_variables test.
* config/i386/sse.md (sdot_prodv64qi): New expander.
(sseunpackmodelower): New mode attr.
(sdot_prod<mode>): Emulate sdot_prodv*qi with sodt_prov*hi
when TARGET_VNNIINT8 is not available.
gcc/testsuite/ChangeLog:
* gcc.target/i386/sdotprodint8_emulate.c: New test.
liuhongt [Tue, 28 Nov 2023 06:46:21 +0000 (14:46 +0800)]
Use vec_extact_lo instead of subreg in reduc_<code>_scal_m.
Loop vectorizer will use vec_perm to select lower part of a vector,
there could be some redundancy when using subreg in
reduc_<code>_scal_m, because rtl cse can't figure out vec_select lower
part is just subreg.
I'm trying to canonicalize vec_select to subreg like aarch64 did, but
there're so many regressions, some are easy to fix, some requires
middle-end adjustment.
So for simplicity, the patch use vec_select instead of subreg in
reduc_<code>_scal_m.
gcc/ChangeLog:
* config/i386/sse.md: (reduc_plus_scal_<mode>): Use
vec_extract_lo instead of subreg.
(reduc_<code>_scal_<mode>): Ditto.
(reduc_<code>_scal_<mode>): Ditto.
(reduc_<code>_scal_<mode>): Ditto.
(reduc_<code>_scal_<mode>): Ditto.
Alexandre Oliva [Thu, 30 Nov 2023 06:40:51 +0000 (03:40 -0300)]
c++: mark short-enums as packed
Unlike C, C++ doesn't mark enums shortened by -fshort-enums as packed.
This makes for undesirable warning differences between C and C++,
e.g. c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early*.c
triggers a warning about a type cast from a pointer to enum that, when
packed, might not be sufficiently aligned.
This change is not enough for that warning to trigger. The tree
expression generated by the C++ front-end is also a little too
complicated for us get to the base pointer. A separate patch takes
care of that.
for gcc/cp/ChangeLog
* decl.cc (finish_enum_value_list): Set TYPE_PACKED if
use_short_enum, and propagate it to variants.
Jason Merrill [Wed, 29 Nov 2023 23:08:23 +0000 (18:08 -0500)]
c++: remove LAMBDA_EXPR_MUTABLE_P
In review of the deducing 'this' patch it came up that LAMBDA_EXPR_MUTABLE_P
doesn't make sense for a lambda with an explicit object parameter. And it
was never necessary, so let's remove it.
gcc/cp/ChangeLog:
* cp-tree.h (LAMBDA_EXPR_MUTABLE_P): Remove.
* cp-tree.def: Remove documentation.
* lambda.cc (build_lambda_expr): Remove reference.
* parser.cc (cp_parser_lambda_declarator_opt): Likewise.
* pt.cc (tsubst_lambda_expr): Likewise.
* ptree.cc (cxx_print_lambda_node): Likewise.
* semantics.cc (capture_decltype): Get the object quals
from the object instead.
Tsukasa OI [Thu, 30 Nov 2023 02:37:54 +0000 (02:37 +0000)]
RISC-V: Fix 'E' extension version to test
Commit 006e90e1 ("RISC-V: Initial RV64E and LP64E support") caused a
regression (test failure) but this is caused by failing to track GCC
changes in that test case (not a true GCC bug).
This commit fixes the test case to track the latest GCC with 'E'
extension version 2.0 (ratified).
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-13.c: Fix 'E' extension version to test.
Juzhe-Zhong [Thu, 30 Nov 2023 02:36:30 +0000 (10:36 +0800)]
RISC-V: Support highpart overlap for floating-point widen instructions
This patch leverages the approach of vwcvt/vext.vf2 which has been approved.
Their approaches are totally the same.
Tested no regression and committed.
PR target/112431
gcc/ChangeLog:
* config/riscv/vector.md: Add widenning overlap.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr112431-10.c: New test.
* gcc.target/riscv/rvv/base/pr112431-11.c: New test.
* gcc.target/riscv/rvv/base/pr112431-12.c: New test.
* gcc.target/riscv/rvv/base/pr112431-13.c: New test.
* gcc.target/riscv/rvv/base/pr112431-14.c: New test.
* gcc.target/riscv/rvv/base/pr112431-15.c: New test.
* gcc.target/riscv/rvv/base/pr112431-7.c: New test.
* gcc.target/riscv/rvv/base/pr112431-8.c: New test.
* gcc.target/riscv/rvv/base/pr112431-9.c: New test.
Philipp Tomsich [Fri, 20 Oct 2023 20:13:40 +0000 (22:13 +0200)]
aarch64: Add support for Ampere-1B (-mcpu=ampere1b) CPU
This patch adds initial support for Ampere-1B core.
The Ampere-1B core implements ARMv8.7 with the following (compiler
visible) extensions:
- CSSC (Common Short Sequence Compression instructions),
- MTE (Memory Tagging Extension)
- SM3/SM4
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def (AARCH64_CORE): Add ampere-1b
* config/aarch64/aarch64-cost-tables.h: Add ampere1b_extra_costs
* config/aarch64/aarch64-tune.md: Regenerate
* config/aarch64/aarch64.cc: Include ampere1b tuning model
* doc/invoke.texi: Document -mcpu=ampere1b
* config/aarch64/tuning_models/ampere1b.h: New file.
Marek Polacek [Fri, 17 Nov 2023 19:48:44 +0000 (14:48 -0500)]
c++: P2280R4, Using unknown refs in constant expr [PR106650]
This patch is an attempt to implement (part of?) P2280, Using unknown
pointers and references in constant expressions. (Note that R4 seems to
only allow References to unknown/Accesses via this, but not Pointers to
unknown.)
This patch works to the extent that the test case added in [expr.const]
works as expected, as well as the test in
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2280r4.html#the-this-pointer>
Most importantly, the proposal makes this compile:
void check(int const (¶m)[3]) {
constexpr auto s = array_size(param);
static_assert (s == 3);
}
and I think it would be a pity not to have it in GCC 14.
What still doesn't work is the test in $3.2:
struct A2 { constexpr int f() { return 0; } };
struct B2 : virtual A2 {};
void f2(B2 &b) { constexpr int k = b.f(); }
where we say
error: '* & b' is not a constant expression
This will be fixed in the future.
PR c++/106650
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression) <case PARM_DECL>: Allow
reference to unknown/this as per P2280.
<case VAR_DECL>: Allow reference to unknown as per P2280.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-array-ptr6.C: Remove dg-error.
* g++.dg/cpp0x/constexpr-ref12.C: Likewise.
* g++.dg/cpp0x/constexpr-ref2.C: Adjust dg-error.
* g++.dg/cpp0x/noexcept34.C: Remove dg-error.
* g++.dg/cpp1y/lambda-generic-const10.C: Likewise.
* g++.dg/cpp0x/constexpr-ref13.C: New test.
* g++.dg/cpp1z/constexpr-ref1.C: New test.
* g++.dg/cpp1z/constexpr-ref2.C: New test.
* g++.dg/cpp2a/constexpr-ref1.C: New test.
Patrick Palka [Wed, 29 Nov 2023 21:42:39 +0000 (16:42 -0500)]
c++: bogus -Wparentheses warning [PR112765]
We need to consistently look through implicit INDIRECT_REF when
setting/checking for -Wparentheses warning suppression. In passing
use the recently introduced STRIP_REFERENCE_REF helper some more.
PR c++/112765
gcc/cp/ChangeLog:
* pt.cc (tsubst_expr) <case MODOP_EXPR>: Look through implicit
INDIRECT_REF when propagating -Wparentheses warning suppression.
* semantics.cc (maybe_warn_unparenthesized_assignment): Replace
REFERENCE_REF_P handling with STRIP_REFERENCE_REF.
(finish_parenthesized_expr): Likewise.
David Faust [Wed, 29 Nov 2023 17:36:02 +0000 (09:36 -0800)]
bpf: change ASM_COMMENT_START to '#'
The BPF "pseudo-C" assembly dialect uses semi-colon (;) to separate
statements, not to begin line comments. The GNU assembler was recently
changed accordingly:
This patch adapts the BPF backend in GCC accordingly, to use a hash (#)
instead of semi-colon (;) for ASM_COMMENT_START. This is supported
already in clang.
gcc/
* config/bpf/bpf.h (ASM_COMMENT_START): Change from ';' to '#'.
gcc/testsuite/
* gcc.target/bpf/core-builtin-enumvalue-opt.c: Change dg-final
scans to not assume a specific comment character.
* gcc.target/bpf/core-builtin-enumvalue.c: Likewise.
* gcc.target/bpf/core-builtin-type-based.c: Likewise.
* gcc.target/bpf/core-builtin-type-id.c: Likewise.
Jakub Jelinek [Wed, 29 Nov 2023 18:19:07 +0000 (19:19 +0100)]
rs6000: Fix up c-c++-common/builtin-classify-type-1.c failure [PR112725]
The rs6000 backend (and s390 one as well) diagnoses passing vector types
to unprototyped functions, which breaks the builtin-classify-type-1.c test.
The builtin isn't really unprototyped, it is just type-generic and accepting
vector types is just fine there, all it does is categorize the vector type.
The following patch makes sure we don't diagnose it for this builtin.
2023-11-29 Jakub Jelinek <jakub@redhat.com>
PR target/112725
* config/rs6000/rs6000.cc (invalid_arg_for_unprototyped_fn): Return
NULL for __builtin_classify_type calls with vector arguments.
Martin Jambor [Wed, 29 Nov 2023 15:24:33 +0000 (16:24 +0100)]
tree-sra: Avoid returns of references to SRA candidates
The enhancement to address PR 109849 contained an importsnt thinko,
and that any reference that is passed to a function and does not
escape, must also not happen to be aliased by the return value of the
function. This has quickly transpired as bugs PR 112711 and PR
112721.
Just as IPA-modref does a good enough job to allow us to rely on the
escaped set of variables, it sems to be doing well also on updating
EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
exactly the situation we need to avoid. Of course, if a call
statement ignores any returned value, we also do not need to check the
flag.
Hopefully this does not pessimize things too much, I have verified
that the PR 109849 testcae remains quick and so should also the
benchmark it is derived from.
gcc/ChangeLog:
2023-11-27 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/112711
PR tree-optimization/112721
* tree-sra.cc (build_access_from_call_arg): New parameter
CAN_BE_RETURNED, disqualify any candidate passed by reference if it is
true. Adjust leading comment.
(scan_function): Pass appropriate value to CAN_BE_RETURNED of
build_access_from_call_arg.
Rainer Orth [Wed, 29 Nov 2023 13:52:04 +0000 (14:52 +0100)]
testsuite, i386: Only check for cfi directives if supported [PR112729]
gcc.target/i386/apx-interrupt-1.c and two more tests FAIL on Solaris/x86
with the native assembler. Like Darwin as, it doesn't support cfi
directives. Instead of adding more and more targets in every affected
test, this patch introduces a cfi effective-target keyword to check for
the prerequisite.
Tested on i386-pc-solaris2.11 (as and gas), x86_64-pc-linux-gnu, and
x86_64-apple-darwin23.1.0.
Thomas Schwinge [Tue, 28 Nov 2023 16:52:34 +0000 (17:52 +0100)]
Fix 'g++.dg/cpp26/static_assert1.C' for '-fno-exceptions' configurations
This test case, added in recent commit 6ce952188ab39e303e4f63e474b5cba83b5b12fd
"c++: Implement C++26 P2741R3 - user-generated static_assert messages [PR110348]",
expectedly runs into 'UNSUPPORTED: [...]: exception handling disabled', but
along the way also FAILs a few tests:
UNSUPPORTED: g++.dg/cpp26/static_assert1.C -std=gnu++98
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++11 (test for warnings, line 6)
[...]
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++11 (test for warnings, line 51)
FAIL: g++.dg/cpp26/static_assert1.C -std=gnu++11 (test for errors, line 52)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++11 (test for warnings, line 56)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++11 (test for warnings, line 57)
FAIL: g++.dg/cpp26/static_assert1.C -std=gnu++11 at line 58 (test for errors, line 57)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++11 (test for warnings, line 59)
[...]
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++11 at line 308 (test for errors, line 307)
UNSUPPORTED: g++.dg/cpp26/static_assert1.C -std=gnu++11: exception handling disabled
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++14 (test for warnings, line 6)
[...]
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++14 (test for warnings, line 51)
FAIL: g++.dg/cpp26/static_assert1.C -std=gnu++14 (test for errors, line 52)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++14 (test for warnings, line 56)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++14 (test for warnings, line 57)
FAIL: g++.dg/cpp26/static_assert1.C -std=gnu++14 at line 58 (test for errors, line 57)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++14 (test for warnings, line 59)
[...]
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++14 at line 257 (test for errors, line 256)
FAIL: g++.dg/cpp26/static_assert1.C -std=gnu++14 (test for errors, line 261)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++14 (test for warnings, line 262)
[...]
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++14 at line 308 (test for errors, line 307)
UNSUPPORTED: g++.dg/cpp26/static_assert1.C -std=gnu++14: exception handling disabled
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++20 (test for warnings, line 6)
[...]
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++20 (test for warnings, line 51)
FAIL: g++.dg/cpp26/static_assert1.C -std=gnu++20 (test for errors, line 52)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++20 (test for warnings, line 56)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++20 (test for warnings, line 57)
FAIL: g++.dg/cpp26/static_assert1.C -std=gnu++20 at line 58 (test for errors, line 57)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++20 (test for warnings, line 59)
[...]
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++20 at line 257 (test for errors, line 256)
FAIL: g++.dg/cpp26/static_assert1.C -std=gnu++20 (test for errors, line 261)
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++20 (test for warnings, line 262)
[...]
PASS: g++.dg/cpp26/static_assert1.C -std=gnu++20 at line 308 (test for errors, line 307)
UNSUPPORTED: g++.dg/cpp26/static_assert1.C -std=gnu++20: exception handling disabled
Use an explicit '-fexceptions' to turn this front end test case all-PASS.
gcc/testsuite/
* g++.dg/cpp26/static_assert1.C: Fix for '-fno-exceptions'
configurations.
Thomas Schwinge [Tue, 28 Nov 2023 16:30:13 +0000 (17:30 +0100)]
Fix '23_containers/span/at.cc' for '-fno-exceptions' configurations
Added in recent commit 1fa85dcf656e2f2c7e483c9ed3c2680bf7db6858
"libstdc++: Add std::span::at for C++26 (P2821R5)", the test case already
does use '#if __cpp_exceptions', but failed to correspondingly guard the
'dg-warning' directives, resulting in:
FAIL: 23_containers/span/at.cc -std=gnu++26 (test for warnings, line 15)
FAIL: 23_containers/span/at.cc -std=gnu++26 (test for warnings, line 26)
PASS: 23_containers/span/at.cc -std=gnu++26 (test for excess errors)
PASS: 23_containers/span/at.cc -std=gnu++26 execution test
libstdc++-v3/
* testsuite/23_containers/span/at.cc: Fix for '-fno-exceptions'
configurations.
[1 MEM <vector(16) int> [(int *)vectp_b.12_28]+0 S64 A32]
are problematic. They tell us the instruction stores and reads a full
vector which it if course does not. There isn't any good MEM_EXPR
we can use here (we lack a way to just specify a pointer and restrict
info for example), and since the MEMs have a vector mode it's
difficult in general as passes do not need to look at the memory
attributes at all.
The easiest way to avoid running into the alias analysis problem is
to scrap the MEM_EXPR when we expand the internal functions for
partial loads/stores. That avoids the disambiguation we run into
which is realizing that we store to an object of less size as
the size of the mode we appear to store.
After the patch we see just
[1 S64 A32]
so we preserve the alias set, the alignment and the size (the size
is redundant if the MEM insn't BLKmode). That's still not good
in case the RTL alias oracle would implement the same
disambiguation but it fends off the gimple one.
This fixes gcc.dg/torture/pr58955-2.c when built with AVX512
and --param=vect-partial-vector-usage=1.
Jakub Jelinek [Wed, 29 Nov 2023 11:26:50 +0000 (12:26 +0100)]
fold-const: Fix up multiple_of_p [PR112733]
We ICE on the following testcase when wi::multiple_of_p is called on
widest_int 1 and -128 with UNSIGNED. I still need to work on the
actual wide-int.cc issue, the latest patch attached to the PR regressed
bitint-{38,39}.c, so will need to debug that, but there is a clear bug
on the fold-const.cc side as well - widest_int is a signed representation
by definition, using UNSIGNED with it certainly doesn't match what was
intended, because -128 as the second operand effectively means unsigned
131072 bit 0xfffff............ffff80 integer, not the signed char -128
that appeared in the source.
In the INTEGER_CST case a few lines above this we already use
case INTEGER_CST:
if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
return false;
return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
SIGNED);
so I think using SIGNED with widest_int is best there (compared to the
other choices in the PR).
2023-11-29 Jakub Jelinek <jakub@redhat.com>
PR middle-end/112733
* fold-const.cc (multiple_of_p): Pass SIGNED rather than
UNSIGNED for wi::multiple_of_p on widest_int arguments.
Iain Sandoe [Sun, 29 Oct 2023 07:19:53 +0000 (07:19 +0000)]
testsuite, x86: Handle a broken assembler
Earlier assembler support for complex fp16 on x86_64 Darwin is broken.
This adds an additional test to the existing target-supports that fails
for the broken assemblers but works for the newer, fixed, ones.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Test an asm line that fails on broken
Darwin assembler versions.
Juzhe-Zhong [Wed, 29 Nov 2023 08:34:10 +0000 (16:34 +0800)]
RISC-V: Support highpart register overlap for vwcvt
Since Richard supports register filters recently, we are able to support highpart register
overlap for widening RVV instructions.
This patch support it for vwcvt intrinsics.
I leverage real application user codes for vwcvt:
https://github.com/riscv/riscv-v-spec/issues/929
https://godbolt.org/z/xoeGnzd8q
This is the real application codes that using LMUL = 8 with unrolling to gain optimal
performance for specific libraury.
You can see in the codegen, GCC has optimal codegen for such since we supported register
lowpart overlap for narrowing instructions (dest EEW < source EEW).
Now, we start to support highpart register overlap from this patch for widening instructions (dest EEW > source EEW).
Leverage this intrinsic codes above but for vwcvt:
* config/riscv/constraints.md (TARGET_VECTOR ? V_REGS : NO_REGS): New register filters.
* config/riscv/riscv.md (no,W21,W42,W84,W41,W81,W82): Ditto.
(no,yes): Ditto.
* config/riscv/vector.md: Support highpart register overlap for vwcvt.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr112431-1.c: New test.
* gcc.target/riscv/rvv/base/pr112431-2.c: New test.
* gcc.target/riscv/rvv/base/pr112431-3.c: New test.
xuli [Wed, 29 Nov 2023 08:38:00 +0000 (08:38 +0000)]
RISC-V: Add explicit braces to eliminate warning.
../.././gcc/gcc/config/riscv/riscv.cc: In function ‘void riscv_option_override()’:
../.././gcc/gcc/config/riscv/riscv.cc:8673:6: warning: suggest explicit braces to avoid ambiguous ‘else’ [-Wdangling-else]
if (TARGET_RVE)
^
Jose E. Marchesi [Wed, 29 Nov 2023 08:16:48 +0000 (09:16 +0100)]
testsuite: move gcc.c-torture/compile/libcall-2.c to gcc.target/i386/libcall-1.c
This patch relocates a test that is really x86 specific, and changes
it to use check_effective_target_int128.
gcc/testsuite/ChangeLog
* gcc.c-torture/compile/libcall-2.c: Remove.
* gcc.target/i386/libcall-1.c: Moved from
gcc.c-torture/compile/libcall-2.c and adapted to use
effective-target for int128_t.
Jakub Jelinek [Wed, 29 Nov 2023 08:19:02 +0000 (09:19 +0100)]
c++: Fix a compile time memory leak in finish_static_assert
On Tue, Nov 28, 2023 at 11:31:48AM -0500, Jason Merrill wrote:
> Jonathan pointed out elsewhere that this gets leaked if error return
> prevents us from getting to the XDELETEVEC.
As there is a single error return in which it can leak, I've just added
a XDELETEVEC (buf); statement to that path rather than introducing some
RAII solution.
2023-11-29 Jakub Jelinek <jakub@redhat.com>
* semantics.cc (finish_static_assert): Free buf on error return.
The introduction of the fold-mem-offsets pass breaks profiledbootstrap
on powerpc64le-linux.
From what I can see, the pass works one basic block at a time and
will punt on any non-DEBUG_INSN uses outside of the current block
(I believe because of the
/* This use affects instructions outside of CAN_FOLD_INSNS. */
if (!bitmap_bit_p (&can_fold_insns, INSN_UID (use)))
return 0;
test and can_fold_insns only set in do_analysis (when processing insns in
current bb, cleared at the end) or results of get_single_def_in_bb
(which are checked to be in the same bb).
But, while get_single_def_in_bb checks for
if (DF_INSN_LUID (def) > DF_INSN_LUID (insn))
return NULL;
The basic block in the PR in question has:
...
(insn 212 210 215 25 (set (mem/f:DI (reg/v/f:DI 10 10 [orig:152 last_viable ] [152]) [2 *last_viable_336+0 S8 A64])
(reg/f:DI 9 9 [orig:155 _342 ] [155])) "pr111601.ii":50:17 683 {*movdi_internal64}
(expr_list:REG_DEAD (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(nil)))
(insn 215 212 484 25 (set (reg:DI 5 5 [226])
(const_int 0 [0])) "pr111601.ii":52:12 683 {*movdi_internal64}
(expr_list:REG_EQUIV (const_int 0 [0])
(nil)))
(insn 484 215 218 25 (set (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(reg/f:DI 9 9 [orig:155 _342 ] [155])) "pr111601.ii":52:12 683 {*movdi_internal64}
(nil))
...
(insn 564 214 216 25 (set (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(plus:DI (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(const_int 96 [0x60]))) "pr111601.ii":52:12 66 {*adddi3}
(nil))
(insn 216 564 219 25 (set (mem/f:DI (reg/v/f:DI 10 10 [orig:152 last_viable ] [152]) [2 _343->next+0 S8 A64])
(reg:DI 5 5 [226])) "pr111601.ii":52:12 683 {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 5 5 [226])
(nil)))
...
and when asking for all uses of %r10 from def 564, it will see uses
in 216 and 212; the former is after the += 96 addition and gets changed
to load from %r10+96 with the addition being dropped, but there is
the other store which is a use across the backedge and when reached
from other edges certainly doesn't have the + 96 addition anywhere,
so the pass doesn't actually change that location.
This patch adds checks from get_single_def_in_bb to get_uses as well,
in particular check that the (regular non-debug) use only appears in the
same basic block as the definition and that it doesn't appear before it (i.e.
use across backedge).
2023-11-29 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/111601
* fold-mem-offsets.cc (get_uses): Ignore DEBUG_INSN uses. Otherwise,
punt if use is in a different basic block from INSN or appears before
INSN in the same basic block. Formatting fixes.
(get_single_def_in_bb): Formatting fixes.
(fold_offsets_1, pass_fold_mem_offsets::execute): Comment formatting
fixes.
Xi Ruoyao [Sun, 19 Nov 2023 19:51:56 +0000 (03:51 +0800)]
LoongArch: Use LSX for scalar FP rounding with explicit rounding mode
In LoongArch FP base ISA there is only the frint.{s/d} instruction which
reads the global rounding mode. Utilize LSX for explicit rounding mode
even if the operand is scalar. It seems wasting the CPU power, but
still much faster than calling the library function.
gcc/ChangeLog:
* config/loongarch/simd.md (LSX_SCALAR_FRINT): New int iterator.
(VLSX_FOR_FMODE): New mode attribute.
(<simd_for_scalar_frint_pattern><mode>2): New expander,
expanding to vreplvei.{w/d} + frint{rp/rz/rm/rne}.{s.d}.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vect-frint-scalar.c: New test.
* gcc.target/loongarch/vect-frint-scalar-no-inexact.c: New test.
Xi Ruoyao [Fri, 17 Nov 2023 20:48:20 +0000 (04:48 +0800)]
LoongArch: Fix usage of LSX and LASX frint/ftint instructions [PR112578]
The usage LSX and LASX frint/ftint instructions had some problems:
1. These instructions raises FE_INEXACT, which is not allowed with
-fno-fp-int-builtin-inexact for most C2x section F.10.6 functions
(the only exceptions are rint, lrint, and llrint).
2. The "frint" instruction without explicit rounding mode is used for
roundM2, this is incorrect because roundM2 is defined "rounding
operand 1 to the *nearest* integer, rounding away from zero in the
event of a tie". We actually don't have such an instruction. Our
frintrne instruction is roundevenM2 (unfortunately, this is not
documented).
3. These define_insn's are written in a way not so easy to hack.
So I removed these instructions and created a "simd.md" file, then added
them and the corresponding expanders there. The advantage of the
simd.md file is we don't need to duplicate the RTL template twice (in
lsx.md and lasx.md).
gcc/ChangeLog:
PR target/112578
* config/loongarch/lsx.md (UNSPEC_LSX_VFTINT_S,
UNSPEC_LSX_VFTINTRNE, UNSPEC_LSX_VFTINTRP,
UNSPEC_LSX_VFTINTRM, UNSPEC_LSX_VFRINTRNE_S,
UNSPEC_LSX_VFRINTRNE_D, UNSPEC_LSX_VFRINTRZ_S,
UNSPEC_LSX_VFRINTRZ_D, UNSPEC_LSX_VFRINTRP_S,
UNSPEC_LSX_VFRINTRP_D, UNSPEC_LSX_VFRINTRM_S,
UNSPEC_LSX_VFRINTRM_D): Remove.
(ILSX, FLSX): Move into ...
(VIMODE): Move into ...
(FRINT_S, FRINT_D): Remove.
(frint_pattern_s, frint_pattern_d, frint_suffix): Remove.
(lsx_vfrint_<flsxfmt>, lsx_vftint_s_<ilsxfmt>_<flsxfmt>,
lsx_vftintrne_w_s, lsx_vftintrne_l_d, lsx_vftintrp_w_s,
lsx_vftintrp_l_d, lsx_vftintrm_w_s, lsx_vftintrm_l_d,
lsx_vfrintrne_s, lsx_vfrintrne_d, lsx_vfrintrz_s,
lsx_vfrintrz_d, lsx_vfrintrp_s, lsx_vfrintrp_d,
lsx_vfrintrm_s, lsx_vfrintrm_d,
<FRINT_S:frint_pattern_s>v4sf2,
<FRINT_D:frint_pattern_d>v2df2, round<mode>2,
fix_trunc<mode>2): Remove.
* config/loongarch/lasx.md: Likewise.
* config/loongarch/simd.md: New file.
(ILSX, ILASX, FLSX, FLASX, VIMODE): ... here.
(IVEC, FVEC): New mode iterators.
(VIMODE): ... here. Extend it to work for all LSX/LASX vector
modes.
(x, wu, simd_isa, WVEC, vimode, simdfmt, simdifmt_for_f,
elebits): New mode attributes.
(UNSPEC_SIMD_FRINTRP, UNSPEC_SIMD_FRINTRZ, UNSPEC_SIMD_FRINT,
UNSPEC_SIMD_FRINTRM, UNSPEC_SIMD_FRINTRNE): New unspecs.
(SIMD_FRINT): New int iterator.
(simd_frint_rounding, simd_frint_pattern): New int attributes.
(<simd_isa>_<x>vfrint<simd_frint_rounding>_<simdfmt>): New
define_insn template for frint instructions.
(<simd_isa>_<x>vftint<simd_frint_rounding>_<simdifmt_for_f>_<simdfmt>):
Likewise, but for ftint instructions.
(<simd_frint_pattern><mode>2): New define_expand with
flag_fp_int_builtin_inexact checked.
(l<simd_frint_pattern><mode><vimode>2): Likewise.
(ftrunc<mode>2): New define_expand. It does not require
flag_fp_int_builtin_inexact.
(fix_trunc<mode><vimode>2): New define_insn_and_split. It does
not require flag_fp_int_builtin_inexact.
(include): Add lsx.md and lasx.md.
* config/loongarch/loongarch.md (include): Include simd.md,
instead of including lsx.md and lasx.md directly.
* config/loongarch/loongarch-builtins.cc
(CODE_FOR_lsx_vftint_w_s, CODE_FOR_lsx_vftint_l_d,
CODE_FOR_lasx_xvftint_w_s, CODE_FOR_lasx_xvftint_l_d):
Remove.
gcc/testsuite/ChangeLog:
PR target/112578
* gcc.target/loongarch/vect-frint.c: New test.
* gcc.target/loongarch/vect-frint-no-inexact.c: New test.
* gcc.target/loongarch/vect-ftint.c: New test.
* gcc.target/loongarch/vect-ftint-no-inexact.c: New test.
Alexandre Oliva [Wed, 29 Nov 2023 07:00:45 +0000 (04:00 -0300)]
Introduce hardbool attribute for C
This patch introduces hardened booleans in C. The hardbool attribute,
when attached to an integral type, turns it into an enumerate type
with boolean semantics, using the named or implied constants as
representations for false and true.
Expressions of such types decay to _Bool, trapping if the value is
neither true nor false, and _Bool can convert implicitly back to them.
Other conversions go through _Bool first.
for gcc/c-family/ChangeLog
* c-attribs.cc (c_common_attribute_table): Add hardbool.
(handle_hardbool_attribute): New.
(type_valid_for_vector_size): Reject hardbool.
* c-common.cc (convert_and_check): Skip warnings for convert
and check for hardbool.
(c_hardbool_type_attr_1): New.
* c-common.h (c_hardbool_type_attr): New.
for gcc/c/ChangeLog
* c-typeck.cc (convert_lvalue_to_rvalue): Decay hardbools.
* c-convert.cc (convert): Convert to hardbool through
truthvalue.
* c-decl.cc (check_bitfield_type_and_width): Skip enumeral
truncation warnings for hardbool.
(finish_struct): Propagate hardbool attribute to bitfield
types.
(digest_init): Convert to hardbool.
for gcc/ChangeLog
* doc/extend.texi (hardbool): New type attribute.
* doc/invoke.texi (-ftrivial-auto-var-init): Document
representation vs values.
Alexandre Oliva [Wed, 29 Nov 2023 07:00:35 +0000 (04:00 -0300)]
call maybe_return_this in build_clone
__dt_base doesn't get its body from a maybe_return_this caller, it's
rather cloned with the full body within build_clone, and then it's
left alone, without going through finish_function_body or
build_delete_destructor_body, that call maybe_return_this.
Now, this is correct as far as the generated code is concerned, since
the cloned body of a cdtor that returns this is also a cdtor body that
returns this. The problem is that the decl for THIS is also cloned,
and it doesn't get the warning suppression introduced by
maybe_return_this, so Wuse-after-free3.C fails with an excess warning
at the closing brace of the dtor body.
I've split out the warning suppression from maybe_return_this, and
arranged to call that bit from the relevant build_clone case.
Unfortunately, because the warning is silenced for all uses of the
THIS decl, rather than only for the ABI-mandated return stmt, this
also silences the very warning that the testcase checks for.
I'm not revamping the warning suppression approach to overcome this,
so I'm xfailing the expected warning on ARM EABI, hoping that's the
only target with cdtor_return_this, and leaving it at that.
for gcc/cp/ChangeLog
* decl.cc (maybe_prepare_return_this): Split out of...
(maybe_return_this): ... this.
* cp-tree.h (maybe_prepare_return_this): Declare.
* class.cc (build_clone): Call it.
for gcc/testsuite/ChangeLog
* g++.dg/warn/Wuse-after-free3.C: xfail on arm_eabi.
Alexandre Oliva [Wed, 29 Nov 2023 07:00:28 +0000 (04:00 -0300)]
c++: for contracts, cdtors never return this
When targetm.cxx.cdtor_return_this() holds, cdtors have a
non-VOID_TYPE_P result, but IMHO this ABI implementation detail
shouldn't leak to the abstract language conceptual framework, in which
cdtors don't have return values. For contracts, specifically those
that establish postconditions on results, such a leakage is present,
and the present patch puts an end to it: with it, cdtors get an error
for result postconditions regardless of the ABI. This fixes
g++.dg/contracts/contracts-ctor-dtor2.C on arm-eabi.
for gcc/cp/ChangeLog
* contracts.cc (check_postcondition_result): Cope with
cdtor_return_this.
Alexandre Oliva [Wed, 29 Nov 2023 07:00:24 +0000 (04:00 -0300)]
Introduce -finline-stringops
try_store_by_multiple_pieces was added not long ago, enabling
variable-sized memset to be expanded inline when the worst-case
in-range constant length would, using conditional blocks with powers
of two to cover all possibilities of length and alignment.
This patch introduces -finline-stringops[=fn] to request expansions to
start with a loop, so as to still take advantage of known alignment
even with long lengths, but without necessarily adding store blocks
for every power of two.
This makes it possible for the supported stringops (memset, memcpy,
memmove, memset) to be expanded, even if storing a single byte per
iteration. Surely efficient implementations can run faster, with a
pre-loop to increase alignment, but that would likely be excessive for
inline expansions.
Still, in some cases, such as in freestanding environments, users
prefer to inline such stringops, especially those that the compiler
may introduce itself, even if the expansion is not as performant as a
highly optimized C library implementation could be, to avoid
depending on a C runtime library.
for gcc/ChangeLog
* expr.cc (emit_block_move_hints): Take ctz of len. Obey
-finline-stringops. Use oriented or sized loop.
(emit_block_move): Take ctz of len, and pass it on.
(emit_block_move_via_sized_loop): New.
(emit_block_move_via_oriented_loop): New.
(emit_block_move_via_loop): Take incr. Move an incr-sized
block per iteration.
(emit_block_cmp_via_cmpmem): Take ctz of len. Obey
-finline-stringops.
(emit_block_cmp_via_loop): New.
* expr.h (emit_block_move): Add ctz of len defaulting to zero.
(emit_block_move_hints): Likewise.
(emit_block_cmp_hints): Likewise.
* builtins.cc (expand_builtin_memory_copy_args): Pass ctz of
len to emit_block_move_hints.
(try_store_by_multiple_pieces): Support starting with a loop.
(expand_builtin_memcmp): Pass ctz of len to
emit_block_cmp_hints.
(expand_builtin): Allow inline expansion of memset, memcpy,
memmove and memcmp if requested.
* common.opt (finline-stringops): New.
(ilsop_fn): New enum.
* flag-types.h (enum ilsop_fn): New.
* doc/invoke.texi (-finline-stringops): Add.
Hongyu Wang [Tue, 28 Nov 2023 03:24:01 +0000 (11:24 +0800)]
[i386] Fix push2pop2 test fail on non-linux target [PR112729]
On linux x86-64, -fomit-frame-pointer was by default enabled so the
push2pop2 tests cfi scans are based on it. On other target with
-fno-omit-frame-pointer the cfi scan will be wrong as the frame pointer
is pushed at first. Add -fomit-frame-pointer to these tests that related
to cfi scan.
Jason Merrill [Tue, 28 Nov 2023 18:54:47 +0000 (13:54 -0500)]
c++: prvalue array decay [PR94264]
My change for PR53220 made array to pointer decay for prvalue arrays
ill-formed to catch well-defined C code that produces a dangling pointer in
C++ due to the shorter lifetime of compound literals. This wasn't really
correct, but wasn't a problem until C++17 added prvalue arrays, at which
point it started rejecting valid C++ code.
I wanted to make sure that we still diagnose the problematic code;
-Wdangling-pointer covers the array-lit.c case, but I needed to extend
-Wreturn-local-addr to handle the return case.
Roger Sayle [Tue, 28 Nov 2023 18:34:56 +0000 (18:34 +0000)]
ARC: Consistent use of whitespace in assembler templates.
This minor clean-up patch tweaks arc.md to use whitespace consistently
in output templates, always using a TAB between the mnemonic and its
operands, and avoiding spaces after commas betweem operands. There
should be no functional changes with this patch, though several test
cases' scan-assembler need to be updated to use \\s+ instead of testing
for a TAB or a space explicitly.
2023-11-28 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* config/arc/arc.md: Make output template whitespace consistent.
Andrew Pinski [Tue, 28 Nov 2023 00:41:25 +0000 (16:41 -0800)]
MATCH: Fix invalid signed boolean type usage
This fixes the incorrect assumption that was done in r14-3721-ge6bcf839894783,
that being able to doing the negative after the conversion would be a valid thing
but really it is not valid for boolean types.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
PR tree-optimization/112738
* match.pd (`(nop_convert)-(convert)a`): Reject
when the outer type is boolean.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Jakub Jelinek [Tue, 28 Nov 2023 17:25:14 +0000 (18:25 +0100)]
c++: Fix up __has_extension (cxx_init_captures)
On Mon, Nov 27, 2023 at 10:58:04AM +0000, Alex Coplan wrote:
> Many thanks both for the reviews, this is now pushed (with Jason's
> above changes implemented) as g:06280a906cb3dc80cf5e07cf3335b758848d488d.
The new test FAILs everywhere with GXX_TESTSUITE_STDS=98,11,14,17,20,2b
I'm normally using for testing.
FAIL: g++.dg/ext/has-feature.C -std=gnu++11 (test for excess errors)
Excess errors:
/home/jakub/src/gcc/gcc/testsuite/g++.dg/ext/has-feature.C:185:2: error: #error
This is on
#if __has_extension (cxx_init_captures) != CXX11
#error
#endif
Comparing the values with clang++ on godbolt and with what is actually
implemented:
void foo () { auto a = [b = 3]() { return b; }; }
both clang++ and GCC implement init captures as extension already in C++11
(and obviously not in C++98 because lambdas aren't implemented there),
unless -pedantic-errors/-Werror=pedantic, so I think we should change
the FE to match the test rather than the other way around.
Making __has_extension return __has_feature for -pedantic-errors and not
for -Werror=pedantic is just weird, but as that is what clang++ implements
and this is for compatibility with it, I can live with it (but perhaps
we should mention it in the documentation). Note, the warnings/errors
can be changed using pragmas inside of the source, so whether one can
use an extension or not depends on where in the code it is (__extension__
to the rescue if it can be specified around it).
I wonder if the has-feature.C test shouldn't be #included in other 2 tests,
one where -pedantic-errors would be in dg-options and through some macro
tell the file that __has_extension will behave like __has_feature, and
another with -Werror=pedantic to document that the option doesn't change
it.
2023-11-28 Jakub Jelinek <jakub@redhat.com>
* cp-objcp-common.cc (cp_feature_table): Evaluate
__has_extension (cxx_init_captures) to 1 even for -std=c++11.
Simon Wright [Tue, 28 Nov 2023 13:56:36 +0000 (14:56 +0100)]
Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the current
assumption for __APPLE__ is that file names are case-insensitive
unless __arm__ or __arm64__ are defined, in which case file names are
declared case-sensitive.
The associated comment is
"By default, we suppose filesystems aren't case sensitive on
Windows and Darwin (but they are on arm-darwin)."
This means that on aarch64-apple-darwin, file names are treated as
case-sensitive, which is not the default case.
The true default position is that macOS file systems are
case-insensitive, iOS file systems are case-sensitive.
Apple provide a header file <TargetConditionals.h> which permits a
compile-time check for the compiler target (e.g. OSX vs IOS); if
TARGET_OS_IOS is defined as 1, this is a build for iOS.
2023-11-22 Simon Wright <simon@pushface.org>
gcc/ada/
PR ada/111909
* adaint.c
(__gnat_get_file_names_case_sensitive): Split out the __APPLE__
check and remove the checks for __arm__, __arm64__. For Apple,
file names are by default case-insensitive unless TARGET_OS_IOS is
set.
Richard Biener [Tue, 28 Nov 2023 11:49:35 +0000 (12:49 +0100)]
middle-end/112741 - ICE with gimple FE and later regimplification
The GIMPLE frontend, when bypassing gimplification, doesn't set
DECL_SEEN_IN_BIND_EXPR_P given there are no such things in GIMPLE.
But it probably should set the flag anyway to avoid later ICEs
when regimplifying.
PR middle-end/112741
gcc/c/
* gimple-parser.cc (c_parser_parse_gimple_body): Also
set DECL_SEEN_IN_BIND_EXPR_Pfor locals.
gcc/testsuite/
* gcc.dg/ubsan/pr112741.c: New testcase.
Uros Bizjak [Tue, 28 Nov 2023 15:56:29 +0000 (16:56 +0100)]
i386: Improve cmpstrnqi_1 insn pattern [PR112494]
REPZ CMPSB instruction does not update FLAGS register when %ecx register
equals zero. Improve cmpstrnqi_1 insn pattern to set FLAGS_REG to its
previous value instead of (const_int 0) when operand 2 equals zero.
PR target/112494
gcc/ChangeLog:
* config/i386/i386.md (cmpstrnqi_1): Set FLAGS_REG to its previous
value when operand 2 equals zero.
(*cmpstrnqi_1): Ditto.
(*cmpstrnqi_1 peephole2): Ditto.
Andrew Jenner [Tue, 28 Nov 2023 15:27:05 +0000 (15:27 +0000)]
Fortran: fix reallocation on assignment of polymorphic variables [PR110415]
This patch fixes two bugs related to polymorphic class assignment in the
Fortran front-end. One (described in PR110415) is an issue with the malloc
and realloc calls using the size from the old vptr rather than the new one.
The other is caused by the return value from the realloc call being ignored.
Testcases are added for these issues.
2023-11-28 Andrew Jenner <andrew@codesourcery.com>
gcc/fortran/
PR fortran/110415
* trans-expr.cc (trans_class_vptr_len_assignment): Add
from_vptrp parameter. Populate it. Don't check for DECL_P
when deciding whether to create temporary.
(trans_class_pointer_fcn, gfc_trans_pointer_assignment): Add
NULL argument to trans_class_vptr_len_assignment calls.
(trans_class_assignment): Get rhs_vptr from
trans_class_vptr_len_assignment and use it for determining size
for allocation/reallocation. Use return value from realloc.
gcc/testsuite/
PR fortran/110415
* gfortran.dg/pr110415.f90: New test.
* gfortran.dg/asan/pr110415-2.f90: New test.
* gfortran.dg/asan/pr110415-3.f90: New test.
Jose E. Marchesi [Fri, 24 Nov 2023 05:30:28 +0000 (06:30 +0100)]
Emit funcall external declarations only if actually used.
There are many places in GCC where alternative local sequences are
tried in order to determine what is the cheapest or best alternative
to use in the current target. When any of these sequences involve a
libcall, the current implementation of emit_library_call_value_1
introduce a side-effect consisting on emitting an external declaration
for the funcall (such as __divdi3) which is thus emitted even if the
sequence that does the libcall is not retained.
This is problematic in targets such as BPF, because the kernel loader
chokes on the spurious symbol __divdi3 and makes the resulting BPF
object unloadable. Note that BPF objects are not linked before being
loaded.
This patch changes asssemble_external_libcall to defer emitting
declarations of external libcall symbols, by saving the call tree
nodes in a temporary list pending_libcall_symbols and letting
process_pending_assembly_externals to emit them only if they have been
referenced. Solution suggested and sketched by Richard Sandiford.
Regtested in x86_64-linux-gnu.
Tested with host x86_64-linux-gnu with target bpf-unknown-none.
gcc/ChangeLog
PR target/109253
* varasm.cc (pending_libcall_symbols): New variable.
(process_pending_assemble_externals): Process
pending_libcall_symbols.
(assemble_external_libcall): Defer emitting external libcall
symbols to process_pending_assemble_externals.
Rainer Orth [Tue, 28 Nov 2023 13:54:34 +0000 (14:54 +0100)]
libsanitizer: Check assembler support for symbol assignment [PR112563]
The recent libsanitizer import broke the build on Solaris/SPARC with the
native as:
/usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol
"__sanitizer_internal_memset" is used but not defined
/usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol
"__sanitizer_internal_memcpy" is used but not defined
/usr/ccs/bin/as: ".libs/sanitizer_errno.s", line 4247: error: symbol
"__sanitizer_internal_memmove" is used but not defined
Since none of the alternatives considered in the PR worked out, this
patch checks if the assembler does support symbol assignment, disabling
the code otherwise. This returns the code to the way it was up to LLVM 16.
Bootstrapped without regressions on sparc-sun-solaris2.11 (as and gas) and
i386-pc-solaris2.11 (as and gas).
This patch fixes a BTF, which would become invalid when having
smaller then 4 byte definitions of enums.
For example, when using the __attribute__((mode(byte))) in the enum
definition.
Two problems were identified:
- it would incorrectly create an entry for enum64 when the size of the
enum was different then 4.
- it would allocate less then 4 bytes for the value entry in BTF, in
case the type was smaller.
BTF generated was validated against clang.
gcc/ChangeLog:
* btfout.cc (btf_calc_num_vbytes): Fixed logic for enum64.
(btf_asm_enum_const): Corrected logic for enum64 and smaller
than 4 bytes values.
This patch enables errors when external calls are created.
When architectural limitations or usage of builtins implies the compiler
to create function calls to external libraries that implement the
functionality, GCC will now report an error claiming that this function
calls are not compatible with eBPF target.
Examples of those are the usage of __builtin_memmove and a sign division
in BPF ISA v3 or below that will require to call __divdi3.
This is currently an eBPF limitation which does not support linking of
object files but rather "raw" non linked ones. Those object files are
loaded and relocated by libbpf and the kernel.
gcc/ChangeLog:
* config/bpf/bpf.cc (bpf_output_call): Report error in case the
function call is for a builtin.
(bpf_external_libcall): Added target hook to detect and report
error when other external calls that are not builtins.
Unlike most other ELF targets, that assembler requires the section name to
be double-quoted. This patch allows for that. It also expects \t to
separate .section directive and name like other similar tests, and escapes
literal dots.
Tested on sparc-sun-solaris2.11 (as and gas) and i386-pc-solaris2.11 (as
and gas).
bpf: Forces __buildin_memcmp not to generate a call upto 1024 bytes.
This patch forces __builtin_memcmp calls upto data sizes of 1024 to
become inline in caller.
This is a requirement by BPF and it mimics the default behaviour of the
clang BPF implementation.
gcc/ChangeLog:
* config/bpf/bpf.cc (bpf_use_by_pieces_infrastructure_p): Added
function to bypass default behaviour.
* config/bpf/bpf.h (COMPARE_MAX_PIECES): Defined to 1024 bytes.
bpf: Delayed the removal of the parser enum plugin handler.
The parser plugin handler that is responsible for collecting enum values
information was being removed way too early.
bpf_resolve_overloaded_core_builtin is called by the parser.
It was moved to the function execute_lower_bpf_core.
gcc/ChangeLog:
* config/bpf/core-builtins.cc
(bpf_resolve_overloaded_core_builtin): Removed call.
(execute_lower_bpf_core): Added all to remove_parser_plugin.
Jakub Jelinek [Tue, 28 Nov 2023 12:14:05 +0000 (13:14 +0100)]
libiberty: Use x86 HW optimized sha1
Nick has approved this patch (+ small ld change to use it for --build-id=),
so I'm commiting it to GCC as master as well.
If anyone from ARM would be willing to implement it similarly with
vsha1{cq,mq,pq,h,su0q,su1q}_u32 intrinsics, it could be a useful linker
speedup on those hosts as well, the intent in sha1.c was that
sha1_hw_process_bytes, sha1_hw_process_block functions
would be defined whenever
defined (HAVE_X86_SHA1_HW_SUPPORT) || defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT)
but the body of sha1_hw_process_block and sha1_choose_process_bytes
would then have #elif defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) for
the other arch support, similarly for any target attributes on
sha1_hw_process_block if needed.
2023-11-28 Jakub Jelinek <jakub@redhat.com>
include/
* sha1.h (sha1_process_bytes_fn): New typedef.
(sha1_choose_process_bytes): Declare.
libiberty/
* configure.ac (HAVE_X86_SHA1_HW_SUPPORT): New check.
* sha1.c: If HAVE_X86_SHA1_HW_SUPPORT is defined, include x86intrin.h
and cpuid.h.
(sha1_hw_process_bytes, sha1_hw_process_block,
sha1_choose_process_bytes): New functions.
* config.in: Regenerated.
* configure: Regenerated.
FAIL: gcc.dg/vect/pr71259.c -flto -ffat-lto-objects (internal compiler error: in SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: gcc.dg/vect/pr71259.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/vect-alias-check-14.c (internal compiler error: in SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: gcc.dg/vect/vect-alias-check-14.c (test for excess errors)
FAIL: gcc.dg/vect/vect-alias-check-14.c -flto -ffat-lto-objects (internal compiler error: in SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: gcc.dg/vect/vect-alias-check-14.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/vect-alias-check-9.c (internal compiler error: in SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: gcc.dg/vect/vect-alias-check-9.c (test for excess errors)
FAIL: gcc.dg/vect/vect-alias-check-9.c -flto -ffat-lto-objects (internal compiler error: in SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: gcc.dg/vect/vect-alias-check-9.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/vect-cond-arith-6.c (internal compiler error: in SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: gcc.dg/vect/vect-cond-arith-6.c (test for excess errors)
FAIL: gcc.dg/vect/vect-cond-arith-6.c -flto -ffat-lto-objects (internal compiler error: in SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: gcc.dg/vect/vect-cond-arith-6.c -flto -ffat-lto-objects (test for excess errors)
FAIL: gcc.dg/vect/vect-gather-5.c (internal compiler error: in SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: gcc.dg/vect/vect-gather-5.c (test for excess errors)
FAIL: gcc.dg/vect/vect-gather-5.c -flto -ffat-lto-objects (internal compiler error: in SET_TYPE_VECTOR_SUBPARTS, at tree.h:4248)
FAIL: gcc.dg/vect/vect-gather-5.c -flto -ffat-lto-objects (test for excess errors)
poly size (1, 1) vectors can not be allowed to interleave VLA SLP since interleave VLA SLP suppose VF at least hold 2 elements,
whereas, poly size (1,1) may possible only have 1 element.
Steve Baird [Tue, 14 Nov 2023 20:06:36 +0000 (12:06 -0800)]
ada: Error compiling reduction expression with overloaded reducer subprogram
In some cases involving a reduction expression with an overloaded reducer
subprogram, the accumulator type is not determined correctly. This can lead
to spurious compile-time errors.
gcc/ada/
* exp_attr.adb (Expand_N_Attribute_Reference): In the case of a
Reduce attribute reference, fix bugs in initializing Accum_Typ.
The previous version was incorrect in the case where E1 refers to
the first of multiple possible overload resolution candidates and
that candidate does not turn out to be the right one. The previous
version also had code to compute Accum_Typ via a different method
if the initial computation turned out to yield a universal numeric
type. Delete that initial computation and use the second method in
all cases.
Gary Dismukes [Wed, 15 Nov 2023 23:57:47 +0000 (23:57 +0000)]
ada: Errors on instance of Multiway_Trees with discriminated type
The compiler may report various type conflicts on an instantiation
of the generic package Ada.Containers.Multiway_Trees with an actual
for Element_Type that is a nonprivate actual type with discriminants
that has a discriminant-dependent component of a private type (such
as a Bounded_Vector type). The type errors occur on an aggregate
of the implementation type Tree_Node_Type within the body of
Multiway_Trees, where the aggregate has a box-defaulted association
for the Element component. (Such type errors could of course arise
in other cases of generic instantiations that follow a similar type
model.)
In the case where the discriminant-dependent component type has a
default-initialization procedure (init proc), the compiler was handling
box associations for such components by expanding the topmost box
association into subaggregates that themselves have box associations,
and didn't properly account for discriminant-dependent subcomponents of
private types. This could be fixed internally in Propagate_Discriminants,
but it seems that the entire machinery for dealing with such subcomponent
associations is unnecessary, and the topmost component association can
be handled directly as a default-initialized box association.
gcc/ada/
* sem_aggr.adb (Add_Discriminant_Values): Remove this procedure.
(Propagate_Discriminants): Remove this procedure.
(Resolve_Record_Aggregate): Remove code (the Capture_Discriminants
block statement) related to propagating discriminants and
generating initializations for subcomponents of a
discriminant-dependent box-defaulted subcomponent of a nonprivate
record type with discriminants, and handle all top-level
components that have a non-null base init proc directly, by
calling Add_Association with "Is_Box_Present => True". Also,
combine that elsif clause with the immediately preceding elsif
clause, since they now both contain the same statement (calls to
Add_Association with the same actuals).
Eric Botcazou [Thu, 9 Nov 2023 14:00:56 +0000 (15:00 +0100)]
ada: Further cleanup in finalization machinery
When transient scopes are being materialized, they can give rise to a block
created around the construct being wrapped or not, depending on the kind of
construct. In both cases finalization actions for the transient objects of
the scope are generated the same way, with normal finalization done manually
immediately after the construct and exceptional finalization deferred to the
enclosing scope by means of a hooking mechanism.
Now when the block is generated, it becomes this enclosing scope, so the
normal finalization that comes with it would also be done immediately after
the construct, even without normal finalization generated manually.
Therefore this change gets rid of the manual finalization as well as of the
hooking in the cases where the block is generated, leading to a significant
streamlining of the expanded code in these cases. This requires fixing a
small inaccuracy of the Within_Case_Or_If_Expression predicate, which must
only be concerned with the dependent expressions, since those are the only
ones to be treated specially by the finalization machinery.
It also contains a small cleanup for the description of the transient scope
management present at the beginning of the exp_ch7.adb file.
gcc/ada/
* exp_ch7.ads (Expand_Cleanup_Actions): Move declaration to the
Finalization Management section.
* exp_ch7.adb (Transient Scope Management): Move description down to
after that of the general finalization and make a few changes.
(Insert_Actions_In_Scope_Around): Call Process_Transients_In_Scope
only if cleanups are being handled.
(Process_Transients_In_Scope): Remove redundant test on Clean.
* exp_util.ads (Within_Case_Or_If_Expression): Adjust description.
* exp_util.adb (Within_Case_Or_If_Expression): Only return true if
within the dependent expressions of the conditional expressions.
Eric Botcazou [Wed, 8 Nov 2023 22:29:01 +0000 (23:29 +0100)]
ada: Fix premature finalization for nested return within extended one
The return object is incorrectly finalized when the nested return is taken,
because the special flag attached to the return object is not updated.
gcc/ada/
* exp_ch6.adb (Build_Flag_For_Function): New function made up of the
code building the special flag for return object present...
(Expand_N_Extended_Return_Statement): ...in there. Replace the code
with a call to Build_Flag_For_Function. Add assertion for the flag.
(Expand_Non_Function_Return): For a nested return, if the return
object needs finalization actions, update the special flag.
When emitting code for architectures with tagged pointers, it is useful
to be able to recognize values representing addresses because they
require special handling. This commits adds the predicate
Is_Address_Compatible_Type, which differs from the node attribute
Is_Descendant_Of_Address by also taking Standard_Address into account.
gcc/ada/
* einfo-utils.ads, einfo-utils.adb (Is_Address_Compatible_Type):
New function.
Gary Dismukes [Tue, 7 Nov 2023 22:16:31 +0000 (22:16 +0000)]
ada: Type error on container aggregate with loop_parameter_specification
The compiler incorrectly reported a type error on a container aggregate
for a Vector type with a loop_parameter_specification specifying a
nonstatic upper bound, complaining that it expected the Vector index
type, but instead found type Count_Type. The expansion of the aggregate
was incorrectly passing a size temporary of type Count_Type to the
function associated with the New_Indexed part of the container type's
Aggregate aspect (New_Vector in the case of Vectors), which has two
formals of the container index type. The fix is to convert the size
temporary to the expected index type.
gcc/ada/
* exp_aggr.adb (Expand_Container_Aggregate): Apply a conversion to the
size temp object passed as the second actual parameter on the call to
the New_Indexed_Subp function, to convert it to the index type of the
container type (taken from the first formal parameter of the function).
Eric Botcazou [Mon, 6 Nov 2023 22:34:20 +0000 (23:34 +0100)]
ada: Fix internal error on declare expression in expression function
When the expression function is not a completion, its (return) expression
does not cause freezing so analyzing the declare expression in this context
must not freeze the type of the object.
The change also contains another fix, which makes it so that the compiler
does not evaluate a nonstatic representation attribute of a scalar subtype
in the same context if the subtype is not already frozen.
gcc/ada/
* sem_attr.adb (Eval_Attribute): Do not proceed in a spec expression
for nonstatic representation attributes of a scalar subtype when the
subtype is not frozen.
* sem_ch3.adb (Analyze_Object_Declaration): Do not freeze the type
of the object in a spec expression.
Yannick Moy [Fri, 3 Nov 2023 13:49:30 +0000 (14:49 +0100)]
ada: Remove dependency on System.Val_Bool in System.Img_Bool
In order to facilitate the certification of System.Img_Bool, remove
its dependency on unit System.Val_Bool. Modify the definition of
ghost function Is_Boolean_Image_Ghost to take the expected boolean
value and move it to System.Val_Spec.
gcc/ada/
* libgnat/s-imgboo.adb: Remove with_clause now in spec file.
* libgnat/s-imgboo.ads: Remove dependency on System.Val_Bool.
(Image_Boolean): Replace call to Value_Boolean by passing value V
to updated ghost function Is_Boolean_Image_Ghost.
* libgnat/s-valboo.ads (Is_Boolean_Image_Ghost): Move to other
unit.
(Value_Boolean.): Update precondition.
* libgnat/s-valspe.ads (Is_Boolean_Image_Ghost): Move here. Add
new parameter for expected boolean value.
Tucker Taft [Sat, 4 Nov 2023 13:53:28 +0000 (13:53 +0000)]
ada: Fix predicate failure that occurred in a test case
The CodePeer test case illustrating a problem where a "high"
precondition failure was expected, died in the GNAT FE on
input_reading.adb. The problem was in Check_SCIL, where
it didn't properly handle a discriminant_specification.
Jakub Jelinek [Tue, 28 Nov 2023 09:16:47 +0000 (10:16 +0100)]
testsuite: Fix up pr111754.c test
On Tue, Nov 28, 2023 at 03:56:47PM +0800, juzhe.zhong@rivai.ai wrote:
> Hi, there is a regression in RISC-V caused by this patch:
>
> FAIL: gcc.dg/vect/pr111754.c -flto -ffat-lto-objects scan-tree-dump optimized "return { 0.0, 9.0e\\+0, 0.0, 0.0 }"
> FAIL: gcc.dg/vect/pr111754.c scan-tree-dump optimized "return { 0.0, 9.0e\\+0, 0.0, 0.0 }"
>
> I have checked the dump is :
> F foo (F a, F b)
> {
> <bb 2> [local count: 1073741824]:
> <retval> = { 0.0, 9.0e+0, 0.0, 0.0 };
> return <retval>;
>
> }
>
> The dump IR seems reasonable to me.
> I wonder whether we should walk around in RISC-V backend to generate the same IR as ARM SVE ?
> Or we should adjust the test ?
Note, the test also FAILs on i686-linux (but not e.g. on x86_64-linux):
/home/jakub/src/gcc/obj67/gcc/xgcc -B/home/jakub/src/gcc/obj67/gcc/ /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c -fdiagnostics-plain-output -O2 -fdump-tree-optimized -S
+-o pr111754.s
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c: In function 'foo':
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:7:1: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:6:3: note: the ABI for passing parameters with 16-byte alignment has changed in GCC 4.6
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:6:3: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi]
FAIL: gcc.dg/vect/pr111754.c (test for excess errors)
Excess errors:
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:7:1: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr111754.c:6:3: warning: SSE vector argument without SSE enabled changes the ABI [-Wpsabi]
So, I think it is wrong to specify
/* { dg-options "-O2 -fdump-tree-optimized" } */
in the test, should be dg-additional-options instead, so that it gets
the implied vector compilation options e.g. for i686-linux (-msse2 in that
case at least), question is if -Wno-psabi should be added as well or not,
and certainly the scan-tree-dump needs to be guarded by appropriate
vect_* effective target (but dunno which, one which asserts support for
V4SFmode and returning it).
Alternatively, perhaps don't check optimized dump but some earlier one
before generic vector lowering, then hopefully it could match on all
targets? Maybe with the <retval> = ... vs. return ... variants.
2023-11-28 Jakub Jelinek <jakub@redhat.com>
PR middle-end/111754
* gcc.dg/vect/pr111754.c: Use dg-additional-options rather than
dg-options, add -Wno-psabi and use -fdump-tree-forwprop1 rather than
-fdump-tree-optimized. Scan forwprop1 dump rather than optimized and
scan for either direct return or setting of <retval> to the vector.
When looking around, I've noticed we have a similar simplification
for parity (with ^ rather than +). Note, unlike the popcount one,
this one doesn't check for INTEGRAL_TYPE_P (type) (which rules out
vector simplification), so I've used the old handling for types_match and
otherwise do it only for scalar argument types and handle different
precision in there.
The testcase ICEs without the previous patch on the first function,
but strangely not on the second which tests parity. The reason
is that in this case there is no wi::bit_and test like for popcount
and for BITINT_TYPEs build_call_internal actually refuses to create it
and thus the whole simplification fails. While
.{CLZ,CTZ,CLRSB,FFS,POPCOUNT,PARITY} ifns are direct optab ifns for
normal integer and vector types (and thus it is desirable to punt if
there is no supported optab for them), they have this large/huge _BitInt
extension before bitint lowering, so the patch also adjusts
build_call_internal to allow that case.
2023-11-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/112719
* match.pd (parity(X)^parity(Y) -> parity(X^Y)): Handle case of
mismatched types.
* gimple-match-exports.cc (build_call_internal): Add special-case for
bit query ifns on large/huge BITINT_TYPE before bitint lowering.
Since my PR112566 r14-5557 changes the following testcase ICEs, because
.POPCOUNT (x) + .POPCOUNT (y) has a simplification attempted even when
x and y have incompatible types (different precisions).
Note, with _BitInt it can ICE already starting with r14-5435 and
I think as a latent problem it exists for years, because IFN_POPCOUNT
calls inherently can have different argument types and return type
is always the same.
The following patch fixes it by using widest_int during the analysis
(which is where it was ICEing) and if it is optimizable, casting to
the wider type so that bit_ior has matching argument types.
2023-11-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/112719
* match.pd (popcount (X) + popcount (Y) -> POPCOUNT (X | Y)): Deal
with argument types with different precisions.
Lewis Hyatt [Mon, 27 Nov 2023 17:08:41 +0000 (12:08 -0500)]
libcpp: Fix unsigned promotion for unevaluated divide by zero [PR112701]
When libcpp encounters a divide by zero while processing a constant
expression "x/y", it returns "x" as a fallback. The value of the fallback is
not normally important, since an error will be generated anyway, but if the
expression appears in an unevaluated context, such as "0 ? 0/0u : -1", then
there will be no error, and the fallback value will be meaningful to the
extent that it may cause promotion from signed to unsigned of an operand
encountered later. As the PR notes, libcpp does not do the unsigned
promotion correctly in this case; fix it by making the fallback return value
unsigned as necessary.
libcpp/ChangeLog:
PR preprocessor/112701
* expr.cc (num_div_op): Set unsignedp appropriately when returning a
stub value for divide by 0.
gcc/testsuite/ChangeLog:
PR preprocessor/112701
* gcc.dg/cpp/expr.c: Add additional tests to cover divide by 0 in an
unevaluated context, where the unsignedness still matters.
Juzhe-Zhong [Mon, 27 Nov 2023 13:24:12 +0000 (21:24 +0800)]
RISC-V: Fix VSETVL PASS regression
This patch is regression fix patch, not an optimization patch.
Since trunk GCC generates redundant vsetvl than GCC-13.
This is the case:
bb 2:
def a2 (vsetvl a2, zero)
bb 3:
use a2
bb 4:
use a2 (vle)
before this patch:
bb 2:
vsetvl a2 zero
bb 3:
vsetvl zero, zero ----> should be eliminated.
bb 4:
vle.v
The root cause is we didn't set bb 3 as transparent since the incorrect codes.
bb 3 didn't modify "a2" just use it, the VSETVL status from bb 2 can be available to bb 3 and bb 4:
bb 2 -> bb 3 -> bb4.
Another regression fix is anticipation calculation:
bb 4:
use a5 (sub)
use a5 (vle)
The vle VSETVL status should be considered as anticipated as long as both sub and vle a5 def are coming from same def.
David Malcolm [Tue, 28 Nov 2023 01:09:35 +0000 (20:09 -0500)]
diagnostics: don't print annotation lines when there's no column info
gcc/ChangeLog:
* diagnostic-show-locus.cc (layout::maybe_add_location_range):
Don't print annotation lines for ranges when there's no column
info.
(selftest::test_one_liner_no_column): New.
(selftest::test_diagnostic_show_locus_one_liner): Call it.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
projects / thirdparty / gcc.git / log
