search for: whidbey

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...

...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 h...

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. I do not have 2003. 2005 is much stricter than 2003 and...

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...

...dex.log -rw------- 1 testuser users 28 Aug 9 11:39 dovecot.list.index.uidmap drwx------ 5 testuser users 4096 Aug 9 11:02 .Junk -rw------- 1 testuser users 0 Aug 9 10:59 maildirfolder drwx------ 2 testuser users 4096 Aug 9 10:59 new -rw------- 1 testuser users 0 Aug 9 11:04 temp.mail4.whidbey.net.8596.7b344a891b2c6691 -rw------- 1 testuser users 0 Aug 9 11:32 temp.mail4.whidbey.net.8761.bfe04f5457e4ba7e -rw------- 1 testuser users 0 Aug 9 11:33 temp.mail4.whidbey.net.8765.44e803d87275348a -rw------- 1 testuser users 0 Aug 9 11:37 temp.mail4.whidbey.net.9031.f4a972591af59e...

...ze 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 ab...

.... it's bad enough they keep breaking backwards compatibility, but what's much worse is that the upgrade is never 100% correct. Builds are broken in subtle and hard to track down ways. It's why VS upgrades get put off for as long as possible. I won't even think of upgrading to Whidbey until several years after its release. _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev _________________________________________________________________ Del din ve...

...mdev at cs.uiuc.edu > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Visual C++ Toolkit > > On Thu, 8 Jul 2004, Vladimir Prus wrote: > > > Sorry, but it is not even close to working (its template and STL support > > > is horribly lacking). The Visual Studio "Whidbey" compiler, now in beta, > > > will handle it though with only a reasonable amount of tweaking to the > > > LLVM sources. I have no idea about when Microsoft intends to release it > > > though, but I would guess that it will be sometime soon. Google can > > &...

...-symlinked folders. We tried version 1.1 alpha2, which actually crashes in this scenario. The only fix we've found is to disable "lazy_expunge". Attached is our "dovecot -n" config. Anyone have an idea what might be causing this or a workaround? Thanks! Rich richs at whidbey.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dovecot-config.txt URL: <http://dovecot.org/pipermail/dovecot/attachments/20070829/5a676a3f/attachment-0002.txt>

...t; even when INTERNALDATE is specified. Since "BODY.PEEK" is being called anyway, our tests didn't reveal any performance impact. Can anyone think of a scenario this would negatively impact? Another option might be to patch the APPEND function? Thanks! Rich Sandberg richs at whidbey.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: outlook-dates.txt URL: <http://dovecot.org/pipermail/dovecot/attachments/20060427/73492efe/attachment.txt> -------------- next part --------------

...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 amazed at the amount of commercial Windows software development that still uses VC++ 6.0 even today. And that's with 7.1 offering real advantages to C++ programmers over 7.0, which itself had real advantages over 6.0. I've yet to see anything for...

...ooked 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 Visual Studio "Whidbey" compiler, now in beta, > will handle it though with only a reasonable amount of tweaking to the > LLVM sources. I have no idea about when Microsoft intends to release it > though, but I would guess that it will be sometime soon. Google can > probably tell you :) Chris, I think...

...it's bad enough they keep breaking backwards compatibility, but what's much worse is that the upgrade is never 100% correct. Builds are broken in subtle and hard to track down ways. It's why VS upgrades get put off for as long as possible. I won't even think of upgrading to Whidbey until several years after its release.

...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 amazed at the amount of commercial Windows software development that still uses VC++ 6.0 even today. And that's with 7.1 offering real advantages to C++ programmers over 7.0, which itself had real advantages over 6.0. I've yet to see anything for u...

...ted 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 Visual Studio "Whidbey" compiler, now in beta, will handle it though with only a reasonable amount of tweaking to the LLVM sources. I have no idea about when Microsoft intends to release it though, but I would guess that it will be sometime soon. Google can probably tell you :) -Chris -- http://llvm.cs.uiuc.ed...

...h they keep breaking backwards compatibility, > but what's much worse is that the upgrade is never 100% correct. Builds > are broken in subtle and hard to track down ways. It's why VS upgrades > get put off for as long as possible. I won't even think of upgrading to > Whidbey until several years after its release. Hopefully you won't have to. By then LLVM and XPS should be a suitable replacement :) Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a...

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

On Thu, 8 Jul 2004, Vladimir Prus wrote: > > Sorry, but it is not even close to working (its template and STL support > > is horribly lacking). The Visual Studio "Whidbey" compiler, now in beta, > > will handle it though with only a reasonable amount of tweaking to the > > LLVM sources. I have no idea about when Microsoft intends to release it > > though, but I would guess that it will be sometime soon. Google can > > probably tell yo...

----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 everyone. I can't get mail.app to report back correct quota information using mail.app and dovecot (though it works with courier-imap). I am looking at migrating away from courier-imap to dovecot but this issue is something I need to have resolved <somehow>. Thunderbird is fine and reports back good info on either connection. I am off to read RFCs (can't I just read the