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