Re: [Bug 13012] 2.6.28.9 causes init to segfault on Debian etch; 2.6.28.8 OK

[Ian Lance Taylor <iant@google.com>]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Ian: we generally do try to be careful and use explicit unsigned types for 
> code that cares about overflow, but we use -fwrapv because there have been 
> some cases where we didn't (and used pointer comparisons or signed 
> integers).
>
> The problem is that apparently gcc-4.1.x was literally generating buggy 
> code with -fwrapv. So now the choice for us is between switching to an 
> explicit version test:
>
> 	-KBUILD_CFLAGS  += $(call cc-option,-fwrapv)
> 	+KBUILD_CFLAGS  += $(shell if [ $(call cc-version) -ge 0402 ]; then \
> 	+                   echo $(call cc-option,-fwrapv); fi ;)
>
> or just switching to -fno-strict-overflow instead:
>
> 	-KBUILD_CFLAGS  += $(call cc-option,-fwrapv)
> 	+KBUILD_CFLAGS  += $(call cc-option,-fno-strict-overflow)
>
> which avoids the buggy gcc versions because it's simply not even supported 
> by gcc-4.1.x (and even if that wasn't the case, possibly because only 
> 'wrapv' is the problematic case - apparently the difference _does_ 
> matter to gcc).

My instinctive advice is that y'all should track down and fix the cases
where the program relies on signed overflow being defined.  However, if
that is difficult--and it is--then I agree that -fno-strict-overflow is
preferable when using a compiler which supports it (gcc 4.2.0 and
later).

(The gcc 4.2 and later option -Wstrict-overflow=N can help find the
cases where a program relies on defined signed overflow, but only if
somebody is patient enough to wade through all the false positives.)

Ian