Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MIR trans] Translate statics #29759

Merged
merged 2 commits into from
Nov 13, 2015
Merged

[MIR trans] Translate statics #29759

merged 2 commits into from
Nov 13, 2015

Conversation

nagisa
Copy link
Member

@nagisa nagisa commented Nov 10, 2015

Fixes #29578

r? @nikomatsakis

My own observations are posted inline as comments.

// The LLVM global has the type of its initializer,
// which may not be equal to the enum's type for
// non-C-like enums.
let val = base::get_item_val(bcx.ccx(), node_id);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may want to get somehow MIR-ified/updated as well because it causes an unnecessary alloca.

@eefriedman
Copy link
Contributor

LGTM

// non-C-like enums.
let val = base::get_item_val(bcx.ccx(), node_id);
let pty = type_of::type_of(bcx.ccx(), const_ty).ptr_to();
PointerCast(bcx, val, pty)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this cast business just out of date?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to efriedman we do necessary casting sometime later in trans.
On Nov 11, 2015 4:01 PM, "Niko Matsakis" notifications@github.com wrote:

In src/librustc_trans/trans/expr.rs
#29759 (comment):

         let const_ty = expr_ty(bcx, ref_expr);

  •        // For external constants, we don't inline.
    
  •        let val = if let Some(node_id) = bcx.tcx().map.as_local_node_id(did) {
    

- // Case 1.

  •            // The LLVM global has the type of its initializer,
    
  •            // which may not be equal to the enum's type for
    
  •            // non-C-like enums.
    
  •            let val = base::get_item_val(bcx.ccx(), node_id);
    
  •            let pty = type_of::type_of(bcx.ccx(), const_ty).ptr_to();
    
  •            PointerCast(bcx, val, pty)
    

is this cast business just out of date?


Reply to this email directly or view it on GitHub
https://github.com/rust-lang/rust/pull/29759/files#r44534266.

@nikomatsakis
Copy link
Contributor

I see now the conversation between @eefriedman and @nagisa. OK, LGTM!

@nikomatsakis
Copy link
Contributor

@bors r+

Thanks!

@bors
Copy link
Contributor

bors commented Nov 11, 2015

📌 Commit f1342ff has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Nov 11, 2015

⌛ Testing commit f1342ff with merge 0fd9ac5...

@bors
Copy link
Contributor

bors commented Nov 11, 2015

💔 Test failed - auto-linux-64-nopt-t

@nagisa
Copy link
Member Author

nagisa commented Nov 11, 2015

I have an approximate guess as to why SIGSEGV might happen. Previously get_static_val used to call trans_external_path and were static contain a function in it, it would SIGSEGV LLVM, so I changed trans_external_path to just trans_extern_const – its a get_static_val after all.

However, I think that might be a reason for us miscompiling something somewhere in libstd and therefore this generalisation proposed by @eefriedman cannot be applied, at least at the moment. I’ll revert the generalisation and use the regular PointerCastey code in MIR as well if this turns out to be true.


That being said, I cannot reproduce this failure locally (and the test that seems to run next doesn’t seem to be relevant at all env::tests::join_paths_unix), therefore I’d like a try run or re-r+ before I revert if this was, perchance, some natural phenomenon at work.

@nikomatsakis
Copy link
Contributor

Huh. So I think that the PointerCast would not lead to a SEGV, but rather a type error from LLVM -- although it may be that we run without LLVM's integrity assertions or something, which could cause a SEGV I gues.

@nikomatsakis
Copy link
Contributor

@bors try

@nikomatsakis
Copy link
Contributor

Anyway, we can certainly do a try run, but that errors looks legit to me.

@nikomatsakis
Copy link
Contributor

@alexcrichton says he HAS seen this sort of crash before, though it occurs very rarely.

@nikomatsakis
Copy link
Contributor

@bors r- retry try

bors added a commit that referenced this pull request Nov 12, 2015
Fixes #29578

r? @nikomatsakis

My own observations are posted inline as comments.
@bors
Copy link
Contributor

bors commented Nov 12, 2015

⌛ Trying commit f1342ff with merge 2adb618...

@arielb1
Copy link
Contributor

arielb1 commented Nov 12, 2015

@nikomatsakis

If you are compiling without --enable-llvm-assertions, LLVM assertion failures cause a core dump.

@nagisa
Copy link
Member Author

nagisa commented Nov 12, 2015

Try build seems to have succeeded (see towards the bottom of http://buildbot.rust-lang.org/grid?branch=try&refresh=15)

@nikomatsakis
Copy link
Contributor

@bors r+

let's give this another go.

@bors
Copy link
Contributor

bors commented Nov 13, 2015

📌 Commit f1342ff has been approved by nikomatsakis

@nikomatsakis
Copy link
Contributor

@bors try- retry r+

@bors
Copy link
Contributor

bors commented Nov 13, 2015

📌 Commit f1342ff has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Nov 13, 2015

⌛ Testing commit f1342ff with merge 3beb159...

bors added a commit that referenced this pull request Nov 13, 2015
Fixes #29578

r? @nikomatsakis

My own observations are posted inline as comments.
@bors bors merged commit f1342ff into rust-lang:master Nov 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants