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