search for: thurther

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. This may prompt thurther normalization, on the otherhand it may not :) Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050711/17d090a4/attachment.html> -------------- next part -------------- An embedded and charset-unspeci...

...ific. Maybe it should be MSVC specific then ? > 5. I notice that the stuff you are controlling enables/disables the exact > same stuff as needed for cygwin. Will this change in the future? Same as Cygwin, so MSVC++ build, gas generated code, can be run on gas. >> This may prompt thurther normalization, on the otherhand it may not :) > > Yes, I think it will. :) In particular, instead of a bunch of checks > based on the target, what we really want is something like this: > > ... in the AsmPrinter ctor... > if (isDarwin) { > TargetUsesFooFeature = true;...

...re multiple dev systems available on windows (including cygwin, mingw, masm, nasm, etc). Please use something more specific. 5. I notice that the stuff you are controlling enables/disables the exact same stuff as needed for cygwin. Will this change in the future? > This may prompt thurther normalization, on the otherhand it may not :) Yes, I think it will. :) In particular, instead of a bunch of checks based on the target, what we really want is something like this: ... in the AsmPrinter ctor... if (isDarwin) { TargetUsesFooFeature = true; TargetUsesBarFeature = tru...

...>> 5. I notice that the stuff you are controlling enables/disables the exact >> same stuff as needed for cygwin. Will this change in the future? > > Same as Cygwin, so MSVC++ build, gas generated code, can be run on gas. I don't understand. >>> This may prompt thurther normalization, on the otherhand it may not :) >> >> Yes, I think it will. :) In particular, instead of a bunch of checks >> based on the target, what we really want is something like this: ... > Yes that would be much better and more normalized. Nate said he might take...

>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 build error. I did try MinGW several months ago but did not even get...

...ds do not directly link against LLVM anyway. Nonetheless, we > don't have binaries built with cygwin or mingw that can be > distributed for use with a natively built LLVM. GNU's frontends are in C is that the problem ? I do not see the area properly. Please can you explain thurther. > * Even when front ends become available, there are still issues with > linking, especially for C++. As the front end is based on g++, it > wants g++ header files and it emits code that needs to link > against g++ runtime libraries. That sort of defeats the point...

Chris Lattner wrote: > On Fri, 18 Feb 2005, Aaron Gray wrote: > >> GNU's frontends are in C is that the problem ? I do not see the area >> properly. Please can you explain thurther. > > I'll let Jeff explain this one. The problem is that gcc cannot be built using VC++. You'll have to ask the gcc project as to why, but they've made it clear they have no intention of supporting this. Even if it could, a gcc build would still require a complete unix emula...

Hi Aaron, which version of makeinfo are you running? 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 build error. > >I did try MinGW several mont...

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

...k against LLVM anyway. Nonetheless, we >> don't have binaries built with cygwin or mingw that can be >> distributed for use with a natively built LLVM. > > GNU's frontends are in C is that the problem ? I do not see the area > properly. Please can you explain thurther. I'll let Jeff explain this one. >> * Even when front ends become available, there are still issues with >> linking, especially for C++. As the front end is based on g++, it >> wants g++ header files and it emits code that needs to link >> against g+...

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

Hi Aaron, have you got any help on this? Henrik >From: "Aaron Gray" Date: Sat, 14 May 2005 18:26:01 +0100 > >Now I believe that I am getting the same error as I was getting last time I >tried to build llvm-gcc. >It may possibly be my Cygwin instillation but am not sure. > > >makeinfo --split-size=5000000 -I ../../../src/llvm-gcc/gcc/doc -I >../../../src/

Oleg, > - llvm/make tools-only worked ok Good. > - llvm-gcc/make all failed with the following message (2nd try): > make[2]: Leaving directory `/home/oleg.smolsky/llvm-gcc-build/gcc' > make[1]: Leaving directory `/home/oleg.smolsky/llvm-gcc-build/gcc' > Checking multilib configuration... > multilib.out is unchanged > Configuring in i686-pc-cygwin/libstdc++-v3 >

...d for cygwin. Will this change in the future? >> >> Same as Cygwin, so MSVC++ build, gas generated code, can be run on gas. > > I don't understand. What this "patch" is for. Basically when a MSVC++ build lcc generates GNU as code. >>>> This may prompt thurther normalization, on the otherhand it may not :) >>> >>> Yes, I think it will. :) In particular, instead of a bunch of checks >>> based on the target, what we really want is something like this: > > ... > >> Yes that would be much better and more normalize...

Now I believe that I am getting the same error as I was getting last time I tried to build llvm-gcc. It may possibly be my Cygwin instillation but am not sure. makeinfo --split-size=5000000 -I ../../../src/llvm-gcc/gcc/doc -I ../../../src/ llvm-gcc/gcc/doc/include \ -o ../../../src/llvm-gcc/gcc/doc/cpp.info ../../../src/llvm-gcc/gcc/doc/cpp.texi ' in