Description of problem: Loading saved data files in Octave from Fedora Extras crashes with an illegal instruction when run on older processors. This should not happen since everything in Core and Extras is compiled with "-march=i386". This was originally reported by a user on the octave mailing list who discovered it on a K6-3 processor. I was able to duplicate this on a Pentium MMX, but not on a Centrino laptop (I think that's roughly equivalent to a P-III, right?). That's all the test cases I can report so far. This was originally reported on the FC4 version of octave that was compiled February 1, which would probably have been compiled with the current release (gcc-4.0.2-8) or the one before. However, the P-MMX case I refered to was on a rawhide system (with a different octave version as well) and would have been compiled February 15 with one of the latest gcc-4.1 releases. I also did a test build of the FC4 version of Octave locally on my P-MMX rawhide system yesterday (gcc-4.1.0-3) and that version also crashed in the same way. Version-Release number of selected component (if applicable): gcc-4.0.2-8 (FC4) gcc-4.1.0-3 (Rawhide) How reproducible: Always Steps to Reproduce: 1. Run octave on a Pentium or K6 processor (possibly others) 2. In octave, run the following commands: octave:1> a=1; octave:2> save testfile.txt a octave:3> load testfile.txt Actual results: panic: Illegal instruction -- stopping myself... attempting to save variables to `octave-core'... save to `octave-core' complete Illegal instruction Expected results: Return to octave prompt, having successfully loaded the file.
Non-i586 instructions can make it into the binary or libraries it uses in many ways, of course I won't rule out GCC's fault now, but it is orders of magnitude less probable than octave or one of its dependencies compiled with e.g. -msse, -msse2, -mfpmath=sse, -march=i686, using inline asm with SSE etc. code or using assembly sources with the same. You need to find out which instruction was it, from which library (or octave main binary?) and in which routine, then look around if there is assembly used and/or with what flags that routine was compiled with.
OK, I have narrowed this down a little. The error occurs in the hdf5 library (also from Extras). The following test program will trigger the illegal instruction: #include "hdf5.h" int main() { return H5Fis_hdf5("hdf5test.c"); } compiling this with "gcc -o hdf5test -lhdf5 hdf5test.c" and running gives an illegal instruction. In gdb the error message says it occurs at: 0x00192353 in H5I_init_group () from /usr/lib/libhdf5.so.0 I looked at the spec file for compiling hdf5 and it is configured using the %configure macro, which would seem to imply that it is compiled with the -march=i386 flag. I don't believe there is any inline assembly in the library.
0007fae4 <H5I_init_group>: 7fae4: 55 push %ebp 7fae5: 57 push %edi 7fae6: 56 push %esi 7fae7: 53 push %ebx 7fae8: 83 ec 1c sub $0x1c,%esp 7faeb: e8 34 2d f9 ff call 12824 <__i686.get_pc_thunk.bx> 7faf0: 81 c3 14 d1 0b 00 add $0xbd114,%ebx 7faf6: 8b 6c 24 30 mov 0x30(%esp),%ebp 7fafa: 8b 74 24 34 mov 0x34(%esp),%esi 7fafe: 83 bb 3c 18 00 00 00 cmpl $0x0,0x183c(%ebx) 7fb05: b8 01 00 00 00 mov $0x1,%eax 7fb0a: 0f 45 83 3c 18 00 00 cmovne 0x183c(%ebx),%eax Of course cmovne is i686+ insn. The bug is in hdf5 configury apparently, see e.g. hdf5-1.6.5/config/gnu-flags hdf5-1.6.5/fortran/config/gnu-flags It does a very stupid thing - sets -march= depending on uname -m. Instead the src.rpm should patch it to use $RPM_OPT_FLAGS (if really needed and src/H5Tconv.c breaks strict aliasing, $RPM_OPT_FLAGS can be overridden e.g. with -O instead of -O2 in it by using "$RPM_OPT_FLAGS -O" or better yet "$RPM_OPT_FLAGS -fno-strict-aliasing" if that works.