[GCC-XML] Failure to handle __is_enum
ndbecker2 at gmail.com
Mon Dec 22 12:56:21 EST 2008
On Monday 22 December 2008, Brad King wrote:
> Neal Becker wrote:
> > I have the current gcc_xml cvs. It seems to choke on boost-1.37.0, where
> > we use __is_enum if gcc is 4.3.
> > Running on gccxml, it seems to identify itself as gcc4.3, but it doesn't
> > seem to understand __is_enum builtin.
> > What's the story here? I think gccxml is really gcc4.2, and doesn't
> > support this builtin? In that case, how do I run gccxml and tell it to
> > use the gcc4.2 config instead of gcc4.3?
> gccxml uses a 4.2 parser internally. It is non-trivial to update the
> internal version so I do it only every few versions.
> We simulate the preprocessing of the target compiler including its
> system headers so that any code generation done based on the xml output
> can compile with the target compiler. In order to handle non-standard
> code in native headers (including MSVC, Borland, and SGI) we copy them
> into a gccxml support directory and patch them. This approach has
> worked well for years but gcc 4.3's headers use *alot* of
> compiler-specific (4.3-only) extensions.
> gccxml distinguishes itself from the preprocessor of the target compiler
> by adding these definitions (documented in the man page):
> MM, mm, and pp are the major, minor, and patch versions of GCC-
> XML. This preprocessor symbol identifies GCC-XML to the source
> code as it is preprocessed. It can be used to enable GCC-XML-
> specific information.
> Defined to internal GCC parser major version.
> Defined to internal GCC parser minor version.
> Defined to internal GCC parser patchlevel.
> From boost's point of view gccxml is another compiler identified by the
> above macros. I know Boost.Config has some support for gccxml. The
> header in question needs to be updated to not use the builtin when the
> compiler is identified as gccxml. This is not the first time:
> For an immediate work-around you can install gcc 4.2 on your system and
> tell gccxml to simulate it with the option "--gccxml-compiler g++4.2".
Wouldn't a simpler workaround be to patch the header, as you suggest above?
More information about the gccxml