similar to: [LLVMdev] Mod for using GAS with MS VC++

On Mon, 11 Jul 2005, Aaron Gray wrote: > Here is a mod to X86 that allows GAS to be used with MS Visual C++. > > I introduces a 'forWindows' variable like 'forCygwin' in th > X86SharedAsmPrinter class. > A couple of comments: 1. Please send patches instead of full files. The best way to do this is to use CVS like this: 'cvs diff -u' in the directory

>> Here is a mod to X86 that allows GAS to be used with MS Visual C++. >> >> I introduces a 'forWindows' variable like 'forCygwin' in th >> X86SharedAsmPrinter class. >> > > A couple of comments: > > 1. Please send patches instead of full files. The best way to do this is > to use CVS like this: 'cvs diff -u' in the

On Tue, 12 Jul 2005, Aaron Gray wrote: >> >> 1. Please send patches instead of full files. The best way to do this is >> to use CVS like this: 'cvs diff -u' in the directory that you care >> about. You can also specify specific files to diff as well. > > Okay, I will do this in future, our posts crossed so I have not done > that for the MASM

>>> 1. Please send patches instead of full files. The best way to do this >>> is >>> to use CVS like this: 'cvs diff -u' in the directory that you care >>> about. You can also specify specific files to diff as well. >> >> Okay, I will do this in future, our posts crossed so I have not done that >> for the MASM backend. I will

Jeff Cohen wrote: > Chris Lattner wrote: > >> On Tue, 12 Jul 2005, Aaron Gray wrote: >> >>>>>> Sure, but presumably you want to differentiate between nasm and >>>>>> masm (if they are not compatible) right? >>>>> >>>>> >>>>> >>>>> Right >>>> >>>>

Chris Lattner wrote: > On Tue, 12 Jul 2005, Aaron Gray wrote: > >>>>> Sure, but presumably you want to differentiate between nasm and >>>>> masm (if they are not compatible) right? >>>> >>>> >>>> Right >>> >>> >>> Then you need something more specific than 'isWindows'. I'd

On Tue, 12 Jul 2005, Aaron Gray wrote: >>> X86InstrInfo.td file it is full of them. >> >> Ah, I see what you're talking about. Please feel free to remove all of >> those from the Intel format. For example, change this: >> >> def IN8rr : I<0xEC, RawFrm, (ops), >> "in{b} {%dx, %al|%AL, %DX}">, Imp<[DX],

>> The GAS intel code generator generates percents, look at the >> X86InstrInfo.td file it is full of them. > > Ah, I see what you're talking about. Please feel free to remove all of > those from the Intel format. For example, change this: > > def IN8rr : I<0xEC, RawFrm, (ops), > "in{b} {%dx, %al|%AL, %DX}">, Imp<[DX],

On Tue, 12 Jul 2005, Aaron Gray wrote: >>> Right, presumably Wndows does not set the TT. Should Windows or MSVC++ >>> have one ? If so how do I go about it. Maybe Jeff should be involved ? >> >> It should/will. Currently there is no C/C++ front-end that works on native >> windows, but that doesn't really matter. In the future, we want to key off

I'm using Ubuntu 8.10 (Intrepid Ibex) and R 2.7.1. I've built a package from source (a modified version of gbm) and it contains some C++ code. I now want to cross-compile it to get a Windows version. I installed R using sudo apt-get update sudo apt-get install r-base sudo apt-get install r-base-dev So far as I can tell, I've also followed all the instructions in the guide

On Monday 25 April 2005 14:43, Vladimir Prus wrote: > The 'i' variable is never modified in the program, however, all analyses > except for -globalsmodref-aa report that the > > %tmp.3 = call int %_Z3bari( int %p ) ; <int> [#uses=1] > > instruction can modify 'i'. I'm somewhat surprised, because it looks like > -globalsmodref-aa is the simplest

Hello, I'm playing with alias analysis, using the following program: %i = external global int ; <int*> [#uses=2] implementation ; Functions: int %_Z3bari(int %p) { entry: %tmp.0 = load int* %i ; <int> [#uses=1] %tmp.1 = setgt int %tmp.0, 10 ; <bool> [#uses=1] br bool %tmp.1, label %then, label %UnifiedReturnBlock then:

A possible minor bug in lib/Target/X86/X86IntelAsmPrinter.cpp X86IntelAsmPrinter::doInitialization is calling AsmPrinter::doInitialization() not X86SharedAsmPrinter::doInitialization() Supprised I did not spot it earlier. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL:

>>>> Right, presumably Wndows does not set the TT. Should Windows or MSVC++ >>>> have one ? If so how do I go about it. Maybe Jeff should be involved ? >>> >>> It should/will. Currently there is no C/C++ front-end that works on >>> native windows, but that doesn't really matter. In the future, we want >>> to key off the target

On Mon, 25 Apr 2005, Vladimir Prus wrote: > The GlobalsModRef::getModRefInfo has this logic: > > // If we are asking for mod/ref info of a direct call with a pointer to a > // global we are tracking, return information if we have it. > if (GlobalValue *GV = const_cast<GlobalValue*>(getUnderlyingObject(P))) > if (GV->hasInternalLinkage()) > > So, no

Vyacheslav, This is the same problem that I had with Cygwin .. nearly identical. The issue was documented in PR492 if you want some background. I'm currently trying to dig up what I did to fix this in December for Cygwin and see if I can apply the same change for mingw. Reid. On Mon, 2005-03-07 at 16:39, Vyacheslav Akhmechet wrote: > Ok, I got home so I have more details. Here's the

>Hi Aaron, >have you got any help on this? Henrik, No. This is where I was stuck some months ago. I do not know makeinfo so was not able to proceed any thurther than verifying the makeinfo statement did the same thing when done on the command line. Basically I am stuck. I do not know whether it was my Cygwin configuration or something I have done or not done or whether it is a valid

Here's the new MASM backend. It has the following files :- lib/Target/X86/X86AsmPrinter.h lib/Target/X86/X86AsmPrinter.cpp lib/Target/X86/X86MASMPrinter.h lib/Target/X86/X86MASMPrinter.cpp lib/Target/X86/X86.td lib/Target/X86/X86InstrInfo.td lib/Target/X86/makefile Makefile.rules win32/x86/x86.vcproj

Hello Aaron, Aaron Gray wrote on 14/10/2005 at 10:22 a.m.: > I am not sure but it looks like a problem with your Cygwin > instillation ? Try a 'make configure' or 'make reconfigure'. Hmmm, I was able to build llvm/tools-only.... As for "make configure" - that didn't help. > Here's a link to the instructions I developed for building LLVM on > Cygwin

Aaron Gray wrote: >> GCC is smart enough to realize it doesn't return. That's because the >> declaration of abort() is decorated with __attribute__((__noreturn__)). >> >> So is GCC smarter than VC++? As it turns out, in VC++ the >> declaration of abort() is decorated with __declspec(noreturn). >> >> Whidbey is not stricter than 2003, it is