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

2016-08-11 Thread Richard Biener
On Thu, Aug 11, 2016 at 7:47 AM, Prasad Ghangal
 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.

>
> 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_

Re: Help with lra

2016-08-11 Thread shmeel gutl

On 10-Aug-16 08:41 PM, Vladimir N Makarov wrote:



On 08/09/2016 12:33 AM, shmeel gutl wrote:

On 03-Aug-16 12:10 AM, Vladimir Makarov wrote:

On 08/02/2016 04:41 PM, shmeel gutl wrote:
I am trying to enable lra for a propriety backend. I ran into one 
problem that I can't solve. In lra-constraints.c:split_reg 
lra_create_new_reg can be called with a hard code rclass of 
NO_REGS. It then queues a move instruction of the type


 set TYPE:new_reg  TYPE:old_reg

But the NO_REGS rclass stops new_reg from matching a register 
constraint and forces a reload. But the reload will have the same 
problem. This recurses until the recursion limit is hit.


What is my backend missing that will allow a register assignment to 
new_reg?
NO_REGS in this case means memory and the generated RTL move insn 
finally should be a target load or store insn.  It is hard to say 
w/o looking at the code but, probably, your move insn descriptions 
do not have memory constraints (or these constraints are quite 
specific).


Currently our memory constraints only match memory operands. I assume 
that you are suggesting that pseudo registers should match memory 
constraints. Is this true only for lra, or, would reload also benefit 
from such a change? Would other passes gain by such a change? Is any 
extra support needed in patterns or hooks?



Move insn descriptions are quit specific.  When you make a port it is 
better to have only one move insn for given mode (although there are 
some tricks to avoid this).  Therefore move insns have a lot of 
alternatives.  That is what I meant.


As for memory constraint you should not to return true for a pseudo.  
Reload/LRA can figure out how to match a spilled pseudo with memory 
(but this constraint should be define_memory_constraint, i saw 
mistakes when people used different forms of constraints for memory 
and had problems).


Again it is hard to say something definite w/o seeing the code what is 
the actual problem.
You hit it on the head with define_memory_constraint. Reload didn't seem 
to need it but LRA does.

Thank you,
Shmeel



gcc-6-20160811 is now available

2016-08-11 Thread gccadmin
Snapshot gcc-6-20160811 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160811/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 239396

You'll find:

 gcc-6-20160811.tar.bz2   Complete GCC

  MD5=b015ee142aa243ba806b835b414f23c0
  SHA1=f4dc215d12d1a411bd884410ae7c2e36191c92ca

Diffs from 6-20160804 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.