Warning: Sun f77 1.4 beta clashes with yacc generated C code
bill at stuart.stat.washington.edu
bill at stuart.stat.washington.edu
Sat Mar 23 06:20:20 AEST 1991
In article <1931 at brchh104.bnr.ca> esri!atlas!simon at uunet.uu.net (Simon Pigot) writes:
>Severe problems occur when using fortran 1.4 beta with C code generated
>using yacc. It seems that fortran 1.4 beta uses a yacc parser to parse
>fortran format specifications. Unfortunately the symbols used by their
>yacc parser conflict with those of any local yacc parsers called - the
>result is total confusion during formatted i/o including spurious error
>messages most often reflecting format statements which have been mangled
>because of the clash.
>If you use nm(1) on libF77.so.1.4 you can see the yacc symbols and
>entrypoints the compiler wants to use:
> ...
> 00042f90 T _yyerror
> 0005c990 D _yyexca
> 00042934 T _yylex
> ...
>Some of the yacc parser data structures are statics but others are
>not..... Some of these are entrypoints (yyparse, yylex and yyerror) and
>get confused with the local yacc parser entrypoints.....
There are too many global symbols defined in the newer Sun fortran
libraries that have names that a C programmer expects to be able to use.
This has caused me a lot of headaches. You can make a list of the
offenders with
cd /usr/lang/SC0.0
nm libF77.a | grep ' [TDC] ' | grep -v '_$' | awk '{print $3}' | sort | uniq
There are 337 of them in Fortran 1.3. Only one contains the digit 7 (you
might think they could flag them all with an F77_ prefix -- and document
that convention). The list includes symbols corresponding to the C names
"new", "scale", "subout", "tmpdir", "tab", "radix", "eor", "new", "rfill",
"bufsiz", "cursor", "errflag", "fatal", as well as all the standard "yy.*"
names generated by yacc. It is pretty easy to run into one of them when
you mix C and Fortran code.
>I hope the sun fortran people fix this before the final 1.4 release.
ditto
Bill
More information about the Comp.sys.sun
mailing list