On Nov 11, 2011, at 12:25 AM, Iain Sandoe wrote:
FWIW your example doesn't reproduce the problem because it contains no
objective c exceptions code.
Ah, but it can be seen to contradict what you said. It also found a bug.
However, OK - I see your point (I also see where the problem came
On Wed, 9 Nov 2011, Mike Stump wrote:
On Nov 9, 2011, at 10:12 AM, Iain Sandoe wrote:
This puts flag_next_runtime into the global options structure
I needed to deal with '-fobjc-sjlj-exceptions' and elected to remove it -
- this is because there is only one valid exception model for
On Nov 10, 2011, at 1:35 AM, Richard Guenther rguent...@suse.de wrote:
flag_exceptions also triggers middle-end behavior - without it no
statement can possibly throw
Actually, one version of exception handling for objective c++ doesn't require
flag_exceptions... One can indeed @throw without
Hi Mike,
just want to state my understanding to allow you to comment if I'm
off
On 10 Nov 2011, at 16:12, Mike Stump wrote:
On Nov 10, 2011, at 1:35 AM, Richard Guenther rguent...@suse.de
wrote:
flag_exceptions also triggers middle-end behavior - without it no
statement can possibly
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
As discussed in:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00927.html
This puts flag_next_runtime into the global options structure
-- hopefully this will pave the way for extracting the information
from objects when doing LTO and making sure that it is (a) consistent
- and (b) that
On Wed, 9 Nov 2011, Iain Sandoe wrote:
I am probably missing something
- but there doesn't seem to be a ready way to set the Init() value of a flag
depending on the target
The way that is done is to use an expression inside Init() that uses a
target macro (it needs to be a macro, not a hook,
On Nov 9, 2011, at 10:12 AM, Iain Sandoe wrote:
This puts flag_next_runtime into the global options structure
I needed to deal with '-fobjc-sjlj-exceptions' and elected to remove it -
- this is because there is only one valid exception model for each
permutation of runtime and ABI - thus
