similar to: [LLVMdev] llvm-link failing depending on order of files

Ah! Okay. A quick test of llvm-lto gets an error: llvm-lto: error adding file 'main.bc': Linking COMDATs named '??_7_Iostream_error_category at std@@6B@': invalid selection kinds! Would it be the case that llvm-lto is also deprecated in favor of the gold plugin? On Tue, Feb 10, 2015 at 4:47 PM, Teresa Johnson <tejohnson at google.com> wrote: > LTOCodeGenerator is used

Following on from my last question, based on such information as I've been able to find on Google, I get the impression llvm-link is effectively deprecated / not actively maintained, because the focus of whole-program optimization is now on the gold plugin. Is that the case, or am I missing something? Running searches over the source tree, it seems the Linker class that actually implements

When I use clang on Windows to compile a program using regular expressions to intermediate code, then run the result through llvm-link and finally try to generate an executable, I get an error. All of these ingredients are necessary; it works if the program doesn't use regular expressions, and it works if I compile it directly instead of going via intermediate code. The use of the exact

This code: int main(int argc, char **argv) { puts("abc"); return 0; } compiles to this: @"\01??_C at _03FIKCJHKP@abc?$AA@" = linkonce_odr unnamed_addr constant [4 x i8] c"abc\00", comdat, align 1 ; Function Attrs: nounwind uwtable define i32 @main(i32 %argc, i8** nocapture readnone %argv) #0 { %1 = tail call i32 @puts(i8* getelementptr inbounds ([4 x i8], [4

Hello Lang, Good work! That was very quick ;-) > I will file a bug tomorrow to add COMDAT support to ORC. I won't have time to work on this feature any time soon, but I will try to provide a sketch of the solution in the bug report in case you or anyone else is interested in taking up the challenge. :) => I suspect this could be an issue that could get in my way more significantly

Yeah, seems to. a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv U _ZN4llvm4outsEv U _ZN4llvm4outsEv 0000000000000000 b _ZGVZN4llvm4outsEvE1S 0000000000000000 T _ZN4llvm4outsEv 0000000000000000 r _ZZN4llvm4outsEvE19__PRETTY_FUNCTION__ 0000000000000000 b _ZZN4llvm4outsEvE1S U _ZN4llvm4outsEv I can try building

Looking again at your link line, I think static library has to appear after their uses. So try to put the .o before the list of library. -- Mehdi > On Mar 25, 2016, at 12:41 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > > Yeah, seems to. > > a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv > U

Hi Emmanuel, Thank you very much for these! I will check them out today and see what's going on. Regards, Lang. On Mon, Apr 27, 2020 at 8:35 PM Emmanuel Roche <roche.emmanuel at gmail.com> wrote: > Hi Lang, > > Thank you for your feedback on the blog post, please find below some > additional inputs from my side on the comments you provided: > > > Regarding

Generally it is safer to include ISO headers first (using the ‘#include <...>’ form) so as to minimise the possibility that a later user declaration or macro definition interferes with the correctness of the Standard libraries. It also tends to make pre-compiled header implementations faster and more shareable across a larger set of files. I would like to suggest revising the LLVM

Tried that just now, same result. On Fri, Mar 25, 2016 at 6:58 AM, Snehasish Kumar <kumar.snehasish at gmail.com> wrote: > Hi Russel, > > Can you try compiling aklo.o using -fno-rtti prior to linking? > > On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I'm trying to link a program with LLVM on Linux.

According to the LLVM coding standards, Immediately after the header file comment <http://llvm.org/docs/CodingStandards.html#header-file-comment> (and include guards if working on a header file), the minimal list of #includes <http://llvm.org/docs/CodingStandards.html#minimal-list-of-includes>required by the file should be listed. We prefer these #includes to be listed in this order:

> On Apr 7, 2016, at 11:59 AM, Xinliang David Li <davidxl at google.com> wrote: > > > > On Thu, Apr 7, 2016 at 11:26 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Apr 7, 2016, at 10:58 AM, Xinliang David Li <davidxl at google.com <mailto:davidxl at google.com>> wrote: >> >>

> On Apr 7, 2016, at 12:39 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > > On Thu, Apr 7, 2016 at 12:29 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Apr 7, 2016, at 11:59 AM, Xinliang David Li <davidxl at google.com <mailto:davidxl at google.com>> wrote: >> >> >>

Since the log tells you that llvm::outs() is not found, and since it is supposed to be found in libLLVMSupport.a, you can try: $ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv ... 0000000000002070 T __ZN4llvm4outsEv ... The output should have the symbol defined. -- Mehdi > On Mar 25, 2016, at 12:18 AM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote:

> On Apr 7, 2016, at 10:58 AM, Xinliang David Li <davidxl at google.com> wrote: > > > > On Wed, Apr 6, 2016 at 9:53 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Apr 6, 2016, at 9:40 PM, Teresa Johnson <tejohnson at google.com <mailto:tejohnson at google.com>> wrote: >> >> >>

We just recently upgraded from Asterisk 1.2 to 1.4, and quickly noticed a change in the behaviour of the queues--a change that we cannot live with. We've used AddQueueMember/RemoveQueueMember to manage logging into and out of our queues for over a year now with Asterisk 1.2, and in that version the queue members were sorted in such a way that the person who had been logged in the longest

Looks like it is also not working on x86_64, using clang/lld I am seeing a segmentation fault: Dump of assembler code for function _Z4funcj: 0x0000000000400590 <+0>: push %rbp 0x0000000000400591 <+1>: push %rbx 0x0000000000400592 <+2>: push %rax 0x0000000000400593 <+3>: mov %edi,%ebp 0x0000000000400595 <+5>: pop %rdx 0x0000000000400596

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

On Fri, Oct 19, 2012 at 2:55 AM, r4start <r4start at gmail.com> wrote: > Hi all. > > While compiling next code > @A = weak unnamed_addr constant { i32, i32, i32 } { i32 0, i32 0, i32 0 }, > section ".data" > was discovered that llc ignores weak linkage if we emit it in COFF object. > Attached patch solves this problem, please review. > > I found some

On Nov 9, 2011, at 11:34 AM, Rafael Espíndola wrote: >>> 1) [Requires ABI change] We emit dynamic initialization code for weak globals >>> (even in TUs where static initialization is required to be performed), unless >>> we can prove that every translation unit will use static initialization. We >>> emit the global plus its guard variable as a single object so