similar to: [LLVMdev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

On Oct 27, 2013, at 12:07 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Chris Lattner <clattner at apple.com> writes: > >>> One short term caveat: Windows is special. > > s/Windows/Visual Studio. > > MinGW has the latest and greatest gcc. > >> I don't see how it is special. > > It is special, sadly, and I'm not talking about C++11

On Sun, Oct 27, 2013 at 5:09 PM, Chris Lattner <clattner at apple.com> wrote: > On Oct 27, 2013, at 12:07 PM, Óscar Fuentes <ofv at wanadoo.es> wrote: >> Chris Lattner <clattner at apple.com> writes: >> >>>> One short term caveat: Windows is special. >> >> s/Windows/Visual Studio. >> >> MinGW has the latest and greatest gcc.

On Mon, Oct 28, 2013 at 9:00 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Dix Lorenz <lists at dix-lorenz.de> writes: > > > I might be mistaken, but to compile for WinXP on VS 2012 you have to > > switch the Platform Toolset and AFAICT that means it will essentially > > be using the VS 2010 compiler and libraries. > > That was how VS 2012 worked at

Here is a table detailing C++11 features support for Visual C++ 2010, 2012, 2013 http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx Specifically, range-based for loops are supported in Visual C++ 2012, 2013 but not in 2010. Yaron 2013/10/28 David Tweed <david.tweed at gmail.com> > On Mon, Oct 28, 2013 at 9:00 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: >

>> It is special, sadly, and I'm not talking about C++11 support only, but >> about the policies MS follows which too often makes very inconvenient >> (or even impossible) to upgrade to newer VS versions. The latest example >> that comes to mind was the release of VS2012: they removed Windows XP >> support, as if upgrading the OS is a non-issue if you ask for it

On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <chandlerc at google.com> wrote: > Greetings, > > This has been discussed many times, and there are a lot of pro's and con's on each side, but increasingly I think the project needs to draw a line in the sand and put in place long-term policies around support for building LLVM & Clang with older C++ toolchains. It also

> On Aug 22, 2014, at 9:53 AM, Daniel Dilts <diltsman at gmail.com> wrote: > > On Fri, Aug 22, 2014 at 9:42 AM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > Starting a new thread to loop in cfe-dev and lldb-dev. For those not following along there has been a thread on llvm-dev about moving the minimum required Visual Studio version to

On Sun, Oct 27, 2013 at 11:18 AM, Chris Lattner <clattner at apple.com> wrote: > On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <chandlerc at google.com> > wrote:> Concrete long term proposal: > > > > We support building with C++ toolchains which were released and widely > available on their respective target platforms at least 2 years prior to > the next

I guess what I'm getting at, is why do we even need to support 2 toolchains with LLVM *at all*? Why can't we just always upgrade to the newest one unless there are serious issues with it? There used to be two reasons that I'm aware of: 1) Licensing. Community used to be Express, and Express used to be limited in functionality. But this is no longer the case. Community is fine for

"Unfortunately, that does appear to be the case. I think MSVC 2010 is a reasonable requirement, but it seems like 2012 is the real target for C++11 features." Bah, they can install Mingw binaries. Marcus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130110/eb78b89f/attachment.html>

On 10/28/13 11:45 AM, Dix Lorenz wrote: > On 27.10.2013, at 20:07, Óscar Fuentes <ofv at wanadoo.es> wrote: > >> Chris Lattner <clattner at apple.com> writes: >> >>>> One short term caveat: Windows is special. >> s/Windows/Visual Studio. >> >> MinGW has the latest and greatest gcc. >> >>> I don't see how it is special.

"Daniels, Marcus G" <mdaniels at lanl.gov> writes: >> "Unfortunately, that does appear to be the case. I think MSVC 2010 is >> a reasonable requirement, but it seems like 2012 is the real target >> for C++11 features." IMO, the only meaty C++11 feature that VS2012 adds over VS2010 is range-based for-loops. > Bah, they can install Mingw binaries.

On Fri, Aug 22, 2014 at 8:58 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 22 August 2014 13:43, Aaron Ballman <aaron at aaronballman.com> wrote: >> My opposition to this switch was the timing. When we researched "what >> minimum can we live with for C++11" nine months ago, we determined >> what versions would make sense, which included MSVC

On Mon, Aug 25, 2014 at 12:04 PM, Gao, Yunzhong <yunzhong_gao at playstation.sony.com> wrote: > Hi, > Sorry for the delay in responding, we have been discussing this internally > and have not had time to do a proper investigation. > >> We absolutely have to ship a set of DLLs that run hosted in VS2012. Is >> there any sort of runtime incompatibility that would happen

If we have no other major users who require VS 2012 support, I think it's reasonable to officially switch now. We might want to wait for 3.6 to go out the door, just to reduce possible issues with porting fixes, but that may be overly cautious. ~Aaron On Wed, Jan 28, 2015 at 7:16 AM, Greg Bedwell <gregbedwell at gmail.com> wrote: > This thread seems to have stalled again without

On Thu, Aug 21, 2014 at 4:35 PM, Chris Bieneman <beanz at apple.com> wrote: > This thread hasn’t had too much traffic, but it sounds like many people are > in favor and there is no strong opposition. If I understand Aaron’s only > objection was based on preserving existing policy rather than a technical > reason. > > Anyone want to make the official call? > > -Chris

>From this website: http://llvm.org/builds/ I've installed the LLVM toolchain on 2 Windows machines. One with Visual Studio 2012 and another with Visual Studio 2013. After installing the LLVM toolchain neither machine shows the LLVM option in the Visual Studio project properties pane where you can select which toolchain to use for the project. Am I missing a step somewhere? :) Thanks for

MSVC survives because there's no effective competition- it's like communications providers in the United States or political parties in China. The alternatives like GCC have no decent development environments for them, and Clang has the bonus of not being mature w.r.t. things like Standard libraries. The reality is, there's nowhere to go *but* MSVC. This stuff is the major reason why

I don't see how the policy of supporting 2 versions is related to that difficulty though. Whether we support 1 versions or 2 versions, 1 version is still going to be deprecated every time a new version is released. So this burden on upgrading buildbots doesn't seem to be much different. As long as chromium compiler version is not tied to llvm compiler version (and if it did, that would be

As the title suggests, what is the status of compiling llvm on versions of MSVC less than 2012? Not so much "Does it work?", but more like "Should any thought be given to whether or not something will break it?" Right now there are a bunch of warnings when compiling LLDB on Windows because it uses various symbols which have been defined since VS2012, but which are re-defined