🚀 go-pugleaf

Dean Schulze (schulze@lpl.arizona.edu) wrote:
: Please list your gcc-version, your libc version,

:     The code that crashes gcc for me is the newmat08 package:
:     ftp tahi.isor.vuw.ac.nz  in pub/newmat08

First and foremost, the helpfile "newmata" of the newmat08 package
says:
> The package is designed for version 2 or 3 of C++. It works with Borland 
> (3.1 & 4.0), Microsoft (7 & 8) and Watcom (10) C++ on a PC and AT&T C++ 
> (2.1 & 3) and Gnu G++ (2.3.3, 2.5.8 & 2.6.0). It works with some 
> problems with Zortech C++ (version 3.04).

So perhaps one might ask, if newmat08 doesn't compile/run clean under
gcc-2.7.2 (g++) then which is "in the wrong", the compiler or the code?
It certainly looks as if newmat08's author is quite aware that the code
compiles only on certain platforms/compilers.

Another example, the LAPACK++ (LAPACK for C++) package didn't compile
on gcc versions above 2.6.3, because of the way that the ANSI C++ standard
had redefined the declaration of the complex class.  So gcc-2.7.0 (g++)
would choke on it, because it expected the new standard.  Who's in the wrong
here??  Turn that idea on its head: if one tried to compile C++ code that
satisfied the ANSI (draft?) standard w.r.t. complex class on, say, a 
commerical compiler that didn't yet accept it then would one be correct 
to say that the code is in the wrong?  Sure it would be nice if the ANSI
C++ standard (and gcc's rapid development pace to keep up with it) would
settle down.  Maybe some like me were spoiled by gcc-2.5.8's long lifetime.
But at least gcc makes the attempt to keep up.  Look at newmat08's code
again: gcc successfully notes the usage of an older (old ANSI) name lookup 
for `for' scoping, and copes with it.

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).  Hey, so
what, gcc's free.  Anyone who wants to do better is free to hack on
gcc's source code...  The same thing can be said for C++ matrix classes,
anyone who doesn't like free packages like newmat08 or LAPACK++ can
write their own.

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.  The original poster complained that his executables
caused an internal error in DDD.  I was able to run gdb on mine, fiddle
with the handling of some SIGxxx's, all ok.  Maybe somebody *can* 
deduce where and why the code segfaults.  And maybe they can deduce 
whether it's a problem with the code (which makes no claim to compile 
under gcc-2.7.2!!) or with gcc-2.7.2's exception handling. (..to be 
perfected?  Film at 11..)  If it's gcc's problem then submit a bug-report.

I have no understanding of the D.Schulze's gripes about the "free" 
compiler (gcc).  To complain in spite of the newmat08's clear
indication that it probably won't compile/run everywhere (and that
exception handling is a big issue with it) seems obtuse to me.
As for the complaint that this is a "Linux" problem per se, well, gcc
is widely used on many architectures (not just because it is free, but
because it is "less bad" than some commercial, native C++ compilers, IMHO).

By the way, on one machine I got one signal(11) error while compiling
that wasn't reproducible.  I tried again and it was ok.  And gcc
told me to send a bug report to, umm, bug-g++@prep.ai.mit.edu or
somewhere, which of course I ignore because that's a hardware problem.
It is somewhat confusing that this is a similar message to the one
that gcc-2.7.0 gives reproducibly for compiling this code.

Lastly, D.Schulze complained that problems cropped up when he tried to 
compile with optimization turned on.  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 combined with 
the fact that the makefile is written to force removal by hand of 
certain hard-linked files for re-compiling is to me a hint that the 
author expects us to compile just once, with no optimizing.  Not all code 
can be safely compiled with optimizing -- to expect otherwise seems 
self-defeating.

Dave Linder
dwl@apmaths.uwo.ca
http://pineapple.apmaths.uwo.ca/~dwl