[Bug target/84945] [8 Regression] UBSAN: gcc/config/i386/i386.c:33312:22: runtime error: shift exponent 32 is too large for 32-bit type 'int'

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Last reconfirmed|2018-03-19 00:00:00         |
                 CC|                            |hjl.tools at gmail dot com,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |kyukhin at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org
            Version|unknown                     |8.0
            Summary|UBSAN:                      |[8 Regression] UBSAN:
                   |gcc/config/i386/i386.c:3331 |gcc/config/i386/i386.c:3331
                   |2:22: runtime error: shift  |2:22: runtime error: shift
                   |exponent 32 is too large    |exponent 32 is too large
                   |for 32-bit type 'int'       |for 32-bit type 'int'

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ugh, this is an important issue.
In GCC 7 we had F_MAX 31, so all of the runtime feature tests are fine.

We have:
struct __processor_model
{
  unsigned int __cpu_vendor;
  unsigned int __cpu_type;
  unsigned int __cpu_subtype;
  unsigned int __cpu_features[1];
} __cpu_model;
and that is an exported variable from libgcc, thankfully only as @GCC_4.8
symbol and thus new programs shouldn't link against that.

No matter what, at least for targets that don't use symbol versioning and
prevent using that symbol, I think we need to rename __cpu_model to something
else (__cpu_model2), add at least one another 32-bit __cpu_features bitfield
and for features >= 32 use the second field instead of the first one.