[Bug c/82817] C frontend errors on SSA name from REG_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 --- Comment #6 from Thomas Preud'homme --- (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 --- > > > > (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.
[Bug c/82817] C frontend errors on SSA name from REG_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 --- Comment #5 from Richard Biener --- (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 --- > > > (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? > > > > > 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.
[Bug c/82817] C frontend errors on SSA name from REG_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 --- Comment #4 from Thomas Preud'homme --- (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 --- > > (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.
[Bug c/82817] C frontend errors on SSA name from REG_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 --- Comment #3 from 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 --- > (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.
[Bug c/82817] C frontend errors on SSA name from REG_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 --- Comment #2 from Thomas Preud'homme --- (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) 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.
[Bug c/82817] C frontend errors on SSA name from REG_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82817 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-03 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- 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.
