Stream: t-compiler/const-eval

Topic: diagnostic output differs w/ vs w/o -O


pnkfelix (Nov 07 2018 at 14:17, on Zulip):

Hey @Oli while investigating issues associated with PR #55532, I encountered the following seeming oddity: on the test in question, I get slightly different diagnostic output based on whether I do or don't include -O

pnkfelix (Nov 07 2018 at 14:17, on Zulip):

I wanted to know if 1. you are aware of this, 2. if its currently expected behavior, and 3. if there's any hope of ... eliminating the difference here?

RalfJ (Nov 07 2018 at 14:23, on Zulip):

@pnkfelix seems to be related to overflow checks?

pnkfelix (Nov 07 2018 at 14:23, on Zulip):

Oh ... because our semantics for overflow differ for with -O vs without, hmmm, yes?

RalfJ (Nov 07 2018 at 14:23, on Zulip):

for anything MIR-based, that is kind-of expected. Not sure how much can be done. The MIR, once generated, encodes whether arithmetic is checked for overflow or not, so anything just executing the MIR will only do overflow checks in debug mode

RalfJ (Nov 07 2018 at 14:23, on Zulip):

the thing is the semantics of MIR do not differ

RalfJ (Nov 07 2018 at 14:23, on Zulip):

MIR building differs

pnkfelix (Nov 07 2018 at 14:24, on Zulip):

(I cannot remember now whether the intention was for such checks to be controlled via -O or -g, but either way, its an excellent hypothesis for why this is arising)

RalfJ (Nov 07 2018 at 14:24, on Zulip):

I once was foolish enough to think that I could make MIR interpretation (miri/CTFE) check for overflow even when the MIR does not ask for it

RalfJ (Nov 07 2018 at 14:24, on Zulip):

half a year later we had a segfault because of that^^

pnkfelix (Nov 07 2018 at 14:24, on Zulip):

wait, what?

pnkfelix (Nov 07 2018 at 14:25, on Zulip):

can you point me to the issue?

RalfJ (Nov 07 2018 at 14:25, on Zulip):

well there were other things playing into this as well, it was because promotion happened and CTFE did not the same thing as run-time code

RalfJ (Nov 07 2018 at 14:25, on Zulip):

that's just to explain why we do overflow checks only when the MIR explicitly asks for it

RalfJ (Nov 07 2018 at 14:26, on Zulip):

can you point me to the issue?

https://github.com/rust-lang/rust/issues/50814

pnkfelix (Nov 07 2018 at 14:27, on Zulip):

the interesting thing to me here is that the diagnostic output is so similar

RalfJ (Nov 07 2018 at 14:27, on Zulip):

const_prop however does special magic to still do overflow checks even in release mode, I think

RalfJ (Nov 07 2018 at 14:27, on Zulip):

maybe that special magic is not quite close enough to what debug mode does

pnkfelix (Nov 07 2018 at 14:27, on Zulip):

like, it seems like const_eval is reporting a problem in either case

pnkfelix (Nov 07 2018 at 14:27, on Zulip):

but it gets tied in with the other overflow checking in different ways....?

RalfJ (Nov 07 2018 at 14:27, on Zulip):

no const_eval involved here

pnkfelix (Nov 07 2018 at 14:27, on Zulip):

...

RalfJ (Nov 07 2018 at 14:27, on Zulip):

this is not in const context

RalfJ (Nov 07 2018 at 14:27, on Zulip):

this is const_prop

RalfJ (Nov 07 2018 at 14:28, on Zulip):

which opportunistically walks over runtime MIR and interprets the parts of it that it can to provide some diagnostics

RalfJ (Nov 07 2018 at 14:28, on Zulip):

its a bad, horrible hack^^

pnkfelix (Nov 07 2018 at 14:28, on Zulip):

let x: i8 = --128; is not const context?

RalfJ (Nov 07 2018 at 14:28, on Zulip):

uh, no?

pnkfelix (Nov 07 2018 at 14:28, on Zulip):

okay hey I don't know

RalfJ (Nov 07 2018 at 14:28, on Zulip):

there's no const there

RalfJ (Nov 07 2018 at 14:28, on Zulip):

okay :)

RalfJ (Nov 07 2018 at 14:28, on Zulip):

you have to ask for const context with const

pnkfelix (Nov 07 2018 at 14:28, on Zulip):

I see

RalfJ (Nov 07 2018 at 14:29, on Zulip):

otherwise its not const context

pnkfelix (Nov 07 2018 at 14:29, on Zulip):

I should see how this behaves if you do that

RalfJ (Nov 07 2018 at 14:29, on Zulip):

with one glaring exception: promotion

RalfJ (Nov 07 2018 at 14:29, on Zulip):

promotion makes some things const context that the user didnt write in const context.

pnkfelix (Nov 07 2018 at 14:29, on Zulip):

okay, is this a case where promotion applies then?

RalfJ (Nov 07 2018 at 14:29, on Zulip):

but in this case, there's no promotion, so this must be the const_prop pass

pnkfelix (Nov 07 2018 at 14:29, on Zulip):

(because I think that was what I was thinking of. Sure, yeah, that's the ticket)

pnkfelix (Nov 07 2018 at 14:30, on Zulip):

There's no promotion... because its not a &--128 or something?

RalfJ (Nov 07 2018 at 14:30, on Zulip):

exactly

oli (Nov 07 2018 at 14:35, on Zulip):

Const prop is slightly hacky, because it had to replicate the old const folding const evaluator

oli (Nov 07 2018 at 14:36, on Zulip):

We could make const prop deterministic, so that --release overflows are also detected

oli (Nov 07 2018 at 14:38, on Zulip):

But we need to have a big discussion about the future of const prop anyway... I don't think it is good the way it is, because we're partially reimplementing miri

pnkfelix (Nov 07 2018 at 14:40, on Zulip):

Okay. Well this isn't the only case of a test that depends on the -O flag (cc T-compiler topic), so I'll leave this be for now

Last update: Nov 15 2019 at 20:05UTC