On Mon, Apr 24, 2017 at 12:17 PM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Mon, Apr 24, 2017 at 11:44 AM, Arnd Bergmann <a...@arndb.de> wrote:
>> On Sun, Apr 23, 2017 at 10:13 PM, Geert Uytterhoeven
>> <ge...@linux-m68k.org> wrote:
>>> On Sat, Apr 22, 2017 at 5:30 PM, Arnd Bergmann <a...@arndb.de> wrote:
>>> My main motivation for keep on using gcc-4.1 is that it gives many warnings
>>> that were disabled in later gcc versions. I do look at all new warnings,
>>> and
>>> send patches when they are real bugs, or are trivial to silence.
>>
>> What kind of warnings do you see that disappeared with later versions?
>> Do you know what caused them to disappear in later versions (different
>> optimization decisions, warning getting disabled by default but still
>> available
>> for turning on manually, ...)? Do you know if the disabled warnings are
>> still there in gcc-4.3 (I can try it out if you give me examples)?
>
> Mostly the "may be used uninitialized" warnings. I believe they were disabled
> in gcc-4.3 (4.2?) and later due to too many false positives, which is not an
> issue for me, as I look at differences.
> They were re-enabled lately (with much less false-positives), that's why you
> see them, and fix them.
Linus added -Wno-maybe-uninitialized a while ago, and I think only gcc-4.8
and higher were affected by that, as earlier versions only understand
-Wuninitialized (meaning both "definitely uninitialized" and "might be
uninitialized". The latest state is that gcc-4.9 enables all uninitialized
warnings and I try to fix them for all known compilers, gcc-4.8
disables -Wmaybe-uninitialized unless you build with "make W=2".
On gcc-4.9 and higher, we also don't enable -Wmaybe-unintialized when
certain configuration options are set that cause extra false positives,
but it's still enabled with W=2.
I actually think it would be a good idea to also disable -Wuninitialized
for gcc-4.7 and earlier unless you ask for W2. That would get us
much closer to a clean build, but still give you the chance to see the
warnings if you really want to.
> For example, do you see the warning fixed by commit 1b8c1012142d8322
> ("drivers: net: xgene: Simplify xgene_enet_setup_mss() to kill warning")
> with gcc-4.3? Yes, that was a false positive.
I see this one until gcc-4.8 if I build with W=2 to turn the warning back on.
> Or see commit cc4a7ffe02c95f53 ("spi: fsl-lpspi: Pre-initialize ret in
> fsl_lpspi_transfer_one_msg()"). That one was a real bug.
>
> I don't see that in any of the kisskb build logs, and they use gcc-4.2.4 for
> avr32. So having gcc-4.2 or gcc-4.3 in a farm won't help.
Also here: I see the warning on ARM with all versions from gcc-4.1 through
4.8 (with W=1), but not any higher versions including 7.0.1. If I mark
fsl_lpspi_transfer_one as 'noinline', I see it on all versions, which is a bit
odd. It might be worth opening a gcc bug report for that. I tried the
'noinline' as I suspected gcc might be smart enough to figure out that
the list is never empty, but I later noticed that it has no way of knowing
that even without the 'noinline' flag.
> And as long as I find real bugs this way, I'd like to continue doing it.
I've tested all the architectures I mentioned earlier that were around 10
years ago (aside from ia64, I could not build gcc successfully) with
linux-4.3 (arbitrarily picked, this was the version in which x86 and mips
no longer built with gcc-4.1), and built a defconfig with both gcc-4.9
(which I had around from earlier testing) and with gcc-4.1/4.3:
gcc-4.1 gcc-4.3 gcc-4.9
alpha failed success success
arm failed success success
cris failed success success
frv failed failed success
m32r success success success
m68k success success success
mips failed failed success
parisc success success success
powerpc failed failed success
s390 failed failed success
sh failed success success
x86 failed success success
I'd conclude that nobody aside from you sends bugfixes for 4.1,
or has done so in a while. I have the logs available if you want,
but there isn't really much surprising: we get the same link error
as on mips and x86 on some additional architectures, powerpc
and s390 use features that weren't available and frv hits an ICE.
We could define the minimum compiler to be gcc-4.3 on all architectures
except m68k (and possibly parisc, certainly nobody cares about
m32r enough), where it would be gcc-4.1, to reflect what is actually
already the case.
Arnd
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
