public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Richard Sandiford <rsandifo@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-2289] expmed: Fix store_bit_field_1 subreg offset Date: Tue, 30 Aug 2022 14:44:42 +0000 (GMT) [thread overview] Message-ID: <20220830144442.8828B382F09D@sourceware.org> (raw) https://gcc.gnu.org/g:1025025b612d632920fe710bb58d36e4d43f3220 commit r13-2289-g1025025b612d632920fe710bb58d36e4d43f3220 Author: Richard Sandiford <richard.sandiford@arm.com> Date: Tue Aug 30 15:43:48 2022 +0100 expmed: Fix store_bit_field_1 subreg offset store_bit_field_1 tries to convert a field assignment into a subreg assignment. Normally it must check that the field occupies a full word (or more specifically, a full REGMODE_NATURAL_SIZE chunk), so that writing to the subreg doesn't clobber any other fields. But it can skip that check if the structure is known to be in an undefined state. The idea was that, in the undefined case, we could rely on simplify_gen_subreg to do the check for a valid subreg, rather than having to repeat the required endianness logic in the caller. Before the addition of the undefined case, the code could use regnum * regsize to get the byte offset, where regnum came from checking that the start was word-aligned. In the undefined case we need to calculate the byte offset explicitly. gcc/ * expmed.cc (store_bit_field_1): Fix byte offset calculation for undefined structures. Diff: --- gcc/expmed.cc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/gcc/expmed.cc b/gcc/expmed.cc index cdc0adb3892..6c02c3bb850 100644 --- a/gcc/expmed.cc +++ b/gcc/expmed.cc @@ -794,7 +794,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, poly_uint64 bitnum, words or to cope with mode punning between equal-sized modes. In the latter case, use subreg on the rhs side, not lhs. */ rtx sub; - HOST_WIDE_INT regnum = 0; + poly_uint64 bytenum; poly_uint64 regsize = REGMODE_NATURAL_SIZE (GET_MODE (op0)); if (known_eq (bitnum, 0U) && known_eq (bitsize, GET_MODE_BITSIZE (GET_MODE (op0)))) @@ -808,13 +808,13 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize, poly_uint64 bitnum, return true; } } - else if (((constant_multiple_p (bitnum, regsize * BITS_PER_UNIT, ®num) - && multiple_p (bitsize, regsize * BITS_PER_UNIT)) - || undefined_p) + else if (multiple_p (bitnum, BITS_PER_UNIT, &bytenum) + && (undefined_p + || (multiple_p (bitnum, regsize * BITS_PER_UNIT) + && multiple_p (bitsize, regsize * BITS_PER_UNIT))) && known_ge (GET_MODE_BITSIZE (GET_MODE (op0)), bitsize)) { - sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0), - regnum * regsize); + sub = simplify_gen_subreg (fieldmode, op0, GET_MODE (op0), bytenum); if (sub) { if (reverse)
reply other threads:[~2022-08-30 14:44 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=20220830144442.8828B382F09D@sourceware.org \ --to=rsandifo@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).