[Bug c/82817] C frontend errors on SSA name from REG_EXPR
rguenth at gcc dot gnu.org
Fri Nov 3 10:24:00 GMT 2017
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Thomas Preud'homme from comment #4)
> (In reply to firstname.lastname@example.org 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 ] )
> > > (mem/c:SI (reg/f:SI r3 ) [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.
More information about the Gcc-bugs