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 16 August 2016 at 14:10, Richard Biener <richard.guenther@gmail.com> wrote:
> 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.
>

I am working on the older revision of trunk. Do I need to do rebasing
before posting patches on the list?


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