similar to: [LLVMdev] Strange i386 cross build error.

> ecc: note: diagnostic msg: /tmp/ARMAsmBackend-265222.cpp > ecc: note: diagnostic msg: /tmp/ARMAsmBackend-265222.sh > ecc: note: diagnostic msg: > > ******************** > The error only occurs for i386. Any ideas? Open a bug report with ARMAsmBackend-265222.cpp and ARMAsmBackend-265222.sh? Cheers, Rafael

I saw this; http://bb.pgr.jp/builders/clang-3stage-cygwin Not sure, though, r195406 triggered this issue. I am still investigating. I guess it could be reproducible with -target i686-* on other hosts. 2013/11/25 Rafael Espíndola <rafael.espindola at gmail.com>: >> ecc: note: diagnostic msg: /tmp/ARMAsmBackend-265222.cpp >> ecc: note: diagnostic msg:

Hi Jim, The diff below is not intended to be a patch, but a starting point. It is the shortest path (I hope) to getting LLVM to emit ARM mapping symbols to the ELF without changing any shared interfaces. Could you have a look at the FIXME comments and offer some pointers on how to get this code out of MCELFStreamer? Thanks, Greg diff --git a/lib/MC/MCELFStreamer.cpp b/lib/MC/MCELFStreamer.cpp

Geting a seg fault. Have not investigted the cause. rkotler at mipsswbrd002:~/richard$ tar vfxz ~/Downloads/ellcc-mips-linux-2014-Mar-24-07-32-26.tgz rkotler at mipsswbrd002:~/richard/ellcc/bin$ gdb ./ecc GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are

> I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. > > What motivated this? Well this: > http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM > > I believe one of the reason the benchmark numbers are totally bogus is that the compilation are done on ARM hosts.

On 11/05/12 04:56, 陳韋任 wrote: >> I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. >> >> What motivated this? Well this: >> http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM >> >> I believe one of the reason the benchmark numbers are totally

The clang/LLVM based ELLCC project (http://ellcc.org), after having reached a huge milestone ( http://ellcc.org/blog/?p=231) has now successfully compiled itself. The steps were: 1. Use gcc to build the compiler with Linux standard libraries. 2. Use ecc to build itself with libc++, libc++ABI, libunwind, musl, and compiler-rt 3. Use the newly built compiler to build itself again. One

On May 11, 2012, at 12:25 AM, James Molloy wrote: > On 11/05/12 04:56, 陳韋任 wrote: >>> I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. >>> >>> What motivated this? Well this: >>> http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM

[~/ellcc/test/source] main% cat printf.c #include <stdio.h> int main(int argc, char** argv) { printf("printf with the string \"%s\"\n", "my string"); } [~/ellcc/test/source] main% ~/ellcc/ellcc/x86-elf-ecc printf.c [~/ellcc/test/source] main% ./a.out printf with the string "my string" [~/ellcc/test/source] main% size a.out text data bss

Thanks for the example, that is very useful in working out the overall scope of the problem, which is now wider than I thought it was. I've put some comments inline. On 15 March 2018 at 19:12, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 3/15/2018 9:43 AM, Peter Smith via llvm-dev wrote: >> >> Hello everyone, this is most likely Arm specific, but could affect

On 16 March 2018 at 10:38, Peter Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 15 March 2018 at 19:12, Friedman, Eli <efriedma at codeaurora.org> wrote: >> Having ARMv7a instructions in an ARMv4t file shouldn't be a problem: a >> function should be allowed to override the CPU attributes to generate code >> for a newer target. This is generally

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same

With all the talk about using lld on the list, I thought it would be interesting to try using it in my clang based ELLCC cross compilation tool chain. http://ellcc.org The change was simple, since I use configuration files to tell clang how to compile, where to find libraries, etc. I described the config files here: http://ellcc.org/blog/?p=13246 All I had to do was change the linker

On Fri, Oct 28, 2016 at 2:56 PM, Richard Pennington via cfe-dev < cfe-dev at lists.llvm.org> wrote: > With all the talk about using lld on the list, I thought it would be > interesting to try using it in my clang based ELLCC cross compilation tool > chain. http://ellcc.org > > The change was simple, since I use configuration files to tell clang how > to compile, where to

Eli Friedman wrote: > I haven't looked at the rest of the email carefully, but why aren't > you just implementing MULHU and MULHS? There's no point to > implementing the *MUL_LOHI variants if the processor doesn't have > them. I have implemented MULHU and MULHS. But if I take out my *MUL_LOHI stuff, the error I get is [~/ellcc/ellcc] main% ./nios2-elf-ecc -S test.c

LLVM Weekly - #39, Sep 29th 2014 ================================ If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/39>. Welcome to the thirty-ninth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex Bradbury](http://asbradbury.org).

Richard Pennington wrote: > Eli Friedman wrote: > >> I haven't looked at the rest of the email carefully, but why aren't >> you just implementing MULHU and MULHS? There's no point to >> implementing the *MUL_LOHI variants if the processor doesn't have >> them. >> > > I have implemented MULHU and MULHS. But if I take out my

Hi all, I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. What motivated this? Well this: http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM I believe one of the reason the benchmark numbers are totally bogus is that the compilation are done on ARM hosts. Given the benchmarks are

On 3/15/2018 9:43 AM, Peter Smith via llvm-dev wrote: > Hello everyone, this is most likely Arm specific, but could affect > other targets where there is a somewhat complex relationship between > the triple and mcpu option. > > At present when clang is used as a linker driver for the gold-plugin > and when using and an explicit -mcpu is not given to clang, then clang > will

Hello everyone, this is most likely Arm specific, but could affect other targets where there is a somewhat complex relationship between the triple and mcpu option. At present when clang is used as a linker driver for the gold-plugin and when using and an explicit -mcpu is not given to clang, then clang will always generate a -Wl,-plugin-opt=mcpu=<default CPU> where the default CPU is based