Cannot compile regex: illegal hardware instruction

[laumann]

The new nightly caused this in regex: rust-lang/regex#50 - the fix is trivial, but it uncovers an illegal hardware instruction that seems to be a bug in rustc.

So far I have (disclaimer: the code is taken from regex)

type NamedClasses = &'static [(&'static str, &'static [(char, char)])];
static ASCII_CLASSES: NamedClasses = &[
     ("alnum", &ALNUM),
];
static ALNUM: &'static [(char, char)] = &[('0', '9'), ('A', 'Z'), ('a', 'z')];
fn main() { }

(playpen)

It seems to be related to f35f973, which changes a lot of statics to consts. In the above example, changing the static modifier of ALNUM to const also allows this to compile, so there is a workaround, but it still seems like a bug that should be addressed.

See:

• Fixed compilation errors regex#51
• HEAD rust fails to compile regex#50

$ rustc -Vv
rustc 1.0.0-dev (fed12499e 2015-03-03) (built 2015-03-04)
binary: rustc
commit-hash: fed12499e7d91f9cdfba5833e34d20e8fd19b898
commit-date: 2015-03-03
build-date: 2015-03-04
host: x86_64-unknown-linux-gnu
release: 1.0.0-dev

[Manishearth]

(Btw, this seems to be happening during trans)

[BurntSushi]

For valgrind output: rust-lang/regex#51 (comment)

[steveklabnik]

Not strictly an ICE, but close enough

[frewsxcv]

This is still an issue using Rust 1.0 beta 2

~/Downloads $ rustc test.rs
test.rs:2:1: 4:3 warning: static item is never used: `ASCII_CLASSES`, #[warn(dead_code)] on by default
test.rs:2 static ASCII_CLASSES: NamedClasses = &[
test.rs:3      ("alnum", &ALNUM),
test.rs:4 ];
test.rs:5:1: 5:79 warning: static item is never used: `ALNUM`, #[warn(dead_code)] on by default
test.rs:5 static ALNUM: &'static [(char, char)] = &[('0', '9'), ('A', 'Z'), ('a', 'z')];
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fish: Job 1, 'rustc test.rs ' terminated by signal SIGSEGV (Address boundary error)

~/Downloads $ rustc --version
rustc 1.0.0-beta.2 (e9080ec39 2015-04-16) (built 2015-04-16)

[arielb1]

Backtrace?

[frewsxcv]

No luck getting a backtrace:

/tmp $ set -x RUST_BACKTRACE 1
/tmp $ rustc -gv hi.rs
fish: Job 1, 'rustc -gv hi.rs ' terminated by signal SIGSEGV (Address boundary error)
/tmp $

At the time of writing, this is still an issue on stable, beta, and nightly channels

[eefriedman]

A somewhat more clear testcase:

static ALNUM: &'static u32 = &1;
static C:u32 = *(&/*implicit deref*/ALNUM as &'static u32);
fn main() { println!("{}", C); }

[eefriedman]

Err, a much more clear testcase:

static ALNUM: &'static u32 = &1;
static C:u32 = **&ALNUM;
fn main() {}

[frewsxcv]

@eefriedman Both of those examples seem to not cause an ICE:

http://is.gd/awTiuu

http://is.gd/w6HUF9

[eefriedman]

If you flip the declaration of C and ALNUM, it ICEs. The accepts-invalid and crash-on-invalid are essentially two variants of the same issue.

[nrc]

bt:

#0  0x00007ffff3a41ee0 in LLVMTypeOf () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_llvm-7e44814b.so
#1  0x00007ffff635d99d in trans::consts::const_expr::h8acb773187e50bb5Pss () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_trans-7e44814b.so
#2  0x00007ffff63b0c79 in trans::consts::const_expr_unadjusted::h06541bee33f5159cZIs ()
   from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_trans-7e44814b.so
#3  0x00007ffff635d420 in trans::consts::const_expr::h8acb773187e50bb5Pss () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_trans-7e44814b.so
#4  0x00007ffff6355dc0 in trans::base::get_item_val::hc5b38e5ad51952cbVNi () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_trans-7e44814b.so
#5  0x00007ffff6352b4f in trans::base::trans_item::h48925c6cb6dfeb22Oqi () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_trans-7e44814b.so
#6  0x00007ffff63600df in trans::base::trans_crate::h8696565b15c10d31Lej () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_trans-7e44814b.so
#7  0x00007ffff7af8667 in driver::phase_4_translate_to_llvm::h2d179cc6784b73795Oa ()
   from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-7e44814b.so
#8  0x00007ffff7af1f35 in driver::phase_3_run_analysis_passes::closure.15599 () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-7e44814b.so
#9  0x00007ffff7aec1f5 in driver::phase_3_run_analysis_passes::h8865956255442467876 ()
   from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-7e44814b.so
#10 0x00007ffff7ad2643 in driver::compile_input::hcad48c94ba42de22Tba () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-7e44814b.so
#11 0x00007ffff7b9d0b4 in run_compiler::h81ca4dc28455e870k6b () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-7e44814b.so
#12 0x00007ffff7b9abee in boxed::F.FnBox$LT$A$GT$::call_box::h3765534436168023650 ()
   from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-7e44814b.so
#13 0x00007ffff7b9a4da in rt::unwind::try::try_fn::h10948129613882328285 () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-7e44814b.so
#14 0x00007ffff7610419 in rust_try_inner () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/libstd-7e44814b.so
#15 0x00007ffff7610406 in rust_try () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/libstd-7e44814b.so
#16 0x00007ffff7579198 in rt::unwind::try::inner_try::hc2015e0398f2bdedIyw () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/libstd-7e44814b.so
#17 0x00007ffff7b9a71b in boxed::F.FnBox$LT$A$GT$::call_box::h16611359455106826858 ()
   from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-7e44814b.so
#18 0x00007ffff758c78d in sys::thread::Thread::new::thread_start::h825939a3e780a437vIv () from /home/ncameron/rust2/x86_64-unknown-linux-gnu/stage1/lib/libstd-7e44814b.so
#19 0x00007ffff1dcd6aa in start_thread (arg=0x7fffefbff700) at pthread_create.c:333
#20 0x00007ffff71cdeed in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

[nrc]

In the end I think this comes down to the compiler permitting access to statics when it should not. The mechanism in const_check is basically not smart enough, but fixing this requires a whole bunch of new machinery and I don't think it is currently worth the effort.

[arielb1]

You don't even need the double-deref:

static BAR: u32 = *&FOO;
static FOO: u32 = 4;

fn main() {}

If we don't make this work, we should probably ban all derefs in constants.

[bstrie]

Compiling these examples now leads to:

error[E0394]: cannot refer to other statics by value, use the address-of operator or a constant instead

Shall we close this? Do we want a new regression test first?

[Manishearth]

I think @steveklabnik knows the answer to this, since he runs Glacier.

[Mark-Simulacrum]

Yeah, I'm going to close, there are tests in-tree that verify this behavior.