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

thopre01 at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Nov 3 09:57:00 GMT 2017


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

--- Comment #4 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
(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'

> 
> > 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.


More information about the Gcc-bugs mailing list