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))
write(*,*) 42_k_k11
end subroutine bug1
end module bugmod
program bugtest
use bugmod
call bug1(cmplx(1))
end program bugtest
C:\gfortran\james\intrinsics\int>gfortran bug1.f90 -obug1
bug1.f90:10.64:
integer, parameter :: k_k11 = kind(int(Parg1,kind=k11))
1
Internal Error at (1):
gfc_validate_kind(): Got bad kind
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
> 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
What is mykinds1?
> What is mykinds1?
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
C:\gfortran\james\intrinsics\int>type bug1.f90
module bugmod
parameter(ik1 = selected_int_kind(2))
implicit complex (P)
contains
subroutine bug1(P1)
integer(ik1), parameter :: k11 = ik1
complex, parameter :: carg1 = 0
parameter(Parg1 = carg1)
integer, parameter :: k_k11 = kind(int(Parg1,kind=k11))
write(*,*) 42_k_k11
end subroutine bug1
end module bugmod
program bugtest
use bugmod
call bug1(cmplx(1))
end program bugtest
C:\gfortran\james\intrinsics\int>gfortran bug1.f90 -obug1
bug1.f90:9.64:
integer, parameter :: k_k11 = kind(int(Parg1,kind=k11))
1
Internal Error at (1):
gfc_validate_kind(): Got bad kind
Sorry about that. Hope the error may be replicated from the above.
(delete)
> integer, parameter :: k_k11 = kind(int(Parg1,kind=k11))
> 1
> Internal Error at (1):
> gfc_validate_kind(): Got bad kind
>
> Sorry about that. Hope the error may be replicated from the above.
>
I have a patch for this bug.
Here's a reduced testcase
subroutine bug1
integer, parameter :: ik1 = 1
integer, parameter :: k_k11 = kind(int((0.,0.), kind=ik1))
end subroutine bug1
If (0.,0.) is replaced by either 0 (i.e., INTEGER) or 0. (i.e., REAL),
then the code compiles.
If ik1 is 1, 2, or 16 (64-bit OS required?), then the ICE occurs.
For ik1 = 4 or 8, the code compiles.
> In article <zLSdnYzTou-yVLbV...@comcast.com>,
> "James Van Buskirk" <not_...@comcast.net> writes:
>> integer, parameter :: k_k11 = kind(int(Parg1,kind=k11))
>> Internal Error at (1):
>> gfc_validate_kind(): Got bad kind
> I have a patch for this bug.
That's good news.
> Here's a reduced testcase
> subroutine bug1
> integer, parameter :: ik1 = 1
> integer, parameter :: k_k11 = kind(int((0.,0.), kind=ik1))
> end subroutine bug1
> If (0.,0.) is replaced by either 0 (i.e., INTEGER) or 0. (i.e., REAL),
> then the code compiles.
> If ik1 is 1, 2, or 16 (64-bit OS required?), then the ICE occurs.
> For ik1 = 4 or 8, the code compiles.
Not to mention that similar code with INT replaced by REAL or CMPLX
had already passed, along with code that had identical invocation of
INT, but in an ordinary expression rather than an initialization
expression. I am optimistic that my test program for initialization
expressions using the INT intrinsic will pass after this patch goes
through. In fact I just now tried it with the complex part commented
out and it passed for the rest.
> Here's a reduced testcase
> subroutine bug1
> integer, parameter :: ik1 = 1
> integer, parameter :: k_k11 = kind(int((0.,0.), kind=ik1))
> end subroutine bug1
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
It looks like your patch probably got it but I'm not sure.
My patch does not catch this. This is an issue with INT2().
program int2_test
k = int2(0) ! Works
k = int2(0.) ! Works
k = int2((0.,0.)) ! invalid kind
end program int2_test
mobile:kargl[209] ~/work/bin/gfortran -static -o z j5.f90
j5.f90:5.21:
end program int2_test
1
Internal Error at (1):
gfc_validate_kind(): Got bad kind
It's in the same area of the compiler, so it shouldn't be too hard
to find.
Correction. Yes, the patch catches this case. I was using the
wrong compiler in testing.
> Correction. Yes, the patch catches this case. I was using the
> wrong compiler in testing.
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 :)
--
FX