This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 970125-0.f


>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.

The above is wrong; I've fixed the g77 docs in my local copy to
change CALL FOO(%LOC(I)) to CALL FOO(%VAL(%LOC(I))) throughout
the pertinent discussion.

>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.

As it should, of course; the docs were wrong.  I expect I'll be
emailing Dave Love patches to fix this, and other related problems
(there's a rats nest in g77 here ;-) sometime this week.
(Hopefully in time for the next snapshot, but I'm also trying to
finish the upgrade of egcs to g77 0.5.23 and do the system.h
cutover for g77.)

There's still a back-end bug here, though, IMO.

        tq vm, (burley)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]