> I'm wondering why verify_ssa doesn't detect this.
It does. See for instance pr 15740, which had generated an ICE.
But what I don't understand is why it didn't ICE in my case.
That we don't constantly see problems is indicitive that the
front-ends are good about using mark_
On Tue, Sep 06, 2005 at 03:37:26PM -0400, Richard Kenner wrote:
> I'm wondering why verify_ssa doesn't detect this.
It does. See for instance pr 15740, which had generated an ICE.
That we don't constantly see problems is indicitive that the
front-ends are good about using mark_addressable when
> Yeah, that's what I realized in working on this problem. Is it worth
> adding a flag to show that this is a gimple-generated variable so we
> can have an assert that we're not trying to mark it as addressable?
What has gimple-generated got to do with it?
Well, if it's gimple-ge
On Tue, Sep 06, 2005 at 03:07:35PM -0400, Richard Kenner wrote:
> Yeah, that's what I realized in working on this problem. Is it worth adding
> a flag to show that this is a gimple-generated variable so we can have
> an assert that we're not trying to mark it as addressable?
What has gimple-gener
If part way through gimplification you mark a variable as addressable,
then you invalidate the gimplification of preceeding statements. At
least for variables whose type satisfies is_gimple_reg_type.
Yeah, that's what I realized in working on this problem. Is it worth adding
a fla
On Tue, Sep 06, 2005 at 02:41:14PM -0400, Richard Kenner wrote:
> It certainly calls mark_addressable in various places, so I don't follow.
Then these are bugs waiting to happen.
If part way through gimplification you mark a variable as addressable,
then you invalidate the gimplification of prece
The gimplifier never sets TREE_ADDRESSABLE on existing variables.
It certainly calls mark_addressable in various places, so I don't follow.
On Tue, Sep 06, 2005 at 01:45:22PM -0400, Richard Kenner wrote:
> Thanks. I was just copying that code without full understanding
> of what it was doing. But where is that flag cleared when TREE_ADDRESSABLE
> is set? I can't find anything that ever clears it?
Because TREE_ADDRESSABLE should alr
>if (TREE_CODE (TREE_TYPE (op)) == COMPLEX_TYPE)
> DECL_COMPLEX_GIMPLE_REG_P (new_var) = 1;
You should not have set this; you're taking the address of
the variable after all.
Thanks. I was just copying that code without full understanding
of what it was doing. But w
On Tue, Sep 06, 2005 at 08:04:29AM -0400, Richard Kenner wrote:
> if (TREE_CODE (TREE_TYPE (op)) == COMPLEX_TYPE)
> DECL_COMPLEX_GIMPLE_REG_P (new_var) = 1;
You should not have set this; you're taking the address of
the variable after all.
> I don't care for the duplication of c
> But only where the semantics are well defined. I can think of several
> different possible semantics for talking the address of arbitrary
> things.
>
> The counter-argument is that it can used when the semantics need *not* be
> well-defined, in other words, where you're saying you do
[EMAIL PROTECTED] (Richard Kenner) writes:
| The whole point of the gimplifier is to avoid making too many restrictions on
| what are valid trees: it's GIMPLE where we want to make those restrictions.
| It seems very duplicative to me to say that the process of creating
| temporaries for certain e
But only where the semantics are well defined. I can think of several
different possible semantics for talking the address of arbitrary
things.
The counter-argument is that it can used when the semantics need *not* be
well-defined, in other words, where you're saying you don't care.
> But secondly, why make that restriction at all? Suppose I have a function
> to which a language semantics requires passing by reference. Now suppose
> the operand is "a + b". Why not just make an ADDR_EXPR of the PLUS_EXPR?
>
> Sure, the front end *could* make a temporary, but the gimplifier h
Hmm, odd that such a rule wouldn't exist.
Not at all odd! We have almost no rules *whatsoever* on what's allowed
in each operand of a GENERIC tree. That's the problem here.
To me it seems an ADDR_EXPR only makes sense on something that is
addressable,
First of all, define "addres
On Tuesday 06 September 2005 15:37, Richard Kenner wrote:
> What would be your proposal as to which nodes it's valid to have as
> operands of an ADDR_EXPR? We certainly never even thought of such a rule
> before.
Hmm, odd that such a rule wouldn't exist. To me it seems an ADDR_EXPR
only makes se
Can't you use get_initialized_tmp_var, then?
No, and that's the whole point! You need to set TREE_ADDRESSABLE on
the variable *before* gimplifying the MODIFY_EXPR.
Steven Bosscher <[EMAIL PROTECTED]> writes:
| On Tuesday 06 September 2005 15:05, Gabriel Dos Reis wrote:
| > Richard Guenther <[EMAIL PROTECTED]> writes:
| > | On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
| > | > I don't think we ever defined "valid GENERIC" that way.
| > | >
| > | >
Richard Kenner <[EMAIL PROTECTED]> wrote:
> /* Otherwise, if we are taking the address of something that is
> neither a refence, declaration, or constant, make a variable for the
operand
> here and then take its address. If we don't do it this way, we may
> confuse the gimplifier because it
Because it doesn't make sense to take the address of a COMPOUND_EXPR
for example? As Kenner puts it himself:
"This turned out to be the "well known" problem that the Ada
front end is making an ADDR_EXPR of odd things, in this case
a COMPOUND_EXPR."
So there
The only useful definition is that valid GENERIC is what the
gimplifier can turn into valid GIMPLE, which is much more well-defined
;) Modulo bugs in the gimplifier of course ...
But that's the whole problem! If you have a tree that the gimplifier
can't correctly process, how do you d
On Tuesday 06 September 2005 15:05, Gabriel Dos Reis wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
> | On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> | > I don't think we ever defined "valid GENERIC" that way.
> | >
> | > About a year ago, when we tried to define it, that's what
Richard Guenther <[EMAIL PROTECTED]> writes:
| On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
| > I don't think we ever defined "valid GENERIC" that way.
| >
| > About a year ago, when we tried to define it, that's what we came up
| > with. If that isn't the definition, then what *is*?
On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> I don't think we ever defined "valid GENERIC" that way.
>
> About a year ago, when we tried to define it, that's what we came up
> with. If that isn't the definition, then what *is*? The problem is that
> we have no document that says wh
I don't think we ever defined "valid GENERIC" that way.
About a year ago, when we tried to define it, that's what we came up
with. If that isn't the definition, then what *is*? The problem is that
we have no document that says what is and is not valid GENERIC. At
least the proposed defini
On Tuesday 06 September 2005 14:04, Richard Kenner wrote:
> On the
> other hand, we define "valid GENERIC" to be those trees that were generated
> by the compiler immediately before the tree-ssa conversion and trees of the
> above form were generated then. So they are valid GENERIC and ought to be
> # VUSE ;
> VIEW_CONVERT_EXPR(*D.861).b = 1;
Why are we using a VIEW_CONVERT_EXPR here btw? I'd say
D.862 = (struct c34007p__T7b *) D.860;
D.862->b = 1;
would be a lot more middle-end friendly and maybe not exposing the
problem you are seeing? Of co
You want to look at tree-ssa-operands.c:get_expr_operands() and see where
things go wrong. Also for D.861 not in SSA form, there might be a missing
call to mark_vars_to_rename and/or update_ssa somewhere. At which point
in the pass flow does the above happen? Is it ever "correct"
On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Here's a fragment of the SSA dump for a shortened version of that
> test.
>
>
> D.860_8 = __gnat_malloc (20);
> # D.861_10 = V_MUST_DEF ;
> D.861 = (struct c34007p__designated *) D.860_8;
> # VUSE ;
> VIEW_CONVERT_EXPR(*D.861).b
On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Here's a fragment of the SSA dump for a shortened version of that
> test.
>
>
> D.860_8 = __gnat_malloc (20);
> # D.861_10 = V_MUST_DEF ;
> D.861 = (struct c34007p__designated *) D.860_8;
> # VUSE ;
> VIEW_CONVERT_EXPR(*D.861).b
Here's a fragment of the SSA dump for a shortened version of that
test.
D.860_8 = __gnat_malloc (20);
# D.861_10 = V_MUST_DEF ;
D.861 = (struct c34007p__designated *) D.860_8;
# VUSE ;
VIEW_CONVERT_EXPR(*D.861).b = 1;
# VUSE ;
VIEW_CONVERT_EXPR(*D.861).l = 3;
There last two s
31 matches
Mail list logo
