similar to: compile klibc problem (EABI version error)

hi, Dale Johannesen wrote: > On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: >> i'm trying to make some experiments with the ARM backend (llvm 2.1) >> and >> therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. >> >> however, the llvm-gcc frontend seems to cause troubles with single >> precision floating point values, i.e., they are

hi, i've got some more things to note. first, the issue is not related to x86_64 being the host machine - it also happens on i686/linux. next, i think (one of) the problem(s) is the use of [HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in llvm-convert.cpp (see patch below). this fixes single precision floating point but breaks double precision. for

Hi all, Actually,I found there is a same problem for arm.For this case,I think > maybe we can play a trick in the clang. > Checking whether the given arch valid or not,before we throw it to the > parser,which can be used for both arm > and aarch64. For the actions I mentioned above,I wrote a check function as below, basing on the naming rules of the arm architecture. +//Only if

On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: > hi, > > i'm trying to make some experiments with the ARM backend (llvm 2.1) > and > therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. > > however, the llvm-gcc frontend seems to cause troubles with single > precision floating point values, i.e., they are not converted > correctly > to the

hi, i'm trying to make some experiments with the ARM backend (llvm 2.1) and therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. however, the llvm-gcc frontend seems to cause troubles with single precision floating point values, i.e., they are not converted correctly to the particular target format (double precision works as expected). it seems the problem is related to

hello mailinglist, i currently try to compile ffmpeg on a 64bit fedora-core 8 machine using llvm2.3. the "good" things first: everything works fine on a 32bit ubuntu-machine using llvm-2.3 (actually i do not know if that is grace to ubuntu or grace to 32bit) when using the normal gcc on the 64bit fc8 machine, everything works too. now the "bad" thing: it does not work on fc8

A new pixman release 0.44.0 is now available. tar.gz: https://cairographics.org/releases/pixman-0.44.0.tar.gz https://www.x.org/releases/individual/lib/pixman-0.44.0.tar.gz tar.xz: https://www.x.org/releases/individual/lib/pixman-0.44.0.tar.xz Hashes: SHA256: 89a4c1e1e45e0b23dffe708202cb2eaffde0fe3727d7692b2e1739fec78a7dac pixman-0.44.0.tar.gz SHA256:

Hello, Everyone. Just few notes for everyone, who wants to build Qt with llvm. Everything was tested with shiny-new Qt 4.2.2 (X11 version) and llvm-gcc4 & LLVM from head. Instructions written here should also work on 1.9 release, as I've tested Qt build last time just before 1.9 release. 1. Specs Qt uses it's own configuration and build system called "qmake". We should

Full_Name: Lixin Han Version: 2.4.0 OS: Windows 2000 Submission from: (NULL) (155.94.110.222) A character vector c('a','b') is supplied to rm(). As a result, 'c' is deleted unintentionally. > a <- 1:5 > b <- 'abc' > c <- letters > ls() [1] "a" "b" "c" > rm(c('a','b')) > ls() character(0)

Hi, I am new to LLVM and have been trying to get it working on scratchbox (ARM target). When I try to build llvm-2.1, the build freezes with the following output.. /scratchbox/compilers/arm-softfloat-linux-gcc-3.4.4-cs-2005q3-2-glibc-2.3.6/bin/sbox-arm-softfloat-linux-gnu-nm: 'libgcc/./_dvmd_lnx_s.o': No such file mv -f libgcc/./_dvmd_lnx.visT libgcc/./_dvmd_lnx.vis

Attached is a port of the new ARM eabi from gcc 4.1 to the llvm-gcc branch. With this patch I am able to bootstrap the 4.0 branch using the new eabi. The llvm-gcc branch fails with ------------------------------------ internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14372 ------------------------------------ But I believe that this is an unrelated problem and I will

Attached is a port of the new ARM eabi from gcc 4.1 to the llvm-gcc branch. With this patch I am able to bootstrap the 4.0 branch using the new eabi. The llvm-gcc branch fails with ------------------------------------ internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14372 ------------------------------------ But I believe that this is an unrelated problem and I will

On 11/24/06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Attached is a port of the new ARM eabi from gcc 4.1 to the llvm-gcc > branch. With this patch I am able to bootstrap the 4.0 branch using > the new eabi. The llvm-gcc branch fails with > > ------------------------------------ > internal compiler error: in prune_unused_types_update_strings, at >

On Feb 8, 2007, at 10:46 AM, Lauro Ramos Venancio wrote: > I'm facing a problem with functions arguments. ARM EABI defines that > 8-bytes arguments must be 8-bytes aligned. For example: > > void @f(i32 %a, i64 %b) > > ARM EABI: > r0 <- %a > r2,r3 <- %b Ok. I suppose this makes it easier to use 64 bit store instructions. > > Darwin: > r0 <- %a >

Hi list, I'm wondering if LLC supports code generation targeting ARM processors and using the EABI. Thanks, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100505/3f16d04f/attachment.html>

Hello, Renato > Anyone has any idea on the status of exception handling in clang/LLVM? > DwarfException cannot be easily overwritten, and adding target specific > code to it seems wrong... Neither llvm-gcc nor clang support exceptions on ARM (except, maybe, sjlj excheptions on arm/darwin). I have some patched uncommitted for EH on ARM but they are too far from being complete. -- With

On Mon, Sep 27, 2010 at 8:50 AM, Dennis Taul <dtaul at codeaurora.org> wrote: > > I am new to LLVM but have perused the code alongside using llvm-gcc > and CLANG to build ARM EABI objects. > > Based on this superficial analysis it appears that LLVM currently does > not support the ARM Exception Handling ABI (as defined under the > EABI). > > Can anyone comment on

> Is it safe to say the MC work provides a (new) foundation for > implementing ARM EH? Or, is providing ARM EH independent of the ARM-MC > work? The latter. MC stuff helps somehow though. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Devang, I believe this has been fixed with llvm r144547. See: <rdar://problem/10441389>. Chad On Nov 14, 2011, at 4:39 PM, Devang Patel wrote: > I filed PR 11378. > Thanks! > - > Devang > > On Nov 14, 2011, at 1:27 PM, Galina Kistanova wrote: > >> Hello Devang, >> >> Please find attached the preprocessed source file and the LLVM >>

On Nov 14, 2011, at 4:52 PM, Chad Rosier wrote: > Devang, > I believe this has been fixed with llvm r144547. See: <rdar://problem/10441389>. It is likely that r144546 fixed some other bug. I just checked, this still fails with r144602. - Devang -------------- next part -------------- An HTML attachment was scrubbed... URL: