Well, I have tried writing test programs to check whether the
type conversion intrinsics CMPLX, REAL, and INT work. The CMPLX
test required over 4000 versions of invocations of CMPLX, but the
REAL and INT versions weren't so bad. The CMPLX version turned up
a bug in gfortran (PR36186) for which the fix is in the pipeline
and the REAL version didn't turn up anything, but the INT version
ran into a showstopper that keeps it from compiling:

C:\gfortran\james\intrinsics\int>type bug1.f90
module bugmod
parameter(ik1 = selected_int_kind(2))
implicit complex (P)
contains
subroutine bug1(P1)
use mykinds1
integer(ik1), parameter :: k11 = ik1
complex, parameter :: carg1 = 0
parameter(Parg1 = carg1)
integer, parameter :: k_k11 = kind(int(Parg1,kind=k11))

In article comcast.com>,
"James Van Buskirk" comcast.net> writes:

What is mykinds1?

"Steven G. Kargl" troutmask.apl.washington.edu> wrote in message
news:g0gfqn$2gv$1@gnus01.u.washington.edu...

Good question. It's a problem that I encounter when trying to
reduce a test case that bigger versions have modules that get
deleted as reduction proceeds but the reduced test case may still
USE the modules because the *.mod file from previous compilations
didn't get deleted. On deleting *.mod and *.o, I see the problem
you experience when attempting to compile. The fix: just delete
the line of code that asks for the module:

C:\gfortran\james\intrinsics\int>dir *.mod
Volume in drive C has no label.
Volume Serial Number is CCC8-B430

Directory of C:\gfortran\james\intrinsics\int

File Not Found

In article comcast.com>,
"James Van Buskirk" comcast.net> writes:

(delete)

"Steven G. Kargl" troutmask.apl.washington.edu> wrote in message
news:g0hvav$8nr$1@gnus01.u.washington.edu...

That's good news.

"Steven G. Kargl" troutmask.apl.washington.edu> wrote in message
news:g0hvav$8nr$1@gnus01.u.washington.edu...

In my test of intrinsics with complex inputs I have also encountered:

C:\gfortran\james\intrinsics\num_initc1>type int2.f90
program int2_test
integer, parameter :: k = kind(int2((0,0)))

write(*,*) K
end program int2_test

C:\gfortran\james\intrinsics\num_initc1>gfortran int2.f90 -oint2
int2.f90:2.46:

integer, parameter :: k = kind(int2((0,0)))
1
Internal Error at (1):
gfc_validate_kind(): Got bad kind

In article comcast.com>,
"James Van Buskirk" comcast.net> writes:

In article gnus01.u.washington.edu>,
kargl@troutmask.apl.washington.edu (Steven G. Kargl) writes:

"Steven G. Kargl" troutmask.apl.washington.edu> wrote in message
news:g0l72r$tu2$1@gnus01.u.washington.edu...

From snapshot of 20080516 confirming that the patch for INT catches
all combinations of all kinds of complex A, all kinds of KIND and
all values of KIND, including absent = 3*(5*5+1) = 78 cases.

Also the fix for BOZ inputs to to CMPLX intrinsic for (all real
or integer kinds)*(B, O, or Z)*(all kinds of KIND and all values
of KIND including absent)* (same for BOZ X and real or integer Y)
= 8*3*(5*3+1)*2 = 768 cases passed, so CMPLX, REAL, and INT now
pass the tests for both ordinary expressions and initialization
expressions.

That's not to say they're perfect: FX turned up something with
denormals and INT(BOZ) is not yet upgraded to f08 compatibility,
but all two bugs detected by my testing of these 3 intrinsics have
been fixed, and quickly. Thanks.

Some more testing has revealed that most compilers have issues on that
same testcase :)