This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression
On Thu, Aug 11, 2016 at 7:47 AM, Prasad Ghangal
<prasad.ghangal@gmail.com> wrote:
> In this patch I am trying to parse gimple call. But I am getting weird
> gimple dump for that.
>
> for this testcase:
> int __GIMPLE() bar()
> {
> int a;
> a = a + 1;
> return a;
> }
>
> void __GIMPLE() foo()
> {
> int b;
> b = bar();
> }
>
> I am getting ssa dump as:
>
> /* Function bar (bar, funcdef_no=0, decl_uid=1744, cgraph_uid=0,
> symbol_order=0)*/
>
> int
> bar ()
> {
> struct FRAME.bar FRAME.0;
> int a;
> void * D_1754;
> void * _3;
>
> bb_2:
> _3 = __builtin_dwarf_cfa (0);
> FRAME.0.FRAME_BASE.PARENT = _3;
> a_6 = a_5(D) + 1;
> return a_6;
>
> }
>
>
>
> /* Function foo (foo, funcdef_no=1, decl_uid=1747, cgraph_uid=1,
> symbol_order=1)*/
>
> void
> foo ()
> {
> int b;
>
> bb_2:
> b_3 = bar ();
> return;
>
> }
>
Somehow foo is treated as nested in bar. Note this even happens
without calls if you
have two functions in the testcase. Usually this means after
finishing parsing of a function
you fail to reset. Looks like the following fixes it:
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 95615bc..b35eada 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -2164,6 +2165,8 @@ c_parser_declaration_or_fndef (c_parser *parser, bool fnde
f_ok,
c_parser_parse_gimple_body (parser);
in_late_binary_op = saved;
cgraph_node::finalize_function (current_function_decl, false);
+ set_cfun (NULL);
+ current_function_decl = NULL;
timevar_pop (tv);
return;
}
Richard.
>
> On 9 August 2016 at 14:37, Richard Biener <richard.guenther@gmail.com> wrote:
>> On Sun, Aug 7, 2016 at 3:19 PM, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
>>> On 4 August 2016 at 18:29, Richard Biener <richard.guenther@gmail.com> wrote:
>>>> On Thu, Aug 4, 2016 at 1:31 PM, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
>>>>> On 2 August 2016 at 14:29, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>>> On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am trying to replace c_parser_paren_condition (parser) in
>>>>>>> c_parser_gimple_if_stmt by c_parser_gimple_paren_condition (parser) as
>>>>>>> described in the patch
>>>>>>>
>>>>>>> I am trying test case
>>>>>>> void __GIMPLE () foo ()
>>>>>>> {
>>>>>>> int a;
>>>>>>> bb_2:
>>>>>>> if (a == 2)
>>>>>>> goto bb_3;
>>>>>>> else
>>>>>>> goto bb_4;
>>>>>>> bb_3:
>>>>>>> a_2 = 4;
>>>>>>> bb_4:
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> but it fails to parse gimple expression and produces error as
>>>>>>> /home/prasad/test3.c: In function ‘foo’:
>>>>>>> /home/prasad/test3.c:1:18: error: invalid operands in gimple comparison
>>>>>>> void __GIMPLE () foo ()
>>>>>>> ^~~
>>>>>>> if (<<< Unknown tree: c_maybe_const_expr
>>>>>>>
>>>>>>> a >>> == 2) goto bb_3; else goto bb_4;
>>>>>>> /home/prasad/test3.c:1:18: internal compiler error: verify_gimple failed
>>>>>>>
>>>>>>> I failed to debug where it is setting to C_MAYBE_CONST_EXPR
>>>>>>
>>>>>> It's in parsing the binary expression. Btw, you don't need lvalue_to_rvalue
>>>>>> conversion or truthvalue conversion - source that would require this would
>>>>>> not be valid GIMPLE. Let me try to debug:
>>>>>>
>>>>>>
>>>>>> (gdb) p debug_tree (cond.value)
>>>>>> <eq_expr 0x7ffff6997960
>>>>>> type <integer_type 0x7ffff688b7e0 int public SI
>>>>>> size <integer_cst 0x7ffff6887ee8 constant 32>
>>>>>> unit size <integer_cst 0x7ffff6887f00 constant 4>
>>>>>> align 32 symtab 0 alias set -1 canonical type 0x7ffff688b7e0
>>>>>> precision 32 min <integer_cst 0x7ffff6887ea0 -2147483648> max
>>>>>> <integer_cst 0x7ffff6887eb8 2147483647>
>>>>>> pointer_to_this <pointer_type 0x7ffff68a5930>>
>>>>>>
>>>>>> arg 0 <c_maybe_const_expr 0x7ffff6997938 type <integer_type
>>>>>> 0x7ffff688b7e0 int>
>>>>>>
>>>>>> arg 1 <var_decl 0x7ffff7fefcf0 a type <integer_type 0x7ffff688b7e0 int>
>>>>>> used SI file t.c line 3 col 7 size <integer_cst
>>>>>> 0x7ffff6887ee8 32> unit size <integer_cst 0x7ffff6887f00 4>
>>>>>> align 32 context <function_decl 0x7ffff699c500 foo>>>
>>>>>> arg 1 <integer_cst 0x7ffff68a4318 type <integer_type
>>>>>> 0x7ffff688b7e0 int> constant 2>
>>>>>> t.c:5:9 start: t.c:5:7 finish: t.c:5:12>
>>>>>> $5 = void
>>>>>> (gdb) b ggc-page.c:1444 if result == 0x7ffff6997938
>>>>>> Breakpoint 6 at 0x8a0d3e: file
>>>>>> /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c, line 1444.
>>>>>> (gdb) run
>>>>>>
>>>>>> Breakpoint 6, ggc_internal_alloc (size=40, f=0x0, s=0, n=1)
>>>>>> at /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c:1444
>>>>>> 1444 return result;
>>>>>> (gdb) fin (a few times)
>>>>>> Run till exit from #0 0x00000000011821b7 in build2_stat (
>>>>>> code=C_MAYBE_CONST_EXPR, tt=<integer_type 0x7ffff688b7e0 int>,
>>>>>> arg0=<tree 0x0>, arg1=<var_decl 0x7ffff7fefcf0 a>)
>>>>>> at /space/rguenther/src/gcc_gimple_fe/gcc/tree.c:4466
>>>>>> 0x000000000081d263 in c_wrap_maybe_const (expr=<var_decl 0x7ffff7fefcf0 a>,
>>>>>> non_const=false)
>>>>>> at /space/rguenther/src/gcc_gimple_fe/gcc/c-family/c-common.c:4359
>>>>>> 4359 expr = build2 (C_MAYBE_CONST_EXPR, TREE_TYPE (expr), NULL, expr);
>>>>>> Value returned is $11 = (tree_node *) 0x7ffff6997938
>>>>>> (gdb) up
>>>>>> #1 0x00000000007b8e81 in build_binary_op (location=176833, code=EQ_EXPR,
>>>>>> orig_op0=<var_decl 0x7ffff7fefcf0 a>,
>>>>>> orig_op1=<integer_cst 0x7ffff68a4318>, convert_p=1)
>>>>>> at /space/rguenther/src/gcc_gimple_fe/gcc/c/c-typeck.c:11549
>>>>>> 11549 op0 = c_wrap_maybe_const (op0, !op0_maybe_const);
>>>>>>
>>>>>> and this is guarded by !in_late_binary_op (which also seems to guard folding).
>>>>>> So I suggest to somewhere at the start of parsing to set in_late_binary_op to
>>>>>> true for -fgimple. Not sure if it works for everything, but you
>>>>>> should have accumulated
>>>>>> quite some tests for -fgimple in the testsuite to make sure it doesn't
>>>>>> regress anything.
>>>>>>
>>>>> I did bootstrap build for the trunk and testing is in progress. How
>>>>> can I test with -fgimple flag enabled?
>>>>
>>>> You can do
>>>>
>>>> make check-gcc RUNTESTFLAGS="--target_board=unix/-fgimple"
>>>>
>>>> Richard.
>>>>
>>> I was comparing result from latest commit and "gcc initial version". I
>>> found most of the testcases failed due to modified gimple dump.
>>
>> Good, that's expected. Can you wrap up as for how is the status on
>> the project schedule? As said, adding more testcases would be good
>> for the SSA parsing feature. A big part missing is now is parsing of
>> function calls?
>>
>> Thanks,
>> Richard.
>>
>>>
>>> Thanks,
>>> Prasad
>>>
>>>>>
>>>>> Thanks,
>>>>> Prasad
>>>>>> The following works for me:
>>>>>>
>>>>>> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
>>>>>> index 70800a2..c8c087a 100644
>>>>>> --- a/gcc/c/c-parser.c
>>>>>> +++ b/gcc/c/c-parser.c
>>>>>> @@ -2158,7 +2159,10 @@ c_parser_declaration_or_fndef (c_parser
>>>>>> *parser, bool fndef_ok,
>>>>>>
>>>>>> if (gimple_body_p && flag_gimple)
>>>>>> {
>>>>>> + bool saved = in_late_binary_op;
>>>>>> + in_late_binary_op = true;
>>>>>> c_parser_parse_gimple_body (parser);
>>>>>> + in_late_binary_op = saved;
>>>>>> cgraph_node::finalize_function (current_function_decl, false);
>>>>>> timevar_pop (tv);
>>>>>> return;
>>>>>>
>>>>>>
>>>>>> Richard.
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Prasad