public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Michael Meissner <meissner@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/users/meissner/heads/dmf007)] Bump up precision size to 16 bits. Date: Wed, 1 Feb 2023 17:30:39 +0000 (GMT) [thread overview] Message-ID: <20230201173039.D10BA3858D33@sourceware.org> (raw) https://gcc.gnu.org/g:829013c6261c6142c6f269eb0b9e605aa65549d5 commit 829013c6261c6142c6f269eb0b9e605aa65549d5 Author: Michael Meissner <meissner@linux.ibm.com> Date: Wed Feb 1 12:30:19 2023 -0500 Bump up precision size to 16 bits. The new __dmr type that is being added as a possible future PowerPC instruction set bumps into a structure field size issue. The size of the __dmr type is 1024 bits. The precision field in tree_type_common is currently 10 bits, so if you store 1,024 into field, you get a 0 back. When you get 0 in the precision field, the ccp pass passes this 0 to sext_hwi in hwint.h. That function in turn generates a shift that is equal to the host wide int bit size, which is undefined as machine dependent for shifting in C/C++. int shift = HOST_BITS_PER_WIDE_INT - prec; return ((HOST_WIDE_INT) ((unsigned HOST_WIDE_INT) src << shift)) >> shift; It turns out the x86_64 where I first did my tests returns the original input before the two shifts, while the PowerPC always returns 0. In the ccp pass, the original input is -1, and so it worked. When I did the runs on the PowerPC, the result was 0, which ultimately led to the failure. 2023-02-01 Richard Biener <rguenther@suse.de> Michael Meissner <meissner@linux.ibm.com> gcc/ * hwint.h (sext_hwi): Add assertion against precision 0. * tree-core.h (tree_type_common): Bump up precision field to 16 bits. Diff: --- gcc/hwint.h | 1 + gcc/tree-core.h | 24 ++++++++++++------------ 2 files changed, 13 insertions(+), 12 deletions(-) diff --git a/gcc/hwint.h b/gcc/hwint.h index e31aa006fa4..ba92efbfc25 100644 --- a/gcc/hwint.h +++ b/gcc/hwint.h @@ -277,6 +277,7 @@ ctz_or_zero (unsigned HOST_WIDE_INT x) static inline HOST_WIDE_INT sext_hwi (HOST_WIDE_INT src, unsigned int prec) { + gcc_checking_assert (prec != 0); if (prec == HOST_BITS_PER_WIDE_INT) return src; else diff --git a/gcc/tree-core.h b/gcc/tree-core.h index 8124a1328d4..b71748c6c02 100644 --- a/gcc/tree-core.h +++ b/gcc/tree-core.h @@ -1686,18 +1686,8 @@ struct GTY(()) tree_type_common { tree attributes; unsigned int uid; - unsigned int precision : 10; - unsigned no_force_blk_flag : 1; - unsigned needs_constructing_flag : 1; - unsigned transparent_aggr_flag : 1; - unsigned restrict_flag : 1; - unsigned contains_placeholder_bits : 2; - + unsigned int precision : 16; ENUM_BITFIELD(machine_mode) mode : 8; - - /* TYPE_STRING_FLAG for INTEGER_TYPE and ARRAY_TYPE. - TYPE_CXX_ODR_P for RECORD_TYPE and UNION_TYPE. */ - unsigned string_flag : 1; unsigned lang_flag_0 : 1; unsigned lang_flag_1 : 1; unsigned lang_flag_2 : 1; @@ -1713,12 +1703,22 @@ struct GTY(()) tree_type_common { so we need to store the value 32 (not 31, as we need the zero as well), hence six bits. */ unsigned align : 6; + /* TYPE_STRING_FLAG for INTEGER_TYPE and ARRAY_TYPE. + TYPE_CXX_ODR_P for RECORD_TYPE and UNION_TYPE. */ + unsigned string_flag : 1; + unsigned no_force_blk_flag : 1; + unsigned warn_if_not_align : 6; + unsigned needs_constructing_flag : 1; + unsigned transparent_aggr_flag : 1; + + unsigned contains_placeholder_bits : 2; + unsigned restrict_flag : 1; unsigned typeless_storage : 1; unsigned empty_flag : 1; unsigned indivisible_p : 1; unsigned no_named_args_stdarg_p : 1; - unsigned spare : 15; + unsigned spare : 9; alias_set_type alias_set; tree pointer_to;
reply other threads:[~2023-02-01 17:30 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=20230201173039.D10BA3858D33@sourceware.org \ --to=meissner@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).