[prev in list] [next in list] [prev in thread] [next in thread]
List: gcc
Subject: Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression
From: Richard Biener <richard.guenther () gmail ! com>
Date: 2016-08-19 9:26:35
Message-ID: CAFiYyc1F9+Wr942jrTP-3PQmZwWederN4G25wNO1-utOQ72USg () mail ! gmail ! com
[Download RAW message or body]
On Fri, Aug 19, 2016 at 10:00 AM, Prasad Ghangal
<prasad.ghangal@gmail.com> wrote:
> 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?
That would be nice indeed.
Thanks,
Richard.
>
> 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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic