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