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;
}
On 9 August 2016 at 14:37, Richard Biener wrote:
> On Sun, Aug 7, 2016 at 3:19 PM, Prasad Ghangal
> wrote:
>> On 4 August 2016 at 18:29, Richard Biener wrote:
>>> On Thu, Aug 4, 2016 at 1:31 PM, Prasad Ghangal
>>> wrote:
On 2 August 2016 at 14:29, Richard Biener
wrote:
> On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal
> 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)
> type size
> unit size
> align 32 symtab 0 alias set -1 canonical type 0x7688b7e0
> precision 32 min max
>
> pointer_to_this >
>
> arg 0 0x7688b7e0 int>
>
> arg 1 0x7688b7e0 int>
> used SI file t.c line 3 col 7 size 0x76887ee8 32> unit size
> align 32 context >>
> arg 1 0x7688b7e0 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 == 0x76997938
> 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 0x011821b7 in build2_stat (
> code=C_MAYBE_CONST_EXPR, tt=,
> arg0=, arg1=)
> at /space/rguenther/src/gcc_gimple_fe/gcc/tree.c:4466
> 0x0081d263 in c_wrap_maybe_const (expr= 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 *) 0x76997938
> (gdb) up
> #1 0x007b8e81 in build_binary_op (location=176833, code=EQ_EXPR,
> orig_op0=,
> orig_op1=, 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 i
