[llvm-dev] [RFC] migrating past C++11

[James Henderson via llvm-dev]

Just to mention that this fixed the issue I was seeing, thanks. +1 on
sorting out thecross-compile step to propagate flags. I could imagine there
being other flags that we are discarding and shouldn't be.

Now to find time to update both my Linux and Windows toolchains...

On Thu, 7 Feb 2019 at 21:07, JF Bastien via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> On Feb 7, 2019, at 12:59 PM, Shoaib Meenai <smeenai at fb.com> wrote:
>
> This was easy enough to fix, so I did so in r353463.
>
>
> Thanks, I agree this fixes an immediate issue but it still doesn’t fix the
> root cause: it sounds like this cross-compile setup loses flags that it
> shouldn’t be losing.
>
>
> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of JF
> Bastien via llvm-dev <llvm-dev at lists.llvm.org>
> *Reply-To: *JF Bastien <jfbastien at apple.com>
> *Date: *Thursday, February 7, 2019 at 12:30 PM
> *To: *"paul.robinson at sony.com" <paul.robinson at sony.com>
> *Cc: *"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
> *Subject: *Re: [llvm-dev] [RFC] migrating past C++11
>
>
>
>
> On Feb 7, 2019, at 11:01 AM, paul.robinson at sony.com wrote:
>
> It seems the CMake changes have landed; but the docs are still a bit out
> of date?
> CMake.html talks about LLVM_FORCE_USE_OLD_TOOLCHAIN but not
> LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN.
>
> I’m. Not sure how one updates the website’s docs, I had assumed the RST
> files would automatically get rebuilt and pushed? Agreed we want it fixed,
> but I don’t think it’s good reason to revert since the error message is
> pretty clear.
>
> Huh. I also thought  the website was kept up to date automagically, which
> is why I looked at the website not the source; but the source does have the
> new option.  Never mind…
>
> Also, it looks like LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN is not propagated
> down to the NATIVE configuration when you set LLVM_OPTIMIZED_TABLEGEN.  If
> that's going to be a permanent deficiency, it should be mentioned in the
> docs as well.
>
> Someone mentioned MSVC was having issues that way?
> https://reviews.llvm.org/rL353374#624722
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_rL353374-23624722&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=jXkuL7NOOygyZEXTmkYhOIbDwj1UhwVNfH8WnSmowIA&s=UT6L9JA4kVtR0MRecFgpu3lQ6GkA1YKsZmhJshQ0Ynw&e=>
> That seems like general badness in the way that configuration is set up,
> no? It should probably get fixed separately
>
> "Somebody else ought to get around to fixing that someday so why bother
> documenting something that might eventually change" does not seem like a
> very robust argument.  I've answered a pile of questions from newcomers
> lately, I would prefer that people not add new reasons for the
> documentation to lie about how things work currently.  Or more accurately,
> don't work, because you can't currently use both those options at once.
>
> If someone does change how the optimized-tablegen feature works (or
> eliminates it entirely), surely they would be able to update the
> documentation accordingly?
> So, please fix.
>
>
> Can you clarify what you’re asking for exactly, and who you’re asking it
> from?
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190208/34c99e7a/attachment.html>