Commit Graph

792 Commits (462b73c1fe1f67a62223a3ccf830f02a2571c016)

Author SHA1 Message Date
Ian Kronquist 462b73c1fe Implement bcmp (#315)
As of LLVM 9.0, certain calls to memcmp may be converted to bcmp, which I guess
could save a single subtraction on some architectures. [1]

bcmp is just like memcmp except instead of returning the difference between the
two differing bytes, it returns non-zero instead. As such, memcmp is a valid
implementation of bcmp.

If we care about size, bcmp should just call memcmp.
If we care about speed, we can change bcmp to look like this instead:
```rust
pub unsafe extern "C" fn bcmp(s1: *const u8, s2: *const u8, n: usize) -> i32 {
    let mut i = 0;
    while i < n {
        let a = *s1.offset(i as isize);
        let b = *s2.offset(i as isize);
        if a != b {
            return 1;
        }
        i += 1;
    }
    0
}
```

In this PR I do not address any changes which may or may not be needed for arm
aebi as I lack proper test hardware.

[1]: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#noteworthy-optimizations
2019-09-30 11:02:47 -05:00
Alex Crichton ea5db23a6a Remove `-nursery` from urls 2019-09-25 11:20:14 -07:00
Alex Crichton 711d17fb3c Update the gitmodule url for `libm` 2019-09-25 11:19:35 -07:00
Alex Crichton 1ac3970855 Migrate to github actions from Azure Pipelines
Less need to manage users, more concurrency, and interface is all in
one!
2019-09-10 21:57:13 -05:00
Alex Crichton 03875452c9
Merge pull request #313 from Lokathor/lokathor-tries-git
Lokathor tries to use the .gitmodules
2019-09-10 08:39:45 -05:00
Lokathor 893fe7e5de update the libm submodule, again 2019-09-09 19:43:37 -06:00
Lokathor 0a3e283c7c Update build.rs 2019-09-06 18:02:11 -06:00
Lokathor 095f020122 Update build.rs 2019-09-06 15:20:05 -06:00
Lokathor b3f16e25f2 Update the libm submodule 2019-09-06 13:48:15 -06:00
Lokathor a14ee75a24 i was told to change this path to my repo and reset things 2019-09-06 11:37:00 -06:00
Alex Crichton 44dc22f34d
Merge pull request #312 from Ralith/elementwise-unordered-atomics
Tidy up unordered elementwise atomic memory intrinsics
2019-08-23 11:07:41 -07:00
Benjamin Saunders 9775f08b1d Tidy up unordered elementwise atomic memory intrinsics 2019-08-23 10:20:09 -07:00
Alex Crichton bc57f53b5d
Merge pull request #311 from Ralith/elementwise-unordered-atomics
Implement LLVM's elementwise unordered atomic memory intrinsics
2019-08-22 16:01:41 -07:00
Benjamin Saunders 997b86d767 Implement LLVM's elementwise unordered atomic memory intrinsics
Allows uses of intrinsics of the form
llvm.(memcpy|memmove|memset).element.unordered.atomic.* to be linked.
2019-08-21 18:21:58 -07:00
Alex Crichton 1060f34342
Merge pull request #310 from alexcrichton/modernize
Modernize the `testcrate` slighty
2019-08-19 17:21:50 -05:00
Alex Crichton f0b43234dd
Merge pull request #309 from jgalenson/file-prefix-map
Support deterministic builds by remapping the __FILE__ prefix if the …
2019-08-19 17:20:33 -05:00
Joel Galenson c8f7928916 Update comment to mention where the __FILE__ macro is used. 2019-08-19 15:12:07 -07:00
Alex Crichton 332220adea Modernize the `testcrate` slighty
* Update `rand` dependency
* Drop `cast` in favor of explicit casting or crate-defined
* Move build script to 2018 edition
2019-08-19 14:02:08 -07:00
Joel Galenson ca423fe49a Support deterministic builds by remapping the __FILE__ prefix if the compiler supports it. 2019-08-19 09:30:45 -07:00
Alex Crichton 36da64f20e Bump to 0.1.19 2019-07-24 07:05:29 -07:00
Alex Crichton c8b08eb470
Merge pull request #306 from da-x/probestack-frame-pointer
probestack: add frame pointers for easier traceback
2019-07-24 09:04:02 -05:00
Dan Aloni 985a43095c probestack: add frame pointers for easier traceback
This turns the following backtrace,

```
>> bt
 #0  0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```

To this:

```
>>> bt
 #0  0x0000555555574e47 in __rust_probestack ()
 #1  0x00005555555595ba in test::main ()
 #2  0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
 #3  0x0000555555561ae3 in std::panicking::try::do_call ()
 #4  0x000055555556595a in __rust_maybe_catch_panic ()
 #5  0x000055555555af9b in std::rt::lang_start_internal ()
 #6  0x00005555555594d5 in std::rt::lang_start ()
 #7  0x000055555555977b in main ()
```
2019-07-24 10:18:30 +03:00
Alex Crichton 79a6a1603d Bump to 0.1.18 2019-07-19 07:44:17 -07:00
Alex Crichton e578d47247
Merge pull request #302 from bjorn3/no_128bit_lang_items
Replace {u,i}128_* lang items with __rust_{u,i}128_* unmangled functions
2019-07-19 09:44:00 -05:00
Alex Crichton 56f5b5d898
Merge pull request #301 from RalfJung/dyn
avoid bare trait objects
2019-07-15 10:04:18 -05:00
Alex Crichton 18f2d2d4ce Bump to 0.1.17 2019-07-15 07:26:49 -07:00
Alex Crichton 1ace961257
Merge pull request #300 from RalfJung/panic
avoid ptr::write which might panic in debug mode
2019-07-15 09:22:12 -05:00
bjorn3 7b716e6285 Fix tests 2019-07-13 12:27:58 +02:00
bjorn3 783430e6ae Replace {u,i}128_* lang items with __rust_{u,i}128_* unmangled functions
The -Zlower-128bit-ops feature is completely broken, as libcore needs
those lang items to compile with this feature, but they are only
provided by compiler_builtins, which itself depends on libcore.
According to rust-lang/rust#58969 the feature never got finished.

This commit removes the associated lang items and replaces them with
normal unmangled functions, when there is no existing intrinsic. This
makes it easier for alternative codegen backends to implement 128bit
integer support.
2019-07-13 11:38:35 +02:00
Ralf Jung 65dacd7150 avoid bare trait objects 2019-07-13 11:07:43 +02:00
Ralf Jung 25edd204fa remove unused imports 2019-07-13 11:00:15 +02:00
Ralf Jung ebeace71ce avoid ptr::write which might panic in debug mode 2019-07-13 10:55:54 +02:00
Alex Crichton 5e06435c29
Merge pull request #299 from varkor/0.1.16
Bump to 0.1.16
2019-06-06 09:25:08 -05:00
varkor d2b44e93b0 Bump to 0.1.16 2019-06-06 01:09:47 +01:00
Alex Crichton 9eafb677ad
Merge pull request #298 from varkor/update-libm
Update libm for fmin/fmax/fminf/fmaxf
2019-06-05 18:34:37 -05:00
Alex Crichton 5d5a85e6ea More fixes for CI 2019-06-05 16:19:26 -07:00
Alex Crichton 20827ad38f Attempt to fix CI 2019-06-05 16:09:39 -07:00
varkor bf3a9e9d0b Update libm for fmin/fmax/fminf/fmaxf 2019-06-05 23:41:18 +01:00
Alex Crichton 43bd89914c
Merge pull request #297 from spl/patch-1
Fix typo: mingw_unwinding
2019-05-21 08:35:12 -05:00
Sean Leather 82f898fd48
Fix typo: mingw_unwinding 2019-05-21 08:43:50 +02:00
Alex Crichton 4cd9d1cc53 Bump to 0.1.15 2019-05-16 08:12:14 -07:00
Alex Crichton f3f5f06d55
Merge pull request #294 from alexcrichton/no-submodule
Remove `compiler-rt` submodule from this repository
2019-05-16 10:10:58 -05:00
Alex Crichton aa41e0d25f Remove `compiler-rt` submodule from this repository
This commit removes the `compiler-rt` submodule from this repository.
The goal here is to align the `compiler-rt` used for compiling C
intrinsics with the upstream rust-lang/rust's usage of `llvm-project`.
Currently we have both an `llvm-project` repository as well as
`compiler-rt`, but they can naturally get out of sync and it's just one
more submodule to manage.

The thinking here is that the feature `c` for this crate, when
activated, will require the user to configure where the source code for
`compiler-rt` is present. This places the onus on the builder of
`compiler-builtins` to check-out and arrange for the appropriate
`compiler-rt` source code to be placed somewhere. For rust-lang/rust
this is already done with the `llvm-project` submodule, and we can
arrange for it to happen on this crate's CI anyway.

For users of this crate this is a bit of a bummer, but `c` is disabled
by default anyway and it seems unlikely that `c` is explicitly opted in
to all that much. (given the purpose of this crate)

This should allow us to archive the `compiler-rt` repository and simply
use `llvm-project` in the rust-lang/rust repository.
2019-05-16 07:50:20 -07:00
Alex Crichton 6566ad9e92 Bump to 0.1.14 2019-05-15 14:47:58 -07:00
Alex Crichton d9672420ab
Merge pull request #293 from alexcrichton/deduplicate-cfg
Remove the need for #[cfg] in #[use_c_shim_if]
2019-05-15 16:45:18 -05:00
Alex Crichton cf98161da7 Remove the need for #[cfg] in #[use_c_shim_if]
This commit tweaks the implementation of the synthetic
`#[use_c_shim_if]` attribute, renaming it to
`#[maybe_use_optimized_c_shim]` in the process. This no longer requires
specifying a `#[cfg]` clause indicating when the optimized intrinsic
should be used, but rather this is inferred and printed from the build
script.

The build script will now print out appropriate `#[cfg]` directives for
rustc to indicate what intrinsics it's compiling. This should remove the
need for us to keep the build script and the source in sync, but rather
the build script can simply take care of everything.
2019-05-15 12:59:31 -07:00
Alex Crichton 6178e2c611 Bump to 0.1.13 2019-05-14 14:41:07 -07:00
Alex Crichton c88c9502b7 Run rustfmt over everything 2019-05-14 14:40:38 -07:00
Alex Crichton ad1bcd2592
Merge pull request #291 from alexcrichton/fix-riscv
Don't compile C code on riscv targets
2019-05-14 16:40:27 -05:00
Alex Crichton e4f46b91ca Don't compile C code on riscv targets
This fixes a longstanding bug in compiler-builtins where C code was
compiled for the riscv targets but when distributed in rust-lang/rust
all the C code was actually compiled for x86_64 since there is no
configured C compiler for riscv. This was exposed by #286 by accident
but the underlying cause was somewhat unrelated.

For now we forcibly disable C code for riscv targets, and when the C
compiler story is sorted out in rust-lang/rust and with `cc-rs` we can
reenable. For now just use all the Rust definitions.

cc rust-lang/rust#60747
2019-05-14 14:29:29 -07:00