ss-199805171100UTC oddity with statement functions (Fortran)

ss-199805171100UTC oddity with statement functions (Fortran)

[Toon Moene]

Consider the following Fortran code:

      program stmfun
      integer n
      values(i,j) = val((i-1)*n+j)
      end

where `values' is a statement function (Fortran's idea of a macro,  
but then at the compiler, not the preprocessor, level) that's not  
used, accessing an array `val' that's not defined.

Now watch this:

% g77 -v -O2 stmfun.f
g77 version 0.5.22-19980315
 gcc -v -O2 -xf77 stmfun.f -xnone -lf2c -lm
Reading specs from  
/usr/local/lib/gcc-lib/m68k-next-nextstep3/2.7.2.3.f.2/specs
gcc version 2.7.2.3.f.2
 /usr/local/lib/gcc-lib/m68k-next-nextstep3/2.7.2.3.f.2/f771  
stmfun.f -fset-g77-defaults -quiet -dumpbase stmfun.f -O2 -version  
-fversion -o /usr/tmp/cc006183.s
GNU F77 version 2.7.2.3.f.2 (68k, MIT syntax) compiled by GNU C  
version 2.7.2.3.f.2.
GNU Fortran Front End version 0.5.22-19980315 compiled: Mar 15 1998  
19:35:34
 as -o /usr/tmp/cc0061831.o /usr/tmp/cc006183.s
 ld -lcrt0.o  
-L/usr/local/lib/gcc-lib/m68k-next-nextstep3/2.7.2.3.f.2  
-L/usr/local/lib /usr/tmp/cc0061831.o -lf2c -lm -lgcc -lsys_s -lgcc

% /usr/snp/bin/g77 -v -O2 stmfun.f
Reading specs from  
/usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/specs
gcc version egcs-2.91.29 19980517 (gcc2 ss-980502 experimental)
 /usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/f771  
stmfun.f -fset-g77-defaults -quiet -dumpbase stmfun.f -O2 -version  
-fversion -o /usr/tmp/cc006188.s
GNU F77 version egcs-2.91.29 19980517 (gcc2 ss-980502 experimental)  
(m68k-next-nextstep3) compiled by GNU C version egcs-2.91.29  
19980517 (gcc2 ss-980502 experimental).
GNU Fortran Front End version 0.5.22-release
 as -o /usr/tmp/cc0061881.o /usr/tmp/cc006188.s
 /usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/collect2  
-lcrt0.o -L/usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29  
-L/usr/snp/m68k-next-nextstep3/lib -L/usr/snp/lib  
/usr/tmp/cc0061881.o -lf2c -lm -lgcc -lsys_s -lgcc
/bin/ld: Undefined symbols:
_val_
collect2: ld returned 1 exit status

Anyone with a bright idea ?

Note that this is not contrary to the Standard - I have seen this  
with Digital's Fortran compiler too, and as far as I understand the  
Fortran 90 Handbook (as close to the Standard as I can get) there is  
nothing to prevent the compiler to generate code for `values' (and  
hence trying to access `val') even if it's not used.

Note 2: For complete understanding of this example one should know  
that in Fortran an identifier, followed by something between  
parentheses, *that isn't declared as an array* is an implicitly  
declared function call :-) :-)

Cheers,
Toon.

Re: ss-199805171100UTC oddity with statement functions (Fortran)

[Craig Burley]

>Anyone with a bright idea ?

This could easily be just a change in the way g77 is handling
the relevant stuff in the front end.  Some g77 bugs have been
due to trying to not tell the back end about various things
that appeared "unused" in the past.  So maybe this change in
behavior came about due to fixing a bug like this.

Or, maybe something regarding inlining broke between 0.5.22
and egcs.

I'll try to make time to look into it myself soon.

        tq vm, (burley)

Re: ss-199805171100UTC oddity with statement functions (Fortran)

[Toon Moene]

>  This could easily be just a change in the way g77 is
>  handling the relevant stuff in the front end.  Some g77
>  bugs have been due to trying to not tell the back end
>  about various things that appeared "unused" in the past.
>  So maybe this change in behavior came about due to fixing
>  a bug like this.
>
>  Or, maybe something regarding inlining broke between
>  0.5.22 and egcs.

Well, I checked that the difference is that g77-0.5.22+gcc-2.7.2.3  
(and egcs snapshots until very recently, at least until the end of  
April !) eliminates the statement function because it isn't used.

I seem to recall that you once described statement functions as  
being implemented as inline nested functions.  Apparently, until  
very recently, the code for such functions was eliminated if they  
weren't used; but nowadays the backend has changed its mind ...

Could it be the case that now you have to declare them "static  
inline" (I have no clear idea what a non-static nested function  
would be, but then, I didn't invent them) ?

Apropos, I really, really hope this change will be reverted - I  
looked into changing my code to cope with this for about half an  
hour, fiercely grepping around in about 350 affected routines, until  
I had eliminated about 10 % of the cases - then I dropped the ball;  
this is no small task ;-)

Cheers,
Toon.

Re: ss-199805171100UTC oddity with statement functions (Fortran)

[Craig Burley]

>Well, I checked that the difference is that g77-0.5.22+gcc-2.7.2.3  
>(and egcs snapshots until very recently, at least until the end of  
>April !) eliminates the statement function because it isn't used.

Do you know which part of the compiler does this?  Keep in mind
I can't reproduce the problem!  All my versions of g77 link your
example with no complaint.

>I seem to recall that you once described statement functions as  
>being implemented as inline nested functions.  Apparently, until  
>very recently, the code for such functions was eliminated if they  
>weren't used; but nowadays the backend has changed its mind ...

Perhaps.  According to my g77 source code, namely, com.c's
ffecom_finish_symbol_transform_, statement functions *will*
get transformed, meaning they *will* be "compiled" to the back end.
So you're probably right that if, indeed, there is a change here,
it's in the back end.

>Could it be the case that now you have to declare them "static  
>inline" (I have no clear idea what a non-static nested function  
>would be, but then, I didn't invent them) ?

Dunno; apparently g77 sets the "nested/inline" flag, which, in this
case, means nested, I assume.

I wonder if the problem really stems from some change in the m68k
configuration that causes *any* external reference to have a separate
line of assembler code output to make sure its known that way?
Have you looked at the assembler output, for example?

>Apropos, I really, really hope this change will be reverted - I  
>looked into changing my code to cope with this for about half an  
>hour, fiercely grepping around in about 350 affected routines, until  
>I had eliminated about 10 % of the cases - then I dropped the ball;  
>this is no small task ;-)

Would it be easier if g77 gave you a direct diagnostic-style pointer
to any implicitly typed reference within a statement function?  I
assume -Wimplicit would cast too wide a net to be useful.  So a special
check might be something I could kludge up in short order; then you
could go fix your code.  :)

        tq vm, (burley)

Re: ss-199805171100UTC oddity with statement functions (Fortran)

[Dave Love]

>>>>> "Craig" == Craig Burley <burley@gnu.org> writes:

 Craig> I wonder if the problem really stems from some change in the
 Craig> m68k configuration that causes *any* external reference to
 Craig> have a separate line of assembler code output to make sure its
 Craig> known that way?

No, this is reproducible on i586-pc-linux-gnulibc1 with a CVS update
done today.  It must be due to something that's changed in the middle
end in the last week or so.  I'll make a test case.

Re: ss-199805171100UTC oddity with statement functions (Fortran)

[Dave Love]

The cause of the grief is:

Fri May 15 18:49:30 1998  Mark Mitchell  <mmitchell@usa.net>

        * toplev.c (rest_of_compilation): Don't defer nested functions.

Re: ss-199805171100UTC oddity with statement functions; was Fortran,now C

[Toon Moene]

OK, you unbelievers:

Is the following change in behaviour really intended ?

% cat stmfun.c
main()
{
        inline int aap() {int noot(); return noot();};
}

% gcc -v -O2 stmfun.c
Reading specs from  
/usr/local/lib/gcc-lib/m68k-next-nextstep3/2.7.2.3.f.2/specs
gcc version 2.7.2.3.f.2
 /usr/local/lib/gcc-lib/m68k-next-nextstep3/2.7.2.3.f.2/cpp -lang-c  
-v -undef -D__GNUC__=2 -D__GNUC_MINOR__=7 -Dmc68000 -Dm68k -DNeXT  
-Dunix -D__MACH__ -D__BIG_ENDIAN__ -D__ARCHITECTURE__="m68k"  
-D__mc68000__ -D__m68k__ -D__NeXT__ -D__unix__ -D__MACH__  
-D__BIG_ENDIAN__ -D__ARCHITECTURE__="m68k" -D__mc68000 -D__m68k  
-D__NeXT -D__unix -Asystem(unix) -Asystem(mach) -Acpu(m68k)  
-Amachine(m68k) -D__OPTIMIZE__ -D__STDC__ -D_NEXT_SOURCE stmfun.c  
/usr/tmp/cc013033.i
GNU CPP version 2.7.2.3.f.2 (68k, MIT syntax)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/m68k-next-nextstep3/include
 /usr/local/lib/gcc-lib/m68k-next-nextstep3/2.7.2.3.f.2/include
 /usr/local/lib/gcc-lib/m68k-next-nextstep3/2.7.2.3.f.2/include/ansi
 /usr/local/lib/gcc-lib/m68k-next-nextstep3/2.7.2.3.f.2/include/bsd
 /NextDeveloper/Headers
 /NextDeveloper/Headers/ansi
 /NextDeveloper/Headers/bsd
 /LocalDeveloper/Headers
 /LocalDeveloper/Headers/ansi
 /LocalDeveloper/Headers/bsd
 /NextDeveloper/2.0CompatibleHeaders
 /usr/include
 /usr/include/bsd
End of search list.
 /usr/local/lib/gcc-lib/m68k-next-nextstep3/2.7.2.3.f.2/cc1  
/usr/tmp/cc013033.i -quiet -dumpbase stmfun.c -O2 -version -o  
/usr/tmp/cc013033.s
GNU C version 2.7.2.3.f.2 (68k, MIT syntax) compiled by GNU C  
version 2.7.2.3.f.2.
 as -o /usr/tmp/cc0130331.o /usr/tmp/cc013033.s
 ld -lcrt0.o  
-L/usr/local/lib/gcc-lib/m68k-next-nextstep3/2.7.2.3.f.2  
-L/usr/local/lib /usr/tmp/cc0130331.o -lgcc -lsys_s -lgcc

% /usr/snp/bin/gcc -v -O2 stmfun.c
Reading specs from  
/usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/specs
gcc version egcs-2.91.29 19980517 (gcc2 ss-980502 experimental)
 /usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/cpp -lang-c  
-v -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -Dmc68000 -Dm68k -DNeXT  
-Dunix -D__MACH__ -D__BIG_ENDIAN__ -D__ARCHITECTURE__="m68k"  
-D_NEXT_SOURCE -D__mc68000__ -D__m68k__ -D__NeXT__ -D__unix__  
-D__MACH__ -D__BIG_ENDIAN__ -D__ARCHITECTURE__="m68k" -D_NEXT_SOURCE  
-D__mc68000 -D__m68k -D__NeXT -D__unix -Asystem(unix)  
-Asystem(mach) -Acpu(m68k) -Amachine(m68k) -D__OPTIMIZE__ -D__STDC__  
-D_NEXT_SOURCE stmfun.c /usr/tmp/cc013039.i
GNU CPP version egcs-2.91.29 19980517 (gcc2 ss-980502 experimental)  
(68k, MIT syntax)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/snp/m68k-next-nextstep3/include
 /usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/include
 /usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/include/ansi
 /usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/include/bsd
 /NextDeveloper/Headers
 /NextDeveloper/Headers/ansi
 /NextDeveloper/Headers/bsd
 /NextDeveloper/2.0CompatibleHeaders
 /usr/include
 /usr/include/bsd
End of search list.
 /usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/cc1  
/usr/tmp/cc013039.i -quiet -dumpbase stmfun.c -O2 -version -o  
/usr/tmp/cc013039.s
GNU C version egcs-2.91.29 19980517 (gcc2 ss-980502 experimental)  
(m68k-next-nextstep3) compiled by GNU C version egcs-2.91.29  
19980517 (gcc2 ss-980502 experimental).
 as -o /usr/tmp/cc0130391.o /usr/tmp/cc013039.s
 /usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/collect2  
-lcrt0.o -L/usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29  
-L/usr/snp/m68k-next-nextstep3/lib -L/usr/snp/lib  
/usr/tmp/cc0130391.o -lgcc -lsys_s -lgcc
/bin/ld: warning table of contents of library:  
/usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/libgcc.a not  
sorted slower link editing will result (use the ranlib(1) -s option)
/bin/ld: warning table of contents of library:  
/usr/snp/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.29/libgcc.a not  
sorted slower link editing will result (use the ranlib(1) -s option)
/bin/ld: Undefined symbols:
_noot
collect2: ld returned 1 exit status

Happy Hunting (this bug).

Toon.