On 11 Nov 2011, at 00:30, Mike Stump wrote:
On Nov 10, 2011, at 9:40 AM, Iain Sandoe wrote:
Thanks for catching that --- brainstorm on my part ... the code
under discussion should have been #ifndef OBCPLUS
There is no prohibition against C having exceptions, so, doesn't
matter if you turn C++ off, you can still throw through C code, so
turning on exceptions is reasonable.
Moreover, there is no personality routine in m32 NeXT libobjc, so
if one tries to engage the zero-cost exceptions, one gets a link
error (and generates a load of unused eh data). I can work around
that if there is still reason to have "-fexceptions" on.
No, this must be wrong:
$ cat t.c
void bar() {
}
void foo() {
bar();
}
int main() {
return 0;
}
$ gcc -fexceptions t.c
$ gcc -m32 -fexceptions t.c
$
Like I said, it does work, one can count on it working and it is
useful, you can't break it. And next week, they'll add catching and
throwing to C, and when they do, it still has to just work. :-)
FWIW your example doesn't reproduce the problem because it contains no
objective c exceptions code.
However, OK - I see your point (I also see where the problem came from).
in the code before the split there is this path (note gcc-4.2.1 system
versionl):
$ gcc-4.2 ../gcc-live-trunk/gcc/testsuite/objc.dg/exceptions-2.m -
lobjc -fobjc-exceptions -fno-objc-sjlj-exceptions -o t
Undefined symbols:
"___gnu_objc_personality_v0", referenced from:
___gnu_objc_personality_v0$non_lazy_ptr in ccOk5CMv.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
I have incorrectly made that path apply to ABI=0,1 NeXT regardless of
the setting of fobjc-sjlj-exceptions.
This doesn't affect GNU runtime or NeXT m64.
Patch under test to fix this (will post later).
Iain
