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

Make `librustc_codegen_llvm` aware of LLVM address spaces. #51576

Open
wants to merge 3 commits into
base: master
from

Conversation

Projects
None yet
@DiamondLovesYou
Contributor

DiamondLovesYou commented Jun 15, 2018

In order to not require overloading functions based on their argument's address
space (among other things), we require the presence of a "flat" (ie an address
space which is shared with every other address space) address space.

This isn't exposed in any way to Rust code. This just makes Rust compatible with
LLVM target machines which, for example, place allocas in a different address
space. amdgcn-amd-amdhsa-amdgiz is a specific example, which places allocas in
address space 5 or the private (at the work item level) address space. This
includes working with nonuniform sized pointers.

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Jun 15, 2018

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

@Mark-Simulacrum

The rustbuild changes look acceptable to me.

@@ -38,6 +38,7 @@ use cache::Interned;
pub struct Llvm {
pub target: Interned<String>,
pub emscripten: bool,
pub dump_enabled: bool,

This comment has been minimized.

@Mark-Simulacrum

Mark-Simulacrum Jun 15, 2018

Member

There should be no need for this here as AFAICT it's always globally set, we never do anything but pass it in from config.llvm_dump_enabled.

@@ -15,7 +15,7 @@ use llvm::{AtomicRmwBinOp, AtomicOrdering, SynchronizationScope, AsmDialect};
use llvm::{Opcode, IntPredicate, RealPredicate, False, OperandBundleDef};
use llvm::{ValueRef, BasicBlockRef, BuilderRef, ModuleRef};
use common::*;
use type_::Type;
use type_::{Type, };

This comment has been minimized.

@Mark-Simulacrum

Mark-Simulacrum Jun 15, 2018

Member

This looks wrong.

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Jun 18, 2018

Contributor

Indeed!

@@ -10,6 +10,7 @@ crate-type = ["dylib"]

[dependencies]
bitflags = "1.0"
syntax_pos = { path = "../libsyntax_pos" }

This comment has been minimized.

@Mark-Simulacrum

Mark-Simulacrum Jun 15, 2018

Member

I don't see this dependency actually being used -- but maybe I'm missing something?

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

rustc_target shouldn't have any dependencies on the compiler, so hopefully this is unused.

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Jun 18, 2018

Contributor

It is used for custom address space names.

Oh, it was. I forgot I had removed it.

@Mark-Simulacrum

This comment has been minimized.

Member

Mark-Simulacrum commented Jun 15, 2018

r? @eddyb probably

@rust-highfive rust-highfive assigned eddyb and unassigned petrochenkov Jun 15, 2018

@@ -553,6 +553,13 @@ impl Handler {
db.emit();
panic!(ExplicitBug);
}
pub fn bug_no_panic(&self, msg: &str) {

This comment has been minimized.

@eddyb
@eddyb

This comment has been minimized.

Member

eddyb commented Jun 15, 2018

cc @alexcrichton

I'm still reading, but some of the details seem a bit more invasive than I expected. reviewed

@@ -47,3 +47,4 @@ jemalloc = ["rustc_target/jemalloc"]
# when this option is enabled or not. That way we can build two, cache two
# artifacts, and have nice speedy rebuilds.
emscripten = ["rustc_llvm/emscripten"]
dump = ["rustc_llvm/dump"]

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

Missing newline at the end of file.

bx.pointercast(dst.llval, Type::i8p(cx)),
bx.pointercast(llscratch, Type::i8p(cx)),
bx.pointercast(dst.llval, ti8.ptr_to_as(dst_addr_space)),
bx.pointercast(llscratch, ti8.ptr_to_as(addr_space)),

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

If this is common, wouldn't a replacement for pointercast that only casts the pointee, but preserves the AS, be better?

@@ -567,7 +571,9 @@ impl<'a, 'tcx> FnTypeExt<'a, 'tcx> for FnType<'tcx, Ty<'tcx>> {
}
PassMode::Cast(cast) => cast.llvm_type(cx),
PassMode::Indirect(_) => {
llargument_tys.push(self.ret.memory_ty(cx).ptr_to());
let ty = self.ret.memory_ty(cx)
.ptr_to_as(cx.alloca_addr_space());

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

Instead of having a method to retrieve a specific AS and then another to create a pointer type, why not have e.g. .alloca_ptr_to(cx) or .ptr_to(cx, AddrSpaceKind::Alloca) (okay, the latter is a bit long).

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Jun 18, 2018

Contributor

I actually already have those functions, I just probably added them after I wrote some of this 😄

llargument_tys.push(arg.layout.scalar_pair_element_llvm_type(cx, 1));
let data_ty = arg.layout.scalar_pair_element_llvm_type(cx, 0)
.as_flat_addr_space(cx);
// Keep the original addrspace, dst's of course aren't ptrs,

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

By "dst" you mean "slice (length)"? Also, I should note this doesn't necessarily work.
The pair could just as well be (&T, &U) where T: Sized, U: Sized.

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

A better approach might be to pass something extra to scalar_pair_element_llvm_type. Same for everything else, really.

(bx.pointercast(src, ptr_ty), unsized_info(bx.cx, a, b, None))
}
(&ty::TyAdt(def_a, _), &ty::TyAdt(def_b, _)) if def_a.is_box() && def_b.is_box() => {
let (a, b) = (src_ty.boxed_ty(), dst_ty.boxed_ty());
assert!(bx.cx.type_is_sized(a));
let ptr_ty = bx.cx.layout_of(b).llvm_type(bx.cx).ptr_to();
let ptr_ty = bx.cx.layout_of(b).llvm_type(bx.cx)
.ptr_to_as(val_ty(src).address_space());
(bx.pointercast(src, ptr_ty), unsized_info(bx.cx, a, b, None))

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

Same here, regarding the usecase of only needed to cast the pointee type.

}
}
}
}

This comment has been minimized.

@eddyb
let g = declare::define_global(cx, &sym[..], val_ty(sc)).unwrap_or_else(||{
bug!("symbol `{}` is already defined", sym);
});
let addr_space = cx.default_const_addr_space();

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

Maybe pass the AddrSpaceKind enum value around instead of the LLVM AS number?

@@ -64,13 +64,16 @@ fn set_global_alignment(cx: &CodegenCx,
pub fn addr_of_mut(cx: &CodegenCx,
cv: ValueRef,
align: Align,
kind: &str)
kind: &str,
addr_space: Option<AddrSpaceIdx>)

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

There shouldn't be that many calls, making this non-optional (and using AddrSpaceKind) would be better IMO.

pub alloca_i8p_ty: Type,
pub const_i8p_ty: Type,
pub global_i8p_ty: Type,
pub flat_i8p_ty: Type,

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

We probably shouldn't have cached types like these.

pub dbg_cx: Option<debuginfo::CrateDebugContext<'tcx>>,

eh_personality: Cell<Option<ValueRef>>,
eh_unwind_resume: Cell<Option<ValueRef>>,
pub rust_try_fn: Cell<Option<ValueRef>>,

intrinsics: RefCell<FxHashMap<&'static str, ValueRef>>,
intrinsics: RefCell<FxHashMap<Cow<'static, str>, ValueRef>>,

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

I think this is worse, because it incurs extra branching. Might as well switch it to String.

ifn!("llvm.memset.p0i8.i32", fn(i8p, t_i8, t_i32, t_i32, i1) -> void);
ifn!("llvm.memset.p0i8.i64", fn(i8p, t_i8, t_i64, t_i32, i1) -> void);
if key.starts_with("llvm.memcpy.") || key.starts_with("llvm.memmove") ||
key.starts_with("llvm.memset") {

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

memcpy has a dot at the end, but the others don't?

llpair = bx.insert_value(llpair, a, 0);
let b = b.copy_addr_space(bx, val_ty(llpair).struct_element_type(1));

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

Why would these two be needed?

PlaceRef {
// HACK(eddyb) have to bitcast pointers until LLVM removes pointee types.
llval: bx.pointercast(llval, field.llvm_type(cx).ptr_to()),
llval: bx.pointercast(llval, dest_ty),

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

Again, could have a pointercast variant that only casts the pointee.

let asp = val_ty(downcast.llval).address_space();
downcast.llval = bx
.pointercast(downcast.llval,
variant_ty.ptr_to_as(asp));

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

Same here.

@@ -17,6 +17,7 @@ use rustc::middle::lang_items::ExchangeMallocFnLangItem;
use rustc_apfloat::{ieee, Float, Status, Round};
use std::{u128, i128};

use abi::{FnType, FnTypeExt, };

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

Superfluous , .

} else {
fn_ret_val
};
let val = bx.pointercast(ret_val, llty_ptr);

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

What is this all doing? Why would the function being called here ever return by indirection?

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Jul 3, 2018

Contributor

Accidentally included. Was created when I was trying to figure out how to work with the AMDGPU target machine. I tried having every function be the amdgpu kernel abi, which doesn't allow non-void return types.

Removed in the next version, to be pushed Soon(TM).

} else {
cx.default_global_addr_space()
}
},

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

We should avoid touching the HIR here, but it's not clear what requirements there actually are.

This comment has been minimized.

@DiamondLovesYou

DiamondLovesYou Jul 3, 2018

Contributor

We need the address space of the global for the global's LLVM type, meaning it needs to compute the same address space as consts::codegen_static.

At the time, I wasn't aware of a better way, but the next version now does what MonoItemExt::define does.

pub fn is_array(&self) -> bool { self.kind() == llvm::TypeKind::Array }
pub fn is_vector(&self) -> bool { self.kind() == llvm::TypeKind::Vector }
pub fn is_struct(&self) -> bool { self.kind() == llvm::TypeKind::Struct }
pub fn is_func(&self) -> bool { self.kind() == llvm::TypeKind::Function }

This comment has been minimized.

@eddyb

eddyb Jun 15, 2018

Member

Why all of these? We should avoid introspecting LLVM types at all costs IMO.

@eddyb

I don't see how any of the code around read-only and read-write global address spaces, actually works. Why are vtable pointers different from any other pointer?
If there is a flat address space, why isn't it used more often? Some documentation would help.

I hope there is a simpler way to support the target platform you want.

kennytm added a commit to kennytm/rust that referenced this pull request Nov 8, 2018

Rollup merge of rust-lang#54993 - TimNN:pda-tdl, r=eddyb
Support for the program data address space option of LLVM's Target Datalayout

This was introduced recently (specifically, for AVR, cc @dylanmckay).

(I came up with this when attempting to run [avr-rust](https://github.com/avr-rust/rust) rebased on the latest [rust-lang](https://github.com/rust-lang/rust) commits. If this requires a different design, some additional discussions, or is not something to pursue right now, I'd be happy to close this PR).

Note that this somewhat overlaps with @DiamondLovesYou's rust-lang#51576, I think, although the implementation here is significantly simpler: Since the address space applies to _all_ program data, we can just check the pointee's type whenever we create an LLVM pointer type. If it is a function we use the program data address space; if not we use the default address space.

cc @eddyb, who has been reviewing rust-lang#51576

Ref: https://llvm.org/docs/LangRef.html#data-layout

bors added a commit that referenced this pull request Nov 9, 2018

Auto merge of #54993 - TimNN:pda-tdl, r=eddyb
Support for the program data address space option of LLVM's Target Datalayout

This was introduced recently (specifically, for AVR, cc @dylanmckay).

(I came up with this when attempting to run [avr-rust](https://github.com/avr-rust/rust) rebased on the latest [rust-lang](https://github.com/rust-lang/rust) commits. If this requires a different design, some additional discussions, or is not something to pursue right now, I'd be happy to close this PR).

Note that this somewhat overlaps with @DiamondLovesYou's #51576, I think, although the implementation here is significantly simpler: Since the address space applies to _all_ program data, we can just check the pointee's type whenever we create an LLVM pointer type. If it is a function we use the program data address space; if not we use the default address space.

cc @eddyb, who has been reviewing #51576

Ref: https://llvm.org/docs/LangRef.html#data-layout

bors added a commit that referenced this pull request Nov 9, 2018

Auto merge of #54993 - TimNN:pda-tdl, r=eddyb
Support for the program data address space option of LLVM's Target Datalayout

This was introduced recently (specifically, for AVR, cc @dylanmckay).

(I came up with this when attempting to run [avr-rust](https://github.com/avr-rust/rust) rebased on the latest [rust-lang](https://github.com/rust-lang/rust) commits. If this requires a different design, some additional discussions, or is not something to pursue right now, I'd be happy to close this PR).

Note that this somewhat overlaps with @DiamondLovesYou's #51576, I think, although the implementation here is significantly simpler: Since the address space applies to _all_ program data, we can just check the pointee's type whenever we create an LLVM pointer type. If it is a function we use the program data address space; if not we use the default address space.

cc @eddyb, who has been reviewing #51576

Ref: https://llvm.org/docs/LangRef.html#data-layout

bors added a commit that referenced this pull request Nov 11, 2018

Auto merge of #54993 - TimNN:pda-tdl, r=eddyb
Support for the program data address space option of LLVM's Target Datalayout

This was introduced recently (specifically, for AVR, cc @dylanmckay).

(I came up with this when attempting to run [avr-rust](https://github.com/avr-rust/rust) rebased on the latest [rust-lang](https://github.com/rust-lang/rust) commits. If this requires a different design, some additional discussions, or is not something to pursue right now, I'd be happy to close this PR).

Note that this somewhat overlaps with @DiamondLovesYou's #51576, I think, although the implementation here is significantly simpler: Since the address space applies to _all_ program data, we can just check the pointee's type whenever we create an LLVM pointer type. If it is a function we use the program data address space; if not we use the default address space.

cc @eddyb, who has been reviewing #51576

Ref: https://llvm.org/docs/LangRef.html#data-layout

@DiamondLovesYou DiamondLovesYou force-pushed the DiamondLovesYou:rustc-trans-addr-space branch from e1c2a5f to 96826e7 Nov 17, 2018

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Nov 17, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:015ff700:start=1542415603662435374,finish=1542415604842538952,duration=1180103578
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Downloading https://files.pythonhosted.org/packages/a6/da/c99b10bfc509cbbea520886d2e8fe0e738e3ce22e2f528381f3bb2229433/awscli-1.16.57-py2.py3-none-any.whl (1.4MB)
    0% |▎                               | 10kB 30.8MB/s eta 0:00:01
    1% |▌                               | 20kB 1.9MB/s eta 0:00:01
    2% |▊                               | 30kB 2.2MB/s eta 0:00:01
    2% |█                               | 40kB 2.0MB/s eta 0:00:01
---

[00:03:51] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:03:51] tidy error: /checkout/src/librustc_codegen_llvm/mir/rvalue.rs:80: line longer than 100 chars
[00:03:51] tidy error: /checkout/src/librustc_codegen_llvm/mir/mod.rs:315: line longer than 100 chars
[00:03:51] tidy error: /checkout/src/librustc_codegen_llvm/mir/block.rs:257: line longer than 100 chars
[00:03:51] tidy error: /checkout/src/librustc_codegen_llvm/intrinsic.rs:572: line longer than 100 chars
[00:03:53] some tidy checks failed
[00:03:53] 
[00:03:53] 
[00:03:53] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:03:53] 
[00:03:53] 
[00:03:53] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:53] Build completed unsuccessfully in 0:00:49
[00:03:53] Build completed unsuccessfully in 0:00:49
[00:03:53] make: *** [tidy] Error 1
[00:03:53] Makefile:79: recipe for target 'tidy' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:00e13840
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Sat Nov 17 00:50:48 UTC 2018
---
travis_time:end:0dcb4ae8:start=1542415848900825500,finish=1542415848907297058,duration=6471558
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0258d5b0
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:2539088c
travis_time:start:2539088c
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0c51e469
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@DiamondLovesYou DiamondLovesYou force-pushed the DiamondLovesYou:rustc-trans-addr-space branch 2 times, most recently from 0bbb650 to 89cfad3 Nov 17, 2018

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Nov 17, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:152f2050:start=1542416636926369794,finish=1542416638059220247,duration=1132850453
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Downloading https://files.pythonhosted.org/packages/a6/da/c99b10bfc509cbbea520886d2e8fe0e738e3ce22e2f528381f3bb2229433/awscli-1.16.57-py2.py3-none-any.whl (1.4MB)
    0% |▎                               | 10kB 1.6MB/s eta 0:00:01
    1% |▌                               | 20kB 1.0MB/s eta 0:00:02
    2% |▊                               | 30kB 1.1MB/s eta 0:00:02
    2% |█                               | 40kB 1.1MB/s eta 0:00:02
---

[00:03:44] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:03:44] tidy error: /checkout/src/librustc_codegen_llvm/mir/rvalue.rs:80: line longer than 100 chars
[00:03:44] tidy error: /checkout/src/librustc_codegen_llvm/mir/mod.rs:315: line longer than 100 chars
[00:03:44] tidy error: /checkout/src/librustc_codegen_llvm/mir/block.rs:257: line longer than 100 chars
[00:03:44] tidy error: /checkout/src/librustc_codegen_llvm/intrinsic.rs:572: line longer than 100 chars
[00:03:45] some tidy checks failed
[00:03:45] 
[00:03:45] 
[00:03:45] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:03:45] 
[00:03:45] 
[00:03:45] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:03:45] Build completed unsuccessfully in 0:00:48
[00:03:45] Build completed unsuccessfully in 0:00:48
[00:03:45] Makefile:79: recipe for target 'tidy' failed
[00:03:45] make: *** [tidy] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:242ee3b4
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Sat Nov 17 01:07:54 UTC 2018
---
travis_time:end:1a46baee:start=1542416874953295564,finish=1542416874959495876,duration=6200312
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1db2f813
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:03f66546
travis_time:start:03f66546
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:0091da2a
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@DiamondLovesYou DiamondLovesYou force-pushed the DiamondLovesYou:rustc-trans-addr-space branch from 89cfad3 to 027c2a5 Nov 17, 2018

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Nov 17, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:04304504:start=1542417640761287941,finish=1542417641880790491,duration=1119502550
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Downloading https://files.pythonhosted.org/packages/a6/da/c99b10bfc509cbbea520886d2e8fe0e738e3ce22e2f528381f3bb2229433/awscli-1.16.57-py2.py3-none-any.whl (1.4MB)
    0% |▎                               | 10kB 11.4MB/s eta 0:00:01
    1% |▌                               | 20kB 1.8MB/s eta 0:00:01
    2% |▊                               | 30kB 2.2MB/s eta 0:00:01
    2% |█                               | 40kB 2.0MB/s eta 0:00:01
---

[00:04:05] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:05] tidy error: /checkout/src/librustc_codegen_llvm/mir/rvalue.rs:80: line longer than 100 chars
[00:04:05] tidy error: /checkout/src/librustc_codegen_llvm/mir/mod.rs:315: line longer than 100 chars
[00:04:05] tidy error: /checkout/src/librustc_codegen_llvm/mir/block.rs:257: line longer than 100 chars
[00:04:06] some tidy checks failed
[00:04:06] 
[00:04:06] 
[00:04:06] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:06] 
[00:04:06] 
[00:04:06] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:06] Build completed unsuccessfully in 0:00:51
[00:04:06] Build completed unsuccessfully in 0:00:51
[00:04:06] Makefile:79: recipe for target 'tidy' failed
[00:04:06] make: *** [tidy] Error 1
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:0a810f51
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Sat Nov 17 01:24:58 UTC 2018
---
travis_time:end:1fe9aebd:start=1542417898567464651,finish=1542417898575283186,duration=7818535
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:14f1bc88
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:01f131f3
travis_time:start:01f131f3
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:2ee1c5d2
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@DiamondLovesYou DiamondLovesYou force-pushed the DiamondLovesYou:rustc-trans-addr-space branch from 027c2a5 to 0dfd557 Nov 17, 2018

@bors

This comment has been minimized.

Contributor

bors commented Nov 17, 2018

☔️ The latest upstream changes (presumably #55627) made this pull request unmergeable. Please resolve the merge conflicts.

@Centril Centril added S-blocked and removed S-blocked labels Dec 1, 2018

@DiamondLovesYou DiamondLovesYou force-pushed the DiamondLovesYou:rustc-trans-addr-space branch 2 times, most recently from 87c22a5 to 3ad92f6 Dec 6, 2018

@bors

This comment has been minimized.

Contributor

bors commented Dec 8, 2018

☔️ The latest upstream changes (presumably #56578) made this pull request unmergeable. Please resolve the merge conflicts.

@DiamondLovesYou DiamondLovesYou force-pushed the DiamondLovesYou:rustc-trans-addr-space branch from 3ad92f6 to 2ee942f Dec 9, 2018

@mati865

This comment has been minimized.

Contributor

mati865 commented Dec 10, 2018

This PR was labelled as Blocked 2 months ago:

Waiting on people to be freed up from work on the 2018 edition

@BatmanAoD is it still the case?

@pietroalbini

This comment has been minimized.

Member

pietroalbini commented Dec 11, 2018

Review ping @eddyb

@bors

This comment has been minimized.

Contributor

bors commented Dec 13, 2018

☔️ The latest upstream changes (presumably #55982) made this pull request unmergeable. Please resolve the merge conflicts.

DiamondLovesYou added some commits Sep 12, 2018

Make `librustc_codegen_llvm` aware of LLVM address spaces.
In order to not require overloading functions based on their argument's address
space (among other things), we require the presence of a "flat" (ie an address
space which is shared with every other address space) address space.

This isn't exposed in any way to Rust code. This just makes Rust compatible with
LLVM target machines which, for example, place allocas in a different address
space. `amdgcn-amd-amdhsa-amdgiz` is a specific example, which places allocas in
address space 5 or the private (at the work item level) address space.

@DiamondLovesYou DiamondLovesYou force-pushed the DiamondLovesYou:rustc-trans-addr-space branch from 2ee942f to e517b7c Dec 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment