lkml.org 
[lkml]   [2009]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Bug 13012] 2.6.28.9 causes init to segfault on Debian etch; 2.6.28.8 OK
From
Date
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


\
 
 \ /
  Last update: 2009-07-13 07:33    [W:0.186 / U:1.608 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site