similar to: status on NewGVN?

On Fri, Jan 5, 2018 at 8:39 PM, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Greetings, > > I just found a bug in NewGVN: https://bugs.llvm.org/show_bug.cgi?id=35839 > I suspect this is a dupe of one of the three bugs we know about. > > > I noticed that it's off by default in clang. > > Yup. I'm going to turn it off by default in

> On 6 Jan 2018, at 04:53, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Jan 5, 2018 at 8:39 PM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Greetings, > > I just found a bug in NewGVN: https://bugs.llvm.org/show_bug.cgi?id=35839

Who maintains apt.llvm.org? On 11/27/18 9:25 AM, Andrew Kelley wrote: > ---------- Forwarded message --------- > From: Andrew Kelley <superjoe30 at gmail.com> > Date: Mon, Nov 26, 2018 at 10:38 AM > Subject: apt.llvm.org has the wrong binaries/headers for llvm-toolchain-xenial-7 > To: LLVM Dev <llvm-dev at lists.llvm.org> > > > This build worked on Nov 24 and

So, 90% of the time I've seen this, it was memory corruption, usually use after free. I know I fixed one after 5.0 branched. You should compile with address sanitizer enabled, and I suspect you will find the issue quicky. If not, we really need ir that reproduces it. On Sun, Sep 17, 2017, 12:27 PM Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think I forgot to

Can you please open a bug on bugzilla and attach the ir testcase? Your fix doesn't look right (just hiding the assertion failure) On Sep 17, 2017 10:45 AM, "Andrew Kelley via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > What do you think about this patch? > > --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp > +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp > @@

Thanks. This is a dupe of PR 34452. On Sun, Sep 17, 2017 at 2:40 PM, Andrew Kelley <superjoe30 at gmail.com> wrote: > > On Sun, Sep 17, 2017 at 4:21 PM, Davide Italiano <davide at freebsd.org> > wrote: > >> Dump the IR before newgvn and run through opt -newgvn. It should crash. >> I'm not familiar with your frontend but you might want to use -mllvm

When zig updated to llvm 5 we started hitting this assertion: zig: /home/andy/downloads/llvm-project/llvm/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = llvm::Instruction; From = llvm::Value]: Assertion `Val && "isa<> used on a null pointer"' failed. I wonder if however this was caused by an

I've got a patched LLD 5.0.0 like this: diff --git a/deps/lld/COFF/Driver.cpp b/deps/lld/COFF/Driver.cpp index 854c3e69..8bab1c11 100644 --- a/deps/lld/COFF/Driver.cpp +++ b/deps/lld/COFF/Driver.cpp @@ -1030,7 +1030,7 @@ void LinkerDriver::link(ArrayRef<const char *> ArgsArr) { if (!Args.hasArgNoClaim(OPT_INPUT)) { fixupExports(); createImportLibrary(/*AsLib=*/true); -

+Rui and Peter On Wed, Jul 25, 2018 at 8:34 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Here's a fix: > > --- a/lld/COFF/Driver.cpp > +++ b/lld/COFF/Driver.cpp > @@ -72,6 +72,9 @@ bool link(ArrayRef<const char *> Args, bool CanExitEarly, > raw_ostream &Diag) { > exitLld(errorCount() ? 1 : 0); > > freeArena(); > +

I think you want to call freeArena() before returning from lld::coff::link. On Sun, Oct 15, 2017 at 6:57 PM, Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I believe this line is the culprit: > > COFF/Driver.cpp:102: > make<std::unique_ptr<MemoryBuffer>>(std::move(MB)); // take ownership > > Patch forthcoming. > > > On Sun, Oct

If you call lld::coff::link twice, the second time gives this backtrace: msvcp140d.dll!00007ffc35830806() Unknown > zig.exe!std::_Debug_pointer<lld::coff::Chunk * __ptr64 const>(lld::coff::Chunk * const * _Ptr, const wchar_t * _File, unsigned int _Line) Line 926 C++ zig.exe!std::_Debug_range2<lld::coff::Chunk * __ptr64 const * __ptr64>(lld::coff::Chunk * const *

Zig Programming Language Zig <http://ziglang.org/> is a system programming language which prioritizes optimality, safety, and readability. It integrates closely with C and is intended to eventually take the place of C. It uses LLVM to produce highly optimized native code and to cross-compile for any target out of the box. Zig is in alpha; progress toward a beta release is underway.

I'd be interested in the existence of a high-quality, open-source, portable linker for apple platforms, but not enough to help make that happen. If I _was_ gonna work on something related to that, I'd probably be inclined to instead add any required features to allow an ELF linker to target a notional darwin-elf target, and to have clang emit darwin-elf object files, and then write a

I'm copying some LLD code into my codebase like this: // workaround for LLD not exposing ability to convert .def to .lib #include <set> namespace lld { namespace coff { class SymbolBody; class StringChunk; struct Symbol; struct Export { StringRef Name; // N in /export:N or /export:E=N StringRef ExtName; // E in /export:E=N SymbolBody *Sym = nullptr; uint16_t Ordinal

On Wed, Jun 14, 2017 at 7:37 PM, Rui Ueyama <ruiu at google.com> wrote: > On Wed, Jun 14, 2017 at 4:24 PM, Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm copying some LLD code into my codebase like this: >> >> // workaround for LLD not exposing ability to convert .def to .lib >> >> #include <set> >>

I saw this change come in yesterday: commit 572ad839e2f66eaa82ffc71b1061eb3d06a4d126 Author: Saleem Abdulrasool <compnerd at compnerd.org> Date: Thu Jun 15 20:39:58 2017 +0000 COFF: add support for lib mode usage When link is invoked with `/def:` and no input files, it behaves as if `lib.exe` was invoked. Emulate this behaviour, generating the import library from the

Dump the IR before newgvn and run through opt -newgvn. It should crash. I'm not familiar with your frontend but you might want to use -mllvm -opt-bisect-limit. On Sep 17, 2017 1:06 PM, "Andrew Kelley" <superjoe30 at gmail.com> wrote: Valgrind is strictly better than address sanitizer, is that right? It runs valgrind-clean: [nix-shell:~/dev/zig/build-llvm5-debug]$ valgrind

On 2018-09-20 10:01, Hans Wennborg via llvm-dev wrote: > Yes, it's a manual process. The binaries are build and tested by > volunteers, and the set of folks who volunteers differs a little > between releases. I would assume LLVM has some kind of CI infrastructure. That should be able to build the release binaries. > The pre-built binaries are really mostly for users who want to

Hi, The 7.0.1-rc2 release has been tagged and is ready for testing. I forgot to bump the version number to 7.0.1 before I tagged -rc1, which is why we are now on -rc2. Remember, you can continue to submit merge requests up until Nov, 21, so keep testing and submitting fixes. Thanks, Tom

It appears that there was an out-of-band patch from Samuel Thibault: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/blob/7/debian/patches/D54378-hurd-triple.diff Although the patch was approved here https://reviews.llvm.org/D54378 Is this patch going to land in 7.0.1 or 8? kristopher > Here's further proof: > > wget >