[patch] new exec-charset testcase

[Alexandre Oliva]

http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01330.html

Back in April 21, 2004, Mark Mitchell wrote:

Here are two alternative solutions to the problem.  I don't quite like
the idea of making the lexer even more context sensitive than it is,
especially given that the parser already knows exactly what's going
on.  Consider, for example:

  asm ("foo" : "=x" (({ int i; asm ("bar" : "=r" (i) : "r" ("bar"));
                        i; })));

you get to keep track of multiple separate asm statements, in a
stack.  This is not a lexer any more.  It's parser stuff.


My first attempt was to try to get both versions of strings saved when
parsing tentatively, and arranging for all locations that used host
strings to get to them properly.  This was a neat trick, but it
enabled me to see something else:

the *only* case in which we parse strings tentatively is while
scanning for the closing parenthesis when tentatively parsing a cast
expression.

However, in a case like this:

  foo = ( (whatever long sequence of tokens forming an expression) );

when we see the first `(', we still scan and save the entire
`(whatever...))' token stream tentatively.  Even though it's pretty
obvious upfront that `(whatever)' can't possibly be a type name.

The solution I liked better was to attempt to parse a type name
upfront.  Then, in the case of a compound literal, we backtrack like
we did before.  The advantage is that now we will no longer scan the
complete expression within parentheses to only then try to tell
whether it begins with a type name.  I *think* this should pay off the
disadvantage of having to parse the type name twice in compound
literal expressions, since parentheses are far more common in
expressions than type casts, that are far more common than compound
literals.

So the second patch below is the one I'm submitting for review.  The
former, probably incomplete, is only for the record.  Ok to install
the latter?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: lex-string-exec-and-host.patch
Type: text/x-patch
Size: 6410 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20040603/828ad47b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cp-parse-cast-dont-scan-parens.patch
Type: text/x-patch
Size: 3242 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20040603/828ad47b/attachment-0001.bin>
-------------- next part --------------

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}