On 02/13/2018 10:07 AM, Manuel López-Ibáñez wrote:
On 13/02/18 03:10, Martin Sebor wrote:
PS Is there any reason why diagnostic-core.h and diagnostic.c
does not/should not include tree.h and other GCC headers?
The short reason is that we want to keep the core diagnostics as
independent of the rest of the compiler as possible so that using it
doesn't bring undesired dependencies. It took some effort a few years
ago to clean-up headers, in particular, the mess of toplev.h, inclusion
of rtl in FE files, inclusion of tree.h in back-end files, etc. I'm not
sure what is the status now but I'm afraid that without any definition
of actual internal/external interfaces and without actual physical
separation of files and compilation steps (read: libraries), the headers
may have crept back in.
Thanks for the background. It makes sense to keep header
dependencies to a minimum. Here it seems like more than
that because adding calls to (for instance) tree_to_uhwi()
to diagnostic.c causes:
/src/gcc/svn/gcc/diagnostic.c:56: undefined reference to
`tree_to_uhwi(tree_node const*)'
collect2: error: ld returned 1 exit status
Makefile:2929: recipe for target 'gcov' failed
make[2]: *** [gcov] Error 1
I wanted to make the _n() functions like warning_n() more
robust by letting them accept a tree argument (as well as
offset_int and wide_int) in addition to HOST_WIDE_INT but
I can't do it if they can't work with these types.
Long time ago there was a plan of making GCC more modular, perhaps
moving to a library framework like LLVM/Clang. I even had a patch that
moved all core diagnostics and line-map stuff to its own libdiagnostic
that was used by libcpp and the rest of the compiler (instead of
overriding call-backs in libcpp like we do now and forcing libcpp into
every executable that wishes to use diagnostics or line-maps).
Unfortunately, it never worked properly because of the build machinery.
More background (probably very much outdated and forgotten):
https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4
https://gcc.gnu.org/wiki/rearch
https://gcc.gnu.org/wiki/ModularGCC
Yes, better/greater modularity would be useful.
Thanks again for the background.
Martin
