For example: #import <Foundation/Foundation.h> #include <algorithm> void f() { @try { } @catch(NSException *_exn) { } } gives the following errors: reduc.mm:5: error: stray ‘@’ in program reduc.mm:6: error: stray ‘@’ in program

Odd. I wouldn't think -fno-exceptions would imply -fno-objc-exceptions. If you stick -fobj-exceptions in the CXXFLAGS after -fno-exceptions, does this compile?

(In reply to comment #1) > Odd. I wouldn't think -fno-exceptions would imply -fno-objc-exceptions. If > you stick -fobj-exceptions in the CXXFLAGS after -fno-exceptions, does this > compile? No. Building with: g++ -c -fno-exceptions -fobjc-exceptions reduc.mm gives the error taking out #include <algorithm> fixes it.

Okay, that's odd. We wrap the STL headers in order to force exceptions off. For GCC, the template is here: http://mxr.mozilla.org/mozilla-central/source/config/gcc-stl-wrapper.template.h Presumably the bug lies in there somewhere, or in one of the headers it includes. You can find the generated version in $objdir/dist/stl_wrappers/algorithm

I don't fully understand ... the error in comment 0 sure sounds like lack of objc exceptions, and the same error in comment 2 sounds like more of same. If you remove the -fno-exceptions from the compile line entirely, what happens? (That might trump -fobjc-exceptions.)

Removing -fno-exceptions fixes the problem.

(In reply to comment #3) > Okay, that's odd. We wrap the STL headers in order to force exceptions off. > For GCC, the template is here: > http://mxr.mozilla.org/mozilla-central/source/config/gcc-stl-wrapper. > template.h > > Presumably the bug lies in there somewhere, or in one of the headers it > includes. You can find the generated version in > $objdir/dist/stl_wrappers/algorithm I was reproducing the problem with out using our wrappers. Perhaps they're not getting picked up?

(In reply to comment #6) > (In reply to comment #3) > > Okay, that's odd. We wrap the STL headers in order to force exceptions off. > > For GCC, the template is here: > > http://mxr.mozilla.org/mozilla-central/source/config/gcc-stl-wrapper. > > template.h > > > > Presumably the bug lies in there somewhere, or in one of the headers it > > includes. You can find the generated version in > > $objdir/dist/stl_wrappers/algorithm I don't have a $objdir/dist/stl_wrappers directory or any files named 'algorithm' in my objdir

For gcc, the wrappers just ensure that (C++) exceptions are off. My guess here would be that <algorithm> and <vector> end up pulling in some objc-specific library code that doesn't honor -fno-(objc)-exceptions.

What do these STL_FLAGS = -I$(DIST)/stl_wrappers WRAP_STL_INCLUDES = 1 MOZ_MSVC_STL_WRAP__Throw= MOZ_MSVC_STL_WRAP__RAISE= say in your $objdir/config/autoconf.mk?

STL_FLAGS = WRAP_STL_INCLUDES = MOZ_MSVC_STL_WRAP__Throw= MOZ_MSVC_STL_WRAP__RAISE= On both 10.5 and 10.6

Looks like that's due to a gcc bug that was fixed in 4.2, if I read gcc's bugzilla correctly. Thanks apple. That's not good but not The Real Bug.

Somewhat related: bug 685927.

A reduced test case is #include <exception_defines.h> void f() { @try { } @finally { } } exception_defines redefines 'try' and 'catch' which explains why this goes bad: #ifndef __EXCEPTIONS // Iff -fno-exceptions, transform error handling code to work without it. # define try if (true) # define catch(X) if (false) # define __throw_exception_again #else // Else proceed normally. # define __throw_exception_again throw #endif

adding #define __EXCEPTIONS at the beginning of the file seems to avoid this redefinition.

Alternatively, using #define _EXCEPTION_DEFINES_H might be cleaner