F77 vs. F90 in Octave

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

F77 vs. F90 in Octave

Rik-4
A quick check for F90 features shows that > 95% is written in F77.  The
exceptions are some files in blas-xtra and lapack-xtra written by Jaroslav
that seem to be in a mostly F77 syntax, but with a few F95 features.

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Daniel Sebald
On 11/24/2014 11:02 AM, Rik wrote:
> A quick check for F90 features shows that>  95% is written in F77.  The
> exceptions are some files in blas-xtra and lapack-xtra written by Jaroslav
> that seem to be in a mostly F77 syntax, but with a few F95 features.

Is the F95 code using a different compiler then?  Or maybe same compiler
but a compatibility flag?  How is it compiling if FC=$F77?

I guess I'd prefer to stick to the autotools method as much as possible.
  In README.MacOS it describes

The commands below are sufficient to build a 32-bit Octave.

   export FC="/usr/bin/gfortran"
...

However, if the make file does FC=$F77, isn't that overriding the
ability to specify the compiler via the environment variable FC?  I see
that as important because what if someone is compiling the code for a
CPU target other than the system the compilation is done on?  I suppose
someone could also add

   export F77="xyz"

Still, I'd stay as close as possible to autoconf, and if it is necessary
to deviate, write a comment along with the deviation.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Rik-4
On 11/24/2014 09:36 AM, Daniel J Sebald wrote:
> On 11/24/2014 11:02 AM, Rik wrote:
>> A quick check for F90 features shows that>  95% is written in F77.  The
>> exceptions are some files in blas-xtra and lapack-xtra written by Jaroslav
>> that seem to be in a mostly F77 syntax, but with a few F95 features.
>
> Is the F95 code using a different compiler then?  Or maybe same compiler
> but a compatibility flag?  How is it compiling if FC=$F77?

As far as I can see, we've simply been getting lucky.  The Fortran compiler
on most Linux systems is gfortran which can compile both F77 and F90 code.


>
> I guess I'd prefer to stick to the autotools method as much as possible.
>  In README.MacOS it describes
>
> The commands below are sufficient to build a 32-bit Octave.
>
>   export FC="/usr/bin/gfortran"
> ...
>
> However, if the make file does FC=$F77, isn't that overriding the ability
> to specify the compiler via the environment variable FC?  I see that as
> important because what if someone is compiling the code for a CPU target
> other than the system the compilation is done on?  I suppose someone
> could also add
>
>   export F77="xyz"
>
> Still, I'd stay as close as possible to autoconf, and if it is necessary
> to deviate, write a comment along with the deviation.

The autotools just set up the defaults and write them to the Makefile.
'make' itself looks at the Makefile, environment variables, and any
overrides given on the command line to decide what value to use for a
variable.  Environment variables override the defaults in the Makefile and
this is standard practice.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Michael Godfrey
In reply to this post by Rik-4
F95 is:
f95 --version
GNU Fortran (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
 so is gfortran:
f95 --version
GNU Fortran (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
=================
and so on.

Compiler options provide suitable behavior.

Checkout:
http://www.g95.org/index.shtml

The GNU fortran system is very good and widely used where "heavy-duty"
computing is required.
Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Michael Godfrey
Minor typo in my previous message:
[godfrey@pbdsl4 octave]$ gfortran --version
GNU Fortran (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

as is:
[godfrey@pbdsl4 octave]$ f95 --version
GNU Fortran (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Daniel Sebald
In reply to this post by Rik-4
On 11/24/2014 11:52 AM, Rik wrote:

> On 11/24/2014 09:36 AM, Daniel J Sebald wrote:
>> On 11/24/2014 11:02 AM, Rik wrote:
>>> A quick check for F90 features shows that>   95% is written in F77.  The
>>> exceptions are some files in blas-xtra and lapack-xtra written by Jaroslav
>>> that seem to be in a mostly F77 syntax, but with a few F95 features.
>>
>> Is the F95 code using a different compiler then?  Or maybe same compiler
>> but a compatibility flag?  How is it compiling if FC=$F77?
>
> As far as I can see, we've simply been getting lucky.  The Fortran compiler
> on most Linux systems is gfortran which can compile both F77 and F90 code.

It's fine if autoconf recognizes that gfortran is compatible with both,
but we shouldn't have to force FC=$F77.

I'm rebuilding from scratch at the moment after having removed FC=$F77.
  I just noticed there is a related modification earlier than the make
stage.  Inside the bootstrap is the following:

bootstrap_epilogue ()
{
   ## G77 is obsolete, but it is still the first option in the autoconf
   ## Fortran macros.  We should avoid it, because mixing old versions of
   ## g77 with modern gcc and g++ causes trouble.  The following will
   ## make it harder (but not impossible) for users to make this mistake.
   ##
   ## FIXME -- we should really work to fix autoconf so that it prefers
   ## gfortran over g77 even when searching for a Fortran 77 compiler.

   echo "replacing all occurrences of g77 with gfortran in configure
script..."

   sed 's/g77/gfortran/g' configure > configure.t
   mv configure.t configure
   chmod 755 configure
}

Perhaps that workaround is out of date.  How does one tell what order
autoconf is using for compiler preference (I've grepped in the auto*
scripts and can't find anything)?  But more than that, isn't the
AC_PROG_F77 macro supposed to control this?

http://www.hep.by/gnu/autoconf/Fortran-Compiler.html

That is, if we want gfortran to have precedence, then we would define
(using the example at the above link)

           AC_PROG_F77([gfortran fl32 f77 fort77 xlf g77 f90 xlf90])

So, perhaps that is a better solution than using the stream editor to
replace g77.

Anyway, compilation is complete without problems here.  What I see in
the Makefile is

F77 = gfortran
...
FC = @FC@

What does the FC = @FC@ mean?

Dan

Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Daniel Sebald
On 11/24/2014 01:33 PM, Daniel J Sebald wrote:

> On 11/24/2014 11:52 AM, Rik wrote:
>> On 11/24/2014 09:36 AM, Daniel J Sebald wrote:
>>> On 11/24/2014 11:02 AM, Rik wrote:
>>>> A quick check for F90 features shows that> 95% is written in F77. The
>>>> exceptions are some files in blas-xtra and lapack-xtra written by
>>>> Jaroslav
>>>> that seem to be in a mostly F77 syntax, but with a few F95 features.
>>>
>>> Is the F95 code using a different compiler then? Or maybe same compiler
>>> but a compatibility flag? How is it compiling if FC=$F77?
>>
>> As far as I can see, we've simply been getting lucky. The Fortran
>> compiler
>> on most Linux systems is gfortran which can compile both F77 and F90
>> code.
>
> It's fine if autoconf recognizes that gfortran is compatible with both,
> but we shouldn't have to force FC=$F77.
>
> I'm rebuilding from scratch at the moment after having removed FC=$F77.
> I just noticed there is a related modification earlier than the make
> stage. Inside the bootstrap is the following:
>
> bootstrap_epilogue ()
> {
> ## G77 is obsolete, but it is still the first option in the autoconf
> ## Fortran macros. We should avoid it, because mixing old versions of
> ## g77 with modern gcc and g++ causes trouble. The following will
> ## make it harder (but not impossible) for users to make this mistake.
> ##
> ## FIXME -- we should really work to fix autoconf so that it prefers
> ## gfortran over g77 even when searching for a Fortran 77 compiler.
>
> echo "replacing all occurrences of g77 with gfortran in configure
> script..."
>
> sed 's/g77/gfortran/g' configure > configure.t
> mv configure.t configure
> chmod 755 configure
> }
>
> Perhaps that workaround is out of date. How does one tell what order
> autoconf is using for compiler preference (I've grepped in the auto*
> scripts and can't find anything)? But more than that, isn't the
> AC_PROG_F77 macro supposed to control this?

Here's an excerpt from configure.ac:

...

dnl Keep this check before the check for the Fortran compiler,
dnl in case -lm is needed to compile Fortran programs.
AC_CHECK_LIB(m, sin)

### Determine the Fortran compiler and how to invoke it

## Default FFLAGS is -O.
if test x"$FFLAGS" = x""; then
   FFLAGS="-O"
fi

## the F77 variable, if set, overrides AC_PROG_F77 automatically
AC_PROG_F77
AC_F77_LIBRARY_LDFLAGS
AC_F77_DUMMY_MAIN
AC_F77_WRAPPERS

...

And here is the configure output for that bit of script:

checking for sin in -lm... yes
checking for gfortran... gfortran
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether gfortran accepts -g... yes
checking how to get verbose linking output from gfortran... -v
checking for Fortran 77 libraries of gfortran...
-L/usr/lib/gcc/x86_64-redhat-linux/4.5.1
-L/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/4.5.1/../../.. -lgfortran -lm
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... lower case, underscore,
no extra underscore
configure: defining FFLAGS to be -O
checking whether gfortran has the intrinsic function ISNAN... yes
checking whether gfortran generates correct size integers... yes
checking whether gfortran accepts -ffloat-store... yes
setting F77_FLOAT_STORE_FLAG to -ffloat-store

The first FORTRAN related thing in this list is "checking for
gfortran... gfortran".  Does this mean that currently the first FORTRAN
compiler that AC looks for is gfortran?  If that is the case, then I
don't think the "epilogue" is needed anymore.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Rik-4
In reply to this post by Daniel Sebald
On 11/24/2014 11:33 AM, Daniel J Sebald wrote:

> On 11/24/2014 11:52 AM, Rik wrote:
>> On 11/24/2014 09:36 AM, Daniel J Sebald wrote:
>>> On 11/24/2014 11:02 AM, Rik wrote:
>>>> A quick check for F90 features shows that>   95% is written in F77.  The
>>>> exceptions are some files in blas-xtra and lapack-xtra written by
>>>> Jaroslav
>>>> that seem to be in a mostly F77 syntax, but with a few F95 features.
>>>
>>> Is the F95 code using a different compiler then?  Or maybe same compiler
>>> but a compatibility flag?  How is it compiling if FC=$F77?
>>
>> As far as I can see, we've simply been getting lucky.  The Fortran compiler
>> on most Linux systems is gfortran which can compile both F77 and F90 code.
>
> It's fine if autoconf recognizes that gfortran is compatible with both,
> but we shouldn't have to force FC=$F77.
>
> I'm rebuilding from scratch at the moment after having removed FC=$F77.
>  I just noticed there is a related modification earlier than the make
> stage.  Inside the bootstrap is the following:
>
> bootstrap_epilogue ()
> {
>   ## G77 is obsolete, but it is still the first option in the autoconf
>   ## Fortran macros.  We should avoid it, because mixing old versions of
>   ## g77 with modern gcc and g++ causes trouble.  The following will
>   ## make it harder (but not impossible) for users to make this mistake.
>   ##
>   ## FIXME -- we should really work to fix autoconf so that it prefers
>   ## gfortran over g77 even when searching for a Fortran 77 compiler.
>
>   echo "replacing all occurrences of g77 with gfortran in configure
> script..."
>
>   sed 's/g77/gfortran/g' configure > configure.t
>   mv configure.t configure
>   chmod 755 configure
> }
>
> Perhaps that workaround is out of date.  How does one tell what order
> autoconf is using for compiler preference (I've grepped in the auto*
> scripts and can't find anything)?  But more than that, isn't the
> AC_PROG_F77 macro supposed to control this?
>
> http://www.hep.by/gnu/autoconf/Fortran-Compiler.html
>
> That is, if we want gfortran to have precedence, then we would define
> (using the example at the above link)
>
>           AC_PROG_F77([gfortran fl32 f77 fort77 xlf g77 f90 xlf90])
>
> So, perhaps that is a better solution than using the stream editor to
> replace g77.

I think this is a fine idea.  Eliminate all the weird hacks with sed in
favor of just listing our preference.

And I'm not sure we want to rely on luck regarding a compiler that handles
both F77 and F90.  I see several choices: 1) Change Jaroslav's code to be
F77-compliant, 2) Change the extension on Jaroslav's files to .f90, but we
would potentially then need to use the AC_PROG_FC macro and get that
working to handle the F90 stuff with a different compiler, 3) Switch
completely over to AC_PROG_FC, but this assumes that any compiler chosen
will be able to compile both F77 and F90 code, 4) force use of gfortran.

>
> Anyway, compilation is complete without problems here.  What I see in the
> Makefile is
>
> F77 = gfortran
> ...
> FC = @FC@
>
> What does the FC = @FC@ mean?

In the final Makefile?  or Makefile.in or Makefile.am?  The pattern @VAR@
is replaced by Autotools when it builds the Makefiles using values from the
configure process.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Daniel Sebald
On 11/24/2014 02:28 PM, Rik wrote:

> On 11/24/2014 11:33 AM, Daniel J Sebald wrote:
>> On 11/24/2014 11:52 AM, Rik wrote:
>>> On 11/24/2014 09:36 AM, Daniel J Sebald wrote:
>>>> On 11/24/2014 11:02 AM, Rik wrote:
>>>>> A quick check for F90 features shows that>    95% is written in F77.  The
>>>>> exceptions are some files in blas-xtra and lapack-xtra written by
>>>>> Jaroslav
>>>>> that seem to be in a mostly F77 syntax, but with a few F95 features.
>>>>
>>>> Is the F95 code using a different compiler then?  Or maybe same compiler
>>>> but a compatibility flag?  How is it compiling if FC=$F77?
>>>
>>> As far as I can see, we've simply been getting lucky.  The Fortran compiler
>>> on most Linux systems is gfortran which can compile both F77 and F90 code.
>>
>> It's fine if autoconf recognizes that gfortran is compatible with both,
>> but we shouldn't have to force FC=$F77.
>>
>> I'm rebuilding from scratch at the moment after having removed FC=$F77.
>>   I just noticed there is a related modification earlier than the make
>> stage.  Inside the bootstrap is the following:
>>
>> bootstrap_epilogue ()
>> {
>>    ## G77 is obsolete, but it is still the first option in the autoconf
>>    ## Fortran macros.  We should avoid it, because mixing old versions of
>>    ## g77 with modern gcc and g++ causes trouble.  The following will
>>    ## make it harder (but not impossible) for users to make this mistake.
>>    ##
>>    ## FIXME -- we should really work to fix autoconf so that it prefers
>>    ## gfortran over g77 even when searching for a Fortran 77 compiler.
>>
>>    echo "replacing all occurrences of g77 with gfortran in configure
>> script..."
>>
>>    sed 's/g77/gfortran/g' configure>  configure.t
>>    mv configure.t configure
>>    chmod 755 configure
>> }
>>
>> Perhaps that workaround is out of date.  How does one tell what order
>> autoconf is using for compiler preference (I've grepped in the auto*
>> scripts and can't find anything)?  But more than that, isn't the
>> AC_PROG_F77 macro supposed to control this?
>>
>> http://www.hep.by/gnu/autoconf/Fortran-Compiler.html
>>
>> That is, if we want gfortran to have precedence, then we would define
>> (using the example at the above link)
>>
>>            AC_PROG_F77([gfortran fl32 f77 fort77 xlf g77 f90 xlf90])
>>
>> So, perhaps that is a better solution than using the stream editor to
>> replace g77.
>
> I think this is a fine idea.  Eliminate all the weird hacks with sed in
> favor of just listing our preference.
>
> And I'm not sure we want to rely on luck regarding a compiler that handles
> both F77 and F90.  I see several choices: 1) Change Jaroslav's code to be
> F77-compliant, 2) Change the extension on Jaroslav's files to .f90, but we
> would potentially then need to use the AC_PROG_FC macro and get that
> working to handle the F90 stuff with a different compiler, 3) Switch
> completely over to AC_PROG_FC, but this assumes that any compiler chosen
> will be able to compile both F77 and F90 code, 4) force use of gfortran.
>
>>
>> Anyway, compilation is complete without problems here.  What I see in the
>> Makefile is
>>
>> F77 = gfortran
>> ...
>> FC = @FC@
>>
>> What does the FC = @FC@ mean?
>
> In the final Makefile?  or Makefile.in or Makefile.am?  The pattern @VAR@
> is replaced by Autotools when it builds the Makefiles using values from the
> configure process.

The final Makefile.

[root@moorglade build1]# grep "FC = @" * -r
doc/interpreter/Makefile:FC = @FC@
doc/liboctave/Makefile:FC = @FC@
doc/doxyhtml/Makefile:FC = @FC@
doc/Makefile:FC = @FC@
doc/refcard/Makefile:FC = @FC@
etc/icons/Makefile:FC = @FC@
examples/code/Makefile:FC = @FC@
examples/Makefile:FC = @FC@
examples/data/Makefile:FC = @FC@
libgui/Makefile:FC = @FC@
libinterp/Makefile:FC = @FC@
liboctave/Makefile:FC = @FC@
Makefile:FC = @FC@
scripts/Makefile:FC = @FC@
src/Makefile:FC = @FC@
test/Makefile:FC = @FC@

I've placed AC_PROG_FC in my configure.ac file to see what happens.  I
don't see any kind of corresponding action to it anywhere.

... Oh, here's the list of FORTRAN compilers that AC checks for (it's
created inside the "configure" file as part of bootstrap):

## the F77 variable, if set, overrides AC_PROG_F77 automatically
ac_ext=f
ac_compile='$F77 -c $FFLAGS conftest.$ac_ext >&5'
ac_link='$F77 -o conftest$ac_exeext $FFLAGS $LDFLAGS conftest.$ac_ext
$LIBS >&5'
ac_compiler_gnu=$ac_cv_f77_compiler_gnu
if test -n "$ac_tool_prefix"; then
   for ac_prog in gfortran xlf f77 frt pgf77 cf77 fort77 fl32 af77 xlf90
f90 pgf90 pghpf epcf90 gfortran g95 xlf95 f95 fort ifort ifc efc
pgfortran pgf95 lf95 ftn
   do
     # Extract the first word of "$ac_tool_prefix$ac_prog", so it can be
a program name with args.
set dummy $ac_tool_prefix$ac_prog; ac_word=$2
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5
$as_echo_n "checking for $ac_word... " >&6; }
if test "${ac_cv_prog_F77+set}" = set; then :
   $as_echo_n "(cached) " >&6
else

I see gfortran as the preference (first in list) and don't even see g77
in the list.  I don't see "g77" in the Octave source tree anywhere other
than comments.  I think that epilogue code can be removed.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Mike Miller
In reply to this post by Rik-4
On Mon, Nov 24, 2014 at 12:28:21 -0800, Rik wrote:

> On 11/24/2014 11:33 AM, Daniel J Sebald wrote:
>> That is, if we want gfortran to have precedence, then we would define
>> (using the example at the above link)
>>
>>           AC_PROG_F77([gfortran fl32 f77 fort77 xlf g77 f90 xlf90])
>>
>> So, perhaps that is a better solution than using the stream editor to
>> replace g77.
>
> I think this is a fine idea.  Eliminate all the weird hacks with sed in
> favor of just listing our preference.

The main problem with listing our preferred compiler like this is that
it discards the curated list of supported compilers that Autoconf
gives us today. So from a portability point of view, we would be
throwing away the autodetection of xlf95, ifort, pgf95, etc, (just
picking some random examples) that we inherit from Autoconf.

There is no way (that I know of) to set our preferred compiler without
specifying the entire list of compilers to try, to put it another way.
Other than the bootstrap_epilogue function that we currently use.

> And I'm not sure we want to rely on luck regarding a compiler that handles
> both F77 and F90.  I see several choices: 1) Change Jaroslav's code to be
> F77-compliant, 2) Change the extension on Jaroslav's files to .f90, but we
> would potentially then need to use the AC_PROG_FC macro and get that
> working to handle the F90 stuff with a different compiler, 3) Switch
> completely over to AC_PROG_FC, but this assumes that any compiler chosen
> will be able to compile both F77 and F90 code, 4) force use of gfortran.

I have no idea how valid it is, but Autoconf's working assumption
seems to be that a F95 compiler will also support F90 and F77, and an
F90 compiler will also support F77.

For #3, we could do something like

  AC_PROG_FC
  AC_PROG_F77([$FC])

to both use the proper detection order we want from AC_PROG_FC and to
force $(F77) to refer to the same compiler.

I also like:

5) Stick with what we have today, compile all Fortran files with
$(F77) as if they were valid F77, and deal with problems in Jaroslav's
code if any bugs are ever encountered and reported.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Daniel Sebald
On 11/24/2014 02:52 PM, Mike Miller wrote:

> On Mon, Nov 24, 2014 at 12:28:21 -0800, Rik wrote:
>> On 11/24/2014 11:33 AM, Daniel J Sebald wrote:
>>> That is, if we want gfortran to have precedence, then we would define
>>> (using the example at the above link)
>>>
>>>            AC_PROG_F77([gfortran fl32 f77 fort77 xlf g77 f90 xlf90])
>>>
>>> So, perhaps that is a better solution than using the stream editor to
>>> replace g77.
>>
>> I think this is a fine idea.  Eliminate all the weird hacks with sed in
>> favor of just listing our preference.
>
> The main problem with listing our preferred compiler like this is that
> it discards the curated list of supported compilers that Autoconf
> gives us today. So from a portability point of view, we would be
> throwing away the autodetection of xlf95, ifort, pgf95, etc, (just
> picking some random examples) that we inherit from Autoconf.
>
> There is no way (that I know of) to set our preferred compiler without
> specifying the entire list of compilers to try, to put it another way.
> Other than the bootstrap_epilogue function that we currently use.

That's correct.  But I just found out how to view what AC's preferred
list is.  gfortran is now at the front of the list.  The fact that g77
isn't even in their list, I think means that we don't even have to worry
about any problem that the stream-editor epilogue script was attempting
to solve.  That is, the comment

   ## FIXME -- we should really work to fix autoconf so that it prefers
   ## gfortran over g77 even when searching for a Fortran 77 compiler.

has been implemented apparently.


>> And I'm not sure we want to rely on luck regarding a compiler that handles
>> both F77 and F90.  I see several choices: 1) Change Jaroslav's code to be
>> F77-compliant, 2) Change the extension on Jaroslav's files to .f90, but we
>> would potentially then need to use the AC_PROG_FC macro and get that
>> working to handle the F90 stuff with a different compiler, 3) Switch
>> completely over to AC_PROG_FC, but this assumes that any compiler chosen
>> will be able to compile both F77 and F90 code, 4) force use of gfortran.
>
> I have no idea how valid it is, but Autoconf's working assumption
> seems to be that a F95 compiler will also support F90 and F77, and an
> F90 compiler will also support F77.

FORTRAN compatibility I don't know about.  I know that C has remained
backward compatible, even going to C++.


> 5) Stick with what we have today, compile all Fortran files with
> $(F77) as if they were valid F77, and deal with problems in Jaroslav's
> code if any bugs are ever encountered and reported.

I think fixing bugs as we encounter is fine, whatever the configuration.
  There can't be that many.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Mike Miller
On Mon, Nov 24, 2014 at 15:02:16 -0600, Daniel J Sebald wrote:

> That's correct.  But I just found out how to view what AC's preferred list
> is.  gfortran is now at the front of the list.  The fact that g77 isn't even
> in their list, I think means that we don't even have to worry about any
> problem that the stream-editor epilogue script was attempting to solve.
> That is, the comment
>
>   ## FIXME -- we should really work to fix autoconf so that it prefers
>   ## gfortran over g77 even when searching for a Fortran 77 compiler.
>
> has been implemented apparently.

I do not believe that is correct. The list you are looking at has
already been run through the bootstrap_epilogue function.

Do feel free to try deleting that function and run ./bootstrap again
and prove me wrong :)

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

Daniel Sebald
On 11/24/2014 03:06 PM, Mike Miller wrote:

> On Mon, Nov 24, 2014 at 15:02:16 -0600, Daniel J Sebald wrote:
>> That's correct.  But I just found out how to view what AC's preferred list
>> is.  gfortran is now at the front of the list.  The fact that g77 isn't even
>> in their list, I think means that we don't even have to worry about any
>> problem that the stream-editor epilogue script was attempting to solve.
>> That is, the comment
>>
>>    ## FIXME -- we should really work to fix autoconf so that it prefers
>>    ## gfortran over g77 even when searching for a Fortran 77 compiler.
>>
>> has been implemented apparently.
>
> I do not believe that is correct. The list you are looking at has
> already been run through the bootstrap_epilogue function.
>
> Do feel free to try deleting that function and run ./bootstrap again
> and prove me wrong :)

Ah, good point.  I just noticed two "gfortran"s in the list, so
something is funny.  Let me try...

Yes, so g77 comes up first.  I take it from the epilogue comment that
the issue isn't compile errors, but the compiled code will malfunction.
  So "fixing compile errors" isn't a good strategy in that case.

Now that I understand the autotools a little more, I don't see the
epilogue as much of an issue.  Someone can always set F77 environment
variable to g77 if that is wanted.

So where were we?  If we simply remove FC=$F77, then worry about compile
errors?

Dan

Reply | Threaded
Open this post in threaded view
|

Re: F77 vs. F90 in Octave

John W. Eaton
Administrator
In reply to this post by Mike Miller
On 11/24/2014 03:52 PM, Mike Miller wrote:

> I also like:
>
> 5) Stick with what we have today, compile all Fortran files with
> $(F77) as if they were valid F77, and deal with problems in Jaroslav's
> code if any bugs are ever encountered and reported.

Yes, this seems reasonable to me.

As I recall, the reason for editing the list during bootstrap is to
avoid using g77 on systems that still have it installed, but for which
system libraries like lapack have been compiled with gfortran.  Cases
like that lead to linking problems, or mixing of calling conventions for
some functions (complex arguments/return values, I think).

I agree with Mike that specifying our own list is the wrong thing to do.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Default F77 is g77

Rik-4
In reply to this post by Daniel Sebald
On 11/24/2014 01:02 PM, Daniel J Sebald wrote:

> On 11/24/2014 02:52 PM, Mike Miller wrote:
>> On Mon, Nov 24, 2014 at 12:28:21 -0800, Rik wrote:
>>> On 11/24/2014 11:33 AM, Daniel J Sebald wrote:
>>>> That is, if we want gfortran to have precedence, then we would define
>>>> (using the example at the above link)
>>>>
>>>>            AC_PROG_F77([gfortran fl32 f77 fort77 xlf g77 f90 xlf90])
>>>>
>>>> So, perhaps that is a better solution than using the stream editor to
>>>> replace g77.
>>>
>>> I think this is a fine idea.  Eliminate all the weird hacks with sed in
>>> favor of just listing our preference.
>>
>> The main problem with listing our preferred compiler like this is that
>> it discards the curated list of supported compilers that Autoconf
>> gives us today. So from a portability point of view, we would be
>> throwing away the autodetection of xlf95, ifort, pgf95, etc, (just
>> picking some random examples) that we inherit from Autoconf.
>>
>> There is no way (that I know of) to set our preferred compiler without
>> specifying the entire list of compilers to try, to put it another way.
>> Other than the bootstrap_epilogue function that we currently use.
>
> That's correct.  But I just found out how to view what AC's preferred
> list is.  gfortran is now at the front of the list.  The fact that g77
> isn't even in their list, I think means that we don't even have to worry
> about any problem that the stream-editor epilogue script was attempting
> to solve.  That is, the comment
>
>   ## FIXME -- we should really work to fix autoconf so that it prefers
>   ## gfortran over g77 even when searching for a Fortran 77 compiler.
>
> has been implemented apparently.

I don't think that's true, at least not for my installation which is only 2
years old (Ubuntu 12.04).  The following is from
/usr/share/autoconf/autoconf/fortran.m4:

# _AC_PROG_FC([DIALECT], [COMPILERS...])
# --------------------------------------
# DIALECT is a Fortran dialect, given by Fortran [YY]YY or simply [YY]YY,
# and must be one of those supported by _AC_FC_DIALECT_YEAR
#
# If DIALECT is supplied, then we search for compilers of that dialect
# first, and then later dialects.  Otherwise, we search for compilers
# of the newest dialect first, and then earlier dialects in increasing age.
# This search order is necessarily imperfect because the dialect cannot
# always be inferred from the compiler name.
#
# Known compilers:
#  f77/f90/f95: generic compiler names
#  g77: GNU Fortran 77 compiler
#  gfortran: GNU Fortran 95+ compiler (released in gcc 4.0)
#  g95: original gcc-based f95 compiler (gfortran is a fork)
#  ftn: native Fortran 95 compiler on Cray X1
#  cf77: native F77 compiler under older Crays (prefer over fort77)
#  fort77: native F77 compiler under HP-UX (and some older Crays)
#  frt: Fujitsu F77 compiler
#  pgf77/pgf90/pghpf/pgf95/pgfortran: Portland Group F77/F90/F95 compilers
#  xlf/xlf90/xlf95: IBM (AIX) F77/F90/F95 compilers
#    Prefer xlf9x to the generic names because they do not reject files
#    with extension `.f'.
#  lf95: Lahey-Fujitsu F95 compiler
#  fl32: Microsoft Fortran 77 "PowerStation" compiler
#  af77: Apogee F77 compiler for Intergraph hardware running CLIX
#  epcf90: "Edinburgh Portable Compiler" F90
#  fort: Compaq (now HP) Fortran 90/95 compiler for Tru64 and Linux/Alpha
#  ifort, previously ifc: Intel Fortran 95 compiler for Linux/x86
#  efc: Intel Fortran 95 compiler for IA64
m4_define([_AC_F95_FC], [gfortran g95 xlf95 f95 fort ifort ifc efc
pgfortran pgf95 lf95 ftn])
m4_define([_AC_F90_FC], [xlf90 f90 pgf90 pghpf epcf90])
m4_define([_AC_F77_FC], [g77 xlf f77 frt pgf77 cf77 fort77 fl32 af77])
AC_DEFUN([_AC_PROG_FC],
[_AC_FORTRAN_ASSERT()dnl
AC_CHECK_TOOLS([]_AC_FC[],
      m4_default([$2],
    m4_case(_AC_FC_DIALECT_YEAR([$1]),
        [1995], [_AC_F95_FC],
        [1990], [_AC_F90_FC _AC_F95_FC],
        [1977], [_AC_F77_FC _AC_F90_FC _AC_F95_FC],
        [_AC_F95_FC _AC_F90_FC _AC_F77_FC])))

The default for the list _AC_F77_FC which begins with g77.  gfortran is
only added in later via _AC_F95_FC.  I checked this by symlinking g77 to
gfortran and then re-running configure and it picks up g77 now instead of
gfortran.

Interestingly, this is the entire list of known compilers so we could
simply put this list in as the preference to AC_PROG_F77 with gfortran at
the start like so:

AC_PROG_F77([gfortran g77 xlf f77 frt pgf77 cf77 fort77 fl32 af77 xlf90 f90
pgf90 pghpf epcf90 g95 xlf95 f95 fort ifort ifc efc pgfortran pgf95 lf95 ftn])

I did this and it now picks up gfortran even with g77 symlinked in /usr/bin.

--Rik


Reply | Threaded
Open this post in threaded view
|

Re: Default F77 is g77

John W. Eaton
Administrator
On 11/24/2014 04:54 PM, Rik wrote:

> On 11/24/2014 01:02 PM, Daniel J Sebald wrote:
>> On 11/24/2014 02:52 PM, Mike Miller wrote:
>>> On Mon, Nov 24, 2014 at 12:28:21 -0800, Rik wrote:
>>>> On 11/24/2014 11:33 AM, Daniel J Sebald wrote:
>>>>> That is, if we want gfortran to have precedence, then we would define
>>>>> (using the example at the above link)
>>>>>
>>>>>             AC_PROG_F77([gfortran fl32 f77 fort77 xlf g77 f90 xlf90])
>>>>>
>>>>> So, perhaps that is a better solution than using the stream editor to
>>>>> replace g77.
>>>>
>>>> I think this is a fine idea.  Eliminate all the weird hacks with sed in
>>>> favor of just listing our preference.
>>>
>>> The main problem with listing our preferred compiler like this is that
>>> it discards the curated list of supported compilers that Autoconf
>>> gives us today. So from a portability point of view, we would be
>>> throwing away the autodetection of xlf95, ifort, pgf95, etc, (just
>>> picking some random examples) that we inherit from Autoconf.
>>>
>>> There is no way (that I know of) to set our preferred compiler without
>>> specifying the entire list of compilers to try, to put it another way.
>>> Other than the bootstrap_epilogue function that we currently use.
>>
>> That's correct.  But I just found out how to view what AC's preferred
>> list is.  gfortran is now at the front of the list.  The fact that g77
>> isn't even in their list, I think means that we don't even have to worry
>> about any problem that the stream-editor epilogue script was attempting
>> to solve.  That is, the comment
>>
>>    ## FIXME -- we should really work to fix autoconf so that it prefers
>>    ## gfortran over g77 even when searching for a Fortran 77 compiler.
>>
>> has been implemented apparently.
>
> I don't think that's true, at least not for my installation which is only 2
> years old (Ubuntu 12.04).  The following is from
> /usr/share/autoconf/autoconf/fortran.m4:
>
> # _AC_PROG_FC([DIALECT], [COMPILERS...])
> # --------------------------------------
> # DIALECT is a Fortran dialect, given by Fortran [YY]YY or simply [YY]YY,
> # and must be one of those supported by _AC_FC_DIALECT_YEAR
> #
> # If DIALECT is supplied, then we search for compilers of that dialect
> # first, and then later dialects.  Otherwise, we search for compilers
> # of the newest dialect first, and then earlier dialects in increasing age.
> # This search order is necessarily imperfect because the dialect cannot
> # always be inferred from the compiler name.
> #
> # Known compilers:
> #  f77/f90/f95: generic compiler names
> #  g77: GNU Fortran 77 compiler
> #  gfortran: GNU Fortran 95+ compiler (released in gcc 4.0)
> #  g95: original gcc-based f95 compiler (gfortran is a fork)
> #  ftn: native Fortran 95 compiler on Cray X1
> #  cf77: native F77 compiler under older Crays (prefer over fort77)
> #  fort77: native F77 compiler under HP-UX (and some older Crays)
> #  frt: Fujitsu F77 compiler
> #  pgf77/pgf90/pghpf/pgf95/pgfortran: Portland Group F77/F90/F95 compilers
> #  xlf/xlf90/xlf95: IBM (AIX) F77/F90/F95 compilers
> #    Prefer xlf9x to the generic names because they do not reject files
> #    with extension `.f'.
> #  lf95: Lahey-Fujitsu F95 compiler
> #  fl32: Microsoft Fortran 77 "PowerStation" compiler
> #  af77: Apogee F77 compiler for Intergraph hardware running CLIX
> #  epcf90: "Edinburgh Portable Compiler" F90
> #  fort: Compaq (now HP) Fortran 90/95 compiler for Tru64 and Linux/Alpha
> #  ifort, previously ifc: Intel Fortran 95 compiler for Linux/x86
> #  efc: Intel Fortran 95 compiler for IA64
> m4_define([_AC_F95_FC], [gfortran g95 xlf95 f95 fort ifort ifc efc
> pgfortran pgf95 lf95 ftn])
> m4_define([_AC_F90_FC], [xlf90 f90 pgf90 pghpf epcf90])
> m4_define([_AC_F77_FC], [g77 xlf f77 frt pgf77 cf77 fort77 fl32 af77])
> AC_DEFUN([_AC_PROG_FC],
> [_AC_FORTRAN_ASSERT()dnl
> AC_CHECK_TOOLS([]_AC_FC[],
>        m4_default([$2],
>      m4_case(_AC_FC_DIALECT_YEAR([$1]),
>          [1995], [_AC_F95_FC],
>          [1990], [_AC_F90_FC _AC_F95_FC],
>          [1977], [_AC_F77_FC _AC_F90_FC _AC_F95_FC],
>          [_AC_F95_FC _AC_F90_FC _AC_F77_FC])))
>
> The default for the list _AC_F77_FC which begins with g77.  gfortran is
> only added in later via _AC_F95_FC.  I checked this by symlinking g77 to
> gfortran and then re-running configure and it picks up g77 now instead of
> gfortran.
>
> Interestingly, this is the entire list of known compilers so we could
> simply put this list in as the preference to AC_PROG_F77 with gfortran at
> the start like so:
>
> AC_PROG_F77([gfortran g77 xlf f77 frt pgf77 cf77 fort77 fl32 af77 xlf90 f90
> pgf90 pghpf epcf90 g95 xlf95 f95 fort ifort ifc efc pgfortran pgf95 lf95 ftn])
>
> I did this and it now picks up gfortran even with g77 symlinked in /usr/bin.
>
> --Rik
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Default F77 is g77

John W. Eaton
Administrator
In reply to this post by Rik-4
On 11/24/2014 04:54 PM, Rik wrote:

> Interestingly, this is the entire list of known compilers so we could
> simply put this list in as the preference to AC_PROG_F77 with gfortran at
> the start like so:
>
> AC_PROG_F77([gfortran g77 xlf f77 frt pgf77 cf77 fort77 fl32 af77 xlf90 f90
> pgf90 pghpf epcf90 g95 xlf95 f95 fort ifort ifc efc pgfortran pgf95 lf95 ftn])
>
> I did this and it now picks up gfortran even with g77 symlinked in /usr/bin.

I don't like this solution for the reasons that Mike Miller already stated.

Also, leaving g77 in the list has the problem of screwing things up if a
system happens to have an old copy of g77 installed but no gfortran.  As
far as I know, there are no versions of g77 that will work with modern
versions of gcc and g++.  Since we rely on linking Fortran and C++ code
together, we must have a consistent set of compilers and g77 will never
work properly for us.  So we might as well simply avoid it by replacing
instances of g77 in the configure script with gfortran.  That solution
seems to be working for us, so I don't see a reason to change it.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Default F77 is g77

Rik-4
On 11/24/2014 02:00 PM, John W. Eaton wrote:
> On 11/24/2014 04:54 PM, Rik wrote:
>
>> Interestingly, this is the entire list of known compilers so we could
>> simply put this list in as the preference to AC_PROG_F77 with gfortran at
>> the start like so:
>>
>> AC_PROG_F77([gfortran g77 xlf f77 frt pgf77 cf77 fort77 fl32 af77 xlf90 f90
>> pgf90 pghpf epcf90 g95 xlf95 f95 fort ifort ifc efc pgfortran pgf95 lf95 ftn])
>>
>> I did this and it now picks up gfortran even with g77 symlinked in /usr/bin.
>
> I don't like this solution for the reasons that Mike Miller already stated.
>
> Also, leaving g77 in the list has the problem of screwing things up if a system happens to have an old copy of g77 installed but no gfortran.  As far as I know, there are no versions of g77 that will work with modern versions of gcc and g++.  Since we rely on linking Fortran and C++ code together, we must have a consistent set of compilers and g77 will never work properly for us.  So we might as well simply avoid it by replacing instances of g77 in the configure script with gfortran.  That solution seems to be working for us, so I don't see a reason to change it.
>


I understand not fixing what isn't broken, but there is also futureproofing.  Using sed on the generated configure feels like a fragile solution that may break as things change in the future.  I think putting in the full list of compilers is also a hack, just slightly less fragile, as I don't see many new Fortran compilers being written.

Another alternative I like is to error out with a message about the problems with g77 if it is selected, rather than substituting gfortran without the user's permission.  In pseudocode,

AC_PROG_F77
if "$F77" = g77; then
  AC_MSG_ERROR([Detected Fortran compiler g77 which does not produce objects that can be linked with BLAS and LAPACK libraries.  Choose a different compiler by setting the environment variable F77 and re-running configure.]
fi

--Rik

Reply | Threaded
Open this post in threaded view
|

Re: Default F77 is g77

Daniel Sebald
On 11/24/2014 04:27 PM, Rik wrote:

> On 11/24/2014 02:00 PM, John W. Eaton wrote:
>>  On 11/24/2014 04:54 PM, Rik wrote:
>>
>> > Interestingly, this is the entire list of known compilers so we could
>> > simply put this list in as the preference to AC_PROG_F77 with gfortran at
>> > the start like so:
>> >
>> > AC_PROG_F77([gfortran g77 xlf f77 frt pgf77 cf77 fort77 fl32 af77
> xlf90 f90
>> > pgf90 pghpf epcf90 g95 xlf95 f95 fort ifort ifc efc pgfortran pgf95
> lf95 ftn])
>> >
>> > I did this and it now picks up gfortran even with g77 symlinked in
> /usr/bin.
>>
>>  I don't like this solution for the reasons that Mike Miller already
> stated.
>>
>>  Also, leaving g77 in the list has the problem of screwing things up if
> a system happens to have an old copy of g77 installed but no gfortran.
> As far as I know, there are no versions of g77 that will work with
> modern versions of gcc and g++.  Since we rely on linking Fortran and
> C++ code together, we must have a consistent set of compilers and g77
> will never work properly for us.  So we might as well simply avoid it by
> replacing instances of g77 in the configure script with gfortran.  That
> solution seems to be working for us, so I don't see a reason to change it.
>>
>
> I understand not fixing what isn't broken, but there is also
> futureproofing.  Using sed on the generated configure feels like a
> fragile solution that may break as things change in the future.  I think
> putting in the full list of compilers is also a hack, just slightly less
> fragile, as I don't see many new Fortran compilers being written.
>
> Another alternative I like is to error out with a message about the
> problems with g77 if it is selected, rather than substituting gfortran
> without the user's permission.  In pseudocode,
>
> AC_PROG_F77
> if "$F77" = g77; then
>    AC_MSG_ERROR([Detected Fortran compiler g77 which does not produce
> objects that can be linked with BLAS and LAPACK libraries.  Choose a
> different compiler by setting the environment variable F77 and
> re-running configure.]
> fi
>
> --Rik

I was going to suggest another variation on the theme would be to
replace "g77" by "" in the bootstrap file.  That way, the precedence is
maintained.  On my system, "gfortran" still ends up being chosen after
AC goes through all the rest and finding none of them.

You do have a point, that sed is required.  But it's required in so many
other places as well.

I understand "g77" doesn't work, but if one of the reasons for replacing
"g77" with "gfortran" is so that "gfortran" is at the front of the list
and we really primarily only want to use "gfortran", then maybe

AC_PROG_F77([gfortran coupleothers])

works.  The advantage of doing that is then "g77" and "gfortran" can
both be present while the user doesn't have to specify F77 environment
variable.

Dan