[LLVMdev] LLVM built on VS C++ 2005

[Jeff Cohen]

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 merely buggier.  VC++ has 
>> always complained about functions failing to return a value; this is 
>> not new in Whidbey.  What is new is that it no longer pays attention 
>> to __declspec(noreturn).
>
>
> Got by a Microsoft bug, sorry about that folks. I should have looked 
> at abort()'s declaration.
>
>> That is why it is difficult to justify supporting Whidbey.  This bug 
>> may have been easy to work around.  The next one may not be so easy. 
>> Remember, if Whidbey wasn't buggy and incomplete, you'd be paying 
>> around $1000 for it instead of downloading it for free.
>
>
> Too earger to get LLVM running. Really I should have checked things 
> out deeper.
> I thought Whidbey would really be upto the job, obviously not.

Well, we don't know until someone tries.

>
> I have ordered a copy of Visual Studio 2003 now anyway so can work 
> with that.
>
> The CVS changes may probably want rolling back ?

These changes aren't worth rolling back.

>
> Jeff, as I say if I can work with/under you on the Visual C++ 2003 
> port then maybe we can get some real work done.

Reid gave a good summary of what needs to be done.  To that list I would 
add:

    * The X86 assembler printer needs to be modified to generate
      assembler code that works with NASMW.  It currently generates
      assembler for the GNU assembler, gas.  The goal is to use the GNU
      tool chain as little as possible when using VC++ for native
      builds.  Microsoft's MASM isn't really an option because Microsoft
      stopped distributing it as part of Visual Studio a long time ago.
    * There is no language front end that can be used with native builds
      at this time.  The GNU C/C++/Java front ends cannot be built
      natively with VC++.  This isn't strictly necessary as the front
      ends 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.
    * 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 of
      a native Windows LLVM.  It's not yet clear how well C code can
      link against MS C's libraries, though it ought to work (and does
      for simple cases).

So the question is, what would you like to work on?

Also, you need to update.  The other problems you encountered have 
already been fixed.

>
> Sorry again for any confusion caused.
>
> Aaron
>
>
>
>