similar to: [LLVMdev] gcc-4.8.1 -flto, error for visibility of LLVMX86CompilationCallback2?

Thanks, now it links. If nobody objects, I will commit the following patch: diff --git a/lib/Target/X86/X86JITInfo.cpp b/lib/Target/X86/X86JITInfo.cpp index 44d8cce..8acc220 100644 --- a/lib/Target/X86/X86JITInfo.cpp +++ b/lib/Target/X86/X86JITInfo.cpp @@ -339,6 +339,8 @@ extern "C" { /// must locate the start of the stub or call site and pass it into the JIT /// compiler function.

Hi Patrik, On 12/06/13 09:48, Patrik Hägglund H wrote: > Thanks, now it links. > > If nobody objects, I will commit the following patch: > > diff --git a/lib/Target/X86/X86JITInfo.cpp b/lib/Target/X86/X86JITInfo.cpp > index 44d8cce..8acc220 100644 > --- a/lib/Target/X86/X86JITInfo.cpp > +++ b/lib/Target/X86/X86JITInfo.cpp > @@ -339,6 +339,8 @@ extern "C" {

Hello, Could I please ask you for help? I opened a case in GCC Bugzilla and got reply that -fpie have to be used to get it compiled. Now it fails for me with: x86_64-pc-linux-gnu-gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2

Am 31.05.2017 um 15:24 schrieb Timo Sirainen: > https://dovecot.org/releases/2.2/dovecot-2.2.30.1.tar.gz > https://dovecot.org/releases/2.2/dovecot-2.2.30.1.tar.gz.sig > > Due to some release process changes I didn't notice that one important bugfix wasn't included in the v2.2.30 release branch before I made the release. So fixing it here with v2.2.30.1. Also included another

I tried to build LLVM with 'gcc-4.8.1 -flto', and when linking unittest programs, I got the following error: /tmp/cc8pMk84.ltrans30.ltrans.o:(.data.rel.ro._ZTIN4llvm2cl15OptionValueCopyISsEE[_ZTIN4llvm2cl15OptionValueCopyISsEE]+0x10): undefined reference to `typeinfo for llvm::cl::GenericOptionValue'

Am 31.05.2017 um 16:35 schrieb Timo Sirainen: > On 31 May 2017, at 16.53, Reindl Harald <h.reindl at thelounge.net > <mailto:h.reindl at thelounge.net>> wrote: >> >> LTO build is as broken as 2.2.30 >> >> libtool: link: ( cd ".libs" && rm -f "lib10_quota_plugin.la" && ln -s >> "../lib10_quota_plugin.la"

(+Chris, since I assume he wrote this policy - and, as I said in my previous email, I wouldn't mind seeing some justification or just seeing the rule go away & drop the anchors I added previously (or, if we're going to keep it, we could add more anchors & actually get to the point where we're -Wweak-vtable clean & enable that warning)) On Wed, Jun 12, 2013 at 1:44 PM,

When trying to compile R on Windows 10 64-bit using LTO as I always do, I encountered a segmentation fault early in the compilation. I am uncertain as to what it means (please see below for error extract). I am using the most recent version of Rtools43 (5863) and updated its libraries prior to starting the build. My EOPTS is " -march=native -pipe -mno-rtm" and my

https://dovecot.org/releases/2.2/dovecot-2.2.30.1.tar.gz https://dovecot.org/releases/2.2/dovecot-2.2.30.1.tar.gz.sig Due to some release process changes I didn't notice that one important bugfix wasn't included in the v2.2.30 release branch before I made the release. So fixing it here with v2.2.30.1. Also included another less important fix. - quota_warning scripts weren't

https://dovecot.org/releases/2.2/dovecot-2.2.30.1.tar.gz https://dovecot.org/releases/2.2/dovecot-2.2.30.1.tar.gz.sig Due to some release process changes I didn't notice that one important bugfix wasn't included in the v2.2.30 release branch before I made the release. So fixing it here with v2.2.30.1. Also included another less important fix. - quota_warning scripts weren't

On 31 May 2017, at 16.53, Reindl Harald <h.reindl at thelounge.net> wrote: > > LTO build is as broken as 2.2.30 > > libtool: link: ( cd ".libs" && rm -f "lib10_quota_plugin.la" && ln -s "../lib10_quota_plugin.la" "lib10_quota_plugin.la" ) > /tmp/ccGO7JSw.ltrans4.ltrans.o:<artificial>:function

On 31 May 2017, at 18.03, Reindl Harald <h.reindl at thelounge.net> wrote: > >>> libtool: link: ( cd ".libs" && rm -f "lib10_quota_plugin.la" && ln -s "../lib10_quota_plugin.la" "lib10_quota_plugin.la" ) >>> /tmp/ccGO7JSw.ltrans4.ltrans.o:<artificial>:function imapc_quota_refresh.lto_priv.22: error: undefined

Hi all, I'm currently trying to use clang to build a largish project on Windows using MinGW. I'm currently performing all of the compilation using g++, and then linking with clang++ with lld (due to separate issues I'm having with compiling with clang with MinGW). Compiling with g++ and then linking with clang+lld seems to work fine for small programs. I'm invoking clang++

On Wed, Jul 17, 2013 at 1:06 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > > On 7/17/13 12:35 PM, Diego Novillo wrote: >> >> On Fri, Jul 12, 2013 at 3:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> >> wrote: >> >>> 3. How to parallelize post-IPO stage >>> ==================================== >>> >>> From 5k'

Hi, I am trying to add a small new backend for LLVM. For assembly printing, I have derived a class from AsmTarget, struct LLVM_LIBRARY_VISIBILITY Asd_ARMAsmPrinter : public AsmPrinter After creating all the bits and pieces, I was trying to use this to print the assembly for a sample program. Though I was getting weird errors. I tried looking for the problem and found that the my target

On Tue, 30 Jul 2019, Reid Kleckner wrote: > I think the bug is that clang won't use a response file unless it thinks the > tool it is running supports them. The MinGW linker tool doesn't claim to > support response files today. I think this would be a simple fix: > $ git diff > diff --git a/clang/lib/Driver/ToolChains/MinGW.h > b/clang/lib/Driver/ToolChains/MinGW.h >

Hi, gfortran trunk and 9-branch now have an option to automatically generate C prototypes for old-style F77 procedures. I just did for a in *.f; do gfortran -fsyntax-only -fc-prototypes-external $a > ${a%.f}.h; done in the src/modules/lapack directory. This generates header files which contain prototypes like int ilaenv_ (int *ispec, char *name, char *opts, int *n1, int *n2, int *n3,

On 7/17/13 12:35 PM, Diego Novillo wrote: > On Fri, Jul 12, 2013 at 3:49 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> 3. How to parallelize post-IPO stage >> ==================================== >> >> From 5k' high, the concept is very simple, just to >> step 1).divide the merged IR into small pieces, >> step 2).and compile

On Sat, May 04, 2019 at 06:42:47PM +0200, Thomas K?nig wrote: > > > - figure out Fortran2003 specification for C/Fortran interoperability > > -- this _sounds_ like the right solution, but I don't think many > > understand how to use it and what is implied (in particular, will > > it require making changes to LAPACK itself?) > > That would actually be fairly

Hi We knew that "clang -mllvm -debug-pass=Structure ..." can print all pass' name. But, when we use LTO , -flto flag and gold plugin. I found that the option " -debug-pass=Structure" would not pass to ld. so it would not print all the LTO pass's name. -------------- next part -------------- An HTML attachment was scrubbed... URL: