Bug 18565

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.