similar to: [LLVMdev] arm patch 2/n

I am splitting the ARM patches to make the merge easier. This one just adds new ARM specif files. The company designer was kind enough to borrow me a powerbook, so this patch was tested on a amd64 and a g4. Best Regards, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: arm1.patch.bz2 Type: application/x-bzip2 Size: 13152 bytes Desc: not available URL:

This patch modifies only the files in gcc/config/arm. Tested on a linux/amd64 and a darwin/powerpc. Best Regards, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: arm3.patch.bz2 Type: application/x-bzip2 Size: 7321 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20061206/2d53d7c6/attachment.bin>

This patch should be in today's mirror ~6am PST. Cheers, -- Jim On Dec 4, 2006, at 4:32 PM, Rafael Espíndola wrote: > On 12/2/06, Jim Laskey <jlaskey at apple.com> wrote: >> Rafael, >> >> Please bracket portions of your changes that involve modification of >> C/C++ source code. For cases of modifying configuration scripts and >> make files, use your

Hi, all It seems that rev. 131463 [1] makes LLVM failed to recognize ARM correctly. My best guess is the variable LLVM_HOSTTRIPLE got something like "armv7l-unknown-linux-gnueabi" when LLVM compiled natively on ARM. Then the Arch (armv7l) is not recognized by LLVM. As you can see from attach (llvm-131463-gcc-4.4.1-native-arm2.log), there are a lot failure while running test cases

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

> Could you please try to remove the empty gcc/unwind.h and try again? I > am currently compiling on a powerbook. I will report as soon as it > finishes. The build finished successfully! Rafael

> I say that we drop it. If someone steps up to start maintaining it, they can begin by resurrecting it from SVN. Patches attached. Cheers, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.patch.bz2 Type: application/x-bzip2 Size: 76683 bytes Desc: not available URL:

On 10 February 2014 03:44, Renato Golin <renato.golin at linaro.org> wrote: > On 10 February 2014 02:59, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> It has to be an attribute because of LTO. You can LTO a file compiled >> with -fasynchronous-unwind-tables and one with >> -fno-asynchronous-unwind-tables. That is why we have the uwtable >>

On Thu, Aug 9, 2012 at 12:49 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> I think this is a leftover from the days we used to have a *byte*code >> and use bzip2 on it :-) >> >> I will try to clean it up. > > The attached patch removes all references to compression from llvm-ar, > llvm-ranlib and related libraries. > > Is it OK? >

Attached is the current ARM patch. It allows the LLVM branch to compile on linux/arm and the resulting libgcc is compatible with a glibc compiled a vanilla gcc,i.e, a statically compiled hello world works :-) The patch was constructed by merging patches from gcc 4.1 with minimal editing for making merging easier. It was requested that I bracket the changes, I will try to remove all unnecessary

On 12/2/06, Jim Laskey <jlaskey at apple.com> wrote: > Rafael, > > Please bracket portions of your changes that involve modification of > C/C++ source code. For cases of modifying configuration scripts and > make files, use your best judgement. Obviously having the brackets > emitted in generated code is problematic (line numbers et cetera), so > don't bother in

>> The semantics uwtable is just "make sure it is possible to unwind past >> this function". It doesn't include anything more, >> like the ability to run destructors. It is used for ABIs that require >> it for use in debuggers and profilers. > > Well, that meaning fails when you have both uwtable and nounwind, > which means: "generate a

On Thu, Aug 9, 2012 at 1:15 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Thu, Aug 9, 2012 at 12:49 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >>> I think this is a leftover from the days we used to have a *byte*code >>> and use bzip2 on it :-) >>> >>> I will try to clean it up. >> >> The attached

> I disagree on this. Table emission by itself doesn't involve code > generation and I don't think it makes sense as a per function attribute > either. You either want it for all functions or only when needed (e.g. > exceptions are possible). As such, it makes perfect sense to me as a > global flag. It has to be an attribute because of LTO. You can LTO a file compiled with

Hi Conrad, Thanks for your help. I am unlucky. No i have this following error : source='speexdec.c' object='speexdec.o' libtool=no \ depfile='.deps/speexdec.Po' tmpdepfile='.deps/speexdec.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ arm-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../libspeex -I/usr/include -O2 -fno-exceptions -O2

On 20 March 2014 02:09, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I think this is just 2. It uses .eh_frame for unwinding proper. The > only difference in .eh_frame is that there is a personality function > defined. If there is no debug information, it should still be possible to unwind the stack via the saved LR on the stack, no? If there is only line info, you

I assume this "CantUnwind table" is not the same as Unwind table index '.ARM.exidx' at offset 0x818 contains 4 entries: 0x5d4 <main>: 0x1 [cantunwind] because the latter prevent any unwinding, breaking debuggers/profilers/sanitizers. As I understand, the right way to enable basic unwind through any function (without emitting landing pands etc, unless they are needed for

I had to revert these changes. When I did a clean build I was inundated with errors. I'm not sure if I made the cut off time for the mirror. -- Jim On Dec 5, 2006, at 8:35 AM, Jim Laskey wrote: > This patch should be in today's mirror ~6am PST. > > Cheers, > > -- Jim > > On Dec 4, 2006, at 4:32 PM, Rafael Espíndola wrote: > >> On 12/2/06, Jim Laskey

Hi all, Since the 3.1 testing day is coming and be a ARM tester, I would like to make sure everything is O.K. so that we don't waste the precious time. As discussed on the ML before, I plan to cross compile LLVM/Clang first, then run regression test and test suite on the pandaboards. Could someone help me check to see if I miss something? Thanks! Here is the pandaboard configuration,

Well, what I had in mind was actually something like the following: entry: result0 = invoke func0 to defer_block unwind landing0 landing0: landingpad result1 = invoke func1 to defer_block unwind landing1 landing1: landingpad br defer_block defer_block: result = phi [ result0, entry ], [ result1, landing0 ], [ null, landing1 ] ... This doesn't have landing pads with multiple