Re: 970125-0.f

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

[ Is the bug in the Fortran Frontend ]

>  Note that we have (ADDR_EXPR (ADDR_EXPR ...))  which
>  seems more than a little strange to me.

Note that 970125-0.f uses the non-standard %LOC construct:

        integer*4 i4
        integer*8 i8
        integer*8 max4
        data max4/2147483647/
        i4 = %loc(i4)
        i8 = %loc(i8)
        print *, max4
        print *, i4, %loc(i4)
        print *, i8, %loc(i8)
        call foo(i4, %loc(i4), i8, %loc(i8))
        end
        subroutine foo(i4, i4a, i8, i8a)
        integer*8 i8
        print *, i4, i4a
        print *, i8, i8a
        end

The documentation says about this:

The @code{%LOC()} construct is an expression
that yields the value of the location of its argument,
@var{arg}, in memory.
[ ... ]
@emph{Implementation Note:} Currently, @code{g77} passes
arguments (those not passed using a construct such as @code{%VAL()})
by reference or descriptor, depending on the type of
the actual argument.
Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
seem to mean the same thing as @samp{CALL FOO(%LOC(I))}, and
in fact might compile to identical code.

This is of course only true when the frontend treats `call  
foo(%loc(i))' specially, as otherwise this would just mean:  Take  
the address of variable `i' and pass it by reference to `foo', which  
indeed would mean to take the address of an address expression.  As  
I never used this construct, I've never run into this, but it might  
well be that `ffecom_arg_ptr_to_expr' in f/com.c `forgets' to treat  
%LOC(I) in a special way here.

HTH,
Toon.