Bug 18565 - gfortran: CONJG: false error message about standard violation
Summary: gfortran: CONJG: false error message about standard violation
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic, patch, rejects-valid
Depends on:
Blocks:
 
Reported: 2004-11-19 13:07 UTC by Harald Anlauf
Modified: 2005-01-29 17:48 UTC (History)
2 users (show)

See Also:
Host: i686-pc-cygwin
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2004-11-19 15:19:38


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Anlauf 2004-11-19 13:07:13 UTC
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
Comment 1 Andrew Pinski 2004-11-19 15:19:37 UTC
Confirmed.
Comment 2 Toon Moene 2004-11-20 12:03:54 UTC
(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.
Comment 3 Steve Kargl 2004-11-22 01:43:17 UTC
Toon, Don't you have commit access to the tree?  You can fix this 
under the "obvious" rule.

-- 
steve
Comment 4 Steve Kargl 2004-11-22 04:19:42 UTC
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
Comment 5 Toon Moene 2004-11-24 00:26:38 UTC
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,

Comment 6 Toon Moene 2004-11-24 00:33:40 UTC
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.

Comment 7 Steve Kargl 2005-01-23 18:16:09 UTC
See http://gcc.gnu.org/ml/fortran/2005-01/msg00284.html
for a patch.
Comment 8 Francois-Xavier Coudert 2005-01-26 09:08:07 UTC
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?
Comment 9 Francois-Xavier Coudert 2005-01-26 19:23:21 UTC
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.
Comment 10 Steve Kargl 2005-01-27 03:23:27 UTC
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.
Comment 11 Steve Kargl 2005-01-27 21:55:54 UTC
New patch at http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02076.html.
Comment 12 CVS Commits 2005-01-29 17:46:50 UTC
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

Comment 13 Paul Brook 2005-01-29 17:48:45 UTC
Fixed.