666609 - STL headers like <algorithm> and <vector> don't mix well with g++ -c -fno-exceptions and objC++ on 10.5

Status: NEW

(Firefox Build System :: General, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

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

Comment 1

[(not currently active) Ted Mielczarek]

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?

Comment 2

[Jeff Muizelaar [:jrmuizel]]

(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.

Comment 3

[(not currently active) Ted Mielczarek]

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

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.)

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Removing -fno-exceptions fixes the problem.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

(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?

Comment 7

[Jeff Muizelaar [:jrmuizel]]

(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

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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?

Comment 10

[Jeff Muizelaar [:jrmuizel]]

STL_FLAGS		=
WRAP_STL_INCLUDES	=
MOZ_MSVC_STL_WRAP__Throw= 
MOZ_MSVC_STL_WRAP__RAISE= 

On both 10.5 and 10.6

Comment 11

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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.

Comment 12

[(not currently active) Ted Mielczarek]

Somewhat related: bug 685927.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

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

Comment 14

[Jeff Muizelaar [:jrmuizel]]

adding

#define __EXCEPTIONS

at the beginning of the file seems to avoid this redefinition.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Alternatively, using 
#define _EXCEPTION_DEFINES_H
might be cleaner