Recent PR111822 fix implemented REG_EH_REGION note copying to a STV converted
preload instruction in general_scalar_chain::convert_op. However, the same
issue remains in timode_scalar_chain::convert_op. Instead of copying the
newly introduced code to timode_scalar_chain::convert_op, the patch unifies
both functions to a common function.
PR target/111822
gcc/ChangeLog:
* config/i386/i386-features.cc (smode_convert_cst): New function
to handle SImode, DImode and TImode immediates.
(scalar_chain::convert_op): Unify from
general_scalar_chain::convert_op and timode_scalar_chain::convert_op.
(general_scalar_chain::convert_op): Remove.
(timode_scalar_chain::convert_op): Remove.
* config/i386/i386-features.h (class scalar_chain):
Redeclare convert_op as protected class member.
(class general_calar_chain): Remove convert_op.
(class timode_scalar_chain): Ditto.
gcc/testsuite/ChangeLog:
* g++.target/i386/pr111822.C (dg-do): Compile only for ia32 targets.
(dg-options): Add -march=x86-64.
Jonathan Wakely [Wed, 13 Mar 2024 10:02:12 +0000 (10:02 +0000)]
libstdc++: Move test error_category to global scope
A recent GDB change causes this test to fail due to missing RTTI for the
custom_cast type. This is presumably because the custom_cat type was
defined as a local class, so has no linkage. Moving it to local scope
seems to fix the test regressions, and probably makes the test more
realistic as a local class with no linkage isn't practical to use as an
error category that almost certainly needs to be referred to in other
scopes.
libstdc++-v3/ChangeLog:
* testsuite/libstdc++-prettyprinters/cxx11.cc: Move custom_cat
to namespace scope.
The current implementation triggers an assertion in
dwarf2out_frame_debug_cfa_offset() under certain circumstances.
The standard code uses REG_FRAME_RELATED_EXPR notes instead
of REG_CFA_OFFSET notes when saving registers on the stack.
So let's do this as well.
gcc/ChangeLog:
PR target/114160
* config/riscv/thead.cc (th_mempair_save_regs):
Emit REG_FRAME_RELATED_EXPR notes in prologue.
François Dumont [Thu, 14 Mar 2024 21:13:57 +0000 (22:13 +0100)]
libstdc++: Implement N3644 on _Safe_iterator<> [PR114316]
Consider range of value-initialized iterators as valid and empty.
libstdc++-v3/ChangeLog:
PR libstdc++/114316
* include/debug/safe_iterator.tcc (_Safe_iterator<>::_M_valid_range):
First check if both iterators are value-initialized before checking if
singular.
* testsuite/23_containers/set/debug/114316.cc: New test case.
* testsuite/23_containers/vector/debug/114316.cc: New test case.
Jonathan Wakely [Tue, 15 Aug 2023 15:35:22 +0000 (16:35 +0100)]
libstdc++: Simplify chrono::__units_suffix using std::format
For std::chrono formatting we can simplify __units_suffix by using
std::format_to to generate the "[n/m]s" suffix with the correct
character type and write directly to the output iterator, so it doesn't
need to be widened using ctype. We can't remove the use of ctype::widen
for formatting a time zone abbreviation as a wide string, because that
can contain arbitrary characters that can't be widened by
__to_wstring_numeric.
This also fixes a bug in the chrono formatter for %Z which created a
dangling wstring_view.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__units_suffix_misc): Remove.
(__units_suffix): Return a known suffix as string view, do not
write unknown suffixes to a buffer.
(__fmt_units_suffix): New function that formats the suffix using
std::format_to.
(operator<<, __chrono_formatter::_M_q): Use __fmt_units_suffix.
(__chrono_formatter::_M_Z): Correct lifetime of wstring.
I caused a regression with commit r10-908 by adding a constraint to the
non-explicit allocator-extended default constructor, but seemingly
forgot to add an explicit overload with the corresponding constraint.
Jakub Jelinek [Thu, 14 Mar 2024 08:57:13 +0000 (09:57 +0100)]
gimple-iterator: Some gsi_safe_insert_*before fixes
When trying to use the gsi_safe_insert*before APIs in bitint lowering,
I've discovered 3 issues and the following patch addresses those:
1) both split_block and split_edge update CDI_DOMINATORS if they are
available, but because edge_before_returns_twice_call first splits
and then adds an extra EDGE_ABNORMAL edge and then removes another
one, the immediate dominators of both the new bb and the bb with
returns_twice call need to change
2) the new EDGE_ABNORMAL edge had uninitialized probability; this patch
copies the probability from the edge that is going to be removed
and similarly copies other flags (EDGE_EXECUTABLE, EDGE_DFS_BACK,
EDGE_IRREDUCIBLE_LOOP etc.)
3) if edge_before_returns_twice_call splits a block, then the bb with
returns_twice call changes, so the gimple_stmt_iterator for it is
no longer accurate, it points to the right statement, but gsi_bb
and gsi_seq are no longer correct; the patch updates it
2024-03-14 Jakub Jelinek <jakub@redhat.com>
* gimple-iterator.cc (edge_before_returns_twice_call): Copy all
flags and probability from ad_edge to e edge. If CDI_DOMINATORS
are computed, recompute immediate dominator of other_edge->src
and other_edge->dest.
(gsi_safe_insert_before, gsi_safe_insert_seq_before): Update *iter
for the returns_twice call case to the gsi_for_stmt (stmt) to deal
with update it for bb splitting.
Jakub Jelinek [Wed, 13 Mar 2024 08:19:05 +0000 (09:19 +0100)]
asan: Fix ICE during instrumentation of returns_twice calls [PR112709]
The following patch on top of the previously posted ubsan/gimple-iterator
one handles asan the same. While the case of returning by hidden reference
is handled differently because of the first recently posted asan patch,
this deals with instrumentation of the aggregates returned in registers
case as well as instrumentation of loads from aggregate memory in the
function arguments of returns_twice calls.
2024-03-13 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/112709
* asan.cc (maybe_create_ssa_name, maybe_cast_to_ptrmode,
build_check_stmt, maybe_instrument_call, asan_expand_mark_ifn): Use
gsi_safe_insert_before instead of gsi_insert_before.
Jakub Jelinek [Wed, 13 Mar 2024 08:16:45 +0000 (09:16 +0100)]
gimple-iterator, ubsan: Fix ICE during instrumentation of returns_twice calls [PR112709]
ubsan, asan (both PR112709) and _BitInt lowering (PR113466) want to
insert some instrumentation or adjustment statements before some statement.
This unfortunately creates invalid IL if inserting before a returns_twice
call, because we require that such calls are the first statement in a basic
block and that we have an edge from the .ABNORMAL_DISPATCHER block to
the block containing the returns_twice call (in addition to other edge(s)).
The following patch adds helper functions for such insertions and uses it
for now in ubsan (I'll post a follow up which uses it in asan and will
work later on the _BitInt lowering PR).
In particular, if the bb with returns_twice call at the start has just
2 edges, one EDGE_ABNORMAL from .ABNORMAL_DISPATCHER and another
(non-EDGE_ABNORMAL/EDGE_EH) from some other bb, it just inserts the
statement or sequence on that other edge.
If the bb has more predecessor edges or the one not from
.ABNORMAL_DISPATCHER is e.g. an EH edge (this latter case likely shouldn't
happen, one would need labels or something like that), the patch splits the
block with returns_twice call such that there is just one edge next to
.ABNORMAL_DISPATCHER edge and adjusts PHIs as needed to make it happen.
The functions also replace uses of PHIs from the returns_twice bb with
the corresponding PHI arguments, because otherwise it would be invalid IL.
E.g. in ubsan/pr112709-2.c (qux) we have before the ubsan pass
<bb 10> :
# .MEM_5(ab) = PHI <.MEM_4(9), .MEM_25(ab)(11)>
# _7(ab) = PHI <_20(9), _8(ab)(11)>
# .MEM_21(ab) = VDEF <.MEM_5(ab)>
_22 = bar (*_7(ab));
where bar is returns_twice call and bb 11 has .ABNORMAL_DISPATCHER call,
this patch instruments it like:
<bb 9> :
# .MEM_4 = PHI <.MEM_17(ab)(4), .MEM_10(D)(5), .MEM_14(ab)(8)>
# DEBUG BEGIN_STMT
# VUSE <.MEM_4>
_20 = p;
# .MEM_27 = VDEF <.MEM_4>
.UBSAN_NULL (_20, 0B, 0);
# VUSE <.MEM_27>
_2 = __builtin_dynamic_object_size (_20, 0);
# .MEM_28 = VDEF <.MEM_27>
.UBSAN_OBJECT_SIZE (_20, 1024, _2, 0);
<bb 10> :
# .MEM_5(ab) = PHI <.MEM_28(9), .MEM_25(ab)(11)>
# _7(ab) = PHI <_20(9), _8(ab)(11)>
# .MEM_21(ab) = VDEF <.MEM_5(ab)>
_22 = bar (*_7(ab));
The edge from .ABNORMAL_DISPATCHER is there just to represent the
returning for 2nd and later times, the instrumentation can't be
done at that point as there is no code executed during that point.
The ubsan/pr112709-1.c testcase includes non-virtual PHIs to cover
the handling of those as well.
2024-03-13 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/112709
* gimple-iterator.h (gsi_safe_insert_before,
gsi_safe_insert_seq_before): Declare.
* gimple-iterator.cc: Include gimplify.h.
(edge_before_returns_twice_call, adjust_before_returns_twice_call,
gsi_safe_insert_before, gsi_safe_insert_seq_before): New functions.
* ubsan.cc (instrument_mem_ref, instrument_pointer_overflow,
instrument_nonnull_arg, instrument_nonnull_return): Use
gsi_safe_insert_before instead of gsi_insert_before.
(maybe_instrument_pointer_overflow): Use force_gimple_operand,
gimple_seq_add_seq_without_update and gsi_safe_insert_seq_before
instead of force_gimple_operand_gsi.
(instrument_object_size): Likewise. Use gsi_safe_insert_before
instead of gsi_insert_before.
* gcc.dg/ubsan/pr112709-1.c: New test.
* gcc.dg/ubsan/pr112709-2.c: New test.
Jakub Jelinek [Fri, 15 Mar 2024 09:46:47 +0000 (10:46 +0100)]
i386: Fix a pasto in ix86_expand_int_sse_cmp [PR114339]
In r13-3803-gfa271afb58 I've added an optimization for LE/LEU/GE/GEU
comparison against CONST_VECTOR. As the comments say:
/* x <= cst can be handled as x < cst + 1 unless there is
wrap around in cst + 1. */
...
/* For LE punt if some element is signed maximum. */
...
/* For LEU punt if some element is unsigned maximum. */
and
/* x >= cst can be handled as x > cst - 1 unless there is
wrap around in cst - 1. */
...
/* For GE punt if some element is signed minimum. */
...
/* For GEU punt if some element is zero. */
Apparently I wrote the GE/GEU (second case) first and then
copied/adjusted it for LE/LEU, most of the adjustments look correct, but
I've left if (code == GE) comparison when testing if it should punt for
signed maximum. That condition is never true, because this is in
switch (code) { ... case LE: case LEU: block and we really meant to
be what the comment says, for LE punt if some element is signed maximum,
as then cst + 1 wraps around.
The following patch fixes the pasto.
2024-03-15 Jakub Jelinek <jakub@redhat.com>
PR target/114339
* config/i386/i386-expand.cc (ix86_expand_int_sse_cmp) <case LE>: Fix
a pasto, compare code against LE rather than GE.
Jakub Jelinek [Thu, 14 Mar 2024 16:48:30 +0000 (17:48 +0100)]
icf: Reset SSA_NAME_{PTR,RANGE}_INFO in successfully merged functions [PR113907]
AFAIK we have no code in LTO streaming to stream out or in
SSA_NAME_{RANGE,PTR}_INFO, so LTO effectively throws it all away
and let vrp1 and alias analysis after IPA recompute that. There is
just one spot, for IPA VRP and IPA bit CCP we save/restore ranges
and set SSA_NAME_{PTR,RANGE}_INFO e.g. on parameters depending on what
we saved and propagated, but that is after streaming in bodies for the
post IPA optimizations.
Now, without LTO SSA_NAME_{RANGE,PTR}_INFO is already computed from
earlier in many cases (er.g. evrp and early alias analysis but other spots
too), but IPA ICF is ignoring the ranges and points-to details when
comparing the bodies. I think ignoring that is just fine, that is
effectively what we do for LTO where we throw that information away
before the analysis, and not ignoring it could lead to fewer ICF merging
possibilities.
So, the following patch instead verifies that for LTO SSA_NAME_{PTR,RANGE}_INFO
just isn't there on SSA_NAMEs in functions into which other functions have
been ICFed, and for non-LTO throws that information away (which matches the
LTO behavior).
Another possibility would be to remember the SSA_NAME <-> SSA_NAME mapping
vector (just one of the 2) on successful sem_function::equals on the
sem_function which is not the chosen leader (e.g. how SSA_NAMEs in the
leader map to SSA_NAMEs in the other function) and use that vector
to union the ranges in sem_function::merge. I can implement that for
comparison, but wanted to post this first if there is an agreement on
doing that or if Honza thinks we should take SSA_NAME_{RANGE,PTR}_INFO
into account. I think we can compare SSA_NAME_RANGE_INFO, but have
no idea how to try to compare points to info. And I think it will result
in less effective ICF for non-LTO vs. LTO unnecessarily.
2024-03-12 Jakub Jelinek <jakub@redhat.com>
PR middle-end/113907
* ipa-icf.cc (sem_item_optimizer::merge_classes): Reset
SSA_NAME_RANGE_INFO and SSA_NAME_PTR_INFO on successfully ICF merged
functions.
Jakub Jelinek [Thu, 14 Mar 2024 13:09:20 +0000 (14:09 +0100)]
aarch64: Fix TImode __sync_*_compare_and_exchange expansion with LSE [PR114310]
The following testcase ICEs with LSE atomics.
The problem is that the @atomic_compare_and_swap<mode> expander uses
aarch64_reg_or_zero predicate for the desired operand, which is fine,
given that for most of the modes and even for TImode in some cases
it can handle zero immediate just fine, but the TImode
@aarch64_compare_and_swap<mode>_lse just uses register_operand for
that operand instead, again intentionally so, because the casp,
caspa, caspl and caspal instructions need to use a pair of consecutive
registers for the operand and xzr is just one register and we can't
just store zero into the link register to emulate pair of zeros.
So, the following patch fixes that by forcing the newval operand into
a register for the TImode LSE case.
2024-03-14 Jakub Jelinek <jakub@redhat.com>
PR target/114310
* config/aarch64/aarch64.cc (aarch64_expand_compare_and_swap): For
TImode force newval into a register.
Jakub Jelinek [Thu, 7 Mar 2024 09:02:49 +0000 (10:02 +0100)]
bb-reorder: Fix -freorder-blocks-and-partition ICEs on aarch64 with asm goto [PR110079]
The following testcase ICEs, because fix_crossing_unconditional_branches
thinks that asm goto is an unconditional jump and removes it, replacing it
with unconditional jump to one of the labels.
This doesn't happen on x86 because the function in question isn't invoked
there at all:
/* If the architecture does not have unconditional branches that
can span all of memory, convert crossing unconditional branches
into indirect jumps. Since adding an indirect jump also adds
a new register usage, update the register usage information as
well. */
if (!HAS_LONG_UNCOND_BRANCH)
fix_crossing_unconditional_branches ();
I think for the asm goto case, for the non-fallthru edge if any we should
handle it like any other fallthru (and fix_crossing_unconditional_branches
doesn't really deal with those, it only looks at explicit branches at the
end of bbs and we are in cfglayout mode at that point) and for the labels
we just pass the labels as immediates to the assembly and it is up to the
user to figure out how to store them/branch to them or whatever they want to
do.
So, the following patch fixes this by not treating asm goto as a simple
unconditional jump.
I really think that on the !HAS_LONG_UNCOND_BRANCH targets we have a bug
somewhere else, where outofcfglayout or whatever should actually create
those indirect jumps on the crossing edges instead of adding normal
unconditional jumps, I see e.g. in
__attribute__((cold)) int bar (char *);
__attribute__((hot)) int baz (char *);
void qux (int x) { if (__builtin_expect (!x, 1)) goto l1; bar (""); goto l1; l1: baz (""); }
void corge (int x) { if (__builtin_expect (!x, 0)) goto l1; baz (""); l2: return; l1: bar (""); goto l2; }
with -O2 -freorder-blocks-and-partition on aarch64 before/after this patch
just b .L? jumps which I believe are +-32MB, so if .text is larger than
32MB, it could fail to link, but this patch doesn't address that.
Jakub Jelinek [Tue, 5 Mar 2024 09:32:38 +0000 (10:32 +0100)]
lower-subreg: Fix ROTATE handling [PR114211]
On the following testcase, we have
(insn 10 7 11 2 (set (reg/v:TI 106 [ h ])
(rotate:TI (reg/v:TI 106 [ h ])
(const_int 64 [0x40]))) "pr114211.c":8:5 1042 {rotl64ti2_doubleword}
(nil))
before subreg1 and the pass decides to use
(reg:DI 127 [ h ]) / (reg:DI 128 [ h+8 ])
register pair instead of (reg/v:TI 106 [ h ]).
resolve_operand_for_swap_move_operator implements it by pretending it is
an assignment from
(concatn (reg:DI 127 [ h ]) (reg:DI 128 [ h+8 ]))
to
(concatn (reg:DI 128 [ h+8 ]) (reg:DI 127 [ h ]))
The problem is that if the rotate argument is the same as destination or
if there is even an overlap between the first half of the destination with
second half of the source we emit incorrect code, because the store to
(reg:DI 128 [ h+8 ]) overwrites what we need for source of the second
move. The following patch detects that case and uses a temporary pseudo
to hold the original (reg:DI 128 [ h+8 ]) value across the first store.
2024-03-05 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/114211
* lower-subreg.cc (resolve_simple_move): For double-word
rotates by BITS_PER_WORD if there is overlap between source
and destination use a temporary.
Jakub Jelinek [Mon, 4 Mar 2024 09:04:19 +0000 (10:04 +0100)]
i386: Fix ICEs with SUBREGs from vector etc. constants to XFmode [PR114184]
The Intel extended format has the various weird number categories,
pseudo denormals, pseudo infinities, pseudo NaNs and unnormals.
Those are not representable in the GCC real_value and so neither
GIMPLE nor RTX VIEW_CONVERT_EXPR/SUBREG folding folds those into
constants.
As can be seen on the following testcase, because it isn't folded
(since GCC 12, before that we were folding it) we can end up with
a SUBREG of a CONST_VECTOR or similar constant, which isn't valid
general_operand, so we ICE during vregs pass trying to recognize
the move instruction.
Initially I thought it is a middle-end bug, the movxf instruction
has general_operand predicate, but the middle-end certainly never
tests that predicate, seems moves are special optabs.
And looking at other mov optabs, e.g. for vector modes the i386
patterns use nonimmediate_operand predicate on the input, yet
ix86_expand_vector_move deals with CONSTANT_P and SUBREG of CONSTANT_P
arguments which if the predicate was checked couldn't ever make it through.
The following patch handles this case similarly to the
ix86_expand_vector_move's SUBREG of CONSTANT_P case, does it just for XFmode
because I believe that is the only mode that needs it from the scalar ones,
others should just be folded.
2024-03-04 Jakub Jelinek <jakub@redhat.com>
PR target/114184
* config/i386/i386-expand.cc (ix86_expand_move): If XFmode op1
is SUBREG of CONSTANT_P, force the SUBREG_REG into memory or
register.
Harald Anlauf [Mon, 11 Mar 2024 21:05:51 +0000 (22:05 +0100)]
Fortran: handle procedure pointer component in DT array [PR110826]
gcc/fortran/ChangeLog:
PR fortran/110826
* array.cc (gfc_array_dimen_size): When walking the ref chain of an
array and the ultimate component is a procedure pointer, do not try
to figure out its dimension even if it is a array-valued function.
gcc/testsuite/ChangeLog:
PR fortran/110826
* gfortran.dg/proc_ptr_comp_53.f90: New test.
Harald Anlauf [Mon, 4 Dec 2023 21:44:53 +0000 (22:44 +0100)]
Fortran: allow RESTRICT qualifier also for optional arguments [PR100988]
gcc/fortran/ChangeLog:
PR fortran/100988
* gfortran.h (IS_PROC_POINTER): New macro.
* trans-types.cc (gfc_sym_type): Use macro in determination if the
restrict qualifier can be used for a dummy variable. Fix logic to
allow the restrict qualifier also for optional arguments, and to
not apply it to pointer or proc_pointer arguments.
Harald Anlauf [Fri, 1 Mar 2024 18:21:27 +0000 (19:21 +0100)]
Fortran: improve checks of NULL without MOLD as actual argument [PR104819]
gcc/fortran/ChangeLog:
PR fortran/104819
* check.cc (gfc_check_null): Handle nested NULL()s.
(is_c_interoperable): Check for MOLD argument of NULL() as part of
the interoperability check.
* interface.cc (gfc_compare_actual_formal): Extend checks for NULL()
actual arguments for presence of MOLD argument when required by
Interp J3/22-146.
gcc/testsuite/ChangeLog:
PR fortran/104819
* gfortran.dg/assumed_rank_9.f90: Adjust testcase use of NULL().
* gfortran.dg/pr101329.f90: Adjust testcase to conform to interp.
* gfortran.dg/null_actual_4.f90: New test.
we must copy the REG_EH_REGION note to the first insn and split the block
after the newly added insn. The REG_EH_REGION on the second insn will be
removed later since it no longer traps.
Marc Poulhiès [Mon, 6 Mar 2023 11:15:13 +0000 (12:15 +0100)]
ada: Fix (again) incorrect handling of Aggregate aspect
Previous fix stopped the processing of the Aggregate aspect early,
skipping the call to Record_Rep_Item, making later call to
Resolve_Container_Aggregate fail.
Also, the previous fix would not handle correctly the case where the
type is private and the check for non-array type can only be done at the
freeze point with the full type.
Adapt the resolving of the aspect when the input is not correct and the
parameters can't be resolved.
gcc/ada/
* sem_ch13.adb (Analyze_One_Aspect): Call Record_Rep_Item.
(Check_Aspect_At_Freeze_Point): Check the aspect is specified on
non-array type only...
(Analyze_One_Aspect): ... instead of doing it too early here.
* sem_aggr.adb (Resolve_Container_Aggregate): Do nothing in case
the parameters failed to resolve.
On arm-none-eabi, the test case fails with
.../null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:63:65: warning: converting a packed 'enum obj_type' pointer (alignment 1) to a 'struct connection' pointer (alignment 4) may result in an unaligned pointer value [-Waddress-of-packed-member]
The error was fixed in basepoints/gcc-14-6517-gb7e4a4c626e, but it
was considered to be a too big change to be backported and thus, the
failing test is marked xfail in GCC13.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c:
Added dg-bogus with xfail on offending line for short_enums.
Jonathan Wakely [Fri, 1 Mar 2024 20:55:10 +0000 (20:55 +0000)]
libstdc++: Update expiry times for leap seconds lists
The list in tzdb.cc isn't the only hardcoded list of leap seconds in the
library, there's the one defined inline in <chrono> (to avoid loading
the tzdb for the common case) and another in a testcase. This updates
them to note that there are no new leap seconds in 2024 either, until at
least 2024-12-28.
libstdc++-v3/ChangeLog:
* include/std/chrono (__get_leap_second_info): Update expiry
time for hardcoded list of leap seconds.
* testsuite/std/time/tzdb/leap_seconds.cc: Update comment.
Jonathan Wakely [Wed, 28 Feb 2024 15:05:08 +0000 (15:05 +0000)]
libstdc++: Fix std::basic_format_arg::handle for BasicFormatters
std::basic_format_arg::handle is supposed to format its value as const
if that is valid, to reduce the number of instantiations of the
formatter's format function. I made a silly typo so that it checks
formattable_with<TD, Context> not formattable_with<const TD, Context>,
which breaks support for BasicFormatters i.e. ones that can only format
non-const types.
There's a static_assert in the handle constructor which is supposed to
improve diagnostics for trying to format a const argument with a
formatter that doesn't support it. That condition can't fail, because
the std::basic_format_arg constructor is already constrained to check
that the argument type is formattable. The static_assert can be removed.
libstdc++-v3/ChangeLog:
* include/std/format (basic_format_arg::handle::__maybe_const_t):
Fix condition to check if const type is formattable.
(basic_format_arg::handle::handle(T&)): Remove redundant
static_assert.
* testsuite/std/format/formatter/basic.cc: New test.
Jonathan Wakely [Sun, 7 Jan 2024 22:21:08 +0000 (22:21 +0000)]
libstdc++: Implement P2905R2 "Runtime format strings" for C++20
This change makes std::make_format_args refuse to create dangling
references to temporaries. This makes the std::vformat API safer. This
was approved in Kona 2023 as a DR for C++20 so the change is implemented
unconditionally.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__formatter_chrono): Always use
lvalue arguments to make_format_args.
* include/std/format (make_format_args): Change parameter pack
from forwarding references to lvalue references. Remove use of
remove_reference_t which is now unnecessary.
(format_to, formatted_size): Remove incorrect forwarding of
arguments.
* testsuite/20_util/duration/io.cc: Use lvalues as arguments to
make_format_args.
* testsuite/std/format/arguments/args.cc: Likewise.
* testsuite/std/format/arguments/lwg3810.cc: Likewise.
* testsuite/std/format/functions/format.cc: Likewise.
* testsuite/std/format/functions/vformat_to.cc: Likewise.
* testsuite/std/format/string.cc: Likewise.
* testsuite/std/time/day/io.cc: Likewise.
* testsuite/std/time/month/io.cc: Likewise.
* testsuite/std/time/weekday/io.cc: Likewise.
* testsuite/std/time/year/io.cc: Likewise.
* testsuite/std/time/year_month_day/io.cc: Likewise.
* testsuite/std/format/arguments/args_neg.cc: New test.
Cassio Neri [Sun, 10 Dec 2023 11:31:31 +0000 (11:31 +0000)]
libstdc++: Remove UB from month and weekday additions and subtractions.
The following invoke signed integer overflow (UB) [1]:
month + months{MAX} // where MAX is the maximum value of months::rep
month + months{MIN} // where MIN is the maximum value of months::rep
month - months{MIN} // where MIN is the minimum value of months::rep
weekday + days {MAX} // where MAX is the maximum value of days::rep
weekday - days {MIN} // where MIN is the minimum value of days::rep
For the additions to MAX, the crux of the problem is that, in libstdc++,
months::rep and days::rep are int64_t. Other implementations use int32_t, cast
operands to int64_t and perform arithmetic operations without risk of
overflowing.
For month + months{MIN}, the implementation follows the Standard's "returns
clause" and evaluates:
Overflow occurs when MIN - 1 is evaluated. Casting to a larger type could help
but, unfortunately again, this is not possible for libstdc++.
For the subtraction of MIN, the problem is that -MIN is not representable.
It's fair to say that the intention is for these additions/subtractions to
be performed in modulus (12 or 7) arithmetic so that no overflow is expected.
which respectively, returns the remainder of Euclidean division of, __x + __y
and __x - __y by __d without overflowing. These functions replace
constexpr unsigned __modulo(long long __n, unsigned __d);
which also calculates the reminder of __n, where __n is the result of the
addition or subtraction. Hence, these operations might invoke UB before __modulo
is called and thus, __modulo can't do anything to remediate the issue.
In addition to solve the UB issues, __add_modulo and __sub_modulo allow better
codegen (shorter and branchless) on x86-64 and ARM [2].
* include/std/chrono: Fix + and - for months and weekdays.
* testsuite/std/time/month/1.cc: Add constexpr tests against overflow.
* testsuite/std/time/month/2.cc: New test for extreme values.
* testsuite/std/time/weekday/1.cc: Add constexpr tests against overflow.
* testsuite/std/time/weekday/2.cc: New test for extreme values.
The current implementation calls __detail::__modulo which is relatively
expensive.
A better implementation is possible if we assume that x.ok() && y.ok() == true,
so that n = x.c_encoding() - y.c_encoding() is in [-6, 6]. In this case, it
suffices to return n >= 0 ? n : n + 7.
The above is allowed by [time.cal.wd.nonmembers]/5: the returned value is
unspecified when x.ok() || y.ok() == false.
The assembly emitted for x86-64 and ARM can be seen in:
https://godbolt.org/z/nMdc5vv9n.
Cassio Neri [Sat, 11 Nov 2023 22:59:50 +0000 (22:59 +0000)]
libstdc++: Simplify year::is_leap()
The current implementation returns
(_M_y & (__is_multiple_of_100 ? 15 : 3)) == 0;
where __is_multiple_of_100 is calculated using an obfuscated algorithm which
saves one ror instruction when compared to _M_y % 100 == 0 [1].
In leap years calculation, it's correct to replace the divisibility check by
100 with the one by 25. It turns out that _M_y % 25 == 0 also saves the ror
instruction [2]. Therefore, the obfuscation is not required.
Cassio Neri [Sat, 11 Nov 2023 16:44:58 +0000 (16:44 +0000)]
libstdc++: Remove unnecessary "& 1" from year_month_day_last::day()
When year_month_day_last::day() was implemented, Dr. Matthias Kretz realised
that the operation "& 1" wasn't necessary but we did not patch it at that
time. This patch removes the unnecessary operation.
Jonathan Wakely [Sat, 4 Nov 2023 08:30:54 +0000 (08:30 +0000)]
libstdc++: Add [[nodiscard]] to std::span members
All std::span member functions are pure functions that have no side
effects. They are only useful for their return value, so they should all
warn if that value is not used.
Jonathan Wakely [Thu, 8 Jun 2023 11:24:43 +0000 (12:24 +0100)]
libstdc++: Optimize std::to_array for trivial types [PR110167]
As reported in PR libstdc++/110167, std::to_array compiles extremely
slowly for very large arrays. It needs to instantiate a very large
specialization of std::index_sequence<N...> and then create a very large
aggregate initializer from the pack expansion. For trivial types we can
simply default-initialize the std::array and then use memcpy to copy the
values. For non-trivial types we need to use the existing
implementation, despite the compilation cost.
As also noted in the PR, using a generic lambda instead of the
__to_array helper compiles faster since gcc-13. It also produces
slightly smaller code at -O1, due to additional inlining. The code at
-Os, -O2 and -O3 seems to be the same. This new implementation requires
__cpp_generic_lambdas >= 201707L (i.e. P0428R2) but that is supported
since Clang 10 and since Intel icc 2021.5.0 (and since GCC 10.1).
libstdc++-v3/ChangeLog:
PR libstdc++/110167
* include/std/array (to_array): Initialize arrays of trivial
types using memcpy. For non-trivial types, use lambda
expressions instead of a separate helper function.
(__to_array): Remove.
* testsuite/23_containers/array/creation/110167.cc: New test.
Andrew Pinski [Sun, 10 Mar 2024 22:17:09 +0000 (22:17 +0000)]
Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351]
The problem here is that merge_truthop_with_opposite_arm would
use the type of the result of the comparison rather than the operands
of the comparison to figure out if we are honoring NaNs.
This fixes that oversight and now we get the correct results in this
case.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
PR middle-end/95351
gcc/ChangeLog:
* fold-const.cc (merge_truthop_with_opposite_arm): Use
the type of the operands of the comparison and not the type
of the comparison.
Andrew Pinski [Tue, 12 Mar 2024 00:40:08 +0000 (17:40 -0700)]
Reject -fno-multiflags [PR114314]
When -fmultiflags option support was added in r13-3693-g6b1a2474f9e422,
it accidently allowed -fno-multiflags which then would pass on to cc1.
This fixes that oversight.
Committed as obvious after bootstrap/test on x86_64-linux-gnu.
Iain Buclaw [Sun, 10 Mar 2024 16:49:06 +0000 (17:49 +0100)]
d: Fix -fpreview=in ICEs with forward referenced parameter [PR112285]
The way that the target hook preferPassByRef is implemented, it relied
on the GCC "back-end" tree type to determine whether or not to use `ref'
ABI for D `in' parameters; e.g: prefer by value if it is expected that
the target will pass the type around in registers.
Building the GCC tree type depends on the AST type being complete - all
semantic processing is finished - but as this hook is called from the
front-end, this will not be the case for forward referenced or
self-referencing types.
The consensus in upstream is that `in' parameters should always be
implicitly `ref', but as the front-end does not yet support all types
being rvalue references, limit this just static arrays and structs.
PR d/112285
PR d/112290
gcc/d/ChangeLog:
* d-target.cc (Target::preferPassByRef): Return true for all static
array and struct types.
gcc/testsuite/ChangeLog:
* gdc.dg/pr112285.d: New test.
* gdc.dg/pr112290.d: New test.
* gdc.test/compilable/previewin.d: Adjust testcase.
Lulu Cheng [Tue, 5 Mar 2024 06:43:04 +0000 (14:43 +0800)]
LoongArch: Fixed an issue with the implementation of the template atomic_compare_and_swapsi.
If the hardware does not support LAMCAS, atomic_compare_and_swapsi needs to be
implemented through "ll.w+sc.w". In the implementation of the instruction sequence,
it is necessary to determine whether the two registers are equal.
Since LoongArch's comparison instructions do not distinguish between 32-bit
and 64-bit, the two operand registers that need to be compared are symbolically
extended, and one of the operand registers is obtained from memory through the
"ll.w" instruction, which can ensure that the symbolic expansion is carried out.
However, the value of the other operand register is not guaranteed to be the
value of the sign extension.
gcc/ChangeLog:
* config/loongarch/sync.md (atomic_cas_value_strong<mode>):
In loongarch64, a sign extension operation is added when
operands[2] is a register operand and the mode is SImode.
gcc/testsuite/ChangeLog:
* g++.target/loongarch/atomic-cas-int.C: New test.
Jerry DeLisle [Sat, 17 Feb 2024 17:24:58 +0000 (09:24 -0800)]
libgfortran: [PR105473] Fix checks for decimal='comma'.
PR libfortran/105473
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Reject comma as a
separator when it is being used as a decimal point.
(parse_real): Reject a '.' when it should be a comma.
(read_real): Likewise.
* io/read.c (read_f): Add more checks for ',' and '.'
conditions.
Eric Botcazou [Thu, 7 Mar 2024 14:05:54 +0000 (15:05 +0100)]
Fix bogus error on allocator for array type with Dynamic_Predicate
This is a regression present on all active branches: the compiler gives
a bogus error on an allocator for an unconstrained array type declared
with a Dynamic_Predicate because Apply_Predicate_Check is invoked directly
on a subtype reference, which it cannot handle.
This moves the check to the resulting access value (after dereference) like
in Expand_Allocator_Expression.
gcc/ada/
PR ada/113979
* exp_ch4.adb (Expand_N_Allocator): In the subtype indication case,
remove call to Apply_Predicate_Check.
gcc/testsuite/
* gnat.dg/predicate15.adb: New test.
Steve Kargl [Fri, 23 Feb 2024 21:05:04 +0000 (22:05 +0100)]
Fortran: ALLOCATE statement, SOURCE/MOLD expressions with subrefs [PR114024]
PR fortran/114024
gcc/fortran/ChangeLog:
* trans-stmt.cc (gfc_trans_allocate): When a source expression has
substring references, part-refs, or %re/%im inquiries, wrap the
entity in parentheses to force evaluation of the expression.
gcc/testsuite/ChangeLog:
* gfortran.dg/allocate_with_source_27.f90: New test.
* gfortran.dg/allocate_with_source_28.f90: New test.
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.
Jakub Jelinek [Fri, 1 Mar 2024 14:42:52 +0000 (15:42 +0100)]
calls: Further fixes for TYPE_NO_NAMED_ARGS_STDARG_P handling [PR114136]
On Tue, Feb 27, 2024 at 04:41:32PM +0000, Richard Earnshaw wrote:
> On Arm the PR107453 change is causing all anonymous arguments to be passed on the
> stack, which is incorrect per the ABI. On a target that uses
> 'pretend_outgoing_vararg_named', why is it correct to set n_named_args to
> zero? Is it enough to guard both the statements you've added with
> !targetm.calls.pretend_outgoing_args_named?
The TYPE_NO_NAMED_ARGS_STDARG_P functions (C23 fns like void foo (...) {})
have NULL type_arg_types, so the list_length (type_arg_types) isn't done for
it, but it should be handled as if it was non-NULL but list length was 0.
So, for the
if (type_arg_types != 0)
n_named_args
= (list_length (type_arg_types)
/* Count the struct value address, if it is passed as a parm. */
+ structure_value_addr_parm);
else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
n_named_args = 0;
else
/* If we know nothing, treat all args as named. */
n_named_args = num_actuals;
case, I think guarding it by any target hooks is wrong, although
I guess it should have been
n_named_args = structure_value_addr_parm;
instead of
n_named_args = 0;
For the second
if (type_arg_types != 0
&& targetm.calls.strict_argument_naming (args_so_far))
;
else if (type_arg_types != 0
&& ! targetm.calls.pretend_outgoing_varargs_named (args_so_far))
/* Don't include the last named arg. */
--n_named_args;
else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
n_named_args = 0;
else
/* Treat all args as named. */
n_named_args = num_actuals;
I think we should treat those as if type_arg_types was non-NULL
with 0 elements in the list, except the --n_named_args would for
!structure_value_addr_parm lead to n_named_args = -1, I think we want
0 for that case.
2024-03-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/114136
* calls.cc (expand_call): For TYPE_NO_NAMED_ARGS_STDARG_P set
n_named_args initially before INIT_CUMULATIVE_ARGS to
structure_value_addr_parm rather than 0, after it don't modify
it if strict_argument_naming and clear only if
!pretend_outgoing_varargs_named.
Jakub Jelinek [Fri, 1 Mar 2024 10:07:36 +0000 (11:07 +0100)]
function: Fix another TYPE_NO_NAMED_ARGS_STDARG_P spot
When looking at PR114175 (although that bug seems to be now a riscv backend
bug), I've noticed that for the TYPE_NO_NAMED_ARGS_STDARG_P functions which
return value through hidden reference, like
#include <stdarg.h>
struct S { char a[64]; };
int n;
struct S
foo (...)
{
struct S s = {};
va_list ap;
va_start (ap);
for (int i = 0; i < n; ++i)
if ((i & 1))
s.a[0] += va_arg (ap, double);
else
s.a[0] += va_arg (ap, int);
va_end (ap);
return s;
}
we were incorrectly calling assign_parms_setup_varargs twice, once
at the start of the function and once in
if (cfun->stdarg && !DECL_CHAIN (parm))
assign_parms_setup_varargs (&all, &data, false);
where parm is the last and only "named" parameter.
The first call, guarded with TYPE_NO_NAMED_ARGS_STDARG_P, was added in
r13-3549 and is needed for int bar (...) etc. functions using
va_start/va_arg/va_end, otherwise the
FOR_EACH_VEC_ELT (fnargs, i, parm)
in which the other call is will not iterate at all. But we shouldn't
be doing that if we have the hidden return pointer.
With the following patch on the above testcase with -O0 -std=c23 the
assembly difference is:
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
pushq %rbx
subq $192, %rsp
.cfi_offset 3, -24
- movq %rdi, -192(%rbp)
- movq %rsi, -184(%rbp)
- movq %rdx, -176(%rbp)
- movq %rcx, -168(%rbp)
- movq %r8, -160(%rbp)
- movq %r9, -152(%rbp)
- testb %al, %al
- je .L2
- movaps %xmm0, -144(%rbp)
- movaps %xmm1, -128(%rbp)
- movaps %xmm2, -112(%rbp)
- movaps %xmm3, -96(%rbp)
- movaps %xmm4, -80(%rbp)
- movaps %xmm5, -64(%rbp)
- movaps %xmm6, -48(%rbp)
- movaps %xmm7, -32(%rbp)
-.L2:
movq %rdi, -312(%rbp)
movq %rdi, -192(%rbp)
movq %rsi, -184(%rbp)
movq %rdx, -176(%rbp)
movq %rcx, -168(%rbp)
movq %r8, -160(%rbp)
movq %r9, -152(%rbp)
testb %al, %al
- je .L13
+ je .L12
movaps %xmm0, -144(%rbp)
movaps %xmm1, -128(%rbp)
movaps %xmm2, -112(%rbp)
movaps %xmm3, -96(%rbp)
movaps %xmm4, -80(%rbp)
movaps %xmm5, -64(%rbp)
movaps %xmm6, -48(%rbp)
movaps %xmm7, -32(%rbp)
-.L13:
+.L12:
plus some renumbering of labels later on which clearly shows
that because of this bug, we were saving all the registers twice
rather then once. With -O2 -std=c23 some of it is DCEd, but we still get
subq $160, %rsp
.cfi_def_cfa_offset 168
- testb %al, %al
- je .L2
- movaps %xmm0, 24(%rsp)
- movaps %xmm1, 40(%rsp)
- movaps %xmm2, 56(%rsp)
- movaps %xmm3, 72(%rsp)
- movaps %xmm4, 88(%rsp)
- movaps %xmm5, 104(%rsp)
- movaps %xmm6, 120(%rsp)
- movaps %xmm7, 136(%rsp)
-.L2:
movq %rdi, -24(%rsp)
movq %rsi, -16(%rsp)
movq %rdx, -8(%rsp)
movq %rcx, (%rsp)
movq %r8, 8(%rsp)
movq %r9, 16(%rsp)
testb %al, %al
- je .L13
+ je .L12
movaps %xmm0, 24(%rsp)
movaps %xmm1, 40(%rsp)
movaps %xmm2, 56(%rsp)
movaps %xmm3, 72(%rsp)
movaps %xmm4, 88(%rsp)
movaps %xmm5, 104(%rsp)
movaps %xmm6, 120(%rsp)
movaps %xmm7, 136(%rsp)
-.L13:
+.L12:
difference, i.e. this time not all, but the floating point args
were conditionally all saved twice.
2024-03-01 Jakub Jelinek <jakub@redhat.com>
* function.cc (assign_parms): Only call assign_parms_setup_varargs
early for TYPE_NO_NAMED_ARGS_STDARG_P functions if fnargs is empty.
Jakub Jelinek [Wed, 28 Feb 2024 08:59:45 +0000 (09:59 +0100)]
graphite: Fix non-INTEGER_TYPE integral comparison handling [PR114041]
The following testcases are miscompiled, because graphite ignores boolean,
enumerated or _BitInt comparisons, rewrites the code as if the comparisons
were always true or always false.
The INTEGER_TYPE checks were initially added in r6-2239 but at that point
it was both in add_conditions_to_domain and in parameter_index_in_region.
Later on the check was also added to stmt_simple_for_scop_p, and finally
r8-3931 changed the stmt_simple_for_scop_p check to INTEGRAL_TYPE_P
and turned the parameter_index_in_region -> assign_parameter_index_in_region
into INTEGRAL_TYPE_P assertion, but the add_conditions_to_domain check
for INTEGER_TYPE remained.
The following patch uses INTEGRAL_TYPE_P to complete the change.
2024-02-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/114041
* graphite-sese-to-poly.cc (add_conditions_to_domain): Check for
INTEGRAL_TYPE_P check rather than INTEGER_TYPE.
Jakub Jelinek [Wed, 28 Feb 2024 08:26:51 +0000 (09:26 +0100)]
testsuite: Add c23-stdarg-4.c test variant where all functions return large struct
I think we have no coverage for the case where structure_value_addr_parm and
TYPE_NO_NAMED_ARGS_STDARG_P are both true. The
if (type_arg_types != 0)
n_named_args
= (list_length (type_arg_types)
/* Count the struct value address, if it is passed as a parm. */
+ structure_value_addr_parm);
else if (TYPE_NO_NAMED_ARGS_STDARG_P (funtype))
n_named_args = 0;
else
/* If we know nothing, treat all args as named. */
n_named_args = num_actuals;
code should probably have n_named_args = structure_value_addr_parm;
instead of n_named_args = 0;, this testcase is an attempt to see if
it is broken on any target.
Jakub Jelinek [Mon, 26 Feb 2024 09:08:45 +0000 (10:08 +0100)]
match.pd: Guard 2 simplifications on integral TYPE_OVERFLOW_UNDEFINED [PR114090]
These 2 patterns are incorrect on floating point, or for -fwrapv, or
for -ftrapv, or the first one for unsigned types (the second one is
mathematically correct, but we ought to just fold that to 0 instead).
So, the following patch properly guards this.
I think we don't need && !TYPE_OVERFLOW_SANITIZED (type) because
in both simplifications there would be UB before and after on
signed integer minimum.
Jakub Jelinek [Thu, 22 Feb 2024 18:32:02 +0000 (19:32 +0100)]
c: Handle scoped attributes in __has*attribute and scoped attribute parsing changes in -std=c11 etc. modes [PR114007]
We aren't able to parse __has_attribute (vendor::attr) (and __has_c_attribute
and __has_cpp_attribute) in strict C < C23 modes. While in -std=gnu* modes
or in -std=c23 there is CPP_SCOPE token, in -std=c* (except for -std=c23)
there are is just a pair of CPP_COLON tokens.
The c-lex.cc hunk adds support for that, but always returns 0 in that case
unlike the GCC 14+ version.
2024-02-22 Jakub Jelinek <jakub@redhat.com>
PR c/114007
gcc/c-family/
* c-lex.cc (c_common_has_attribute): Parse 2 CPP_COLONs with
the first one with COLON_SCOPE flag the same as CPP_SCOPE but
ensure 0 is returned then.
gcc/testsuite/
* gcc.dg/c23-attr-syntax-8.c: New test.
libcpp/
* include/cpplib.h (COLON_SCOPE): Define to PURE_ZERO.
* lex.cc (_cpp_lex_direct): When lexing CPP_COLON with another
colon after it, if !CPP_OPTION (pfile, scope) set COLON_SCOPE
flag on the first CPP_COLON token.
Jakub Jelinek [Thu, 22 Feb 2024 09:19:15 +0000 (10:19 +0100)]
call-cdce: Add missing BUILT_IN_*F{32,64}X handling and improve BUILT_IN_*L [PR113993]
The following testcase ICEs, because can_test_argument_range
returns true for BUILT_IN_{COSH,SINH,EXP{,M1,2}}{F32X,F64X}
among many other builtins, but get_no_error_domain doesn't handle
those.
float32x_type_node when supported in GCC always has DFmode, so that
case is easy (and call-cdce assumes that SFmode is IEEE float and DFmode
is IEEE double). So *F32X is simply handled by adding those cases
next to *F64.
float64x_type_node when supported in GCC by definition has a mode
with larger precision and exponent range than DFmode, so it can be XFmode,
TFmode or KFmode. I went through all the l/f128 suffixed builtins and
verified that the float128x_type_node no error domain range is actually
identical to the Intel extended long double no error domain range; it isn't
that surprising, both IEEE quad and Intel/Motorola extended have the same
exponent range [-16381, 16384] (well, Motorola -16382 probably because of
different behavior for denormals, but that has nothing to do with
get_no_error_domain which is about large inputs overflowing into +-Inf
or triggering NaN, denormals could in theory do something solely for sqrt
and even that is fine). In theory some target could have different larger
type, so for *F64X the code verifies that
REAL_MODE_FORMAT (TYPE_MODE (float64x_type_node))->emax == 16384
and if so, uses the *F128 domains, otherwise falls back to the non-suffixed
ones (aka *F64), that is certainly the conservative minimum.
While at it, the patch also changes the *L suffixed cases to do pretty much
the same, the comment said that the function just assumes for *L
the *F64 ranges, but that is unnecessarily conservative.
All we currently have for long double is:
1) IEEE quad (emax 16384, *F128 ranges)
2) XFmode Intel/Motorola extended (emax 16384, same as *F128 ranges)
3) IBM extended (double double, emax 1024, the extra precision doesn't
really help and the domains are the same as for *F64)
4) same as double (*F64 again)
So, the patch uses also for *L
REAL_MODE_FORMAT (TYPE_MODE (long_double_type_node))->emax == 16384
checks and either tail recurses into the *F128 case for that or to
non-suffixed (aka *F64) case otherwise.
BUILT_IN_*F128X not handled because no target has those and it doesn't
seem something is on the horizon and who knows what would be used for that.
Thus, all we get this wrong for are probably VAX floats or something
similar, no intent from me to look at that, that is preexisting issue.
BTW, I'm surprised we don't have BUILT_IN_EXP10F{16,32,64,128,32X,64X,128X}
builtins, seems glibc has those (sure, I think except *16 and *128x).
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 [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, 3 Feb 2024 13:37:19 +0000 (14:37 +0100)]
ggc-common: Fix save PCH assertion
We are getting a gnuradio PCH ICE
/usr/include/pybind11/stl.h:447:1: internal compiler error: in gt_pch_save, at ggc-common.cc:693
0x1304e7d gt_pch_save(_IO_FILE*)
../../gcc/ggc-common.cc:693
0x12a45fb c_common_write_pch()
../../gcc/c-family/c-pch.cc:175
0x18ad711 c_parse_final_cleanups()
../../gcc/cp/decl2.cc:5062
0x213988b c_common_parse_file()
../../gcc/c-family/c-opts.cc:1319
(unfortunately it isn't reproduceable always, but often needs
up to 100 attempts, isn't reproduceable in a cross etc.).
The bug is in the assertion I've added in gt_pch_save when adding
relocation support for the PCH files in case they happen not to be
mmapped at the selected address.
addr is a relocated address which points to a location in the PCH
blob (starting at mmi.preferred_base, with mmi.size bytes) which contains
a pointer that needs to be relocated. So the assertion is meant to
verify the address is within the PCH blob, obviously it needs to be
equal or above mmi.preferred_base, but I got the other comparison wrong
and when one is very unlucky and the last sizeof (void *) bytes of the
blob happen to be a pointer which needs to be relocated, such as on the
s390x host addr 0x8008a04ff8, mmi.preferred_base 0x8000000000 and
mmi.size 0x8a05000, addr + sizeof (void *) is equal to mmi.preferred_base +
mmi.size and that is still fine, both addresses are end of something.
2024-02-03 Jakub Jelinek <jakub@redhat.com>
* ggc-common.cc (gt_pch_save): Allow addr to be equal to
mmi.preferred_base + mmi.size - sizeof (void *).
Jakub Jelinek [Wed, 31 Jan 2024 09:56:56 +0000 (10:56 +0100)]
simplify-rtx: Fix up last argument to simplify_gen_unary [PR113656]
When simplifying e.g. (float_truncate:SF (float_truncate:DF (reg:XF))
or (float_truncate:SF (float_extend:XF (reg:DF)) etc. into
(float_truncate:SF (reg:XF)) or (float_truncate:SF (reg:DF)) we call
simplify_gen_unary with incorrect op_mode argument, it should be
the argument's mode, but we call it with the outer mode instead.
As these are all floating point operations, the argument always
has non-VOIDmode and so we can just use that mode (as done in similar
simplifications a few lines later), but neither FLOAT_TRUNCATE nor
FLOAT_EXTEND are operations that should have the same modes of operand
and result. This bug hasn't been a problem for years because normally
op_mode is used only if the mode of op is VOIDmode, otherwise it is
redundant, but r10-2139 added an assertion in some spots that op_mode
is right even in such cases.
2024-01-31 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/113656
* simplify-rtx.cc (simplify_context::simplify_unary_operation_1)
<case FLOAT_TRUNCATE>: Fix up last argument to simplify_gen_unary.
Jakub Jelinek [Tue, 30 Jan 2024 08:58:05 +0000 (09:58 +0100)]
tree-ssa-strlen: Fix up handle_store [PR113603]
Since r10-2101-gb631bdb3c16e85f35d3 handle_store uses
count_nonzero_bytes{,_addr} which (more recently limited to statements
with the same vuse) can walk earlier statements feeding the rhs
of the store and call get_stridx on it.
Unlike most of the other functions where get_stridx is called first on
rhs and only later on lhs, handle_store calls get_stridx on the lhs before
the count_nonzero_bytes* call and does some si->nonzero_bytes comparison
on it.
Now, strinfo structures are refcounted and it is important not to screw
it up.
What happens on the following testcase is that we call get_strinfo on the
destination idx's base (g), which returns a strinfo at that moment
with refcount of 2, one copy referenced in bb 2 final strinfos, one in bb 3
(the vector of strinfos was unshared from the dominator there because some
other strinfo was added) and finally we process a store in bb 6.
Now, count_nonzero_bytes is called and that sees &g[1] in a PHI and
calls get_stridx on it, which in turn calls get_stridx_plus_constant
because &g + 1 address doesn't have stridx yet. This creates a new
strinfo for it:
si = new_strinfo (ptr, idx, build_int_cst (size_type_node, nonzero_chars),
basesi->full_string_p);
set_strinfo (idx, si);
and the latter call, because it is the first one in bb 6 that needs it,
unshares the stridx_to_strinfo vector (so refcount of the g strinfo becomes
3).
Now, get_stridx_plus_constant needs to chain the new strinfo of &g[1] in
between the related strinfos, so after the g record. Because the strinfo
is now shared between the current bb and 2 other bbs, it needs to
unshare_strinfo it (creating a new strinfo which can be modified as a copy
of the old one, decrementing refcount of the old shared one and setting
refcount of the new one to 1):
if (strinfo *nextsi = get_strinfo (chainsi->next))
{
nextsi = unshare_strinfo (nextsi);
si->next = nextsi->idx;
nextsi->prev = idx;
}
chainsi = unshare_strinfo (chainsi);
if (chainsi->first == 0)
chainsi->first = chainsi->idx;
chainsi->next = idx;
Now, the bug is that the caller of this a couple of frames above,
handle_store, holds on a pointer to this g strinfo (but doesn't know
about the unsharing, so the pointer is to the old strinfo with refcount
of 2), and later needs to update it, so it
si = unshare_strinfo (si);
and modifies some fields in it.
This creates a new strinfo (with refcount of 1 which is stored into
the vector of the current bb) based on the old strinfo for g and
decrements refcount of the old one to 1. So, now we are in inconsistent
state, because the old strinfo for g is referenced in bb 2 and bb 3
vectors, but has just refcount of 1, and then have one strinfo (the one
created by unshare_strinfo (chainsi) in get_stridx_plus_constant) which
has refcount of 1 but isn't referenced from anywhere anymore.
Later on when we free one of the bb 2 or bb 3 vectors (forgot which)
that decrements refcount from 1 to 0 and poisons the strinfo/returns it to
the pool, but then maybe_invalidate when looking at the other bb's pointer
to it ICEs.
The following patch fixes it by calling get_strinfo again, it is guaranteed
to return non-NULL, but could be an unshared copy instead of the originally
fetched shared one.
I believe we only need to do this refetching for the case where get_strinfo
is called on the lhs before get_stridx is called on other operands, because
we should be always modifying (apart from the chaining changes) the strinfo
for the destination of the statements, not other strinfos just consumed in
there.
2024-01-30 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113603
* tree-ssa-strlen.cc (strlen_pass::handle_store): After
count_nonzero_bytes call refetch si using get_strinfo in case it
has been unshared in the meantime.
Jakub Jelinek [Thu, 18 Jan 2024 09:21:12 +0000 (10:21 +0100)]
i386: Add -masm=intel profiling support [PR113122]
x86_function_profiler emits assembly directly into file and only emits
AT&T syntax. The following patch adjusts it to emit MASM syntax
if -masm=intel.
As it doesn't use asm_fprintf, I can't use {|} syntax for the dialects.
I've tested using
for i in -mcmodel=large "-mcmodel=large -fpic" "" -fpic "-m32 -fpic" "-m32"; do
./xgcc -B ./ -c -O2 -fprofile $i -masm=att pr113122.c -o pr113122.o1;
./xgcc -B ./ -c -O2 -fprofile $i -masm=intel pr113122.c -o pr113122.o2;
objdump -dr pr113122.o1 > /tmp/1; objdump -dr pr113122.o2 > /tmp/2;
diff -up /tmp/1 /tmp/2; done
that the emitted sequences are identical after assembly.
2024-01-18 Jakub Jelinek <jakub@redhat.com>
PR target/113122
* config/i386/i386.cc (x86_function_profiler): Add -masm=intel
support. Add missing space after , in emitted assembly in some
cases. Formatting fixes.
* gcc.target/i386/pr113122-1.c: New test.
* gcc.target/i386/pr113122-2.c: New test.
* gcc.target/i386/pr113122-3.c: New test.
* gcc.target/i386/pr113122-4.c: New test.
Jakub Jelinek [Tue, 16 Jan 2024 10:49:34 +0000 (11:49 +0100)]
cfgexpand: Workaround CSE of ADDR_EXPRs in VAR_DECL partitioning [PR113372]
The following patch adds a quick workaround to bugs in VAR_DECL
partitioning.
The problem is that there is no dependency between ADDR_EXPRs of local
decls and CLOBBERs of those vars, so VN can CSE uses of ADDR_EXPRs
(including ivopts integral variants thereof), which can break
add_scope_conflicts discovery of what variables are actually used
in certain region.
E.g. we can have
ivtmp.40_3 = (unsigned long) &MEM <unsigned long[100]> [(void *)&bitint.6 + 8B];
...
uses of ivtmp.40_3
...
bitint.6 ={v} {CLOBBER(eos)};
...
ivtmp.28_43 = (unsigned long) &MEM <unsigned long[100]> [(void *)&bitint.6 + 8B];
...
uses of ivtmp.28_43
before VN (such as dom3), which the add_scope_conflicts code identifies as 2
independent uses of bitint.6 variable (which is correct), but then VN
determines ivtmp.28_43 is the same as ivtmp.40_3 and just uses ivtmp.40_3
even in the second region; at that point add_scope_conflict thinks the
bitint.6 variable is not used in that region anymore.
The following patch does a simple single def-stmt check for such ADDR_EXPRs
(rather than say trying to do a full propagation of what SSA_NAMEs can
contain ADDR_EXPRs of local variables), which seems to workaround all 4 PRs.
In addition to this patch I've used the attached one to gather statistics
on the total size of all variable partitions in a function and seems besides
the new testcases nothing is really affected compared to no patch (I've
actually just modified the patch to == OMP_SCAN instead of == ADDR_EXPR, so
it looks the same except that it never triggers). The comparison wasn't
perfect because I've only gathered BITS_PER_WORD, main_input_filename (did
some replacement of build directories and /tmp/ccXXXXXX names of LTO to make
it more similar between the two bootstraps/regtests), current_function_name
and the total size of all variable partitions if any, because I didn't
record e.g. the optimization options and so e.g. torture tests which iterate
over options could have different partition sizes even in one compiler when
BITS_PER_WORD, main_input_filename and current_function_name are all equal.
So had to write an awk script to check if the first triple in the second
build appeared in the first one and the quadruple in the second build
appeared in the first one too, otherwise print result and that only
triggered in the new tests.
Also, the cc1plus binary according to objdump -dr is identical between the
two builds except for the ADDR_EXPR vs. OMP_SCAN constant in the two spots.
2024-01-16 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113372
PR middle-end/90348
PR middle-end/110115
PR middle-end/111422
* cfgexpand.cc (add_scope_conflicts_2): New function.
(add_scope_conflicts_1): Use it.
* gcc.c-torture/execute/pr90348.c: New test.
* gcc.c-torture/execute/pr110115.c: New test.
* gcc.c-torture/execute/pr111422.c: New test.
Jakub Jelinek [Wed, 10 Jan 2024 12:29:47 +0000 (13:29 +0100)]
libgomp: Fix up FLOCK fallback handling [PR113192]
My earlier change broke Solaris testing, because @FLOCK@ isn't substituted
just into libgomp/Makefile where it worked, but also the
testsuite/libgomp-site-extra.exp file where Make variables aren't present
and can't be substituted.
The following patch instead computes the absolute srcdir path and uses it
for FLOCK.
2024-01-10 Jakub Jelinek <jakub@redhat.com>
PR libgomp/113192
* configure.ac (FLOCK): Use $libgomp_abs_srcdir/testsuite/flock
instead of \$(abs_top_srcdir)/testsuite/flock.
* configure: Regenerated.
The copy attributes is allowed on decls as well as types and even has
checks whether decl (set to *node) is DECL_P or TYPE_P, but for diagnostics
unconditionally uses DECL_SOURCE_LOCATION (decl), which obviously only works
if it applies to a decl.
2024-01-09 Jakub Jelinek <jakub@redhat.com>
PR c/113262
* c-attribs.cc (handle_copy_attribute): Don't use
DECL_SOURCE_LOCATION (decl) if decl is not DECL_P, use input_location
instead. Formatting fixes.
Jakub Jelinek [Tue, 9 Jan 2024 08:54:06 +0000 (09:54 +0100)]
libgomp: Use absolute pathname to testsuite/flock [PR113192]
When flock program doesn't exist, libgomp configure attempts to
offer a fallback version using a perl script, but we weren't using
absolute filename to that, so it apparently failed to work correctly.
The following patch arranges for it to get the absolute filename.
Tested by John David in the PR.
2024-01-09 Jakub Jelinek <jakub@redhat.com>
PR libgomp/113192
* configure.ac (FLOCK): Use \$(abs_top_srcdir)/testsuite/flock
rather than $srcdir/testsuite/flock.
* configure: Regenerated.
Jakub Jelinek [Fri, 22 Dec 2023 11:29:34 +0000 (12:29 +0100)]
combine: Don't optimize paradoxical SUBREG AND CONST_INT on WORD_REGISTER_OPERATIONS targets [PR112758]
As discussed in the PR, the following testcase is miscompiled on RISC-V
64-bit, because num_sign_bit_copies in one spot pretends the bits in
a paradoxical SUBREG beyond SUBREG_REG SImode are all sign bit copies:
5444 /* For paradoxical SUBREGs on machines where all register operations
5445 affect the entire register, just look inside. Note that we are
5446 passing MODE to the recursive call, so the number of sign bit
5447 copies will remain relative to that mode, not the inner mode.
5448
5449 This works only if loads sign extend. Otherwise, if we get a
5450 reload for the inner part, it may be loaded from the stack, and
5451 then we lose all sign bit copies that existed before the store
5452 to the stack. */
5453 if (WORD_REGISTER_OPERATIONS
5454 && load_extend_op (inner_mode) == SIGN_EXTEND
5455 && paradoxical_subreg_p (x)
5456 && MEM_P (SUBREG_REG (x)))
and then optimizes based on that in one place, but then the
r7-1077 optimization triggers in and treats all the upper bits in
paradoxical SUBREG as undefined and performs based on that another
optimization. The r7-1077 optimization is done only if SUBREG_REG
is either a REG or MEM, from the discussions in the PR seems that if
it is a REG, the upper bits in paradoxical SUBREG on
WORD_REGISTER_OPERATIONS targets aren't really undefined, but we can't
tell what values they have because we don't see the operation which
computed that REG, and for MEM it depends on load_extend_op - if
it is SIGN_EXTEND, the upper bits are sign bit copies and so something
not really usable for the optimization, if ZERO_EXTEND, they are zeros
and it is usable for the optimization, for UNKNOWN I think it is better
to punt as well.
So, the following patch basically disables the r7-1077 optimization
on WORD_REGISTER_OPERATIONS unless we know it is still ok for sure,
which is either if sub_width is >= BITS_PER_WORD because then the
WORD_REGISTER_OPERATIONS rules don't apply, or load_extend_op on a MEM
is ZERO_EXTEND.
2023-12-22 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/112758
* combine.cc (make_compopund_operation_int): Optimize AND of a SUBREG
based on nonzero_bits of SUBREG_REG and constant mask on
WORD_REGISTER_OPERATIONS targets only if it is a zero extending
MEM load.
Jonathan Wakely [Tue, 27 Feb 2024 17:50:34 +0000 (17:50 +0000)]
libstdc++: Fix conditions for using memcmp in std::lexicographical_compare_three_way [PR113960]
The change in r11-2981-g2f983fa69005b6 meant that
std::lexicographical_compare_three_way started to use memcmp for
unsigned integers on big endian targets, but for that to be valid we
need the two value types to have the same size and we need to use that
size to compute the length passed to memcmp.
I already defined a __is_memcmp_ordered_with trait that does the right
checks, std::lexicographical_compare_three_way just needs to use it.
libstdc++-v3/ChangeLog:
PR libstdc++/113960
* include/bits/stl_algobase.h (__is_byte_iter): Replace with ...
(__memcmp_ordered_with): New concept.
(lexicographical_compare_three_way): Use __memcmp_ordered_with
instead of __is_byte_iter. Use correct length for memcmp.
* testsuite/25_algorithms/lexicographical_compare_three_way/113960.cc:
New test.
Jonathan Wakely [Sat, 18 Nov 2023 21:09:53 +0000 (21:09 +0000)]
libstdc++: Fix std::tr2::dynamic_bitset support for alternate characters
libstdc++-v3/ChangeLog:
* include/tr2/dynamic_bitset (dynamic_bitset): Pass zero and one
characters to _M_copy_from_string.
* testsuite/tr2/dynamic_bitset/string.cc: New test.
Jonathan Wakely [Tue, 14 Nov 2023 10:56:57 +0000 (10:56 +0000)]
libstdc++: Fix <charconv> uses of signed types with <bit> functions
In <charconv> we pass the int __base parameter to our internal versions
of <bit> functions, __bit_width and __countr_zero. Those functions are
only defined for unsigned types, so we need to convert the base to
unsigned. The base must be in the range [2,36] so we can mask off the
low bits and then convert that to unsigned, so that we don't need to
care about negative values becoming large unsigned values.
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_pow2_base): Convert base to
unsigned for call to __countr_zero.
(__from_chars_alnum): Likewise for call to __bit_width.
Jonathan Wakely [Thu, 23 Nov 2023 14:34:59 +0000 (14:34 +0000)]
libstdc++: Fix access error in __gnu_test::uneq_allocator
The operator== function is only a friend of the LHS argument, so cannot
access the private member of the RHS argument. Use the public accessor
instead.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_allocator.h (uneq_allocator): Fix
equality operator for heterogeneous comparisons.
Andrew Pinski [Thu, 29 Feb 2024 06:39:32 +0000 (22:39 -0800)]
aarch64: Fix memtag builtins vs GC [PR108174]
The memtag builtins were being GC'ed away so we end up
with a crash sometimes (maybe even wrong code).
This fixes that issue by adding GTY on the variable/struct
aarch64_memtag_builtin_data.
Committed as obvious after a build/test for aarch64-linux-gnu.
PR target/108174
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.cc (aarch64_memtag_builtin_data): Make
static and mark with GTY.
git://gcc.gnu.org / gcc.git / log