(no subject)

Hi,

As the LLDB build currently exists, there are a large number of warnings which clutter the build. This is even worse on Linux when building with gcc.

I was wondering if there would be any objection to forcing errors on warnings as they as they get cleaned up. This requires that the compiler support marking certain warnings a errors (i.e. -Werror=*). clang and gcc support many of these, and this would need to be conditionalised on compiler support to ensure that no one is prevented from continuing to build LLDB.

LLVM actually has buildbots that build with -Werror which helps prevent new errors from being integrated in clang and LLVM, unfortunately, the buildbot situation for LLDB is not as pretty. As such, I was wondering if it would be acceptable to push this down into the normal build.

+1

On Linux/gcc, the great majority of warnings is for a warning about using %p in a printf with a void* argument, which IMHO is a bogus warning that only gcc emits, and AFAICT can’t be disabled without disabling the other far-more-useful printf warnings. I wound up writing a script to filter these out from my build logs rather than try to fix them all.

Yes, we might consider this is the GCC warning that Steve mentions below is able to be disabled for GCC builds.

The one problem is the variety of warnings that are enabled by default on different systems. GCC enables different things by default, and so does clang. As the compilers change it will be hard for other people on other systems to keep up. Also, no changes should ever be reverted because of compiler warnings, people would need to fix them on the system on which they are failing due to the compiler differences...

So currently, unless GCC can disable the lame "%p" warning when using anything but a "void *", this is a non-starter.

Greg

Yes, we might consider this is the GCC warning that Steve mentions below
is able to be disabled for GCC builds.

While Steve is correct that the %p conversion does cause a large amount of
noise, it is not the only warning that gets emitted.

The one problem is the variety of warnings that are enabled by default on
different systems. GCC enables different things by default, and so does
clang. As the compilers change it will be hard for other people on other
systems to keep up. Also, no changes should ever be reverted because of
compiler warnings, people would need to fix them on the system on which
they are failing due to the compiler differences...

So currently, unless GCC can disable the lame "%p" warning when using

anything but a "void *", this is a non-starter.

Just to make sure that we are talking about the same thing, I am *not*
suggesting we enable -Werror (even LLVM doesnt do that by default, only on
the buildbots). I am suggesting that once things are cleaned up, we enable
those specific items as errors to avoid having them be re-introduced.

Yes, we might consider this is the GCC warning that Steve mentions below
is able to be disabled for GCC builds.

The one problem is the variety of warnings that are enabled by default on
different systems. GCC enables different things by default, and so does
clang. As the compilers change it will be hard for other people on other
systems to keep up. Also, no changes should ever be reverted because of
compiler warnings, people would need to fix them on the system on which
they are failing due to the compiler differences...

So currently, unless GCC can disable the lame "%p" warning when using
anything but a "void *", this is a non-starter.

I realise that this is probably an exercise in futility, but, if I were to
spend the time to add the appropriate casts for the pointer conversions
(which consequentially would quiet up some of the static analyzer
warnings!), would there be any objections to that?

Having slowly cleaned up some of the warnings, it seems that there are
actual minor things floating about that we were missing.

I’m not against it.

Locally I’ve occasionally done the static_cast<void*> (something_p) and that shuts up the gcc %p warning. (And in the process have found interesting things like enum cases being ignored, etc.).

One negative of all that IMHO is that it adds clutter, but if it helps us find real warnings, my vote would be to do it.

I guess bonus points would be for adding clang --fixit for this one…

I'm not against it.

Locally I've occasionally done the static_cast<void*> (something_p) and
that shuts up the gcc %p warning. (And in the process have found
interesting things like enum cases being ignored, etc.).

One negative of all that IMHO is that it adds clutter, but if it helps us
find real warnings, my vote would be to do it.

Just an FYI in case people missed it, I pushed the change to quiet up that
warning. There are still a few other warnings that are floating around,
but, it is a much more happy build now.

This goes back to my original question of, do we want to add -Werror=
options for the warnings that have been cleaned up to prevent regressing on
those specifically?

I don't think this is the correct approach, the warning should just be
disabled for GCC as lame...

Joerg

I think the issue there is that sometimes the warning is appropriate.

I suspect one way to handle is to disable on gcc and just expect the clang builds to catch the real issues in that case.

Correct, that was my suggestion.

Joerg