David Blaikie <dblaikie at gmail.com> writes:> Selfhost clang. Whenever we get a warning from Clang we either fix > Clang or fix the build quite quickly.Not possible,> If you want to fix the build such that LLVM can be built -Werror clean > with GCC the right solution is going to be to turn off -Wuninitialized > when the LLVM build system detects that it is using GCC rather than > Clang (we have the inverse, where we turn on certain Clang warning > flags when we detect that we're using Clang).I would like to keep -Wuninitialized if at all possible because it does in fact detect bugs.> Pragmas: maybe, but it would probably muddy the waters a fair bit. > Depends how noisy any given warning is - I suspect -Wuninitialized > wouldn't meet the bar for pragma suppressions (there would be too many > suppressions) & should just be disabled in the build system when using > GCC. We can rely on Clang's warnings to catch things that can be > caught reliably.I really dislike disabling warnings if we can suppress them in specific cases. I can't use clang to catch things, gcc is my only option. -David
On Thu, Jan 3, 2013 at 11:16 AM, <dag at cray.com> wrote:> David Blaikie <dblaikie at gmail.com> writes: > >> Selfhost clang. Whenever we get a warning from Clang we either fix >> Clang or fix the build quite quickly. > > Not possible,Out of curiosity - why not? (sure, I realize everyone has internal build systems, etc, that they're ultimately integrating LLVM into - but that doesn't mean you have to do your development there (Google has an internal build system & I could do my development there, but I tend to develop with an upstream-style CMake+Ninja (& selfhosting) setup))>> If you want to fix the build such that LLVM can be built -Werror clean >> with GCC the right solution is going to be to turn off -Wuninitialized >> when the LLVM build system detects that it is using GCC rather than >> Clang (we have the inverse, where we turn on certain Clang warning >> flags when we detect that we're using Clang). > > I would like to keep -Wuninitialized if at all possible because it does > in fact detect bugs.I'm not saying it doesn't detect bugs. My statement(s) were made with that (& other issues mentioned) in mind.>> Pragmas: maybe, but it would probably muddy the waters a fair bit. >> Depends how noisy any given warning is - I suspect -Wuninitialized >> wouldn't meet the bar for pragma suppressions (there would be too many >> suppressions) & should just be disabled in the build system when using >> GCC. We can rely on Clang's warnings to catch things that can be >> caught reliably. > > I really dislike disabling warnings if we can suppress them in specific > cases.It just depends how many cases there are. If it becomes a very common suppression the pragmas will rather get in the way of working with the code.> I can't use clang to catch things, gcc is my only option.
David Blaikie <dblaikie at gmail.com> writes:>>> Selfhost clang. Whenever we get a warning from Clang we either fix >>> Clang or fix the build quite quickly. >> >> Not possible, > > Out of curiosity - why not? (sure, I realize everyone has internal > build systems, etc, that they're ultimately integrating LLVM into - > but that doesn't mean you have to do your development there (Google > has an internal build system & I could do my development there, but I > tend to develop with an upstream-style CMake+Ninja (& selfhosting) > setup))We use gcc to build our whole compiler and we develop, test and release all using the same build process so that things are consistent. In the past we've been burned when developers use a different process and don't see bugs that testers see.>>> Pragmas: maybe, but it would probably muddy the waters a fair bit. >>> Depends how noisy any given warning is - I suspect -Wuninitialized >>> wouldn't meet the bar for pragma suppressions (there would be too many >>> suppressions) & should just be disabled in the build system when using >>> GCC. We can rely on Clang's warnings to catch things that can be >>> caught reliably. >> >> I really dislike disabling warnings if we can suppress them in specific >> cases. > > It just depends how many cases there are. If it becomes a very common > suppression the pragmas will rather get in the way of working with the > code.How about I prepare patches with the pragmas and then folks can review them and see how they feel. Does that sound reasonable? -David