This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
Hi, the following program gives a false error message when compiled with "gfortran -std=f95": integer, parameter :: dp = kind (1.d0) complex(dp) :: z1, z2 z1 = (0._dp, 1._dp) z2 = conjg (z1) print *, z1, z2 end I get: In file gfcbug21.f90:4 z2 = conjg (z1) 1 Error: Type of argument 'z' in call to 'conjg' at (1) should be COMPLEX(4), not COMPLEX(8) This is clearly wrong. According to my copy of Metcalf&Reid, CONJG is a generic elemental function. Cheers, -ha
Confirmed.
(In reply to comment #0) > z2 = conjg (z1) > 1 > Error: Type of argument 'z' in call to 'conjg' at (1) should be COMPLEX(4), not > COMPLEX(8) Yep, I think this in intrinsic.c: add_sym_1 ("dconjg", 1, 1, BT_COMPLEX, dd, GFC_STD_GNU, NULL, gfc_simplify_conjg, gfc_resolve_conjg, z, BT_COMPLEX, dd, 0); should be: add_sym_1 ("dconjg", 1, 1, BT_COMPLEX, dd, GFC_STD_F95, NULL, gfc_simplify_conjg, gfc_resolve_conjg, z, BT_COMPLEX, dd, 0); Toon.
Toon, Don't you have commit access to the tree? You can fix this under the "obvious" rule. -- steve
Toon, I take it back. The code as written is correct. DCONJG is not listed in "13.6 Specific names for standard intrinsic functions" of the current standard. It you change the code, then DCONJG will not be flagged if --std=f95 is given to the compiler. -- steve
Subject: Re: gfortran: CONJG: false error message about standard violation sgk at troutmask dot apl dot washington dot edu wrote: > ------- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2004-11-22 01:43 ------- > Toon, Don't you have commit access to the tree? You can fix this > under the "obvious" rule. Given the comments on fortran@gcc.gnu.org you don't seem to understand how little time each of the maintainers have to even test their own patches :-) I just today managed to check that my idea actually holds water, and will probably (!) be committed the coming weeked (!) Cheers,
Subject: Re: gfortran: CONJG: false error message about standard violation sgk at troutmask dot apl dot washington dot edu wrote: > ------- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2004-11-22 04:19 ------- > Toon, > > I take it back. The code as written is correct. Now you know why I want to have it reviewed :-( However, your data point is interesting. Perhaps the point where the decision "is this a Fortran XX intrinsic" is made at the wrong point. conjg(double complex) obviously is correct Fortran 95 (when double complex is a "typedef" of COMPLEX(8)), but dconjg is not a correct specific intrinsic. Thanks for looking into this.
See http://gcc.gnu.org/ml/fortran/2005-01/msg00284.html for a patch.
The same bug happens with aimag (and, as far as I can see, for the same reasons): $ cat a.f90 program bug implicit none complex(8) x write(*,*) aimag(x) end $ gfortran -std=f95 a.f90 In file a.f90:5 write(*,*) aimag(x) 1 Error: Type of argument 'z' in call to 'aimag' at (1) should be COMPLEX(4), not COMPLEX(8) Could a similar patch be applied?
Compiling with -std=f95, you can also get these errors: Error: Type of argument 'x' in call to 'cos' at (1) should be REAL(4), not COMPLEX(8) Error: Type of argument 'x' in call to 'exp' at (1) should be REAL(4), not COMPLEX(8) Error: Type of argument 'x' in call to 'log' at (1) should be REAL(4), not COMPLEX(8) Error: Type of argument 'x' in call to 'sin' at (1) should be REAL(4), not COMPLEX(8) Error: Type of argument 'x' in call to 'sqrt' at (1) should be REAL(4), not COMPLEX(8) which are the same as the ones in this PR, as well as: Error: Function 'dimag' at (1) has no implicit type Error: Function 'dcmplx' at (1) has no implicit type Error: Function 'dconjg' at (1) has no implicit type Error: Function 'dreal' at (1) has no implicit type which probably have similar causes.
FX, The first of errors with COS() and friends is caused by marking DCOS as GFC_STD_F77, which apparent is not a subset of GFC_STD_F95. You did not show the code that gives the second set of errors, but I can guess. It looked something like implicit none complex(8) z z = (1.d0,1.d0) print *, dimag(z) end If you compile with -std=f95 and dimag() is not a specific name for the generic function aimag, then the errors you give are indeed correct. The reason is that dimag is not added to the list of intrinsics so gfortran does not know about it and you specified implicit none.
New patch at http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02076.html.
Subject: Bug 18565 CVSROOT: /cvs/gcc Module name: gcc Changes by: pbrook@gcc.gnu.org 2005-01-29 17:46:35 Modified files: gcc/fortran : ChangeLog check.c intrinsic.c intrinsic.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: double_complex_1.f90 Log message: 2005-01-29 Paul Brook <paul@codesourcery.com> PR fortran/18565 * check.c (real_or_complex_check): New function. (gfc_check_fn_c, gfc_check_fn_r, gfc_check_fn_rc): New functions. * intrinsic.c (add_functions): Use new check functions. * intrinsic.h (gfc_check_fn_c, gfc_check_fn_r, gfc_check_fn_rc): Add prototypes. testsuite/ * gfortran.dg/double_complex_1.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.315&r2=1.316 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/check.c.diff?cvsroot=gcc&r1=1.22&r2=1.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/intrinsic.c.diff?cvsroot=gcc&r1=1.37&r2=1.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/intrinsic.h.diff?cvsroot=gcc&r1=1.20&r2=1.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4956&r2=1.4957 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/double_complex_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
Fixed.