https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- 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? > 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.
