Re: [Qemu-devel] [PATCH] configure: Always compile with -fwrapv

[Markus Armbruster]

Peter Maydell <address@hidden> writes:

> QEMU's code relies on left shifts of signed integers always
> being defined behaviour with the obvious 2s-complement
> semantics. The only way to tell the compiler (and any
> associated undefined-behaviour sanitizer) that we require a
> C dialect with these semantics is to use the -fwrapv option.
> This is a bit of a heavy hammer for the job as it also gives
> us guaranteed semantics on integer arithmetic overflow which
> in theory we don't require.
>
> In an ideal world this would allow us to drop the warning
> flag -Wno-shift-negative-value, but we must retain this to
> avoid spurious warnings on clang versions predating the
> fix to https://llvm.org/bugs/show_bug.cgi?id=25552.
>
> Signed-off-by: Peter Maydell <address@hidden>
> ---
> We agreed before 2.7 release that this was the best long term
> approach to our shift issues, since it's now clear that both
> clang and gcc do agree that -fwrapv provides the semantics we
> want.
>
>  configure | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 331c36f..14efce3 100755
> --- a/configure
> +++ b/configure
> @@ -389,7 +389,11 @@ sdl2_config="${SDL2_CONFIG-${cross_prefix}sdl2-config}"
>  ARFLAGS="${ARFLAGS-rv}"
>  
>  # default flags for all hosts
> -QEMU_CFLAGS="-fno-strict-aliasing -fno-common $QEMU_CFLAGS"
> +# We use -fwrapv to tell the compiler that we require a C dialect where
> +# left shift of signed integers is well defined and has the expected
> +# 2s-complement style results. (Both clang and gcc agree that it
> +# provides these semantics.)
> +QEMU_CFLAGS="-fno-strict-aliasing -fno-common -fwrapv $QEMU_CFLAGS"
>  QEMU_CFLAGS="-Wall -Wundef -Wwrite-strings -Wmissing-prototypes $QEMU_CFLAGS"
>  QEMU_CFLAGS="-Wstrict-prototypes -Wredundant-decls $QEMU_CFLAGS"
>  QEMU_CFLAGS="-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
> $QEMU_CFLAGS"

If I remember correctly, we discussed -fno-strict-overflow (which the
kernel uses), but in the end opted for the more stringent -fwrapv.

Reviewed-by: Markus Armbruster <address@hidden>