[gmx-users] intel compiler + amd64: help needed.
David van der Spoel
spoel at xray.bmc.uu.se
Wed May 31 22:22:42 CEST 2006
Jones de Andrade wrote:
> Hi all!
> Ok, got what should be done. But now I have a (big) question: this code
> compiles properly with gcc. Ok, maybe that means difference of tolerance
> between different compilers. But the code also compiles with intel on
> intel machines, and seems to work properly on older amd machines (not
> quite sure if they need to be so old that there is no SSE even).
> Is there any possibility the compiler is messing out with us somehow?
> Cause the same machine, different compilers, would mean bogus or
> something comiler, but same compiler, differente machines (or different
> cpu manufacturer?), seems to mean evil economics practices. :(
> Is there any chance this "suppositions" could be right? And so, it would
> be useless to try to crack our heads on "debugging" for one specific
> compiler the more optimized code of the world?
> Thanks for everything in advance.
There may be a problem with arguments passing. The vararg mechanism is a
sleezy way of passing an arbitrary number of arguments to a function. It
is based on macros, and since arguments are passed as either ints,
doubles or strings, where ints may be 4 bytes and the others 8 bytes
there could be confusion in the compiler. We could probably make it
fool-proof, try attached file just for fun.
> On 5/31/06, *David Mathog* <mathog at caltech.edu
> <mailto:mathog at caltech.edu>> wrote:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00002aaaab15a88c in __find_specmb () from /lib64/tls/libc.so.6
> > (gdb) where
> > #0 0x00002aaaab15a88c in __find_specmb () from /lib64/tls/libc.so.6
> > #1 0x00002aaaab140e6f in vfprintf () from /lib64/tls/libc.so.6
> > #2 0x00002aaaab15e2a9 in vsprintf () from /lib64/tls/libc.so.6
> > #3 0x00002aaaab149568 in sprintf () from /lib64/tls/libc.so.6
> > #4 0x000000000040248b in mknb_code (format=0x40cd2e "s") at
> > mknb_metacode.c:282
> This says that there's a call to sprintf() at mknb_metacode.c line
> 282. Just before that call check all the parameters that will
> be passed to sprintf. You can do that in the debugger, but you
> might find it easier to just put a bunch of printf's in at that point.
> Looks like there's a a bad pointer in there somewhere. Once you
> figure out which variable is bogus trace back up through the following
> code with the debugger (or more printf's)
> > #5 0x0000000000401aaf in mknb_declare_real (name=0x7fffffffd0d0
> > "ix1,iy1,iz1,fix1,fiy1,fiz1") at mknb_metacode.c:104
> > #6 0x0000000000403e62 in mknb_declare_variables () at
> > mknb_declarations.c:258
> > #7 0x0000000000400fef in mknb_write_function () at mknb.c:154
> > #8 0x00000000004017cf in main (argc=1, argv=0x7fffffffd628) at
> until you find out where things have gone wrong.
> David Mathog
> mathog at caltech.edu <mailto:mathog at caltech.edu>
> Manager, Sequence Analysis Facility, Biology Division, Caltech
> gmx-users mailing list gmx-users at gromacs.org
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
David van der Spoel, PhD, Assoc. Prof., Molecular Biophysics group,
Dept. of Cell and Molecular Biology, Uppsala University.
Husargatan 3, Box 596, 75124 Uppsala, Sweden
phone: 46 18 471 4205 fax: 46 18 511 755
spoel at xray.bmc.uu.se spoel at gromacs.org http://folding.bmc.uu.se
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the gromacs.org_gmx-users