Re: [Patch, libjava] use -fnon-call-exceptions rather than -fasynchronous-unwind-tables.

[IainS <developer at sandoe-acoustics dot co dot uk>]

On 18 Aug 2010, at 10:40, Richard Guenther wrote:

> On Wed, Aug 18, 2010 at 11:30 AM, IainS
> <developer@sandoe-acoustics.co.uk> wrote:
> > Hi
> > IIUC, the following should be the 'correct' approach.
> > OK for trunk? (with an appropriate changelog,  of course).
> > Iain
>
> That doens't match what the comment says.  What is it the correct
> approach for?

true, I missed adjusting the comment.

I think that the point is that the underlying requirement is to handle  
non-call-exceptions, and that the method by which that is achieved  
should be left to the target to decide.

[at present -fasynchronous-unwind-tables is set unconditionally by - 
fnon-call-exception in any case (although I'm not sure that's correct  
in all cases)]

> > Index: libjava/classpath/configure.ac
> > ===================================================================
> > --- libjava/classpath/configure.ac      (revision 163330)
> > +++ libjava/classpath/configure.ac      (working copy)
> > @@ -563,7 +563,7 @@ if test "x${COMPILE_JNI}" = xyes; then
> >     dnl CFLAGS that are used for all native code.  We want to compile
> >     dnl everything with unwinder data so that backtrace() will always
> >     dnl work.
> > -    EXTRA_CFLAGS='-fexceptions -fasynchronous-unwind-tables'
> > +    EXTRA_CFLAGS='-fexceptions -fnon-call-exceptions'
> >     AC_SUBST(EXTRA_CFLAGS)
> >
> >     dnl Strict warning flags which not every module uses.