Sorry about the incomplete update. I had meant to commit just the
implicit-none fix, but included some updated files that referenced the
memory_module.f file, so I have submitted the rest of my code.
Mark Williamson wrote:
> 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.
>
The makedepend problem is because the script does not consider #ifdefs
in determining dependencies, which I did not consider. So, I have added
my xray source files. They are still incomplete, but are not compiled
without manually #defining the _XRAY cpp macro.
>
>
> 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?
>
Gfortran is so full of bugs, I am surprised it actually works most of
the time. It's OK to move set_coor_array() outside of memory_init(), but
it needs an natom argument added. Go ahead and update it, and make sure
it works for your gfortran. If not, just put an "#if 0" block for now.
Joe
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Mar 29 2009 - 01:18:01 PDT
