On Tue, Jul 5, 2011 at 6:41 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote:
> On Mon, Jul 4, 2011 at 11:38 PM, Peter Maydell <peter.mayd...@linaro.org> 
> wrote:
>> On 4 July 2011 23:00, Raghavendra D Prabhu <raghu.prabh...@gmail.com> wrote:
>>> This is to avoid gcc optimizating out the comparison in assert,
>>> due to assumption of signed overflow being undefined by default 
>>> (-Werror=strict-overflow).
>>
>>>--- a/Makefile.hw
>>>+++ b/Makefile.hw
>>>@@ -9,7 +9,7 @@ include $(SRC_PATH)/rules.mak
>>>
>>> $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw)
>>>
>>> -QEMU_CFLAGS+=-I.. -I$(SRC_PATH)/fpu
>>> +QEMU_CFLAGS+=-I.. -I$(SRC_PATH)/fpu -fno-strict-overflow
>>
>> Can you give a more detailed description of the problem this is trying
>> to solve? I think it would be nicer if we could remove the assumptions
>> about signed overflows instead, if that's practical.
>>
>> (Also, if we do want to add this compiler flag then it ought to be
>> done in configure I think, as we do for -fno-strict-aliasing.)
>
> "a correct C/C++ program must never generate signed overflow when
> computing an expression. It also means that a compiler may assume that
> a program will never generated signed overflow."
>
> http://www.airs.com/blog/archives/120

You can check out the warnings that gcc raises with ./configure
--extra-cflags="-Wstrict-overflow -fstrict-overflow" --disable-werror.

Either we'd have to fix the warnings or we could use
-fno-strict-overflow/-fwrapv.

This patch seems reasonable to me.  We're telling gcc not to take
advantage of the undefined behavior of signed overflow.  It also means
QEMU code is assuming two's complement representation and wrapping on
overflow, but that is a common assumption (what QEMU-capable hardware
doesn't?).

Reviewed-by: Stefan Hajnoczi <stefa...@linux.vnet.ibm.com>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to