Forwarding to main group.  None of my posts to D.gnu come through.

> I think it would be increadibly difficult to write a GCC front end in C++.

Why?
The two interface rather well...

> Therefore I think we'll have to port the D front end to straight C first, while attemping to parallel Walter's overall object structure. Its unfortunate because it would be nice to have a non-divergent versions, but I don't think there is an easier way to do it.  Any thoughts?  (practical thoughts only please)

I would stay with the current D front end as it is and write a (small) layer
to do the interfacing.
I have understood from Walter that he has done stuff like that too to
interface newer idea's in newer code with the existing code generator, but I
could be wrong.

> 2. Create an overall framework/coupling for working with the GCC front end.  This serves two purposes.  First of all, to isolate us from the changing GCC front-end interface.  Second of all, the GCC front end stuff is ugly, we should be able to encapsulate it and produce something that allows us to manage it at a higher level so that we only have to get intimate with it once.  The rest of the time we'll work above it.

That's what I mean, write a conversion layer between the D front end and
GCC...
Rewriting what has been done and still is in development does not sound like
the greatest idea to me.

I have a gut feeling you are in way over your head.

Sean

"Andrew C. Oliver" <acoliver@apache.org> wrote in message news:3CFAAA3F.2020800@apache.org...
> Forwarding to main group.  None of my posts to D.gnu come through.

I agree,
And what happens when Walter makes a change... You may have to rewrite a big
chunk of it.

"Jan Knepper" <jan@smartsoft.cc> wrote in message news:3CFAC302.D8A04FBF@smartsoft.cc...
> > I think it would be increadibly difficult to write a GCC front end in C++.
>
> Why?
> The two interface rather well...
>
> > Therefore I think we'll have to port the D front end to straight C first, while attemping to parallel Walter's overall object structure. Its unfortunate because it would be nice to have a non-divergent versions, but I don't think there is an easier way to do it.  Any thoughts?  (practical thoughts only please)
>
> I would stay with the current D front end as it is and write a (small)
layer
> to do the interfacing.
> I have understood from Walter that he has done stuff like that too to
> interface newer idea's in newer code with the existing code generator, but
I
> could be wrong.
>
> > 2. Create an overall framework/coupling for working with the GCC front end.  This serves two purposes.  First of all, to isolate us from the changing GCC front-end interface.  Second of all, the GCC front end stuff is ugly, we should be able to encapsulate it and produce something that allows us to manage it at a higher level so that we only have to get intimate with it once.  The rest of the time we'll work above it.
>
> That's what I mean, write a conversion layer between the D front end and
> GCC...
> Rewriting what has been done and still is in development does not sound
like
> the greatest idea to me.
>
>
>

Jan Knepper wrote:
>>I think it would be increadibly difficult to write a GCC front end in
>>C++.
> 
> 
> Why?
> The two interface rather well...
> 

You do realize It'd be the *first* C++ written GCC front end right?  I'm not sure how to do it while fitting into GCC.

Take a quick gander at this: http://cobolforgcc.sourceforge.net/cobol_toc.html#TOC48 and the Toy or tree language.  See if you still feel like this.


> 
> I would stay with the current D front end as it is and write a (small) layer
> to do the interfacing.
> I have understood from Walter that he has done stuff like that too to
> interface newer idea's in newer code with the existing code generator, but I
> could be wrong.
> 
> 
>>2. Create an overall framework/coupling for working with the GCC front
>>end.  This serves two purposes.  First of all, to isolate us from the
>>changing GCC front-end interface.  Second of all, the GCC front end
>>stuff is ugly, we should be able to encapsulate it and produce something
>>that allows us to manage it at a higher level so that we only have to
>>get intimate with it once.  The rest of the time we'll work above it.
> 
> 
> That's what I mean, write a conversion layer between the D front end and
> GCC...
> Rewriting what has been done and still is in development does not sound like
> the greatest idea to me.
>

Humm.  Yes I don't like it, I just am not entirely sure how to do so otherwise.  I'll take another look.

-Andy

> 
> 

Hi,

"Andrew C. Oliver" <acoliver@apache.org> wrote in message news:3CFAAA3F.2020800@apache.org...
> Forwarding to main group.  None of my posts to D.gnu come through.
>
> I think it would be increadibly difficult to write a GCC front end in C++.  Therefore I think we'll have to port the D front end to straight C first, while attemping to parallel Walter's overall object structure. Its unfortunate because it would be nice to have a non-divergent versions, but I don't think there is an easier way to do it.  Any thoughts?  (practical thoughts only please)

I agree. The problem is that the code will depend on the C++ RTL which GCC probably does not link with. A solution to this is to put the C++ code into a shared library and include the C++ RTL in the shared library and resolve references to that internally. There might be problems initializing the C++ RTL, but that can be overcome. I have used this technique a couple of times. Its not without problems, though.

I would prefer a pure C solution, and in any case, we need a solution that does not use features specific to DMC. I have found:

- complex_t

- Hexadecimal notation of double literals supported by strtod()

- Use of strtof() and strtold(). Neither my Windows compiler or GCC have
them,
  and they are not part of x/Open specification either. If strtod() is used
in stead
  of strtold() precision is lost. I don't know it this can be solved.

- Use of contracts.

I don't know if there are others. If Walter's source, not the documentation, is to be authorative, it would be nice if it could be used as-is. This would allow the source to be easily updated.

I have a working lexer, and a partial bison grammar that has all statements
and expressions. I've stopped, temporarily anyway, for a number of reasons:
- The D specification is incomplete in the sense that it covers all language
constructs. For examle, BasicType and BasicType2 are not described.
- I ran into conflicts attempting to model the declarations by
reverse-engineering Walter's front-end. I may be my fault.
- I would like to consider the D specification authorative - not the
existing front-end. But I'm not sure if I can.

I prefer a bison solution over recursive descent because it allows grammar documentation to be extracted directly from the source. My approach is also a little different from Walter's regarding strings. I use wchar_t's everywhere internally.

Some problems I have identified are described below. Don't take me wrong. I think that Walter has been doing a great job, and I hope a list with even the smallet things described will help making it a better product.

In http://www.digitalmars.com/d/lex.html :

- "synchronized" not listed as keyword

- "===" and "!==" are not described as tokens.

- "asm", "delegate" are is not described as a keywords.

- "volatile" is described as a keyword. However, it is stated in
  "statement.html" that "D has no volatile storage type". I suspect
  that way to many keywords are reserved.

- Literal grammar uses 0b, not 0x, for hexadecimal literals.
  So this is wrong:
            Hexadecimal:
              0b HexDigits

- It is not specified that 0B and 0X are valid prefixes for literal
integers;
  Only 0b and 0X are described. Case does not matter in "lexer.c".

- It is stated:
        "Floats can be in decimal or hexadecimal notation, as in standard
C".
   Hexadecimal notation is not standard, is it? Is definitely is not
standard
   C++ (not described in ISO/IEC 14882). It expect this will cause
   some difficulty because the underlying C library does not support
   hexadecimal notation using strtod().

http://www.digitalmars.com/d/expression.html

    ShiftExpression:
      AddExpression
      AddExpression << AddExpression
      AddExpression >> AddExpression
      AddExpression <<< AddExpression
    The <<< operator is not defined by "lex.html", and "dmd" will not
compile it.
    It is probably a typo, and the operator should be >>>. The same problem
    exists with <<<= vs. >>>=.

    In the definition of the ShiftExpression above, AddExpression should be
    replaced with ShiftExpression on the left side of the operator (in a
Bison
    grammar)The same goes for other binary expression. If not, expressions
    like a+b+c will not compile.

    "ArgumentList" is not described.

    "NewExpression" is not described.

    The description of variable initialization is ambiguous. It says:
        IdentifierList:
          Variable
          Variable , IdentifierList
        Variable:
          Identifier
          Identifier = Expression
    "Expression" is a comma separated list of AssignmentExpression's, and it
    therefore conflicts with IdentifierList. So, Expression should be
    AssignmentExpression instead (like it is in C).

http://www.digitalmars.com/d/statement.html

    {} is both an EmptyStatement and a BlockStatement. EmptyStatement
    should not be in the grammar.

    Synchronize Statement uses the keyword "synchronize". However, the
    keyword is defined as "synchronized" (with a "d") in both "lexer.c" and
"lex.html".

    How about rethrowing exceptions? The ThrowStatement does not
    allow throw to be used without an expression:
        ThrowStatement:
          throw Expression ;

    The AsmStatement is described as:
        AsmStatement:
      { }
      { AsmInstructionList }
    It lacks the "asm" keyword.

In http://www.digitalmars.com/d/declaration.html :

- BasicType and BasicType2 are not described.

- Only const, static, final, synchronized, and deprecated are described
   as storage specifiers (or whatever it should be called). However,
   "parser.c" recognizes many more.

Could GCC simply be compiled with the g++ compiler, rather than gcc? That would then make it easy to interface D's C++ front end to GCC's C.

gcc can normally compile both C and C++ files.  g++ is just a frontend, that also adds the proper libraries during linking.  I'm not sure how it behaves during its own build process.  AFAIK, it compiles a gcc with just C support, using the platform's C compiler, then, using the generated gcc, it compiles itself again with optimizations activated for all the selected languages (not only C), and after that it compiles the standard libs for some of the languages using the compilers generated in the previous stage (number 2).

I think you can find links to detailed instructions on how adding a new frotend should be done at http://gcc.gnu.org/readings.html.  Good luck!

HTH,
  Laurentiu

"Walter" <walter@digitalmars.com> wrote in message news:adg4t2$1obg$2@digitaldaemon.com...
> Could GCC simply be compiled with the g++ compiler, rather than gcc? That would then make it easy to interface D's C++ front end to GCC's C.

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:adg4i1$1o2s$1@digitaldaemon.com...

> I would prefer a pure C solution, and in any case, we need a solution that does not use features specific to DMC. I have found:
>
> - complex_t

If this is what I think it is, then won't "typedef complex complex_t" work?

> - Hexadecimal notation of double literals supported by strtod()
>
> - Use of strtof() and strtold(). Neither my Windows compiler or GCC have
> them,
>   and they are not part of x/Open specification either. If strtod() is
used
> in stead
>   of strtold() precision is lost. I don't know it this can be solved.

The solution is obvious: write your own versions of these. =)

> - Use of contracts.

Since a bugless program should never ever produce contract violations, and since contracts don't have side-effects, I think you could just strip these away.

Or maybe write some macros to imitate DBC in pure C?

> In http://www.digitalmars.com/d/lex.html :
>
> - "synchronized" not listed as keyword

I remember some others weren't as well. Also, several listed there aren't actually keywords ("ascii").

> - Literal grammar uses 0b, not 0x, for hexadecimal literals.
>   So this is wrong:
>             Hexadecimal:
>               0b HexDigits

Just a mistype.


> - It is stated:
>         "Floats can be in decimal or hexadecimal notation, as in standard
> C".
>    Hexadecimal notation is not standard, is it? Is definitely is not
> standard
>    C++ (not described in ISO/IEC 14882). It expect this will cause
>    some difficulty because the underlying C library does not support
>    hexadecimal notation using strtod().

Yep, it's not standard. You'll have to write your own conversion utils for it to work.

>     How about rethrowing exceptions? The ThrowStatement does not
>     allow throw to be used without an expression:
>         ThrowStatement:
>           throw Expression ;

It doesn't in practice as well. You'll just have to throw the exception you've caught, I guess.

Walter wrote:
> Could GCC simply be compiled with the g++ compiler, rather than gcc? That
> would then make it easy to interface D's C++ front end to GCC's C.
> 
> 
> 
> 

Cost / benefit analysis --

Here are disadvantages:

1. We'd never get into the GCC standard distribution that way.  I'm not sure if we want that, but wider adoption for D would certainly result from default inclusion.

2. We'd forever be *out of sync* with the GCC folks.

3. The GCC folks would think us odd and probably not work very closely with us.

4. Supporting a divergent version of GCC might be a massive undertaking

5. I bet this would be a lot of work.

6. There are no C++ examples of GCC Front ends (or existing front ends written in C++ that I know of).  We'd be on our own.

Advantages:

1. Resist the effort of rewriting the D Front end in C
2. The D community is largely composed of C++ advocates who might be more likely to contribute with a C++ effort.

Anything I missed?

-Andy


I changed CC=gcc to CC=g++ then did make clean bootstrap this is what I got:
(the same thing works with gcc)
--------------

if [ x"" != x ]; then \
  g++ -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-3.0/libiberty/../include  -W -Wa
ll -Wtraditional -pedantic  ../../gcc-3.0/libiberty/argv.c -o pic/argv.o; \
else true; fi
g++ -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-3.0/libiberty/../include -W -Wall
 -Wtraditional -pedantic ../../gcc-3.0/libiberty/argv.c
../../gcc-3.0/libiberty/argv.c:90: `argv' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:91: `char ** dupargv' redeclared as different kin
d of symbol
../../gcc-3.0/libiberty/../include/libiberty.h:38: previous declaration of `char
 ** dupargv(char **)'
../../gcc-3.0/libiberty/argv.c:91: syntax error before `char'
../../gcc-3.0/libiberty/argv.c:96: parse error before `if'
../../gcc-3.0/libiberty/argv.c:100: `argc' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:100: syntax error before `!='
../../gcc-3.0/libiberty/argv.c:100: syntax error before `++'
../../gcc-3.0/libiberty/argv.c:101: warning: ANSI C++ forbids declaration `copy'
 with no type
../../gcc-3.0/libiberty/argv.c:101: conflicting types for `int copy'
../../gcc-3.0/libiberty/argv.c:94: previous declaration as `char ** copy'
../../gcc-3.0/libiberty/argv.c:101: `argc' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:102: parse error before `if'
../../gcc-3.0/libiberty/argv.c:106: `argc' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:106: syntax error before `!='
../../gcc-3.0/libiberty/argv.c:106: syntax error before `++'
../../gcc-3.0/libiberty/argv.c:109: `argc' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:109: warning: ANSI C++ forbids declaration `copy'
 with no type
../../gcc-3.0/libiberty/argv.c:109: `len' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:109: assignment (not initialization) in declarati
on
../../gcc-3.0/libiberty/argv.c:110: parse error before `if'
../../gcc-3.0/libiberty/argv.c:115: `argc' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:115: `argv' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:115: `argc' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:115: warning: ANSI C++ forbids declaration `strcp
y' with no type
../../gcc-3.0/libiberty/argv.c:115: `int strcpy' redeclared as different kind of
 symbol
/usr/include/string.h:33: previous declaration of `char * strcpy(char *, const c
har *)'
../../gcc-3.0/libiberty/argv.c:115: warning: initializer list being treated as c
ompound expression
../../gcc-3.0/libiberty/argv.c:116: parse error before `}'
../../gcc-3.0/libiberty/argv.c:117: `argc' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:117: warning: ANSI C++ forbids declaration `copy'
 with no type
../../gcc-3.0/libiberty/argv.c:117: assignment (not initialization) in declarati
on
../../gcc-3.0/libiberty/argv.c:118: parse error before `return'
../../gcc-3.0/libiberty/argv.c:144: `vector' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:145: variable or field `freeargv' declared void
../../gcc-3.0/libiberty/argv.c:145: `int freeargv' redeclared as different kind
of symbol
../../gcc-3.0/libiberty/../include/libiberty.h:33: previous declaration of `void
 freeargv(char **)'
../../gcc-3.0/libiberty/argv.c:145: syntax error before `char'
../../gcc-3.0/libiberty/argv.c:151: syntax error before `!='
../../gcc-3.0/libiberty/argv.c:151: syntax error before `++'
../../gcc-3.0/libiberty/argv.c:155: `vector' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:155: warning: ANSI C++ forbids declaration `free'
 with no type
../../gcc-3.0/libiberty/argv.c:155: `int free' redeclared as different kind of s
ymbol
/usr/include/stdlib.h:67: previous declaration of `void free(void *)'
../../gcc-3.0/libiberty/argv.c:156: parse error before `}'
../../gcc-3.0/libiberty/argv.c:206: `input' was not declared in this scope
../../gcc-3.0/libiberty/argv.c:207: `char ** buildargv' redeclared as different
kind of symbol
../../gcc-3.0/libiberty/../include/libiberty.h:29: previous declaration of `char
 ** buildargv(char *)'
../../gcc-3.0/libiberty/argv.c:207: syntax error before `char'
../../gcc-3.0/libiberty/argv.c:219: parse error before `if'
../../gcc-3.0/libiberty/argv.c:237: warning: ANSI C++ forbids declaration `nargv
' with no type
../../gcc-3.0/libiberty/argv.c:237: conflicting types for `int nargv'
../../gcc-3.0/libiberty/argv.c:217: previous declaration as `char ** nargv'
../../gcc-3.0/libiberty/argv.c:237: warning: initialization to `int' from `char
**' lacks a cast
../../gcc-3.0/libiberty/argv.c:238: parse error before `}'
../../gcc-3.0/libiberty/argv.c:242: warning: ANSI C++ forbids declaration `nargv
' with no type
../../gcc-3.0/libiberty/argv.c:242: redefinition of `int nargv'
../../gcc-3.0/libiberty/argv.c:237: `int nargv' previously defined here
../../gcc-3.0/libiberty/argv.c:242: warning: initialization to `int' from `char
**' lacks a cast
../../gcc-3.0/libiberty/argv.c:242: multiple initializations given for `nargv'
../../gcc-3.0/libiberty/argv.c:243: parse error before `}'
../../gcc-3.0/libiberty/argv.c:249: warning: ANSI C++ forbids declaration `argv'
 with no type
../../gcc-3.0/libiberty/argv.c:249: conflicting types for `int argv'
../../gcc-3.0/libiberty/argv.c:216: previous declaration as `char ** argv'
../../gcc-3.0/libiberty/argv.c:249: warning: converting NULL to non-pointer type

../../gcc-3.0/libiberty/argv.c:250: parse error before `}'
../../gcc-3.0/libiberty/argv.c:253: warning: ANSI C++ forbids declaration `argv'
 with no type
../../gcc-3.0/libiberty/argv.c:253: redefinition of `int argv'
../../gcc-3.0/libiberty/argv.c:249: `int argv' previously defined here
../../gcc-3.0/libiberty/argv.c:254: warning: ANSI C++ forbids declaration `argv'
 with no type
../../gcc-3.0/libiberty/argv.c:254: warning: ANSI C++ forbids variable-size arra
y `argv'
../../gcc-3.0/libiberty/argv.c:254: variable-size type declared outside of any f
unction
../../gcc-3.0/libiberty/argv.c:254: conflicting types for `int argv[2]'
../../gcc-3.0/libiberty/argv.c:253: previous declaration as `int argv'
../../gcc-3.0/libiberty/argv.c:254: invalid initializer
../../gcc-3.0/libiberty/argv.c:255: parse error before `}'
../../gcc-3.0/libiberty/argv.c:257: warning: ANSI C++ forbids declaration `arg'
with no type
../../gcc-3.0/libiberty/argv.c:257: warning: initialization to `int' from `char
*' lacks a cast
../../gcc-3.0/libiberty/argv.c:258: parse error before `while'
../../gcc-3.0/libiberty/argv.c:269: syntax error before `++'
../../gcc-3.0/libiberty/argv.c:312: syntax error before `++'
../../gcc-3.0/libiberty/argv.c:315: warning: ANSI C++ forbids declaration `arg'
with no type
../../gcc-3.0/libiberty/argv.c:315: conflicting types for `int * arg'
../../gcc-3.0/libiberty/argv.c:257: previous declaration as `int arg'
../../gcc-3.0/libiberty/argv.c:316: warning: ANSI C++ forbids declaration `argv'
 with no type
../../gcc-3.0/libiberty/argv.c:316: warning: ANSI C++ forbids variable-size arra
y `argv'
../../gcc-3.0/libiberty/argv.c:316: variable-size type declared outside of any f
unction
../../gcc-3.0/libiberty/argv.c:316: redefinition of `int argv[2]'
../../gcc-3.0/libiberty/argv.c:254: `int argv[2]' previously defined here
../../gcc-3.0/libiberty/argv.c:316: invalid initializer
../../gcc-3.0/libiberty/argv.c:317: parse error before `if'
../../gcc-3.0/libiberty/argv.c:320: warning: ANSI C++ forbids declaration `argv'
 with no type
../../gcc-3.0/libiberty/argv.c:320: conflicting types for `int argv'
../../gcc-3.0/libiberty/argv.c:316: previous declaration as `int argv[2]'
../../gcc-3.0/libiberty/argv.c:320: warning: converting NULL to non-pointer type

../../gcc-3.0/libiberty/argv.c:321: parse error before `break'
../../gcc-3.0/libiberty/argv.c:323: syntax error before `++'
../../gcc-3.0/libiberty/argv.c:324: warning: ANSI C++ forbids declaration `argv'
 with no type
../../gcc-3.0/libiberty/argv.c:324: warning: ANSI C++ forbids variable-size arra
y `argv'
../../gcc-3.0/libiberty/argv.c:324: variable-size type declared outside of any f
unction
../../gcc-3.0/libiberty/argv.c:324: conflicting types for `int argv[2]'
../../gcc-3.0/libiberty/argv.c:320: previous declaration as `int argv'
../../gcc-3.0/libiberty/argv.c:324: invalid initializer
../../gcc-3.0/libiberty/argv.c:326: parse error before `while'
../../gcc-3.0/libiberty/argv.c: In function `void __static_initialization_and_de
struction_0(int, int)':
cc1plus.exe: register name not specified for `((anonymous))'
../../gcc-3.0/libiberty/argv.c:242: Internal compiler error in `make_decl_rtl',
at varasm.c:739
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[1]: *** [argv.o] Error 1
make[1]: Leaving directory `/cygdrive/d/andy/homestuff/d/gcc-3.0-obj/libiberty'
make: *** [all-libiberty] Error 2