similar to: [LLVMdev] LLVM built on VS C++ 2005

Aaron Gray wrote:- > Hi, > > I have built yesterdays CVS download of LLVM on Whidbey (Microsoft Visual Studio 2005). > > LLVM built with trivial mods due to VS strictness compared to GCC. Basically there are missing return statement/values where Abort() is called, I replaced these with dummy constructors to get them to compile. Sounds like GCC is smart enough to realise it

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 merely buggier. VC++ has always complained about functions failing to return a

> 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 merely buggier. VC++ has always > complained

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

Trivial? That's GREAT news! Nice job. Yes, we would be interested in the patches to get it to run. Thanks for letting us know! Reid. On Wed, 2005-02-16 at 18:50, Aaron Gray wrote: > Hi, > > I have built yesterdays CVS download of LLVM on Whidbey (Microsoft > Visual Studio 2005). > > LLVM built with trivial mods due to VS strictness compared to GCC. > Basically

>> I thought Whidbey would really be upto the job, obviously not. > > Well, we don't know until someone tries. Oh, well we have got a bug to report to Microsoft then ! I still may carry on implementing any mods on the VS2003 port over to 2005 so we know where we are with that. There may well be a second beta so it would be good to get any problems in and reported to Microsoft in

On Fri, 18 Feb 2005, Aaron Gray wrote: >>> I thought Whidbey would really be upto the job, obviously not. >> >> Well, we don't know until someone tries. > > Oh, well we have got a bug to report to Microsoft then ! > > I still may carry on implementing any mods on the VS2003 port over to 2005 > so we know where we are with that. There may well be a second

>> I still may carry on implementing any mods on the VS2003 port over to >> 2005 >> so we know where we are with that. There may well be a second beta so it >> would be good to get any problems in and reported to Microsoft in lue of >> that. > > ok. If both you and Jeff are okay with still implementing a VC2005 version spawning off changes to the VC2003 port

Hi Jeff and Morten, I was just wondering if below wisdom is true, why not prefix every solution and project file with VC71 in front of the file name to signal the case that it is only designed for that specific IDE/tool? This gives us room for comming up with other solution and project files for another MS specific IDE/tool independt of each other. Henrik. ----Original Message Follows----

I'm not sure you understand the problem. Are you saying that a file compiled with mingw can catch an exception thrown by a file compiled with VC++ when the two are linked into a single program? That a program compiled with mingw can be linked against the VC++ runtime and *not* the mingw/gcc runtime? Linking against system DLLs is very different from what I'm talking about. Adam

On Friday 18 February 2005 11:40 am, Jeff Cohen wrote: > I'm not sure you understand the problem. I wouldn't be surprised :) > Are you saying that a file > compiled with mingw can catch an exception thrown by a file compiled > with VC++ when the two are linked into a single program? That a program > compiled with mingw can be linked against the VC++ runtime and *not*

I'm afraid that still does not completely answer the question. I'll accept that it will work for C programs, given what you quote. It says nothing about C++ however. That's a different animal entirely. g++ mangles names in a completely different fashion than VC++. Does mingw use VC++ style mangling? g++ processes exceptions in a completely different fashion than VC++. I

Hi Reid, I'll send a complete report tommorow, its getting late. It looks like there is alot of work to do to get the MS VC version in line with the Unix release. I am very willing to help out with porting. The tests and regression tests look a biggy maybe they would be better done on the command line using make rather than separate Visual Studio projects. As I say I am willing to help

Hi, Have you tried the new VC8 Beta? It's been out for less than 2 weeks: http://lab.msdn.microsoft.com/express/visualc/default.aspx It's supposed to have improved standards compliance. Regards, -Eugene Talagrand On Thu, 8 Jul 2004, Chris Lattner wrote: > Date: Thu, 08 Jul 2004 01:56:03 -0500 (CDT) > From: Chris Lattner <sabre at nondot.org> > Reply-To: llvmdev at

On Friday 18 February 2005 11:19 am, Chris Lattner wrote: > I think that G++ has some support for linking to native windows libraries, > using by MingW? We should eventually be able to do as well as it does. > Note that for non C/C++ compilers, this is not an issue. It does indeed. You can even use mingw/g++ to cross-compile Windows exe under Linux.

It's a possibility, though it would be better to create whole separate trees for different versions of VS. It's not just the project and solutions that need to be kept separate; the object files themselves cannot be mixed between different versions of VS. There's no rush though. Trust me, C/C++ programmers will not rush to adopt Whidbey once it's released. You'd be

----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfileor directory Date: Thu, 23 Dec 2004 08:05:39 -0800 >Yes, it

Hi all, I just wanted to know if anyone's looked into using the free version of Microsoft's Visual C++ toolkit for LLVM: http://msdn.microsoft.com/visualc/vctoolkit2003/ -bw -- || "If wishes and buts were clusters of nuts, we'd all have a bowl of || granola!" - Mr. Jellineck

Henrik Bach wrote: > ----Original Message Follows---- > From: Jeff Cohen <jeffc at jolt-lang.org> > Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List > <llvmdev at cs.uiuc.edu> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': > No suchfileor

Chris Lattner wrote: > On Thu, 8 Jul 2004, Bill Wendling wrote: > > I just wanted to know if anyone's looked into using the free version of > > Microsoft's Visual C++ toolkit for LLVM: > > > > http://msdn.microsoft.com/visualc/vctoolkit2003/ > > Sorry, but it is not even close to working (its template and STL support > is horribly lacking). The