Greetings, I finally have taken the time to look at our nightly builds of scipy for win32 and noticed that specfun is not compiling--as some have reported here: http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/002 457.html and a link to the threaded discussion is here: http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/thr ead.html Specifically you get an 'internal compiler error' when you have -O3 set (using no optimization setting seems to work). I've tried it with gcc ~3.2 and it compiles fine but 3.2.3 and a 3.3.1 (that comes with cygwin) were not able to compile it. Since specfun.f is a rather large file it would be impossible for me to reduce this to a simple case for reporting to the g77 folks or finding a workaround. Does anyone (Travis O.?) want to take a stab at this? (It would stink to have to specify gcc 3.2 or below as a build requirement on windows.) Thanks, Travis BTW Here's what I get with gcc 3.3.1: ....<a bunch of warnings>... Lib\special\specfun\specfun.f: In subroutine `cgama': Lib\special\specfun\specfun.f:7786: warning: `y1' might be used uninitialized in this function Lib\special\specfun\specfun.f:7794: warning: `na' might be used uninitialized in this function Lib\special\specfun\specfun.f: In subroutine `aswfb': Lib\special\specfun\specfun.f:7871: warning: `sw' might be used uninitialized in this function Lib\special\specfun\specfun.f:7881: Internal compiler error in emit_swap_insn, a t reg-stack.c:990 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.mingw.org/bugs.shtml> for instructions. warning: build_py: package init file 'Lib\tests\__init__.py' not found (or not a regular file) warning: build_py: package init file 'c:\temp\2.1\scipy\Lib\cluster\tests\__init __.py' not found (or not a regular file) warning: build_py: package init file 'c:\temp\2.1\scipy\Lib\fftpack\tests\__init __.py' not found (or not a regular file) ...<more warnings>... ........................ Travis N. Vaught Enthought, Inc. (512)536-1057 http://www.enthought.com ........................
Travis N. Vaught wrote:
Greetings,
I finally have taken the time to look at our nightly builds of scipy for win32 and noticed that specfun is not compiling--as some have reported here:
http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/002 457.html
and a link to the threaded discussion is here:
http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/thr ead.html
Specifically you get an 'internal compiler error' when you have -O3 set (using no optimization setting seems to work).
I've tried it with gcc ~3.2 and it compiles fine but 3.2.3 and a 3.3.1 (that comes with cygwin) were not able to compile it.
I went through this same process and discovered it as well. I will try to localize the error to one subroutine and submit it as a bug-report to the g77 people. I agree that it is a pain to have to eliminate -O3 for one file.
On Mon, 19 Jan 2004, Travis N. Vaught wrote:
Greetings,
I finally have taken the time to look at our nightly builds of scipy for win32 and noticed that specfun is not compiling--as some have reported here:
http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/002 457.html
and a link to the threaded discussion is here:
http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/thr ead.html
Specifically you get an 'internal compiler error' when you have -O3 set (using no optimization setting seems to work).
I've tried it with gcc ~3.2 and it compiles fine but 3.2.3 and a 3.3.1 (that comes with cygwin) were not able to compile it.
Since specfun.f is a rather large file it would be impossible for me to reduce this to a simple case for reporting to the g77 folks or finding a workaround. Does anyone (Travis O.?) want to take a stab at this? (It would stink to have to specify gcc 3.2 or below as a build requirement on windows.)
One possible workaround that might be worth to try is to separate the two offending functions (RMN2L and ASWFB) in specfun.f to two different files (rmn2l.f and aswfb.f). Hopefully, g77 will compile them with -O3. If not, then at least the sizes of files are much smaller in order to find a workaround. Note that I am currently working on scipy_distutils and there might be a simple way to use different compiler flags for different sources. But in order to keep it simple, the sources should reside in different directories (that should contain setup.cfg files where it is possible to enable/disable optimization flags). So, this gives another solution if nothing else will work. Pearu
Pearu Peterson wrote:
One possible workaround that might be worth to try is to separate the two offending functions (RMN2L and ASWFB) in specfun.f to two different files (rmn2l.f and aswfb.f). Hopefully, g77 will compile them with -O3. If not, then at least the sizes of files are much smaller in order to find a workaround.
I have taken aswfb out of the specfun file and now the rest of the specfun.f file compiles normally. The extracted subroutine still gives the error which I will submit to the gcc bug database. It would appear that it is -O3 and -funroll-loops flags together that give the problem (any other combination of the flags does not seem to reproduce the error for me). What error are you getting on rmn21.f ? I don't see any error there. -Travis O.
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
On Mon, 19 Jan 2004, Travis Oliphant wrote:
Pearu Peterson wrote:
One possible workaround that might be worth to try is to separate the two offending functions (RMN2L and ASWFB) in specfun.f to two different files (rmn2l.f and aswfb.f). Hopefully, g77 will compile them with -O3. If not, then at least the sizes of files are much smaller in order to find a workaround.
I have taken aswfb out of the specfun file and now the rest of the specfun.f file compiles normally. The extracted subroutine still gives the error which I will submit to the gcc bug database.
Have you played with the loops and the code of this function? May be recoding with a different style might cause g77 to succeed?
It would appear that it is -O3 and -funroll-loops flags together that give the problem (any other combination of the flags does not seem to reproduce the error for me).
If that is the case then we can disable -funroll-loops instead of -O3 for bugy gcc versions, -O3 should be more useful than unrolling loops. This is very simple in build_flib.py. Could you sum up under which conditions the compiler bug appears? The following information should be enough: os.name os.uname sys.platform g77 --version # only the version numbers when there is a failure # and when not. Then I can make a patch to build_flib.py to resolve this issue.
What error are you getting on rmn21.f ?
I took this information from http://www.scipy.org/site_content/mailman?fn=scipy-user/2004-January/002459....
I don't see any error there.
Good. Pearu
Hi I have been looking into this problem and submitted it as a bug to the MinGW people (I'll put the bug report at the end of this email). The reply I got from them was: ======================================================= Comment By: Danny Smith (dannysmith) Date: 2004-01-10 09:45 This is a gcc bug that is fixed in gcc 3.3.3 and trunck sources. Danny ======================================================= I was hoping that mingw + gcc 3.3.3 would arrive soon enough and make this go away? Best regards Brett ============================ Original bug report to mingw Category: gcc Group: None
Status: Closed Resolution: Fixed Priority: 5 Submitted By: Brett Olivier (bgoli) Assigned to: Danny Smith (dannysmith) Summary: g77 (gcc 3.3.1) emit_swap_insn internal compiler error
Initial Comment: A specific combination (-O3 -funroll-loops - march=pentium3) of compiler flags causes g77 to fail with an internal compiler error with the attached routines Compile command: g77 -Wall -fno-second-underscore -O3 -funroll-loops - march=pentium3 -malign-double -fomit-frame-pointer -c specfun_error_func.f -o specfun_error_func.o Output: specfun_error_func.f: In subroutine `rmn2l': specfun_error_func.f:32: warning: `sw' might be used uninitialized in this funct ion specfun_error_func.f:38: warning: `lg' might be used uninitialized in this funct ion specfun_error_func.f:45: warning: `np' might be used uninitialized in this funct ion specfun_error_func.f:47: warning: `eps1' might be used uninitialized in this fun ction specfun_error_func.f:69: warning: `eps2' might be used uninitialized in this fun ction specfun_error_func.f:75: internal compiler error: in emit_swap_insn, at reg-stac k.c:987 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.mingw.org/bugs.shtml> for instructions. After playing around a bit I found the following two workarounds that allow me to compile these two functions. Current workaround (1) remove flag: -O3 ================= Compile command: g77 -Wall -fno-second-underscore -funroll-loops - march=pentium3 -malign-double -fomit-frame-pointer -c specfun_error_func.f -o specfun_error_func.o Output: compiles OK Current workaround (2) remove flags: -funroll-loops -march=pentium3 ================= Compile command: g77 -Wall -fno-second-underscore -O3 -malign-double - fomit-frame-pointer -c specfun_error_func.f -o specfun_error_func.o Output: compiles OK Environment ========= OS == Windows 2000 SP 4 gcc -v ====== Reading specs from c:/mingw/bin/../lib/gcc- lib/mingw32/3.3.1/specs Configured with: ../gcc/configure --with-gcc --with-gnu- ld --with-gnu-as --host= mingw32 --target=mingw32 --prefix=/mingw --enable- threads --disable-nls --enable -languages=c,c++,f77,objc,ada,java --disable-win32- registry --disable-shared --e nable-sjlj-exceptions --enable-libgcj --disable-java-awt - -without-x --enable-ja va-gc=boehm --disable-libgcj-debug --enable- interpreter --enable-hash-synchroniz ation Thread model: win32 gcc version 3.3.1 (mingw special 20030804-1) ld -v ==== GNU ld version 2.13.90 20030111 MinGW installer + updates =================== MinGW-3.1.0-1.exe binutils-2.13.90-20030111-1.tar.gz gcc-core-3.3.1-20030804-1.tar.gz gcc-g++-3.3.1-20030804-1.tar.gz gcc-g77-3.3.1-20030804-1.tar.gz mingw-runtime-3.2.tar.gz w32api-2.4.tar.gz ----------------------------------------------------------------------
Comment By: Danny Smith (dannysmith) Date: 2004-01-10 09:45
Message: Logged In: YES user_id=11494 This is a gcc bug that is fixed in gcc 3.3.3 and trunck sources. Danny ----------------------------------------------------------------------
On Mon, 19 Jan 2004, Travis N. Vaught wrote:
Greetings,
I finally have taken the time to look at our nightly builds of scipy for win32 and noticed that specfun is not compiling--as some have reported here:
Note that I am currently working on scipy_distutils and there might be a simple way to use different compiler flags for different sources. But in order to keep it simple, the sources should reside in different directories (that should contain setup.cfg files where it is possible to enable/disable optimization flags). So, this gives another solution if nothing else will work.
Pearu
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
-- Brett G. Olivier (bgoli at sun . ac . za) Biochemistry Dept, Stellenbosch University Tel: +27-21-8085871 Fax: +27-218085863
It looks like several people are working on this at once. I have heard that this bug in gcc 3.3.1 is fixed in later versions of gcc. I altered the fortran file so that an uniitialized variable is now initialized prior to a loop and this seems to avoid the compiler bug. Please check the new specfun.f file to see if it works right without any other compiler tweaking... It seems to for me. -Travis O.
On Mon, 19 Jan 2004, Travis Oliphant wrote:
It looks like several people are working on this at once.
I have heard that this bug in gcc 3.3.1 is fixed in later versions of gcc.
I altered the fortran file so that an uniitialized variable is now initialized prior to a loop and this seems to avoid the compiler bug.
Please check the new specfun.f file to see if it works right without any other compiler tweaking...
It seems to for me.
I think this is just great! Such a small change will make recent scipy available to a large number of Windows users after so long time.. Thanks, Pearu
participants (4)
-
Brett G. Olivier -
Pearu Peterson -
Travis N. Vaught -
Travis Oliphant