llvm dev - Oct 2013 - [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

On 27 October 2013 15:53, Chris Lattner <clattner at apple.com> wrote:
> I'm not sure what you mean.  Are your proposing that clang 3.4 use any
> features supported by clang 3.3?  If so, that won't work, because clang
> can't self-host on all interesting architectures, e.g. it isn't
fully ABI
> compatible with Visual C++ (yet).
>
No, not yet. Certainly not for 3.4!

My comment was more to the effect that we could use this as a target for
the future (and probably never achieve it), thus why "design
guideline" and
not a developer policy.

We'll have to make sure we can do it on all "interesting"
architectures
first (given all constraints).

--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131027/ed62cb4b/attachment.html>

On Sun, Oct 27, 2013 at 4:07 PM, Renato Golin <renato.golin at
linaro.org>wrote:
> On 27 October 2013 15:53, Chris Lattner <clattner at apple.com>
wrote:
>
>> I'm not sure what you mean.  Are your proposing that clang 3.4 use
any
>> features supported by clang 3.3?  If so, that won't work, because
clang
>> can't self-host on all interesting architectures, e.g. it isn't
fully ABI
>> compatible with Visual C++ (yet).
>>
>
> No, not yet. Certainly not for 3.4!
>
> My comment was more to the effect that we could use this as a target for
> the future (and probably never achieve it), thus why "design
guideline" and
> not a developer policy.
>
> We'll have to make sure we can do it on all "interesting"
architectures
> first (given all constraints).
>
I think that just establishing a floor on the problem (a soft one, which
naturally has to be interpreted based on the realities at the time) is the
best first step. I *don't* want to lose the ability to host LLVM and Clang
with reasonably modern C++ toolchains that are not Clang-derived. I *do*
want to set expectations with clear guidelines for what we consider
"reasonably modern" to be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131027/6db7c420/attachment.html>

On 27 October 2013 21:13, Chandler Carruth <chandlerc at google.com>
wrote:
> I think that just establishing a floor on the problem (a soft one, which
> naturally has to be interpreted based on the realities at the time) is the
> best first step. I *don't* want to lose the ability to host LLVM and
Clang
> with reasonably modern C++ toolchains that are not Clang-derived. I *do*
> want to set expectations with clear guidelines for what we consider
> "reasonably modern" to be.
>
I couldn't agree more.

My jump the gun moment was due to the fact that I always estimate
minimum/expected/maximum outcomes, to make sure they follow a nice linear
scale with respect to features/work/cost/time. Having the "previous
support" as standard would be a maximum, in a world where Clang/LLVM is the
de-facto standard on all platforms. It'll never happen, but it's a
direction that would bring nice surrounding improvements if pursued.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131027/e2caa1d5/attachment.html>