gcc (GCC) 3.3 20030718 (Gentoo Linux 3.3-r1, propolice) When building openssl-0.9.7b on my Pentium3 (coppermine) machine, I get openssl-0.9.7b/crypto/mem_clr.c: internal compiler error: Floating point exception (I will attach the intermediate output from cpp for reporting to GCC maintainers) I have narrowed this one down to a "collision" between the "-march=pentium3" switch that I specified in my CFLAGS and the switch hard-coded into the openSSL configure system: "-mcpu=pentium". Attached is a patch to the ebuild which removes the -mcpu optimization if -march is in CFLAGS. This worksforme. (This is more properly a GCC bug, but it arises because of a peculiarity in the openSSL build, so I fix the openSSL ebuild...) Reproducible: Always Steps to Reproduce: 1. 2. 3. This occurred in a stage2 installation; after bootstrap.sh I emerged gcc-3.3-r1 before proceeding with a "emerge system".
Created attachment 15155 [details, diff] Patch to openssl-0.9.7b.ebuild to correct compiler flags
Created attachment 15156 [details] Compiler output that caused gcc to crash (long) This is the file that the crash report from GCC instructed me to report to the GCC maintainers.
got same error, but fix it by filtering -fprefetch-loop-arrays flag. After that, compiles fine, and no change to -march (which BTW, I use -march=pentium4)
Created attachment 15335 [details, diff] fprefetch-loop-arrays filter flag filter -fprefetch-loop-arrays flag to enable gcc-3.3 compilation
I can compile openssh by removing the mcpu flag if-and-only-if the march flag is specified in CFLAGS -- which means that you can keep the -fprefetch-loop-arrays flag. Did my new ebuild not work for you? I am using Pentium III (x86 coppermine).
Its the combination with then the mismatched -march and -mcpu ... : -------------------------------------------------------------------- azarah@nosferatu tmp $ cat t1.c #include <string.h> unsigned char cleanse_ctr = 0; void *ptr; size_t len; void cleanse(void *ptr, size_t len) { unsigned char *p = ptr; size_t loop = len; while(loop--) { *(p++) = cleanse_ctr; cleanse_ctr += (17 + (unsigned char)((int)p & 0xF)); } if(memchr(ptr, cleanse_ctr, len)) { cleanse_ctr += 63; } } azarah@nosferatu tmp $ gcc -c t1.c -march=pentium3 -mcpu=pentium -O2 -fprefetch-loop-arrays t1.c: In function `cleanse': t1.c:18: internal compiler error: Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions. Preprocessed source stored into /tmp/cc6DARhi.out file, please attach this to your bugreport azarah@nosferatu tmp $ gcc -c t1.c -march=pentium3 -mcpu=pentium3 -O2 -fprefetch-loop-arrays azarah@nosferatu tmp $ gcc -c t1.c -march=pentium3 -mcpu=pentium2 -O2 -fprefetch-loop-arrays azarah@nosferatu tmp $ gcc -c t1.c -march=pentium2 -mcpu=pentium -O2 -fprefetch-loop-arrays cc1: warning: -fprefetch-loop-arrays not supported for this target (try -march switches) azarah@nosferatu tmp $ gcc -c t1.c -march=pentium4 -mcpu=pentium -O2 -fprefetch-loop-arrays t1.c: In function `cleanse': t1.c:18: internal compiler error: Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions. Preprocessed source stored into /tmp/ccQT53sX.out file, please attach this to your bugreport azarah@nosferatu tmp $
Yes, that is clear to me. See the first patch of this bug which modifies the ebuild to fix this. It has little or nothing to do with prefetch-loop-arrays, I think. Or maybe prefetch-loop-arrays triggers it too. Anyway, I think my first patch should be applied. Thanks!
Right, but -march=foo imply -mcpu=foo, so I do not know how valid it is to not set them the same, or at least set -mcpu lower than -march ....
Yes, that's correct. So my patch modifies the ebuild so that the -mcpu flag is REMOVED IFF -march is defined in CFLAGS. This would avoid any conflict, between the two flags, I think.
why not always patch it out ... that way if user wants to use debug flags or whatever, they dont have to worry about it
Its an option, but we should submit to the gcc guys as a bug. I will try to do that somewhere tomorrow. Here is the latest version of the code that cause the issue (more compact): ------------------------------------- void foofunc(void *ptr, int len) { unsigned char *p = (char *)ptr; unsigned char ctr = 0; int loop = len; while(loop--) *(p++) = ctr; }
*** Bug 25518 has been marked as a duplicate of this bug. ***
OpenSSL 0.9.7b-r2 commited.
