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