similar to: Symbols in 'llvm.used' stripped by --gc-sections

It is expected and not unusual to need to update the lit test in such case. I'd need to see exactly which test breaks and how to know though. Best, -- Mehdi 2017-09-18 13:17 GMT-07:00 Johan Engelen <jbc.engelen at gmail.com>: > The fix (https://reviews.llvm.org/D37961) does not work. From what I > have learned thusfar, the module identifier is used as filename sometimes >

I've created a review for your patch Mehdi: https://reviews.llvm.org/D37961 First time using `arc`, so hope things went well. - Johan On Tue, Sep 12, 2017 at 5:25 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > Hi Johan, > > 2017-09-11 14:21 GMT-07:00 Johan Engelen <jbc.engelen at gmail.com>: > >> On Fri, Sep 8, 2017 at 9:04 PM, Johan Engelen

With `save-temps` as plugin option, I get extra files for the MAIN module (called `a.o`): `a.o.opt.bc` and `a.thinlto.bc`. The `a.thinlto.bc` file contains nothing, only `source_filename = ...` . The `a.o.opt.bc` (this looks like the result after ThinLTO importing and optimization) contains the assembly block that it should not have: ``` module asm "\09.text" module asm

The fix (https://reviews.llvm.org/D37961) does not work. From what I have learned thusfar, the module identifier is used as filename sometimes (I think when writing an intermediate module index summary), and so a bunch of lit tests fail with the "fix". I'll look further into fixing this, any help is appreciated. ( One thing that may be important is to have a deterministic suffix.

The plugin version (and LLVM) are LLVM 3.9.0 (the release source tarball). I've attached the source files and the temporary files generated. `a.o` is the "MAIN" module. `b.o` is the "ASM" module. The error I get is: /usr/bin/ld: error: a.o.thinlto.o: multiple definition of 'foo' /usr/bin/ld: b.o.thinlto.o: previous definition here (the files depend on D runtime

On Thu, Oct 31, 2019 at 3:46 AM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > On Wed, Oct 30, 2019 at 4:17 PM Johan Engelen <jbc.engelen at gmail.com> > wrote: > >> Hi all, >> Since 2724d9e12960cc1d93eeabbfc9aa1bffffa041cc, llvm-config -cxxflags >> no longer reports the C++ language standard version (e.g. "-std=c++14") >> used to

On Mon, Dec 21, 2015 at 12:08 AM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Sun, Dec 20, 2015 at 5:57 PM, Johan Engelen <jbc.engelen at gmail.com> > wrote: > > > > Perhaps LLVM_ATTRIBUTE_ALWAYS_INLINE could be defined to "inline" if the > > compiler has no support for always_inline (currently it is set to > nothing in > > that

On Thu, Aug 3, 2017 at 6:19 PM, Tim Northover <t.p.northover at gmail.com> wrote: > 2017-08-03 8:58 GMT-07:00 Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org>: > > The error is gone after removing (or reducing) the alignment of `%a`. > This > > makes me believe that our inline asm syntax is correct to add an offset > to a > > pointer: "

On Fri, Sep 8, 2017 at 9:04 PM, Johan Engelen <jbc.engelen at gmail.com> wrote: > > On Thu, Sep 7, 2017 at 5:44 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > >> Hi Johan, >> >> ld64 only calls functions from llvm/include/llvm-c/lto.h (defined >> in llvm/tools/lto/lto.cpp) >> >> For instance ThinLTOCodeGenerator::addModule is called

Is there any eta for when viewvc will be back? I prefer to use viewvc because all of the commit emails have the SVN commit number, but not the corresponding git hashes, so it makes it easier to look it up. Or is there some easy way to map an svn commit number to the corresponding git hash? Douglas Yung From: Johan Engelen [mailto:jbc.engelen at gmail.com] Sent: Saturday, March 12, 2016 5:03 AM

On Mon, Oct 3, 2016 at 4:27 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > On Mon, Oct 3, 2016 at 6:53 AM, Johan Engelen via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> I am trying to add ThinLTO to the LDC compiler. It seems to work well >> on Mac (XCode 8) and Ubuntu (ld.gold + LLVMgold plugin). >> However, I am

It's currently disabled until the issues with llvm.org load would be resolved. Use klaus instead. On Sat, Feb 27, 2016 at 6:53 AM, Yung, Douglas via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I’ve noticed since about Thursday that llvm.org/viewvc seems to be only > returning 404 error when trying to access it. Is this service going away? > > >

Hi all, I stumbled upon either a bug, or we are emitting wrong inline asm code. The testcase is: ``` source_filename = "testcase.d" target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-apple-macosx" define void @_D7asanasm3fooFZv() { %a = alloca [4 x i32], align 32 call void asm sideeffect "movl %ebx, 4+$0",

On Sat, Jun 11, 2016 at 7:57 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 06/11/2016 07:52 PM, Johan Engelen via llvm-dev wrote: > > On Fri, Jun 10, 2016 at 9:00 PM, Sylvestre Ledru via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > http://llvm-apt.ecranbleu.org/apt/ > > > >

Hi all, Since 2724d9e12960cc1d93eeabbfc9aa1bffffa041cc, llvm-config -cxxflags no longer reports the C++ language standard version (e.g. "-std=c++14") used to compile LLVM. This may break builds of projects that build with the same flags as LLVM, e.g. the LDC compiler. Quoting from llvm/tools/llvm-config/CMakeLists.txt: ``` # The language standard potentially affects the ABI/API of

Hi all, I just found an optimization regression regarding simple dataflow/constprop analysis: https://godbolt.org/g/Uz8P7t This code ``` int dataflow(int b) { int a; if (b==4) a = 3*b; // fully optimized when changed to a = 3; else a = 5; if (a == 4) return 0; else return 1; } ``` is no longer optimized to just a "return 1". The regression happened in LLVM

We should handle this a lot better after r34763 ~Craig On Mon, Nov 26, 2018 at 3:13 PM Craig Topper <craig.topper at gmail.com> wrote: > Here's a quick patch that fixes this. I don't know to avoid it in IR. I > haven't checked any other tests, but it does fix your case. I'll try to put > up a real phabricator tonight or tomorrow. > > diff --git

On Mon, Jun 20, 2016 at 10:01 AM, Anton Korobeynikov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > P.S.: On a similar note, are there any news regarding llvm.org/apt? > We are working on it. Note, however, that it seems that the majority > of bogus load seemed to come from CI systems, which pulled apt repo > for every and each downstream commit without any caching /

Hi all, I am working on adding PGO to LDC (LLVM D Compiler). The current implementation 1) uses LLVM's InstrProf pass to generate an instrumented executable 2) links to compiler-rt/lib/profile for the runtime functionality to write a raw profile data file 3) uses llvm-profdata to merge profile data and convert from profraw to profdata format 4) uses llvm::IndexedInstrProfReader to read-in

Hi all, Will libFuzzer be part of the release pre-built binaries at http://releases.llvm.org/ in the future? Thanks, Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170721/91c6cffe/attachment.html>