This might be a bug in any of the following: - gcc/f951 - gmp - mpfr - Sun system libraries - binutils - UltraSPARC-IIe (not likely, but you never know)
Of course, there is always possibility it was just me doing something stupid. If there is any way (or test) to check if bug is in f951 or not in f951, please let me know. So far, I had the problem only with gcc/f951 generated code on this machine (relatively bussy box that was running all kind of stuff in the past 3 years). So it's either gcc/f951, or some obscure bug in other component(s) that gets triggered only by gcc/f951. When I compile sample Fortran hello world program, it produces different output depending on which machine it is run (if dynamically linked). Or depending on which machine it was compiled on (if statically linked). Statically linked binary shouldn't include any machine-specific code (libc_psr is shared-only library, there's no libc_psr.a). However, f951 itself gets dynamically linked against this system library which is processor dependant. I've downloaded the "hello world" program from the net. Haven't done Fortran in long time, but looking at it, it should print "Hello, world." in endless loop. Running "uname -a" shows: $ uname -a SunOS apollo 5.9 Generic_112233-04 sun4u sparc SUNW,UltraAX-e2 Solaris When compiled with -m32 and run on SUNW,UltraAX-e2 machine (output of uname -i), the program exits immediatelly with no output. When compiled with -m64, it works correctly. If I copy the 32bit program (including libgfortran and libgcc_s libraries) to any other machine (tested on UltraSPARC-II and UltraSPARC-IIi) it works correctly. If I compile the program statically on SUNW,UltraAX-e2 machine, and then copy it to different machine, it doesn't work. If I compile the program statically on any other machine, and copy it to SUNW,UltraAX-e2 machine, it works correctly. $ ldd a.out libgfortran.so.0 => /opt/pbl/lib/libgfortran.so.0 libm.so.1 => /usr/lib/libm.so.1 libgcc_s.so.1 => /opt/pbl/lib/libgcc_s.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,UltraAX-e2/lib/libc_psr.so.1 $ ldd /opt/pbl/libexec/gcc/sparc-sun-solaris2.9/4.0.2/f951 libmpfr.so.1 => /opt/pbl/lib/libmpfr.so.1 libgmp.so.3 => /opt/pbl/lib/libgmp.so.3 libc.so.1 => /usr/lib/libc.so.1 libgcc_s.so.1 => /opt/pbl/lib/libgcc_s.so.1 libdl.so.1 => /usr/lib/libdl.so.1 /usr/platform/SUNW,UltraAX-e2/lib/libc_psr.so.1 gcc 4.0.2: ../configure --prefix=/opt/pbl --with-local-prefix=/opt/pbl --with-cpu=ultrasparc --with-tune=ultrasparc --enable-languages=c,ada,c++,f95,java,objc --disable-nls --with-gmp=/opt/pbl --with-mpfr=/opt/pbl --with-gnu-ld --with-gnu-as --with-ld=/opt/pbl/bin/ld --with-as=/opt/pbl/bin/as --enable-java-awt=xlib --with-x gmp 4.1.4: ../configure --build=sparc-sun-solaris2.9 --enable-cxx --enable-shared --enable-static --with-readline --with-gnu-ld mpfr 2.2.0 (with all recommended patches): ../configure --prefix=/opt/pbl --with-gmp=/opt/pbl --enable-static --enable-shared binutils 2.16: ../configure --prefix=/opt/pbl --exec-prefix=/opt/pbl --with-mpfr=/opt/pbl --with-gmp=/opt/pbl --enable-shared --disable-nls --enable-64-bit-bfd I also did couple of test installations into my home directory (gcc/gmp/mpfr/binutils) and was able to reproduce the problem every time. I have only one UltraSPARC-IIe box (500MHz processor), so can't tell if the problem is repeatable on every one of them. It is on mine. -- Summary: executable generated by f951 doesn't work with 32-bit SUNW,UltraAX-e2 (UltraSPARC-IIe) shared libc_psr.so.1 Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alex at milivojevic dot org GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25998