A move away from CLN?

Richard B. Kreckel kreckel at thep.physik.uni-mainz.de
Tue Jul 31 15:20:44 CEST 2001


Talking about KAI's C++ compiler, I just tested it.  It definitely is a
frontend to the native compiler.  Where else do all the notes in the local
text sections `00000000 t gcc2_compiled.' come from?

Other than that they did a pretty good job in standard conformance.  There
are two little issues in CLN, namely in the lines
    cln/src/float/misc/cl_F_leastneg.cc:44
    cln/src/float/misc/cl_F_leastpos.cc:44
where you must manually change `&TheLfloat(erg)->data[0]' to
`&erg->data[0]'.  Dunno what's going wrong -- TheLfloat() is definitely
defined at this point of translation.  Then, static CLN indeed passed all
the tests.  This doesn't work for Debian, only for RedHat, because of this
gcc-2.96 insanity.

For GiNaC, I was less lucky.  I don't understand enough about this
compiler's template-resolution.  I keep getting errors of this form:
    archive.o(.text+0xbe9): undefined reference to 
    `void std::vector<T1, T2>::insert_aux(T2::pointer, const T1 &) 
     [with T1=GiNaC::archive_node::property_info, 
           T2=std::allocator<GiNaC::archive_node::property_info>]'
The occurrence of `::insert_aux' hints at some problem in their library,
since this is not declared in GiNaC or the standard.  Duraid, does this
ring a bell to you?  How do you link your stuff with KAI C++?

The very idea of having a C++ compiler produce C code for the system's 
native compiler appears as deeply anachronistic to me.  There are some
things that you'll *never* get correct with this approach and they will
make life difficult.  Consider inline functions which are just expanded at
the appropiate place prior to feeding them to the native compiler.  If
something goes wrong at this point the native compiler will later
be faced with unresolved mangled names and you'll see error messages of
unbelievable verbosity.  Like this one:
    /data/scratch/KCC/installation/KCC_BASE/include/vector:149:
    `__T146099832' undeclared (first use in this function)
How do you debug this?  How do you find the place where the error was
triggered?  I had to do binary searches over preprocessed source
files.  Ouuww, sucks...

Bottom line:  Real C++-compilers like g++ have definite advantages over
`transpilers' like KCC.  At least on x86 I see no performance gain from
KAI's compiler.  This is the third commercial C++ `Wunderwaffe' that
flunked over here, but your mileage may vary.

Bottom line of bottom line:  Our efforts are better spent by helping
to shake out the bugs of GCC-3.

Regards
    -richy.
-- 
Richard Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>





More information about the GiNaC-devel mailing list