Re: Using C++ within a backend?

[Alexandre Courbot <Alexandre dot Courbot at lifl dot fr>]

> > Since  I need  to  use  the type-checking  system  designed for  the
> > architecture I'm porting  gcc to, I'll need to use  C++ code from my
> > backend (the library I have to link to is written in C++). I thought
> > this  might be  a  good idea  to write  as  much of  the backend  as
> > possible in C++, and define the needed functions as extern "C".
>
> I have  the same problem with  the file tree.h, which  I can't include
> from a C++ program, even with
>
> extern "C" {
> #include "..."
> }
>
> For now, I'm writting  most of my code in pure C,  and I have wrappers
> around C++ functions  written in C. When  I want to use a  tree from a
> C++ file, I just typedef it to be a void *.

I finally managed to get things to compile correctly. as you mentionned, every 
include of GCC files should be done within extern "C", otherwise you 
obviously get errors at link time.

The only gcc include file I had to change is rtl.h. I've created my own 
rtl-fix.h file in my backend directory and use this one instead of rtl.h. The 
only changes are line 109-110:

  rtx rtx;
  rtvec rtvec;

Changing them to

  rtx_def * rtx;
  rtvec_def * rtvec;

got me out of trouble. But is it normal? rtx and rtvec are already defined as 
typedefs, respectively of rtx_def * and rtvec_def *, so my change doesn't 
actually change anything to the program's meaning. Still, the error messages 
I got about these lines (see my initial post) seemed to mean something like 
the names "rtx" and "rtvec" are already reserved by the typedef, so you can't 
use them to declare class members. While I find it weird, this behavior 
perfectly suits me since I can go ahead, but maybe it's a bug too?

Other files that cause troubles are recog.h, expr.h, basic-block.h and ggc.h. 
I can be more verbose on what went wrong if you want. My backend can live 
without them, so I just don't use them at all anymore (don't even know why I 
included them - actually it's kinda hard to know which files depend on each 
other, so I ripped off the include lines from another backend. I have to 
admit that some more clarity regarding this point would have been welcome 
though).

tree.h issues some warnings like this one:
../../gcc-3.2.2-camille/gcc/tree.h:2215: warning: non-static const member `
   const char* const attribute_spec::name' in class without a constructor

but it doesn't alter the compilation itself. All the other files I've included 
(can give the list if you wish) went through quietly.

There is *only* one part that required a C file, because some of the above 
mentioned files were needed: it's the declaration and initialisation of 
targetm. So my target.c now only does this job. All the rest has been moved 
to another C++ file, with the interface used by the rest of the compiler 
(i.e. all the functions I call and variables used in target.h and target.md) 
declared as extern "C".

> But in the long run, I think that GCC's header files should compile in
> C++  :  That would  be  simpler  for code  reuse  and  linking to  C++
> libraries,  and anyway, most  of the  time, when  a C  program doesn't
> compile in C++, this is because it's too dirty ...

Everybody seems to agree on this point. I do think too that having the whole 
compiler compiling in C++ as well as in C would mean the code is clearer. Not 
that it isn't clear yet - when you overcome your fear of diving into such a 
big project's code you realize that the code is well commented and quite 
straightforward to follow, and the doc is very clear on which file do what. 
But it would probably be clearer in the way that C++ is more strict than C - 
which has the implicit consequence to leave less room for bugs.

Having the headers parseable by a C++ compiler would be great too. It would 
make backend writing much more comfortable by allowing the use of C++. I'm 
pretty sure being able to write C++ now will greatly improve my efficiency at 
designing and writing my backend. Moreover, in some weird cases you need to 
use C++ libraries in the backend, this would make this thing much easier. If 
this point could be considered for 3.4, that would just be *great*!

Thanks for the replies!
Alex.