Volodymyr Babin wrote:
> Hi everyone,
>
> I take my hat off to Joe for his recent efforts regarding the
Me too; it's difficult work, but will have a long term benefit for everyone.
> locmem & 'implicit none'. OTOH, upon 'cvs update -d' I am getting:
>
> No file name associated with module xray_interface_module
> make: *** [depend] Error 1
I was seeing that too; I think I fixed it by removing the depend file in
the sander dir.
In addition, the new memory_module.f code is exposing a weird bug in
RHEL4's gfortran. The issue is not with the code, but is with the compiler.
[mjw:sander]$ gfortran -v
Using built-in specs.
Target: x86_64-redhat-linux5E
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--with-gxx-include-dir=/usr/include/c++/3.4.3 --enable-libgcj-multifile
--enable-languages=c,c++,java,f95 --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=x86_64-redhat-linux5E
Thread model: posix
gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
fails:
======
[mjw:sander]$ gfortran -c -O0 -fno-second-underscore -ffree-form -g
-Wall -o memory_module.o _memory_module.f
_memory_module.f: In function âmory_initâ_memory_module.f:507: internal
compiler error: in modified_type_die, at dwarf2out.c:8495
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:
http://bugzilla.redhat.com/bugzilla> for instructions.
works:
======
gfortran -c -O0 -fno-second-underscore -ffree-form -g -Wall -o
memory_module.o _memory_module.f
Hence, it is the -g flag that is the issue here. I don't think a typical
user will see this since I'm using AMBERBUILDFLAGS=-g -Wall , however it
would be nice to get a fix. I think it is related to the nesting of
set_coor_array() in memory_init(), if one comments out that section, the
bug goes away and it compiles:
contains
!subroutine set_coor_array(ptr,x)
! _REAL_, pointer :: ptr(:,:)
! _REAL_, target :: x(3,natom)
! ptr => x
!end subroutine set_coor_array
end subroutine memory_init
Taking this one step further, if one moves this outside of
memory_init(), the problem is fixed:
return
end subroutine memory_init
subroutine set_coor_array(ptr,x)
_REAL_, pointer :: ptr(:,:)
_REAL_, target :: x(3,natom)
ptr => x
end subroutine set_coor_array
end module memory_module
I will do some more research on this and submit a bug report to Redhat.
I've not tested this with any other versions of gfortran, but will do
soon once I'm done with the charmm CMAP stuff.
It is alway difficult in this situation when one hits a compiler bug.
Within the reporting process, it is pretty much essential to supply some
example code that triggers the issue. This is not really an option when
dealing with a closed source section of code and hence one has to
develop a stand alone example which can take a lot of time.
Joe, can I apply the fix of moving set_coor_array() outside of
memory_init() for this moment in time?
regards,
Mark
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Mar 29 2009 - 01:17:24 PDT
