search for: e12fff1

...0: e92d4800 push {fp, lr} 4: e1a0b00d mov fp, sp 8: e24dd008 sub sp, sp, #8 c: ebfffffe bl 0 <foo> 10: e58d0004 str r0, [sp, #4] 14: e1a0d00b mov sp, fp 18: e8bd4800 pop {fp, lr} 1c: e12fff1e bx lr As you can see, no inlining took place, so there is still a reference to foo(). However, no definition for foo() is actually present. If I instead define foo as "static __inline", then the definition of foo() is retained: 00000000 <bar>: 0: e92d4800...

...8b88: e92d4800 push {fp, lr} 8b8c: e1a0b00d mov fp, sp 8b90: e24dd008 sub sp, sp, #8 8b94: e58d0004 str r0, [sp, #4] 8b98: e59d0004 ldr r0, [sp, #4] 8b9c: ebffdd17 bl 0 <__preinit_array_end> 8ba0: e1a0d00b mov sp, fp 8ba4: e8bd4800 pop {fp, lr} 8ba8: e12fff1e bx lr where the bl 0 causes a seg fault. I'll check x86_64, but currently don't have that setup, so it'll take me a little bit of time to check. -----Original Message----- From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] Sent: Friday, May 30, 2014 2:05 PM To: Daniel S...

I noticed that LLD doesn’t preserve the symbol type for a defsym directive. For example: $ cat f.c void f() {} $ clang -c f.c $ ld.lld -shared --defsym=g=f f.o $ objdump -T a.out DYNAMIC SYMBOL TABLE: 00000000000012a0 g DF .text 0000000000000006 f 00000000000012a0 g D .text 0000000000000000 g f is marked as a function symbol, but g is not. I recognize this is hard to do in the general

As reported in an earlier thread (http://clang-developers.42468.n3.nabble.com/Disable-memset-synthesis-tp4057810.html), we noticed in some cases that the llvm.memset intrinsic, if lowered to stores, could help with performance. Here's a test case: If LIMIT is > 8, I see that a call to memset is emitted for arm & aarch64, but not for x86 target. typedef struct { int v0[100]; }

...;main' block 0 offset 0 size 8 block 0 offset 0 size 8 JITTing function 'main' JIT: Starting CodeGen of Function main JIT: Emitting BB0 at [0x4512e010] JIT: 0x4512e010: %R0<def> = MOVi 30, 14, %reg0, %reg0 0xe3a0001e JIT: 0x4512e014: BX_RET 14, %reg0, %R0<imp-use,kill> 0xe12fff1e JIT: Finished CodeGen of [0x4512e010] Function: main: 8 bytes of text, 0 relocations JIT: Binary code: JIT: 00000000: e3a0001e e12fff1e *** I appreciate any suggestions what can I do in my situation. -- Martins Mozeiko

...;*srand*>: 1564 91d8: e3a02000 mov r2, #0 1565 91dc: e59f300c ldr r3, [pc, #12] ; 91f0 <srand+0x18> 1566 91e0: e5933000 ldr r3, [r3] 1567 91e4: e58300a8 str r0, [r3, #168] ; 0xa8 1568 91e8: e58320ac str r2, [r3, #172] ; 0xac 1569 91ec: e12fff1e bx lr As you can see, the call to *srand* is just a *bl (Branch with Link)*, not a *blx (Branch with Link and Exchange instruction set)*, so I think something is going wrong here. Indeed, when using a binary analysis tool to simulate this code, it cannot executes correctly *srand* because it...

...e58d0004 str r0, [sp, #4] > 8b98: e59d0004 ldr r0, [sp, #4] > 8b9c: ebffdd17 bl 0 <__preinit_array_end> > 8ba0: e1a0d00b mov sp, fp > 8ba4: e8bd4800 pop {fp, lr} > 8ba8: e12fff1e bx lr > > where the bl 0 causes a seg fault. > > I'll check x86_64, but currently don't have that setup, so it'll take me a little bit of time to check. > > -----Original Message----- > From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] >...

We've found an error during the use of LTO that appears to happen only during the use of the gold linker. We essentially have a file which is compiled *without* LTO: f1() { h1(); } And a second file that is compiled/linked *with* LTO: f2() { f1(); h1(); } This second file has the function h1() inlined during LTO. The resulting executable fails because the symbol for h1