Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
