This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression


On Mon, Aug 15, 2016 at 8:59 PM, Prasad Ghangal
<prasad.ghangal@gmail.com> wrote:
> On 11 August 2016 at 15:58, Richard Biener <richard.guenther@gmail.com> wrote:
>> 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.
>>
> I have updated the patch and committed along with testcases

That's great - note that it's now time to wrap up and prepare a formal
submission of the
work you have done.  I'd like to see patch(es) generated from the git
repo and submitted
to gcc-patches together with appropriate ChangeLog entries.  I'd also
like to see an
overall summary of achievements refering to your timeline proposal and
I'd like to know
TODOs that you stumbled over.

When you prepare patches that's also a good time to review those yourself for
formatting, missing comments and trivial improvements to clarity that
can be still made.

What I've seen sofar the project is in a usable prototype stage!

Thanks,
Richard.

> Thanks,
> Prasad
>>>
>>> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]