Re: 970125-0.f

[Craig Burley <burley at gnu dot org>]

>  In message <199806012144.RAA08793@melange.gnu.org>you write:
>  > >Note that we have (ADDR_EXPR (ADDR_EXPR ...))  which seems more than
>  > >a little strange to me.
>  > 
>  > In the general case, not any stranger than (ADDR_EXPR (PLUS_EXPR ...)),
>  > which gcc has supported for years.  (Making it possible for me to
>  > rip a bunch of grody code out of g77, and apparently the changes
>  > were driven by Kenner wanting to remove similar code from GNAT as well,
>  > though maybe gpc drove this.)
>So what does it mean to have ADDR_EXPR (PLUS_EXPR ...))).  Do you
>put the result of the PLUS_EXPR into a stack slot, then take it's
>address?

I *think* that's what gcc has done for years.

And, I realized I should have later pointed out that this sort of
"fleeting" ADDR_EXPR is inherently *not* designed to pass a pointer
that lasts beyond the procedure call.

In C terms, this means that doing

  foo (&(&i));
  bar ();

would itself be okay, but that foo and bar could *not* do:

  int **saved_i;

  foo(int **i)
  {
    saved_i = i;
  }

  bar()
  {
    printf ("%p", saved_i);
  }

But that's okay for languages like Fortran, which do not generally
have the C concept of persistent pointers.

So you don't have to worry about such a pointer being persistent,
e.g. being used after the call to read or write the temporary
variable the back end creates -- meaning it can be destroyed
immediately upon return.

>  > Specifically, (ADDR_EXPR (ADDR_EXPR (VAR_DECL `foo'))) in, e.g., a
>  > list of arguments, means "pass a pointer to the address of foo".
>  > Or, "pass the address of foo by reference", which is how g77 really
>  > looks at it.
>OK.  So you want/need the pointer to foo shoved into a stack slot
>and we pass the address of the stack slot?  I can do that, though I
>don't see how it's useful :-)  

Well, it's useful in that that's how it has worked for a very long
time, and that's what various front ends expect.

The alternative is that I go back to a version of g77 a couple of
years old, find the code that worked around the gcc back end *not*
doing this, and try to resurrect it in the current g77 sources...and
that the GNAT, gpc, and other front-end people do similar things
for their front ends.

A bug in the change, though, is that the tree.def documentation for
ADDR_EXPR wasn't updated years ago when its "mandate" was expanded in
this fashion.  That might have saved some trouble -- but at least the
code in expr.c that implements this mandate seems to be pretty
easy to spot.  E.g. the fact that it *doesn't* call abort() when it
sees, e.g., a PLUS_EXPR or ADDR_EXPR as the subexpression is somewhat
revealing by itself.

        tq vm, (burley)

P.S. I just found the ChangeLog entry I think corresponds to this
change:

Wed Mar 31 07:00:45 1993  Richard Kenner  (kenner@apple-gunkies.gnu.ai.mit.edu)

        * expr.c (expand_expr, case ADDR_EXPR): Allow taking the
        address of any object; used in call-by-reference situations.