Stream: t-compiler

Topic: ICE triage


pnkfelix (Jun 03 2019 at 12:26, on Zulip):

I'm going to do a bit of ICE triage right now. I think getting control over our database of ICE's is going to be more important than any other bit of triage I can do right now.

pnkfelix (Jun 03 2019 at 12:29, on Zulip):

so lets see, here are the unprioritized I-ICE issues, oldest first.

pnkfelix (Jun 03 2019 at 12:31, on Zulip):

first: "Array as asm output ICEs LLVM" #13368

pnkfelix (Jun 03 2019 at 12:32, on Zulip):

requires #[feature(asm)]. asm is not currently on the 2019 roadmap; see tracking issue #29722 here

pnkfelix (Jun 03 2019 at 12:34, on Zulip):

I'm going to CC #29722 and mark the ICE's with asm as P-medium, with the intention that they be upgraded in priority if we upgrade the priority on asm in general. (And I'll follow a similar protocol for any other ICE that seems to be intertwined with an unstable feature that is not on the 2019 roadmap.)

pnkfelix (Jun 03 2019 at 12:40, on Zulip):

next: "compiler segfault with deref of *() in asm arg" #13520

pnkfelix (Jun 03 2019 at 12:40, on Zulip):

I'm handling this same as #13368 above

pnkfelix (Jun 03 2019 at 12:43, on Zulip):

next: "compiler abort in LLVM code when using a newtype-wrapper as an argument" #15402

pnkfelix (Jun 03 2019 at 12:43, on Zulip):

for some reason this is also connected to feature(asm).

pnkfelix (Jun 03 2019 at 12:44, on Zulip):

I handled it same as #13368 above

pnkfelix (Jun 03 2019 at 12:45, on Zulip):

next: "ICE: Intrinsics cannot be used as bare functions" #15694

oli (Jun 03 2019 at 12:46, on Zulip):

I looked at that recently, we can probably create another shim generator for intrinsics

pnkfelix (Jun 03 2019 at 12:46, on Zulip):

but we could also just make it a proper error, no?

pnkfelix (Jun 03 2019 at 12:47, on Zulip):

(as aatch suggested back in 2015)

oli (Jun 03 2019 at 12:47, on Zulip):

oh, that would probably be for the best, as the shims have various problems

pnkfelix (Jun 03 2019 at 12:48, on Zulip):

oh wait, this depends on feature(intrinsics) anyway

pnkfelix (Jun 03 2019 at 12:49, on Zulip):

/me looks for a tracking issue in preparation for marking as P-medium

pnkfelix (Jun 03 2019 at 13:06, on Zulip):

I couldn't find a tracking issue, but I left a triage note and marked #15694 as P-medium, here

pnkfelix (Jun 03 2019 at 13:07, on Zulip):

next: "ICE when simplest rust-call method is called" #22565

pnkfelix (Jun 03 2019 at 13:07, on Zulip):

this depends on the "rust-call" ABI

pnkfelix (Jun 03 2019 at 13:15, on Zulip):

(which is not stable; guarded under feature(unboxed_closures), tracking issue #29625)

pnkfelix (Jun 03 2019 at 13:16, on Zulip):

however, #34901 demonstrates a case where a "rust-call" call site does not require the feature gate...

pnkfelix (Jun 03 2019 at 13:17, on Zulip):

(namely, when the use site is in a different crate from the definition site.)

pnkfelix (Jun 03 2019 at 13:18, on Zulip):

I'm going to triage #34901 as P-high because it strikes me as a stability hole

pnkfelix (Jun 03 2019 at 13:36, on Zulip):

and I'm going to triage #22565 as P-medium, under assumption that it depends on (someone in dependency chain) using feature(unboxed_closures)

pnkfelix (Jun 03 2019 at 14:15, on Zulip):

next: "ICE: capacity overflow or "Illegal instruction (core dumped)" with very large static item" #23600

pnkfelix (Jun 03 2019 at 14:16, on Zulip):

the bug discussion has a couple different examples, focused on two dimensions: length in {0xffff_ffff_ffff_ffff, 0xffff_ffff}, and zero-sized-vs-nonzero-sized.

pnkfelix (Jun 03 2019 at 14:19, on Zulip):

nonzero-sized with length 0xffff_ffff causes the compiler to use a bunch of RAM and time before it ends with an LLVM OOM.

pnkfelix (Jun 03 2019 at 14:20, on Zulip):

nonzero-sized with length 0xffff_ffff_ffff_ffff causes the compiler to error with a "too big for the current architecture" error.

oli (Jun 03 2019 at 14:23, on Zulip):

not sure what we can improve there other than have special cased code for repeat-expressions in the const evaluator

pnkfelix (Jun 03 2019 at 14:24, on Zulip):

okay?

pnkfelix (Jun 03 2019 at 14:24, on Zulip):

I mean, that doesn't sound so bad to me.

pnkfelix (Jun 03 2019 at 14:24, on Zulip):

sure, its dumb code

pnkfelix (Jun 03 2019 at 14:24, on Zulip):

but these are also pretty dumb outcomes.

oli (Jun 03 2019 at 14:27, on Zulip):

while we can do it and it would just be somewhat annoying in const eval, the problem I see is that let mut x = [0; 0xFFFF_FFFF_FFFF_FFFF]; x[900]=42; would end up either getting weird logic to handle efficiently, or just allocate the entire thing on the 42 write

pnkfelix (Jun 03 2019 at 14:29, on Zulip):

I was assuming we could error based on the absurd length of the initial array

pnkfelix (Jun 03 2019 at 14:29, on Zulip):

you want to represent it as a allocate-on-write value?

pnkfelix (Jun 03 2019 at 14:30, on Zulip):

(which then means we do not observe an error until the write occurs?)

pnkfelix (Jun 03 2019 at 14:30, on Zulip):

or are you hoping to eventually have some support where arrays at const-eval time are represented sparsely?

pnkfelix (Jun 03 2019 at 14:31, on Zulip):

(while a sparse array representation sounds tempting, I suspect it would just end up being super complex given that we'd want to allocate the dense representation once we see a borrow or similar...)

oli (Jun 03 2019 at 14:31, on Zulip):

oh, borrows are no problem in miri, even if we picked a sparse representation

oli (Jun 03 2019 at 14:32, on Zulip):

but yea, the backing code for allocations would be crazy

pnkfelix (Jun 03 2019 at 14:32, on Zulip):

hmm okay yeah, not borrows.

pnkfelix (Jun 03 2019 at 14:32, on Zulip):

maybe eventual casts of borrows to unsafe pointers would be tricky

oli (Jun 03 2019 at 14:32, on Zulip):

XD not even that

pnkfelix (Jun 03 2019 at 14:32, on Zulip):

but I assume that you and Ralf could do something clever for those too

pnkfelix (Jun 03 2019 at 14:32, on Zulip):

ANyway

oli (Jun 03 2019 at 14:32, on Zulip):

miri has like 3 levels of abstraction

pnkfelix (Jun 03 2019 at 14:33, on Zulip):

What is the problem with erroring at the point where the array is initially created?

oli (Jun 03 2019 at 14:33, on Zulip):

ok, so... report an error if the allocations are too large?

oli (Jun 03 2019 at 14:33, on Zulip):

absolutely none, we just need to pick a limit

pnkfelix (Jun 03 2019 at 14:33, on Zulip):

is the issue that you do not want miri to be consulting the runtime architecture limit?

pnkfelix (Jun 03 2019 at 14:33, on Zulip):

I assume it already does something similar to deal with sizeof

oli (Jun 03 2019 at 14:34, on Zulip):

that's one problem, but also we can't figure out the maximum RAM size at all anyway

oli (Jun 03 2019 at 14:34, on Zulip):

maybe we can just pick a nice value and make it configurable similar to the recursion limit?

pnkfelix (Jun 03 2019 at 14:34, on Zulip):

okay so you're worried about the gulf between maximum RAM size and the maximum architecture size?

pnkfelix (Jun 03 2019 at 14:34, on Zulip):

as in, choosing a limit that is "obviously" too large

oli (Jun 03 2019 at 14:34, on Zulip):

yea

oli (Jun 03 2019 at 14:35, on Zulip):

ppl will complain about 100GB arrays being denied, I guarantee it :D

pnkfelix (Jun 03 2019 at 14:35, on Zulip):

I think something analogous to recursion limit makes a lot of sense here.

pnkfelix (Jun 03 2019 at 14:35, on Zulip):

since usually 100GB arrays are a user error

oli (Jun 03 2019 at 14:35, on Zulip):

we used to have a memory limit for miri, but removed it, should be easy enough to re-add just for const eval

pnkfelix (Jun 03 2019 at 14:36, on Zulip):

in any case

pnkfelix (Jun 03 2019 at 14:36, on Zulip):

this isn't P-high, obviously

pnkfelix (Jun 03 2019 at 14:39, on Zulip):

Based on what I've observed on my Linux box, I'm going to triage this as P-low. I added a summary of the outcomes I observed to a grid at the top of the issue.

Pietro Albini (Jun 03 2019 at 14:42, on Zulip):

I think getting control over our database of ICE's is going to be more important than any other bit of triage I can do right now.

FYI Crater results for 1.36 are pretty bad (700 regressions), so you might want to take a look at that soonish
https://github.com/rust-lang/rust/issues/61401#issuecomment-498089693

pnkfelix (Jun 03 2019 at 14:43, on Zulip):

thanks @Pietro Albini ; I did notice that there were a bunch of regression issues logged when I skimmed the results.

pnkfelix (Jun 03 2019 at 14:43, on Zulip):

I'll try to get to that soon-ish too.

pnkfelix (Jun 03 2019 at 14:43, on Zulip):

(most likely, first thing tomorrow)

Pietro Albini (Jun 03 2019 at 14:43, on Zulip):

thanks!

Pietro Albini (Jun 03 2019 at 14:43, on Zulip):

this was only the check-only+rustdoc btw, results for the full run still have to come in

Last update: Nov 20 2019 at 01:40UTC