Re: Serious problems with tree-ssa operand handling

Re: Serious problems with tree-ssa operand handling

[Richard Kenner]

    I would need a test case.

The test case is the Ada library file I mentioned.  It happens to be a *very*
small file.

    Do you have a variable that is a GIMPLE reg and at the same time
    belongs to an alias set or its address is taken?

Yes.  See my later message.

Re: Serious problems with tree-ssa operand handling

[Diego Novillo]

On Tue, 2004-09-07 at 11:27, Richard Kenner wrote:

>     Do you have a variable that is a GIMPLE reg and at the same time
>     belongs to an alias set or its address is taken?
> 
> Yes.  See my later message.
>
What later message?  Thanks to your reluctance to use a properly
threading mailer, I find it impossible to follow the threads that you
contribute to.  Lately, I have had to start ignoring threads that you
break with your MUA, so I don't know what you are talking about.

Give me a test case and a way to reproduce it.  Otherwise, I can't help
you.


Diego.

Re: Serious problems with tree-ssa operand handling

[Joe Buck]

On Tue, Sep 07, 2004 at 11:27:18AM -0400, Diego Novillo wrote:
> On Tue, 2004-09-07 at 11:27, Richard Kenner wrote:
> 
> >     Do you have a variable that is a GIMPLE reg and at the same time
> >     belongs to an alias set or its address is taken?
> > 
> > Yes.  See my later message.
> >
> What later message?  Thanks to your reluctance to use a properly
> threading mailer, I find it impossible to follow the threads that you
> contribute to.  Lately, I have had to start ignoring threads that you
> break with your MUA, so I don't know what you are talking about.

Agreed; any long thread Kenner participates in is unreadable.

Here's an item for the projects file: let's call it "deKennerize".  Given
an mbox file full of gcc messages, try to deduce what message each message
from Richard Kenner is replying to, using subjects, dates, recipients, and
quoted text as clues.  Produce a new mbox file with proper References or
In-Reply-To headers added.

This is easiest given a Perl or Python module that supports parsing of
mbox files into messages and headers.

Re: Serious problems with tree-ssa operand handling

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.COM> writes:

| On Tue, Sep 07, 2004 at 11:27:18AM -0400, Diego Novillo wrote:
| > On Tue, 2004-09-07 at 11:27, Richard Kenner wrote:
| > 
| > >     Do you have a variable that is a GIMPLE reg and at the same time
| > >     belongs to an alias set or its address is taken?
| > > 
| > > Yes.  See my later message.
| > >
| > What later message?  Thanks to your reluctance to use a properly
| > threading mailer, I find it impossible to follow the threads that you
| > contribute to.  Lately, I have had to start ignoring threads that you
| > break with your MUA, so I don't know what you are talking about.
| 
| Agreed; any long thread Kenner participates in is unreadable.
| 
| Here's an item for the projects file: let's call it "deKennerize".  Given
| an mbox file full of gcc messages, try to deduce what message each message
| from Richard Kenner is replying to, using subjects, dates, recipients, and
| quoted text as clues.  Produce a new mbox file with proper References or
| In-Reply-To headers added.
| 
| This is easiest given a Perl or Python module that supports parsing of
| mbox files into messages and headers.

I would think it would be easier if Richar Kenner accepted to use a
MUA that does not break things.  Even Robert Dewar eventually swicthed to
something helpful.

-- Gaby

Re: Serious problems with tree-ssa operand handling

[Richard Kenner]

    You would probably find the original 4.3bsd sources here, if you are
    willing to fork out the $99..

    http://www.mckusick.com/csrg/

Thanks.  I ordered it.  I'm pretty sure the SunOS sources aren't exactly
the same as the 4.3bsd mailer sources, but I think the only differences
has to do with the graphical mailer, which I no longer use.

So hopefully I should be set up by the end of the month (it sounds like
I should get the CDs in around a week).

Re: Serious problems with tree-ssa operand handling

[Erik Trulsson]

On Thu, Sep 16, 2004 at 07:55:00PM +0200, Kai Henningsen wrote:
> kenner@vlsi1.ultra.nyu.edu (Richard Kenner)  wrote on 16.09.04 in <10409161326.AA03462@vlsi1.ultra.nyu.edu>:
> 
> >     What exactly is the build problem you are running into?
> >
> > It was a few months ago.  Each version had a different problem.  Mostly
> > missing macros.a
> >
> >     nail is derived from berkeley mail, so it shouldn't be too unportable.
> >
> > I know.  That's what I thought and SunOS 4.1.4 is pretty much a vanilla
> > 4.3bsd, so I was quite surprised.
> 
> Well, I have no idea if this helps, but the FreeBSD CVS does contain a  
> version tagged bsd_44_lite. That *should* be close - but you never know.

Likely to be large differences.  4.3BSD was originally released in
1986. 4.4BSD-Lite was released in 1994 (after the legal problems with
AT&T had been resolved.) There was quite a bit of development done
between 4.3BSD and 4.4BSD.

Some old BSD releases can be found at ftp://ftp.funet.fi/pub/unix
The original 4.3BSD doesn't seem to be there but 4.3BSD-Reno is.

-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

Re: Serious problems with tree-ssa operand handling

[Kai Henningsen]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner)  wrote on 16.09.04 in <10409161326.AA03462@vlsi1.ultra.nyu.edu>:

>     What exactly is the build problem you are running into?
>
> It was a few months ago.  Each version had a different problem.  Mostly
> missing macros.a
>
>     nail is derived from berkeley mail, so it shouldn't be too unportable.
>
> I know.  That's what I thought and SunOS 4.1.4 is pretty much a vanilla
> 4.3bsd, so I was quite surprised.

Well, I have no idea if this helps, but the FreeBSD CVS does contain a  
version tagged bsd_44_lite. That *should* be close - but you never know.

Their CVS access description page seems to be
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/anoncvs.html

MfG Kai

Re: Serious problems with tree-ssa operand handling

[Robert Dewar]

Richard Kenner wrote:

>     | Robert and I have very different usage patterns (he uses a laptop and I
>     | use different computers in different places), so his solution won't work
>     | for me.
> 
>     So, you think it is better to inconvenient other people?
> 
> I don't follow.  It's not a matter of inconvenience: the solution
> Robert uses *depends* on his using only one machine.  It *can't* work
> for me since I don't do that.

Actually that's not true at all, you can use Mozilla to read mail from
multiple machines just fine. Surely the issue is switching to a different
mailer, there are dozens of mailers that thread properly. Certainly if
you think you would be comfortable using Mozilla like I do, the issue
of using multiple machines is not a reason to avoid this!

(says Robert, who has joined the ranks of those a bit frustrated
by Richard's failure to thread :-)

Re: Serious problems with tree-ssa operand handling

[Richard Earnshaw]

On Thu, 2004-09-16 at 14:26, Richard Kenner wrote:
>     What exactly is the build problem you are running into?
> 
> It was a few months ago.  Each version had a different problem.  Mostly
> missing macros.a
> 
>     nail is derived from berkeley mail, so it shouldn't be too unportable.
> 
> I know.  That's what I thought and SunOS 4.1.4 is pretty much a vanilla
> 4.3bsd, so I was quite surprised.

You would probably find the original 4.3bsd sources here, if you are
willing to fork out the $99..

http://www.mckusick.com/csrg/

R.

Re: Serious problems with tree-ssa operand handling

[Richard Kenner]

    What exactly is the build problem you are running into?

It was a few months ago.  Each version had a different problem.  Mostly
missing macros.a

    nail is derived from berkeley mail, so it shouldn't be too unportable.

I know.  That's what I thought and SunOS 4.1.4 is pretty much a vanilla
4.3bsd, so I was quite surprised.

Re: Serious problems with tree-ssa operand handling

[Daniel Berlin]

On Thu, 16 Sep 2004, Richard Kenner wrote:

>    > Does anybody have sources for /usr/ucb/mail for SunOS 4.1.4 ...
>
>    http://nail.sourceforge.net/
>
> I'm sorry, but I can't find the 4.1.4 sources there.  That seems to just
> contain sources for a different program called "nail".  Somebody else
> suggested I try to use it, but every version I tried to compile wouldn't even
> build on my machine,

What exactly is the build problem you are running into?

nail is derived from berkeley mail, so it shouldn't be too unportable.

We all understand that you are completely 100% busy, so we're happy to 
help try to make it so we can read your threads.

Re: Serious problems with tree-ssa operand handling

[Richard Kenner]

    So, what is *so unique* to you and your settings that, with all machines
    and OSes you're using you cannot manage to have one of them use a MUA
    that sets references? 

I didn't say I can't, I just said that *Robert's* solution won't work for me
since it depends on using a laptop everywhere.  I only have terminal
emulators on the machines I'm sitting in front of and use a text-based
mailer on this system from everywhere

Indeed, I know I *can* find an MUA that'll work fine by modifying this one:
it's just a matter of getting the sources so I can do that work.  We had them,
but, as I said, the CD was in a machine that was stolen.  So they need to
be found again.  I keep looking, but if anybody else has them, it'll save
me time.  I expect it to be a few hours work to make the change once I
locate them.

Re: Serious problems with tree-ssa operand handling

[Gabriel Dos Reis]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

|     | Robert and I have very different usage patterns (he uses a laptop and I
|     | use different computers in different places), so his solution won't work
|     | for me.
| 
|     So, you think it is better to inconvenient other people?
| 
| I don't follow.  It's not a matter of inconvenience: the solution
| Robert uses *depends* on his using only one machine.  It *can't* work
| for me since I don't do that.

Well, I happen to use different machines running different OSes at
different places; yet, I've managed to use a MUA that set references
properly.  I highly suspect that I'm not alone in that situation.
I highly doubt it depends on one using only one machine.  That is a
non-argument. 

So, what is *so unique* to you and your settings that, with all machines
and OSes you're using you cannot manage to have one of them use a MUA
that sets references? 

-- Gaby

Re: Serious problems with tree-ssa operand handling

[Richard Kenner]

    > Does anybody have sources for /usr/ucb/mail for SunOS 4.1.4 ...

    http://nail.sourceforge.net/

I'm sorry, but I can't find the 4.1.4 sources there.  That seems to just
contain sources for a different program called "nail".  Somebody else
suggested I try to use it, but every version I tried to compile wouldn't even
build on my machine, so I couldn't even start to look and see if it would
work for me.

I'm perfectly willing to modify my mailer to add "In-Reply-To" (I accidentally
said "References" in my last message), but I need the sources to start with.
Does that site have them?

Re: Serious problems with tree-ssa operand handling

[Richard Kenner]

    | Robert and I have very different usage patterns (he uses a laptop and I
    | use different computers in different places), so his solution won't work
    | for me.

    So, you think it is better to inconvenient other people?

I don't follow.  It's not a matter of inconvenience: the solution
Robert uses *depends* on his using only one machine.  It *can't* work
for me since I don't do that.

    | What I want to do is add "References" support to the mailer I use, but
    | haven't been able to find the sources to start with.

    Zack had provided many links and suggestions in the past.

I don't remember who it was, but somebody did point to a mailer called
"nail".  Unfortunately, I couldn't even get it to compile on my machine, so I
couldn't see if it was suitable or not.  Starting from what I have and adding
what's needed is 100% safe, so that's my plan.  I had the sources, but they
were in a CD of a machine that got stolen before I was able to read them, so
I couldn't use them.  I haven't been able to find them (/usr/ucb/mail sources
for SunOs 4.1.4) again.  If anybody has them, as I said, I'd greatly
appreciate it.

Re: Serious problems with tree-ssa operand handling

[Richard Henderson]

On Wed, Sep 15, 2004 at 10:24:35PM -0400, Richard Kenner wrote:
> Does anybody have sources for /usr/ucb/mail for SunOS 4.1.4 ...

http://nail.sourceforge.net/



r~

Re: Serious problems with tree-ssa operand handling

[Gabriel Dos Reis]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

|     I would think it would be easier if Richar Kenner accepted to use a
|     MUA that does not break things.  Even Robert Dewar eventually swicthed
|     to something helpful.
| 
| Robert and I have very different usage patterns (he uses a laptop and I
| use different computers in different places), so his solution won't work
| for me.

So, you think it is better to inconvenient other people?

| What I want to do is add "References" support to the mailer I use, but
| haven't been able to find the sources to start with.

Zack had provided many links and suggestions in the past.


-- Gaby

Re: Serious problems with tree-ssa operand handling

[Richard Kenner]

    I would think it would be easier if Richar Kenner accepted to use a
    MUA that does not break things.  Even Robert Dewar eventually swicthed
    to something helpful.

Robert and I have very different usage patterns (he uses a laptop and I
use different computers in different places), so his solution won't work
for me.

What I want to do is add "References" support to the mailer I use, but
haven't been able to find the sources to start with.

Does anybody have sources for /usr/ucb/mail for SunOS 4.1.4 (or similar
version)?

Re: Serious problems with tree-ssa operand handling

[Richard Kenner]

    Give me a test case and a way to reproduce it.  Otherwise, I can't help
    you.

After building a gnat1 and setting up a library directory (make gnatlib
and let it blow up), do:

	./gnat1 -Iada/rts -O2 -gnatpg ada/rts/g-exctra.adb

Re: Serious problems with tree-ssa operand handling

[Diego Novillo]

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

> As I said originally, this puts a pointer into the stack of that function
> into the operands of the statement.  That causes an access of junk when
> the operands are referenced.
> 
No, it does not.  VAR is not a GIMPLE register, follow what happens to
non-GIMPLE registers in add_stmt_operand:

   1424 add_stmt_operand (tree *var_p, tree stmt, int flags)
   1425 {
[ ... ]
   1430
   1431   var = *var_p;
   1432   STRIP_NOPS (var);
[ ... ]
   1445   is_real_op = is_gimple_reg (var);
   1446   if (!is_real_op && !DECL_P (var))
   1447     var = get_virtual_var (var);
[ ... ]
   1463
   1464   if (is_real_op)
   1465     {
   1466       /* The variable is a GIMPLE register.  Add it to real operands.  */
   1467       if (flags & opf_is_def)
   1468         append_def (var_p);
   1469       else
   1470         append_use (var_p);
   1471     }
   1472   else
   1473     {
[ ... ]
   1497                   append_v_may_def (var);
[ ... ]
   1509                   append_v_must_def (var);
   1510                 }
[ ...]
   1515                   append_v_may_def (var);
[ ... ]
   1520               append_vuse (var);
[ ... ]
   1543                 append_v_may_def (var);
   1544
[ ... ]
   1546                 append_v_may_def (VARRAY_TREE (aliases, i));
[ ... ]
   1556                 append_vuse (var);
   1557
[ ... ]
   1559                 append_vuse (VARRAY_TREE (aliases, i));
[ ... ]
   1565      }

I have elided most of the logic.  But you see that we only ever use
VAR_P if we are given a real operand (i.e., a symbol that
is_gimple_reg).  The only reason we take the address of the variable is
because for GIMPLE regs we want to store a pointer into the operand so
that we can simplify operand replacement.

We could probably split add_stmt_operand in two so that we have a
version for GIMPLE regs and a version for others.  The downside is that
some of the preparatory logic in add_stmt_operands may have to move to
the callers.


> But I shouldn't have to put in that kludge and disable both checks.
> 
No.  Both kludges are papering over the real problem and are wrong.  I
would need a test case.  Do you have a variable that is a GIMPLE reg and
at the same time belongs to an alias set or its address is taken?


Diego.

Serious problems with tree-ssa operand handling

[Richard Kenner]

I sent http://gcc.gnu.org/ml/gcc/2004-09/msg00189.html on Saturday because
the breakage also happened on Friday.  I've done more work here, which has left
me more confused.  See also http://gcc.gnu.org/ml/gcc/2004-09/msg00196.html

The issue is the adding of virtual operands for a call.  It uses alias
information to do that and adds the operand with:

        tree var = referenced_var (i);
 
        add_stmt_operand (&var, ...);
 
As I said originally, this puts a pointer into the stack of that function
into the operands of the statement.  That causes an access of junk when
the operands are referenced.

I tried fixing that with:

	tree *var_p = &referenced_var (i);
	add_stmt_operand (var_p, stmt, opf_is_def);

That now references defined memory.  But it has the problem that we then
try to put an SSA_NAME into referenced_vars, which is wrong.

Moreover, we get a verification error:

g-exctra.adb: In function `GNAT.EXCEPTION_TRACES.DECORATOR_WRAPPER':
g-exctra.adb:69: error: Found a virtual definition for a GIMPLE register
while verifying SSA_NAME decorator_traceback_35 in statement
#   gnat__exception_traces__current_decorator<D449>_29 = V_MAY_DEF <gnat__except
ion_traces__current_decorator<D449>_18>;
#   T.9<D466>_34 = V_MAY_DEF <T.9<D466>_23>;
#   decorator_traceback<D456>_35 = V_MAY_DEF <decorator_traceback<D456>_17>;
#   T.11<D468>_30 = V_MAY_DEF <T.11<D468>_28>;
#   VUSE <T.8<D465>_27>;
T.11<D468> = gnat__exception_traces__current_decorator.7_19 (T.8<D465>);

This is confusing because an example in doc/tree-ssa.texi implies this sort
of thing is valid.

I disabled that check and "fixed" the clobbering of referenced_vars by trying

		tree *var_p = (tree *) ggc_alloc (sizeof (tree *));

		*var_p = referenced_var (i);
		add_stmt_operand (var_p, stmt, opf_is_def);

Now I get another check failure, saying that a variable appears both as a
real and virtual operand.  When I disable *that* check, I finally get
the Ada RTS to compile, but I get new ACATS failures (possibly related, but
maybe not).

But I shouldn't have to put in that kludge and disable both checks.

Something looks very badly wrong here but I don't understand how this is
supposed to work, so can't say what.