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: What do do with the exceptional case of expand_case for SJLJ exceptions

On Wed, Apr 18, 2012 at 2:44 PM, Richard Henderson <> wrote:
> On 04/18/2012 05:39 AM, Jan Hubicka wrote:
>> Well, if SJLJ lowering happens as gimple pass somewhere near the end of gimple
>> queue, this should not be problem at all. (and implementation would be cleaner)
> If you can find a clean way of separating sjlj expansion from dw2 expansion,
> please do. ?But there's a lot of code shared between the two. ?I see nothing
> wrong with always expanding via tablejump.

In that case, would something like the following patch be acceptable?
I have verified that all targets that always set
TARGET_EXCEPT_UNWIND_INFO define casesi and/or tablejump.

        * toplev.c (process_options): Fail for sjlj exceptions if the
target machine
        has no casesi insn and no tablejump insn.

Index: toplev.c
--- toplev.c    (revision 187394)
+++ toplev.c    (working copy)
@@ -1265,6 +1265,16 @@ process_options (void)
           "and -ftree-loop-linear)");

+#if !defined(HAVE_casesi) && !defined(HAVE_tablejump)
+  if (flag_exceptions
+      && targetm_common.except_unwind_info (&global_options) == UI_SJLJ)
+    {
+      sorry ("setjmp/longjmp-based exception handling not supported "
+            "on this target machine "
+            "(required %<casesi%> or %<tablejump%> insns are not present)");
+    }
   if (flag_mudflap && flag_lto)
     sorry ("mudflap cannot be used together with link-time optimization");

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