Gcc as callable libraries (was: removing toxic emailers)

David Malcolm dmalcolm@redhat.com
Thu Apr 15 21:31:06 GMT 2021


On Thu, 2021-04-15 at 21:48 +0200, Thomas Koenig wrote:
> David,
> 
> for some reason or other, I did not get your mail, so I will
> just reply copying in from the archive.
> 
> First, thanks for injecting some sanity into the discussion.

Thanks Thomas

> I will not discuss RMS' personal shortcomings or the lack of them.
> In today's toxic political climate, such allegations are often
> made up and weaponized without an effective defense for the
> alleged wrongdoer.  I don't know the truth of the matter, and I make
> a point of not finding out.

Fair enough.

>  > In many ways the last 8 years of my career have been
>  > an attempt to get gcc to respond to the appearance of LLVM/clang
> (I've
>  > added JIT-compilation, improved diagnostics, and I'm implementing
> a
>  > static analysis pass)
> 
> And this is highly welcome, and has made gcc (including gfortran) a
> much
> better compiler.  I well remember how you implemented the much better
> colored error messages that gfortran has now.

I've added a bunch of features to the C and C++ frontends (underlined
ranges, labelling of such reanges, fix-it hints, etc), but I don't have
the Fortran skills to know what would be appropriate to gfortran.  Let
me know if you have ideas for specific improvements to how gfortran
diagnostics work that I might be able to help implement.

> 
>  > Perhaps a pronouncement like: "try to make everything be
> consumable as
>  > libraries with APIs, as well as as standalone binaries" might have
>  > helped (and still could; can we do that please?)
> 
> That makes perfect sense, as LLVM shows, and is something that the
> steering committee could decide for the project (or rather, it could
> issue a pronouncement that this will not be opposed if some volunteer
> does it).
> 
> I think this could be as close to an unanimous decision as there can
> be among such a diverse community as the gcc developers.  If the FSF
> takes umbrage at this, the ball is in their court.

I deliberately added the weasel-words "try to", because these things
are, of course, much easier said that done.

I attempted to reduce gcc's use of global state back in 2013 with a
view to making it a shared library, but eventually the sheer size of
the task overwhelmed me.  In libgccjit I hid everything behind a
separate API, with a bug mutex guarding all of gcc's global state,
which feels like something of a cop-out.

One idea I had would be to refactor out our diagnostics code into a
libdiagnostics (or similar), so that all of the source-
printing/underlining/fix-it logic etc could be used outside of gcc, and
the use of diagnostic_context might help towards that.  But even "just"
that's decidedly non-trivial.

Hope this is constructive
Dave




More information about the Gcc mailing list