[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-13 Thread jvdelisle at gcc dot gnu dot org


--- Comment #24 from jvdelisle at gcc dot gnu dot org  2007-11-14 01:17 
---
Fixed on trunk.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-13 Thread jvdelisle at gcc dot gnu dot org


--- Comment #23 from jvdelisle at gcc dot gnu dot org  2007-11-14 01:06 
---
Subject: Bug 33162

Author: jvdelisle
Date: Wed Nov 14 01:06:13 2007
New Revision: 130169

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130169
Log:
2007-11-13  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33162
*gfortran.dg/proc_decl_1.f90: Update.
*gfortran.dg/proc_decl_7.f90: New test.
*gfortran.dg/proc_decl_8.f90: New test.
*gfortran.dg/proc_decl_9.f90: New test.
*gfortran.dg/proc_decl_10.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_decl_10.f90
trunk/gcc/testsuite/gfortran.dg/proc_decl_7.f90
trunk/gcc/testsuite/gfortran.dg/proc_decl_8.f90
trunk/gcc/testsuite/gfortran.dg/proc_decl_9.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/proc_decl_1.f90


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-13 Thread jvdelisle at gcc dot gnu dot org


--- Comment #22 from jvdelisle at gcc dot gnu dot org  2007-11-14 00:59 
---
Subject: Bug 33162

Author: jvdelisle
Date: Wed Nov 14 00:59:09 2007
New Revision: 130168

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130168
Log:
2007-11-11  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33162
* decl.c (match_procedure_decl): Remove TODO and allow intrinsics in
PROCEDURE declarations.  Set attr.untyped to allow the interface to be
resolved later where the symbol type will be set.
* interface.c (compare_intr_interfaces): Remove static from pointer
declarations.  Add type and kind checks for dummy function arguments.
(compare_actual_formal_intr): New function to compare an actual
argument with an intrinsic function. (gfc_procedures_use): Add check
for
interface that points to an intrinsic function, use the new function.
* resolve.c (resolve_specific_f0): Resolve the intrinsic interface.
(resolve_specific_s0): Ditto.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-11 Thread patchapp at dberlin dot org


--- Comment #21 from patchapp at dberlin dot org  2007-11-12 05:56 ---
Subject: Bug number PR33162

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00598.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-03 Thread jvdelisle at gcc dot gnu dot org


--- Comment #20 from jvdelisle at gcc dot gnu dot org  2007-11-03 22:02 
---
Created an attachment (id=14480)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14480&action=view)
Revised preliminary patch that also fixes comment #19

This patch adds some similar code to resolve_unknown_f.  I may explore pushing
this code block up one level.

Janus, regarding the two statements I bypass in decl.c.  I find that I get an
error for trying to change attributes of use associated functions.  If I
include !attr.use_assoc in the conditions I get a negative refs error.  This
may be a matter of finding the write combination of conditions for these.  In
the meantime, this part3c patch is working for the cases I have and regression
tests fine.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-02 Thread jaydub66 at gmail dot com


--- Comment #19 from jaydub66 at gmail dot com  2007-11-02 20:53 ---
Hi Jerry,
I tried your patch (part 3b), and noticed that it fails on the following code:

real function t(x)
  real ::x
  t = x
end function

program p
  implicit none
  intrinsic sin
  procedure(sin):: t
  print *,t(1.0)
end program

Seems like this is due to the stuff which you added to decl.c
(match_procedure_decl):

+  if (proc_if != NULL && proc_if->attr.intrinsic
+ && gfc_intrinsic_actual_ok (proc_if->name, 0))
+   goto set_if;
+
   if (!sym->attr.pointer && gfc_add_external (&sym->attr, NULL) ==
FAILURE)
return MATCH_ERROR;
   if (gfc_add_proc (&sym->attr, sym->name, NULL) == FAILURE)
return MATCH_ERROR;

   /* Set interface.  */
+set_if:

This prevents the procedure from getting the "external" and "procedure"
attributes, if the interface is an intrinsic routine. This is wrong. A symbol
declared by a PROCEDURE() statement should always get the "procedure"
attribute.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-01 Thread jvdelisle at gcc dot gnu dot org


--- Comment #18 from jvdelisle at gcc dot gnu dot org  2007-11-02 05:56 
---
Created an attachment (id=14466)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14466&action=view)
Revised preliminary last patch

This revised patch adds a check for NULL proc_if in decl.c

This appears to fix the regressions.  Also, one dg-error must be removed from
line 40 of proc_decl_1.f90 since that line now compiles without error with this
patch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-01 Thread jvdelisle at gcc dot gnu dot org


--- Comment #17 from jvdelisle at gcc dot gnu dot org  2007-11-02 05:40 
---
hmm I posted that part3 patch too soon. I see I have several regressions.  Oh
well, its a start. :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-11-01 Thread jvdelisle at gcc dot gnu dot org


--- Comment #16 from jvdelisle at gcc dot gnu dot org  2007-11-02 05:25 
---
Created an attachment (id=14465)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14465&action=view)
Preliminary last patch for this PR

This patch enables the test case in Comment #3 to compile and execute
correctly.  I am not certain it covers all necessary checks.  I would
appreciate some testing and comments.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-31 Thread jvdelisle at gcc dot gnu dot org


--- Comment #15 from jvdelisle at gcc dot gnu dot org  2007-10-31 14:31 
---
Subject: Bug 33162

Author: jvdelisle
Date: Wed Oct 31 14:30:48 2007
New Revision: 129799

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129799
Log:
2007-10-31  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33162
* gfortran.dg/interface_19.f90: New.
* gfortran.dg/interface_20.f90: New.
* gfortran.dg/interface_21.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/interface_19.f90
trunk/gcc/testsuite/gfortran.dg/interface_20.f90
trunk/gcc/testsuite/gfortran.dg/interface_21.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-31 Thread jvdelisle at gcc dot gnu dot org


--- Comment #14 from jvdelisle at gcc dot gnu dot org  2007-10-31 14:27 
---
Subject: Bug 33162

Author: jvdelisle
Date: Wed Oct 31 14:26:57 2007
New Revision: 129798

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129798
Log:
2007-10-31  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33162
* interface.c (compare_intr_interfaces): New function to check
intrinsic
function arguments against formal arguments. (compare_interfaces): Fix
logic in comparison of function and subroutine attributes.
(compare_parameter): Use new function for intrinsic as argument.
* resolve.c (resolve_actual_arglist): Allow an intrinsic without
function attribute to be checked further.  Set function attribute if
intrinsic symbol is found, return FAILURE if not.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/resolve.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-30 Thread patchapp at dberlin dot org


--- Comment #13 from patchapp at dberlin dot org  2007-10-31 04:00 ---
Subject: Bug number PR33162

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01855.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-27 Thread burnus at gcc dot gnu dot org


--- Comment #12 from burnus at gcc dot gnu dot org  2007-10-27 21:07 ---
(In reply to comment #8)
> Interesting is whether the following should be accepted or not.
[...]
> EXTERNAL foo  ! implicit interface
> call sub(foo) ! sub's argument has an explicit interface

gfortran, NAG f95 and Lahey rightfully reject it:

"12.4.1.3 Actual arguments associated with dummy procedure entities"
[...]
"If the interface of the dummy argument is explicit, the characteristics listed
in 12.2 shall be the same for the associated actual argument and the
corresponding dummy argument"

(openf95, sunf95, g95 and ifort accept this program; one could allow it for
-std=gnu or legacy, but it is probably not worth the trouble.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-26 Thread jvdelisle at gcc dot gnu dot org


--- Comment #11 from jvdelisle at gcc dot gnu dot org  2007-10-27 00:57 
---
Subject: Bug 33162

Author: jvdelisle
Date: Sat Oct 27 00:57:26 2007
New Revision: 129674

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129674
Log:
2007-10-26  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33162
* gfortran.dg/argument_checking_9.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/argument_checking_9.f90
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-26 Thread jvdelisle at gcc dot gnu dot org


--- Comment #10 from jvdelisle at gcc dot gnu dot org  2007-10-27 00:54 
---
Subject: Bug 33162

Author: jvdelisle
Date: Sat Oct 27 00:54:20 2007
New Revision: 129673

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129673
Log:
2007-10-26  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33162
* intrinsic.h: Add prototypes for four new functions, gfc_check_datan2,
gfc_check_dprod, gfc_check_fn_d, and gfc_check_x_yd.
* intrinsic.c (add_functions): Add double precision checks for dabs,
dacos, dacosh, dasin, dasinh, datan, datanh, datan2, dbesj0, dbesj1,
dbesy0, dbesy1, dcos, dcosh, ddim, derf, derfc, dexp, dgamma,
dlgama, dlog, dlog10, dmod, dsign, dsin, dsinh, dsqrt, dtan, and dtanh.
Add real check dprod.
* check.c (gfc_check_datan2): New function to check for double
precision
argumants. (gfc_check_dprod, gfc_check_fn_d, and gfc_check_x_yd):
Ditto.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/intrinsic.c
trunk/gcc/fortran/intrinsic.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-22 Thread jvdelisle at gcc dot gnu dot org


--- Comment #9 from jvdelisle at gcc dot gnu dot org  2007-10-23 01:42 
---
The example in Comment #8 is rejected by gfortran because of this bug.  It is
rejected by Lahey:

Diagnostic messages: program name(main)
   2204-S: "SOURCE.F90", line 18, column 6: In the reference to procedure
'sub', the type of actual argument must be the same as that of the
corresponding dummy argument.

There is no type information about external foo so I think this should be
rejected. (Siding with NAG and Lahey as well)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-21 Thread burnus at gcc dot gnu dot org


--- Comment #8 from burnus at gcc dot gnu dot org  2007-10-22 06:56 ---
(In reply to comment #6)
> Created an attachment (id=14381)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14381&action=view) [edit]
> Patch to add checks for double specifics

This looks wrong:
+gfc_check_a_pd (gfc_expr *a, gfc_expr *p)
+  if (double_check (a, 0) == FAILURE || double_check (a, 0) == FAILURE)
(left of || same as right)

(In reply to comment #7)
> Created an attachment (id=14382)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14382&action=view) [edit]
> Preliminary argument checking with intrinsics
>
> This "draft" patch catches the latest invalid case provided in Comment #4. 
> This is only checking a simple case of no argument vs there is an argument.

I'm not sure this is the right approach, see example in PR 33847 for something
gfortran rightfully rejects. gfortran currently has already interface checks,
however, there is no interface known for specific intrinsics procedures, which
we also need for PROCEDURE.

Interesting is whether the following should be accepted or not. NAG f95 and
gfortran reject it, g95 and ifort allow it (well, as PR 33847 shows, their
checking is rather weak).

-
module m
implicit none
contains
  subroutine sub(a)
interface
  function a(x)
real :: a, x
intent(in) :: x
  end function a
end interface
print *, a(4.0)
  end subroutine sub
end module m

use m
implicit none
EXTERNAL foo  ! implicit interface
call sub(foo) ! sub's argument has an explicit interface
end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-21 Thread jvdelisle at gcc dot gnu dot org


--- Comment #7 from jvdelisle at gcc dot gnu dot org  2007-10-21 21:32 
---
Created an attachment (id=14382)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14382&action=view)
Preliminary argument checking with intrinsics

This "draft" patch catches the latest invalid case provided in Comment #4. 
This is only checking a simple case of no argument vs there is an argument. 
With gfc_find_function we can access the formal argument list for the
intrinsics and proceed to check them.  I will develop this further to check
number and types of arguments to verify a match.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-21 Thread jvdelisle at gcc dot gnu dot org


--- Comment #6 from jvdelisle at gcc dot gnu dot org  2007-10-21 16:39 
---
Created an attachment (id=14381)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14381&action=view)
Patch to add checks for double specifics

This patch adds checks for double specific intrinsics.  I added checks for
those specific intrinsics listed in the standard as well as some extensions
provided by gfortran.  Please give it a look over for completeness.  I will
submit to list after I build the ChangeLog entry.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-21 Thread burnus at gcc dot gnu dot org


--- Comment #5 from burnus at gcc dot gnu dot org  2007-10-21 10:44 ---
> This patch: Allows the test case in comment #1 to compile and run correctly 
> with
> no regressions in the test suite.

It also wrongly allows the test case in the bugreport PR 33847 to compile. Thus
we should add a test case for this to the test suite. (That PR is not about
intrinsic functions.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-21 Thread burnus at gcc dot gnu dot org


--- Comment #4 from burnus at gcc dot gnu dot org  2007-10-21 09:30 ---
Several intrinsic functions come as specific and as generic functions. For
instance
  COS as generic function takes as argument REAL(k) and COMPLEX(k), k=4,8,10,16
  and returns the same type and kind as it got as argument.
whereas
  COS as specific function takes as argument REAL(4) and returns REAL(4)
 DCOS as specific function takes as argument REAL(8) and returns REAL(8)

Therefore,
  intrinsic cos
  COS(1.0) ! generic intrinsic function; matches specific function  COS
  COS(1d0) ! generic intrinsic function; matches specific function DCOS
  end
are valid, however,
  intrinsic dcos
  DCOS(1.0)
is wrong as the specific function requires REAL(8) as argument and not REAL(4).
NAG f95:
  ERROR: Wrong data type for argument X to the DCOS intrinsic
g95:
  Error: Type of argument 'x' in call to 'dcos' at (1) should be REAL(8),
 not REAL(4)

In order to detect this, either check.c has to be refined or for specific
function the interface has to be stored. The latter is needed in the following.

If one passes an intrinsic function as actual argument, e.g.
  call sub(cos) ! see valid program in comment 1
the procedure is the specific intrinsic and not the generic intrinsic; in this
case this it means that "cos" gets REAL(4) as argument and returns REAL(4).

Currently, this information is not stored in intrinsic.c. If it were, one could
simply do:
  module mm
  contains
subroutine foo(trig)
  intrinsic cos
  procedure(cos) :: trig ! real(4) function
  print *, trig(1.0)
end subroutine
  end module mm
!and then
  use mm
  call foo(sin) ! specific function with real(4)
  call foo(tan) ! specific function with real(4)
  call foo(dcos)! wrong: specific function with real(8)
  end
The statement
  PROCEDURE(cos) :: trig
declares trig as a procedure which has the same interface as the specific
function cos. In this case the interface of the specific COS is probably:

  elemental function cos(x)
real(4), intent(in) :: x
real(4) :: cos
  end function cos

Thus, in order to implement
  "PROCEDURE( intrinsic specific function )"
one needs to know (in match_procedure) the explicit interface of that function.
While the PROCEDURE statement is a Fortran 2003 feature, the program in comment
1 is a valid Fortran 95 program. The problem of the patch in comment 2 is that
it also allows the following program which is invalid:

module m
implicit none
contains
  subroutine sub(a)
interface
  function a()
real :: a
  end function a
end interface
print *, a()
  end subroutine sub
end module m

use m
implicit none
intrinsic cos
! NAG f95:
! Error: Specific intrinsic COS has more arguments than dummy proc A
call sub(cos)
end

Note that the program in comment 4 is wrong since
  use m
imports the interface of my1 and and my2, while the following declares the
interfaces again:
  procedure(dcos):: my1
  procedure(cos) :: my2

The reason that Janus has not implemented "PROCEDURE( specific intrinsic )" is
that we currently do not store the interface of specific intrinsics, which made
the support a bit difficult.

(PROCEDURE(otherProcedure) is already supported for non-intrinsic procedures
such as:
  procedure(foo) :: bar
  call bar(4,4.4)
 contains
  subroutine foo(x,y)
integer :: x
real:: y
  end subroutine
end ! )


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-20 Thread jvdelisle at gcc dot gnu dot org


--- Comment #3 from jvdelisle at gcc dot gnu dot org  2007-10-21 03:34 
---
Tobias, is this what you meant in your original comment that should work?

module m
implicit none
  interface
double precision function my1(x)
  double precision, intent(in) :: x
end function my1
  end interface
  interface
real(kind=4) function my2(x)
  real, intent(in) :: x
end function my2
  end interface
end module

use m
procedure(dcos):: my1
procedure(cos) :: my2
print *, my2(1.0)
print *, my1(1d0)
end

Now this gives:

test.f90:16.14:

procedure(dcos) :: my1
 1
Error: Fortran 2003: Support for intrinsic procedure 'dcos' in PROCEDURE
statement at (1) not yet implemented in gfortran
test.f90:17.13:

procedure(cos) :: my2
1
Error: Fortran 2003: Support for intrinsic procedure 'cos' in PROCEDURE
statement at (1) not yet implemented in gfortran


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-10-20 Thread jvdelisle at gcc dot gnu dot org


--- Comment #2 from jvdelisle at gcc dot gnu dot org  2007-10-21 00:15 
---
This patch:

Index: interface.c
===
--- interface.c (revision 129496)
+++ interface.c (working copy)
@@ -1679,8 +1679,9 @@ compare_actual_formal (gfc_actual_arglis
return 0;

}
-  else if (!compare_parameter (f->sym, a->expr,
-  ranks_must_agree || rank_check,
is_elemental))
+  else if (a->expr->ts.type != BT_PROCEDURE 
+  && !compare_parameter (f->sym, a->expr, ranks_must_agree
+ || rank_check, is_elemental))
{
  if (where)
gfc_error ("Type/rank mismatch in argument '%s' at %L",

Allows the test case in comment #1 to compile and run correctly with no
regressions in the test suite.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-21 00:15:45
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162



[Bug fortran/33162] INTRINSIC functions as ACTUAL argument

2007-09-05 Thread burnus at gcc dot gnu dot org


--- Comment #1 from burnus at gcc dot gnu dot org  2007-09-05 14:14 ---
Besides the argument kind checking of specific intrinsic procedures and
besides using specific intrinsic as name in the PROCEDURE statement, the
following fails as well. The error message is:
  Error: Type/rank mismatch in argument 'a' at (1)
This program works with NAG f95, g95, ifort, openf95 ...

module m
implicit none
contains
  subroutine sub(a)
interface
  function a(x)
real :: a, x
intent(in) :: x
  end function a
end interface
optional :: a
if(present(a)) print *, a(4.0)
  end subroutine sub
end module m

use m
implicit none
intrinsic cos
call sub()
call sub(cos)
end


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||30871
  nThis||
   Keywords||rejects-valid
Summary|Type checking absent for|INTRINSIC functions as
   |specific names of INTRINSIC |ACTUAL argument
   |functions   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33162