similar to: Cross-compiling only compiler-rt libraries

Hi folks, I'm hitting the below assertion failure when compiling this small piece of C code (repro.c, attached). My command line is: bin/clang --target=aarch64-linux-gnu -c -O2 repro.c clang is built from top of trunk as of this morning. It only happens at -O2, and it doesn't happen with the default target (x86_64). I tried to reproduce using just 'llc -O2' but didn't

Thanks for notifying me. Yes, this was a recent change. Taking a look now. On Wed, Jul 20, 2016 at 1:49 PM, Michael Kuperstein <mkuper at google.com> wrote: > +Sanjay, who touched this last. :-) > > On Wed, Jul 20, 2016 at 12:44 PM, Ismail Badawi (ibadawi) via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi folks, >> >> I'm hitting the

Sanjay: let me know if this is something that will apply to 3.9. Thanks, Hans On Wed, Jul 20, 2016 at 5:59 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Quick update - the bug existed before I refactored that chunk in > InstSimplify with: > https://reviews.llvm.org/rL275911 > > In fact, as discussed in https://reviews.llvm.org/D22537 - because we have a

Sure. David, what do you think about merging this to 3.9? Sanjay: are you saying I'd just apply that diff to InstructionSimplify.cpp, not InstCombineSelect.cpp? On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: > Hi Hans - > > Yes, I think this is a good patch for 3.9 (cc'ing David Majnemer as code > owner). The functional change was

Hi Evgeniy, I just created a new buildbot that compiles and tests compiler-rt together with LLVM/Clang using the CMake build: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/0 There are a few ASan failures and I'd like to check with you which of them are real failures that we need to fix and which are just unsupported / noise. These tests are running on an ARMv7

The point here is, if you are not building for Android. You will hit this patch with cmake configuration -DCOMPILER_RT_TEST_TRIPLE=aarch64-linux-gnu + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") + test_target_arch(aarch64 "-march=aarch64") I don't see "-march=aarch64" is a valid flag on either LLVM or GCC. Should we replace this

Hi, I wonder if this is a valid flag in either clang/gcc. The flag in question is "-march=aarch64". I verified with latest tip and neither clang nor gcc fail to recognize this flag. This piece of code is in cmake/config-ix.cmake in compiler-rt repo. + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") + test_target_arch(aarch64

On 16 December 2014 at 21:12, Gundapaneni, Sumanth <sgundapa at quicinc.com> wrote: > The point here is, if you are not building for Android. > You will hit this patch with cmake configuration -DCOMPILER_RT_TEST_TRIPLE=aarch64-linux-gnu > > + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") > + test_target_arch(aarch64

David, Sanjay: ping? On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org> wrote: > Sure. David, what do you think about merging this to 3.9? > > Sanjay: are you saying I'd just apply that diff to > InstructionSimplify.cpp, not InstCombineSelect.cpp? > > On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: >> Hi

LGTM On Wednesday, July 27, 2016, Hans Wennborg <hans at chromium.org> wrote: > David, Sanjay: ping? > > On Mon, Jul 25, 2016 at 11:07 AM, Hans Wennborg <hans at chromium.org > <javascript:;>> wrote: > > Sure. David, what do you think about merging this to 3.9? > > > > Sanjay: are you saying I'd just apply that diff to > >

Hi Renato, Are you sure? Armv8-a is aarch32, not aarch64. Something smells fishy there. Cheers, James On Thu, 18 Dec 2014 at 08:03, Renato Golin <renato.golin at linaro.org> wrote: > On 16 December 2014 at 20:29, Christophe Lyon > <christophe.lyon at linaro.org> wrote: > >> I don't see "-march=aarch64" is a valid flag on either LLVM or GCC. >

On 10 December 2014 at 16:06, Renato Golin <renato.golin at linaro.org> wrote: > Hi Sumanth, > > Christophe (cc'd) is seeing the same problems on his build. It seems > that r181130 (by Tim) has something to do with it, but I'm not sure. > > I remember trying to build compiler-rt on AArch64 natively in > February, and even running the test-suite with it, so

Hi, I'm not sure what's up with BuiltinLongJmpTest. I think Greg was the last to do anything about arm-linux support in asan. As for the aarch64 failures, do you want to build the aarch64 bit stuff, but not run the tests? In cmake we try to detect target platforms supported by the compiler, but we don't check that binaries actuall run. But why is there so little failures, if the

I believe the C source files in builtins directory are generic enough. Why not build a clang_rt.builtins-aarch64 library? --Sumanth G -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140708/969ee15b/attachment.html>

Sure, we can build libclang_rt.builtins-aarch64.a, if there are users for it and, ideally, someone able to setup a buildbot and keep it in a working state. On Tue, Jul 8, 2014 at 11:32 AM, sgundapa <sgundapa at codeaurora.org> wrote: > I believe the C source files in builtins directory are generic enough. > > Why not build a clang_rt.builtins-aarch64 library? > > > >

Hi, Right. I'm aware of that. But to Clang, "armv8-a" as an architecture is ARMv8/AArch32. Unless Clang has recently got a lot cleverer than it has been in the past. James On Thu Dec 18 2014 at 9:06:04 AM Christophe Lyon <christophe.lyon at linaro.org> wrote: > On 18 December 2014 at 09:07, James Molloy <james at jamesmolloy.co.uk> > wrote: > > Hi Renato,

On Thu, Nov 21, 2013 at 10:59 AM, Kostya Serebryany <kcc at google.com> wrote: > +eugenis > (we are dealing with it: primarily we are trying to get hold of some PPC > machine to verify our fix) > > I have a PPC64 machine handy and can test a patch. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, Jan 15, 2016 at 11:05 AM, Ismail Donmez <ismail at i10z.com> wrote: > Hi, > > On Fri, Jan 15, 2016 at 12:59 AM, Chris Bieneman <beanz at apple.com> wrote: >> I’m kinda scared that you’re using it. What are you trying to accomplish >> that you are using it? Generally having LLVM split among that many >> dynamically loaded libraries results in

Hi, This I believe is a bug in kernel headers on openSUSE PPC64 but maybe there is some workaround. compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_linux.cc includes asm/stat.h which ends up with errors: /usr/include/asm/stat.h:31:2: error: unknown type name 'ino_t' ino_t st_ino; ^ /usr/include/asm/stat.h:34:2: error: unknown type name

Hi Does anyone have a plan of attack for some things which libgcc is providing on AARCH64, but compiler-rt isn't yet? We're hitting some Fortran issues with quad bits missing in glibc as a result. Specifically this list __addtf3 __eqtf2 __extenddftf2 __extendsftf2 __fixtfdi __fixtfsi __floatditf __floatsitf __gcc_qadd __gcc_qdiv __gcc_qmul __gcc_qsub __getf2 __gttf2 __letf2 __lttf2