[Bug middle-end/108623] We need to grow the precision field in tree_type_common for PowerPC

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:e2b993db57f90fedd1bd7756f7ad4c5bfded4b8f

commit r14-577-ge2b993db57f90fedd1bd7756f7ad4c5bfded4b8f
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>

            PR middle-end/108623
            * tree-core.h (tree_type_common): Bump up precision field to 16
bits.
            Align bit fields > 1 bit to at least an 8-bit boundary.