🚀 go-pugleaf

    David Linder writes:

>A central issue in the newmat08 package is the exception handling.  I was
>able to that turn off completely via a #define in its include.h file
>(provided for just that purpose) and got it to compile and run as a.out
>format with gcc-2.6.3 (which had no exception handling abilities).  Lucky,
>no?

>But then I tried it with gcc-2.7.0 in an unmodified Slackware3.0, and
>it failed at compile time with internal compiler errors.  
>Okay, so gcc-2.7.0's ability
>to understand exception handling may not have been perfected then (or
>the author's code could be faulty.. not my job to check)

    First of all, thanks for taking the time to look into this problem.

    Someone else responded via e-mail that he got newmat08 to compile
with gcc 2.7.0 by turning off exception handling as you did and fixing
some scoping problems.  gcc 2.7.2 generated a message for me to compile
with -fhandle-exceptions (or something like that) and that solved the
compile time exception problem for me.  It also generated warnings about
non-ANSI for loop scoping, but these were not errors so I did not change
the code.  So I guess that one could conclude that exception handling
should be turned off and perhaps that scoping should be brought up to
standard.  Part of the problem could be fixed, but ...


>Okay, now come to gcc-2.7.2, I got it to compile without choking (albeit
>I did this with an a.out libg++.a) but some of the executables run ok
>and some SIGSEGV.

    If you believe your machine's hardware to be OK then it looks like
there is a problem with gcc 2.7.2.  I'm perplexed by your willingness
to gaff off a seg fault with code that ran under a previous version.
What I'm trying to determine is whether or not gcc 2.7.2 is reliable
under Linux, and it looks like it is not.

 
>I have no understanding of the D.Schulze's gripes about the "free" 
compiler (gcc)

    If there was an alternative I would be willing to pay a reasonable
price for it, but as long as gcc is supported it is unlikely that anyone
will offer a commercial alternative.  The gcc maintainers need to offer
a reliable product even if it is free, or they should stop supporting it
so that someone can offer a reliable commercial alternative.  Breaking
lots of existing code is a bad thing to do.  (I'll conceed that it hasn't
been proven yet that gcc 2.7.2 is at fault, but it sure looks like it.
Maybe we all have bad hardware.)


>There are no optimization switches 
>turned on in the newmat08's "gnu.mak" makefile.  Apparently the author 
>didn't think that the code would work with optimizations (or he would 
>have included an alternate set of lines with them..?).

    This is a non-sequitur.  I recall nothing in the newmat08 documentation
about problems optimizing under certain platforms.

    OK, David, you think it is alright that gcc 2.7.2 can't implement
exception handling and can't optimize because it is free.  This is a sad
statement about gcc.  Why do you make apologies for it?

    I just want reliable tools, and so far it looks like gcc 2.7.2 is
unreliable.


Dean Schulze