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). 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. Neil Booth wrote:>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 doesn't return? > >Neil. > >_______________________________________________ >LLVM Developers mailing list >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev > > > >
> 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. I have ordered a copy of Visual Studio 2003 now anyway so can work with that. The CVS changes may probably want 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. Sorry again for any confusion caused. Aaron
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 > > > >
On Fri, 18 Feb 2005, Aaron Gray wrote:>> 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. > > I have ordered a copy of Visual Studio 2003 now anyway so can work with that. > > The CVS changes may probably want rolling back ?Aaron, don't worry about it, there is no confusion. We occasionally have to work around bugs in other compilers (including VC7.1), so this sort of patch is no different. As long as the changes required to get Whidbey working do not adversely affect other users/compilers, I don't have any problem with them. Again, thanks for the patch! The one thing to watch out for though is that other uses of abort will probably creep into the compiler over time, so we might accidentally break Whidbey support. Jeff has experienced this with VC7.1 support getting minorly broken from time to time as well. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/