Attempting to point to fixed address
James Van Buskirk
TV. I was trying to write a program that would display a test
pattern on it, but encountered the following problem:
C:\gfortran\clf\HelloWin>type bug1.f90
program bug1
use ISO_C_BINDING
implicit none
character(kind=C_CHAR), pointer :: cDefault(:)
call C_F_POINTER(transfer(32512_C_INTPTR_T,C_NULL_PTR), &
cDefault,[1])
end program bug1
C:\gfortran\clf\HelloWin>gfortran bug1.f90
f951.exe: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
C:\gfortran\clf\HelloWin>gfortran -v
Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/gcc_equation/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/
lto-wrapper.exe
Target: x86_64-w64-mingw32
Thread model: win32
gcc version 4.6.0 20101204 (experimental) (GCC)
Can anyone suggest a workaround?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
glen herrmannsfeldt
> I finally got the doohickey that allowed me to hook up my PC to my
> TV. I was trying to write a program that would display a test
> pattern on it, but encountered the following problem:
(snip)
> call C_F_POINTER(transfer(32512_C_INTPTR_T,C_NULL_PTR), &
> cDefault,[1])
You mean direct write into display memory? I didn't know
that you could still do that. In the DOS days that was
fairly common, but that was before protected mode memory
access.
Still, it shouldn't get an internal compiler error.
-- glen
steve
> C:\gfortran\clf\HelloWin>gfortran bug1.f90
> f951.exe: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
--
steve
James Van Buskirk
news:bc7d4827-7bec-4435...@t8g2000prh.googlegroups.com...
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
Thanks for taking a look at this, Steve. In the meantime I have found
a workaround:
C:\gfortran\clf\HelloWin>type bug2a.f90
program bug2a
use ISO_C_BINDING
implicit none
character(kind=C_CHAR), pointer :: cDefault(:)
integer(C_INTPTR_T) address
type(C_PTR) p
address = 32512
p = transfer(address,p)
call C_F_POINTER(p,cDefault,[1])
call sub(cDefault)
end program bug2a
subroutine sub(x)
use ISO_C_BINDING
implicit none
integer(C_INTPTR_T), value :: x
write(*,'(a,i0)') 'Address = ',x
end subroutine sub
C:\gfortran\clf\HelloWin>gfortran bug2a.f90 -obug2a
bug2a.f90:11.11:
call sub(cDefault)
1
Error: Dummy argument 'x' of procedure 'sub' at (1) has an attribute that
requir
es an explicit interface for this procedure
bug2a.f90:11.12:
call sub(cDefault)
1
Warning: Type mismatch in argument 'x' at (1); passed CHARACTER(1) to
INTEGER(8)
C:\gfortran\clf\HelloWin>type bug2b.f90
program bug2
use ISO_C_BINDING
implicit none
character(kind=C_CHAR), pointer :: cDefault(:)
integer(C_INTPTR_T) address
type(C_PTR) p
interface
subroutine sub(string) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
character(kind=C_CHAR) string(*)
end subroutine sub
end interface
address = 32512
p = transfer(address,p)
call C_F_POINTER(p,cDefault,[1])
call sub(cDefault)
end program bug2
subroutine sub(x) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
integer(C_INTPTR_T), value :: x
write(*,'(a,i0)') 'Address = ',x
end subroutine sub
C:\gfortran\clf\HelloWin>gfortran bug2b.f90 -obug2b
C:\gfortran\clf\HelloWin>bug2b
Address = 32512
So it seems that the SOURCE argument to the TRANSFER intrinsic must
be a literal as well as the MOLD argument being of TYPE(C_PTR) or
TYPE(C_FUNPTR) to trigger this ICE. Perhaps this happens because
the initialization expression compiler rather than the ordinary
expression compiler is operative?
James Van Buskirk
news:iebn5v$igv$1...@news.eternal-september.org...
> Thanks for taking a look at this, Steve. In the meantime I have found
> a workaround:
There were a couple of other approaches to what I was ultimately
trying to do:
C:\gfortran\clf\HelloWin>type bug3.f90
module mod
implicit none
interface sub
subroutine sub_string(string) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
character(kind=C_CHAR) string(*)
end subroutine sub_string
subroutine sub_ptr(string) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
type(C_PTR), value :: string
end subroutine sub_ptr
end interface sub
end module mod
program bug3
use ISO_C_BINDING
use mod
implicit none
integer(C_INTPTR_T) address
type(C_PTR) p
address = 32512
p = transfer(address,p)
call sub(p)
end program bug3
subroutine sub(x) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
integer(C_INTPTR_T), value :: x
write(*,'(a,i0)') 'Address = ',x
end subroutine sub
C:\gfortran\clf\HelloWin>gfortran bug3.f90 -obug3
bug3.f90:4.27:
subroutine sub_string(string) bind(C,name='_Sub')
1
bug3.f90:9.24:
subroutine sub_ptr(string) bind(C,name='_Sub')
2
Error: Binding label '_Sub' in interface body at (1) collides with the
global en
tity '_Sub' at (2)
bug3.f90:19.10:
use mod
1
Fatal Error: Can't open module file 'mod.mod' for reading at (1): No such
file o
r directory
gfortran: internal compiler error: Aborted (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
C:\gfortran\clf\HelloWin>type bug4.f90
module mod
implicit none
end module mod
program bug4
use ISO_C_BINDING
use mod
implicit none
interface
subroutine sub(string) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
character(kind=C_CHAR) string(*)
end subroutine sub
end interface
character(kind=C_CHAR), pointer :: t1(:), t2(:)
integer(C_INTPTR_T) address
type(C_PTR) p1, p2
address = 32512
p1 = transfer(address,p1)
call C_F_POINTER(p1,t1,[0])
write(*,'(a,i0,a)') 'C_PTR to ',address,' is '// &
trim(merge(' ','not',C_ASSOCIATED(p1)))// &
' C_ASSOCIATED.'
write(*,'(a,i0)') 'Calling sub with address set to ',address
call sub(t1)
address = 32520
p2 = transfer(address,p2)
call C_F_POINTER(p2,t2,[0])
write(*,'(a,i0,a)') 'C_PTR to ',address,' is '// &
trim(merge(' ','not',C_ASSOCIATED(p1)))// &
' C_ASSOCIATED.'
write(*,'(a,i0)') 'Calling sub with address set to ',address
call sub(t2)
write(*,'(a,i0,a)') 'The two Fortran pointers are '// &
trim(merge(' ','not',associated(t1,t2)))// &
' associated.'
write(*,'(a,i0,a)') 'Fortran pointers p1 is '// &
trim(merge(' ','not',associated(t1,t2)))// &
' associated with itself.'
end program bug4
subroutine sub(x) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
integer(C_INTPTR_T), value :: x
write(*,'(a,i0)') 'Address = ',x
end subroutine sub
C:\gfortran\clf\HelloWin>gfortran bug4.f90 -obug4
C:\gfortran\clf\HelloWin>bug4
C_PTR to 32512 is C_ASSOCIATED.
Calling sub with address set to 32512
Address = 32512
C_PTR to 32520 is C_ASSOCIATED.
Calling sub with address set to 32520
Address = 32520
The two Fortran pointers are not associated.
Fortran pointers p1 is not associated with itself.
gfortran is perfect in bug4.f90, doing just what I would expect from
reading the standard. However, I don't understand what is
objectionable about bug3.f90. From N1830.pdf, section 16.2:
"Program units, common blocks, external procedures, entities with
binding labels, external input/output units, pending data transfer
operations, and images are global entities of a program. The name
of a common block with no binding label, external procedure with
no binding label, or program unit that is not a submodule is a
global identifier. The submodule identifier of a submodule is a
global identifier. A binding label of an entity of the program is
a global identifier. An entity of the program shall not be
identified by more than one binding label.
The global identifier of an entity shall not be the same as the
global identifier of any other entity. Furthermore, a binding label
shall not be the same as the global identifier of any other global
entity, ignoring differences in case."
So as I see it, the global entity is the external procedure you get
by compiling subroutine sub. Its binding label, '_Sub', is a global
identifier. No other binding label is being used to identify it.
The binding label '_Sub' is being used 3 times to identify subroutine
sub, in its definition and in the interface bodies sub_string and
sub_ptr, but all three times it refers to the same entity.
What I am trying to do here is desirable since some Win32 API
functions have an argument that can be a pointer to a NUL-terminated
string or NULL or an integer, depending on context. One could
define an interface where the argument in type(C_PTR), passed by
value, as in subroutine sub_ptr above, but then you have to take the
C_LOC of every actual string you pass it and that could be a pain if
the string happens to be repeat('blah',3)//string_fun(pi)//achar(0)
because an expression doesn't have a C_LOC (maybe with some
exceptions...) so you have to store the result of the expression
somewhere and take the C_LOC of somewhere, awkward if allocatable
lengths aren't available.
James Van Buskirk
> write(*,'(a,i0,a)') 'Fortran pointers p1 is '// &
> trim(merge(' ','not',associated(t1,t2)))// &
> ' associated with itself.'
Quite garbled. Intended was:
write(*,'(a,i0,a)') 'Fortran pointer t1 is '// &
trim(merge(' ','not',associated(t1,t1)))// &
' associated with itself.'
But the (correct) output is unchanged for this case, bug4.f90.
steve
> "James Van Buskirk" <not_va...@comcast.net> wrote in messagenews:iebn5v$igv$1...@news.eternal-september.org...
(fatal error, ICE, and bug4.f90 removed)
> gfortran is perfect in bug4.f90, doing just what I would expect from
> reading the standard. However, I don't understand what is
> objectionable about bug3.f90. From N1830.pdf, section 16.2:
>
> "Program units, common blocks, external procedures, entities with
> binding labels, external input/output units, pending data transfer
> operations, and images are global entities of a program. The name
> of a common block with no binding label, external procedure with
> no binding label, or program unit that is not a submodule is a
> global identifier. The submodule identifier of a submodule is a
> global identifier. A binding label of an entity of the program is
> a global identifier. An entity of the program shall not be
> identified by more than one binding label.
>
> The global identifier of an entity shall not be the same as the
> global identifier of any other entity. Furthermore, a binding label
> shall not be the same as the global identifier of any other global
> entity, ignoring differences in case."
>
> So as I see it, the global entity is the external procedure you get
> by compiling subroutine sub. Its binding label, '_Sub', is a global
> identifier. No other binding label is being used to identify it.
> The binding label '_Sub' is being used 3 times to identify subroutine
> sub, in its definition and in the interface bodies sub_string and
> sub_ptr, but all three times it refers to the same entity.
I think the passage you quote says that gfortran is doing the
right thing with reporting problems for bug3.f90. Cutting
the passage down, I have
"... entities with binding labels ... are global entities
of a program. ... A binding label of an entity of the program
is a global identifier.
The global identifier of an entity shall not be the same as
the global identifier of any other entity. Furthermore, a
binding label shall not be the same as the global identifier
of any other global entity."
subroutine sub_string(string) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
character(kind=C_CHAR) string(*)
end subroutine sub_string
subroutine sub_ptr(string) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
type(C_PTR), value :: string
end subroutine sub_ptr
sub_string and sub_ptr are global entities. The first occurrence
of "bind(C,name='_Sub')" is a binding label and it is a global
identifier. The second occurrence of this binding label appears
to violate the last sentence I quoted.
Note, I could be wrong in that interpreting Standardese is
not one of my better qualities. :)
--
steve
James Van Buskirk
> subroutine sub_string(string) bind(C,name='_Sub')
> use ISO_C_BINDING
> implicit none
> character(kind=C_CHAR) string(*)
> end subroutine sub_string
> subroutine sub_ptr(string) bind(C,name='_Sub')
> use ISO_C_BINDING
> implicit none
> type(C_PTR), value :: string
> end subroutine sub_ptr
> sub_string and sub_ptr are global entities. The first occurrence
> of "bind(C,name='_Sub')" is a binding label and it is a global
> identifier. The second occurrence of this binding label appears
> to violate the last sentence I quoted.
> Note, I could be wrong in that interpreting Standardese is
> not one of my better qualities. :)
I think that you are wrong but it's a subtle point and it is
certainly possible that in fact you have it right and I am wrong.
My position is that the binding name '_Sub' is being given to the
procedure defined by subroutine sub, not the interface bodies
above. Here, let me change my example to something which it is
obvious, at least to me, that should compile:
C:\gfortran\clf\HelloWin>type bug3a.f90
module mod
implicit none
interface sub
! subroutine sub_string(string) bind(C,name='_Sub')
! use ISO_C_BINDING
! implicit none
! character(kind=C_CHAR) string(*)
! end subroutine sub_string
subroutine sub_ptr(string) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
type(C_PTR), value :: string
end subroutine sub_ptr
end interface sub
end module mod
program bug3
use ISO_C_BINDING
use mod
implicit none
integer(C_INTPTR_T) address
type(C_PTR) p
address = 32512
p = transfer(address,p)
call sub(p)
end program bug3
subroutine sub(x) bind(C,name='_Sub')
use ISO_C_BINDING
implicit none
integer(C_INTPTR_T), value :: x
write(*,'(a,i0)') 'Address = ',x
end subroutine sub
C:\gfortran\clf\HelloWin>gfortran bug3a.f90 -obug3a
C:\gfortran\clf\HelloWin>bug3a
Address = 32512
This compiled in spite of the fact that the binding name '_Sub'
appeared twice in the program. But that's OK, I claim, because in
both instances the binding name '_Sub' referred to external
subroutine sub. Another way of looking at it is to consider that
subroutine sub could have been written as a C function returning
void and have been invoked by a C caller. One could replace the
calling program unit by a Fortran one and that would be where the
interface body would reside, and it's clear the the binding name
'_Sub' is an instruction to the linker about where to look for
the procedure that the interface body told the compiler how to
invoke.
Alternatively, one could replace the callee with a Fortran
subroutine, which is subroutine sub. The code for subroutine
sub tells the compiler what it should do and its interface,
while its binding name '_Sub' is a message to the linker that
it should satisfy external references that are looking for that
name.
The entire program in bug3a.f90 is the result of replacing both
caller and callee with Fortran program units. It would be strange
if it didn't compile because that would imply that only one side or
the other could be replaced by Fortran, not both. But if one were to
claim that '_Sub' is the binding name of the interface body sub_ptr
then bug3a.f90 would be invalid. I claim that it is valid because
subroutine sub_ptr(string) bind(C,name='_Sub')
says that '_Sub' is the binding name of the external procedure
that interface body sub_ptr tells the compiler how to invoke, not
that of interface body sub_ptr itself.
Given that logic, the original program, bug3.f90, should, in my
view, have compiled because the binding name '_Sub' referred to
the same thing, external subroutine sub, in all 3 cases.
James Van Buskirk
> My position is that the binding name '_Sub' is being given to the
> procedure defined by subroutine sub, not the interface bodies
> above.
Oh, goody. While looking through th N1830.pdf for something else,
I found:
"C518 An entity with the BIND attribute shall be a common block,
variable, type, or procedure."
Since an interface body is none of the above, the entity with the
BIND attribute has to be the procedure defined by subroutine sub.
steve
>
> So it seems that the SOURCE argument to the TRANSFER intrinsic must
> be a literal as well as the MOLD argument being of TYPE(C_PTR) or
> TYPE(C_FUNPTR) to trigger this ICE. Perhaps this happens because
> the initialization expression compiler rather than the ordinary
> expression compiler is operative?
>
Your guess is not too far from the truth. I have a patch that
allows this code to compile:
program z
use iso_c_binding
type(c_ptr) m
m = transfer(32512, m)
m = transfer(32512, C_NULL_PTR)
end program z
I have no idea if the result gives the desired effect.
Oh, and, my patched gfortran can compile your original code
in your first post.
James Van Buskirk
> Your guess is not too far from the truth. I have a patch that
> allows this code to compile:
> program z
> use iso_c_binding
> type(c_ptr) m
> m = transfer(32512, m)
> m = transfer(32512, C_NULL_PTR)
> end program z
> I have no idea if the result gives the desired effect.
> Oh, and, my patched gfortran can compile your original code
> in your first post.
Thanks for the patch, Steve. From looking at your patch
I am not sure if it handles:
C:\gfortran\clf\HelloWin>type bug5.f90
program bug5
use iso_c_binding
type(c_funptr) m
m = transfer(32512, m)
m = transfer(32512, C_NULL_FUNPTR)
end program bug5
C:\gfortran\clf\HelloWin>gfortran bug5.f90 -obug5
f951.exe: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
steve
wrote:
It's not clear to me whether you're testing my
patch. The patch has not been committed to the
gcc repository, so you would need to build gfortran
with my patch applied to test. The patch is sitting
in the bug database with the hope that someone will
review and OK it for inclusion in gcc.
--
steve
James Van Buskirk
> It's not clear to me whether you're testing my
> patch. The patch has not been committed to the
> gcc repository, so you would need to build gfortran
> with my patch applied to test. The patch is sitting
> in the bug database with the hope that someone will
> review and OK it for inclusion in gcc.
Testing your patch is way beyond my capabilities. I just scanned it
visually and saw the string "c_ptr" but didn't see the string
"c_funptr". I thought that once we had gone through all the effort
of moving the stove aside we might as well step on all cockroaches
we expose.
steve
Ah sorry, misread the code you modified. I've updated
my patch to skip C_FUNPTR entities as well. I suspect
that there may also be problems if one uses an array
of C_PTR or C_FUNPTRs or functions that return either
derived type (don't know if this is possible, because
I've never thought about it).
--
steve
James Van Buskirk
> Ah sorry, misread the code you modified. I've updated
> my patch to skip C_FUNPTR entities as well. I suspect
> that there may also be problems if one uses an array
> of C_PTR or C_FUNPTRs or functions that return either
> derived type (don't know if this is possible, because
> I've never thought about it).
Functions that return C_FUNPTRs don't sound as daunting as procedure
pointers that point at procedures that are functions that themselves
return procedure pointer results :)
Is this the kind of thing you were thinking about?
C:\gfortran\clf\HelloWin>type bug6.f90
program bug6
use ISO_C_BINDING
implicit none
interface
function fun()
use ISO_C_BINDING
implicit none
type(C_FUNPTR) fun
end function fun
end interface
type(C_PTR) array(2)
type(C_FUNPTR) result
integer(C_INTPTR_T), parameter :: const(*) = [32512,32520]
result = fun()
array = transfer([integer(C_INTPTR_T)::32512,32520],array)
write(*,*) transfer(result,const)
write(*,*) transfer(array,const)
end program bug6
function fun()
use ISO_C_BINDING
implicit none
type(C_FUNPTR) fun
fun = transfer(32512_C_INTPTR_T,fun)
end function fun
C:\gfortran\clf\HelloWin>gfortran bug6.f90 -obug6
f951.exe: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
steve
wrote:
> "steve" <kar...@comcast.net> wrote in message
>
> news:198b1f14-967f-4df5...@z26g2000prf.googlegroups.com...
>
> > Ah sorry, misread the code you modified. I've updated
> > my patch to skip C_FUNPTR entities as well. I suspect
> > that there may also be problems if one uses an array
> > of C_PTR or C_FUNPTRs or functions that return either
> > derived type (don't know if this is possible, because
> > I've never thought about it).
>
> Functions that return C_FUNPTRs don't sound as daunting as procedure
> pointers that point at procedures that are functions that themselves
> return procedure pointer results :)
>
> Is this the kind of thing you were thinking about?
>
Yep. gdb shows that it is breaking in a most fun
and discouraging way. :(
Not to mention, tobias doe not like my patch.
--
steve
James Van Buskirk
> Yep. gdb shows that it is breaking in a most fun
> and discouraging way. :(
> Not to mention, tobias doe not like my patch.
Bummer. But I was just thinking that maybe it would be good to have
a test case that forces gfortran to evaluate the expressions in
question as initialization expressions because it seems to have a
knack for weaseling its way out of that if possible. As I was
composing such a test case I found a couple of other anomalies:
C:\gfortran\clf\HelloWin>type bug7a.f90
program bug7a
use ISO_FORTRAN_ENV
use ISO_C_BINDING
implicit none
integer(C_INTPTR_T), parameter :: n1 = 32152
integer(C_INTPTR_T), parameter :: k1 = &
REAL_KINDS(modulo(n1,size(REAL_KINDS))+1)
real(k1) x
x = 1
write(*,*) kind(n1), kind(size(REAL_KINDS))
write(*,*) x
end program bug7a
C:\gfortran\clf\HelloWin>gfortran bug7a.f90 -obug7a
bug7a.f90:8.7:
real(k1) x
1
Warning: C kind type parameter is for type INTEGER but type at (1) is REAL
C:\gfortran\clf\HelloWin>bug7a
8 4
1.0000000
First off, that warning seems completely spurious. Also, note that
MODULO is accepting arguments of different KINDs, a reasonable
extension, but one that is undocumented under the MODULO function
in the gfortran manual.
With that off our chest, we may offer an improved test case:
C:\gfortran\clf\HelloWin>type bug7.f90
program bug7
use ISO_C_BINDING
use ISO_FORTRAN_ENV
implicit none
type(C_PTR), parameter :: p1 = &
transfer(32512_C_INTPTR_T,C_NULL_PTR)
type(C_FUNPTR), parameter :: p2(*) = transfer( &
[integer(C_INTPTR_T)::32519,32526],[C_NULL_FUNPTR])
integer(C_INTPTR_T), parameter :: n1 = transfer(p1,0_C_INTPTR_T)
integer(C_INTPTR_T), parameter :: k1 = &
REAL_KINDS(modulo(n1,size(REAL_KINDS,kind=kind(n1)))+1)
real(k1) x
integer(C_INTPTR_T), parameter :: n2 = transfer(p2(1),0_C_INTPTR_T)
integer(C_INTPTR_T), parameter :: k2 = &
REAL_KINDS(modulo(n2,size(REAL_KINDS,kind=kind(n2)))+1)
real(k2) y
integer(C_INTPTR_T), parameter :: n3 = transfer(p2(2),0_C_INTPTR_T)
integer(C_INTPTR_T), parameter :: k3 = &
REAL_KINDS(modulo(n3,size(REAL_KINDS,kind=kind(n3)))+1)
real(k3) z
integer i
x = 1
y = 2
z = 3
i = x+y+z
write(*,*) i
end program bug7
C:\gfortran\clf\HelloWin>gfortran bug7.f90 -obug7
steve
wrote:
As always, use -std=f95 or -std=f2003 or -std=f2008 to
suppress extensions (not sure it helps, too lazy to check).
Here, the cause of non-documentation is fairly clear.
Most gfortran intrinsic procedures were written years
before the documentation. In fact the person writing
the code and person writing the docs typically are
different people. The doc writer probably followed
one of standards while the coder followed his own
whim.
This is a perfect opportunity for someone who would
like to get involved with gfortran development, ie.,
review the documentation and submit patches.
Tobias has fixed this issue and the other C_PTR/C_FUNPTR
related issue with revision 168031.
Gary L. Scott
James Van Buskirk
> Tobias has fixed this issue and the other C_PTR/C_FUNPTR
> related issue with revision 168031.
Thanks to you and Tobias!
James Van Buskirk
> Tobias has fixed this issue and the other C_PTR/C_FUNPTR
> related issue with revision 168031.
The fix arrived in time to make it into
ftp://ftp.equation.com/gcc/gcc-4.6-20101218-64.exe
and I have completed the program that got bitten by this bug and now
happily draws the test pattern on my TV:
http://home.comcast.net/~kmbtib/Fortran_stuff/testpattern.f90
Thanks again.
James Van Buskirk
> The fix arrived in time to make it into
> ftp://ftp.equation.com/gcc/gcc-4.6-20101218-64.exe
> and I have completed the program that got bitten by this bug and now
> happily draws the test pattern on my TV:
> http://home.comcast.net/~kmbtib/Fortran_stuff/testpattern.f90
> Thanks again.
But I still am seeing a problem with the bug7.f90 program I posted
earlier:
C:\gfortran\clf\testpattern>type bug7.f90
C:\gfortran\clf\testpattern>gfortran bug7.f90 -obug7
bug7.f90:9.51:
integer(C_INTPTR_T), parameter :: n1 = transfer(p1,0_C_INTPTR_T)
1
Error: Components of structure constructor 'c_ptr' at (1) are PRIVATE
bug7.f90:11.26:
REAL_KINDS(modulo(n1,size(REAL_KINDS,kind=kind(n1)))+1)
1
Error: Symbol 'n1' at (1) has no IMPLICIT type
bug7.f90:12.10:
real(k1) x
1
Error: Symbol 'k1' at (1) has no IMPLICIT type
bug7.f90:16.7:
real(k2) y
1
Warning: C kind type parameter is for type INTEGER but type at (1) is REAL
bug7.f90:20.7:
real(k3) z
1
Warning: C kind type parameter is for type INTEGER but type at (1) is REAL
bug7.f90:23.4:
x = 1
1
Error: Symbol 'x' at (1) has no IMPLICIT type
bug7.f90:5.33:
type(C_PTR), parameter :: p1 = &
1
Error: Components of structure constructor 'c_ptr' at (1) are PRIVATE
bug7.f90:8.6:
[integer(C_INTPTR_T)::32519,32526],[C_NULL_FUNPTR])
1
Error: Components of structure constructor 'c_funptr' at (1) are PRIVATE
bug7.f90:8.6:
[integer(C_INTPTR_T)::32519,32526],[C_NULL_FUNPTR])
1
Error: Components of structure constructor 'c_funptr' at (1) are PRIVATE
Those error statements are at least incorrect in that they should
read "components of the structure", not "components of the structure
constructor" and I couldn't find where in the standard this usage is
disallowed in any case. The same syntax but in a slightly
different context passed in the test case for PR45362:
C:\gfortran\clf\testpattern>type bug8.f90
program test
use ISO_C_BINDING
implicit none
type(C_PTR) m
integer(c_intptr_t) :: a
integer(transfer(transfer(4_c_intptr_t, c_null_ptr),1_c_intptr_t)) :: b
a = transfer (transfer("ABCE", m), 1_c_intptr_t)
print '(z8)', a
if ( int(z'45434241') /= a &
.and. int(z'41424345') /= a &
.and. int(z'4142434500000000',kind=8) /= a) &
call i_do_not_exist()
end program test
subroutine i_do_not_exist
end subroutine i_do_not_exist
C:\gfortran\clf\testpattern>gfortran bug8.f90 -obug8
C:\gfortran\clf\testpattern>bug8
45434241
As can be seen, gfortran in this context did accept a TRANSFER
from a C_PTR to an integer in an initialization expression, but not
in my program.
As a side note about PR46825 and PR46917: to reproduce these ICE
reports you probably need to test with 32-bit versions of gfortran
that were built after the fix for PR46678 went in:
C:\gfortran\clf\testpattern>gfortran -v
Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/gcc_equation/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.0/
lto-wrapper.exe
Target: x86_64-w64-mingw32
Thread model: win32
gcc version 4.6.0 20101218 (experimental) (GCC)
C:\gfortran\clf\testpattern>cd ..\PR46825
C:\gfortran\clf\PR46825>type PR46825.f90
MODULE GENFILE_TYPE
IMPLICIT NONE
TYPE VECTOR
PRIVATE
INTEGER :: FROM_ATOM
END TYPE VECTOR
TYPE GENFILE
PRIVATE
INTEGER :: VECTOR_COUNT
TYPE(VECTOR), DIMENSION(:), POINTER :: VECTORS
END TYPE GENFILE
CONTAINS
FUNCTION GET_VECTORS(GF)
TYPE(GENFILE), INTENT(IN) :: GF
TYPE(VECTOR), DIMENSION(GF%VECTOR_COUNT) :: GET_VECTORS
GET_VECTORS = GF%VECTORS
END FUNCTION GET_VECTORS
END MODULE GENFILE_TYPE
MODULE ENERGY_FUNCTION
USE GENFILE_TYPE
IMPLICIT NONE
TYPE(GENFILE), PRIVATE :: MY_GENFILE
TYPE(VECTOR), DIMENSION(:), ALLOCATABLE, PRIVATE :: VECTORS
CONTAINS
SUBROUTINE ENERGY_FUNCTION_SPECIAL_INIT()
VECTORS = GET_VECTORS(MY_GENFILE)
END SUBROUTINE ENERGY_FUNCTION_SPECIAL_INIT
END MODULE ENERGY_FUNCTION
C:\gfortran\clf\PR46825>gfortran -c PR46825.f90
C:\gfortran\clf\PR46825>cd ..\PR46917
C:\gfortran\clf\PR46917>gfortran -c PR46917.f90
C:\gfortran\clf\PR46917>type PR46917.f90
module random_integer_mod
implicit none
contains
function vec_block(ivec,block_size) result(jvec)
integer, intent(in) :: ivec(:)
integer, intent(in) :: block_size
integer :: jvec(size(ivec)*block_size)
jvec = 1
end function vec_block
!
function permute_blocks(nitems,block_size) result(ivec)
integer, intent(in) :: block_size,nitems
integer :: ivec(nitems)
integer :: nblocks
integer, allocatable :: jvec(:)
nblocks = 1
allocate (jvec(nblocks*block_size))
jvec = vec_block(permutation(nblocks),block_size)
ivec = 1
end function permute_blocks
!
function permutation(n) result(ivec)
integer, intent(in) :: n
integer :: ivec(n)
ivec = 1
end function permutation
end module random_integer_mod
But with the 32-bit version:
C:\gfortran\clf\PR46917>gfortran -v
Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/gcc_equation32/bin/../libexec/gcc/i686-pc-mingw32/4.6.0/l
to-wrapper.exe
Target: i686-pc-mingw32
Thread model: win32
gcc version 4.6.0 20101218 (experimental) (GCC)
C:\gfortran\clf\PR46917>gfortran -c PR46917.f90
PR46917.f90: In function 'permute_blocks':
PR46917.f90:18:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
C:\gfortran\clf\PR46917>cd ..\PR46825
C:\gfortran\clf\PR46825>gfortran -c PR46825.f90
PR46825.f90: In function 'energy_function_special_init':
PR46825.f90:30:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
James Van Buskirk
> As a side note about PR46825 and PR46917: to reproduce these ICE
> reports you probably need to test with 32-bit versions of gfortran
> that were built after the fix for PR46678 went in:
I tested with baf's build:
C:\gfortran\clf\PR46917>gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/gfortran32/bin/../libexec/gcc/i586-pc-mingw32/4.6.0/lto-w
rapper.exe
Target: i586-pc-mingw32
Configured with:
../gcc-trunk/configure --prefix=/mingw --enable-languages=c,for
tran --with-gmp=/home/brad/gfortran/dependencies --disable-werror --enable-threa
ds --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared --dis
able-win32-registry --with-dwarf2 --disable-sjlj-exceptions --enable-lto
Thread model: win32
gcc version 4.6.0 20101201 (experimental) [trunk revision 167359] (GCC)
And it's recent enough to have the fix for PR46678 and a 32-bit
Windows build, and indeed it does not suffer from PR46678, but
neither does it experience PR46825 nor PR46917 so my conjecture
about the alignment of the stars required to reproduce the latter
two bugs was incorrect.