Adding to G++: Adding a warning on throwing unspecified exceptions.

Brian Dessent
Mon Sep 22 13:34:00 GMT 2008

Simon Hill wrote:

> (Of course I was
> horrified to see it's not written in C++, and it's loaded with macros
> --- why??).

You seem to refer to g++ as if it's a separate program from gcc but it's
really not.  All of the middle- and back-end code is shared between the
language front-ends, so if you introduce C++ there you now require a
pre-existing C++ bootstrap compiler even for people that have no
interest or need for C++ language support and are only building a C (or
Fortran or Java or Ada) compiler.  A lot of people have a problem with
that because some systems may not have or even want anything more than a
C compiler.

You could of course limit use of C++ to the C++ frontend, similar to how
the Ada frontend is written in Ada.  But I don't think that would do
much to alleviate the issue that you're complaining about because it
would still have to use all the same macros to represent trees and types
and so on to the language independent parts of the compiler.

Nevertheless it's a topic that keeps coming up and there are a number of
people that would like the advantages of better compile time type
checking and so on.  This debate always rages on because there is
constant fear that it will open the door for the more exotic and
unmaintainable C++ features to sneak in, in addition to the higher
bootstrap requirements.  At the moment there is slow progress in getting
things to the point where gcc can at least be built with a C++
compiler.  See also the gcc-in-cxx branch.

> What I'd like to add is something that I've seen many people request,
> and something I really want to use:
> Adding a -W option to check that all function calls and throws comply
> with the throw() clause of the function they are launched from.

You really ought to read the past threads on this topic, for example:


The general consensus is that doing this at compile time cannot give you
anything useful, because the compiler can only see one compilation unit
at a time and so the only thing it can know of all the downstream
functions that are in other CUs is what is provided in the exception
specifiers of the prototypes.  You're essentially trusting that all
exception specifiers for every function in the program and *all* library
code are always present and always correct which is a huge leap of faith
that I don't think is supported by reality.  For example the Boost
rationale basically says they are unusable in practical code except in
special cases:

> 1) Is my task a sensible one? Is there anything I have got fundamentally wrong?
> 2) Is there anyone currently doing this? I'd hate to simply duplicate
> their effort.

You should certainly look at EDoc++, mentioned in the above threads.

> I can't find much readable documentation about the source. Does anyone
> have any good documentation links about the overall program flow
> through g++, files/functions etc? I need a primer.

Don't neglect the wiki: <>

> 7) To someone new to the g++ source the included documentation seems
> pretty poor and cryptic. README mentions non-existant files,
> INSTALL/README says it's obsolete and redirects to a file "index.html"
> which doesn't yet exist. And why does the documentation have all these
> .texi, .info and (unlinked) manpage .1/.7 files. What's wrong with
> .txt, .html or similar? Shouldn't documentation be available from the
> download instead of having to go online to actually find out how to
> build and read the documentation itself - the documentation doesn't
> really take up much space. In this age do manpages actually have any
> advantages?

The documentation's canonical form is texinfo, i.e. gcc/doc/*.texi. 
Everything else (HTML, PDF, DVI, .info, manpages) is auto-generated from
the texinfo, e.g. "make html", "make pdf", etc.  Whether the generated
files are in your tree depends on whether you're working from a SVN
checkout or a release tarball, but the texinfo sources are always there.


More information about the Gcc mailing list