similar to: [LLVMdev] how to build eglibc using llvm-gcc without unsupported -fno-toplevel-reorder

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

On 2010-02-21 23:36, Sergey Yakoushkin wrote: > Hi, Rafael > > Inlined asm markup inside functions and on the top level is used to > split asm prologue/epilogue parts in very fine-grained manner. > So, splitting source c won't give the same result. You could have 2 files: - 1 which contains the function, and a marker where prolog ends (beginning of file is implicit marker of

Hi, Rafael Inlined asm markup inside functions and on the top level is used to split asm prologue/epilogue parts in very fine-grained manner. So, splitting source c won't give the same result. Regards, Sergey Y. 2010/2/22 Rafael Espindola <espindola at google.com> I haven't looked at the code, but why can't you split the .c files > into multiple files instead of splitting

> 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

> 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, >> 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

Package: src:xcp-vncterm Version: 0.1-2 Severity: important Tags: sid jessie User: debian-glibc at lists.debian.org Usertags: ftbfs-glibc-2.17 The package fails to build in a test rebuild on at least amd64 with eglibc-2.17, but succeeds to build with eglibc-2.13. The severity of this report may be raised before the jessie release. The test rebuild was done together with GCC-4.8, so some issues

Hi Rui, Not sure if you have seen this problem, but I have been running into this problem when I run the lld tests and the failure occurence is once in 5 times. lld: ../tools/lld/lib/Core/Resolver.cpp:402: void lld::Resolver::deadStripOptimize(): Assertion `symAtom' failed. #0 0x4b05ae llvm::sys::PrintStackTrace(_IO_FILE*)

On Fri, Jun 07, 2013 at 11:48:03AM -0400, Rafael Espíndola wrote: > > It is (almost) possible to compile glibc using DragonEgg -- there > > are only a handful of patches required (for LLVM and DragonEgg), > > most of which are now up for review. > > > > It builds, and most of glibc's test suite currently passes, except > > for some tests that deal with

Hi Quentin, I’ve started running an ABI test suite with global isel on AArch64, and while it hasn’t found any ABI issues it has hit an assertion in clang when using the __fp16 type. Here’s a reproducer: __fp16 pass_f16(__fp16 p) { return p; } $ /work/llvm/build/bin/clang --target=aarch64-arm-none-eabi -march=armv8-a -c test.c -O0 -mllvm -global-isel -mllvm -global-isel-abort=0

Hi, I have cross-compiled just the basic samba 4.0.6 using bitbake recipe for ARM, which succeeded. However the resulting binaries are large in size. I used the exact same configuration options in both the cases. There is at least a 10 fold increase in the smbd compared to native x86. --- Native x86 ---- -rwxr-xr-x 1 pranavd users 92979 May 31 10:57 /usr/sbin/smbd -rwxr-xr-x 1 pranavd users

Hello Tobias, I think that looks reasonable to me, I think it will be down to the llvm-objcopy team whether they want to make .ARM.attributes a special case or not. The best way to find out is to submit a patch, citing the problems with old versions of libc, I'd expect that you'll need to add a test case for the patch to be accepted. To do that it is probably best to look at the existing

Hey all, I was wondering if clang/LLVM has support to compile glibc in its entirety? The only thing I could find of recent was this thread saying the only way it could really be done is to use the dragonegg plugin with gcc... https://groups.google.com/forum/#!topic/llvm-dev/pmZYVNTrVYQ [LLVMdev] clang/llvm with glibc 8 posts by 5 authors [X] [X] Dave Buehmann [X]

Jordan, I have sent the patch via Phabricator: https://reviews.llvm.org/D69188 Let me know if I got it right. -- Tobias On Thu, Oct 17, 2019 at 7:12 PM Jordan Rupprecht <rupprecht at google.com> wrote: > > Tobias, > I don't have much experience with ARM, but from your report and Peter's explanation of why LLD does it, I agree we should be consistent with LLD and keep the

After re-cmaking and rebuilding everything from scratch, I'm seeing failures in MCJIT. It this something known or expected? I build LLVM/clang with pre-packaged clang-3.7.0, with "-stdlib=libc++". Example failure: /w/bld/org/./bin/lli -remote-mcjit -mcjit-remote-process=/w/bld/org/./bin/lli-child-target /w/src/llvm.org/test/ExecutionEngine/MCJIT/remote/eh.ll -- Exit Code:

Thanks all. Amara, could you take a look? > On Nov 20, 2017, at 3:06 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > I’ve raised: > https://bugs.llvm.org/show_bug.cgi?id=35359 <https://bugs.llvm.org/show_bug.cgi?id=35359> > https://bugs.llvm.org/show_bug.cgi?id=35360 <https://bugs.llvm.org/show_bug.cgi?id=35360> >

Hi Lang, I am on Ubuntu 14.04. I am building ToT: llvm, clang, polly, lld, compiler-rt, libcxx, libcxxabi. The build compiler is: clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04 The failures show up during "make check-all". My cmake command was: cmake -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/w/c/org -DLLVM_TARGETS_TO_BUILD:STRING=all

Processing commands for control at bugs.debian.org: > tags 653294 + jessie Bug #653294 [hellanzb] hellanzb: doesn't work with python-twisted 11.1.0-1 (patch included) Added tag(s) jessie. > tags 701439 + jessie Bug #701439 [src:ircd-hybrid] ircd-hybrid: ftbfs with eglibc-2.17 Added tag(s) jessie. > tags 616910 + jessie Bug #616910 [src:musiclibrarian] musiclibrarian: deprecation of

Hi, I was trying to create a new *Store* instruction and inserting it to LLVM IR (.ll) file. I found the following constructor in LLVM Manual: StoreInst::StoreInst <http://llvm.org/docs/doxygen/html/classllvm_1_1StoreInst.html#aa2a72f9a51b317f5b4ab8695adf59025> (Value <http://llvm.org/docs/doxygen/html/classllvm_1_1Value.html> * Val, Value

Hi Oliver, Thanks for trying this. Could you file a different PR for each of the problem you found and reference the umbrella PR: http://llvm.org/PR35347? <http://llvm.org/PR35347?> Thanks, -Quentin > On Nov 17, 2017, at 8:17 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > One more reproducer, this time with small (<64bit) values