public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Matthew Malcomson <matmal01@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/vendors/ARM/heads/morello)] dwarf2out: Avoid creating rtx with mode MAX_MACHINE_MODE Date: Fri, 10 Dec 2021 16:49:33 +0000 (GMT) [thread overview] Message-ID: <20211210164933.B31463857C66@sourceware.org> (raw) https://gcc.gnu.org/g:a16e2e017098bc895d12bf08402bdfab65a7d11d commit a16e2e017098bc895d12bf08402bdfab65a7d11d Author: Alex Coplan <alex.coplan@arm.com> Date: Thu Nov 18 13:53:16 2021 +0000 dwarf2out: Avoid creating rtx with mode MAX_MACHINE_MODE This patch fixes an off-by-one out-of-bounds access of a global variable found by bootstrapping --with-build-config=bootstrap-asan. With this patch applied, the compiler now succesfully bootstraps in this configuration. The issue here is that the code in dwarf2out.c abuses the mode of rtxes (specifically EXPR_LISTs) to store some extra information. In particular, with the testcase below, this code can end up creating an EXPR_LIST rtx with the mode set to MAX_MACHINE_MODE. This is problematic because MAX_MACHINE_MODE itself is not a valid mode: all of the arrays (mapping modes to some other entity) in the generated insn-modes.c only contain MAX_MACHINE_MODE entries, so MAX_MACHINE_MODE is not a valid index to these arrays (it is one past the end of the array). The reason we only see this with the Morello compiler is due to the check_code_and_mode check invoked on the creation of any rtx. This function then ends up using CAPABILITY_MODE_P on MAX_MACHINE_MODE, which expands to a use of the GET_MODE_CLASS macro, which accesses one off the end of the mode_class array (defined in the generated insn-modes.c). Looking at dwarf2out.c:decl_piece_node, it seems that abusing the mode in this way is simply a trick to avoid allocating an extra rtx to store the bitsize argument, so in this patch we just force the code to allocate the extra rtx (which can represent any integer) for the case of bitsize == MAX_MACHINE_MODE. Testcase that shows the problem (compile with -O -g): typedef struct { __int128 ll; } DWunion; void __divti3() { DWunion vv = {.0}; } gcc/ChangeLog: * dwarf2out.c (decl_piece_node): Avoid creating an EXPR_LIST with a mode of MAX_MACHINE_MODE. Diff: --- gcc/dwarf2out.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index 9c0327d7209..2e3ff1134db 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -6141,7 +6141,7 @@ decl_piece_varloc_ptr (rtx piece) static rtx_expr_list * decl_piece_node (rtx loc_note, HOST_WIDE_INT bitsize, rtx next) { - if (bitsize > 0 && bitsize <= (int) MAX_MACHINE_MODE) + if (bitsize > 0 && bitsize < (int) MAX_MACHINE_MODE) return alloc_EXPR_LIST (bitsize, loc_note, next); else return alloc_EXPR_LIST (0, gen_rtx_CONCAT (VOIDmode,
reply other threads:[~2021-12-10 16:49 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20211210164933.B31463857C66@sourceware.org \ --to=matmal01@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).