similar to: [LLVMdev] Problem with __inline keyword

So you see the issue as well in ARM? When doing a objdump -D weakMainO1.exe | grep -A 10 "<_ZN1C13caller_methodEv>:" I see: 00008b88 <_ZN1C13caller_methodEv>: 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

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

Glad to hear you can reproduce it. What I don't know is if this is a linker issue or an LLVM issue. -----Original Message----- From: Rafael Espíndola [mailto:rafael.espindola at gmail.com] Sent: Friday, May 30, 2014 3:58 PM To: Daniel Stewart Cc: LLVM Developers Mailing List Subject: Re: Error with Gold Linker during LTO Sorry, I had understood that the linker was crashing, not the

Hi. I am trying to run LLVM with JIT on ARM processor (Android phone). Currently I have problems using external functions. Any call to external function crashes and gives me signal 11 (SIGSEGV) at some random address. I'm trying to run following C code: *** extern void add1(int* x); int main() { int a = 10; int b = 20; add1(&b); int c = a + b; return c; } *** It gives

1. I would like to know why there is a difference in function prologue generated for same function with clang and gcc. Compiler options used for gcc were as follows: arm-linux-gnueabi-gcc all-types.c -w -march=armv7-a -mtune=cortex-a8 -mfloat-abi=softfp -mfpu=vfp -g -lm -o all-types_gcc Compiler options used for clang were as follows: /usr/local/bin/clang all-types.c -w

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]; }

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

Hi all, I am trying to cross-compile my application for ARM Cortex-M3. Here's how I'm doing it: 1, Get a pre-built GNU toolchain for ARM Cortex-M processors from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads 2, Create an object file for ARM: clang -c -target arm-none-eabi -mcpu=cortex-m3 -mthumb -O3 -g

On Wed, Jul 18, 2012 at 5:45 PM, Renato Golin <rengolin at systemcall.org> wrote: > On 18 July 2012 15:46, salvatore benedetto > <salvatore.benedetto at gmail.com> wrote: >> $ clang++ -ccc-host-triple thumbv7m-none-gnueabi noInclude.cpp -c >> --sysroot=/home/emitrax/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/ > > Try -ccc-gcc-name

On 18 July 2012 15:46, salvatore benedetto <salvatore.benedetto at gmail.com> wrote: > $ clang++ -ccc-host-triple thumbv7m-none-gnueabi noInclude.cpp -c > --sysroot=/home/emitrax/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/ Try -ccc-gcc-name arm-none-linux-gnueabi-g++ -ccc-host-triple thumbv7m-none-linux-gnueabi Sometimes it's better than sysroot, as it finds it

Hello > I know there are some weird semantics among different compilers with > the inline/__inline keywords in C when you don't pair them with > static, but I can't imagine that this is correct. Is there a bug > here, or am I missing something? Yes, clang is correct here, you're missing C99 inline semantics. You can either read C99 standard or

On Wed, Jul 18, 2012 at 6:08 PM, salvatore benedetto <salvatore.benedetto at gmail.com> wrote: > On Wed, Jul 18, 2012 at 5:45 PM, Renato Golin <rengolin at systemcall.org> wrote: >> On 18 July 2012 15:46, salvatore benedetto >> <salvatore.benedetto at gmail.com> wrote: >>> $ clang++ -ccc-host-triple thumbv7m-none-gnueabi noInclude.cpp -c >>>

On Tue, 2018-06-05 at 10:05 -0700, Nick Desaulniers wrote: > Functions marked extern inline do not emit an externally visible > function when the gnu89 C standard is used. Some KBUILD Makefiles > overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without > an explicit C standard specified, the default is gnu11. Since c99, the > semantics of extern inline have changed

On Tue, 2018-06-05 at 10:05 -0700, Nick Desaulniers wrote: > Functions marked extern inline do not emit an externally visible > function when the gnu89 C standard is used. Some KBUILD Makefiles > overwrite KBUILD_CFLAGS. This is an issue for GCC 5.1+ users as without > an explicit C standard specified, the default is gnu11. Since c99, the > semantics of extern inline have changed

Actually, it looks like this is already done in Speex as of revision 7150 in SVN (7/15/2004). As long as HAVE_CONFIG_H is defined in the project settings (which it is in all of the project files in SVN), win32\config.h should be included, and this has #define inline __inline in it. Oleg - you should make sure HAVE_CONFIG_H is defined in your project settings. And, you didn't say which

On Wed, Oct 31, 2018 at 10:20:00PM -0700, Joe Perches wrote: > On Wed, 2018-10-31 at 13:55 +0100, Peter Zijlstra wrote: > > > > Anyway, with the below patch, I get: > > > > text data bss dec hex filename > > 17385183 5064780 1953892 24403855 1745f8f defconfig-build/vmlinux > > 17385678 5064780 1953892 24404350

On Wed, Oct 31, 2018 at 10:20:00PM -0700, Joe Perches wrote: > On Wed, 2018-10-31 at 13:55 +0100, Peter Zijlstra wrote: > > > > Anyway, with the below patch, I get: > > > > text data bss dec hex filename > > 17385183 5064780 1953892 24403855 1745f8f defconfig-build/vmlinux > > 17385678 5064780 1953892 24404350

Hi all, I've been struggling for several weeks to get Microsoft Visual Studio 2005 to build FLAC. MinGW worked fine, but the resulting binary didn't support Cyrillic or Greek characters, so I thought MSVC might cut it. Anyway, I'm not a very good programmer, but I got it working. Probably it's of use to tell what I did 1) Compile ogg and get the library and include tree in the

List, I am working on having clang parse a recent windows.h header. I am encountering great success, however I have one problem with inlined functions. In winnt.h, there are a series of definitions for Int64ShllMod32 and related functions, these functions are defined as __inline. Compiling a multi file project with clang produces errors because these functions appear more than once and at link

Ben Allison wrote: > There's a more few issues for compiling on MSVC. I put together a patch. > > Here's a quick rundown: > * must use __inline keyword with static inline functions (bitmath.h) If you include "share/compath.h" you will get a inline #defined as __inline when _MSC_VER is defined. I'd prefer a single diffinition of that in one place and one place