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.
Eric Botcazou [Fri, 28 Mar 2025 17:51:23 +0000 (18:51 +0100)]
ada: Document supported GCC optimization switches
In particular the most recently added ones, namely -Og and -Oz. But -Ofast
is not documented because it disregards strict compliance with standards.
gcc/ada/ChangeLog:
* usage.adb (Usage): Justify the documentation of common switches
like that of other switches. Rework that of the -O switch.
* doc/gnat_ugn/building_executable_programs_with_gnat.rst (Compiler
switches) <-O>: Rework and document 'z' and 'g' operands.
* doc/gnat_ugn/gnat_and_program_execution.rst (Optimization Levels):
Rework and document -Oz and -Og switches.
* gnat_ugn.texi: Regenerate.
Jonathan Wakely [Wed, 28 May 2025 14:19:18 +0000 (15:19 +0100)]
libstdc++: Make system_clock::to_time_t always_inline [PR99832]
For some 32-bit targets Glibc supports changing the size of time_t to be
64 bits by defining _TIME_BITS=64. That causes an ABI change which
would affect std::chrono::system_clock::to_time_t. Because to_time_t is
not a function template, its mangled name does not depend on the return
type, so it has the same mangled name whether it returns a 32-bit time_t
or a 64-bit time_t. On targets where the size of time_t can be selected
at preprocessing time, that can cause ODR violations, e.g. the linker
selects a definition of to_time_t that returns a 32-bit value but a
caller expects 64-bit and so reads 32 bits of garbage from the stack.
This commit adds always_inline to to_time_t so that all callers inline
the conversion to time_t, and will do so using whatever type time_t
happens to be in that translation unit.
Existing objects compiled before this change will either have inlined
the function anyway (which is likely if compiled with any optimization
enabled) or will contain a COMDAT definition of the inline function and
so still be able to find it at link-time.
The attribute is also added to system_clock::from_time_t, because that's
an equally simple function and it seems reasonable for them to both be
always inlined.
libstdc++-v3/ChangeLog:
PR libstdc++/99832
* include/bits/chrono.h (system_clock::to_time_t): Add
always_inline attribute to be agnostic to the underlying type of
time_t.
(system_clock::from_time_t): Add always_inline for consistency
with to_time_t.
* testsuite/20_util/system_clock/99832.cc: New test.
Jonathan Wakely [Wed, 4 Jun 2025 17:22:28 +0000 (18:22 +0100)]
libstdc++: Fix std::format thousands separators when sign present [PR120548]
The leading sign character should be skipped when deciding whether to
insert thousands separators into a floating-point format.
libstdc++-v3/ChangeLog:
PR libstdc++/120548
* include/std/format (__formatter_fp::_M_localize): Do not
include a leading sign character in the string to be grouped.
* testsuite/std/format/functions/format.cc: Check grouping when
sign is present in the output.
Andrew Pinski [Wed, 30 Apr 2025 22:10:29 +0000 (15:10 -0700)]
vectorizer: Fix riscv build [PR120042]
r15-9859-ga6cfde60d8c added a call to dominated_by_p to tree-vectorizer.h
but dominance.h is not always included; and you get a build failure on riscv building
riscv-vector-costs.cc.
Let's add the include of dominance.h to tree-vectorizer.h
Pushed as obvious after builds for riscv and x86_64.
gcc/ChangeLog:
PR target/120042
* tree-vectorizer.h: Include dominance.h.
Gary Dismukes [Sat, 22 Mar 2025 00:01:52 +0000 (00:01 +0000)]
ada: Error on subtype with static predicate used in case_expression
The compiler improperly flags an error on the use of a subtype with a
static predicate as a choice in a case expression alternative, complaining
that the subtype has a nonstatic predicate. The fix for this is to add
a test for the subtype not having a static predicate.
gcc/ada/ChangeLog:
* einfo.ads: Revise comment about Dynamic_Predicate flag to make it
more accurate.
* sem_case.adb (Check_Choices): Test "not Has_Static_Predicate_Aspect"
as additional guard for error about use of subtype with nonstatic
predicate as a case choice. Improve related error message.
Eric Botcazou [Tue, 25 Mar 2025 17:23:50 +0000 (18:23 +0100)]
ada: Fix wrong initialization of library-level object by conditional expression
The previous fix was not robust enough in the presence of transient scopes.
gcc/ada/ChangeLog:
* exp_ch4.adb (Insert_Conditional_Object_Declaration): Deal with a
transient scope being created around the declaration.
* freeze.adb (Freeze_Entity): Do not call Freeze_Static_Object for
a renaming declaration.
Gary Dismukes [Fri, 21 Mar 2025 22:03:46 +0000 (22:03 +0000)]
ada: Storage_Error on Ordered_Maps container aggregate with enumeration Key_Type
The compiler fails with a Storage_Error when compiling a container aggregate
for a Map type coming from an instantiation of Ada.Containers.Ordered_Maps
that specifies an enumeration type for the Key_Type formal.
gcc/ada/ChangeLog:
* exp_aggr.adb (Build_Container_Aggr_Code.To_Int): Apply Enumeration_Pos
to Entity (Expr) rather than Expr.
Xi Ruoyao [Sun, 11 May 2025 08:44:31 +0000 (16:44 +0800)]
ext-dce: Don't refine live width with SUBREG mode if !TRULY_NOOP_TRUNCATION_MODES_P [PR 120050]
If we see a promoted subreg and TRULY_NOOP_TRUNCATION says the
truncation is not a noop, then all bits of the inner reg are live. We
cannot reduce the live mask to that of the mode of the subreg.
gcc/ChangeLog:
PR rtl-optimization/120050
* ext-dce.cc (ext_dce_process_uses): Break early if a SUBREG in
rhs is promoted and the truncation from the inner mode to the
outer mode is not a noop when handling SETs.
Jason Merrill [Fri, 6 Jun 2025 14:26:28 +0000 (10:26 -0400)]
c++: recursive template with deduced return [PR120555]
Here since r15-4120 we were prematurely complaining about the use of func
within its own definiton, which is fine at instantiation time. So don't
require this for function templates that are currently being defined.
But keep the error for instantiations of templates that are not currently
being defined, which we similarly did not diagnose before r15-4120 but other
implementations do.
Both of these follow the general principle from [temp.res.general]/6 that we
only error in a template body if no instatiation could be well-formed.
Also remove a redundant call to require_deduced_type.
Jason Merrill [Wed, 4 Jun 2025 17:31:02 +0000 (13:31 -0400)]
c++: constexpr prvalues vs genericize [PR120502]
Here constexpr evaluation was getting confused by the result of
split_nonconstant_init, which leaves an INIT_EXPR from an empty CONSTRUCTOR
to be followed by member initialization. As a result
CONSTRUCTOR_NO_CLEARING was set for the time_zone, and
cxx_eval_store_expression didn't set it again for the initial clobber in the
basic_string constructor, so when cxx_fold_indirect_ref wants to check
whether the anonymous union active member had type non_trivial_if, we see
that we don't currently have a value for the anonymous union, try to add
one, and fail.
So let's do constexpr evaluation before split_nonconstant_init.
PR c++/120502
gcc/cp/ChangeLog:
* cp-gimplify.cc (cp_fold_r) [TARGET_EXPR]: Do constexpr evaluation
before genericize.
* constexpr.cc (cxx_eval_store_expression): Add comment.
Gary Dismukes [Mon, 17 Mar 2025 18:30:00 +0000 (18:30 +0000)]
ada: Support fixed-lower-bound array types as generic actual parameters
Attempting to use a fixed-lower-bound array type (or subtype) as
an actual parameter for a formal unconstrained array type was being
rejected by the compiler (complaining about the index type of the
actual not matching the index type of the formal type). The compiler
was improperly testing the actual's FLB range and finding that it didn't
statically match the index type of the formal array type; it should
instead test the underlying index type of the FLB type or subtype.
gcc/ada/ChangeLog:
* sem_ch3.adb (Constrain_Index): In the case of a fixed-lower-bound index,
set Etype of the newly created itype's Scalar_Range from the index's Etype.
* sem_ch12.adb (Validate_Array_Type_Instance): If the actual subtype is
a fixed-lower-bound type, then check again the Etype of its Scalar_Range.
Piotr Trojanek [Mon, 17 Mar 2025 12:20:53 +0000 (13:20 +0100)]
ada: Reject component-related aspects on formal non-array types
In Ada 2022 aspects Atomic_Components and Volatile_Components can be specified
for a formal array type, but they were wrongly accepted on any formal type.
Also, we don't need to check if the corresponding pragmas appear in Ada 2022
mode, because generic formal parameters can't have explicit representation
pragmas in any Ada version and can only have aspects since Ada 2022.
gcc/ada/ChangeLog:
* sem_prag.adb (Analyze_Pragma): Fix conditions for legality checks on
formal type declarations.
Piotr Trojanek [Mon, 17 Mar 2025 11:57:26 +0000 (12:57 +0100)]
ada: Fix glitch in handling of Atomic_Components on generic formal type
In Ada 2022 aspects Atomic_Components and Volatile_Components can be specified
for a formal array type, but then they need to be set on the base type entity.
Otherwise we get an assertion failure in debug build and wrong legality errors
in production builds.
gcc/ada/ChangeLog:
* sem_prag.adb (Analyze_Pragma): If pragmas apply to a formal array
type, then set the flags on the base type.
Gary Dismukes [Sat, 8 Mar 2025 01:05:35 +0000 (01:05 +0000)]
ada: Missing discriminant check on assignment of Bounded_Vector aggregate
When a container aggregate for a Bounded_Vector type involves an iterated
association that is assigned to a vector object whose capacity (as defined
by the Capacity discriminant) is less than the number of elements of the
aggregate, Constraint_Error should be raised due to failing a discriminant
check on the assignment. But the compiler fails to do proper expansion,
plus omits the check, and instead creates a temporary whose capacity is
bounded by that of the target vector of the assignment. It attempts to
assign all elements of the aggregate to the temporary, resulting in
a failure on a call to the Replace_Element operation that assigns past
the length of the temporary vector (which can result in a Storage_Error
due to a segment violation).
This is fixed by ensuring that the temporary object is declared with
an unconstrained base subtype rather than the assignment target's
constrained subtype.
gcc/ada/ChangeLog:
* exp_aggr.adb (Expand_Container_Aggregate): Use the Base_Type of the
subtype provided by the context as the subtype of the temporary object
initialized by the aggregate.
Gary Dismukes [Fri, 28 Feb 2025 00:08:19 +0000 (00:08 +0000)]
ada: Incorrect creation of corresponding expression of class-wide contracts
GNAT was incorrectly implementing the Ada rules for resolving calls to
primitive functions within inherited class-wide pre- and postconditions,
as specified in RM22 6.1.1 (relating to AI12-0113). Only function calls
that involve formals of the associated primitive subprogram should be
treated using the "(notional) formal derived type" rules. In particular,
calls that are tag-indeterminate (for example, "F(G)") should not be mapped
to call the corresponding primitives of the derived type (they should still
call the primitives of the ancestor type). The fix for this involves a new
predicate function that recursively traverses calls to determine the calls
that satisfy the criteria for mapping. These changes also completely remove
the mapping of formals that was done in Contracts.Merge_Class_Conditions
(in Inherit_Condition), since the mapping will be done later anyway by
Build_Class_Wide_Expression, and the earlier mapping interferes with that.
Note: The utility function Sem_Util.Check_Parents is no longer called
after removal of the single call to it from contracts.adb, but it's being
retained (along with the generic subprograms in Atree that it depends on)
for possible use in VAST.
gcc/ada/ChangeLog:
* contracts.adb (Inherit_Condition): Remove Assoc_List and its uses
along with function Check_Condition, since mapping of formals will
effectively be done in Build_Class_Wide_Expression (by Replace_Entity).
* exp_util.adb (Replace_Entity): Only rewrite entity references in
function calls that qualify according to the result of calling the
new function Call_To_Parent_Dispatching_Op_Must_Be_Mapped.
(Call_To_Parent_Dispatching_Op_Must_Be_Mapped): New function that
determines whether a function call to a primitive of Par_Subp
associated tagged type needs to be mapped (according to whether
it has any actuals that reference controlling formals of the
primitive).
Eric Botcazou [Thu, 27 Feb 2025 19:43:04 +0000 (20:43 +0100)]
ada: Fix spurious error on anonymous array initialized by conditional expression
Even though the actual subtype of the anonymous array is not yet set on the
object itself by the time Insert_Conditional_Object_Declaration is called,
it is set on its initialization expression, so it can simply be forwarded
to Insert_Conditional_Object_Declaration from there, which avoids creating
a new one for each new object and triggering a subtype mismatch later.
gcc/ada/ChangeLog:
* exp_ch4.adb (Insert_Conditional_Object_Declaration): Remove Decl
formal parameter, add Typ and Const formal parameters.
(Expand_N_Case_Expression): Fix pasto in comment. Adjust call to
Insert_Conditional_Object_Declaration and tidy up surrounding code.
(Expand_N_If_Expression): Adjust couple of calls to
Insert_Conditional_Object_Declaration.
Javier Miranda [Fri, 31 Jan 2025 20:21:09 +0000 (20:21 +0000)]
ada: Constant_Indexing used when context requires a variable
In the case of an assignment where the type of its left hand side
is an indexable container that has indexable container components
(for example a container vector of container vectors), and both
indexable containers have Constant_Indexing and Variable_Indexing
aspects, the left hand side of the assignment is erroneously
interpreted as constant indexing. The error results in spurious
compile-time error messages saying that the left hand side of
the assignment must be a variable.
gcc/ada/ChangeLog:
* sem_ch4.adb (Constant_Indexing_OK): Add missing support for
RM 4.1.6(13/3), and improve performance to avoid climbing more
than needed. Add documentation.
(Try_Indexing_Function): New subprogram.
(Expr_Matches_In_Formal): Added new formals.
(Handle_Selected_Component): New subprogram.
(Has_IN_Mode): New subprogram.
(Try_Container_Indexing): Add documentation, code reorganization
and extend its functionality to improve its support for prefixed
notation calls.
Steve Baird [Fri, 7 Feb 2025 20:29:46 +0000 (12:29 -0800)]
ada: Incorrect unresolved operator name in an instantiation
In some cases, a generic containing a use of a unary operator successfully
compiles but the compiler incorrectly rejects the corresponding use in
an instantiation.
gcc/ada/ChangeLog:
* sem_ch4.adb
(Find_Unary_Types): Because we reanalyze names in an instance,
we sometimes have to take steps to filter out extraneous name
resolution candidates that happen to be visible at the point of the
instance declaration. Remove some code that appears to have been
written with this in mind. This is done for two reasons. First, the
code sometimes doesn't work (possibly because the In_Instance test
is not specific enough - it probably should be testing to see whether
we are in an instance of the particular generic in which the result
of calling Corresponding_Generic_Type was declared) and causes correct
code to be rejected. Second, the code seems to no longer be necessary
(possibly because of subsequent fixes in this area which are not
specific to unary operators).
projects / thirdparty / gcc.git / log
