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

[thopre01 at gcc dot gnu.org]

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

--- Comment #6 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> (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?

There isn't 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.

As you can see I'm not familiar with the C parser. I thought there'd be helper
function to do the IO and buffering and then the lexer would be called on the
buffer. I thought the call to _cpp_get_fresh_line in _cpp_lex_direct followed
by the switch case indicated such a design.

In that case looking to make the RTL C lexer friendly is probably the pragmatic
solution.