Another -C check bug
Here is an interesting run-time check bug. I have an internal subroutine where an array index is changed in another internal subroutine by host association. The run-time check misses the fact that the index has been updated. Here is an example. It seems to relate to the use of a derived-type as well.
program test
implicit none
type my_type
integer, allocatable :: type(:)
integer :: size=0
end type my_type
type(my_type) :: obj
allocate(obj%type(10))
call sub1()
contains
subroutine sub1()
call incr()
write(*,*)'obj%size=',obj%size
obj%type(obj%size)=1
end subroutine sub1
subroutine incr()
obj%size=obj%size+1
end subroutine incr
end program test
Here is my result:
obj%size= 1
****** FORTRAN RUN-TIME SYSTEM ******
Subscript out of range. Location: line 14 column 12 of 'test2.f90'
Subscript number 1 has value 0 in array 'TYPE'
Abort
[1010 byte] By [
Joe_Krahna] at [2007-11-27 11:00:44]
# 1
I thought I should go ahead a submit a bug report for this, but I noticed that Sun Studio 12 is not yet present in the list of product versions.
Another quick question: are Linux versions supposed to define __SUNPRO_F95=0x830 when using -cpp? It is a useful feature.
# 2
People seem to have been using "other" because Studio 12 is not an available category.
I think the Linux versions should define __SUNPRO_F95=0x830. Have you found otherwise?
igba at 2007-7-29 12:31:37 >
# 3
Linux versions do not define __SUNPRO_F95 at all, even though the string to do so exists in the executable. I get the other cpp defines, so I thought maybe it skips that one if it is not on a Sun.
# 4
I made my own error handlers for __f90_shape_err() and __f95_null_pointer_err(). In this case, __f90_cb_err_str() is called, but I can't get it to call my own function. It seems that there is something that causes it to link only to the version in libfsu.so. Any ideas why my function is not getting linked to, even though it is present in the same object file as the RT check?
# 6
> Linux versions do not define __SUNPRO_F95 at all,
> even though the string to do so exists in the
> executable. I get the other cpp defines, so I thought
> maybe it skips that one if it is not on a Sun.
What version of Linux are you running? I just tried this:
% f95 -dryrun -xpp=cpp foo.F
...
/usr/bin/cpp -undef -D__SUNPRO_F90=0x830 -D__SUNPRO_F95=0x830 ...
I believe the machine I used is running RHEL release 4.
igba at 2007-7-29 12:31:37 >
# 7
OK, I figured out the problem. I am getting the __SUNPRO defines, but used them in a way that fpp did not substitute them. The problem I have not is that -xpp=cpp does not work because the flag -Y<path> is given, which is not a standard cpp flag, and I just get an error message.
I am guessing that Sun cpp accepts a -Y flag, and sun Fortran assumes that it is standard. If so, maybe a good solution would be just to distribute Sun's cpp along with fpp. Another problem is that cpp is called with a specific path, so there is apparently no way to override it. So, it looks to me like this is a bug. But, it seems unlikely that nobody would have noticed it, unless everybody sticks with fpp, or if the -Y flag is new in this release.
