Gcc as callable libraries (was: removing toxic emailers)
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. 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. > 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. > 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.
Re: Gcc as callable libraries (was: removing toxic emailers)
On Thu, Apr 15, 2021 at 5:04 PM Thomas Koenig via Gcc 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. > > 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. > > > 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. > > > 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. Andrew Macleod led a BOF at GNU Cauldron 2013 that discussed re-architecting and modularizing GCC along these same lines. The header flattening was one step. Thanks, David
Re: Gcc as callable libraries (was: removing toxic emailers)
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
Re: Gcc as callable libraries (was: removing toxic emailers)
On Thu, 2021-04-15 at 17:31 -0400, David Malcolm via Gcc wrote: > On Thu, 2021-04-15 at 21:48 +0200, Thomas Koenig wrote: [...snip...] > > > 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, ~~~ big, I meant to write. > which feels like something of a cop-out. libgccjit calls into as and ld, which shows up in the profile, so another idea I dabbled in the whole "libraries rather than just executables" area is to make as and ld buildable as shared libraries; hence this 2015 experiment: "[PATCH 00/16] RFC: Embedding as and ld inside gcc driver and into libgccjit" crossposted between gcc-patches and binutils here: https://gcc.gnu.org/legacy-ml/gcc-patches/2015-06/msg00116.html https://sourceware.org/legacy-ml/binutils/2015-06/msg00010.html (admittedly my prototype had a barely-existent API, but it gave me a 5x speedup on a synthetic benchmark, which was dominated by the overhead of dynamically linking libbfd into as and ld on each invocation IIRC; better to do it once when libgccjit is linked into the process). > > 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 > >
