On 11 August 2016 at 15:58, Richard Biener <richard.guent...@gmail.com> wrote:
> On Thu, Aug 11, 2016 at 7:47 AM, Prasad Ghangal
> <prasad.ghan...@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

Thanks,
Prasad
>>
>> On 9 August 2016 at 14:37, Richard Biener <richard.guent...@gmail.com> wrote:
>>> On Sun, Aug 7, 2016 at 3:19 PM, Prasad Ghangal <prasad.ghan...@gmail.com> 
>>> wrote:
>>>> On 4 August 2016 at 18:29, Richard Biener <richard.guent...@gmail.com> 
>>>> wrote:
>>>>> On Thu, Aug 4, 2016 at 1:31 PM, Prasad Ghangal <prasad.ghan...@gmail.com> 
>>>>> wrote:
>>>>>> On 2 August 2016 at 14:29, Richard Biener <richard.guent...@gmail.com> 
>>>>>> wrote:
>>>>>>> On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal 
>>>>>>> <prasad.ghan...@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

Reply via email to