[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3k52d1775.fsf@google.com>
Date: Sun, 12 Jul 2009 22:29:50 -0700
From: Ian Lance Taylor <iant@...gle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Frans Pop <elendil@...net.nl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kbuild@...r.kernel.org, barryn@...ox.com,
bugme-daemon@...zilla.kernel.org
Subject: Re: [Bug 13012] 2.6.28.9 causes init to segfault on Debian etch; 2.6.28.8 OK
Linus Torvalds <torvalds@...ux-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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists