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

[Simon Marchi <simon dot marchi at polymtl dot ca>]

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