[CLN-list] Options for FP errors in CLN?

John Pye john.pye at student.unsw.edu.au
Fri Jul 29 02:34:32 CEST 2005


Hi Richy

So it looks like the main issue is the overhead of processing the
exceptions through destructors in CLN. I made a simple change to one or
two lines in the cl_abort.cc file such that it now throws

runtime_error("CLN error");

This has been adequate for me to get good information back from GDB. My
applications of CLN are perhaps not typical; I'm using GiNaC to
implement a fairly basic non-linear solver with a possible view to
adding DAE solver capabilities at some point. So the CLN speed is not so
critical at this stage; more likely my immediate bottleneck will be in
other areas related to dense matrix manipulation in a fortan library I'm
using. What's more importantant is that I can quickly track down the
source of my coding erros.

I didn't compile CLN originally, I downloaded an RPM for FC3 i386,
latest CLN, GiNaC 1.3.1. from 'pbone' RPM repository. I've now compiled
CLN with my changes and created a new RPM but I'm still using the
standard GiNaC which I downloaded.

If you want to try to build CLN with exceptions as I have, you can use
the attached RPM spec & patch file, if you wish. As you can see, there
is no special 'configure' call, just the patch which I applied. A more
rigorous approach would be to add specialised 'throws' depending on the
error which occurred (throw cln_nan_error(), etc?); my patch is minimal.

As for -fno-exceptions, I don't know about that compiler directive. Does
G++ insert "abort" calls in place of "throw" calls if you use that? I
can see that you have a difficult balance between speed and
userfriendliness to decide on here.

I might have been wrong about SIGFPE. I thought that under such cases a
stack dump might be generated, which could be used to locate the error.
Mistaken in that?

Cheers

JP

Richard B. Kreckel wrote:

>Dear John,
>
>On Thu, 28 Jul 2005, John Pye wrote:
>  
>
>>I've been doing a lot of work with GiNaC recently but just now I think I
>>have a problem which relates more specifically with CLN, so hopefully
>>I'm asking this question in the right place.
>>
>>I have had a few problems now with CLN's error handling: it tends to
>>just abort when something goes wrong. Is there a reason why it doesn't
>>just throw exceptions that I can catch?
>>
>>    
>>
>>>void cl_error_floating_point_nan (void)
>>>{
>>>	fprint(std::cerr, "floating point NaN occurred.\n");
>>>	cl_abort();
>>>}
>>>
>>>
>>>      
>>>
>>I can see that I could rewrite the 'cl_abort' function so that it does
>>throw exceptions, but I just wanted to point out that CLN is a big job
>>to compile and it might be nice if it gives this sort of functionality
>>out-of-the-box.
>>    
>>
>
>I've also become somewhat unsatisfied with that scheme, lately.  But I
>haven't found the time to dig into this.  Question: What exactly
>happens when you throw an exception from within a library that was
>compiled with -fno-exceptions?
>
>  
>
>>I can't use the suggested method from the manual either,
>>    
>>
>[...]
>  
>
>>because my pre-compiled CLN doesn't seem to have debug symbols:
>>    
>>
>
>Of course not: when I last compiled it with -g the size of the library
>exceeded 64MB.  I'm not enthusiastic about shipping precompiled lib of
>this size.
>
>  
>
>>So, I'd like to suggest replacing cl_abort with either a SIGFPE or a
>>standard exception of some sort.
>>    
>>
>
>I don't see how SIGFPE would help you with the "no stack" problem.  And
>before compiling it with exceptions I would be interested in the overhead
>this incurs, especially in the stack unwinding code that comes with dtors.
>
>  
>
>>But please, if there are other issues at hand, or reasons why you don't
>>do things that way, I'd be keen to know.
>>    
>>
>
>The list of reasons above is complete, I think.
>
>Regards
>  -richy.
>  
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cln-1.1.9.patch
Url: http://www.cebix.net/pipermail/cln-list/attachments/20050729/2511a354/cln-1.1.9.ksh
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cln.spec
Url: http://www.cebix.net/pipermail/cln-list/attachments/20050729/2511a354/cln.ksh


More information about the CLN-list mailing list