On 03/21/14 11:25, Sergey Isakov wrote: > Hi, > Why not just correct the sources to eliminate these mistakes? > Sergey
Very good question, thank you. First, because the sources are already correct, and the things to change are *not* mistakes. They are valid constructs that the compilers fail to recognize as such. But this is the minor point. We do fix the warnings that we can see. Second, the major point is this: - I prepare a patch series, build it and test it at each patch, and make it warning-free. - I submit the patchset, Jordan and the community reviews it, and Jordan prepares to commit it. About two weeks have passed since my posting. - Either Jordan tries to build the patchset with a different compiler than mine, or Jordan commits the patchset, someone fetches it from the repo, and tries to build it with a compiler different from mine. The build breaks with *invalid* warnings that I had absolutely no chance to see. At least another week has passed. So, I get to drop everything after three weeks and mangle my code to fix up an *invalid* warning that I had no chance to see. This is not a technical issue but a workflow one. "Correcting the sources to eliminate the mistakes", as you say, in a proactive manner, would require me to build *each* patch in my series (for bisectability), for at least *two* arches (Ia32 and X64), for at least *five* gcc versions (4.4 to 4.8) and like *three* MSVC versions. That's 2*(5+3) == 16 builds *per patch*. I sometimes have patchsets with ~20 patches, and that's not a high count for a patchset. Do you suggest I execute 320 builds before submitting a patchset? Do you build each one of your patches with sixteen (compiler, target arch) pairs during live development? Increasing the latency of your build cycle from like 1 minute to a quarter of an hour? And that's supposing that you can fire off each gcc version and each MSVC version in an automated, scripted manner, without human intervention. Thanks Laszlo > On 21.03.2014, at 13:53, Laszlo Ersek wrote: > >> Hi, >> >> I'm interested in feedback for the following BuildTools-related idea. >> >> Over the past months working with OVMF I have distilled the following >> conviction about invalid compiler warnings (false positives emitted for >> intended and valid C constructs): >> >> (1) gcc likes to warn about uninitialized local variables that it finds >> might be read without an intervening assignment. >> >> (2) MSVC like to warn about implicit type conversions in assignments and >> argument passing. >> >> Experience has shown that, for OVMF code specifically, these warnings >> are *always* wrong. They force us to mangle the code in order to shut >> them up, and they tend to throw a wrench in the gears of development >> process. >> >> The explanation for the latter fact is that the set of constructs that >> the compilers warn about is a moving target. It varies with compiler >> version *and* with target architecture (Ia32 vs. X64). >> >> In effect, requiring that these two classes of warnings be treated as >> errors under all circumstances *guarantees* that our *valid* code will >> be unjustifiedly rejected by *some* (compiler, architecture) >> combination. We cannot prepare ourselves in advance for all possible >> (compiler, architecture) pairs, hence the horrible disruption of >> workflow that I mention above. >> >> The most recent example is: >> >> for Ia32 for X64 >> --------- ----------------------- >> gcc-4.4 breaks[1] builds without a squeak >> gcc-4.8 breaks[2] builds without a squeak >> >> Note that [1] and [2] are *completely distinct* warnings. As in, when >> building for Ia32, gcc-4.4 and gcc-4.8 warn about uninitialized >> variables in *distinct* source files. The intersection of the warnings >> emitted is the empty set. (I know this because I completed both builds >> afterwards.) >> >> My proposal is the following. >> >> (1) For GCC, introduce the following additional compiler flags: >> >> GCC:*_GCC44_*_CC_FLAGS = -Wno-error=uninitialized >> GCC:*_GCC45_*_CC_FLAGS = -Wno-error=uninitialized >> GCC:*_GCC46_*_CC_FLAGS = -Wno-error=uninitialized >> GCC:*_GCC47_*_CC_FLAGS = -Wno-error=maybe-uninitialized >> GCC:*_GCC48_*_CC_FLAGS = -Wno-error=maybe-uninitialized >> >> Gcc-4.4 to gcc-4.6 cannot distinguish the following two cases: >> - "I can *prove* that this local variable is read while uninitialized" >> - "I can see some way, a possibly unreachable way, to read an >> uninitialized local variable". >> >> Hence for gcc-4.4 to gcc-4.6, we should degrade -Wuninitialized from >> error to warning. >> >> http://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Warning-Options.html#Warning-Options >> http://gcc.gnu.org/onlinedocs/gcc-4.5.4/gcc/Warning-Options.html#Warning-Options >> http://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Warning-Options.html#Warning-Options >> >> Gcc-4.7 and later *can* distinguish the above two cases (proven lack of >> initialization vs. possible). Hence we should degrade only >> -Wmaybe-uninitialized. >> >> http://gcc.gnu.org/onlinedocs/gcc-4.7.3/gcc/Warning-Options.html#Warning-Options >> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Warning-Options.html#Warning-Options >> >> (2) For MSVC, come up with a similar solution that degrades errors about >> *valid* implicit type conversions to warnings. >> >> Again, experience shows that, for OVMF specifically, treating these >> warnings as errors produces *net negative* value. There has not been >> *one* instance where the warning was right. >> >> The warnings should stay, but they must not stop the build. We will >> continue to address warnings *that we see* while developing code. We >> shall not allow the build to break for users who happen to use compilers >> / arches different from ours. >> >> Thanks, >> Laszlo >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/edk2-devel >> > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel > ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
