[Bug c/82817] C frontend errors on SSA name from REG_EXPR

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Thomas Preud'homme from comment #4)
> (In reply to rguenther@suse.de from comment #3)
> > On Fri, 3 Nov 2017, thopre01 at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817
> > > 
> > > --- Comment #2 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
> > > (In reply to Richard Biener from comment #1)
> > > > The GIMPLE FE also doesn't like that some variable names created by the
> > > > middle-end contain '.'.
> > > > 
> > > > I belive it would be good to "fix" create_tmp_var_name.  I suppose it
> > > > intentionally uses ASM_FORMAT_PRIVATE_NAME to avoid clashes with user
> > > > vars - but that should only be necessary for globals which should better
> > > > use a more "manual" way of creating the name.
> > > 
> > > That would work for this specific instance but as I said it's a more general
> > > problem. You can see at the end another such case:
> > > 
> > > expected character `[', found `)'
> > > 
> > > for this RTL:
> > > 
> > >       (cinsn 11 (set (reg:SI r3 [orig:111 c.1_2 ] [111])
> > >                     (mem/c:SI (reg/f:SI r3 [117]) [1 c+0 S4 A32]))
> > > "testcase.c":7)
> > 
> > But if you change c.1_2 to c_1_2 for example, does it work?
> 
> For the first error yes but I still get:
> 
> pr82817.c:12:56: error: expected character `[', found `)'
> pr82817.c:12:85: note: following context is ` [0  S4 A32])) "testcase.c":7'

No idea what it is complaining about though...  there isn't any mismatching
in braces, no?

> > 
> > > I don't see why the RTL body goes through the C tokenizer since we only seems
> > > to care about matching curly braces and detecting EOF which I'm sure a lower
> > > level function that deals with encoding and buffer management would do.
> > 
> > Because we're using the C parser to parse things like type and function
> > declarations.
> 
> Even *in* the body of the function? The comment on top of
> c_parser_parse_rtl_body says:
> 
>    The RTL parser works on the level of characters read from a
>    FILE *, whereas c_parser works at the level of tokens.
>    Square this circle by consuming all of the tokens up to and
>    including the closing brace, recording the start/end of the RTL
>    fragment, and reopening the file and re-reading the relevant
>    lines within the RTL parser.
> 
> That sounds to me that for anything after the opening curly braces we should
> avoid the tokenizer and when arriving to the closing curly braces set the
> parser to continue from there.

But we do lexing up-front so not sure if that works.