ruby -e 'case 1; when 2r; 3; end'

Dies with a SIGSEGV.

Backtrace (with a debug build):

* thread #1, name = 'ruby27', stop reason = signal SIGSEGV
    frame #0: 0x0000000801add4e8 libruby27.so.27`append_compile_error(iseq=0x000000089445a6b8, line=1125956, fmt="") at compile.c:380:47
    frame #1: 0x00007fffffffc930
  * frame #2: 0x0000000801c4d915 libruby27.so.27`rb_st_lookup [inlined] do_hash(key=36847331000, tab=0x000000086f314d40) at st.c:326:33
    frame #3: 0x0000000801c4d90b libruby27.so.27`rb_st_lookup(tab=0x000000086f314d40, key=36847331000, value=0x00007fffffffc958) at st.c:1104
    frame #4: 0x0000000801b63443 libruby27.so.27`rb_hash_lookup2 [inlined] hash_stlike_lookup(hash=36847330480, key=<unavailable>, pval=0x00007fffffffc958) at hash.c:0
    frame #5: 0x0000000801b6339a libruby27.so.27`rb_hash_lookup2(hash=36847330480, key=36847331000, def=8) at hash.c:2070
    frame #6: 0x0000000801b0640a libruby27.so.27`when_vals(iseq=0x000000089445a550, cond_seq=0x00007fffffffcb60, vals=0x0000000878b93098, l1=<unavailable>, only_special_literals=1, literals=<unavailable>) at compile.c:4322:18
    frame #7: 0x0000000801afac70 libruby27.so.27`iseq_compile_each0 at compile.c:5334:27
    frame #8: 0x0000000801afa5c1 libruby27.so.27`iseq_compile_each0(iseq=0x000000089445a550, ret=0x00007fffffffcd60, node=0x0000000878b93108, popped=0) at compile.c:7162
    frame #9: 0x0000000801b0ab71 libruby27.so.27`setup_args_core [inlined] compile_args(node=0x0000000878b93140) at compile.c:3923:13
    frame #10: 0x0000000801b0ab59 libruby27.so.27`setup_args_core(iseq=0x000000089445a550, args=0x00007fffffffcd60, argn=<unavailable>, dup_rest=<unavailable>, flag=<unavailable>, keywords=0x00007fffffffcd28) at compile.c:5049
    frame #11: 0x0000000801af4dbf libruby27.so.27`iseq_compile_each0 [inlined] compile_call(iseq=0x000000089445a550, ret=0x00007fffffffce80, node=0x0000000878b93060, type=<unavailable>, line=1, popped=0) at compile.c:7046:16
    frame #12: 0x0000000801af4ce1 libruby27.so.27`iseq_compile_each0(iseq=0x000000089445a550, ret=0x00007fffffffce80, node=0x0000000878b93060, popped=0) at compile.c:7670
    frame #13: 0x0000000801adc735 libruby27.so.27`rb_iseq_compile_node(iseq=0x000000089445a550, node=<unavailable>) at compile.c:702:6
    frame #14: 0x0000000801b85a47 libruby27.so.27`rb_iseq_new_with_opt(ast=0x000000089445a718, name=<unavailable>, path=<unavailable>, realpath=<unavailable>, first_lineno=1, parent=0x0000000819358010, type=ISEQ_TYPE_MAIN, option=0x0000000801cf1d28) at iseq.c:821:5
    frame #15: 0x0000000801b85b6d libruby27.so.27`rb_iseq_new_main(ast=<unavailable>, path=<unavailable>, realpath=<unavailable>, parent=<unavailable>) at iseq.c:787:12
    frame #16: 0x0000000801c40537 libruby27.so.27`ruby_process_options at ruby.c:1904:9
    frame #17: 0x0000000801c3f433 libruby27.so.27`ruby_process_options(argc=<unavailable>, argv=<unavailable>) at ruby.c:2413
    frame #18: 0x0000000801b3f513 libruby27.so.27`ruby_options(argc=<unavailable>, argv=<unavailable>) at eval.c:124:2
    frame #19: 0x0000000000201cca ruby27`main(argc=<unavailable>, argv=<unavailable>) at main.c:50:23
    frame #20: 0x0000000000201a70 ruby27`_start(ap=<unavailable>, cleanup=<unavailable>) at crt1.c:76:7

It happens whenever a rational literal is used as a branch in a case expression.  Happens during the parse/compile phase (e.g. when "require"'ing a file with a construct like that).  With both package and port.  I tested on 12.2-RELEASE, 12.2-STABLE and 14-CURRENT and they all have the problem.

The problem started happening recently but I'm not sure when or due to what changes.

It doesn't happen if Ruby is built with GCC (e.g. by setting USE_GCC=yes in the port).

Looks like it's a case of Clang's optimizer being a bit more aggressive (and/or header macros being defined in a way that leads to that).

Patch:

diff --git c/lang/ruby27/files/patch-compile.c i/lang/ruby27/files/patch-compile.c
new file mode 100644
index 000000000000..c766600b8f40
--- /dev/null
+++ i/lang/ruby27/files/patch-compile.c
@@ -0,0 +1,20 @@
+--- compile.c.orig	2021-04-05 08:39:38.000000000 -0400
++++ compile.c	2021-05-03 20:49:59.011745000 -0400
+@@ -1820,7 +1820,7 @@
+         return rb_float_cmp(lit, val);
+     }
+     else {
+-        UNREACHABLE_RETURN(-1);
++        return -1;
+     }
+ }
+ 
+@@ -1838,7 +1838,7 @@
+       case T_FLOAT:
+         return rb_dbl_long_hash(RFLOAT_VALUE(a));
+       default:
+-        UNREACHABLE_RETURN(0);
++        return 0;
+     }
+ }
+ 

The default branches there are NOT unreachable and Clang eliding them seems to be causing a runaway program counter.

There's actually a flaw in Ruby there that causes a pessimization of the hash table optimization for the literals of a switch because the hash table doesn't properly handles all numeric types (but it still tries to insert them in it), but it harmlessly fallsback to testing the branches one by one.

lang/ruby26 and lang/ruby30 have the same problem and could use the same patch.