llvm dev - Aug 2014 - [LLVMdev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk

> 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 2013. The motivating reason is this will allow
us to take advantage of a bunch of C++11 features that are not supported by MSVC
2012.
> 
> Is there an existing policy on how supported compiler versions are
selected?
There was a discussion last year
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html
<http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html>) WRT
allowing LLVM to use C++11 features which established a precedent of supporting
compilers released back for two years, with a special caveat for Windows.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/6259bcbf/attachment.html>

On Fri, Aug 22, 2014 at 9:58 AM, Chris Bieneman <beanz at apple.com>
wrote:
>
> 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>
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 2013. The motivating reason
is
>> this will allow us to take advantage of a bunch of C++11 features that
are
>> not supported by MSVC 2012.
>>
>
> Is there an existing policy on how supported compiler versions are
> selected?
>
>
> There was a discussion last year (
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html) WRT
> allowing LLVM to use C++11 features which established a precedent of
> supporting compilers released back for two years, with a special caveat for
> Windows.
>
> -Chris
>
>From the link:
*we support building with the **most recent 2 versions of VS available at
the *prior* release. For example** when we branch for 3.4, the two versions
will be 2012 and 2013. Those two** would be supported on mainline from then
through 3.5, and when we branch** for 3.5 we would re-evaluate. *


If that is followed exactly support for VS2012 would not be able to be
dropped.  However, it is rather easy to get the latest VC++ compiler from
Microsoft at no cost (Express edition anybody?), so I don't have any real
concern with dropping support for VS2012.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/e13fd439/attachment.html>

Officially, the latest two major versions- so MSVC 2012 and 2013.

The main issue I'd see here is that all of those features are relatively
untested- for example, in VS 14 CTP3 they had to introduce a new error to
explicitly break all the cases where the compiler silently did totally the
wrong thing. The ones that were included in VS2012 CTP are not quite as
bad. But the reality of using VS2013 is not that all of these features will
suddenly be available to use- there's a lot of compiler issues that would
need to be worked around, including some
silently-generates-totally-the-wrong-code bugs. They can also report
totally incorrect errors- e.g. reporting errors that have nothing to do
with the real error, in totally the wrong location, or both.

Seeing the feature list seems compelling, but MSVC's actual support is
often still below the standard you can find in GCC or Clang, even in
officially supported features. There's a price to be paid not just in terms
of breaking users who are still VS2012-dependent, but also in terms of
debugging VS2013-only bugs.

Personally, I think that it's worth upping the minimum requirement whenever
you're not breaking a substantial portion of your userbase. All I'm
saying
is, the experience of many of us using VS2013 is that that feature list is
a little ... optimistic. Upgrading on that basis alone may well yield
undesirable results.

Perhaps it would be better to consider a fork, where the new features are
employed, and then if it doesn't introduce new bugs, it could be merged.
This would also give more time for people to report in with a VS2012
dependency.

On 22 August 2014 17:58, Chris Bieneman <beanz at apple.com> wrote:
>
> 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>
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 2013. The motivating reason
is
>> this will allow us to take advantage of a bunch of C++11 features that
are
>> not supported by MSVC 2012.
>>
>
> Is there an existing policy on how supported compiler versions are
> selected?
>
>
> There was a discussion last year (
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html) WRT
> allowing LLVM to use C++11 features which established a precedent of
> supporting compilers released back for two years, with a special caveat for
> Windows.
>
> -Chris
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/e0dc72ec/attachment.html>

> On Aug 22, 2014, at 10:09 AM, Daniel Dilts <diltsman at gmail.com>
wrote:
> 
> 
> 
> 
> On Fri, Aug 22, 2014 at 9:58 AM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
> 
>> On Aug 22, 2014, at 9:53 AM, Daniel Dilts <diltsman at gmail.com
<mailto: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 2013. The motivating reason is this will allow
us to take advantage of a bunch of C++11 features that are not supported by MSVC
2012.
>> 
>> Is there an existing policy on how supported compiler versions are
selected?
> 
> There was a discussion last year
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html
<http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066847.html>) WRT
allowing LLVM to use C++11 features which established a precedent of supporting
compilers released back for two years, with a special caveat for Windows.
> 
> -Chris
> 
> From the link:
> we support building with the most recent 2 versions of VS available at the
*prior* release. For example when we branch for 3.4, the two versions will be
2012 and 2013. Those two would be supported on mainline from then through 3.5,
and when we branch for 3.5 we would re-evaluate.
> 
> 
> If that is followed exactly support for VS2012 would not be able to be
dropped.  However, it is rather easy to get the latest VC++ compiler from
Microsoft at no cost (Express edition anybody?), so I don't have any real
concern with dropping support for VS2012.
> 

Also from that link:

One short term caveat: Windows is special.

I don't think we should follow the 2-year rule for Windows. It really is
special for at least three reasons:
1) We can't bootstrap on Windows. While there is tons of exciting work
going on here to change that, even then the quality of Windows support is
likely to change very rapidly.
2) Visual Studio's C++ support moved very slowly for a long time, and is
now improving at an amazing rate. We shouldn't be hampered by past problems
and should take advantage of this recent progress.
3) We have less insight into when new versions of the MSVC++ toolchain
will arrive.

I feel it is also worth recognizing that by the time we branch for 3.6 the two
most recent versions of Visual Studio will probably be 2013 and 14, so we’re
really only proposing moving forward a few months early.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140822/ee2ac882/attachment.html>

On 22 August 2014 20:18, Óscar Fuentes <ofv at wanadoo.es>
wrote:
> I second this. My experience with VS is that new features are usually
> broken if you go beyond the simple cases. And the roadmaps have little
> credibility, based on a continuous flow of disappointments since...
> forever.
Is there any interest from Microsoft to actually fix those problems,
or is that their policy that what's there is there? The latter seems
to be their policy on other products, and for what I know, VS too. I
ask that because holding on partial and broken support that will never
be fixed or completed is kind of backwards.

I'm not a Windows guy, but I wonder why so many people use MSVC if the
support is so patchy and hopeless as most people seem to imply. Also,
compiling Clang with MSVC and making Clang MSVC compatible are two
completely different things. A commercial toolchain based on MSVC
compatibility doesn't necessarily need to be compiled with MSVC
itself.

Or maybe the Windows environment is so alien that I'm basing my points
on completely unreasonable assumptions...

cheers,
-renato

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'd positively love clang-cl. As soon as that
is done, then support for cl can probably be entirely dropped and the state
of the available compilers will be drastically improved.

Microsoft *is* issuing more and more out-of-band bugfix updates. But the
current state for VS2013 is still that most bugfixes will hit in VS
"14"
(currently projected for 2015).


On 23 August 2014 21:24, Renato Golin <renato.golin at linaro.org> wrote:
> On 22 August 2014 20:18, Óscar Fuentes <ofv at wanadoo.es> wrote:
> > I second this. My experience with VS is that new features are usually
> > broken if you go beyond the simple cases. And the roadmaps have little
> > credibility, based on a continuous flow of disappointments since...
> > forever.
>
> Is there any interest from Microsoft to actually fix those problems,
> or is that their policy that what's there is there? The latter seems
> to be their policy on other products, and for what I know, VS too. I
> ask that because holding on partial and broken support that will never
> be fixed or completed is kind of backwards.
>
> I'm not a Windows guy, but I wonder why so many people use MSVC if the
> support is so patchy and hopeless as most people seem to imply. Also,
> compiling Clang with MSVC and making Clang MSVC compatible are two
> completely different things. A commercial toolchain based on MSVC
> compatibility doesn't necessarily need to be compiled with MSVC
> itself.
>
> Or maybe the Windows environment is so alien that I'm basing my points
> on completely unreasonable assumptions...
>
> cheers,
> -renato
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140823/d6d01697/attachment.html>

On Aug 23, 2014, at 1:24 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> 
> Also,
> compiling Clang with MSVC and making Clang MSVC compatible are two
> completely different things. A commercial toolchain based on MSVC
> compatibility doesn't necessarily need to be compiled with MSVC
> itself.
But it must. If you want to be able to use LLVM DLLs inside a Windows app, it
has to be built with MSVC because they have their own C++ ABI.  At some point,
Clang will support Microsoft's ABI well enough to consider a bootstrap
instead.

Alex

"Why do developers make such ridiculous statements about broken
tools?"

Richard, clang on Windows is not completely compatible with either mingw or
Visual C++ toolchains so it's not (yet! clang is improving all the time) a
practical alternative.

1) clang TLS is not compatible with mingw implementation emutls, so no
C++11 concurrency. (anyone know of a solution?)
2) clang does not produce debug information in Visual C++ format (except
for line infromation), so no debugging.

I'm not sure is SEH support is ready in clang.

 This leaves a C++ developer two main choices, the mingw toolchain or
the Visual
C++ one. I'm not choosing based on brouchures or blog posts. I do work with
both toolchains extensively. My preference for development work is working
around the C++ limitations of Visual C++ in exchange for developing under
Visual Studio IDE which I find most productive.

YMMV, please, I'm not trying to start a flame war.

Ideally, I'd like to see clang completely support Visual C++ ABI and
debugging info so we'll have the best solution, clang with Visual Studio
and integrated debugger.

Yaron



2014-08-24 4:49 GMT+03:00 Óscar Fuentes <ofv at wanadoo.es>:
> Alex Rosenberg <alexr at leftfield.org> writes:
>
> > On Aug 23, 2014, at 1:24 PM, Renato Golin <renato.golin at
linaro.org>
> wrote:
> >>
> >> Also,
> >> compiling Clang with MSVC and making Clang MSVC compatible are two
> >> completely different things. A commercial toolchain based on MSVC
> >> compatibility doesn't necessarily need to be compiled with
MSVC
> >> itself.
> >
> > But it must. If you want to be able to use LLVM DLLs inside a Windows
> > app, it has to be built with MSVC because they have their own C++ ABI.
>
> This is false. LLVM libraries can be used on C++ Windows applications
> just fine without using MSVC at all.
>
> > At some point, Clang will support Microsoft's ABI well enough to
> > consider a bootstrap instead.
>
> AFAIK Clang bootstraps on MinGW-w64.
>
> To go back on topic: C++ features advertised by MSVC as recently
> supported usually are too immature to be used on practice. So looking at
> a brochure is not enough when deciding what you gain when you upgrade
> your MSVC install.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140824/5798a24d/attachment.html>

On 24 August 2014 08:45, Yaron Keren <yaron.keren at gmail.com>
wrote:
> Ideally, I'd like to see clang completely support Visual C++ ABI and
> debugging info so we'll have the best solution, clang with Visual
Studio and
> integrated debugger.
Amidst all the flame, there's one truth coming out of it, and one that
we already have a firm opinion: following broken tools is not a wise
path. And by broken here, I don't mean MSVC, I mean GCC.

While there are many good things coming out of GCC at any moment in
time, not all that comes is gold, and we took the decision long ago to
not blindly follow what GCC does just because "bacon". I'd rather
not
do that with MSVC either.

In the same way that both GCC and MSVC are broken, Clang/LLVM is
*also* broken, and anyone following us, will have a hard time. I had
to do that myself at one time, and it wasn't pleasant. LLVM is a
mature library, Clang is a mature compiler, but we still don't have a
mature toolchain like both GCC and MSVC have on either Linux or
Windows and very likely not even on Darwin.

That all means two things:

1. We can't complain about others before having a working toolchain
that is stable, widely used and with a mission that isn't "work as a
replacement to <foo>".

2. We'll have to choose our path, which will probably not be the same
as any other toolchain exactly, and we have to stick to it.

The fact that we're sticking to rational decisions is finally changing
the source code of many lazy developers that thought that GCC was the
only option. A few examples are the Linux kernel, the Android system
and the Chromium browser. I'd love to see the same effort and
determination on the Windows side, as I hear many horror stories of
patchy support and people having nightmares about it. Though, I have
no idea where to start, as I haven't used Windows for almost two
decades.

I agree with Chandler, lets go back to the matter a hand. But the
result might be, from Alex's answer, that we can't do it just now.

My only point in this email is: shall we try harder? Shall we try to
liberate horrified users, like we're doing with the other toolchain?
:D

cheers,
--renato

On Aug 23, 2014, at 6:49 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> Alex Rosenberg <alexr at leftfield.org> writes:
> 
>> On Aug 23, 2014, at 1:24 PM, Renato Golin <renato.golin at
linaro.org> wrote:
>>> 
>>> Also,
>>> compiling Clang with MSVC and making Clang MSVC compatible are two
>>> completely different things. A commercial toolchain based on MSVC
>>> compatibility doesn't necessarily need to be compiled with MSVC
>>> itself.
>> 
>> But it must. If you want to be able to use LLVM DLLs inside a Windows
>> app, it has to be built with MSVC because they have their own C++ ABI.
> 
> This is false. LLVM libraries can be used on C++ Windows applications
> just fine without using MSVC at all.
If the main executable is built with MSVC's C++ ABI, then what are you going
to build LLVM with that even links? MinGW doesn't use the MSVC C++ ABI.
Clang-cl dosn't generate PDB data. The only available option is MSVC.
>> At some point, Clang will support Microsoft's ABI well enough to
>> consider a bootstrap instead.
> 
> AFAIK Clang bootstraps on MinGW-w64.
MinGW doesn't implement the same C++ ABI at all. It implements the Itanium
ABI like we use on every other platform.
> To go back on topic: C++ features advertised by MSVC as recently
> supported usually are too immature to be used on practice. So looking at
> a brochure is not enough when deciding what you gain when you upgrade
> your MSVC install.
Agreed. Let's get back to the original proposal, which was for us to abandon
our established policy and drop a version of MSVC that we support in order to
use variadic templates to rewrite cl::opt.

Alex

LLDB supports building with 2013 only. This has been the situation for 
some time now, so from our side I don't see any problems.


On 24/08/2014 15:58, Alex Rosenberg wrote:
> On Aug 23, 2014, at 6:49 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
>
>> Alex Rosenberg <alexr at leftfield.org> writes:
>>
>>> On Aug 23, 2014, at 1:24 PM, Renato Golin <renato.golin at
linaro.org> wrote:
>>>> Also,
>>>> compiling Clang with MSVC and making Clang MSVC compatible are
two
>>>> completely different things. A commercial toolchain based on
MSVC
>>>> compatibility doesn't necessarily need to be compiled with
MSVC
>>>> itself.
>>> But it must. If you want to be able to use LLVM DLLs inside a
Windows
>>> app, it has to be built with MSVC because they have their own C++
ABI.
>> This is false. LLVM libraries can be used on C++ Windows applications
>> just fine without using MSVC at all.
> If the main executable is built with MSVC's C++ ABI, then what are you
going to build LLVM with that even links? MinGW doesn't use the MSVC C++
ABI. Clang-cl dosn't generate PDB data. The only available option is MSVC.
>
>>> At some point, Clang will support Microsoft's ABI well enough
to
>>> consider a bootstrap instead.
>> AFAIK Clang bootstraps on MinGW-w64.
> MinGW doesn't implement the same C++ ABI at all. It implements the
Itanium ABI like we use on every other platform.
>
>> To go back on topic: C++ features advertised by MSVC as recently
>> supported usually are too immature to be used on practice. So looking
at
>> a brochure is not enough when deciding what you gain when you upgrade
>> your MSVC install.
> Agreed. Let's get back to the original proposal, which was for us to
abandon our established policy and drop a version of MSVC that we support in
order to use variadic templates to rewrite cl::opt.
>
> Alex
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
-- 
- Colin Riley
Games Technology Director

Codeplay Software Ltd
45 York Place, Edinburgh, EH1 3HP
Tel: 0131 466 0503
Fax: 0131 557 6600
Website: http://www.codeplay.com
Twitter: https://twitter.com/codeplaysoft