Re: [PATCH 0/5] Remove a few hurdles of compiling with clang

Simon Marchi
2017-06-12T15:54:42Z

On 2017-06-12 16:35, Eli Zaretskii wrote:
> That's not the issue: AFAIU, GDB already builds with clang.
>
> The issue is how much effort would we want to invest for that, and
> what are we willing to give up when using GCC to be able to use other
> compilers. For example, the proposed patch adds an explicit "-x c++"
> switch to _all_ compilations, and also tweaks the warning switches.
> I'm not sure we want GCC builds to be affected so that clang builds
> could be cleaner. But maybe we have a policy about this which deems
> these issues acceptable?

Hi Eli,

I included in this patchset the changes that I think improve the
situation with Clang, but are neutral to GCC, so I don't think these
should pose any problem. Here is what I have to say about each patch:

- gdb: Pass -x c++ to the compiler: GCC (and even the Intel compiler)
supports this option too, at worst it's a neutral change for compiling
with GCC.

- gdb: Use -Werror when checking for (un)supported warning flags: it
just forces the behavior to what's already the default with GCC. Again,
it's neutral at worst, at best it protects us if GCC ever decides to
change its default behavior.

- gdb: Add -Wno-mismatched-tags: We already have a system that tests
which warning flags are supported by the current compiler, so this flag
will not be included in the builds with GCC. So it's neutral for GCC,
and improves the situation for Clang with almost no effort.

- linux-low: Remove usage of "register" keyword: That's a good legacy
code cleanup in any case, IMHO.

- Add ATTRIBUTE_PRINTF to trace_start_error: It's actually a legit
warning, I'm surprised GCC itself doesn't warn about that.

But I think it's a good thing to discuss how far we're willing to go to
make GDB build cleanly with Clang, because some other issues are not so
easily resolved. Some warnings are a bit silly and don't provide much
value (e.g. [1] or -Wmismatched-tags), so it may not make sense to go
too far out of our way to make it happy.

I think it's also good to have this discussion because of how relevant
Clang is nowadays. A big number of software developers are on OS
X/macOS, on which Clang is the default compiler (shipped with Xcode).
Making the source more Clang-friendly removes a barrier to them
contributing to GDB.

Simon

[1] https://bugs.llvm.org//show_bug.cgi?id=22712#c1