This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

On Wed, Aug 18, 2010 at 11:30 AM, IainS
<> wrote:
IIUC, the following should be the 'correct' approach.
OK for trunk? (with an appropriate changelog,  of course).

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/
--- libjava/classpath/      (revision 163330)
+++ libjava/classpath/      (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'

dnl Strict warning flags which not every module uses.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]