This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Buggy ssereg float function return on amd64
- From: Tobias Burnus <burnus at net-b dot de>
- To: "Kevin B. McCarty" <kmccarty at debian dot org>
- Cc: debian-toolchain at lists dot debian dot org, fortran at gcc dot gnu dot org, doko at cs dot tu-berlin dot de, bartoldeman at users dot sourceforge dot net, kamaraju at bluebottle dot com, camm at enhanced dot com
- Date: Wed, 19 Dec 2007 20:05:21 +0100
- Subject: Re: Buggy ssereg float function return on amd64
- References: <474DA3DE.6030509@net-b.de> <476037E6.4030508@debian.org>
Hi Kevin,
Kevin B. McCarty wrote:
> you wrote (sort of as an aside to the main point
>> I start with a comment to:
>> http://wiki.debian.org/GfortranTransition
>> "getarg and some other g77 specific functions have been removed from
>> gfortran."
>>
>> This is not the case. See:
>> http://gcc.gnu.org/onlinedocs/gfortran/GETARG.html
>>
>> My guess would be that the program contained an
>> EXTERNAL GETARG
>> which instructs gfortran to regard GETARG a user-supplied function.
>> Simply removing the EXTERNAL line or using
>> INTRINSIC GETARG
>> should work.
>>
>
> Actually, the case in which this is a significant issue is *C or C++*
> code trying to call FORTRAN's GETARG. Since libgfortran now has several
> versions of getarg (the symbols in the library are named things like
> _gfortran_getarg_i4), it is no longer possible for C/C++ code to access
> that function via the old usual method of adding an underscore to the
> FORTRAN function name, i.e. getarg_().
>
> Is it not possible to include a default version of getarg_ in
> libgfortran that is just an alias to _gfortran_getarg_i4 ? There might
> be similar issues for other libgfortran functions, I don't personally know.
>
The problem with having "xxx_" symbols in the libgfortran file is that
this potentially clashes with user functions such as especially for
"gamma_" vs. _gfortran_gamma*.
Besides, I still do not quite understand why it should be needed. If I
understood the problem correctly, only MPICH is affected. Why do you not
use a patch like the attached one, which seems to work for other
vendors. Or do I miss something else? (I do not know MPICH that well, I
use OpenMPI.)
Tobias
PS: Attached patch comes from mpich-1.2.7p1-125.src.rpm of openSUSE Factory.
ftp://ftp.gwdg.de/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/src/mpich-1.2.7p1-125.src.rpm
In the SPEC file one finds:
%if %{gnu}
%define c_compiler gcc
%define compiler_path /usr/bin
%define setenvs export FC=gfortran; export F77_GETARGDECL="intrinsic
GETARG"
%define fopts %{nil}
%define extralibs %{nil}
%define extraldopts %{nil}
%endif
--- mpe/aclocal_f77.m4.orig 2006-01-24 13:09:59.000000000 +0100
+++ mpe/aclocal_f77.m4 2006-01-24 14:08:55.000000000 +0100
@@ -348,10 +348,10 @@
dnl will catch most systems and will speed up the tests.
dnl
dnl Next, the libraries are only added if they are needed to complete a
-dnl link; they aren't added just because they exist.
+dnl link; they aren''t added just because they exist.
dnl
dnl f77argdef
-dnlD*/
+dnl D*/
dnl
dnl Random notes
dnl You can export the command line arguments from C to the g77 compiler
@@ -396,9 +396,10 @@
if test -z "$ac_fcompilelink" ; then
ac_fcompilelink="${F77-f77} -o conftest $FFLAGS $flags conftest.f $LDFLAGS $LIBS 1>&AC_FD_CC"
fi
- AC_MSG_CHECKING([if ${F77-f77} $flags $libs works with GETARG and IARGC])
+ AC_MSG_CHECKING([whether ${F77-f77} $flags $libs works with GETARG and IARGC])
if AC_TRY_EVAL(ac_fcompilelink) && test -x conftest ; then
- if test "$ac_cv_prog_f77_cross" = "no" ; then
+ # Check that cross != yes so that this works with autoconf 2.52
+ if test "$ac_cv_prog_f77_cross" != "yes" ; then
if ./conftest >/dev/null 2>&1 ; then
found_answer="yes"
FXX_MODULE="$fxx_module"
@@ -492,7 +493,7 @@
+U77"
fi
# Discard options that are not available:
- save_IFS="$IFS"
+ # (IFS already saved above)
IFS="
"
save_trial_FLAGS="$trial_FLAGS"
@@ -518,7 +519,7 @@
end
EOF
if test -n "$fflag" ; then flagval="with $fflag" ; else flagval="" ; fi
- AC_MSG_CHECKING([that Fortran 77 routine names are case-insensitive $flagval])
+ AC_MSG_CHECKING([whether Fortran 77 routine names are case-insensitive $flagval])
dnl we can use double quotes here because all is already
dnl evaluated
ac_fcompilelink_test="${F77-f77} -o conftest $fflag $FFLAGS conftest.f $LDFLAGS $LIBS 1>&AC_FD_CC"
@@ -594,6 +595,13 @@
continue
fi
;;
+ 7) # gfortran won't find getarg if it is marked as external
+ FXX_MODULE=""
+ F77_GETARGDECL="intrinsic GETARG"
+ F77_GETARG="call GETARG(i,s)"
+ F77_IARGC="IARGC()"
+ MSG="intrinsic GETARG and IARGC"
+ ;;
*) # exit from while loop
FXX_MODULE=""
F77_GETARGDECL=""
@@ -631,13 +639,13 @@
if test "$libs" = " " -o "$libs" = "0" ; then libs="" ; fi
for flags in $trial_FLAGS ; do
if test "$flags" = " " -o "$flags" = "000"; then flags="" ; fi
- AC_MSG_CHECKING([if ${F77-f77} $flags $libs works with $MSG])
+ AC_MSG_CHECKING([whether ${F77-f77} $flags $libs works with $MSG])
IFS="$save_IFS"
dnl We need this here because we've fiddled with IFS
ac_fcompilelink_test="${F77-f77} -o conftest $FFLAGS $flags conftest.f $LDFLAGS $libs $LIBS 1>&AC_FD_CC"
found_answer="no"
if AC_TRY_EVAL(ac_fcompilelink_test) && test -x conftest ; then
- if test "$ac_cv_prog_f77_cross" = "no" ; then
+ if test "$ac_cv_prog_f77_cross" != "yes" ; then
if ./conftest >/dev/null 2>&1 ; then
found_answer="yes"
fi