#309 Zip files are available for bugs 696297 and 696305

gcc (462)
Dan Mathews

I apologize if this wasn't a good idea, but I wanted to make sure that
someone knew that the appropriate zip files are available (and
uploaded) for bugs "[696297] Compiler says it's unable to find a
spill reg, bails out" and "[696305] compiler internal error:
Segmentation fault"


  • Danny Smith

    Danny Smith - 2003-03-05

    Logged In: YES

    If you want anyone to take your bug reports seriously,
    please make the effort of attempting to narrow down
    your compiler switches to a minimal set that causes the
    bug. Simply adding every compiler switch that you can
    find makes it very difficult to diagnose anything. Some
    of the compiler switches may be inappropriate for the
    target. The fact that gcc does not diagnose that is a
    bug. But don't expect somebody else to help unless you
    show some sign of putting in effort yourself.


  • Dan Mathews

    Dan Mathews - 2003-03-06

    Logged In: YES


    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 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 only 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_.

  • Danny Smith

    Danny Smith - 2004-07-27
    • status: open --> closed
  • Danny Smith

    Danny Smith - 2004-07-27
    • status: closed --> closed-duplicate
  • Earnie Boyd

    Earnie Boyd - 2013-01-31
    • Description has changed:


    • status: closed-duplicate --> closed
    • resolution: --> duplicate
    • category: --> Duplicate
    • milestone: --> OTHER

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks