ada: Fix error on Designated_Storage_Model with extensions disabled
The format string used for the error in that case requires setting the
Error_Msg_Name_1 global variable. This was not done so this patch adds
the missing assignment.
Andrew Pinski [Tue, 20 May 2025 20:21:28 +0000 (13:21 -0700)]
middle-end: Fix complex lowering of cabs with no LHS [PR120369]
This was introduced by r15-1797-gd8fe4f05ef448e . I had missed that
the LHS of the cabs call could be NULL. This seems to only happen at -O0,
I tried to produce one that happens at -O1 but needed many different
options to prevent the removal of the call.
Anyways the fix is just keep around the call if the LHS is null.
Bootstrapped and tested on x86_64-linux-gnu.
PR middle-end/120369
gcc/ChangeLog:
* tree-complex.cc (gimple_expand_builtin_cabs): Return early
if the LHS of cabs is null.
Patrick Palka [Thu, 3 Jul 2025 14:55:17 +0000 (10:55 -0400)]
libstdc++: Update LWG 4166 changes to concat_view::end() [PR120934]
In r15-4555-gf191c830154565 we proactively implemented the initial
proposed resolution for LWG 4166 which later turned out to be
insufficient, since we must also require equality_comparable of the
underlying iterators before concat_view could be a common range.
This patch implements the updated P/R, requiring all underlying
iterators to be forward (which implies equality_comparable) before
making concat_view common, which fixes the testcase from this PR.
PR libstdc++/120934
libstdc++-v3/ChangeLog:
* include/std/ranges (concat_view::end): Refine condition
for returning an iterator instead of default_sentinel as
per the updated P/R for LWG 4166.
* testsuite/std/ranges/concat/1.cc (test05): New test.
Jason Merrill [Wed, 2 Jul 2025 22:03:57 +0000 (18:03 -0400)]
c++: uninitialized TARGET_EXPR and constexpr [PR120684]
In r15-7532 for PR118856 I introduced a TARGET_EXPR with a
TARGET_EXPR_INITIAL of void_node to express that no initialization is done.
And indeed evaluating that doesn't store a value for the TARGET_EXPR_SLOT
variable.
But then at the end of the full-expression, destroy_value stores void_node
to express that its lifetime has ended. If we evaluate the same
full-expression again, global_ctx->values still holds the void_node, causing
confusion when we try to destroy it again. So clear out any value before
evaluating a TARGET_EXPR_INITIAL of void_type.
PR c++/120684
PR c++/118856
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression) [TARGET_EXPR]: Clear
the value first if is_complex.
Jonathan Wakely [Wed, 2 Jul 2025 20:54:06 +0000 (21:54 +0100)]
libstdc++: Fix regression in std::uninitialized_fill for C++98 [PR120931]
A typo in r15-4473-g3abe751ea86e34 made it ill-formed to use
std::uninitialized_fill with iterators that aren't pointers (or pointers
wrapped in our __normal_iterator) if the value type is a narrow
character type.
libstdc++-v3/ChangeLog:
PR libstdc++/120931
* include/bits/stl_uninitialized.h (__uninitialized_fill<true>):
Fix typo resulting in call to __do_uninit_copy instead of
__do_uninit_fill.
* testsuite/20_util/specialized_algorithms/uninitialized_fill/120931.cc:
New test.
Fortran: Fix out of bounds access in structure constructor's clean up [PR120711]
A structure constructor's generated clean up code was using an offset
variable, which was manipulated before the clean up was run leading to
an out of bounds access.
PR fortran/120711
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_array_ctor_element): Store the value
of the offset for reuse.
gcc/testsuite/ChangeLog:
* gfortran.dg/asan/array_constructor_1.f90: New test.
Eric Botcazou [Mon, 26 May 2025 07:25:57 +0000 (09:25 +0200)]
ada: Fix alignment violation for mix of aligned and misaligned composite types
This happens when the chain of initialization procedures is called on the
subcomponents and causes the creation of temporaries along the way out of
alignment considerations. Now these temporaries are not necessary in the
context and were not created until recently, so this gets rid of them.
gcc/ada/ChangeLog:
* gcc-interface/trans.cc (addressable_p): Add COMPG third parameter.
<COMPONENT_REF>: Do not return true out of alignment considerations
for non-strict-alignment targets if COMPG is set.
(Call_to_gnu): Pass true as COMPG in the call to the addressable_p
predicate if the called subprogram is an initialization procedure.
Eric Botcazou [Tue, 6 May 2025 17:14:40 +0000 (19:14 +0200)]
ada: Fix wrong finalization of constrained subtype of unconstrained array type
This implements the Is_Constr_Array_Subt_With_Bounds flag for allocators.
gcc/ada/ChangeLog:
* gcc-interface/trans.cc (gnat_to_gnu) <N_Allocator>: Allocate the
bounds alongside the data if the Is_Constr_Array_Subt_With_Bounds
flag is set on the designated type.
<N_Free_Statement>: Take into account the allocated bounds if the
Is_Constr_Array_Subt_With_Bounds flag is set on the designated type.
Eric Botcazou [Thu, 1 May 2025 23:30:56 +0000 (01:30 +0200)]
ada: Fix missing error on too large Component_Size not multiple of storage unit
This is a small regression introduced a few years ago.
gcc/ada/ChangeLog:
* gcc-interface/decl.cc (gnat_to_gnu_component_type): Validate the
Component_Size like the size of a type only if the component type
is actually packed.
Insert_Actions performs a sanity check when it goes through an
expression with actions while going up the three. That check was not
perfectly right before this patch and spuriously failed when inserting
range checks in some situation. This patch makes the check more robust.
The Finalizable aspect introduced controlled types for which not all the
finalization primitives exist. This patch makes Make_Deep_Record_Body
handle this case correctly.
gcc/ada/ChangeLog:
* exp_ch7.adb (Make_Deep_Record_Body): Fix case of absent Initialize
primitive.
Since the introduction of the Finalizable aspect, there can be types
for which Is_Controlled returns True but that don't have all three
finalization primitives. The Generate_Finalization_Actions raised an
exception in that case before this patch, which fixes the problem.
gcc/ada/ChangeLog:
* exp_aggr.adb (Generate_Finalization_Actions): Stop assuming that
initialize primitive exists.
ada: Fix assertion failure on finalizable aggregate
The Finalizable aspect makes it possible that
Insert_Actions_In_Scope_Around is entered with an empty list of after
actions. This patch fixes a condition that was not quite right in this
case.
Eric Botcazou [Tue, 27 May 2025 11:32:18 +0000 (13:32 +0200)]
ada: Fix wrong conversion of controlled array with representation change
The problem is that a temporary is created for the conversion because of the
representation change, and it is finalized without having been initialized.
gcc/ada/ChangeLog:
* exp_ch4.adb (Handle_Changed_Representation): Alphabetize local
variables. Set the No_Finalize_Actions flag on the assignment.
Sam James [Mon, 23 Jun 2025 22:28:01 +0000 (23:28 +0100)]
Fixup dropping REG_EQUAL note in ext-dce
Followup to r16-1613-g34e1e5e33ec3eb. remove_reg_equal_equiv_notes's
2nd argument is 'no_rescan' which we accidentally had on, tripping
an assert in combine or ira because we hadn't left things in a consistent
state.
Fix the thinko by enabling rescanning.
gcc/ChangeLog:
PR rtl-optimization/120795
* ext-dce.cc (ext_dce_try_optimize_insn): Enable rescan in
remove_reg_equal_equiv_notes call.
Jeff Law [Sun, 22 Jun 2025 18:06:08 +0000 (12:06 -0600)]
[committed][PR rtl-optimization/120550] Drop REG_EQUAL note after ext-dce transformation
This bug was found by Edwin's fuzzing efforts on RISC-V, though it likely
affects other targets.
In simplest terms when ext-dce converts an extension into a (possibly
simplified) subreg copy it may make an attached REG_EQUAL note invalid.
In the case Edwin found the note was an extension, but I don't think that would
necessarily always be the case. The note could have other forms which
potentially need invalidation. So the safest thing to do is just remove any
attached REG_EQUAL or REG_EQUIV note.
Note adjusting Edwin's testcase in the obvious way to avoid having to interpret
printf output for pass/fail status makes the bug go latent. That's why no
testcase is included with this patch.
Bootstrapped and regression tested on x86_64. Obviously also verified it fixes
the testcase Edwin filed.
This is a good candidate for cherry-picking to the gcc-15 release branch after
simmering on the trunk a bit.
PR rtl-optimization/120550
gcc/
* ext-dce.cc (ext_dce_try_optimize_insn): Drop REG_EQUAL/REG_EQUIV
notes on modified insns.
Richard Biener [Wed, 2 Jul 2025 11:44:59 +0000 (13:44 +0200)]
Do not query further vector epilogues after a masked epilogue
When doing --param vect-partial-vector-usage=1 we'd continue querying
the target whether it wants more vector epilogues, but when it comes
back with a suggestion we then might iterate endlessly. Do not
even ask the target when we decided for the last epilogue to be
one with partial vectors.
PR tree-optimization/120927
* tree-vect-loop.cc (vect_analyze_loop): Stop querying
further epilogues after one with partial vectors.
Jakub Jelinek [Tue, 1 Jul 2025 17:37:39 +0000 (19:37 +0200)]
testsuite: Fix up gcc.target/powerpc/builtin_altivec_tr_stxvr_runnable.c test (test UB) [PR120919]
In my reading of the test and the instructions emitted by the
builtins, it invokes UB 4 times, each time overwriting one byte
after some variable (sc, then ss, then si and then sll).
If we are lucky, like at -O0 -mcpu=power10, there is just padding
there or something that doesn't make the tests fail, if unlucky
like with -O0 -mcpu=power10 -fstack-protector-strong,
&sc + 1 == &expected_sc
and so it overwrites the expected_sc variable.
The test fails when testing with
RUNTESTFLAGS="--target_board=unix/'{,-fstack-protector-strong}'"
on power10.
The following patch fixes that by using arrays of 2 elements, so that
the overwriting of 1 byte happens to the part of the same variable.
2025-07-01 Jakub Jelinek <jakub@redhat.com>
PR testsuite/120919
* gcc.target/powerpc/builtin_altivec_tr_stxvr_runnable.c (main): Change
sc, ss, si and sll vars from scalars to arrays of 2 elements,
initialize and test just the first one though.
Jakub Jelinek [Tue, 1 Jul 2025 13:28:10 +0000 (15:28 +0200)]
c++: Fix up cp_build_array_ref COND_EXPR handling [PR120471]
The following testcase is miscompiled since the introduction of UBSan,
cp_build_array_ref COND_EXPR handling replaces
(cond ? a : b)[idx] with cond ? a[idx] : b[idx], but if there are
SAVE_EXPRs inside of idx, they will be evaluated just in one of the
branches and the other uses uninitialized temporaries.
Fixed by keeping doing what it did if idx doesn't have side effects
and is invariant. Otherwise if op1/op2 are ARRAY_TYPE arrays with
invariant addresses or pointers with invariant values, use
SAVE_EXPR <op0>, SAVE_EXPR <idx>, SAVE_EXPR <op0> as a new condition
and SAVE_EXPR <idx> instead of idx for the recursive calls.
Otherwise punt, but if op1/op2 are ARRAY_TYPE, furthermore call
cp_default_conversion on array, so that COND_EXPR with ARRAY_TYPE doesn't
survive in the IL until expansion.
2025-07-01 Jakub Jelinek <jakub@redhat.com>
PR c++/120471
gcc/cp/
* typeck.cc (cp_build_array_ref) <case COND_EXPR>: If idx is not
INTEGER_CST, don't optimize the case (but cp_default_conversion on
array early if it has ARRAY_TYPE) or use
SAVE_EXPR <op0>, SAVE_EXPR <idx>, SAVE_EXPR <op0> as new op0 depending
on flag_strong_eval_order and whether op1 and op2 are arrays with
invariant address or tree invariant pointers. Formatting fixes.
gcc/testsuite/
* g++.dg/ubsan/pr120471.C: New test.
* g++.dg/parse/pr120471.C: New test.
Tomasz Kamiński [Fri, 13 Jun 2025 11:28:30 +0000 (13:28 +0200)]
libstdc++: Format %r, %x and %X using locale's time_put facet [PR120648]
Similarly to issue reported for %c in PR117214, the format string for locale
specific time (%r, %X) and date (%x) representations may contain specifiers
not accepted by chrono-spec, leading to exception being thrown. This
happened for following conversion specifier and locale combinations:
* %r, %X for aa_DJ.UTF-8, ar_SA.UTF-8
* %x for ca_AD.UTF-8, my_MM.UTF-8
This fix follows approach from r15-8490-gc24a1d5, and uses time_put to emit
localized date format. The existing _M_c is reworked to handle all locale
dependent conversion specifies, by accepting them as argument. It is also
renamed to _M_c_r_x_X.
PR libstdc++/120648
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (__formatter_chrono::_M_format_to):
Handle %c, %r, %x and %X by passing them to _M_c_r_x_X.
(__formatter_chrono::_M_c_r_x_X): Reworked from _M_c.
(__formatter_chrono::_M_c): Renamed into above.
(__formatter_chrono::_M_r, __formatter_chrono::_M_x)
(__formatter_chrono::_M_X): Removed.
* testsuite/std/time/format/pr117214.cc: New tests for %r, %x,
%X with date, time and durations.
Jakub Jelinek [Tue, 1 Jul 2025 15:33:32 +0000 (17:33 +0200)]
s390: Add -fno-stack-protector to 3 tests
In Fedora/RHEL we usually test with
make check RUNTESTFLAGS="--target_board=unix/'{,-fstack-protector-strong}'"
because -fstack-protector-strong is used when building pretty much all the
packages.
In the past Marek Polacek has committed tweaks to various tests to make
them PASS in such testing, see e.g. r14-6276 or r14-2200.
These 3 tests FAIL with -fstack-protector-strong on s390x because they
use check-function-bodies and aren't prepared for the extra
-fstack-protector-{strong,all} extra code in the prologue/epilogue.
Gary Dismukes [Tue, 20 May 2025 00:16:25 +0000 (00:16 +0000)]
ada: Fix for compiler crash on function return with Relaxed_Finalization parts
The compiler crashes on compiling a return statement of a function whose result
type has a component whose type is specified with Relaxed_Finalization. The
compiler was attempting to retrieve a nonexistent BIP_Collection extra formal
from the enclosing function, which may not exist in the case of result types
with Relaxed_Finalization.
gcc/ada/ChangeLog:
* exp_ch3.adb (Build_Heap_Or_Pool_Allocator): Test not Has_Relaxed_Finalization
as a guard against retrieving BIP_Collection formal (and related code).
Gary Dismukes [Fri, 16 May 2025 23:11:26 +0000 (23:11 +0000)]
ada: Compiler fails on unchecked deallocation for constrained protected subtype
The compiler fails with an error or Assert_Failure when calling
an instantiation of Unchecked_Deallocation that has been instantiated
with a constrained subtype of a discriminated protected type.
gcc/ada/ChangeLog:
* sem_ch3.adb (Constrain_Corresponding_Record): Inherit Class_Wide_Type on the
created constrained subtype.
Eric Botcazou [Tue, 6 May 2025 17:03:19 +0000 (19:03 +0200)]
ada: Fix wrong finalization of constrained subtype of unconstrained array type
Dynamically allocated objects of a constrained subtype of an unconstrained
array type with a controlled component type have not been properly finalized
since the first rewrite of the finalization machinery more than a decade
ago. The reason is that the Finalize_Address routine is that of the base
type, which is unconstrained, and thus requires the bounds, which are not
present for the subtype in the allocation.
This is fixed by setting Is_Constr_Array_Subt_With_Bounds for allocators the
same way it is set for object declarations. The rest is just refactoring.
gcc/ada/ChangeLog:
* exp_ch7.adb (Shift_Address_For_Descriptor): New function.
(Make_Address_For_Finalize): Call above function.
(Make_Finalize_Address_Stmts): Likewise.
* exp_util.ads (Is_Constr_Array_Subt_Of_Unc_With_Controlled): New
predicate.
* exp_util.adb (Is_Constr_Array_Subt_Of_Unc_With_Controlled): Ditto.
(Remove_Side_Effects): Call above predicate.
* sem_ch3.adb (Analyze_Object_Declaration): Likewise.
* sem_ch4.adb (Analyze_Allocator): Allocate the bounds by setting
Is_Constr_Array_Subt_With_Bounds when appropriate.
Eric Botcazou [Mon, 5 May 2025 14:59:13 +0000 (16:59 +0200)]
ada: Fix wrong finalization of constrained array derived from unconstrained
The bug had been present for dynamically allocated objects since the first
rewrite of the finalization machinery more than a decade ago, and was then
propagated to statically declared objects by the recent rewrite.
gcc/ada/ChangeLog:
* exp_util.adb (Finalize_Address): Do not go to the root type for
array types.
Eric Botcazou [Thu, 1 May 2025 23:10:36 +0000 (01:10 +0200)]
ada: Small cleanup in the finalization machinery
The generic finalization machinery and the finalization machinery for
transient objects disagree on which controlled objects should be finalized
indirectly, i.e. through an access value: the former only considers return
objects of (selected) function calls, whereas the latter considers all
objects designated by a reference, which means that it must be careful
about not finalizing them twice.
The discrepancy does not seem to cause problems in practice, but is awkward
and creates additional work for the finalization machinery for transient
objects, as well as code duplication.
gcc/ada/ChangeLog:
* exp_util.ads (Is_Finalizable_Access): New predicate.
(Is_Non_BIP_Func_Call): Delete.
(Is_Secondary_Stack_BIP_Func_Call): Likewise.
* exp_util.adb (Is_Finalizable_Access): New predicate.
(Initialized_By_Aliased_BIP_Func_Call): Delete.
(Initialized_By_Reference): Likewise.
(Is_Aliased): Only consider the nontransient object serviced by
the transient scope.
(Is_Part_Of_BIP_Return_Statement): Minor tweak.
(Is_Finalizable_Transient): Remove calls to Initialized_By_Reference
and Initialized_By_Aliased_BIP_Func_Call.
Call Is_Finalizable_Access for access objects.
(Is_Non_BIP_Func_Call): Delete.
(Is_Secondary_Stack_BIP_Func_Call): Likewise.
(Requires_Cleanup_Actions): Call Is_Finalizable_Access for access
objects.
(Side_Effect_Free): Return True for N_Reference.
* exp_ch7.adb (Build_Finalizer.Process_Declarations): Call
Is_Finalizable_Access for access objects.
Eric Botcazou [Fri, 2 May 2025 13:32:54 +0000 (15:32 +0200)]
ada: Fix wrong finalization of temporary constrained array of controlled type
This regression has been introduced by the rewrite of the finalization
machinery, which now requires a specific handling of constrained array
types with controlled component and an unconstrained first subtype.
gcc/ada/ChangeLog:
* exp_util.adb (Is_Expression_Of_Func_Return): New predicate.
(Is_Related_To_Func_Return): Call Is_Expression_Of_Func_Return.
(Remove_Side_Effects): Generate a temporary for a function call
that returns a constrained array type with controlled component
and an unconstrained first subtype.
Jakub Jelinek [Tue, 1 Jul 2025 09:26:45 +0000 (11:26 +0200)]
tailc: Handle musttail in case of non-cleaned-up cleanups, especially ASan related [PR120608]
The following testcases FAIL at -O0 -fsanitize=address. The problem is
we end up with something like
_26 = foo (x_24(D)); [must tail call]
// predicted unlikely by early return (on trees) predictor.
finally_tmp.3_27 = 0;
goto <bb 5>; [INV]
...
<bb 5> :
# _6 = PHI <_26(3), _23(D)(4)>
# finally_tmp.3_8 = PHI <finally_tmp.3_27(3), finally_tmp.3_22(4)>
.ASAN_MARK (POISON, &c, 4);
if (finally_tmp.3_8 == 1)
goto <bb 7>; [INV]
else
goto <bb 6>; [INV]
<bb 11> :
<L11>:
return _7;
before the sanopt pass. This is -O0, we don't try to do forward
propagation, jump threading etc. And what is worse, the sanopt
pass lowers the .ASAN_MARK calls that the tailc/musttail passes
already handle into somewthing that they can't easily pattern match.
The following patch fixes that by
1) moving the musttail pass 2 passes earlier (this is mostly just
for -O0/-Og, for normal optimization levels musttail calls are
handled in the tailc pass), i.e. across the sanopt and cleanup_eh
passes
2) recognizes these finally_tmp SSA_NAME assignments, PHIs using those
and GIMPLE_CONDs deciding based on those both on the backwards
walk (when we start from the edges to EXIT) and forwards walk
(when we find a candidate tail call and process assignments
after those up to the return statement). For backwards walk,
ESUCC argument has been added which is either NULL for the
noreturn musttail case, or the succ edge through which we've
reached bb and if it sees GIMPLE_COND with such comparison,
based on the ESUCC and comparison it will remember which later
edges to ignore later on and which bb must be walked up to the
start during tail call discovery (the one with the PHI).
3) the move of musttail pass across cleanup_eh pass resulted in
g++.dg/opt/pr119613.C regressions but moving cleanup_eh before
sanopt doesn't work too well, so I've extended
empty_eh_cleanup to also handle resx which doesn't throw
externally
I know moving a pass on release branches feels risky, though the
musttail pass is only relevant to functions with musttail calls,
so something quite rare and only at -O0/-Og (unless one e.g.
disables the tailc pass).
2025-07-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/120608
* passes.def (pass_musttail): Move before pass_sanopt.
* tree-tailcall.cc (empty_eh_cleanup): Handle GIMPLE_RESX
which doesn't throw externally through recursion on single
eh edge (if any and cnt still allows that).
(find_tail_calls): Add ESUCC, IGNORED_EDGES and MUST_SEE_BBS
arguments. Handle GIMPLE_CONDs for non-simplified cleanups with
finally_tmp temporaries both on backward and forward walks, adjust
recursive call.
(tree_optimize_tail_calls_1): Adjust find_tail_calls callers.
* c-c++-common/asan/pr120608-3.c: New test.
* c-c++-common/asan/pr120608-4.c: New test.
* g++.dg/asan/pr120608-3.C: New test.
* g++.dg/asan/pr120608-4.C: New test.
Jakub Jelinek [Tue, 1 Jul 2025 09:58:28 +0000 (11:58 +0200)]
testsuite: Fix up pr119318.c test for big-endian [PR120082]
The test is not endianess clean, x[0] is supposed to be ((__int128)0x19)<<32
on little endian - 0x19 is in the second vector elt - but ((__int128)0x19)<<64
on big endian. I've added also verification of int and __int128 sizes just
in case we have say 16-bit or 64-bit int target with __int128 type, or
pdp endian gets __int128 support.
2025-07-01 Jakub Jelinek <jakub@redhat.com>
PR ipa/119318
PR testsuite/120082
* gcc.dg/ipa/pr119318.c (main): Expect different result on big endian
from little endian, on unexpected endianness or int/int128 sizes don't
test anything. Formatting fixes.
Bob Duff [Tue, 29 Apr 2025 17:12:44 +0000 (13:12 -0400)]
ada: Make class-wide Max_Size_In_Storage_Elements return a large value
Max_Size_In_Storage_Elements is supposed to return a value greater or
equal to what is passed for any heap allocation for an object of the
type. For a tagged type T, we don't know the allocation size for
descendants; therefore T'Class'Max_Size_In_Storage_Elements should
return a huge number. In particular, it now returns Storage_Count'Last,
which is greater than any possible heap allocation.
Previously, T'Class'Max_Size_In_Storage_Elements was returning
the same value as T'Max_Size_In_Storage_Elements, which was
wrong.
gcc/ada/ChangeLog:
* exp_attr.adb (Attribute_Max_Size_In_Storage_Elements):
Return Storage_Count'Last converted to universal_integer.
Steve Baird [Sat, 12 Apr 2025 00:38:29 +0000 (17:38 -0700)]
ada: Record type Put_Image procedures omitting discriminant values
If a type T has a partial view with a known_discriminant_part and no
user-specified Put_Image aspect specification, then the output generated
by T'Put_Image would incorrectly omit the discriminant values.
gcc/ada/ChangeLog:
* exp_put_image.adb (Build_Record_Put_Image_Procedure): If
Discriminant_Specifications takes us from the full view of a type
to an (intentionally) unanalyzed subtree, then instead find
discriminant entities by calling Discriminant_Specifications on
the partial view of the type.
ada: Fix crash on nested access-to-subprogram types
This patch fixes a crash on some subprograms with anonymous
access-to-subprogram parameters by removing delayed freezing of
subprograms in some cases where it wasn't necessary. The -gnatD output
for itypes is also improved.
Eric Botcazou [Mon, 14 Apr 2025 08:23:52 +0000 (10:23 +0200)]
ada: Fix internal error on Ghost aspect applied to Big_Integers
That's a regression introduced by the rewrite of the finalization machinery,
in the form of dangling references to Master_Node entities remaining in the
tree after the removal of the ignored Ghost code.
gcc/ada/ChangeLog:
* exp_ch7.adb (Process_Transient_In_Scope): Bail out if the object
is an ignored ghost entity.
Eric Botcazou [Mon, 14 Apr 2025 08:04:27 +0000 (10:04 +0200)]
ada: Fix internal error on expression function called for default expression
This happens for the default expression of a controlled component when an
aggregate is used for the record type, because of a freeze node generated
for the expression within an artificial block that is needed to implement
the cleanup actions attached to the assignment of the component.
This is fixed by extending the special treatment applied to freeze nodes
by Insert_Actions, in the case of loops generated for aggregates, to the
case of blocks generated for aggregates.
gcc/ada/ChangeLog:
* exp_util.adb (Insert_Actions): Extend special treatment applied
to freeze nodes to the case of blocks generated for aggregates.
Tomasz Kamiński [Tue, 24 Jun 2025 07:17:12 +0000 (09:17 +0200)]
libstdc++: Report compilation error on formatting "%d" from month_last [PR120650]
For month_day we incorrectly reported day information to be available, which lead
to format_error being thrown from the call to formatter::format at runtime, instead
of making call to format ill-formed.
PR libstdc++/120650
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h
(formatter<chrono::month_day_last,_CharT>::parse): Call _M_parse with
only Month being available.
Eric Botcazou [Sat, 28 Jun 2025 15:42:26 +0000 (17:42 +0200)]
Fix compilation of concatenation with illegal character constant
This fixes an error recovery issue, whereby the compilation of a string
concatenation with an illegal character constant hangs.
gcc/ada/
PR ada/120854
* sem_eval.adb (Get_String_Val): Be prepared for an integer literal
after a serious error is detected, and raise PE on other nodes.
gcc/testsuite/
* gnat.dg/concat6.adb: New test.
Eric Botcazou [Fri, 27 Jun 2025 21:47:49 +0000 (23:47 +0200)]
Fix misoptimization of CONSTRUCTOR with reverse SSO
fold_ctor_reference already punts on a CONSTRUCTOR whose type has reverse
storage order, but it can be invoked in a couple of places on a CONSTRUCTOR
with native storage order that has been wrapped in a VIEW_CONVERT_EXPR to a
type with reverse storage order; this would require a post adjustment that
does not currently exist, thus yield wrong code for this admittedly quite
pathological (but supported) case.
gcc/
* gimple-fold.cc (fold_const_aggregate_ref_1) <COMPONENT_REF>:
Bail out immediately if the reference has reverse storage order.
* tree-ssa-sccvn.cc (fully_constant_vn_reference_p): Likewise.
gcc/testsuite/
* gnat.dg/sso20.adb: New test.
Harald Anlauf [Fri, 27 Jun 2025 21:00:48 +0000 (23:00 +0200)]
Fortran: follow-up fix to checking of renamed-on-use interface name [PR120784]
Commit r16-1633 introduced a regression for imported interfaces that were
not renamed-on-use, since the related logic did not take into account that
the absence of renaming could be represented by an empty string.
Richard Biener [Fri, 20 Jun 2025 13:07:20 +0000 (15:07 +0200)]
tree-optimization/120729 - limit compile time in uninit_analysis::prune_phi_opnds
The testcase in this PR shows, on the GCC 14 branch, that in some
degenerate cases we can spend exponential time pruning always
initialized paths through a web of PHIs. The following adds
--param uninit-max-prune-work, defaulted to 100000, to limit that
to effectively O(1).
PR tree-optimization/120729
* gimple-predicate-analysis.h (uninit_analysis::prune_phi_opnds):
Add argument of work budget remaining.
* gimple-predicate-analysis.cc (uninit_analysis::prune_phi_opnds):
Likewise. Maintain and honor it throughout the recursion.
* params.opt (uninit-max-prune-work): New.
* doc/invoke.texi (uninit-max-prune-work): Document.
Jeff Law [Tue, 10 Jun 2025 12:38:52 +0000 (06:38 -0600)]
[RISC-V] Fix ICE due to splitter emitting constant loads directly
This is a fix for a bug found internally in Ventana using the cf3 testsuite.
cf3 looks to be dead as a project and likely subsumed by modern fuzzers. In
fact internally we tripped another issue with cf3 that had already been
reported by Edwin with the fuzzer he runs.
Anyway, the splitter in question blindly emits the 2nd adjusted constant into a
register, that's not valid if the constant requires any kind of synthesis --
and it well could since we're mostly focused on the first constant turning into
something that can be loaded via LUI without increasing the cost of the second
constant.
Instead of using the split RTL template, this just emits the code we want
directly, using riscv_move_insn to synthesize the constant into the provided
temporary register.
Tested in my system. Waiting on upstream CI's verdict before moving forward.
gcc/
* config/riscv/riscv.md (lui-constraint<X:mode>and_to_or): Do not use
the RTL template for split code. Emit it directly taking care to avoid
emitting a constant load that needed synthesis. Fix formatting.
gcc/testsuite/
* gcc.target/riscv/ventana-16122.c: New test.
Paul Thomas [Thu, 1 May 2025 14:22:54 +0000 (15:22 +0100)]
Fortran: Source allocation of pure function result rejected [PR119948]
2025-05-07 Paul Thomas <pault@gcc.gnu.org>
and Steven G. Kargl <kargl@gcc.gnu.org>
gcc/fortran
PR fortran/119948
* resolve.cc (gfc_impure_variable): The result of a module
procedure with an interface declaration is not impure even if
the current namespace is not the same as the symbol's.
* primary.cc (match_variable): Module procedures with sym the
same as result can be treated as variables, although marked
external.
gcc/testsuite/
PR fortran/119948
* gfortran.dg/pr119948.f90: New test.
aarch64: Incorrect removal of ZA restore [PR120624]
The PCS defines a lazy save scheme for managing ZA across normal
"private-ZA" functions. GCC currently uses this scheme for calls
to all private-ZA functions (rather than using caller-save).
Therefore, before a sequence of calls to private-ZA functions, GCC emits
code to set up a lazy save. After the sequence of calls, GCC emits code
to check whether lazy save was committed and restore the ZA contents
if so.
These sequences are emitted by the mode-switching pass, in an attempt
to reduce the number of redundant saves and restores.
The lazy save scheme also means that, before a function can use ZA,
it must first conditionally store the old contents of ZA to the caller's
lazy save buffer, if any.
This all creates some relatively complex dependencies between
setup code, save/restore code, and normal reads from and writes to ZA.
These dependencies are modelled using special fake hard registers:
;; Sometimes we use placeholder instructions to mark where later
;; ABI-related lowering is needed. These placeholders read and
;; write this register. Instructions that depend on the lowering
;; read the register.
(LOWERING_REGNUM 87)
;; Represents the contents of the current function's TPIDR2 block,
;; in abstract form.
(TPIDR2_BLOCK_REGNUM 88)
;; Holds the value that the current function wants PSTATE.ZA to be.
;; The actual value can sometimes vary, because it does not track
;; changes to PSTATE.ZA that happen during a lazy save and restore.
;; Those effects are instead tracked by ZA_SAVED_REGNUM.
(SME_STATE_REGNUM 89)
;; Instructions write to this register if they set TPIDR2_EL0 to a
;; well-defined value. Instructions read from the register if they
;; depend on the result of such writes.
;;
;; The register does not model the architected TPIDR2_ELO, just the
;; current function's management of it.
(TPIDR2_SETUP_REGNUM 90)
;; Represents the property "has an incoming lazy save been committed?".
(ZA_FREE_REGNUM 91)
;; Represents the property "are the current function's ZA contents
;; stored in the lazy save buffer, rather than in ZA itself?".
(ZA_SAVED_REGNUM 92)
;; Represents the contents of the current function's ZA state in
;; abstract form. At various times in the function, these contents
;; might be stored in ZA itself, or in the function's lazy save buffer.
;;
;; The contents persist even when the architected ZA is off. Private-ZA
;; functions have no effect on its contents.
(ZA_REGNUM 93)
Every normal read from ZA and write to ZA depends on SME_STATE_REGNUM,
in order to sequence the code with the initial setup of ZA and
with the lazy save scheme.
The code to restore ZA after a call involves several instructions,
including conditional control flow. It is initially represented as
a single define_insn and is split late, after shrink-wrapping and
prologue/epilogue insertion.
The split form of the restore instruction includes a conditional call
to __arm_tpidr2_restore:
The write to SME_STATE_REGNUM indicates the end of the region where
ZA_REGNUM might differ from the real contents of ZA. In other words,
it is the point at which normal reads from ZA and writes to ZA
can safely take place.
To finally get to the point, the problem in this PR was that the
unsplit aarch64_restore_za pattern was missing this change to
SME_STATE_REGNUM. It could therefore be deleted as dead before
it had chance to be split. The split form had the correct dataflow,
but the unsplit form didn't.
Unfortunately, the tests for this code tended to use calls and asms
to model regions of ZA usage, and those don't seem to be affected
in the same way.
gcc/
PR target/120624
* config/aarch64/aarch64.md (SME_STATE_REGNUM): Expand on comments.
* config/aarch64/aarch64-sme.md (aarch64_restore_za): Also set
SME_STATE_REGNUM
gcc/testsuite/
PR target/120624
* gcc.target/aarch64/sme/za_state_7.c: New test.
rtl-ssa: Reject non-address uses of autoinc regs [PR120347]
As the rtl.texi documentation of RTX_AUTOINC expressions says:
If a register used as the operand of these expressions is used in
another address in an insn, the original value of the register is
used. Uses of the register outside of an address are not permitted
within the same insn as a use in an embedded side effect expression
because such insns behave differently on different machines and hence
must be treated as ambiguous and disallowed.
late-combine was failing to follow this rule. One option would have
been to enforce it during the substitution phase, like combine does.
This could either be a dedicated condition in the substitution code
or, more generally, an extra condition in can_merge_accesses.
(The latter would include extending is_pre_post_modify to uses.)
However, since the restriction applies to patterns rather than to
actions on patterns, the more robust fix seemed to be test and reject
this case in (a subroutine of) rtl_ssa::recog. We already do something
similar for hard-coded register clobbers.
Using vec_rtx_properties isn't the lightest-weight operation
out there. I did wonder about relying on the is_pre_post_modify
flag of the definitions in the new_defs array, but that would
require callers that create new autoincs to set the flag before
calling recog. Normally these flags are instead updated
automatically based on the final pattern.
Besides, recog itself has had to traverse the whole pattern,
and it is even less light-weight than vec_rtx_properties.
At least the pattern should be in cache.
The rtl-ssa fix showed up a mistake (of mine) in the rtl_properties
walker: try_to_add_src would drop all flags except IN_NOTE before
recursing into RTX_AUTOINC addresses.
RTX_AUTOINCs only occur in addresses, and so for them, the flags coming
into try_to_add_src are set by:
unsigned int base_flags = flags & rtx_obj_flags::STICKY_FLAGS;
...
if (MEM_P (x))
{
...
This means that the only flags that can be set are:
- IN_NOTE (the sole member of STICKY_FLAGS)
- IN_MEM_STORE
- IN_MEM_LOAD
Thus dropping all flags except IN_NOTE had the effect of dropping
IN_MEM_STORE and IN_MEM_LOAD, and nothing else. But those flags
are the ones that mark something as being part of a mem address.
The exclusion was therefore exactly wrong.
gcc/
PR rtl-optimization/120347
* rtlanal.cc (rtx_properties::try_to_add_src): Don't drop the
IN_MEM_LOAD and IN_MEM_STORE flags for autoinc registers.
* rtl-ssa/changes.cc (recog_level2): Check whether an
RTX_AUTOINCed register also appears outside of an address.
gcc/testsuite/
PR rtl-optimization/120347
* gcc.dg/torture/pr120347.c: New test.
Haochen Jiang [Tue, 17 Jun 2025 06:08:38 +0000 (14:08 +0800)]
i386: Remove CLDEMOTE for clients
CLDEMOTE is not enabled on clients according to SDM. SDM only mentioned
it will be enabled on Xeon and Atom servers, not clients. Remove them
since Alder Lake (where it is introduced).
gcc/ChangeLog:
* config/i386/i386.h (PTA_ALDERLAKE): Use PTA_GOLDMONT_PLUS
as base to remove PTA_CLDEMOTE.
(PTA_SIERRAFOREST): Add PTA_CLDEMOTE since PTA_ALDERLAKE
does not include that anymore.
* doc/invoke.texi: Update texi file.
Jakub Jelinek [Mon, 23 Jun 2025 14:08:34 +0000 (16:08 +0200)]
tailc: Allow musttail tail calls with -fsanitize=address [PR120608]
These testcases show another problem with -fsanitize=address
vs. musttail tail calls. In particular, there can be
.ASAN_MARK (POISON, &a, 4);
etc. calls after a tail call and those just prevent the tailc pass
to mark the musttail calls as [tail call].
Normally, the sanopt pass (which comes after tailc) will optimize those
away, the optimization is if there are no .ASAN_CHECK calls or normal
function calls dominated by those .ASAN_MARK (POSION, ...) calls, the
poison is not needed, because in the epilog sequence (the one dealt with
in the patch posted earlier today) all the stack slots are unpoisoned anyway
(or poisoned for use-after-return).
Unlike __builtin_tsan_exit_function, .ASAN_MARK is not a real function
and is always expanded inline, so can be never tail called successfully,
so the patch just ignores those for the cfun->has_musttail && diag_musttail
cases. If there is a non-musttail call, it will fail worst case during
expansion because there is the epilog asan sequence.
2025-06-12 Jakub Jelinek <jakub@redhat.com>
PR middle-end/120608
* tree-tailcall.cc (empty_eh_cleanup): Ignore .ASAN_MARK (POISON)
internal calls for the cfun->has_musttail case and diag_musttail.
(find_tail_calls): Likewise.
* c-c++-common/asan/pr120608-1.c: New test.
* c-c++-common/asan/pr120608-2.c: New test.
Jakub Jelinek [Mon, 23 Jun 2025 13:58:55 +0000 (15:58 +0200)]
expand: Allow musttail tail calls with -fsanitize=address [PR120608]
The following testcase is rejected by GCC 15 but accepted (with
s/gnu/clang/) by clang.
The problem is that we want to execute a sequence of instructions to
unpoison all automatic variables in the function and mark the var block
allocated for use-after-return sanitization poisoned after the call,
so we were just disabling tail calls if there are any instructions
returned from asan_emit_stack_protection.
It is fine and necessary for normal tail calls, but for musttail
tail calls we actually document that accessing the automatic vars of
the caller is UB as if they end their lifetime right before the tail
call, so we also want address sanitizer user-after-return to diagnose
that.
The following patch will only disable normal tail calls when that sequence
is present, for musttail it will arrange to emit a copy of that sequence
before the tail call sequence. That sequence only tweaks the shadow memory
and nothing in the code emitted by call expansion should touch the shadow
memory, so it is ok to emit it already before argument setup.
2025-06-23 Jakub Jelinek <jakub@redhat.com>
PR middle-end/120608
* cfgexpand.cc: Include rtl-iter.h.
(expand_gimple_tailcall): Add ASAN_EPILOG_SEQ argument, if non-NULL
and expand_gimple_stmt emitted a tail call, emit a copy of that
insn sequence before the call sequence.
(expand_gimple_basic_block): Remove DISABLE_TAIL_CALLS argument, add
ASAN_EPILOG_SEQ argument. Disable tail call flag only on non-musttail
calls if that flag is set, pass it to expand_gimple_tailcall.
(pass_expand::execute): Pass VAR_RET_SEQ directly as last
expand_gimple_basic_block argument rather than its comparison with
NULL.
As is outlined in the PR, we have a few define_insn_and_split patterns which
optimize away explicit masking of shift/bit positions when the masking matches
what the hardware's behavior.
A small number of those define_insn_and_split patterns generate a single
instruction. It's fairly elegant in that we were essentially just rewriting
the RTL to match an existing pattern.
In one case we'd do the rewriting and later turn a 32bit shift into a bset.
That's not safe because the masking of a 32bit shift uses 0x1f while masking on
bset uses 0x3f on rv64. The net was incorrect code as seen in the BZ entry.
The fix is pretty simple. There's no real reason we need to use a
define_insn_and_split. It was just convenient. Instead we can use a simple
define_insn. That avoids a change in the masking behavior for the shift
count/bit position and the masking stays in the RTL.
I quickly scanned the entire port and didn't see any additional
define_insn_and_splits that obviously generated a single instruction outside
the shift/rotate space, though in the vector space that's nontrivial to
ascertain.
This was been run through my tester for the cross configurations, but not the
native bootstrap/regression test (yet).
PR target/119971
gcc/
* config/riscv/bitmanip.md (rotation with masked count): Rewrite
as define_insn patterns. Fix formatting.
* config/riscv/riscv.md (shift with masked count): Similarly.
gcc/testsuite
* gcc.target/riscv/pr119971.c: New test.
* gcc.target/riscv/zbb-rol-ror-03.c: Adjust test slightly.
Jakub Jelinek [Thu, 19 Jun 2025 06:57:27 +0000 (08:57 +0200)]
dfp: Further decimal_real_to_integer fixes [PR120631]
Unfortunately, the following further testcase shows that there aren't
problems only with very large precisions and large exponents, but pretty
much anything larger than 64-bits. After all, before _BitInt support dfp
didn't even have {,unsigned }__int128 <-> _Decimal{32,64,128,64x} support,
and the testcase again shows some of the conversions yielding zeros.
While the pr120631.c test worked even without the earlier patch.
So, this patch assumes 64-bit precision at most is ok and for anything
larger it just uses exponent 0 and multiplies afterwards.
2025-06-19 Jakub Jelinek <jakub@redhat.com>
PR middle-end/120631
* dfp.cc (decimal_real_to_integer): Use result multiplication not just
when precision > 128 and dn.exponent > 19, but when precision > 64
and dn.exponent > 0.
* gcc.dg/dfp/bitint-10.c: New test.
* gcc.dg/dfp/pr120631.c: New test.
Jakub Jelinek [Wed, 18 Jun 2025 06:07:22 +0000 (08:07 +0200)]
dfp, real: Fix up FLOAT_EXPR/FIX_TRUNC_EXPR constant folding between dfp and large _BitInt [PR120631]
The following testcase shows that while at runtime we handle conversions
between _Decimal{64,128} and large _BitInt correctly, at compile time we
mishandle them in both directions, in one direction we end up in ICE in
decimal_from_integer callee because the char buffer is too short for the
needed number of decimal digits, in the conversion of dfp to large _BitInt
we return 0 in the wide_int.
The following patch fixes the ICE by using larger buffer (XALLOCAVEC
allocated, it will be never larger than 65536 / 3 bytes) in the larger
_BitInt case, and the other direction by setting exponent to exp % 19
and instead multiplying the result by needed powers of 10^19 (10^19 chosen
as largest power of ten that can fit into UHWI).
2025-06-18 Jakub Jelinek <jakub@redhat.com>
PR middle-end/120631
* real.cc (decimal_from_integer): Add digits argument, if larger than
256, use XALLOCAVEC allocated buffer.
(real_from_integer): Pass val_in's precision divided by 3 to
decimal_from_integer.
* dfp.cc (decimal_real_to_integer): For precision > 128 if finite
and exponent is large, decrease exponent and multiply resulting
wide_int by powers of 10^19.
Harald Anlauf [Sun, 15 Jun 2025 19:09:28 +0000 (21:09 +0200)]
Fortran: fix checking of MOLD= in ALLOCATE statements [PR51961]
In ALLOCATE statements where the MOLD= argument is present and is not
scalar, and the allocate-object has an explicit-shape-spec, the standard
does not require the ranks to agree. In that case we skip the rank check,
but emit a warning if -Wsurprising is given.
PR fortran/51961
gcc/fortran/ChangeLog:
* resolve.cc (conformable_arrays): Use modified rank check when
MOLD= expression is given.
Jakub Jelinek [Tue, 17 Jun 2025 11:20:11 +0000 (13:20 +0200)]
crc: Fix up ICE from optimize_crc_loop [PR120677]
The following testcase ICEs, because optimize_crc_loop inserts a call
statement before labels instead of after labels.
Fixed thusly (plus fixed other issues noticed around it).
2025-06-17 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/120677
* gimple-crc-optimization.cc (crc_optimization::optimize_crc_loop):
Insert before gsi_after_labels instead of gsi_start_bb. Use
gimple_bb (output_crc) instead of output_crc->bb. Formatting fix.
Georg-Johann Lay [Sat, 14 Jun 2025 17:57:18 +0000 (19:57 +0200)]
AVR: Fix PR120423 / PR116389.
The problem with PR120423 and PR116389 is that reload might assign an invalid
hard register to a paradoxical subreg. For example with the test case from
the PR, it assigns (REG:QI 31) to the inner of (subreg:HI (QI) 0) which is
valid, but the subreg will be turned into (REG:HI 31) which is invalid
and triggers an ICE in postreload.
The problem only occurs with the old reload pass.
The patch maps the paradoxical subregs to a zero-extends which will be
allocated correctly. For the 120423 testcases, the code is the same like
with -mlra (which doesn't implement the fix), so the patch doesn't even
introduce a performance penalty.
The patch is only needed for v15: v14 is not affected, and in v16 reload
will be removed.
PR rtl-optimization/120423
PR rtl-optimization/116389
gcc/
* config/avr/avr.md [-mno-lra]: Add pre-reload split to transform
(left shift of) a paradoxical subreg to a (left shift of) zero-extend.
gcc/testsuite/
* gcc.target/avr/torture/pr120423-1.c: New test.
* gcc.target/avr/torture/pr120423-2.c: New test.
* gcc.target/avr/torture/pr120423-116389.c: New test.
Jakub Jelinek [Thu, 12 Jun 2025 18:22:39 +0000 (20:22 +0200)]
recip: Reset range info when replacing sqrt with rsqrt [PR120638]
This pass reuses a SSA_NAME on the lhs of sqrt etc. call as lhs
of .RSQRT etc. call. The following testcase is miscompiled since my recent
ranger cast changes, because we compute (correct) range for sqrtf argument
as well as result but then recip pass keeps using that range for the .RQSRT
call which returns 1. / sqrt, so the function then returns 0.5f
unconditionally.
Note, on foo this is a regression from GCC 15, but on bar it regressed
already with the r14-536 change.
2025-06-12 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/120638
* tree-ssa-math-opts.cc (pass_cse_reciprocals::execute): Call
reset_flow_sensitive_info on arg1.
Jakub Jelinek [Thu, 5 Jun 2025 13:47:19 +0000 (15:47 +0200)]
real: Fix up real_from_integer [PR120547]
The function has 2 problems, one is _BitInt specific and the other is
most likely also reproduceable only with it.
The first issue is that I've missed updating the function for _BitInt,
maxbitlen as MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT
obviously isn't guaranteed to be larger than any integral type we might
want to convert at compile time from wide_int to REAL_VALUE_FORMAT.
Just using len instead of it works fine, at least when used after
HOST_BITS_PER_WIDE_INT is added to it and it is truncated to multiples
of HOST_BITS_PER_WIDE_INT.
The other bug is that if the value has too many significant bits (formerly
maxbitlen - cnt_l_z, now len - cnt_l_z), the code just shifts it right and
adds the shift count to the future exponent. That isn't correct for
rounding as the testcase attempts to show, the internal real format has more
bits than any precision in supported format, but we still need to
distinguish bewtween values exactly half way between representable floating
point values (those should be rounded to even) and the case when we've
shifted away some non-zero bits, so the value was tiny bit larger than half
way and then we should round up.
The patch uses something like e.g. soft-fp uses in these cases, right shift
with sticky bit in the least significant bit.
2025-06-05 Jakub Jelinek <jakub@redhat.com>
PR middle-end/120547
* real.cc (real_from_integer): Remove maxbitlen variable, use
len instead of that. When shifting right, or in 1 if any of the
shifted away bits are non-zero. Formatting fix.
Jakub Jelinek [Tue, 20 May 2025 06:21:14 +0000 (08:21 +0200)]
tree-chrec: Use signed_type_for in convert_affine_scev
On s390x-linux I've run into the gcc.dg/torture/bitint-27.c test ICEing in
build_nonstandard_integer_type called from convert_affine_scev (not sure
why it doesn't trigger on x86_64/aarch64).
The problem is clear, when ct is a BITINT_TYPE with some large
TYPE_PRECISION, build_nonstandard_integer_type won't really work on it.
The patch fixes it similarly what has been done for GCC 14 in various
other spots.
2025-05-20 Jakub Jelinek <jakub@redhat.com>
* tree-chrec.cc (convert_affine_scev): Use signed_type_for instead of
build_nonstandard_integer_type.
Fortran: Fix missing substring ref for allocatable saved vars [PR120483]
Compute a substring ref on an allocatable static character array
using pointer arithmetic. Using an array type corrupts type
layouting and crashes omp generation.
PR fortran/120483
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_substring): Use pointer arithmetic on
static allocatable char arrays.
Jonathan Wakely [Wed, 11 Jun 2025 10:11:52 +0000 (11:11 +0100)]
libstdc++: Do not specialize std::formatter for incomplete type [PR120625]
Using an incomplete type as the template argument for std::formatter
specializations causes problems for program-defined specializations of
std::formatter which have constraints. When the compiler has to find
which specialization of std::formatter to use for the incomplete type it
considers the program-defined specializations and checks to see if their
constraints are satisfied, which can give errors if the constraints
cannot be checked for incomplete types.
This replaces the base class of the disabled specializations with a
concrete class __formatter_disabled, so there is no need to match a
specialization and no more incomplete type.
libstdc++-v3/ChangeLog:
PR libstdc++/120625
* include/std/format (__format::__disabled): Remove.
(__formatter_disabled): New type.
(formatter<char*, wchar_t>, formatter<const char*, wchar_t>)
(formatter<char[N], wchar_t>, formatter<string, wchar_t>)
(formatter<string_view, wchar_t>): Use __formatter_disabled as
base class instead of formatter<__disabled, wchar_t>.
* testsuite/std/format/formatter/120625.cc: New test.
Martin Jambor [Thu, 29 May 2025 14:32:04 +0000 (16:32 +0200)]
ipa: When inlining, don't combine PT JFs changing signedness (PR120295)
In GCC 15 we allowed jump-function generation code to skip over a
type-cast converting one integer to another as long as the latter can
hold all the values of the former or has at least the same precision.
This works well for IPA-CP where we do then evaluate each jump
function as we propagate values and value-ranges. However, the
test-case in PR 120295 shows a problem with inlining, where we combine
pass-through jump-functions so that they are always relative to the
function which is the root of the inline tree. Unfortunately, we are
happy to combine also those with type-casts to a different signedness
which makes us use sign zero extension for the expected value ranges
where we should have used sign extension. When the value-range which
then leads to wrong insertion of a call to builtin_unreachable is
being computed, the information about an existence of a intermediary
signed type has already been lost during previous inlining.
This patch simply blocks combining such jump-functions so that it is
back-portable to GCC 15. Once we switch pass-through jump functions
to use a vector of operations rather than having room for just one, we
will be able to address this situation with adding an extra conversion
instead.
gcc/ChangeLog:
2025-05-19 Martin Jambor <mjambor@suse.cz>
PR ipa/120295
* ipa-prop.cc (update_jump_functions_after_inlining): Do not
combine pass-through jump functions with type-casts changing
signedness.
Eric Botcazou [Sat, 5 Apr 2025 14:21:45 +0000 (16:21 +0200)]
ada: Fix documentation of Generalized Finalization extension
The current documentation does not reflect the implementation present in
the compiler and contains various other inaccuracies.
gcc/ada/ChangeLog:
* doc/gnat_rm/gnat_language_extensions.rst
(Generalized Finalization): Document the actual implementation.
(No_Raise): Move to separate section.
* gnat_rm.texi: Regenerate.
ada: Tweak special handling of synchronized type scopes
Exp_Util.Insert_Actions handles scopes of synchronized types specially,
but the condition it tested before this patch was not quite correct in
some cases, for example during some expansion operations made under
Expand_N_Task_Type_Declaration. This patch refines the test.
projects / thirdparty / gcc.git / log
