question about arithmetic exceptions

Andrew Haley aph@pasanda.cygnus.co.uk
Mon Nov 29 08:32:00 GMT 1999


> From: Godmar Back <gback@cs.utah.edu>
> Date: Mon, 29 Nov 1999 09:26:42 -0700 (MST)
> > 
> > > Nevertheless, the hack in libgcj seems suboptimal.
> > 
> > Sure, it's ugly.  However, unless libgcc changes substantially this
> > hack will continue to work, and it provides all the funtionality we
> > need without burdening C and C++ with the extra code space usage.
> > 
> 
> Isn't "continue to work" a rather strong statement if you compare it 
> to your comment that it'll already break if you compile libgcc with 
> -fomit-frame-pointer?

That is, IMO, a substantial change.

> I also agree with you that it's not about performance.  It's about
> brittle code IMO.
> 
> I believe that the right approach is to first split libgcc2.c into
> different source files, grouped by functionality.  For instance, it
> could look like this:
> 
> libgcc2/arith
> libgcc2/arith/divdi3.c
> libgcc2/arith/moddi3.c
> 		...
> libgcc2/bb/bb.c
> libgcc2/eh/eh.c
> ...
> 
> Etc.
> 
> There should be differently compiled versions of some files depending on
> what executable is built, i.e., divdi3-noexc and a divdi3-exc from which
> the compiler driver could choose when linking an executable.

Sure, that would work.  No disagreement.  But does the problem justify
such a large reorganization of the compiler?

Andrew.


More information about the Java mailing list