On Wed, 27 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> 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.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
This is OK. A natural question arising is whether anything else might
generate a VIEW_CONVERT_EXPR for code that somehow reinterprets memory as
of type _BitInt, and then later fail to ensure required sign/zero
extension, or whether this is the only place where a VIEW_CONVERT_EXPR of
_BitInt type can cause problems.
--
Joseph S. Myers
[email protected]
