New macro expander preamble

[Zack Weinberg]

On Thu, Oct 26, 2000 at 04:55:46PM -0700, Zack Weinberg wrote:
> On Wed, Oct 25, 2000 at 11:18:49PM +0100, Neil Booth wrote:
> > My next few posts will be a large diff for a new macro expander.
> 
> More detailed commentary later.

Here it comes.  This is sort of stream of consciousness, bear with me.

I've fixed up the integrated preprocessor and will send a patch
tomorrow (bootstrap's still running).  It exposed some bugs.  Most of
them could be addressed by a follow-up patch.

There's a serious bug in skip_rest_of_line - it doesn't dump
lookahead.  This shows up with the integrated preprocessor,
pragma-[12].c:

#pragma unknown
  /* ... */

The 'unknown' is in the lookahead queue because of do_pragma.
cb_def_pragma in c-lex.c doesn't consume any tokens because
-Wunknown-pragmas is off.  skip_rest_of_line ignores the lookahead
queue, so the next time c_lex calls cpp_get_token, 'unknown' pops up
as if it had been part of the running text.  I've got this hacked
around in my tree by setting pfile->skipping and then calling
_cpp_get_token instead of _cpp_lex_token, in skip_rest_of_line, but
that may not be the right fix.

With the integrated preprocessor, c-torture/execute/920730-1t.c breaks
- -fpreprocessed is ignoring # 123 markers.  The simplest fix is to
add IN_I to the dtable entry for #line.

gcc.dg/cpp/2000720-1.S breaks with or without integrated cpp:
$ ./xgcc -B./ -E 20000720-1.S 
# 1 "20000720-1.S"



         nop call b

'nop' and 'call b' need to be on separate lines.  The bug appears to
be that lookahead doesn't remember that we've advanced to a new line.

There's still some debugging printfs (#if'd out) in the memory pool
code.  Either strip them or change them to #ifdef POOL_DEBUG or
something like that.

This sort of thing should get a trigraph warning:

/* blah *??/
/

I'm not sure this is enough to get a pointer "suitably aligned so that
it may be assigned to a pointer to any type of object and then used
to access such an object or an array of such objects in the space
allocated."  Might this be what's wrong with the sparc?

struct dummy
{
  char z;
  union
  {
    double d;
    int *p;
  } u;
};

#define DEFAULT_ALIGNMENT (offsetof (struct dummy, u))

In the directive table, you took out all the frequency counts and
information about which directives are extensions.  That may not be
important anymore, but it was still valuable information.  I'd like
them put back.

Really old K+R compilers don't know #elif.  GCC had to be adjusted not
to use it, a couple months back -

Thu Aug  3 10:05:53 2000  Akiko Matsushita <matusita@sra.co.jp>

        * gengenrtl.c, rtl.c: Avoid #elif.

Do we want to cause -Wtraditional to warn about it?  Do we want to
continue to support it in -traditional mode?

>From an old comment:

>  We currently do not support the _Pragma operator.  Support for that
>  has to be coordinated with the front end.  Proposed implementation:
>  both #pragma blah blah and _Pragma("blah blah") become
>  __builtin_pragma(blah blah) and we teach the parser about that.

Better idea: when we see _Pragma("blah blah"), we run the string
through a destringizer, then call run_directive(T_PRAGMA) on it.

Is the temp string pool ever flushed except at end of execution?

zw