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

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

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

--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:4b0443361a82ef89d519c9ae6d4d3bec74376e8f

commit r14-9694-g4b0443361a82ef89d519c9ae6d4d3bec74376e8f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 27 19:38:06 2024 +0100

    c-family: Cast __atomic_load_*/__atomic_exchange_* result to _BitInt rather
then VCE it [PR114469]

    As written in the PR, torture/bitint-64.c test fails with -O2 -flto
    and the reason is that on _BitInt arches where the padding bits
    are undefined, the padding bits in the _Atomic vars are also undefined,
    but when __atomic_load or __atomic_exchange on a _BitInt _Atomic variable
    with some padding bits is lowered into __atomic_load_{1,2,4,8,16} or
    __atomic_exchange_*, the mode precision unsigned result is
VIEW_CONVERT_EXPR
    converted to _BitInt and because of the VCE nothing actually sign/zero
    extends it as needed for later uses - the var is no longer addressable and
    expansion assumes such automatic vars are properly extended.

    The following patch fixes that by using NOP_EXPR on it (the
    VIEW_CONVERT_EXPR after it will then be optimized away during
    gimplification, didn't want to repeat it in the code as else result =
build1
    (VIEW_CONVERT_EXPR, ...); twice.

    2024-03-27  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/114469
            * c-common.cc (resolve_overloaded_builtin): For _BitInt result
            on !extended targets convert result to the _BitInt type before
            using VIEW_CONVERT_EXPR.