similar to: Debugging a potential bug when generating wasm32

wasm-ld is currently unable to link a shared wasm library (generated with `wasm-ld --shared`) with .o files and produce a working executable. I'm curious if there's a fundamental reason for this, or is this simply something that wasn't needed and could be implemented if needed. I think this could be done by - Resolving "GOT.mem" and "GOT.func" imports and

On 9/25/20 5:14 AM, Aur?lien Aptel wrote: > Ken Bass via samba <samba at lists.samba.org> writes: >> Can you please expand on this, I am confused as to what you are >> suggesting.? If 'getent pass' works properly and shows no >> overlap/confusion, this seems to be related to cifsacl. > It's still hard to say at this point. > > cifs.idmap logs

On 9/25/20 12:23 PM, Rowland penny via samba wrote: > On 25/09/2020 17:15, Ken Bass via samba wrote: >> On 9/25/20 5:14 AM, Aur?lien Aptel wrote: >>> Ken Bass via samba <samba at lists.samba.org> writes: >>>> Can you please expand on this, I am confused as to what you are >>>> suggesting.? If 'getent pass' works properly and shows no

Hi, the german telco Colt Telekom has assigned the phone number block 56830-xxx to one of our customers. In the diaplan we have setup extensions like the following ones: exten => 56830910,1,Answer() exten => 56830910,2,Dial(SIP/bduerring,10,tr) exten => 56830910,3,VoiceMail,u20 exten => 56830910,4,hangup exten => 56830910,103,VoiceMail,b20 exten => 56830910,104,hangup exten

Somehow I wish not all parts of a libc but parts that can be provided without a JavaScript wrapper for .wasm can be provided from llvm's libc (leaving a stab implementation for the rest like file system). I've put together a minimal libc on [1] so using a 26kb .wasm binary file one can decode both PNG and JPG using this [2] simple to integrate JavaScript code, can be easily ported in other

Hello, Lately, I have been working on moving Debian & Ubuntu packages to a stage2 build. This means that, instead of shipping llvm-toolchain packages built with gcc, we are rebuilding everything a second time using the newly built clang. Now, when pushed to Debian, it caused some unexpected issues in particular with rust reported here:

On Wed, Nov 11, 2015 at 07:14:28PM -0800, Sean Silva via llvm-dev wrote: > Can you show a real benchmark that users have tried to write where the call > overhead of actually using an external function call is measurable? This is the wrong question. The correct question is: What useful benchmark cannot trivally factor out the overhead of the external function call. Yes, if you do

On 25/09/2020 17:15, Ken Bass via samba wrote: > On 9/25/20 5:14 AM, Aur?lien Aptel wrote: >> Ken Bass via samba <samba at lists.samba.org> writes: >>> Can you please expand on this, I am confused as to what you are >>> suggesting.? If 'getent pass' works properly and shows no >>> overlap/confusion, this seems to be related to cifsacl. >>

Hi llvmers, As you may know, work has been progressing on the experimental WebAssembly backend in llvm. However, there is currently not a good linking story. Most the of existing linking strategies (i.e. those in the emscripten toolchain) involve bitcode linking and whole program compilation at link time. To improve this situation I've been working on adding a wasm backend for lld. My

Can you link to docs about the wasm object format? (both relocatable and executable) Also, traditional object file linkers are primarily concerned with concatenating binary blobs with small amount of patching of said binary blobs based on computed virtual (memory) addresses. Or perhaps to put it another way, what traditional object file linkers do is construct program images meant to be mapped

Back in December, there was some discussion here about the Ultra 20''s bios being confused by the EFI labels ZFS uses. After seeing a report about the X2100 exhibiting the same behavior as the Ultra 20, I reproduced the problem and filed: 6407133 X2100 bios intimidated by ZFS-created EFI labels hopefully that bios will get fixed, too. - Bill

The beautiful world of uncontained dependencies: - We restrict mockall to 0.11.0, which in practice currently expands to 0.11.4, - mockall depends on predicates-tree, - predicates-tree depends on predicates-core, - approx. two weeks ago, predicates-tree and predicates-core have seen *PATCHLEVEL* upgrades (1.0.7 -> 1.0.9, and 1.0.5 -> 1.0.6, respectively) that now require

On Tue, Jul 02, 2019 at 10:14:19PM +0900, Hiroyuki Katsura wrote: >From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> > >--- > Makefile.am | 4 ++++ > configure.ac | 3 +++ > generator/Makefile.am | 3 +++ > generator/bindtests.ml | 3 +++ > generator/bindtests.mli | 1 + > generator/main.ml | 5 +++++ > generator/rust.ml

I originally meant to post only the "vector.h" patch, but then (independently) nbdkit wouldn't build. Hence the other (rust plugin) patch. Laszlo Laszlo Ersek (2): common/utils: document empty_vector compound literal assignment plugins/rust: restrict predicates-{tree,core} to {1.0.7,1.0.5} common/utils/vector.h | 8 +++++++- plugins/rust/Cargo.toml | 2 ++ 2 files changed,

I have been working on adding proper tail (via `become`) to rustc. I was able to make them work (some parts of the type checker aren't implemented yet). However, I ran into an LLVM-related problem. LLVM claims to support proper tail calls when fastcc is used — but only on i386, x86-64 and PowerPC. Is this accurate? Will proper tail calls be supported on WebAssembly? Are they supported on

On 9/24/20 1:06 PM, Rowland penny via samba wrote: > OK, you are using users & groups in the 1000-29999 range, why ? could > it be that you have the same users in /etc/passwd and AD ? On my Linux installs, I allow for a 'local' account with user id 1000. That is the only local account and is used for installing the OS (or in case AD is down). All other user/group accounts are

Cause llvm-libc are in early stage, and we can easily catch up the support with linux. After we add wasi support in llvm-lic, we can easily get a usable llvm-libc across different platform such as linux/windows/macos/android. don't know if iOS is a target, but these target are very much enough -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An

Hi, This is Ariel from the Rust team again. I am having another pass ordering issue. Looking at the pass manager at https://github.com/llvm-mirror/llvm/blob/7034870f30320d6fbc74effff539d946018cd00a/lib/Transforms/IPO/PassManagerBuilder.cpp (the early SimplifyCfg now doesn't sink stores anymore! I can't wait until I can get to use that in rustc!) I find that the loop optimization group

Hi, compiler-rt builtins currently doesn't build on MSVC 2019, I the problem is that compiler-rt\lib\builtins\int_math.h includes the header ymath.h. according to eg. https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/finite-finitef?view=vs-2019 the header to include is float.h also the ymath.h file contains the comment /* ymath.h internal header */ so probably shall not be

On Thu, Sep 12, 2019 at 8:18 AM Teresa Johnson <tejohnson at google.com> wrote: > I just have a couple suggestions off the top of my head: > - have you tried using the new pass manager > (-fexperimental-new-pass-manager)? That has access to additional analysis > info during inlining and is able to make more precise PGO based inline > decisions. > (although note the above