A function returning a COMPLEX value cannot be compiled in g77 and called from gfortran (or vice versa) - doing so results in a segfault or incorrect results. (See test case below.) This is a problem, since for the near future g77 and gfortran are likely to coexist on many systems, and incompatible calling conventions for F77 code means that libraries like the BLAS will have to be provided in two flavors (g77 and gfortran) on the same system, a major headache for users (not to mention distributors). Note that COMPLEX argument passing seems to be okay (the below test case works fine if it is switched from a function into a subroutine). Environment: System: Linux fftw.org 2.6.3-1-686-smp #2 SMP Tue Feb 24 20:29:08 EST 2004 i686 GNU/Linux Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../configure --prefix=/home/stevenj/gcc4 --enable-languages=c,f95 How-To-Repeat: Create two files, arg1.f and arg1tst.f, consisting of: arg1.f: complex function arg1(x, y) complex x, y arg1 = x + y return end arg1tst.f: program arg1tst complex x,y,z, arg1 x = cmplx(1.,2.) y = cmplx(3.,4.) z = arg1(x,y) write(*,*) z end Compile arg1.f with g77 (I'm using version 3.3.5): g77 -c arg1.f Compile arg1tst.f with gfortran, and link with arg1.o from above: gfortran arg1tst.f arg1.o -o arg1tst Run ./arg1tst, and the result on my system is: Segmentation fault Expected output is: ( 4.000000 , 6.000000 )
Yes we know about this and it will not be fixed.
Have 'we' ever agreed not to fix this? I would be interested in the rationale given at that time. The issue Steven raises is important, even if there are only four functions returning COMPLEX in BLAS: cdotc, cdotu, zdotc, and zdotu Reopened until agreement is reached.
g77's documentation of the calling convention: `-fno-f2c' Do not generate code designed to be compatible with code generated by `f2c' use the GNU calling conventions instead. The `f2c' calling conventions require functions that return type `REAL(KIND=1)' to actually return the C type `double', and functions that return type `COMPLEX' to return the values via an extra argument in the calling sequence that points to where to store the return value. Under the GNU calling conventions, such functions simply return their results as they would in GNU C--`REAL(KIND=1)' functions return the C type `float', and `COMPLEX' functions return the GNU C type `complex' (or its `struct' equivalent). This does not affect the generation of code that interfaces with the `libg2c' library. However, because the `libg2c' library uses `f2c' calling conventions, `g77' rejects attempts to pass intrinsics implemented by routines in this library as actual arguments when `-fno-f2c' is used, to avoid bugs when they are actually called by code expecting the GNU calling conventions to work. For example, `INTRINSIC ABS;CALL FOO(ABS)' is rejected when `-fno-f2c' is in force. (Future versions of the `g77' run-time library might offer routines that provide GNU-callable versions of the routines that implement the `f2c' intrinsics that may be passed as actual arguments, so that valid programs need not be rejected when `-fno-f2c' is used.) *Caution:* If `-fno-f2c' is used when compiling any source file used in a program, it must be used when compiling _all_ Fortran source files used in that program.
Subject: Re: COMPLEX function returns incompatible with g77 I confirm that it works when you compile arg1.f with -fno-f2c: g77 -fno-f2c -c arg1.f gfortran arg1tst.f arg1.o -o arg1tst ./arg1tst ( 4.000000 , 6.000000 ) However, this doesn't really alter the basic question of why you are changing the default calling conventions.
(In reply to comment #4) > However, this doesn't really alter the basic question of why you are > changing the default calling conventions. Well chaning to be more target's C like (because that is what gfortran uses now) ABI.
And gfortran is totally new front-end, written from scratch.
(In reply to comment #4) > However, this doesn't really alter the basic question of why you are > changing the default calling conventions. You could call it an oversight. The -fno-f2c calling convention is handled by the compiler automatically (set function type to complex, and it will do the right thing), and nobody ever tried interoperability of this feature with g77.
Subject: Re: COMPLEX function returns incompatible with g77 On Wed, 23 Feb 2005, pinskia at gcc dot gnu dot org wrote: > Well chaning to be more target's C like (because that is what gfortran > uses now) ABI. If you're breaking backwards ABI compatibility anyway, which does not seem like a decision to take lightly, clean up everything at once. e.g. you want to get rid of f2c cruft, why not make -fno-second-underscore the default as well? (Despite the gcc manual's claims, no non-GNU compilers that I know of append 2 underscores to external names with underscores, at least any more. Almost all of them, e.g. SGI, Intel ifc, Portland, Tru64, ..., append a single underscore in all cases. IBM xlf and HP/UX append no underscores at all.)
Subject: Re: COMPLEX function returns incompatible with g77 On Wed, 23 Feb 2005, pinskia at gcc dot gnu dot org wrote: > And gfortran is totally new front-end, written from scratch. Obviously. That doesn't mean that the rest of the world ceases to exist.
Upgraded to normal severity, interoperability with g77 is important.
Working on this.
BTW I will also propose a patch to make -fno-second-underscore the default, once this is fixed.
Subject: Re: COMPLEX function returns incompatible with g77 On Thu, 3 Mar 2005, tobi at gcc dot gnu dot org wrote: > BTW I will also propose a patch to make -fno-second-underscore the > default, once this is fixed. I'm confused...shouldn't it be one or the other? i.e. either make -ff2c -fsecond-underscore the default, compatible with g77, *or* make -fno-f2c -fno-second-underscore the default, incompatible with g77 but free of f2c cruft. I would vote for the former, simply because compatibility with g77 by default has huge practical advantages for library distributors that seem (to me) to outweigh the aesthetic benefits of removing f2c cruft. (Making -fno-second-underscore the default does have the non-aesthetic practical advantage of better compatibility with non-GNU compilers, but the GNU project has traditionally placed a higher priority on compatibility with free software than with non-free software.) Steven
I agree with you that -ff2c should imply -fsecond-underscore. I don't agree that the advantages of -ff2c outweigh the disadvantages of -fno-f2c so far that -fno-f2c should be the default. If we don't switch to -fno-f2c as default now, it will never happen in the foreseeable future. One practical problem with gfortran and -ff2c is the following: gfortran's library uses the -fno-f2c calling convention, so using -ff2c with my patch so-far will break use of complex functions as actual arguments. The restriction from the quote from g77's documentation applies the exactly opposite way. I haven't yet looked into how much of an effort fixing this would be.
Subject: Re: COMPLEX function returns incompatible with g77 On Thu, 3 Mar 2005, tobi at gcc dot gnu dot org wrote: > I agree with you that -ff2c should imply -fsecond-underscore. I don't > agree that the advantages of -ff2c outweigh the disadvantages of > -fno-f2c so far that -fno-f2c should be the default. Just to be clear, what exactly do you feel are the concrete practical advantages to -ff2c?
Subject: Re: COMPLEX function returns incompatible with g77 > Just to be clear, what exactly do you feel are the concrete practical > advantages to -ff2c? (Sorry, I mean -fno-f2c. The practical advantages to backwards compatibility are obvious.)
- a simpler compiler - simpler interfacing with C code - less excess precision problems with floating point returns (REAL*4 returns are not returned as REAL*8) - faster executables - we'll never get this if we don't do it now But if you really like the default the other way round, I'd suggest: - you implement the necessary changes to the library :-) - we discuss this on the mailing list once I submit the patch, so that other people can weigh in as well. I hope to get there today, I have finished the COMPLEX part, and I don't think the REAL part will be difficult.
BTW, most (if not all) of the affected functions in BLAS / LAPACK are auxiliary functions, i.e. are only called from within those libraries. Changing the interface will only affect functions called from the outside, so compatibility issues might not be so bad. But as I said, a discussion of this should take place on the mailing list.
Patch here: http://gcc.gnu.org/ml/fortran/2005-03/msg00060.html
Subject: Bug 20178 CVSROOT: /cvs/gcc Module name: gcc Changes by: tobi@gcc.gnu.org 2005-05-10 22:06:55 Modified files: gcc/fortran : ChangeLog gfortran.h invoke.texi lang.opt options.c trans-decl.c trans-expr.c trans-types.c gcc/testsuite : ChangeLog libgfortran : ChangeLog Makefile.am Makefile.in aclocal.m4 Added files: gcc/testsuite/gfortran.dg: f2c_1.f90 f2c_2.f90 f2c_3.f90 libgfortran/intrinsics: f2c_specifics.F90 Log message: gcc/fortran/ PR fortran/20178 * gfortran.h (gfc_option): Add flag_f2c. * invoke.texi: Document '-ff2c' command line option. Adapt documentation for '-fno-second-underscore' and '-fno-underscoring'. * lang.opt (ff2c): New entry. * options.c (gfc-init_options): Set default calling convention to -fno-f2c. Mark -fsecond-underscore unset. (gfc_post_options): Set -fsecond-underscore if not explicitly set by user. (handle_options): Set gfc_option.flag_f2c according to requested calling convention. * trans-decl.c (gfc_get_extern_function_decl): Use special f2c intrinsics where necessary. (gfc_trans_deferred_vars): Change todo error to assertion. * trans-expr.c (gfc_conv_variable): Dereference access to hidden result argument. (gfc_conv_function_call): Add hidden result argument to argument list if f2c calling conventions requested. Slightly restructure tests. Convert result of default REAL function to requested type if f2c calling conventions are used. Dereference COMPLEX result if f2c cc are used. * trans-types.c (gfc_sym_type): Return double for default REAL function if f2c cc are used. (gfc_return_by_reference): Slightly restructure logic. Return COMPLEX by reference depending on calling conventions. (gfc_get_function_type): Correctly make hidden result argument a pass-by-reference argument for COMPLEX. Remove old code which does this for derived types. libgfortran/ PR fortran/20178 * Makefile.am (gfor_specific_src): Add 'intrinsics/f2c_intrinsics.F90' to dependencies. * Makefile.in: Regenerate. * intrinsics/f2c_specific.F90: New file. gcc/testsuite/ PR fortran/20178 * gfortran.dg/f2c_1.f90, gfortran.dg/f2c_2.f90, gfortran.dg/f2c_3.f90: New tests. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.418&r2=1.419 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/gfortran.h.diff?cvsroot=gcc&r1=1.68&r2=1.69 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/invoke.texi.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/lang.opt.diff?cvsroot=gcc&r1=1.11&r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/options.c.diff?cvsroot=gcc&r1=1.18&r2=1.19 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-decl.c.diff?cvsroot=gcc&r1=1.57&r2=1.58 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.42&r2=1.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-types.c.diff?cvsroot=gcc&r1=1.41&r2=1.42 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5459&r2=1.5460 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/f2c_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/f2c_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/f2c_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.211&r2=1.212 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.am.diff?cvsroot=gcc&r1=1.32&r2=1.33 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/Makefile.in.diff?cvsroot=gcc&r1=1.33&r2=1.34 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/aclocal.m4.diff?cvsroot=gcc&r1=1.8&r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/f2c_specifics.F90.diff?cvsroot=gcc&r1=NONE&r2=1.1
Fixed on the mainline. I will commit this to the branch after the obligatory testing and the necessary changes (unfortunately -fsecond-underscore became the default on the branch).
Subject: Re: COMPLEX function returns incompatible with g77 tobi at gcc dot gnu dot org wrote: > ------- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10 22:23 ------- > Fixed on the mainline. I will commit this to the branch after the obligatory > testing and the necessary changes (unfortunately -fsecond-underscore became the > default on the branch). [ Sorry for the late reply ] I wonder if that really means we have to stick to -fsecond-underscore on the 4.0 branch. Only 4.0.0 is out, and it is very probable that *nobody* uses it for any serious work in Fortran anyway. I feel we can safely change the default, even on the branch.
Subject: Re: COMPLEX function returns incompatible with g77 toon at moene dot indiv dot nluug dot nl wrote: > ------- Additional Comments From toon at moene dot indiv dot nluug dot nl 2005-05-15 11:32 ------- > Subject: Re: COMPLEX function returns incompatible with > g77 > > tobi at gcc dot gnu dot org wrote: > > >>------- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10 22:23 ------- >>Fixed on the mainline. I will commit this to the branch after the obligatory >>testing and the necessary changes (unfortunately -fsecond-underscore became the >>default on the branch). > > > [ Sorry for the late reply ] > > I wonder if that really means we have to stick to -fsecond-underscore on > the 4.0 branch. Only 4.0.0 is out, and it is very probable that > *nobody* uses it for any serious work in Fortran anyway. > > I feel we can safely change the default, even on the branch. I'm also inclined to doing this, 4.0.1 will probably be vastly more usable than 4.0, but I'd still like to get feedback from the list. It's really a minor incompatibility. Especially since a lot of people seem to use '-fno-second-underscore'. - Tobi
Subject: Re: COMPLEX function returns incompatible with g77 Tobias Schlüter wrote: >>>------- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10 22:23 ------- >>>Fixed on the mainline. I will commit this to the branch after the obligatory >>>testing and the necessary changes (unfortunately -fsecond-underscore became the >>>default on the branch). >> >> >>[ Sorry for the late reply ] >> >>I wonder if that really means we have to stick to -fsecond-underscore on >>the 4.0 branch. Only 4.0.0 is out, and it is very probable that >>*nobody* uses it for any serious work in Fortran anyway. >> >>I feel we can safely change the default, even on the branch. > > > I'm also inclined to doing this, 4.0.1 will probably be vastly more usable > than 4.0, but I'd still like to get feedback from the list. It's really a > minor incompatibility. Especially since a lot of people seem to use > '-fno-second-underscore'. I'll commit this during the week, unless somebody objects. Toon's approval together with no objections so far is enough for me, but I wanted to give everybody a last chance to object. - Tobi
This is now fixed, right?
Yes. Thanks for reminding me.