Re: Problem with operand handling

Re: Problem with operand handling

[Richard Kenner]

    what is 'decorator_traceback'? 

I've got to run and will be back on this afternoon, but I'll put
the .t18.ssa file below.  It's small enough.

    Did you call mark_call_clobbered() on decorator_traceback?  If so, why
    if it passes all the tests in is_gimple_reg..  ie, its not volatile,
    its address is not taken, and its not global...

A quick GDB session shows that it is called for that variable, from
add_may_alias.


;; Function GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER (gnat__exception_traces__decorator_wrapper)

GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER (traceback, len)
{
  system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] & decorator_traceback;
  typedef system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615 gnat__exception_traces__decorator_wrapper__Tdecorator_tracebackS[T.5];
  typedef <unnamed type> struct <unnamed type>;
  typedef gnat__exception_traces__decorator_wrapper__TTdecorator_tracebackSP1___XDL_1 gnat__exception_traces__decorator_wrapper__TTdecorator_tracebackSP1___XDL_1;
  natural___XDLU_0__2147483647 gnat__exception_traces__decorator_wrapper__TTdecorator_tracebackSP1___U;
  struct string___XUP T.11;
  system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[(long int) <PLACEHOLDER_EXPR struct ada__exceptions__traceback__tracebacks_array___XUP>.P_BOUNDS->LB0 .. (long int) <PLACEHOLDER_EXPR struct ada__exceptions__traceback__tracebacks_array___XUP>.P_BOUNDS->UB0] * decorator_traceback.10;
  struct ada__exceptions__traceback__tracebacks_array___XUB T.9;
  struct ada__exceptions__traceback__tracebacks_array___XUP T.8;
  struct string___XUP (*gnat__exception_traces__traceback_decorator) (struct ada__exceptions__traceback__tracebacks_array___XUP) gnat__exception_traces__current_decorator.7;
  struct string___XUP T.6;
  long int T.5;
  bit_size_type T.4;
  bit_size_type T.3;
  long int T.2;
  long int T.1;
  integer len.0;

<bb 0>:
  gnat__exception_traces__decorator_wrapper__TTdecorator_tracebackSP1___U_2 = len_1;
  len.0_3 = (integer) len_1;
  len.0_4 = (integer) len_1;
  T.1_5 = (long int) len.0_4;
  T.2_6 = MAX_EXPR <T.1_5, 0>;
  len.0_7 = (integer) len_1;
  T.1_8 = (long int) len.0_7;
  T.2_9 = MAX_EXPR <T.1_8, 0>;
  T.3_10 = (bit_size_type) T.2_9;
  T.4_11 = T.3_10 * 64;
  len.0_12 = (integer) len_1;
  T.1_13 = (long int) len.0_12;
  T.2_14 = MAX_EXPR <T.1_13, 0>;
  T.5_15 = T.2_14 * 8;
  decorator_traceback_17 = (system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] &) traceback_16;
  gnat__exception_traces__current_decorator.7_19 = gnat__exception_traces__current_decorator;
  len.0_20 = (integer) len_1;
  T.9.LB0 = 1;
  T.9.UB0 = len.0_20;
  decorator_traceback.10_24 = (system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[(long int) <PLACEHOLDER_EXPR struct ada__exceptions__traceback__tracebacks_array___XUP>.P_BOUNDS->LB0 .. (long int) <PLACEHOLDER_EXPR struct ada__exceptions__traceback__tracebacks_array___XUP>.P_BOUNDS->UB0] *) decorator_traceback_17;
  T.8.P_ARRAY = decorator_traceback.10_24;
  T.8.P_BOUNDS = &T.9;
  T.11 = gnat__exception_traces__current_decorator.7_19 (T.8);
  T.6 = T.11;
  return T.6;

}

Re: Problem with operand handling

[Diego Novillo]

On Tue, 2004-09-07 at 10:02, Richard Kenner wrote:

> GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER (traceback, len)
> {
>   system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] & decorator_traceback;
>
What does this declaration mean?  Is decorator_traceback

>   decorator_traceback_17 = (system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] &) traceback_16;
>
According to this, decorator_traceback is a GIMPLE register.  It seems
to be a pointer of some kind?  I can't parse the original declaration. 
You'll have to figure out why we first think that decorator_traceback is
a gimple reg, and then we think otherwise.

This may help.  Put this test in add_may_alias:

if (is_gimple_reg (var) || is_gimple_reg (alias))
  abort ();


Diego.

Re: Problem with operand handling

[Andrew MacLeod]

On Tue, 2004-09-07 at 10:41, Diego Novillo wrote:
> On Tue, 2004-09-07 at 10:02, Richard Kenner wrote:
> 
> > GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER (traceback, len)
> > {
> >   system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] & decorator_traceback;
> >
> What does this declaration mean?  Is decorator_traceback
> 
> >   decorator_traceback_17 = (system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] &) traceback_16;
> >
> According to this, decorator_traceback is a GIMPLE register.  It seems
> to be a pointer of some kind?  I can't parse the original declaration. 
> You'll have to figure out why we first think that decorator_traceback is
> a gimple reg, and then we think otherwise.
> 
> This may help.  Put this test in add_may_alias:
> 
> if (is_gimple_reg (var) || is_gimple_reg (alias))
>   abort ();
> 

This should probably be added permanently under ENABLE_CHECKING....

Andrew

Re:

[Nathan Sidwell]

   wrote:
> On Tue, 2004-09-07 at 10:41, Diego Novillo wrote:
> 
>>On Tue, 2004-09-07 at 10:02, Richard Kenner wrote:
>>
>>
>>>GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER (traceback, len)
>>>{
>>>  system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] & decorator_traceback;
>>>
>>
>>What does this declaration mean?  Is decorator_traceback
>>
>>
>>>  decorator_traceback_17 = (system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] &) traceback_16;
>>>
>>
>>According to this, decorator_traceback is a GIMPLE register.  It seems
>>to be a pointer of some kind?  I can't parse the original declaration. 
>>You'll have to figure out why we first think that decorator_traceback is
>>a gimple reg, and then we think otherwise.
>>
>>This may help.  Put this test in add_may_alias:
>>
>>if (is_gimple_reg (var) || is_gimple_reg (alias))
>>  abort ();
>>
> 
> 
> This should probably be added permanently under ENABLE_CHECKING....
spelt
	gcc_assert (!is_gimple_reg (var) && !is_gimple_reg (alias));

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: Re:

[Andrew MacLeod]

On Tue, 2004-09-07 at 11:45, Nathan Sidwell wrote:

> >>if (is_gimple_reg (var) || is_gimple_reg (alias))
> >>  abort ();
> >>
> > 
> > 
> > This should probably be added permanently under ENABLE_CHECKING....
> spelt
> 	gcc_assert (!is_gimple_reg (var) && !is_gimple_reg (alias));


of course :-)

Its so hard to remember to change to modern ways :-)

Andrew

Re: Problem with operand handling

[Richard Kenner]

    I think he was looking for the traceback froim this abort() so we can
    see where the real operand is incorrectly being added to the alias
    list...

Sorry.  This was a small enough test case that I already was able to set
a breakpoint there.

It's from compute_flow_insensitive_aliasing.  But I see something
interesting.  This is in addressable_vars and TREE_ADDRESSABLE isn't
set.  That's wrong, isn't it?

Re: Problem with operand handling

[Richard Henderson]

On Tue, Sep 07, 2004 at 05:38:43PM -0400, Richard Kenner wrote:
> This is in addressable_vars and TREE_ADDRESSABLE isn't
> set.  That's wrong, isn't it?

Yes, and is exactly the sort of mistake we expected.


r~

Re: Problem with operand handling

[Richard Kenner]

Sorry for the delay in responding.

    >   system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] & decorator_traceback;

    What does this declaration mean?

I think this is how it prints a REFERENCE_TYPE.

    This may help.  Put this test in add_may_alias:

    if (is_gimple_reg (var) || is_gimple_reg (alias))
      abort ();

It aborts, as I think you expected.

Re: Problem with operand handling

[Andrew MacLeod]

On Tue, 2004-09-07 at 16:35, Richard Kenner wrote:
> Sorry for the delay in responding.
> 
>     >   system__traceback_entries__traceback_entry___XDLU_0__18446744073709551615[1 .. T.2] & decorator_traceback;
> 
>     What does this declaration mean?
> 
> I think this is how it prints a REFERENCE_TYPE.
> 
>     This may help.  Put this test in add_may_alias:
> 
>     if (is_gimple_reg (var) || is_gimple_reg (alias))
>       abort ();
> 
> It aborts, as I think you expected.

 I think he was looking for the traceback froim this abort() so we can
see where the real operand is incorrectly being added to the alias
list...


Andrew

Re: Problem with operand handling

[Richard Kenner]

    > It was happening via a TMT "variable".

    These are alias variables and should never pass the is_gimple_test, so
    we ought not be doing anything with the address being passed into
    add_stmt_operand, the entire function should be dealing with just the
    'var' aspect of whats being passed in.

    Does your variable pass this causing it to be a gimple_reg?  Perhaps a
    flag is set incorrectly or something?

OK, I went back to the code before any of my changes.

The add_stmt_operand is being called from the EXECUTE_IF_SET_IN_BITMAP
call that's looking at call_clobbered_vars.  The variable in this case is
decorator_traceback and is_gimple_reg is set.  In the initial case,
a TMT variable isn't involved.

Re: Problem with operand handling

[Andrew MacLeod]

On Tue, 2004-09-07 at 09:31, Richard Kenner wrote:
>     > It was happening via a TMT "variable".
> 
>     These are alias variables and should never pass the is_gimple_test, so
>     we ought not be doing anything with the address being passed into
>     add_stmt_operand, the entire function should be dealing with just the
>     'var' aspect of whats being passed in.
> 
>     Does your variable pass this causing it to be a gimple_reg?  Perhaps a
>     flag is set incorrectly or something?
> 
> OK, I went back to the code before any of my changes.
> 
> The add_stmt_operand is being called from the EXECUTE_IF_SET_IN_BITMAP
> call that's looking at call_clobbered_vars.  The variable in this case is
> decorator_traceback and is_gimple_reg is set.  In the initial case,
> a TMT variable isn't involved.

what is 'decorator_traceback'? 

From your other note, it seems to indicate that the root of the problem
is that it is being treated as *both* a virtual and a real operand,
which is not allowed.

 The call clobbered list should NOT contain anything which passes
is_gimple_reg(), to the best of my knowledge.  Did you call
mark_call_clobbered() on decorator_traceback?  If so, why if it passes
all the tests in is_gimple_reg..  ie, its not volatile, its address is
not taken, and its not global...

Andrew

Re: Problem with operand handling

[Richard Kenner]

    The only time &var is used as a pointer is if the variable passes the
    test 'is_gimple_reg()'.  Only real operands store this pointer value. 
    If var is a virtual SSA_NAME operand, then we store *var into a tree and
    keep that value around.

I think this is pre-ssa-conversion, so it's still a VAR_DECL.  I didn't
see any code to do that copying.

    So this should only be causing you a problem if you have an
    is_gimple_reg() which is being passed to add_stmt_operand in this
    manner. The thats a bug.

It was happening via a TMT "variable".

Re: Problem with operand handling

[Andrew MacLeod]

On Tue, 2004-09-07 at 08:41, Richard Kenner wrote:
>     The only time &var is used as a pointer is if the variable passes the
>     test 'is_gimple_reg()'.  Only real operands store this pointer value. 
>     If var is a virtual SSA_NAME operand, then we store *var into a tree and
>     keep that value around.
> 
> I think this is pre-ssa-conversion, so it's still a VAR_DECL.  I didn't
> see any code to do that copying.
> 

The is_gimple-ness isnt related to SSA. I should have phrased better.  

We cannot mix virtual and real operands. That is simply not allowed. The
only time the address of the thing being pointed to used is if the
variable passes the is_gimple_reg() test.  The rest of the time *var is
used:
The first stmt in add_stmt_operands is 
  var = *var_p;
and the is_real_op is set based on the return value of is_gimple_reg\().

The only place we actually store these values is through the append_*()
routines. append_def and append_use iare called with var_p,. and all the
others (append_vuse, append_v_may_def, append_v_must_def) are called
either with the derefeernced value 'var', or with a varray_tree item
from the alias list.




>     So this should only be causing you a problem if you have an
>     is_gimple_reg() which is being passed to add_stmt_operand in this
>     manner. The thats a bug.
> 
> It was happening via a TMT "variable".

These are alias variables and should never pass the is_gimple_test, so
we ought not be doing anything with the address being passed into
add_stmt_operand, the entire function should be dealing with just the
'var' aspect of whats being passed in.

is_gimple_reg checks:

 return (is_gimple_variable (t)
          && is_gimple_reg_type (TREE_TYPE (t))
          /* A volatile decl is not acceptable because we can't reuse it as
             needed.  We need to copy it into a temp first.  */
          && ! TREE_THIS_VOLATILE (t)
          && ! needs_to_live_in_memory (t));


Does your variable pass this causing it to be a gimple_reg?  Perhaps a
flag is set incorrectly or something?

Problem with operand handling

[Richard Kenner]

When I work around the problem with lcm.c, I then get:

../../xgcc -B../../ -c -g -O2      -W -Wall -gnatpg  g-exctra.adb -o g-exctra.o
+===========================GNAT BUG DETECTED==============================+
| 5.03h (20040831) (x86_64-unknown-linux-gnu) GCC error:                   |
| in var_ann, at tree-flow-inline.h:38                                     |

Upon investigating, I find I don't understand something about tree-ssa-operands.

It looks like add_stmt_operand is supposed to be passed a pointer to the
operand.  But in a number of places in tree-ssa-operands.c, you have

	tree var = referenced_var (i);

	add_stmt_operand (&var, ...);

But this puts a pointer into the stack of that function into the operands
of the statement.  That looks very wrong and seems to be causing my problem.
How is that supposed to work?

Re: Problem with operand handling

[Andrew MacLeod]

On Sat, 2004-09-04 at 10:51, Richard Kenner wrote:
> When I work around the problem with lcm.c, I then get:
> 
> ../../xgcc -B../../ -c -g -O2      -W -Wall -gnatpg  g-exctra.adb -o g-exctra.o
> +===========================GNAT BUG DETECTED==============================+
> | 5.03h (20040831) (x86_64-unknown-linux-gnu) GCC error:                   |
> | in var_ann, at tree-flow-inline.h:38                                     |
> 
> Upon investigating, I find I don't understand something about tree-ssa-operands.
> 
> It looks like add_stmt_operand is supposed to be passed a pointer to the
> operand.  But in a number of places in tree-ssa-operands.c, you have
> 
> 	tree var = referenced_var (i);
> 
> 	add_stmt_operand (&var, ...);
> 
> But this puts a pointer into the stack of that function into the operands
> of the statement.  That looks very wrong and seems to be causing my problem.
> How is that supposed to work?

Well, I didnt actually write that part of the code, I think thats
Diego's :-)

The only time &var is used as a pointer is if the variable passes the
test 'is_gimple_reg()'.  Only real operands store this pointer value. 
If var is a virtual SSA_NAME operand, then we store *var into a tree and
keep that value around.

So this should only be causing you a problem if you have an
is_gimple_reg() which is being passed to add_stmt_operand in this
manner. The thats a bug.

Andrew

Re: Problem with operand handling

[Andrew Pinski]

On Sep 4, 2004, at 7:51 AM, Richard Kenner wrote:

> When I work around the problem with lcm.c, I then get:
>
> ../../xgcc -B../../ -c -g -O2      -W -Wall -gnatpg  g-exctra.adb -o 
> g-exctra.o
> +===========================GNAT BUG 
> DETECTED==============================+
> | 5.03h (20040831) (x86_64-unknown-linux-gnu) GCC error:               
>     |
> | in var_ann, at tree-flow-inline.h:38                                 
>     |
>
> Upon investigating, I find I don't understand something about 
> tree-ssa-operands.
>
> It looks like add_stmt_operand is supposed to be passed a pointer to 
> the
> operand.  But in a number of places in tree-ssa-operands.c, you have
>
> 	tree var = referenced_var (i);
>
> 	add_stmt_operand (&var, ...);
>
> But this puts a pointer into the stack of that function into the 
> operands
> of the statement.  That looks very wrong and seems to be causing my 
> problem.
> How is that supposed to work?


Usually this means someone forgot to mark something as needed for
renaming.  I have ran this myself when writing some SSA based
optimizations and forgot to mark a variable for renaming.

Thanks,
Andrew Pinski