Using C++ within a backend?

Using C++ within a backend?

[Alexandre Courbot]

Hi all,

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". This might not be a good idea for bootstrapping but is fine in my 
case anyway, since I only want a basic cross-compiler.

Problem is, g++ (3.2.3 here) doesn't seem to like gcc's include files. 
Whenever I include rtl.h for instance, I get:

../../gcc-3.2.2-camille/gcc/rtl.h:109: declaration of 
`rtx_def*rtunion_def::rtx
   '
config.h:8: changes meaning of `rtx' from `typedef struct rtx_def*rtx'
../../gcc-3.2.2-camille/gcc/rtl.h:110: declaration of `
   rtvec_def*rtunion_def::rtvec'
config.h:10: changes meaning of `rtvec' from `typedef struct rtvec_def*rtvec'

Effectively, line 109 of rtl.h is
  rtx rtx;

Which I understand cause problems to g++.

I've thought of working this around by writing C code when necessary and C++ 
when possible, but it would involves making messy wrappers. Another solution 
would be to say g++ to treat a part of the program as pure C, this I haven't 
found neither. Putting the includes within an extern "C" clause doesn't help, 
and the doc doesn't mention a command-line option that would make g++ more 
permissive with the code.

I'm also surprised I haven't found anything about this topic in the archives - 
I'd have bet this was a common question. Has somebody here messed up with C++ 
in the backend and could advice me? Is it possible to safely include gcc's 
include files from a C++ file?

Thanks for any advice!
Alex.

Re: Using C++ within a backend?

[Gabriel Dos Reis]

Alexandre Courbot <Alexandre.Courbot@lifl.fr> writes:

[...]

| Problem is, g++ (3.2.3 here) doesn't seem to like gcc's include files. 
| Whenever I include rtl.h for instance, I get:
| 
| ../../gcc-3.2.2-camille/gcc/rtl.h:109: declaration of 
| `rtx_def*rtunion_def::rtx
|    '
| config.h:8: changes meaning of `rtx' from `typedef struct rtx_def*rtx'
| ../../gcc-3.2.2-camille/gcc/rtl.h:110: declaration of `
|    rtvec_def*rtunion_def::rtvec'
| config.h:10: changes meaning of `rtvec' from `typedef struct rtvec_def*rtvec'
| 
| Effectively, line 109 of rtl.h is
|   rtx rtx;
| 
| Which I understand cause problems to g++.

It would be probably better if we could avoid such constructs in GCC
sources.  However, such a chaneg won't be practical for 3.2.3, 3.3.0.
Maybe a project for 3.4 or 3.5.

-- Gaby

Re: Using C++ within a backend?

[Matthieu Moy]

Alexandre Courbot <Alexandre.Courbot@lifl.fr> writes:

> Hi all,

Hi,

> 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 *. 

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 ... 

-- 
Matthieu

Re: Using C++ within a backend?

[Kevin Handy]

Matthieu Moy wrote:

>Alexandre Courbot <Alexandre.Courbot@lifl.fr> writes:
>
>  
>
>>Hi all,
>>    
>>
>
>Hi,
>
>  
>
>>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 *. 
>
>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 ... 
>

Might it be useful to make the entire gcc compiler compilable by
the C++ compiler in some future version?  i.e. make the C files
capable of being compiled using the C++ compiler, not converting
them to C++. This would require changing the K&R definitions
to inline ones, but since that appears to be in the plan anyway...

I'd think that being able to use different front ends to compile GCC
might help uncover latent bugs and ambigous constructs (since the C
and C++ front ends use different parsers, iirc).

Re: Using C++ within a backend?

[Mike Stump]

On Tuesday, April 15, 2003, at 02:52 PM, Kevin Handy wrote:
> Might it be useful to make the entire gcc compiler compilable by
> the C++ compiler in some future version?

I think so.  I don't think anyone would argue against the general idea.

Re: Using C++ within a backend?

[Alexandre Courbot]

> > 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.

[PATCH] Re: Using C++ within a backend?

[Matthieu Moy]

Alexandre Courbot <Alexandre.Courbot@lifl.fr> writes:

> 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. 

OK. I did the same for cp-tree.h. 

I should have done it before: it was rather trivial ! 

Usually, the file cp-tree.h is included as follows :

#include "config.h"
#include "system.h"
#include "tree.h"
#include "cp-tree.h"

There are 2 problems:

system.h includes the file <stdbool.h>, which tries to define the type
bool. 

#define-ing  the variable  __STDBOOL_H__ before  that does  the trick.
(Don't know how much portable this is ...)

The file cp-tree.h has a  structure member called "operator", which is
a keyword of C++. 

So, the  my solution is  to have the  following file, which  I include
instead of including cp-tree.h :

#ifndef __cplusplus

#ifdef GCC_BRANCH_IS_SSA

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "tm.h"
#include "tree.h"
#include "cp-tree.h"

#else // GCC_BRANCH_IS_SSA

#include "config.h"
#include "system.h"
#include "tree.h"
#include "cp-tree.h"

#endif // GCC_BRANCH_IS_SSA


#else // We are in C++

extern "C" {
#include "config.h"
#define __STDBOOL_H__
#include "system.h"
#include "tree.h"

#define operator cp_operator
#include "cp-tree.h"
#undef operator
}

#endif

#endif

For  now,  this is  an  awfull hack,  but  I  strongly recommand  that
something cleaner be applied to the main branch of GCC :

* Renaming   any    variable   whose    name   is   a    C++   keyword
  (s/operator/cp_operator/g for example)

* Apply the following patch to system.h :

--- system.h~	Wed May 22 01:44:39 2002
+++ system.h	Thu Apr 17 10:35:06 2003
@@ -543,6 +543,7 @@
 #undef TRUE
 #undef FALSE
 
+#ifndef __cplusplus
 #ifdef HAVE_STDBOOL_H
 # include <stdbool.h>
 #else
@@ -552,6 +553,7 @@
 # define bool _Bool
 # define true 1
 # define false 0
+#endif
 #endif
 
 #define TRUE true

-- 
Matthieu

Re: [PATCH] Re: Using C++ within a backend? (contd)

[Matthieu Moy]

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> OK. I did the same for cp-tree.h. 
>
> I should have done it before: it was rather trivial ! 

Hmm, not so much ;-)

Including  the file  tree.h from  a C++  file was  easy, but  using it
requires some more work, because  there are some uses of implicit cast
between enums (typically c_tree_code and tree_code).

The first thing to do is to allow comparison between them :

#ifdef __cplusplus
inline bool operator==(tree_code tc, c_tree_code ctc) {
  return (c_tree_code)tc == ctc;
}

inline bool operator==(c_tree_code ctc, tree_code tc) {
  return (c_tree_code)tc == ctc;
}

inline bool operator!=(tree_code tc, c_tree_code ctc) {
  return (c_tree_code)tc != ctc;
}

inline bool operator!=(c_tree_code ctc, tree_code tc) {
  return (c_tree_code)tc != ctc;
}
#endif

(Note that it  would probably be cleaner to add  the explicit casts in
the right places instead of defining new operators)

Then,  we have  to  add explicit  casts  when required.  For now,  the
following seems to be sufficient for me :

--- tree.h~	Mon Apr 14 19:59:14 2003
+++ tree.h	Fri Apr 18 11:04:03 2003
@@ -291,7 +291,7 @@
 #define TREE_CHECK(t, code) __extension__				\
 ({  const tree __t = (t);						\
     if (TREE_CODE(__t) != (code))					\
-      tree_check_failed (__t, code, __FILE__, __LINE__, __FUNCTION__);	\
+      tree_check_failed (__t, (tree_code)code, __FILE__, __LINE__, __FUNCTION__);	\
     __t; })
 #define TREE_CLASS_CHECK(t, class) __extension__			\
 ({  const tree __t = (t);						\

-- 
Matthieu