I just wonder that Visual Studio .NET 2003 is the most compatible one among various MS Visual Studio versions for LLVM.
Thank you
Seung Jae Lee
It is, if only because it's the version I use, but 2005 is supposed to work also. That being said, I wouldn't be surprised to learn that it doesn't due to recent STL issues. Versions prior to 2003 won't work.
Seung Jae Lee wrote:
I'm using the basic stuff (just libraries, 1.9) with 2005, although we
had to fix a few compilation errors locally. Can't remember of the top
of my head what they where but IIRC there were some explicit namespace
qualifications missing here and there.
HTH,
Andreas
The recent issues concern the head revision, post 1.9. As no one has ever submitted patches to fix 2005 problems with the 1.9 release, it is safe to say they still exist.
Andreas Fredriksson wrote:
> It is, if only because it's the version I use, but 2005 is supposed to
> work also. That being said, I wouldn't be surprised to learn that it
> doesn't due to recent STL issues. Versions prior to 2003 won't work.I'm using the basic stuff (just libraries, 1.9) with 2005, although we
had to fix a few compilation errors locally. Can't remember of the top
of my head what they where but IIRC there were some explicit namespace
qualifications missing here and there.
Could you submit the patch? We could make sure that 2.0 doesn't have the
same problem.
Thanks,
Reid.
I successfully build llvm from cvs using vs2005 and stlport. I also had a couple of issues, but most were due to outdated project files. I also had to implement code for the alloca instruction.
Sure, I can't test this from where I am now but if anyone can take it
for a spin to test it and verify the fix then by all means check it
in. I'm just providing a hand-edited diff from our vendor branch here
(1.9 tarball version); it's the best I can do right now.
I think the most important part was the change to the StoreSDNode
constructor which relied on implicit type lookup.
// Andreas
llvm-msvc2005.patch.gz (1.86 KB)
It is supposed to build without stlport, which most people won’t have, though Microsoft is making that somewhat challenging right now. The project files were not out of date at the 1.9 release, and they’re not out of date right now. I assume the alloca instruction is still broken because – and I hate to sound like a broken record – no patch was provided.
Jake wrote:
No, the problem with StoreSDNode was that an argument as being called Value, which hid the class Value later on in the argument list. This also broke 2003 and was fixed a while ago.
_WIN32_WINNT is not supposed to be predefined, so that warning shouldn’t be occurring. I have never seen it myself, and a predefined value could be inappropriate.
Most of the other changes seem to be about inserting casts, and I’d like to know what errors they are fixing. The casts are not needed with GCC or VS 2003.
Andreas Fredriksson wrote:
No, the problem with StoreSDNode was that an argument as being called Value,
which hid the class Value later on in the argument list. This also broke
2003 and was fixed a while ago.
Ok, I didn't know that. We've been using the 1.9 tarball version, as I said.
_WIN32_WINNT is not supposed to be predefined, so that warning shouldn't be
occurring. I have never seen it myself, and a predefined value could be
inappropriate.
Many win32 projects define this globally when they need some specific
target version of the platform SDK. Maybe the correct way would be to
do a less-than check and bail out instead.
Most of the other changes seem to be about inserting casts, and I'd like to
know what errors they are fixing. The casts are not needed with GCC or VS
2003.
I didn't add those but I'm fairly sure they only fixed warnings about
c-style casts.
So in effect my patch offered zero value for the list, please disregard it 
// A
Jeff Cohen wrote:
The recent issues concern the head revision, post 1.9. As no one has ever submitted patches to fix 2005 problems with the 1.9 release, it is safe to say they still exist.
For the 1.5 release I submitted patches that made everything compile correctly with VS2005, I think there are some mails in the archives about the issues I ran into. I also submitted patches to make everything compile on x64 windows, but since there was no x64 backend at that point it could only produce 32-bit code. I think there are only small problems with new code that need to be fixed, but since my company doesn't use LLVM at the moment it's hard for me to justify spending time on it...
m.
Andreas Fredriksson wrote:
No, the problem with StoreSDNode was that an argument as being called Value,
which hid the class Value later on in the argument list. This also broke
2003 and was fixed a while ago.Ok, I didn't know that. We've been using the 1.9 tarball version, as I said.
Just to make clear, there are no problems building 1.9 with VS 2003, nor are there any problems as I write this.
_WIN32_WINNT is not supposed to be predefined, so that warning shouldn't be
occurring. I have never seen it myself, and a predefined value could be
inappropriate.Many win32 projects define this globally when they need some specific
target version of the platform SDK. Maybe the correct way would be to
do a less-than check and bail out instead.
That's what we do. We define it in llvm/lib/System/Win32/Win32.h, which in included by every file that uses the Win32 API. There is no reason for you to redefine it. Changing it to an earlier version will cause build failures, changing it to a later version will have no effect, other than to permit the use of more recent Win32 APIs that will prevent LLVM from running on versions as old as Windows 2000.
Most of the other changes seem to be about inserting casts, and I'd like to
know what errors they are fixing. The casts are not needed with GCC or VS
2003.I didn't add those but I'm fairly sure they only fixed warnings about
c-style casts.
I don't understand. How does introducing c-style casts were none existed silence warnings about c-style casts?
So in effect my patch offered zero value for the list, please disregard it
OK
Morten Ofstad wrote:
Jeff Cohen wrote:The recent issues concern the head revision, post 1.9. As no one has ever submitted patches to fix 2005 problems with the 1.9 release, it is safe to say they still exist.For the 1.5 release I submitted patches that made everything compile correctly with VS2005, I think there are some mails in the archives about the issues I ran into. I also submitted patches to make everything compile on x64 windows, but since there was no x64 backend at that point it could only produce 32-bit code. I think there are only small problems with new code that need to be fixed, but since my company doesn't use LLVM at the moment it's hard for me to justify spending time on it... m.
Even just mailing me a build log showing the problems would be a big help.
Just to make clear, there are no problems building 1.9 with VS 2003, nor
are there any problems as I write this.
I'm fairly sure we grabbed the 1.9 tarball off the website, but I
could be wrong.
That's what we do. We define it in llvm/lib/System/Win32/Win32.h, which
in included by every file that uses the Win32 API. There is no reason
for you to redefine it. Changing it to an earlier version will cause
build failures, changing it to a later version will have no effect,
other than to permit the use of more recent Win32 APIs that will prevent
LLVM from running on versions as old as Windows 2000.
Yes; my point was merely that in some build environments it's
convenient to just define it to , say, Windows XP all across the
solution with a property sheet (as we had done).
// A
Andreas Fredriksson wrote:
That's what we do. We define it in llvm/lib/System/Win32/Win32.h, which
in included by every file that uses the Win32 API. There is no reason
for you to redefine it. Changing it to an earlier version will cause
build failures, changing it to a later version will have no effect,
other than to permit the use of more recent Win32 APIs that will prevent
LLVM from running on versions as old as Windows 2000.Yes; my point was merely that in some build environments it's
convenient to just define it to , say, Windows XP all across the
solution with a property sheet (as we had done).
But why modify our solution to make this change? How is it convenient to change something that worked, and in the process create a problem you'd like us to fix? And, of course, when you pull the 2.0 tarball, you'll have to make the change all over again
Jeff Cohen wrote:
Morten Ofstad wrote:
Jeff Cohen wrote:
The recent issues concern the head revision, post 1.9. As no one has ever submitted patches to fix 2005 problems with the 1.9 release, it is safe to say they still exist.
For the 1.5 release I submitted patches that made everything compile correctly with VS2005, I think there are some mails in the archives about the issues I ran into. I also submitted patches to make everything compile on x64 windows, but since there was no x64 backend at that point it could only produce 32-bit code. I think there are only small problems with new code that need to be fixed, but since my company doesn't use LLVM at the moment it's hard for me to justify spending time on it...m.
Even just mailing me a build log showing the problems would be a big help.
I just spent an hour to get the latest CVS version and compile it with VS2005 -- apart from a small problem with an outdated bison on my system I ran into a few problems. First of all there seems to be some dependency problem with Intrinsics.gen so the first time you build it has not been generated before the first time it's included. I suspect this is the same with VS2003 if you make a completely clean checkout from CVS and try to build. Second, the VS2005 compiler gives an error when compiling TargetInstrInfo.h:getPointerRegClass() (line 386) because the function doesn't return a value (it abort()s so it's not really a problem), just add this line at the end of the function:
return NULL; // Must return a value in order to compile with VS 2005
There's a ton of warnings, a few of which seem to be 'real' but most are just noise - I don't have time to go through them, but I can mail you the build logs if you're really interested.
Last there is an annoyance in that the FileParser.y custom build rule doesn't find the output, so it is run every time you build. This wouldn't be so bad if it was only this file, but it in turn causes Intrinsics.gen to be generated every time and this causes a lot of other files to be rebuilt. I hacked the dobison.cmd script so it never detects bison and always copies the .cvs files to get around the bison version problem, so I thought I had found the problem when I saw that the .output file from bison was entered as one of the outputs of the build step. But removing this from the outputs didn't help, it's still executing the custom build rule every time. The strange thing is it works fine for FileLexer.l.
Anyway, it was not too much trouble to get it going - I can check that it works again before the 2.0 release of LLVM if you remind me to...
m.
Morten Ofstad wrote:
I just spent an hour to get the latest CVS version and compile it with VS2005 -- apart from a small problem with an outdated bison on my system I ran into a few problems. First of all there seems to be some dependency problem with Intrinsics.gen so the first time you build it has not been generated before the first time it's included. I suspect this is the same with VS2003 if you make a completely clean checkout from CVS and try to build. Second, the VS2005 compiler gives an error when compiling
No, even with a completely clean checkout there are no problems with VS 2003. Most likely, VS 2005 make a mistake converting a project file. As I've seen every version of VS mess up the migration of the previous version's files, I bet this is what happened.
Your version of bison should work now. The newer versions have developed a bad habit of making semicolons optional.
TargetInstrInfo.h:getPointerRegClass() (line 386) because the function doesn't return a value (it abort()s so it's not really a problem), just add this line at the end of the function:
return NULL; // Must return a value in order to compile with VS 2005
Fixed. VS 2003 (and GCC) are smart enough to know abort() doesn't return. Looks like a bug introduced in VS 2005.
There's a ton of warnings, a few of which seem to be 'real' but most are just noise - I don't have time to go through them, but I can mail you the build logs if you're really interested.
Sure, mail it to me. Sometimes there's a real bug hiding in there. The vast bulk of the warnings are 32/64-bit portability warnings and are potentially real issues, especially when having LLVM cross-compile from one to the other (which is why I don't suppress them). GCC doesn't seem capable of detecting these, so nothing stops the vast majority of LLVM developers from introducing more of them.
Last there is an annoyance in that the FileParser.y custom build rule doesn't find the output, so it is run every time you build. This wouldn't be so bad if it was only this file, but it in turn causes Intrinsics.gen to be generated every time and this causes a lot of other files to be rebuilt. I hacked the dobison.cmd script so it never detects bison and always copies the .cvs files to get around the bison version problem, so I thought I had found the problem when I saw that the .output file from bison was entered as one of the outputs of the build step. But removing this from the outputs didn't help, it's still executing the custom build rule every time. The strange thing is it works fine for FileLexer.l.
Again, VS 2003 doesn't have this problem.
Anyway, it was not too much trouble to get it going - I can check that it works again before the 2.0 release of LLVM if you remind me to...
Thanks, that would be great