Menu
▾
▴
[Mingw-notify] [ mingw-Bugs-694909 ] -msse, -msse2 causes 3047: internal error
|
From: SourceForge.net <no...@so...> - 2004-07-27 02:10:11
|
Bugs item #694909, was opened at 2003-02-28 21:18 Message generated for change (Comment added) made by dannysmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=694909&group_id=2435 Category: gcc Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dan Mathews (danwmathews) Assigned to: Danny Smith (dannysmith) Summary: -msse, -msse2 causes 3047: internal error Initial Comment: -msse, -msse2 causes 3047: internal error: Arithmetic exception Running Windows XP, Pentium Pro, msys, mingw, all latest versions as I just downloaded them 3 days ago and also installed all available package updates, gcc (GCC) 3.2.2 (mingw special 20030208-1). Error is totally reproducable and independent of which program is being compiled/linked. ---------------------------------------------------------------------- >Comment By: Danny Smith (dannysmith) Date: 2004-07-27 14:10 Message: Logged In: YES user_id=11494 FIXED IN 3.4.1 ---------------------------------------------------------------------- Comment By: Dan Mathews (danwmathews) Date: 2003-03-06 15:03 Message: Logged In: YES user_id=722870 Danny: My purpose in trying the GCC compiler was purely practical - the version of C++ I have on my "main" machine is Visual Studio .NET (which is _not_ an optimizing compiler when compiling to native machine code). (I also have Visual Studio 5.0 available on an old machine that I use primarily as a file/print server; it's a pain in the rear to have to go into the closet to use it.) My interest is purely in doing the maximum amount of optimization possible. This is because the VS .NET native executables run _very_ slowly. (In one case, for a CPU-bound program, the Visual Studio .NET executable took more than 34 times longer than the optimized GNU program.) This is the reason for all of the compiler switches (plus turning on possible warnings...). Also, without all of the optimizations, the GNU executable was only about 10% (rather than 34 times) faster than the .NET executable, meaning there is no point for me in doing this exercise if the optimization options are not turned on. (As a comparison, the VC 5.0 optimized executable was 15 times faster than the .NET executable.) What you don't know is that I have tried various combinations of switches using a binary-search technique (a slow and laborious process) and have only gotten other errors (or even worse, programs that simply didnt work) which I _didnt report. (One program, a simple calculator program whose source I handed out as a demo back when I taught C/C++, not only doesnt work, but produces output indicating that there are _multiple_, unrelated, bugs in the generated code I consistently get wrong answers without there being a detectable pattern, and in many cases the incorrect answers are obviously the results of bugs in at least _two_ places in the generated executable (the wrong answer formatted incorrectly).) So far, out of 5 real programs that I have tried to compile with the GNU compiler, only _one_ has produced a real, _working_, executable! Most of these are (years-) old programs that I was doing minor enhancements to or was trying to use as a benchmark, and they have gone through many iterations of the Microsoft compilers (and in some cases, compilers for other machines) without problem. I will also note that these programs compile with few or no warnings even on the GNU compiler with all of the warning switches turned on i.e., they are _valid_ C/C++ programs that do not depend on machine dependent or unspecified behaviors. The bottom line??? I am trying to use GCC/G++ as a working compiler in a semi-production environment, not as something to play around with. Frankly, I don't have the time or inclination to do hundreds of experiments to try to find out what I am doing wrong/not doing wrong in a program or to determine what options work/dont work to debug the compiler for you guys. These are _real_ compiler errors, not some spurious side-effects of badly formed/written programs. (Look at the resolution for [694909] -msse, -msse2 causes 3047: internal error, which has been submitted to gcc.gnu.org, for an example of this fact.) So far, I am truly disappointed to say, gcc/g++ has failed miserably for me. So for now Ill simply go back to tromping upstairs into the closet to use VC5.0, it may not be as fast as GNU at its best, but at least it _works_. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2003-03-04 17:44 Message: Logged In: YES user_id=30442 Here is a reduced test case: int main(void) { int *p; int Tape[10]; for (p = Tape; p < Tape + 10; *(p++) = 0); return 0; } This causes the ICE when compiled as: gcc -c arith_bug.c -fprefetch-loop-arrays -fstrength-reduce -O - msse (with at least GCC versions 3.1 through 3.2.2) Please report this to the GCC bug tracking system at gcc.gnu.org because IMHO it is unlikely to be MinGW- specific. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2003-03-04 17:44 Message: Logged In: YES user_id=30442 Here is a reduced test case: int main(void) { int *p; int Tape[10]; for (p = Tape; p < Tape + 10; *(p++) = 0); return 0; } This causes the ICE when compiled as: gcc -c arith_bug.c -fprefetch-loop-arrays -fstrength-reduce -O - msse (with at least GCC versions 3.1 through 3.2.2) Please report this to the GCC bug tracking system at gcc.gnu.org because IMHO it is unlikely to be MinGW- specific. ---------------------------------------------------------------------- Comment By: Dan Mathews (danwmathews) Date: 2003-03-01 16:57 Message: Logged In: YES user_id=722870 Here's a zip file containing all of the supporting files... ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-03-01 16:47 Message: Logged In: YES user_id=11494 Please try to upload your testcase again. It's missing. Danny ---------------------------------------------------------------------- Comment By: Dan Mathews (danwmathews) Date: 2003-03-01 12:25 Message: Logged In: YES user_id=722870 It happens when I try to compile a program. (As far as SSE and the Pentium is concerned, I couldn't (and still can't) remember whether it's AMD or Intel that has SSE instructions so I thought I would add it to see what happens...) Attached is _everything_ you need: A complete transcript (input and output) of the commands I used to both produce and not produce this error. All of the batch files used in the process. The source code of the shortest of one of the many programs that produced this error. Please feel free to get back to me if you need anything else/have any questions. ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2003-02-28 21:36 Message: Logged In: YES user_id=30442 Even though it may be independent of the program for you, it would help to have a tiny example program and the exact command you use to build it, just to be sure. Is this error generated by GCC when you try to compile the program, or by Windows when you run it, or what? If the problem occurs when you run the program then surely it is because Pentium Pro processors don't support SSE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=694909&group_id=2435 |