Releases/gcc 12 #65
Open
Releases/gcc 12 #65
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This is an unofficial mirror that has nothing to do with the GCC project, so submitting pull requests here is a waste of time. Also, I have no idea what this pull request is trying to do but it would never be accepted even if it was submitted to the right place. |
atahanozbayram
approved these changes
Apr 2, 2024
Initializing a vector using Vec : V.Vector := [Some_Type'(Some_Abstract_Type with F => 0)]; may crash the compiler. The expander marks the N_Extension_Aggregate for delayed expansion which never happens and incorrectly ends up in gigi. The delayed expansion is needed for nested aggregates, which the original code is testing for, but container aggregates are handled differently. Such assignments to container aggregates are later transformed into procedure calls to the procedures named in the Aggregate aspect definition, for which the delayed expansion is not required/expected. gcc/ada/ PR ada/118234 * exp_aggr.adb (Convert_To_Assignments): Do not mark node for delayed expansion if parent type has the Aggregate aspect. * sem_util.adb (Is_Container_Aggregate): Move... * sem_util.ads (Is_Container_Aggregate): ... here and make it public.
This just applies the same fix to Expand_Array_Aggregate as the one that was recently applied to Convert_To_Assignments. gcc/ada/ PR ada/118234 * exp_aggr.adb (Convert_To_Assignments): Tweak comment. (Expand_Array_Aggregate): Do not delay the expansion if the parent node is a container aggregate.
This handles the case where a component association is present. gcc/ada/ PR ada/118234 * exp_aggr.adb (Convert_To_Assignments): In the case of a component association, call Is_Container_Aggregate on the parent's parent. (Expand_Array_Aggregate): Likewise.
gcc/ada * libgnarl/s-taprop__dummy.adb: Remove use clause for System.Parameters. (Unlock): Remove Global_Lock formal parameter. (Write_Lock): Likewise.
gcc/ada/ PR ada/112958 * Makefile.rtl (LIBGNAT_TARGET_PAIRS) [x86 FreeBSD]: Add specific version of s-dorepr.adb. * libgnat/s-dorepr__freebsd.adb: New file.
…tion (PR118924) During analysis of PR 118924 it was discussed that total scalarization invents access paths (strings of COMPONENT_REFs and possibly even ARRAY_REFs) which did not exist in the program before which can have unintended effects on subsequent AA queries. Although not doing that does not mean that SRA cannot create such situations (see the bug for more info), it has been agreed that not doing this is generally better. This patch therfore makes SRA fall back on creating simple MEM_REFs when accessing components of an aggregate corresponding to what a SRA variable now represents. gcc/ChangeLog: 2025-03-26 Martin Jambor <[email protected]> PR tree-optimization/118924 * tree-sra.cc (create_total_scalarization_access): Set grp_same_access_path flag to zero. (cherry picked from commit 4044571)
Because the testcase for the issue in master is in a commit I do not plan to backport to GCC 12 but the issue is avoided by my previous one nevertheless, I am backporting the testcase in this one. gcc/testsuite/ChangeLog: 2025-04-29 Martin Jambor <[email protected]> PR tree-optimization/118924 * g++.dg/tree-ssa/pr118924.C: New test.
The PR shows us spinning in dce.cc:fast_dce at the start of combine.
This spinning appears to be because of a disagreement between the fast_dce code
and the code in df-problems.cc:df_lr_bb_local_compute. Specifically, they
disagree on the treatment of partial defs. For the testcase in the PR, we have
the following insn in bb 3:
(insn 10 8 13 3 (clobber (subreg:V1DF (reg/v:V2x1DF 104 [ __val ]) 8)) -1
(nil))
which gives rise to a DF def with DF_REF_FLAGS = 0x8b0, i.e.
DF_REF_PARTIAL | DF_REF_READ_WRITE | DF_REF_MUST_CLOBBER | DF_REF_SUBREG.
Eliding the large block comment for readability, the code in
df_lr_bb_local_compute does the following (for each insn):
FOR_EACH_INSN_INFO_DEF (def, insn_info)
{
unsigned int dregno = DF_REF_REGNO (def);
bitmap_set_bit (&bb_info->def, dregno);
if (DF_REF_FLAGS (def) & (DF_REF_PARTIAL | DF_REF_CONDITIONAL))
bitmap_set_bit (&bb_info->use, dregno);
else
bitmap_clear_bit (&bb_info->use, dregno);
}
i.e. it models partial defs as a RMW operation; thus for the def arising
from i10 above, it records a use of r104; hence it ends up in the
live-in set for bb 3.
However, as it stands, the code in dce.cc:fast_dce (and its callee
dce_process_block) has no such provision for DF_REF_PARTIAL defs. It
does not treat these as a RMW and does not compute r104 above as being
live-in to bb 3. At the end of dce_process_block we compute the
following "did something happen" condition used to decide termination of
the analysis:
block_changed = !bitmap_equal_p (local_live, DF_LR_IN (bb));
if (block_changed)
bitmap_copy (DF_LR_IN (bb), local_live);
BITMAP_FREE (local_live);
return block_changed;
because of the disagreement between df_lr_local_compute and the local
analysis done by fast_dce, we invariably have r104 in DF_LR_IN, but not
in local_live. Hence we always return true here, call
df_analyze_problem (which re-computes DF_LR_IN according to
df_lr_bb_local_compute, re-adding r104), and so the analysis never
terminates.
This patch therefore adjusts df_simulate_defs (called from
dce_process_block) to match the behaviour of df_lr_bb_local_compute in
this respect, namely we make it model partial defs as RMW operations by
setting the relevant register live. This fixes the spinning in fast_dce
for this testcase.
gcc/ChangeLog:
PR rtl-optimization/116564
* df-problems.cc (df_simulate_defs): For partial defs, mark the
register live (treat it as a RMW operation).
gcc/testsuite/ChangeLog:
PR rtl-optimization/116564
* gcc.target/aarch64/torture/pr116564.c: New test.
(cherry picked from commit 758e617)
2023-11-06 John David Anglin <[email protected]> * config/pa/pa-linux.h (NEED_INDICATE_EXEC_STACK): Define to 1.
The problem is for inline-asm goto, the outer rtl insn type is a jump_insn and get_attr_length does not handle ASM specially unlike if the outer rtl insn type was just insn. This fixes the issue by adding support for both CALL_INSN and JUMP_INSN with asm. OK? Bootstrapped and tested on x86_64-linux-gnu. PR middle-end/118411 gcc/ChangeLog: * final.cc (get_attr_length_1): Handle asm for CALL_INSN and JUMP_INSNs. Signed-off-by: Andrew Pinski <[email protected]> (cherry picked from commit c1729df)
This is a backport of https://go.dev/cl/640237 from the main repo. Fixes PR go/118286 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/640435 (cherry picked from commit ed1493e)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Support for Apple Silicon!!!