This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: treelang fix for .info build, and add flag needed by c-common.c
- From: Tim Josling <tej at melbpc dot org dot au>
- To: Neil Booth <neil at daikokuya dot demon dot co dot uk>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 19 May 2002 14:25:44 +1000
- Subject: Re: treelang fix for .info build, and add flag needed by c-common.c
- Organization: Melbourne PC User Group
- References: <3CE6E29E.407C739E@melbpc.org.au> <20020518234015.GA18416@daikokuya.demon.co.uk>
Neil
You are quite right. It was only a matter of time before somebody noticed this.
However when I tried to execute that strategy (for two years now in my cobol front end) I found that I needed 5 times as much code in treetree.c, and the maintenance effort was far higher. So now my strategy is 'use c-common.c unless I want to do something different'. It is not elegant I know and I live in fear that someone will change c-common.c in such a way that I need to clone it.
In my view, this suggests that the back end interface needs some work to make it more language independent, more clean and perhaps to provide some higher level constructs (a good example of something that is too low level is structs and unions). However I have not thoroughly researched this point so at this stage it is just my opinion.
Maybe when the c-common.c exercise is completed and things stabilise it may be worth looking at this again.
Tim Josling
Neil Booth wrote:
> Tim Josling wrote:-
>
> > The info build error was pointed out by Magnus Fromreide. He supplied a patch but I made my own.
> >
> > c-common.c needs warn_format_zero_length so I addeed that to treetree.c
>
> Is it not better to remove your dependency on c-common.c? As we share
> more and more in the C front ends you're only going to be defining ever
> more abort functions.
>
> Neil.