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