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

[Pedro Alves <palves at redhat dot com>]

On 06/13/2017 10:14 AM, Yao Qi wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> That's precisely the reason why I raised this: it would be good to
>> have a clear policy on this, to avoid the need for unnecessary work
>> and unnecessary disputes.  (I actually hoped we already did have such
>> a policy, but if not, I think we should try to come up with it.)
> 
> In general, it is good to keep GDB built by different popular compilers,
> so people are easy to build GDB and different warnings from different
> compilers will catch more bugs in GDB.  On the other hand, GCC is still
> the primary compiler to build GDB, and support of other compilers in
> building GDB should not undermine the case that GDB is built by GCC.
> For example, it is not acceptable to build GDB with compiler X but break
> the build with GCC.  We still must fix the GDB build failure with GCC, as
> what we did in the past, and we welcome the contributions to fix the GDB
> build with other compilers.

I'm fine with that, as long as other compilers don't unreasonably hold
us back, when GCC is an option, and the user base that'd want to actually
use such a compiler is small.  E.g., maintenance effort, and migration
to newer language revisions.  Here I don't specifically mean Clang,
but in general.  E.g., exaggerating to illustrate a point, if someone wanted
to port GDB to OddballPlatform used by to handful of people in the world,
and that requires building with a 10-year-old compiler that nobody's
maintaining, then I think it'd be unreasonable for everyone upstream to have
to keep such a port in mind and consider whether such a port would get broken
by some GDB patch or design change.

Other popular compilers nowadays tend to support "GNU C/C++" and impersonate
as GCC (define __GNUC__, etc.), so porting effort tends to not be that big
in practice, fortunately.

The MSVC compiler issue came up in the -Wno-mismatched-tags discussion,
and I think my statements may have sounded too strongly against MSVC.
If someone wants to make GDB buildable with Visual Studio for some reason,
I'd personally be OK with that, as long as that doesn't involve uglifying
the codebase, or holding back migration to newer language revisions.
Modern versions are getting better at standards compliance and gnulib
supports MSVC (ISTR there's some command line compiler wrapper that makes
it possible to run configury with msvc), so it may actually be doable.
I don't know why would someone want to do it, though.  But until someone
seriously steps forward and commits to maintaining such a port, caring
about "-Wmismatched-tags" warnings is useless, since I suspect that
issue would be the least of the porting effort troubles.

BTW, on the different warnings, IMO, ideally every bug that Clang finds in
the code that GCC didn't warn about should be considered a GCC bug,
and we should make sure that it's reported on the GCC tracker.

Thanks,
Pedro Alves