[Bug tree-optimization/114469] New: gcc.dg/torture/bitint-64.c failure with -O2 -flto -std=c23 -fwrapv

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

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

            Bug ID: 114469
           Summary: gcc.dg/torture/bitint-64.c failure with -O2 -flto
                    -std=c23 -fwrapv
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

This test fails with
make check-gcc GCC_TEST_RUN_EXPENSIVE=1
RUNTESTFLAGS="dg-torture.exp=bitint-64.c"
FAIL: gcc.dg/torture/bitint-64.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
The question is if _Atomic _BitInt(5) should be in memory always sign extended,
or as the ABI says the upper bits are unspecified.
If the former, then I'd say the problem is on the
/* Strip inner integral conversions that do not change precision or size, or
   zero-extend while keeping the same size (for bool-to-char).  */
(simplify
  (view_convert (convert@0 @1))
  (if ((INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0)))
       && (INTEGRAL_TYPE_P (TREE_TYPE (@1)) || POINTER_TYPE_P (TREE_TYPE (@1)))
       && TYPE_SIZE (TREE_TYPE (@0)) == TYPE_SIZE (TREE_TYPE (@1))
       && (TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1))
           || (TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE
(@1))
               && TYPE_UNSIGNED (TREE_TYPE (@1)))))
   (view_convert @1)))
match.pd simplification which transforms
  _5 = (unsigned _BitInt(5)) _4;
  _7 = (unsigned _BitInt(5)) e.0_1;
  _8 = _5 + _7;
  _9 = (_BitInt(5)) _8;
  _10 = VIEW_CONVERT_EXPR<unsigned char>(_9);
to just
  _5 = (unsigned _BitInt(5)) _4;
  _7 = (unsigned _BitInt(5)) e.0_1;
  _8 = _5 + _7;
  _10 = VIEW_CONVERT_EXPR<unsigned char>(_8);
so it is no longer sign extended in the unsigned char.
If the upper bits are undefined as the psABI on x86 says, then perhaps the
VIEW_CONVERT_EXPR emitted by c-common.cc (resolve_overloaded_builtin) is the
culprit:
      _13 = __atomic_load_1 (&b, 5);
      _14 = VIEW_CONVERT_EXPR<_BitInt(5)>(_13);
and we should change that
            /* Cast function result from I{1,2,4,8,16} to the required type. 
*/
            result = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (new_return),
result);
to something like if (INTEGRAL_TYPE_P (TREE_TYPE (new_return))IINTEGRAL_TYPE_P
(TREE_TYPE (new_return))NTEGRAL_TYPE_P (TREE_TYPE (new_return)))
            if (INTEGRAL_TYPE_P (TREE_TYPE (new_return)))
              result = fold_convert (TREE_TYPE (new_return), result);
            else
              result = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (new_return),
result);
Joseph, thoughts on this?