The test case for PR97969 needs updates in order to comply with recent
changes in GCC14. Without these changes, failures like this can be seen
on arm-none-eabi:
.../pr97969.c:6:9: error: type defaults to 'int' in declaration of 'a' [-Wimplicit-int]
.../pr97969.c:34:1: error: return type defaults to 'int' [-Wimplicit-int]
.../pr97969.c:40:3: error: implicit declaration of function 'ae' [-Wimplicit-function-declaration]
.../pr97969.c:42:3: error: implicit declaration of function 'af' [-Wimplicit-function-declaration]
.../pr97969.c:43:7: error: implicit declaration of function 'ag' [-Wimplicit-function-declaration]
.../pr97969.c:46:10: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
.../pr97969.c:48:10: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
.../pr97969.c:50:8: error: implicit declaration of function 'setjmp' [-Wimplicit-function-declaration]
.../pr97969.c:51:5: error: implicit declaration of function 'ah' [-Wimplicit-function-declaration]
.../pr97969.c:52:5: error: implicit declaration of function 'ai' [-Wimplicit-function-declaration]
.../pr97969.c:54:5: error: implicit declaration of function 'aj' [-Wimplicit-function-declaration]
Patch has been verified on Linux.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr97969.c: Update to comply with GCC14 changes.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
See PR90698. On Xcode 15, the tests currently lead to a segfault of the
clang assembler.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr113689-1.c: Skip test on darwin.
* gcc.target/i386/pr113689-2.c: Likewise.
* gcc.target/i386/pr113689-3.c: Likewise.
Since my r11-532 changes to implement DR2237, for this test:
template<typename T>
struct S {
S<T>();
};
in C++20 we emit the ugly:
q.C:3:8: error: expected unqualified-id before ')' token
3 | S<T>();
which doesn't explain what the problem is. This patch improves that
diagnostic, reduces the error to a pedwarn, and adds a -Wc++20-compat
diagnostic. We now say:
q.C:3:7: warning: template-id not allowed for constructor in C++20 [-Wtemplate-id-cdtor]
3 | S<T>();
q.C:3:7: note: remove the '< >'
This patch also fixes
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97202#c8>
where the C++20 diagnostic was missing altogether: The problem was that I checked
for CPP_TEMPLATE_ID too early, at a point at which cp_parser_template_id may not
have been called yet. So let's check for it at the end of the function, after
the tentative parse and rollback.
-Wc++20-compat triggered in libitm/; I sent a patch for that.
DR 2237
PR c++/107126
PR c++/97202
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): In C++20 or with -Wc++20-compat,
turn on -Wtemplate-id-cdtor.
* c.opt (Wtemplate-id-cdtor): New.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_unqualified_id): Downgrade the DR2237 error to
a pedwarn.
(cp_parser_constructor_declarator_p): Likewise.
gcc/ChangeLog:
* doc/invoke.texi: Document -Wtemplate-id-cdtor.
gcc/testsuite/ChangeLog:
* g++.dg/DRs/dr2237.C: Adjust dg-error.
* g++.dg/parse/constructor2.C: Likewise.
* g++.dg/template/error34.C: Likewise.
* g++.old-deja/g++.pt/ctor2.C: Likewise.
* g++.dg/DRs/dr2237-2.C: New test.
* g++.dg/DRs/dr2237-3.C: New test.
* g++.dg/DRs/dr2237-4.C: New test.
* g++.dg/DRs/dr2237-5.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-1.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-2.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-3.C: New test.
* g++.dg/warn/Wtemplate-id-cdtor-4.C: New test.
torture/bitint-37.c test FAILed on i686-linux e.g. on
signed _BitInt(575) + unsigned _BitInt(575) -> signed _BitInt(575)
__builtin_add_overflow. With 64-bit limbs, we use 4 .UADDC calls in
the IL, 2 in a loop (which handles the first 8 limbs), then one partial
limb (we use 63 bits from that) and finally last_ovf case due to the
mixing of signed vs. unsigned.
But with 32-bit limbs, we use 5 .UADDC calls in the IL, 2 in a loop (which
handles the first 16 limbs), then one full limb above that, one partial
(31 bits) and finally last_ovf case, and for the last_ovf case the code
computed incorrect idx and so partly did the wrong thing, e.g. overwrote
the result from the previous .UADDC.
Fixed thusly.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
* gimple-lower-bitint.cc (itint_large_huge::lower_addsub_overflow): Fix
computation of idx for i == 4 of bitint_prec_huge.
The ia32 _BitInt support revealed a bug in floatbitint?d.c.
As can be even guessed from how the code is written in the loop,
the intention was to set inexact to non-zero whenever the remainder
after division wasn't zero, but I've ended up just checking whether
the 2 least significant limbs of the remainder were non-zero.
Now, in the dfp/bitint-4.c test in one case the remainder happens
to have least significant 64 bits zero and then the higher limbs are
non-zero; with 32-bit limbs that means 2 least significant limbs are zero
and so the code acted as if it was exactly divisible.
Fixed thusly.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
* soft-fp/floatbitintdd.c (__bid_floatbitintdd): Or in all remainder
limbs into inexact rather than just first two.
* soft-fp/floatbitintsd.c (__bid_floatbitintsd): Likewise.
* soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise.
I've tried last night to enable _BitInt support for i?86-linux, and
a few spots in libgcc emitted -Wshift-count-overflow warnings and clearly
didn't do what it was supposed to do.
Fixed thusly.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
* soft-fp/fixddbitint.c (__bid_fixddbitint): Fix up
BIL_TYPE_SIZE == 32 shifts.
* soft-fp/fixsdbitint.c (__bid_fixsdbitint): Likewise.
* soft-fp/fixtdbitint.c (__bid_fixtdbitint): Likewise.
* soft-fp/floatbitintdd.c (__bid_floatbitintdd): Likewise.
* soft-fp/floatbitinttd.c (__bid_floatbitinttd): Likewise.
As the following testcases show, the gimple-low outlining of assume
magic functions handled volatile automatic vars (including
parameters/results) like non-volatile ones except it copied volatile
to the new PARM_DECL, which has the undesirable effect that a load
from the volatile var is passed to IFN_ASSUME and so there is a
side-effect there even when side-effects of the assume attribute
shouldn't be evaluated.
The following patch fixes that by passing address of the volatile
variables/parameters/results instead and doing loads or stores from it
or to it where it was originally accessed in the assume attribute
expression.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
PR middle-end/110754
* gimple-low.cc (assumption_copy_decl): For TREE_THIS_VOLATILE
decls create PARM_DECL with pointer to original type, set
TREE_READONLY and keep TREE_THIS_VOLATILE, TREE_ADDRESSABLE,
DECL_NOT_GIMPLE_REG_P and DECL_BY_REFERENCE cleared.
(adjust_assumption_stmt_op): For remapped TREE_THIS_VOLATILE decls
wrap PARM_DECL into a simple TREE_THIS_NO_TRAP MEM_REF.
(lower_assumption): For TREE_THIS_VOLATILE vars pass ADDR_EXPR
of the var as argument.
* gcc.dg/attr-assume-6.c: New test.
* g++.dg/cpp23/attr-assume12.C: New test.
In the previous patch I haven't touched the gcc diagnostic routines,
using HOST_SIZE_T_PRINT* for those is obviously undesirable because we
want the strings to be translatable. We already have %w[diox] for
HOST_WIDE_INT arguments, this patch adds t and z modifiers for those.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
gcc/
* pretty-print.cc (pp_integer_with_precision): Handle precision 3 for
size_t and precision 4 for ptrdiff_t. Formatting fix.
(pp_format): Document %{t,z}{d,i,u,o,x}. Implement t and z modifiers.
Formatting fixes.
(test_pp_format): Test t and z modifiers.
* gcc.cc (read_specs): Use %td instead of %ld and casts to long.
gcc/c-family/
* c-format.cc (gcc_diag_length_specs): Add t and z modifiers.
(PP_FORMAT_CHAR_TABLE, gcc_gfc_char_table): Add entries for t and
z modifiers.
gcc/fortran/
* error.cc (error_print): Handle z and t modifiers on d, i and u.
* check.cc (gfc_check_transfer): Use %zd instead of %ld and casts to
long.
* primary.cc (gfc_convert_to_structure_constructor): Use %td instead
of %ld and casts to long.
I went through suspicios %l in format strings of *printf family functions
combined with casts to (long) or (unsigned long) and tried to find out the
types of the original expressions that were cast.
Quite a few had size_t type, so I've used the new HOST_SIZE_T_PRINT_*
macros together with cast to fmt_size_t for those, and then there were
quite a few HOST_WIDE_INTs cast to long, used HOST_WIDE_INT_PRINT_* for
those without casts. There was one case of a weird unsigned int variable
used with %lu and (long) cast too.
2024-02-10 Jakub Jelinek <jakub@redhat.com>
gcc/
* ipa-icf.cc (sem_item_optimizer::process_cong_reduction,
sem_item_optimizer::dump_cong_classes): Use HOST_SIZE_T_PRINT_UNSIGNED
and casts to fmt_size_t instead of "%lu" and casts to unsigned long.
* tree.cc (print_debug_expr_statistics): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
(print_value_expr_statistics, print_type_hash_statistics): Likewise.
* dwarf2out.cc (output_macinfo_op): Use HOST_WIDE_INT_PRINT_UNSIGNED
instead of "%lu" and casts to unsigned long.
* gcov-dump.cc (dump_gcov_file): Use %u instead of %lu and casts to
unsigned long.
* tree-ssa-dom.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
* cfgexpand.cc (dump_stack_var_partition): Use
HOST_SIZE_T_PRINT_UNSIGNED and casts to fmt_size_t instead of "%lu"
and casts to unsigned long.
* gengtype.cc (adjust_field_rtx_def): Likewise.
* tree-into-ssa.cc (htab_statistics): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
* postreload-gcse.cc (dump_hash_table): Likewise.
* ggc-page.cc (alloc_page): Use HOST_SIZE_T_PRINT_UNSIGNED
and casts to fmt_size_t instead of "%lu" and casts to unsigned long.
(ggc_internal_alloc, ggc_free): Likewise.
* genpreds.cc (write_lookup_constraint_1): Likewise.
(write_insn_constraint_len): Likewise.
* tree-dfa.cc (dump_dfa_stats): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
* varasm.cc (output_constant_pool_contents): Use
HOST_WIDE_INT_PRINT_DEC instead of "%ld" and casts to long.
* var-tracking.cc (dump_var): Likewise.
gcc/c-family/
* c-ada-spec.cc (dump_template_types): Use HOST_SIZE_T_PRINT_UNSIGNED
and casts to fmt_size_t instead of "%lu" and casts to unsigned long.
gcc/c/
* c-decl.cc (get_parm_array_spec): Use HOST_WIDE_INT_PRINT_UNSIGNED
instead of "%lu" and casts to unsigned long or unsigned long long.
gcc/cp/
* tree.cc (debug_binfo): Use HOST_WIDE_INT_PRINT_DEC instead of "%ld"
and casts to long.
* pt.cc (print_template_statistics): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
* class.cc (dump_class_hierarchy_1): Use HOST_WIDE_INT_PRINT_UNSIGNED
instead of "%lu" and casts to unsigned long. For TYPE_ALIGN, use
%u instead of %lu and drop casts to unsigned long.
* parser.cc (cp_lexer_peek_nth_token): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long.
gcc/fortran/
* trans-common.cc (build_common_decl): Use %wu instead of %lu and
casts to unsigned long.
* resolve.cc (resolve_ordinary_assign): Use %wd instead of %ld and
casts to long.
* array.cc (gfc_resolve_character_array_constructor): Likewise.
* data.cc (create_character_initializer): Likewise.
gcc/jit/
* jit-playback.cc (new_bitcast): Use HOST_WIDE_INT_PRINT_DEC instead
of "%ld" and casts to long.
gcc/lto/
* lto-common.cc (print_lto_report_1): Use HOST_SIZE_T_PRINT_DEC
and casts to fmt_size_t instead of "%ld" and casts to long. Use
%d instead of %ld and casts to long for searches and collisions.
Test-cases, with constexpr-reinterpret3.C dg-ice:ing the PR c++/113545 bug.
Regarding the request in the comment, A dg-do run when there's an ICE
will cause some CI's to signal an error for the run being "UNRESOLVED"
(compilation failed to produce executable). Note that dejagnu (1.6.3)
itself doesn't consider this an error.
gcc/testsuite:
PR c++/113545
* g++.dg/cpp1y/constexpr-reinterpret3.C,
g++.dg/cpp1y/constexpr-reinterpret4.C: New tests.
Re-write address arithmetic in gm2-libs/SArgs.mod:GetArg
to avoid (void *) computation. mc treats ADDRESS as (char *)
but does not cast user type (PtrToChar) to (char *) when
performing address arithmetic.
gcc/m2/ChangeLog:
PR modula2/113848
* gm2-libs/SArgs.mod (GetArg): Re-write address arithmetic
to avoid (void *) computation.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
Here we crash on this invalid code because we seem to infinitely recurse
and end up with __type_pack_element with index that doesn't tree_fits_shwi_p
which then crashes on tree_to_shwi.
Thanks to Jakub for suggesting a nicer fix than my original one.
PR c++/113834
gcc/cp/ChangeLog:
* semantics.cc (finish_type_pack_element): Perform range checking
before tree_to_shwi.
gcc/testsuite/ChangeLog:
* g++.dg/ext/type_pack_element4.C: New test.
Here the problem is that we give hard errors while substituting
template parameters during overload resolution of is_throwable
which has an invalid throw in decltype.
The backtrace shows that fn_type_unification -> instantiate_template
-> tsubst* passes complain=0 as expected, but build_throw doesn't
have a complain parameter. So let's add one. Also remove a redundant
local variable which I should have removed in my P2266 patch.
There's still one problem for which I opened <https://gcc.gnu.org/PR113853>.
We need to patch up treat_lvalue_as_rvalue_p and remove the dg-bogus.
Thanks to Patrick for notifying me of this PR. This doesn't fully fix
113789; there I think I'll have to figure our why a candidate wasn't
discarded from the overload set.
PR c++/98388
gcc/cp/ChangeLog:
* coroutines.cc (coro_rewrite_function_body): Pass tf_warning_or_error
to build_throw.
(morph_fn_to_coro): Likewise.
* cp-tree.h (build_throw): Adjust.
* except.cc (expand_end_catch_block): Pass tf_warning_or_error to
build_throw.
(build_throw): Add a tsubst_flags_t parameter. Use it. Remove
redundant variable. Guard an inform call.
* parser.cc (cp_parser_throw_expression): Pass tf_warning_or_error
to build_throw.
* pt.cc (tsubst_expr) <case THROW_EXPR>: Pass complain to build_throw.
libcc1/ChangeLog:
* libcp1plugin.cc (plugin_build_unary_expr): Pass tf_error to
build_throw.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/sfinae69.C: New test.
PR fortran/113799
gcc/fortran/ChangeLog:
* arith.cc (reduce_unary): Remember any overflow encountered during
reduction of unary arithmetic operations on array constructors and
continue, and return error status, but terminate on serious errors.
gcc/testsuite/ChangeLog:
* gfortran.dg/arithmetic_overflow_2.f90: New test.
Since is_same has a fallback native implementation, and
_GLIBCXX_HAVE_BUILTIN_IS_SAME does not support toggling which
implementation to use, we remove the _GLIBCXX_HAVE_BUILTIN_IS_SAME
definition and use _GLIBCXX_USE_BUILTIN_TRAIT instead.
libstdc++-v3/ChangeLog:
* include/bits/c++config (_GLIBCXX_HAVE_BUILTIN_IS_SAME):
Removed.
* include/std/type_traits (is_same): Use
_GLIBCXX_USE_BUILTIN_TRAIT instead of
_GLIBCXX_HAVE_BUILTIN_IS_SAME.
(is_same_v): Likewise.
Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Here when streaming in the fields of the as-base version of
_Formatting_scanner<int> we end up overwriting ANON_AGGR_TYPE_FIELD
of the anonymous union type, since it turns out this type is shared
between the original FIELD_DECL and the as-base FIELD_DECL copy (copied
during layout_class_type). ANON_AGGR_TYPE_FIELD first gets properly set
to the original FIELD_DECL when streaming in the canonical definition of
_Formatting_scanner<int>, and then gets overwritten to the as-base
FIELD_DECL when streaming in the the as-base definition. This leads to
lookup_anon_field later giving the wrong answer when resolving the
_M_values use at instantiation time.
This patch makes us avoid overwriting ANON_AGGR_TYPE_FIELD when streaming
in an as-base class definition; it should already be properly set at that
point.
PR c++/112580
gcc/cp/ChangeLog:
* module.cc (trees_in::read_class_def): When streaming in
an anonymous union field of an as-base class, don't overwrite
ANON_AGGR_TYPE_FIELD.
gcc/testsuite/ChangeLog:
* g++.dg/modules/anon-3_a.H: New test.
* g++.dg/modules/anon-3_b.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
On the following testcases memcpy lowering folds the calls to
reading and writing of MEM_REFs with huge INTEGER_TYPEs - uint256_t
with OImode or uint512_t with XImode. Further optimization turn
the load from MEM_REF from the large/huge _BitInt var into VIEW_CONVERT_EXPR
from it to the uint256_t/uint512_t. The backend doesn't really
support those except for "movoi"/"movxi" insns, so it isn't possible
to handle it like casts to supportable INTEGER_TYPEs where we can
construct those from individual limbs - there are no OImode/XImode shifts
and the like we can use.
So, the following patch makes sure for such VCEs that the SSA_NAME operand
of the VCE lives in memory and then turns it into a VIEW_CONVERT_EXPR so
that we actually load the OImode/XImode integer from memory (i.e. a mov).
We need to make sure those aren't merged with other
operations in the gimple_lower_bitint hunks.
For SSA_NAMEs which have underlying VAR_DECLs that is all we need, those
VAR_DECL have ARRAY_TYPEs.
For SSA_NAMEs which have underlying PARM_DECLs or RESULT_DECLs those have
BITINT_TYPE and I had to tweak expand_expr_real_1 for that so that it
doesn't try convert_modes on those when one of the modes is BLKmode - we
want to fall through into the adjust_address on the MEM.
2024-02-09 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113783
* gimple-lower-bitint.cc (bitint_large_huge::lower_stmt): Look
through VIEW_CONVERT_EXPR for final cast checks. Handle
VIEW_CONVERT_EXPRs from large/huge _BitInt to > MAX_FIXED_MODE_SIZE
INTEGER_TYPEs.
(gimple_lower_bitint): Don't merge mergeable operations or other
casts with VIEW_CONVERT_EXPRs to > MAX_FIXED_MODE_SIZE INTEGER_TYPEs.
* expr.cc (expand_expr_real_1): Don't use convert_modes if either
mode is BLKmode.
* gcc.dg/bitint-88.c: New test.
build_conflict_bit_table uses %ld format string for
(long) some_int_expression * sizeof (something)
argument, that doesn't work on LLP64 hosts because the
expression has then size_t aka unsigned long long type there.
It can be fixed with
(long) (some_int_expression * sizeof (something))
but it means the value is truncated if it doesn't fit into long.
Ideally we'd use %zd or %zu modifiers here, but it is unclear if we
can rely on it on all hosts, it has been introduced in C99 and C++11
includes C99 by reference, but in reality whether this works or not
depends on the host C library and some of them are helplessly obsolete.
This patch instead introduces new macros HOST_SIZE_T_PRINT_* which
one can use in *printf family function format strings and cast to
fmt_size_t type.
2024-02-09 Jakub Jelinek <jakub@redhat.com>
* hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRINT_DEC,
HOST_SIZE_T_PRINT_UNSIGNED, HOST_SIZE_T_PRINT_HEX,
HOST_SIZE_T_PRINT_HEX_PURE): Define.
* ira-conflicts.cc (build_conflict_bit_table): Use it. Formatting
fixes.
Some exports were missed from the GCC-13 cycle, these are added here
along with the bitint-related ones added in GCC-14.
libgcc/ChangeLog:
* config/i386/libgcc-darwin.ver: Export bf and bitint-related
synbols.
The asm goto expansion ICEs on the following testcase (which normally
is rejected later), because expand_asm_stmt emits the code to copy
the large var out of the out operand to its memory location into
after_rtl_seq ... after_rtl_end sequence and because it is asm goto,
it duplicates the sequence on each successor edge of the asm goto.
The problem is that with -mstringop-strategy=byte_loop that sequence
contains loops, so CODE_LABELs, JUMP_INSNs, with other strategies
could contain CALL_INSNs etc.
But the copying is done using a loop doing
emit_insn (copy_insn (PATTERN (curr)));
which does the right thing solely for INSNs, it will do the wrong thing
for JUMP_INSNs, CALL_INSNs, CODE_LABELs (with RTL checking even ICE on
them), BARRIERs and the like.
The following patch partially fixes it (with the hope that such stuff only
occurs in asms that really can't be accepted; if one uses say "=rm" or
"=g" constraint then the operand uses the memory directly and nothing is
copied) by using the
duplicate_insn_chain function which is used e.g. in RTL loop unrolling and
which can handle JUMP_INSNs, CALL_INSNs, BARRIERs etc.
As it is meant to operate on sequences inside of basic blocks, it doesn't
handle CODE_LABELs (well, it skips them), so if we need a solution that
will be correct at runtime here for those cases, we'd need to do further
work (e.g. still use duplicate_insn_chain, but if we notice any CODE_LABELs,
walk the sequence again, add copies of the CODE_LABELs and then remap
references to the old CODE_LABELs in the copied sequence to the new ones).
Because as is now, if the code in one of the sequence copies (where the
CODE_LABELs have been left out) decides to jump to such a CODE_LABEL, it
will jump to the CODE_LABEL which has been in the original sequence (which
the code emits on the last edge, after all, duplicating the sequence
EDGE_COUNT times and throwing away the original was wasteful, compared to
doing that just EDGE_COUNT - 1 times and using the original.
2024-02-09 Jakub Jelinek <jakub@redhat.com>
PR middle-end/113415
* cfgexpand.cc (expand_asm_stmt): For asm goto, use
duplicate_insn_chain to duplicate after_rtl_seq sequence instead
of hand written loop with emit_insn of copy_insn and emit original
after_rtl_seq on the last edge.
* gcc.target/i386/pr113415.c: New test.
Due to -fnon-call-exceptions the bitint lowering adds new EH edges
in various places, so that the EH edge points from handling (e.g. load or
store) of each of the limbs. The problem is that the EH edge destination
as shown in the testcase can have some PHIs. If it is just a virtual
PHI, no big deal, the pass uses TODO_update_ssa_only_virtuals, but if
it has other PHIs, I think we need to copy the values from the preexisting
corresponding EH edge (which is from the original stmt to the EH pad)
to the newly added EH edge, so that the PHI arguments are the same rather
than missing (which ICEs during checking at the end of the pass).
This patch adds a function to do that and uses it whenever adding EH edges.
2024-02-09 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113818
* gimple-lower-bitint.cc (add_eh_edge): New function.
(bitint_large_huge::handle_load,
bitint_large_huge::lower_mergeable_stmt,
bitint_large_huge::lower_muldiv_stmt): Use it.
* gcc.dg/bitint-89.c: New test.
The following patch is the optimization part of PR113774, where in
handle_cast we emit some conditionals which are always true and presumably
VRP would figure that out later and clean it up, except that instead
thread1 is invoked and threads everything through the conditions, so we end
up with really ugly code which is hard to be cleaned up later and then
run into PR113831 VN bug and miscompile stuff.
handle_cast computes low and high as limb indexes, where idx < low
doesn't need any special treatment, just uses the operand's limb,
idx >= high cases all the bits in the limb are an extension (so, for
unsigned widening cast all those bits are 0, for signed widening cast
all those bits are equal to the in earlier code computed sign mask,
narrowing cast don't trigger this code) and then the idx == low && idx <
high case if it exists need special treatment (some bits are copied, others
extended, or all bits are copied but sign mask needs to be computed).
The code already attempted to optimize away some unneeded casts, in the
first hunk below e.g. for the case like 257 -> 321 bit extension, where
low is 4 and high 5 and we use a loop handling the first 4 limbs (2
iterations) with m_upwards_2limb 4 - no special handling is needed in the
loop, and the special handling is done on the first limb after the loop
and then the last limb after the loop gets the extension only, or
in the second hunk where can emit a single comparison instead of
2 e.g. for the low == high case - that must be a zero extension from
multiple of limb bits, say 192 -> 328, or for the case where we know
the idx == low case happens in the other limb processed in the loop, not
the current one.
But the testcase shows further cases where we always know some of the
comparisons can be folded to true/false, in particular there is
255 -> 257 bit zero extension, so low 3, high 4, m_upwards_2limb 4.
The loop handles 2 limbs at the time and for the first limb we were
emitting idx < low ? operand[idx] : 0; but because idx goes from 0
with step 2 2 iterations, idx < 3 is always true, so we can just
emit operand[idx]. This is handled in the first hunk. In addition
to fixing it (that is the " - m_first" part in there) I've rewritten
it using low to make it more readable.
Similarly, in the other limb we were emitting
idx + 1 <= low ? (idx + 1 == low ? operand[idx] & 0x7ff....ff : operand[idx]) : 0
but idx + 1 <= 3 is always true in the loop, so all we should emit is
idx + 1 == low ? operand[idx] & 0x7ff....ff : operand[idx],
Unfortunately for the latter, when single_comparison is true, we emit
just one comparison, but the code which fills the branches will fill it
with the operand[idx] and 0 cases (for zero extension, for sign extension
similarly), not the operand[idx] (aka copy) and operand[idx] & 0x7ff....ff
(aka most significant limb of the narrower precision) cases. Instead
of making the code less readable by using single_comparison for that and
handling it in the code later differently I've chosen to just emit
a condition which will be always true and let cfg cleanup clean it up.
2024-02-09 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113774
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't
emit any comparison if m_first and low + 1 is equal to
m_upwards_2limb, simplify condition for that. If not
single_comparison, not m_first and we can prove that the idx <= low
comparison will be always true, emit instead of idx <= low
comparison low <= low such that cfg cleanup will optimize it at
the end of the pass.
* gcc.dg/torture/bitint-57.c: New test.
When running the testsuite for newlib nano, the --specs=nano.specs
option is used. This option prepends cpp_unique_options with
"-isystem =/include/newlib-nano" so that the newlib nano header files
override the newlib standard ones. As the -isystem option is prepended,
the -quiet option is no longer the first option to cc1. Adjust the test
accordingly.
Patch has been verified on Windows and Linux.
gcc/testsuite/ChangeLog:
* gcc.misc-tests/options.exp: Allow other options before the
-quite option for cc1.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
There's no need to check for self-assignment here, it would just add
extra code for an unlikely case. Add a comment saying so.
libstdc++-v3/ChangeLog:
PR libstdc++/100147
* include/bits/gslice.h (operator=): Add comment about lack of
self-assignment check.
Adding rvv related flags (i.e. --param=riscv-autovec-preference) to
non vector targets bypassed the dejagnu skip test directive. Change the
target selector to skip if rvv is enabled
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/abi-1.c: change selector
* gcc.target/riscv/rvv/base/pragma-2.c: ditto
* gcc.target/riscv/rvv/base/pragma-3.c: ditto
Signed-off-by: Edwin Lu <ewlu@rivosinc.com>
These non-standard extensions use GCC-specific built-ins. Use
__has_builtin to avoid errors when Clang compiles this header.
See https://github.com/llvm/llvm-project/issues/24289
libstdc++-v3/ChangeLog:
* include/tr2/type_traits (bases, direct_bases): Use
__has_builtin to check if required built-ins are supported.
The v*_fp16_xN_1.c tests on Arm have been unstable since they were
added. This is not a problem with the tests themselves, or even the
patches that were added, but with the testsuite infrastructure. It
turned out that another set of dg- tests for fp16 were corrupting the
cached set of options used by the new tests, leading to running the
tests with incorrect flags.
So the primary goal of this patch is to fix the incorrect internal
caching of the options needed to enable fp16 alternative format on
Arm: the code was storing the result in the same variable that was
being used for neon_fp16 and this was leading to testsuite instability
for tests that were checking for neon with fp16.
But in cleaning this up I also noted that we weren't then applying the
flags correctly having detected what they were, so we also address
that.
I suspect there are still some further issues to address here, since
the framework does not correctly test that the multilibs and startup
code enable alternative format; but this is still an improvement over
what we had before.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp
(check_effective_target_arm_fp16_alternative_ok_nocache): Use
et_arm_fp16_alternative_flags to cache the result. Improve test
for FP16 availability.
(add_options_for_arm_fp16_alternative): Use
et_arm_fp16_alternative_flags.
* g++.dg/ext/arm-fp16/arm-fp16-ops-3.C: Update dg-* flags.
* g++.dg/ext/arm-fp16/arm-fp16-ops-4.C: Likewise.
* gcc.dg/torture/arm-fp16-int-convert-alt.c: Likewise.
* gcc.dg/torture/arm-fp16-ops-3.c: Likewise.
* gcc.dg/torture/arm-fp16-ops-4.c: Likewise.
* gcc.target/arm/fp16-aapcs-3.c: Likewise.
* gcc.target/arm/fp16-aapcs-4.c: Likewise.
* gcc.target/arm/fp16-compile-alt-1.c: Likewise.
* gcc.target/arm/fp16-compile-alt-10.c: Likewise.
* gcc.target/arm/fp16-compile-alt-11.c: Likewise.
* gcc.target/arm/fp16-compile-alt-12.c: Likewise.
* gcc.target/arm/fp16-compile-alt-2.c: Likewise.
* gcc.target/arm/fp16-compile-alt-3.c: Likewise.
* gcc.target/arm/fp16-compile-alt-4.c: Likewise.
* gcc.target/arm/fp16-compile-alt-5.c: Likewise.
* gcc.target/arm/fp16-compile-alt-6.c: Likewise.
* gcc.target/arm/fp16-compile-alt-7.c: Likewise.
* gcc.target/arm/fp16-compile-alt-8.c: Likewise.
* gcc.target/arm/fp16-compile-alt-9.c: Likewise.
* gcc.target/arm/fp16-rounding-alt-1.c: Likewise.
Since template argument coercion happens relative to the most general
template (for a class template at least), during NTTP type CTAD we might
need to consider outer arguments particularly if the CTAD template is from
the current instantiation (and so depends on outer template parameters).
This patch makes do_class_deduction substitute as many levels of outer
template arguments into a CTAD template (from the current instantiation)
as it can take.
PR c++/113649
gcc/cp/ChangeLog:
* pt.cc (do_class_deduction): Add outer_targs parameter.
Substitute outer arguments into the CTAD template.
(do_auto_deduction): Pass outer_targs to do_class_deduction.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class65.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com>
The relation oracle grows the internal vector of SSAs as needed, but
due to an oversight was not growing the basic block vector. This
fixes the oversight.
PR tree-optimization/113735
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr113735.c: New test.
gcc/ChangeLog:
* value-relation.cc (equiv_oracle::add_equiv_to_block): Call
limit_check().
Some information was (re-)computed in different places.
This patch computes them in new struct McuInfo and passes
it around in order to provide the information.
gcc/
* config/avr/gen-avr-mmcu-specs.cc (struct McuInfo): New.
(main, print_mcu, diagnose_mrodata_in_ram): Pass it down.
1. The only supported TLS code sequence with ADD is
addq foo@gottpoff(%rip),%reg
Change je constraint to a memory operand in APX NDD ADD pattern with
register source operand.
2. The instruction length of APX NDD instructions with immediate operand:
op imm, mem, reg
may exceed the size limit of 15 byes when non-default address space,
segment register or address size prefix are used.
Add jM constraint which is a memory operand valid for APX NDD instructions
with immediate operand and add jO constraint which is an offsetable memory
operand valid for APX NDD instructions with immediate operand. Update
APX NDD patterns with jM and jO constraints.
gcc/
PR target/113711
PR target/113733
* config/i386/constraints.md: List all constraints with j prefix.
(j>): Change auto-dec to auto-inc in documentation.
(je): Changed to a memory constraint with APX NDD TLS operand
check.
(jM): New memory constraint for APX NDD instructions.
(jO): Likewise.
* config/i386/i386-protos.h (x86_poff_operand_p): Removed.
* config/i386/i386.cc (x86_poff_operand_p): Likewise.
* config/i386/i386.md (*add<dwi>3_doubleword): Use rjO.
(*add<mode>_1[SWI48]): Use je and jM.
(addsi_1_zext): Use jM.
(*addv<dwi>4_doubleword_1[DWI]): Likewise.
(*sub<mode>_1[SWI]): Use jM.
(@add<mode>3_cc_overflow_1[SWI]): Likewise.
(*add<dwi>3_doubleword_cc_overflow_1): Use rjO.
(*and<dwi>3_doubleword): Likewise.
(*anddi_1): Use jM.
(*andsi_1_zext): Likewise.
(*and<mode>_1[SWI24]): Likewise.
(*<code><dwi>3_doubleword[any_or]): Use rjO
(*code<mode>_1[any_or SWI248]): Use jM.
(*<code>si_1_zext[zero_extend + any_or]): Likewise.
* config/i386/predicates.md (apx_ndd_memory_operand): New.
(apx_ndd_add_memory_operand): Likewise.
gcc/testsuite/
PR target/113711
PR target/113733
* gcc.target/i386/apx-ndd-2.c: New test.
* gcc.target/i386/apx-ndd-base-index-1.c: Likewise.
* gcc.target/i386/apx-ndd-no-seg-global-1.c: Likewise.
* gcc.target/i386/apx-ndd-seg-1.c: Likewise.
* gcc.target/i386/apx-ndd-seg-2.c: Likewise.
* gcc.target/i386/apx-ndd-seg-3.c: Likewise.
* gcc.target/i386/apx-ndd-seg-4.c: Likewise.
* gcc.target/i386/apx-ndd-seg-5.c: Likewise.
* gcc.target/i386/apx-ndd-tls-1a.c: Likewise.
* gcc.target/i386/apx-ndd-tls-2.c: Likewise.
* gcc.target/i386/apx-ndd-tls-3.c: Likewise.
* gcc.target/i386/apx-ndd-tls-4.c: Likewise.
* gcc.target/i386/apx-ndd-x32-1.c: Likewise.
Rename pr to lowercase and drop lastprivate.
gcc/testsuite/ChangeLog:
PR tree-optimization/113808
* gfortran.dg/vect/vect-early-break_1-PR113808.f90: Moved to...
* gfortran.dg/vect/vect-early-break_1-pr113808.f90: ...here.
There's a bug in vectorizable_live_operation that restart_loop is defined
outside the loop.
This variable is supposed to indicate whether we are doing a first or last
index reduction. The problem is that by defining it outside the loop it becomes
dependent on the order we visit the USE/DEFs.
In the given example, the loop isn't PEELED, but we visit the early exit uses
first. This then sets the boolean to true and it can't get to false again.
So when we visit the main exit we still treat it as an early exit for that
SSA name.
This cleans it up and renames the variables to something that's hopefully
clearer to their intention.
gcc/ChangeLog:
PR tree-optimization/113808
* tree-vect-loop.cc (vectorizable_live_operation): Don't cache the
value cross iterations.
gcc/testsuite/ChangeLog:
PR tree-optimization/113808
* gfortran.dg/vect/vect-early-break_1-PR113808.f90: New test.
I've reconsidered my last change to dr_may_alias_p and decided
it was correct before. The following reverts that change.
* tree-vect-data-refs.cc (vect_analyze_early_break_dependences):
Revert last change to dr_may_alias_p.
I had missed a conversion from unsigned long to uint64_t.
This fixes the failing test on -m32.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-early-break_110-pr113467.c: Change unsigned long *
to uint64_t *.
There is another corn case when similar as below example:
void test (void)
{
__riscv_vaadd ();
}
We report error when overloaded function with empty args. For example:
test.c: In function 'foo':
test.c:8:3: error: no matching function call to '__riscv_vaadd' with empty args
8 | __riscv_vaadd ();
| ^~~~~~~~~~~~~~~~~~~~
Unfortunately, it will meet another ICE similar to below after above
message. The underlying build function checker will have zero args
and break some assumption of the function checker. For example, the
count of args is not less than 2.
ice.c: In function ‘foo’:
ice.c:8:3: internal compiler error: in require_immediate, at
config/riscv/riscv-vector-builtins.cc:4252
8 | __riscv_vaadd ();
| ^~~~~~~~~~~~~
0x20b36ac riscv_vector::function_checker::require_immediate(unsigned
int, long, long) const
.../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins.cc:4252
0x20b890c riscv_vector::alu_def::check(riscv_vector::function_checker&) const
.../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins-shapes.cc:387
0x20b38d7 riscv_vector::function_checker::check()
.../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins.cc:4315
0x20b4876 riscv_vector::check_builtin_call(unsigned int, vec<unsigned int, va_heap, vl_ptr>,
.../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins.cc:4605
0x2069393 riscv_check_builtin_call
.../__RISC-V_BUILD__/../gcc/config/riscv/riscv-c.cc:227
Below test are passed for this patch.
* The riscv regression tests.
PR target/113766
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-shapes.cc (struct alu_def): Make
sure the c.arg_num is >= 2 before checking.
(struct build_frm_base): Ditto.
(struct narrow_alu_def): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr113766-1.c: Add new cases.
Signed-off-by: Pan Li <pan2.li@intel.com>
My fix for bug 111059 and bug 111911 caused a conversion of a floating
constant to boolean to wrongly no longer be considered an integer
constant expression, because logic to insert a NOP_EXPR in
c_objc_common_truthvalue_conversion for an argument not an integer
constant expression itself now took place after rather than before the
conversion to bool. In the specific case of casting a floating
constant to bool, the result is an integer constant expression even
though the argument isn't (build_c_cast deals with ensuring that casts
to integer type of anything of floating type more complicated than a
single floating constant don't get wrongly treated as integer constant
expressions even if they fold to constants), so fix the logic in
c_objc_common_truthvalue_conversion to handle that special case.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/113776
gcc/c
* c-typeck.cc (c_objc_common_truthvalue_conversion): Return an
integer constant expression for boolean conversion of floating
constant.
gcc/testsuite/
* gcc.dg/pr113776-1.c, gcc.dg/pr113776-2.c, gcc.dg/pr113776-3.c,
gcc.dg/pr113776-4.c: New tests.
The new testcase from P2308 crashed trying to expand 'this' without an
object to refer to, because we stripped the TARGET_EXPR in
create_template_parm_object. So let's leave it on for giving an error.
gcc/cp/ChangeLog:
* pt.cc (create_template_parm_object): Pass TARGET_EXPR to
cxx_constant_value.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class64.C: New test.
