similar to: [LLVMdev] Typos in ARMInstrInfo.td ?

Thanks. Fixed with r147032. Evan On Dec 16, 2011, at 1:50 AM, George Russell wrote: > Hi, > > I think there are a set of typos in the ATOMIC_LOAD_UMIN_I* and > ATOMIC_LOAD_UMAX_I* > pseudo-instructions . > > Specifically, > > def ATOMIC_LOAD_MIN_I32 : PseudoInst< > (outs GPR:$dst), (ins GPR:$ptr, GPR:$val), NoItinerary, >

Hi Evan, The problem repeats with the i8 and i16 variants, as well. Cheers, George On 21/12/2011 04:07, Evan Cheng wrote: > Thanks. Fixed with r147032. > > Evan > > On Dec 16, 2011, at 1:50 AM, George Russell wrote: > >> Hi, >> >> I think there are a set of typos in the ATOMIC_LOAD_UMIN_I* and >> ATOMIC_LOAD_UMAX_I* >> pseudo-instructions .

Quoting Gabor Greif <ggreif at gmail.com>: Hi Gabor, I can not open the link, can you send again? > AAAH! > > I see you are still at 2.5. Then this patch (the fix) > is relevant for you: > > <http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/ > ilist.h?r1=66061&r2=68785&diff_format=h> > > Cheers, > > Gabor > > >

Hi all, I think there is a typo in TargetLowering.cpp where Names[RTLIB::SYNC_FETCH_AND_XOR_4] = "__sync_fetch_and-xor_4"; is given, and it looks like it should be "__sync_fetch_and_xor_4"; This was added here: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/TargetLowering.cpp?view=diff&r1=106320&r2=106321

Hi Jim, > Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why. Attributes should be emitted into object file as well... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Sep 29, 2010, at 3:58 PM, Anton Korobeynikov wrote: > Hi Jim, > >> Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why. > Attributes should be emitted into object file as well... Yes, but surely not by a function explicitly indicated to be for assembly files. I would expect there to be an

On Sep 29, 2010, at 4:27 PM, Jason Kim wrote: >> Yes, but surely not by a function explicitly indicated to be for assembly files. I would expect there to be an equivalent function to do what needs done for object files. Perhaps there isn't one (yet) and that's what's leading to the confusion? > > LOL :-) Yes, maybe that's it. Included is a patch w comments that >

On Wed, Sep 29, 2010 at 4:00 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Sep 29, 2010, at 3:58 PM, Anton Korobeynikov wrote: > >> Hi Jim, >> >>> Since this is by definition only for .s file emission, why is this clearly wrong? Perhaps it is, but it's not obvious to me why. >> Attributes should be emitted into object file as well... > >

On Sep 29, 2010, at 3:09 PM, Jason Kim wrote: > Hi Everyone, > > I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, > and had some questions. > > Currently, it defines quite a few methods like printAddrMode4Operand > (linked to ARMInstrInfo.td) that currently assume raw text support in > the OutStreamer. Are these methods still supposed to be

Hi Everyone, I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, and had some questions. Currently, it defines quite a few methods like printAddrMode4Operand (linked to ARMInstrInfo.td) that currently assume raw text support in the OutStreamer. Are these methods still supposed to be invoked in the MC'ized path for assembly output? Is JimG's new MC/.s

--- Prevents errors like these: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-apps/shadow/files/shadow-4.1.5-stdarg.patch?view=diff&r1=text&tr1=1.1&r2=text&tr2=1.1&diff_format=s helper/utils.c | 1 + 1 file changed, 1 insertion(+) diff --git a/helper/utils.c b/helper/utils.c index 67d8ad2..c211a03 100644 --- a/helper/utils.c +++ b/helper/utils.c @@ -16,10

Hi, I'm trying to add a new intrinsic to the ARM backend. The intrinsic should a custom comparison. To do so, I started with first defining the intrinsic in llvm/include/llvm/IR/intrinsicsARM.td: def int_foo_cmp : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], []>; The second step I did is adding a new pseudo instruction matching that intrinsic in lib/Target/ARM/ARMInstInfo.td:

I don't know since when, but this file has been changed to remove all the trickery (aka defines) needed for MinGW-w64 (and probably everything else that as forgotten) to succesfully compile it. Attached is a patch that reintroduces the compiler checking. I would like to see this in LLVM 3.0, otherwise (by the looks of the reintroduced code) anything newer than _MSC_VER_1500 will be broken.

I''m wondering if I should file a bug against this or is this just a case of a user doing something stupid :) I ran the following script on my desktop: #!/usr/sbin/dtrace -s pid9276:::entry { @counting[probefunc] = count(); } And my Xsession immediately crashed and through me back to the login screen. My OS is 5.11 snv_50 i86pc i386 i86pc with a dual core amd chip and 2G or

Dear r-help users, I have the following simple problem: Reading data from a file. The file is a .txt file exported ("save as...") from Excel (see below for an example). The Excel file consists of two header rows (first row consists of ticker symbols of stocks, the second row consists of column explanations ("Date","Px Last"), followed by several rows of