On Wed, 2004-09-15 at 00:17, Paolo Invernizzi wrote:> On Sep 15, 2004, at 8:40 AM, Henrik Bach wrote: > > > Hi, > > > > Has some one committed these patches into CVS? > > Not yet... checked 10 minutes ago...Hopefully Chris will get to it today (Wednesday).> I'm attaching the cvs diff -u version of them (I've read Reid Spencer > post about it) >Thanks!> > Paolo, thanks for the patches. In the near future I'll try to compile > > them. > > > > I've installed STLport 6.4.2 with vc6. > > May I suggest you to use a newer version of the compiler? VC6 is not > so compliant to the C++ standard as VC7 and above. > You can also download for free a version of VC.NET 2005 beta, as I've > noted that in LLVM code there's a reference to its runtime library, > meaning that someone else has worked with it over LLVM...Yes, in fact I'd be daring enough to suggest that it be the standard. We'll have fewer compilation problems with VC++ 2005 because it is (supposedly) more standards compliant than previous versions. Please use this download: http://lab.msdn.microsoft.com/express/visualc/default.aspx There is also an update, as of 9/10/2004: http://www.microsoft.com/downloads/details.aspx?FamilyID=afd04ff1-9d16-439a-9a5e-e13eb0341923&DisplayLang=en This is the compiler I will use for the Win32 port (when I get to it).> > <gossip> I've read that an MSIL front-end for LLVM is being > developed... </gossip>This was started by Chris while he was at MS but the work he did there is proprietary to MS. So, you won't see that happen any time soon. However, Chris was able to determine that doing an MSIL->LLVM translator shouldn't be difficult. Reid -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040915/4cb9d3a6/attachment.sig>
On Wed, 15 Sep 2004 07:39:23 -0700 Reid Spencer <reid at x10sys.com> wrote:> Yes, in fact I'd be daring enough to suggest that it be the standard. > We'll have fewer compilation problems with VC++ 2005 because it is > (supposedly) more standards compliant than previous versions. Please use > this download:While this may be true, it's not a realistic request. Even among commercial developers with MSDN subscriptions, it is common to delay upgrading to the lastest VC++ for a year or two or even three. I've personally been involved with two such upgrades, from 5 to 6 and 6 to 7.1 and it's a pain. The project files are not converted correctly. Code that compiled before no longer does. Code that does compile no longer runs correctly. You depend on some third-party library that hasn't itself upgraded to the latest VC++ (still a problem with 7.1). And don't even think of doing this near the end of a release cycle for your product. The mere thought of using a /beta/ version of a Microsoft product... And for those without an MSDN subscription, the cost of purchasing the latest Visual Studio is enough disincentive. If the LLVM code base doesn't want to compile with VC++ 6 because it's not sufficiently ANSI compliant, that's a good enough reason to not support it. I know that template support wasn't very compliant with 6 (though still better than most non-g++ Unix compilers even today) and LLVM uses templates a lot. While 6 is still common, by now most are switching to 7.1. As it seems to work well enough with 7.1, I don't think standardizing on an unreleased version that won't become dominant for four years or so is constructive. And that assumes it actually ships in 2005 :)
On Wed, 15 Sep 2004, Jeff Cohen wrote:> If the LLVM code base doesn't want to compile with VC++ 6 because it's > not sufficiently ANSI compliant, that's a good enough reason to not > support it. I know that template support wasn't very compliant with 6 > (though still better than most non-g++ Unix compilers even today) and > LLVM uses templates a lot. While 6 is still common, by now most are > switching to 7.1. As it seems to work well enough with 7.1, I don't > think standardizing on an unreleased version that won't become dominant > for four years or so is constructive. And that assumes it actually > ships in 2005 :)I agree to some extent. Basically it depends on how close 7.1 is to compiling the LLVM tree today. If supporting 7.1 will require making lots of ugly changes to the source base to support 7.1 (due to lack of compliance with the C++ standard), then it may be reasonable to require 8.0 if it fixes the problems. If there are only minor things that 7.1 gets wrong, and they aren't very invasive, I agree that it would be wonderful to support it. :) -Chris -- http://llvm.org/ http://nondot.org/sabre/
On Sep 15, 2004, at 5:58 PM, Jeff Cohen wrote:> While 6 is still common, by now most are > switching to 7.1. As it seems to work well enough with 7.1, I don't > think standardizing on an unreleased version that won't become dominant > for four years or so is constructive. And that assumes it actually > ships in 2005 :)I agree. I think that 7.1 is the right way to go, I suggested 8 only because right now It's possible to download it freely from MS, and I think that is not soo different from 7.1 --- Paolo Invernizzi
On Wed, 2004-09-15 at 08:58, Jeff Cohen wrote:> On Wed, 15 Sep 2004 07:39:23 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > Yes, in fact I'd be daring enough to suggest that it be the standard. > > We'll have fewer compilation problems with VC++ 2005 because it is > > (supposedly) more standards compliant than previous versions. Please use > > this download: > > While this may be true, it's not a realistic request. Even among > commercial developers with MSDN subscriptions, it is common to delay > upgrading to the lastest VC++ for a year or two or even three.This doesn't affect LLVm because nobody ever tried compiling this with older VC++ versions. I'm advocating the latest so that we have fewer "upgrade" problems going forward.> I've > personally been involved with two such upgrades, from 5 to 6 and 6 to > 7.1 and it's a pain.I sympathize, that's why I'm trying to push the compiler version as far forward as possible to avoid pain later on.> The project files are not converted correctly.We won't use VC++ project files. You'll still have to compile with cygwin tools. There's just too many other dependencies (flex, bison, awk, sed, grep, gmake) ..> Code that compiled before no longer does. Code that does compile no > longer runs correctly. You depend on some third-party library that > hasn't itself upgraded to the latest VC++ (still a problem with 7.1).Again, while I can sympathize, this problem doesn't affect LLVM because we have no legacy of compiling on Win32.> And don't even think of doing this near the end of a release cycle for > your product. The mere thought of using a /beta/ version of a Microsoft > product...Yes, this is more of a concern to me. That's why I suggested using the update as well. While we'll be bleeding edge for a while, eventually VC++ 8 will be released and its SP1 will make it actually work correctly. If we start adjusting for its quirks now, we can (hopefully) have something reasonably stable by the time lots of Win32 people start using LLVM.> > And for those without an MSDN subscription, the cost of purchasing the > latest Visual Studio is enough disincentive.Another reason why I suggested the free download alternative ;>> If the LLVM code base doesn't want to compile with VC++ 6 because it's > not sufficiently ANSI compliant, that's a good enough reason to not > support it.That's exactly the reason.> I know that template support wasn't very compliant with 6 > (though still better than most non-g++ Unix compilers even today) and > LLVM uses templates a lot. While 6 is still common, by now most are > switching to 7.1. As it seems to work well enough with 7.1, I don't > think standardizing on an unreleased version that won't become dominant > for four years or so is constructive. And that assumes it actually > ships in 2005 :)I agree there's some risk and I think we should make our attempt to have it compile with VC++ 7.1 (thanks Paolo!). However, LLVM requires a standards compliant compiler. If 7.1 isn't up to the task, then we can't use it. So far, the changes needed in LLVM have been minor so it hasn't been a problem. However, we're not going to bastardize the code base just to support a compiler that isn't up to snuff. I think you're right that "standardization" on the VC 8 compiler is somewhat risky. We should continue the 7.1 effort while also using 8(beta) and when 8 is ready, then it should become the standard for windows (assuming it actually implements the C++ standard correctly!) Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040915/10c30e44/attachment.sig>