Date: Wed, 29 May 1996 10:14:46 -0500 (CDT) From: "Lars Jonas Olsson" <jonas@mcs.com> To: jmz@cabri.obs-besancon.fr (Jean-Marc Zucconi) Cc: hackers@freebsd.org, jonas@mcs.net Subject: Re: Potential f77 bugs Message-ID: <m0uOmxU-0005yQC@mars.mcs.com> In-Reply-To: <9605291439.AA29854@cabri.obs-besancon.fr> from "Jean-Marc Zucconi" at May 29, 96 03:39:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
>
> >>>>> Steven G Kargl writes:
>
> > Hackers,
> > I've been looking at the current implementation of the f77 wrapper
> > utility for the f2c+gcc combo, and I've discovered some potential bugs
> > with the way options are handled. (Actually, J Wunsch pointed out the
> > inconsistencies.) According to the source (see gcc.c), the -onetrip
> > f2c option should be honored. Thus,
>
> > %f77 -onetrip file.f
>
> > should cause DO loops to be executed at least once. However, you end
> > up with an a.out file named netrip. Other problems involve the -kr and
> > -krd f2c options.
>
> > %gcc -kr file.c
> > %gcc -krd file.c
>
> > work without reporting that the -k[] option is not valid for a C file
> > compilation. The language specification for Fortran within gcc.c is quite
> > bogus.
>
> > Thus, I have written a new f77 wrapper utility that handles the f2c and
> > gcc options. Additionally, I have written a short man page describing the
> > new f77 utility. It should be noted that my f77 command does not currently
> > support all f2c and gcc options (many don't make sense to use).
>
> > If there is interest, I will submit a GNAT report with an 8k+ uuencode,
> > gzipped tar file.
>
> In fact it seems that none of the f2c flags are processed by f77, and
> that they are simply passed to gcc. (I also encountered this problem
> when I wanted to use the -ext option).
>
> I am interested in a wrapper able to parse all the f2c options!
>
> Jean-Marc
Some f2c flags are processed. The rule is:
(From usr/src/gnu/usr.bin/cc/cc/gcc.c)
/***** ljo's Fortran rule *****/
{".f", "@f2c"},
{"@f2c",
"f2c %{checksubscripts:-C} %{I2} %{onetrip} %{honorcase:-U} %{u} %{w}\
%{ANSIC:-A} %{a} %{C++}\
%{c} %{E} %{ec} %{ext} %{f} %{72} %{g} %{h} %{i2} %{kr}\
%{P} %{p} %{r} %{r8} %{s} %{w8} %{z} %{N*}\
%i %{!pipe: -o %g.c} %{pipe:-o -}|\n",
"cpp -lang-c %{nostdinc*} %{C} %{v} %{A*} %{I*} %{P} %I\
%{C:%{!E:%eGNU C does not support -C without using -E}}\
%{M} %{MM} %{MD:-MD %b.d} %{MMD:-MMD %b.d} %{MG}\
-undef -D__GNUC__=%v1 -D__GNUC_MINOR__=%v2\
%{ansi:-trigraphs -$ -D__STRICT_ANSI__}\
%{!undef:%{!ansi:%p} %P} %{trigraphs} \
%c %{O*:%{!O0:-D__OPTIMIZE__}} %{traditional} %{ftraditional:-traditional}\
%{traditional-cpp:-traditional}\
%{g*} %{W*} %{w} %{pedantic*} %{H} %{d*} %C %{D*} %{U*} %{i*}\
%{pipe:-} %{!pipe:%g.c} %{!M:%{!MM:%{!E:%{!pipe:%g.i}}}}%{E:%W{o*}}%{M:%W{o*}}%{MM:%W{o*}} |\n",
"%{!M:%{!MM:%{!E:cc1 %{!pipe:%g.i} %1 \
%{!Q:-quiet} -dumpbase %b.c %{d*} %{m*} %{a}\
%{g*} %{O*} %{W*} %{w} %{pedantic*} %{ansi} \
%{traditional} %{v:-version} %{pg:-p} %{p} %{f*}\
%{aux-info*}\
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}\
%{S:%W{o*}%{!o*:-o %b.s}}%{!S:-o %{|!pipe:%g.s}} |\n\
%{!S:as %{R} %{j} %{J} %{h} %{d2} %a %Y\
%{c:%W{o*}%{!o*:-o %w%b.o}}%{!c:-o %d%w%u.o}\
%{!pipe:%g.s} %A\n }}}}"},
/***** End of ljo's Fortran rule *****/
This means that we forward to f2c the arguments:
-checksubscripts (renamed to -C before being sent to f2c)
-I2
-onetrip (This one is erronuous as it conflicts with gcc's -o)
-honorcase (renamed to -U)
-u
-w
-ANSIC (renamed to -A)
-a
-C++
etc.
When I wrote this rule I renamed some arguments, but didn't study all
arguments in detail. I think that we probably do not need all possible
f2c options and the ones we need could be renamed to not conflict with
the other compiler stages. The options that we rename should probably
be named similarly to g77's options. Or perhaps rename all conflicting
options with a f2c_ prefix. Another option is to remove some conflciting
options sent to cpp, cc1, and as.
If we can get a consensus on what options a Fortran compiler needs
I think the current solution is quite flexible and solves the f2c
integration quite well. Before this solution we had various f77
shell scripts that never quite handled debugging, profiling, output
renaming, etc.
Jonas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0uOmxU-0005yQC>