similar to: [LLVMdev] Assertion failure in MC emitter running LLVM libs on Android using android-ndk

Hi, >> Are there any reasons why option can't be supported by llvm? > It is hard and has very few users. For this to work you would have to > add ordering information to the LLVM IL. It looks easier to patch > eglibc. I agree, impact of issue is limited. But it prevents out of the box compilation of libraries for some targets. Also, looks like glibc and eglibc maintainers do

> I agree, impact of issue is limited. But it prevents out of the box > compilation of libraries for some targets. > Also, looks like glibc and eglibc maintainers do not welcome patches > for llvm (yet). I would be very surprised if glibc ever does. I don't have any experience with eglibc. > In general, saving order of appearance doesn't seem to be bad thing. > Are

> Hi Sachin, > > The declaration of functions called via the "call" instruction is a > GlobalValue in your Module. You can go through all of the > GlobalValues, look for those that are Function declarations (use the > "Function::isDeclaration()" method), and then placing them in the > appropriate place in your assembly file. > > Would that work? Hi

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

Hola LLVMers, I'm debugging through some strangeness that I'm seeing on X64 on windows with LLVM2.2. I had to change the code so that it would engage the x64 target machine on windows builds, but I've otherwise left LLVM 2.2 alone. The basic idea is that I've got a function bar which is compiled by VStudio and I'm creating another function foo via LLVM JIT which is going

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

> Are there any reasons why option can't be supported by llvm? It is hard and has very few users. For this to work you would have to add ordering information to the LLVM IL. It looks easier to patch eglibc. > Regards, > Sergey Yakoushkin Cheers, -- Rafael Ávila de Espíndola

Hi, llvm doesn't support -fno-toplevel-reorder option which affects glibc/eglibc for some targets. http://www.llvm.org/bugs/show_bug.cgi?id=6364 >From conversations with gcc and eglibc maintainers, seems option is highly expected and is not going to deprecate. >> 2010/2/23 Ian Lance Taylor <iant at google.com>: >> If option is going to deprecate in gcc in near future as

Hi all, Does anyone compiled asterisk using NKD build in android. Please give some suggestions. Thanks Nikhil

Hi all, I can't get CELT to compile with the latest version of the Android NDK. It seems that the compiler (GNU) is rejecting any variable that starts with an underscore and then a capital letter (e.g. "_C"). I know that according to the C++ standard these are "Reserved Names" and must not be used in user code, but the Android compiler seems to be applying this

Hi LLVM Android NDK developers, I was curious how clang was built for this release, but didn't find the llvm-setup executable in the NDK. Can you share how your build was configured here? And I see the Chromium build distributes a separate version of clang that looks to be somewhere beyond the 3.2 release. Has there been any talk of both Android and Chromium sharing the same clang? Or is

Hi flac-dev, When we try to build libFLAC v1.3.1 using the Android NDK, we currently are getting an error in a couple files: ../../third_party/flac/src/libFLAC/md5.c:498:25: error: use of undeclared > identifier 'SIZE_MAX' > if ((size_t)channels > SIZE_MAX / (size_t)bytes_per_sample) > I filed a bug for it on the sourceforge bug tracker:

Hey, I am trying to build a haskell cross compiler to android by building the glasgow haskell compiler with target=arm-linux-androideabi. It builds, but the executables the compiler produces segfaults on my android device. This is probably not llvm related, but I want to rule that out. I used the llvm version shipped with ubuntu 12.10 for the build. I was wondering if maybe I have to use llvm

cc +andrewhsieh +loganchien On Tue, Nov 13, 2012 at 11:21 PM, Joe Abbey <jabbey at arxan.com> wrote: > Hats off to the Android NDK team! > > Thanks for including me here, but I'd like to clarify that this is all from the really hard work of Andrew Hsieh and Logan Chien, and a few other Android engineers. (I'm actually not working on Android anymore, Andrew and Logan have

Yes, llvm-config. Thanks for the pointer to the build script - that's what I was looking for. -Greg On Thu, Jan 31, 2013 at 5:24 PM, Andrew Hsieh <andrewhsieh at google.com>wrote: > You mean llvm-config? It was deleted after the build. You can modify our > build script build-llvm.sh to get it back. > Clang/llvm-3.2 will be available in the next NDK release. There is no

Hats off to the Android NDK team! http://developer.android.com/tools/sdk/ndk/index.html Important changes: * Added the Clang 3.1 compiler to the NDK. The GNU Compiler Collection (GCC) 4.6 is still the default, so you must explicitly enable the Clang compiler option as follows: * For ndk-build, export NDK_TOOLCHAIN_VERSION=clang3.1 or add this environment variable setting

Hi Xiph.org Team. We are using opusfile library <https://github.com/xiph/opusfile> for streaming *.opus* audio in our projects. But now we have a problem with building opusfile library for android with *ndk-build*. In particular, with arm64-v8a platform: Google removed <sys/timeb.h> from android. And now building opusfile with nkd-build crashes with error "fatal error:

This patch is still not creating elf32_x86_64 objects. No idea why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 hosts which is nice. :) --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6

Hi Sachin, The declaration of functions called via the "call" instruction is a GlobalValue in your Module. You can go through all of the GlobalValues, look for those that are Function declarations (use the "Function::isDeclaration()" method), and then placing them in the appropriate place in your assembly file. Would that work? -bw On Jan 28, 2009, at 12:23 AM,

On Oct 16, 2008, at 11:29 AM, Nuno Lopes wrote: >> + /// allocateSpace - reserves space in the current block if any, or >> + /// allocate a new one of the given size + virtual void >> *allocateSpace(intptr_t Size, unsigned Alignment); + >> Please capitalize "reserves". > > ok. > > >> + /// allocateSpace - general-purpose space allocator >>