CMPLX, REAL, and INT -- almost done
James Van Buskirk
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))
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
Steven G. Kargl
"James Van Buskirk" <not_...@comcast.net> writes:
> 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?
James Van Buskirk
news:g0gfqn$2gv$1...@gnus01.u.washington.edu...
> 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.
Steven G. Kargl
> news:g0gfqn$2gv$1...@gnus01.u.washington.edu...
>
>> 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:
>
(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.
James Van Buskirk
> 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.
James Van Buskirk
> 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.
Steven G. Kargl
> news:g0hvav$8nr$1...@gnus01.u.washington.edu...
>
>> 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.
Steven G. Kargl
Correction. Yes, the patch catches this case. I was using the
wrong compiler in testing.
James Van Buskirk
> 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.
FX
Some more testing has revealed that most compilers have issues on that
same testcase :)
--
FX