Paul Keir [Mon, 12 Feb 2024 18:15:49 +0000 (18:15 +0000)]
libstdc++: Fix constexpr basic_string union member [PR113294]
A call to `basic_string::clear()` in the std::string move assignment
operator leads to a constexpr error from an access of inactive union
member `_M_local_buf` in the added test (`test_move()`). Changing
`__str._M_local_buf` to `__str._M_use_local_data()` in
`operator=(basic_string&& __str)` fixes this.
PR libstdc++/113294
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (basic_string::operator=): Use
_M_use_local_data() instead of _M_local_buf on the moved-from
string.
* testsuite/21_strings/basic_string/modifiers/constexpr.cc
(test_move): New test.
Signed-off-by: Paul Keir <paul.keir@uws.ac.uk> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Jakub Jelinek [Mon, 12 Feb 2024 19:46:04 +0000 (20:46 +0100)]
lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions multiple of limb_prec [PR113849]
handle_cast handles the simple way all narrowing large/huge bitint to
large/huge bitint conversions and also such widening conversions if we can
assume that the most significant limb is processed using constant index
and both lhs and rhs have same number of limbs.
But, the condition whether we can rely on the most significant limb
being processed using constant index is incorrect.
For m_upwards_2limb it was correct (m_upwards_2limb then is the number
of limbs handled by the loop, so if lhs_type has larger precision than
that, it is handled with constant index), similarly if m_var_msb is set
(on left shifts), it is never handled with constant idx. But in other
cases, like right shifts or non-equality comparisons, or bitquery operations
which operate from most significant to least significant limb, all those
can handle even the most significant limb in a loop when lhs_type has
precision which is a multiple of limb_prec.
So, the following patch punts on the optimization in that case and goes for
the conditionals in the loop for that case.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113849
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't use
fast path for widening casts where !m_upwards_2limb and lhs_type
has precision which is a multiple of limb_prec.
The C and C++ FEs when parsing attributes already canonicalize them
(i.e. if they start with __ and end with __ substrings, we remove those).
lookup_attribute already verifies in gcc_assert that the first character
of name is not an underscore, and even lookup_scoped_attribute_spec doesn't
attempt to canonicalize the namespace it is passed. But for some historic
reason it was canonicalizing the name argument, which misbehaves when
an attribute starts with ____ and ends with ____.
I believe it is just wrong to try to canonicalize
lookup_scope_attribute_spec name attribute, it should have been
canonicalized already, in other spots where it is called it is already
canonicalized before.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
PR c++/113674
* attribs.cc (extract_attribute_substring): Remove.
(lookup_scoped_attribute_spec): Don't call it.
Jakub Jelinek [Mon, 12 Feb 2024 17:51:25 +0000 (18:51 +0100)]
testsuite: Fix up gcc.dg/pr113693.c for ia32
As I wrote earlier and we've discussed on IRC, with the ia32 _BitInt
enablement patch this testcase FAILs on ia32, there is nothing vectorized in
there, even with -mavx512{vl,bw,dq}, so no dbgcnt messages are emitted.
The following patch instead prunes it.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/pr113693.c: Guard _BitInt(837) use with
__BITINT_MAXWIDTH__ >= 837. Use dg-prune-output instead of
dg-message for dbgcnt message.
Jakub Jelinek [Mon, 12 Feb 2024 17:50:16 +0000 (18:50 +0100)]
libiberty: Fix up libiberty_vprintf_buffer_size
When writing the HOST_SIZE_T_PRINT_UNSIGNED incremental patch,
my first bootstrap failed on i686-linux. That is because I've also had
@@ -1344,8 +1344,10 @@ adjust_field_rtx_def (type_p t, options_
}
subfields = create_field (subfields, t,
- xasprintf (".fld[%lu].%s",
- (unsigned long) aindex,
+ xasprintf (".fld["
+ HOST_SIZE_T_PRINT_UNSIGNED
+ "].%s",
+ (fmt_size_t) aindex,
subname));
subfields->opt = nodot;
if (t == note_union_tp)
hunk in gengtype.cc. While sprintf obviously can print in this case %llu
with fmt_size_t being unsigned long long (that is another bug I'll fix
incrementally), seems libiberty_vprintf_buffer_size
can't deal with that, it ignores h, hh, l, ll and L modifiers and
unconditionally, estimates 30 chars as upper bounds for integers (that is
fine) and then uses (void) va_arg (ap, int); to skip over the argument
regardless if it was %d, %ld, %lld, %hd, %hhd etc.
Now, on x86_64 that happens to work fine probably for all of those,
on ia32 for everything but %lld, because it then skips just one half
of the long long argument; now as there is %s after it, it will try to
compute strlen not from the pointer argument corresponding to %s, but
from the most significant half of the previous long long argument.
So, the following patch attempts not to completely ignore the modifiers,
but figure out from them whether to va_arg an int (used for h and hh as
well), or long, or long long, or size_t, or ptrdiff_t - added support for
z and t there, plus for Windows I64. And also %Lf etc. for long double.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
* vprintf-support.c (libiberty_vprintf_buffer_size): Handle
properly l, ll, z, t or on _WIN32 I64 modifiers for diouxX
and L modifier for fFgGeE.
Iain Buclaw [Sun, 4 Feb 2024 21:04:14 +0000 (22:04 +0100)]
d: Fix callee destructor call invalidates the live object [PR113758]
When generating the argument, check the isCalleeDestroyingArgs hook, and
force a TARGET_EXPR to be created if true, so that a reference to the
live object isn't passed directly to the function that runs dtors.
When instead dealing with caller running destructors, two temporaries
were being generated, one explicit temporary generated by the D
front-end, and another implicitly by the code generator. This has been
reduced to one by setting DECL_VALUE_EXPR on the explicit temporary to
bind it to the implicit slot created for the TARGET_EXPR, as that has
the shorter lifetime of the two.
PR d/113758
gcc/d/ChangeLog:
* d-codegen.cc (d_build_call): Force a TARGET_EXPR when callee
destorys its arguments.
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Set
SET_DECL_VALUE_EXPR on the temporary variable to make it a placeholder
for the TARGET_EXPR_SLOT.
Christophe Lyon [Sat, 10 Feb 2024 21:17:08 +0000 (21:17 +0000)]
gcc/Makefile.in: Always check info dependencies
BUILD_INFO is currently a byproduct of checking makeinfo
presence/version. INSTALL_INFO used to be defined similarly, but was
removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df
(svn r38141).
In order to save build time, our CI overrides MAKEINFO=echo, which
works when invoking 'make all' but not for 'make install' in case some
info files need an update.
I noticed this while testing a patch posted on the gcc-patches list,
leading to an error at 'make install' time after updating tm.texi (the
build reported 'new text' in tm.texi and stopped). This is because
'install' depends on 'install-info', which depends on
$(DESTDIR)$(infodir)/gccint.info (among others).
As discussed, it is better to detect this problem during 'make all'
rather than 'make install', and we still want to detect it even if
makeinfo is not available.
This patch makes configure set BUILD_INFO=no-info in case makeinfo is
missing/too old, which effectively makes the build rules no-ops
(x$(BUILD_INFO) != xinfo), and updates Makefile.in so that 'info'
dependencies are still checked.
The initial heap trampoline implementation was targeting 64b
platforms. As the PR demonstrates this creates an issue where it
is expected that the same symbols are exported for 32 and 64b.
Rather than conditionalize the exports and code-gen on x86_64,
this patch provides a basic implementation of the IA32 trampoline.
This also avoids potential user confusion, when a 32b target has
64b multilibs, and vice versa; which is the case for Darwin.
PR target/113855
gcc/ChangeLog:
* config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
available to all sub-targets.
* config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete.
* config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): Delete.
libgcc/ChangeLog:
* config.host: Add trampoline support to x?86-linux.
* config/i386/heap-trampoline.c (trampoline_insns): Provide
a variant for IA32.
(union ix86_trampoline): Likewise.
(__gcc_nested_func_ptr_created): Implement a basic trampoline
for IA32.
Richard Biener [Fri, 9 Feb 2024 09:16:38 +0000 (10:16 +0100)]
tree-optimization/113831 - wrong VN with structurally identical ref
When we use get_ref_base_and_extent during VN and that ends up using
global ranges to restrict the range of a ref we have to take care
of not using the same expression in the hashtable as for a ref that
could not use that global range. The following attempts to ensure
this by applying similar logic as get_ref_base_and_extent to
copy_reference_ops_from_ref so they behave consistent.
PR tree-optimization/113831
PR tree-optimization/108355
* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): When
we see variable array indices and get_ref_base_and_extent
can resolve those to constants fix up the ops to constants
as well.
(ao_ref_init_from_vn_reference): Use 'off' member for
ARRAY_REF and ARRAY_RANGE_REF instead of recomputing it.
(valueize_refs_1): Also fixup 'off' of ARRAY_RANGE_REF.
* gcc.dg/torture/pr113831.c: New testcase.
* gcc.dg/tree-ssa/ssa-fre-104.c: Likewise.
As detailed in PR modula2/113888, the 32-bit libm2pim/target.c doesn't
assemble in a Linux/sparc64 multilib build. However, the root cause is
that the HAVE_EXP10* macros are never defined. While I was at it, I
checked for other cases where the code uses HAVE_* macros that are
missing from config.h.in.
This patch adds the missing checks, changes the configure checks where
the names don't match what's used in the code, or corrects the code to
use the right names.
So far tested on sparc64-unknown-linux-gnu by building libgm2 (32 and
64-bit) and running the gm2 tests.
Pan Li [Sat, 10 Feb 2024 10:59:55 +0000 (18:59 +0800)]
RISC-V: Fix misspelled term args in error_at message
When build with "-Werror=format-diag", there will be one misspelled
term args as below. This patch would like fix it by taking the term
arguments instead.
../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node*
riscv_vector::resolve_overloaded_builtin(location_t, unsigned int, tree,
vec<tree_node*, va_gc>*)':
../../gcc/config/riscv/riscv-vector-builtins.cc:4633:65: error:
misspelled term 'args' in format; use 'arguments' instead
[-Werror=format-diag]
4633 | error_at (loc, "no matching function call to %qE with empty
args", fndecl);
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc (resolve_overloaded_builtin):
Replace args to arguments for misspelled term.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr113766-1.c: Adjust the test cases.
Georg-Johann Lay [Mon, 12 Feb 2024 10:10:48 +0000 (11:10 +0100)]
AVR: target/112944 - Addendum: Link code to initialize NVMCTRL_CTRLB.FLMAP
For devices that see a part for the flash memory in the RAM address space,
bit-field NVMCTRL_CTRLB.FLMAP must match the value of symbol __flmap.
This is achieved by dragging in startup code from lib<mcu>.a.
The mechanism is the same like for libgcc's __do_copy_data and __do_clear_bss.
The code is implemented in AVR-LibC #931 and can be dragged by referencing
__do_flmap_init.
In addition to setting FLMAP, that code also sets bit FLMAPLOCK provided
symbol __flmap_lock has a non-zero value. This protects FLMAP from future
changes.
When the __do_flmap_init code is not wanted, the symbol can be satisfied by
linking with -Wl,--defsym,__do_flmap_init=0
gcc/
PR target/112944
* config/avr/gen-avr-mmcu-specs.cc (print_mcu) [have_flmap]:
<*link_rodata_in_ram>: Spec undefs symbol __do_flmap_init
when not linked with -mrodata-in-ram.
testsuite: Update test case to comply with GCC14 changes
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.
Marek Polacek [Fri, 2 Feb 2024 19:53:01 +0000 (14:53 -0500)]
c++: DR2237, cdtor and template-id tweaks [PR107126]
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.
Jakub Jelinek [Sat, 10 Feb 2024 11:52:23 +0000 (12:52 +0100)]
lower-bitint: Fix up .{ADD,SUB}_OVERFLOW lowering
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.
Jakub Jelinek [Sat, 10 Feb 2024 11:51:39 +0000 (12:51 +0100)]
libgcc: Fix a bug in _BitInt -> dfp conversions
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.
Jakub Jelinek [Sat, 10 Feb 2024 11:50:52 +0000 (12:50 +0100)]
libgcc: Fix BIL_TYPE_SIZE == 32 support in _BitInt <-> dfp support
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.
Jakub Jelinek [Sat, 10 Feb 2024 10:28:00 +0000 (11:28 +0100)]
gimple-low: Fix up handling of volatile automatic vars in assume attribute [PR110754]
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.
Jakub Jelinek [Sat, 10 Feb 2024 10:27:14 +0000 (11:27 +0100)]
Add %[zt][diox] support to pretty-print
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.
Jakub Jelinek [Sat, 10 Feb 2024 10:26:26 +0000 (11:26 +0100)]
Use HOST_SIZE_T_PRINT_* and HOST_WIDE_INT_T_PRINT_* some more
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.
c++: testcases for PR113545 (constexpr with switch and passing non-constexpr parameter)
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.
Gaius Mulley [Sat, 10 Feb 2024 02:18:54 +0000 (02:18 +0000)]
PR modula2/113848 modula2 does not build with clang
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.
Marek Polacek [Fri, 9 Feb 2024 17:03:50 +0000 (12:03 -0500)]
c++: fix ICE with __type_pack_element [PR113834]
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.
Marek Polacek [Tue, 6 Feb 2024 20:35:16 +0000 (15:35 -0500)]
c++: make build_throw SFINAE-friendly [PR98388]
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.
Harald Anlauf [Thu, 8 Feb 2024 20:51:38 +0000 (21:51 +0100)]
Fortran: error recovery on arithmetic overflow on unary operations [PR113799]
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.
Ken Matsui [Thu, 8 Feb 2024 08:12:07 +0000 (00:12 -0800)]
libstdc++: Use _GLIBCXX_USE_BUILTIN_TRAIT for is_same
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>
Patrick Palka [Fri, 9 Feb 2024 17:40:28 +0000 (12:40 -0500)]
c++/modules: anon union member of as-base class [PR112580]
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.
Jakub Jelinek [Fri, 9 Feb 2024 15:17:08 +0000 (16:17 +0100)]
lower-bitint: Fix handling of VIEW_CONVERT_EXPRs to minimally supported huge INTEGER_TYPEs [PR113783]
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.
Jakub Jelinek [Fri, 9 Feb 2024 10:51:08 +0000 (11:51 +0100)]
hwint: Introduce HOST_SIZE_T_PRINT_*
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.
Jakub Jelinek [Fri, 9 Feb 2024 10:08:33 +0000 (11:08 +0100)]
expand: Fix asm goto expansion [PR113415]
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.
Jakub Jelinek [Fri, 9 Feb 2024 10:07:34 +0000 (11:07 +0100)]
lower-bitint: Fix up additions of EH edges [PR113818]
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.
Jakub Jelinek [Fri, 9 Feb 2024 10:06:00 +0000 (11:06 +0100)]
lower-bitint: Attempt not to emit always true conditions in handle_cast [PR113774]
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.
testsuite: Pattern does not match when using --specs=nano.specs
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.
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
arm: testsuite: fix issues relating to fp16 alternative testing
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.
Patrick Palka [Thu, 8 Feb 2024 14:10:44 +0000 (09:10 -0500)]
c++: NTTP type CTAD w/ tmpl from current inst [PR113649]
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.
Aldy Hernandez [Tue, 6 Feb 2024 09:22:30 +0000 (10:22 +0100)]
ranger: Grow BBs in relation oracle as needed [PR113735]
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.
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.
H.J. Lu [Tue, 6 Feb 2024 03:48:48 +0000 (19:48 -0800)]
x86: Update constraints for APX NDD instructions
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.
Tamar Christina [Thu, 8 Feb 2024 10:43:13 +0000 (10:43 +0000)]
middle-end: don't cache restart_loop in vectorizable_live_operations [PR113808]
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.
Pan Li [Wed, 7 Feb 2024 08:34:46 +0000 (16:34 +0800)]
RISC-V: Bugfix for RVV overloaded intrinsic ICE in function checker
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.
* 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.
Joseph Myers [Thu, 8 Feb 2024 01:34:09 +0000 (01:34 +0000)]
c: Fix boolean conversion of floating constant as integer constant expression [PR113776]
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.
Jason Merrill [Wed, 7 Feb 2024 20:03:01 +0000 (15:03 -0500)]
c++: class nttp ICE
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.
Patrick Palka [Wed, 7 Feb 2024 19:24:51 +0000 (14:24 -0500)]
libstdc++: Work around modules issue causing hello-1 ICE [PR113710]
The forward declarations of std::get in <bits/stl_pair.h> added in r14-8710-g65b4cba9d6a9ff are causing an ICE in the test modules/hello-1
due to what seems to be a declaration merging issue in modules.
What's happening is that in hello-1_b.C we first include <string_view>,
which indirectly includes <bits/stl_pair.h> which forms the dependent
specialization tuple_element<__i, tuple<_Elements...>> (appearing in
the signatures of some of the std::get overloads) and adds it to the
specializations table.
We then import hello which indirectly includes <tuple> (in the GMF),
within which we define a partial specialization of tuple_element with
that same template-id. So importing hello in turn streams in this
partial specialization but we don't merge it with the previously created
dependent specialization, and we end up with two equivalent types for
this template-id with different TYPE_CANONICAL.
This patch works around this issue by adding a forward declaration of
the tuple_element partial specialization from <tuple> to <bits/stl_pair.h>
so that it appears alongside the dependent specialization of the same
template-id. So when including <bits/stl_pair.h> we immediately register
the template-id as a partial specialization, and if we later stream in the
partial specialization the MK_partial case of trees_in::key_mergeable will
match them up. (So perhaps a proper modules fix for this might be to make
key_mergeable try to match up a streamed in partial specialization with an
existing specialization from the table via match_mergeable_specialization.)
PR testsuite/113710
PR c++/113814
libstdc++-v3/ChangeLog:
* include/bits/stl_pair.h (tuple_element): Add forward
declaration of the partial specialization for tuple.
Richard Biener [Wed, 7 Feb 2024 12:08:43 +0000 (13:08 +0100)]
tree-optimization/113796 - if-conversion and ranges
The following makes sure to wipe range info before folding the
COND_EXPRs we insert as part of replacing PHI nodes when combining
blocks in the if-conversion pass.
PR tree-optimization/113796
* tree-if-conv.cc (combine_blocks): Wipe range-info before
replacing PHIs and inserting predicates.
Roger Sayle [Wed, 7 Feb 2024 14:21:34 +0000 (14:21 +0000)]
PR target/113690: Remove TImode REG_EQUAL notes in STV.
This patch fixes PR target/113690, an ICE-on-valid regression on x86_64
that exhibits with a specific combination of command line options. The
cause is that x86's scalar-to-vector pass converts a chain of instructions
from TImode to V1TImode, but fails to appropriately update or delete the
attached REG_EQUAL note. This implements Uros' recommendation of removing
these notes. For convenience, this code (re)factors the logic to convert
a TImode constant into a V1TImode constant vector into a subroutine and
reuses it.
For the record, STV is actually doing something useful in this strange
testcase, GCC with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types
-funroll-loops generates:
2024-02-07 Roger Sayle <roger@nextmovesoftware.com>
Uros Bizjak <ubizjak@gmail.com>
gcc/ChangeLog
PR target/113690
* config/i386/i386-features.cc (timode_convert_cst): New helper
function to convert a TImode CONST_SCALAR_INT_P to a V1TImode
CONST_VECTOR.
(timode_scalar_chain::convert_op): Use timode_convert_cst.
(timode_scalar_chain::convert_insn): Delete REG_EQUAL notes.
Use timode_convert_cst.
gcc/testsuite/ChangeLog
PR target/113690
* gcc.target/i386/pr113690.c: New test case.
With the release of Binutils 2.42, this brings the level of
system-register support in GCC in line with the current
state-of-the-art in Binutils, ensuring everything available in
Binutils is plainly accessible from GCC.
Where Binutils uses a more detailed description of which features are
responsible for enabling a given system register, GCC aliases the
binutils-equivalent feature flag macro constant to that of the base
architecture implementing the feature, resulting in entries such as
#define AARCH64_FL_S2PIE AARCH64_FL_V8_9A
in `aarch64.h', thus ensuring that the Binutils `aarch64-sys-regs.def'
file can be understood by GCC without the need for modification.
To accompany the addition of the new system registers, a new test is
added confirming they were successfully added to the list of
recognized registers.
Kushal Pal [Fri, 26 Jan 2024 07:51:37 +0000 (13:21 +0530)]
gccrs: Remove obsolete classes and functions.
Trait functions now use AST::Function class, so classes
AST::TraitItemFunc, AST::TraitItemMethod, AST::TraitFunctionDecl,
AST::TraitMethodDecl and their related functions can be removed.
Philip Herron [Sun, 4 Feb 2024 17:07:05 +0000 (17:07 +0000)]
gccrs: fix bug in pattern check for tuples
We can point to generic parent types which means we need to do the shallow
resolve thing that rustc does. We have destructure which is similar to get
what the parameter type points to.
Fixes #2775
gcc/rust/ChangeLog:
* typecheck/rust-hir-type-check-pattern.cc (TypeCheckPattern::visit): use destructure
gcc/testsuite/ChangeLog:
* rust/compile/issue-2775.rs: New test.
Signed-off-by: Philip Herron <herron.philip@googlemail.com>
Nobel Singh [Mon, 29 Jan 2024 22:35:03 +0000 (04:20 +0545)]
gccrs: Move the Implementation of implitem lowering into its own file.
This patch moves the implementation of the implitem lowering
from rust-ast-lower-implitem.h into the rust-ast-lower-implitem.cc
file.
gcc/rust/ChangeLog:
* Make-lang.in: Add rust-ast-lower-implitem.cc to list of objects.
* hir/rust-ast-lower-implitem.h (RUST_AST_LOWER_IMPLITEM_H): Remove
implementation.
* hir/rust-ast-lower-implitem.cc: Copy implementation from header.
Philip Herron [Sat, 3 Feb 2024 11:34:30 +0000 (11:34 +0000)]
gccrs: remove old generics hack to reuse generic symbols from previous seg
This patch introduces one regression because generics are getting better
understood over time. The code here used to apply generics with the same
symbol from previous segments which was a bit of a hack with out limited
inference variable support. The regression looks like it will be related
to another issue which needs to default integer inference variables much
more aggresivly to default integer.
* rust/compile/issue-1773.rs: Moved to...
* rust/compile/issue-1773.rs.bak: ...here.
* rust/compile/issue-2723-1.rs: New test.
* rust/compile/issue-2723-2.rs: New test.
Nobel Singh [Fri, 19 Jan 2024 15:06:34 +0000 (20:51 +0545)]
gccrs: Set the default ABI to C for extern blocks and extern functions
Previously, the default ABI was set to Rust, which is not correct for
extern blocks and extern functions. This patch changes the default
ABI to C for these cases.
gcc/rust/ChangeLog:
* hir/rust-ast-lower-base.cc (ASTLoweringBase::lower_qualifiers):
Change default ABI to C for extern functions
(ASTLoweringBase::lower_extern_block): Likewise
projects / thirdparty / gcc.git / log
