https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98957
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Though, in this case it seems like the best fix is to:
2021-02-04 Jakub Jelinek <ja...@redhat.com>
PR target/98957
* config/i386/x86-tune.def (X86_TUNE_BRANCH_PREDICTION_HINTS,
X86_TUNE_PROMOTE_QI_REGS): Use HOST_WIDE_INT_0U instead of 0U.
(X86_TUNE_QIMODE_MATH): Use ~HOST_WIDE_INT_0U instead of ~0U.
--- gcc/config/i386/x86-tune.def.jj 2021-01-04 10:25:45.175162012 +0100
+++ gcc/config/i386/x86-tune.def 2021-02-04 10:56:20.031489884 +0100
@@ -580,15 +580,16 @@ DEF_TUNE (X86_TUNE_AVOID_VECTOR_DECODE,
on simulation result. But after P4 was made, no performance benefit
was observed with branch hints. It also increases the code size.
As a result, icc never generates branch hints. */
-DEF_TUNE (X86_TUNE_BRANCH_PREDICTION_HINTS, "branch_prediction_hints", 0U)
+DEF_TUNE (X86_TUNE_BRANCH_PREDICTION_HINTS, "branch_prediction_hints",
+ HOST_WIDE_INT_0U)
/* X86_TUNE_QIMODE_MATH: Enable use of 8bit arithmetic. */
-DEF_TUNE (X86_TUNE_QIMODE_MATH, "qimode_math", ~0U)
+DEF_TUNE (X86_TUNE_QIMODE_MATH, "qimode_math", ~HOST_WIDE_INT_0U)
/* X86_TUNE_PROMOTE_QI_REGS: This enables generic code that promotes all 8bit
arithmetic to 32bit via PROMOTE_MODE macro. This code generation scheme
is usually used for RISC targets. */
-DEF_TUNE (X86_TUNE_PROMOTE_QI_REGS, "promote_qi_regs", 0U)
+DEF_TUNE (X86_TUNE_PROMOTE_QI_REGS, "promote_qi_regs", HOST_WIDE_INT_0U)
/* X86_TUNE_EMIT_VZEROUPPER: This enables vzeroupper instruction insertion
before a transfer of control flow out of the function. */
because disabling QImode math on all the PROCESSOR_* tunings which happen to be
>= 32 seems unintended. E.g. in GCC 8 that was just
PROCESSOR_BTVER2 and PROCESSOR_ZNVER1, in GCC <= 7 none, in GCC 9
PROCESSOR_BDVER{2,3,4}, PROCESSOR_BTVER{1,2} and PROCESSOR_ZNVER{1,2},
GCC 10 added PROCESSOR_AMDFAM10 to the GCC 9 set and trunk adds
PROCESSOR_ATHLON, PROCESSOR_K8 and PROCESSOR_ZNVER3 to that set (set of tunings
that disable QImode math).
