- User Since
- Apr 18 2013, 6:48 AM (387 w, 3 d)
Thu, Sep 17
Cherry-picked to 11.x as b78e5de029c26c309f541ab883fa5d6d953b073d.
Cherry-picked to 11.x as 4fe4e35452ef17ce3db08b080e3b0642d36c5094.
Okay, cherry-picked to 11.x as 80e2fc1e6e68d6ed57dccc03c6a5121e216bfd43.
Wed, Sep 16
Pushed to 11.x as 4a26e3b33798424dc5a4843f7b29a617bef81656.
Cherry-picked to the branch as 8f2c29681ce768afb739b6cf5ccca81dd87d5326.
Tue, Sep 15
Nice! I tried this out, and it appears to work.
Sadly after this commit, I'm no longer able to build the Flang docs, my build failing like this:
I see it now. Thanks!
I think it would be safer to do the change purely as an optimization in codegen (maybe we could add a new helper method that could also be used by the warning).
For "optimization in codegen", do you mean optimization after the IR is generated or like I did in CodeGenFunction::EmitCXXTypeidExpr?
This seems to have caused https://bugs.llvm.org/show_bug.cgi?id=47512
No worries :) Thanks for the notes!
Please go ahead and commit to the branch.
Please go ahead and commit.
lgtm please commit so this makes it into the release.
This has probably had enough time for review. Please commit.
Mon, Sep 14
@hans - Does that sound right to you?
Added target condition.
Fri, Sep 11
This is new functionality, so I don't think we should merge it so late in the release process.
Thu, Sep 10
Cherrty-picked the revert to 11.x as 8ae3293030d9691ebe0006b79cec1b06bb8015cf
https://reviews.llvm.org/D87471 makes building with snmalloc work for me, both with msvc and clang-cl.
I've been trying to use this, but not with much luck so far.
I'm not sure that changing isPotentiallyEvaluated() is the right thing to do. The meaning of that corresponds to text in the standard: https://eel.is/c++draft/expr.typeid#3 so changing it to something that doesn't match the standard exactly seems wrong.
Wed, Sep 9
Alok, Adrian: please work on addressing the concerns raised in https://bugs.llvm.org/show_bug.cgi?id=47287, or please revert this change.
Tue, Sep 8
Mon, Sep 7
But please add a -triple parameter to the test files, and check the dynamic_cast<void*> behavior in each case before committing.
Pushed to 11.x as 8399522c96a94bfb7c1cbf4df2bed0b3d826fbf6. Please let me know if there any follow-ups.
Thu, Sep 3
Okay, almost there..
Wed, Sep 2
Seems reasonable to me. Just some nits.
Looks great, thanks!
Tue, Sep 1
Okay, adding it to clang-cl seems fine to me. But I think it could be a simple alias?
Mon, Aug 31
Would it be enough for users to specify /clang:-mtune instead? How does icc spell its option?
Pushed to 11.x as 7166d2653be30b18d87a112ca99ae706dd998ba2
Cherry-picked to 11.x as defbc77a7c951d8cc47daf49df15c7f548cada05.
I tried building the Flang docs with this applied, and they build fine, but show up empty in my web browser.
Fri, Aug 28
This seems to have broken 32-bit builds for me. In an x86 VS 2019 prompt:
Are you still ok with the revised version? It was prompted by a question in Bug 47304 which showed that I'd missed some cases before.
Pushed to 11.x as ba3413982cbd7a5b5aeaf2ea34e0a91d5561202d. Please let me know if there are any follow-ups.
Pushed to 11.x as b931e22c954374acf75c4f1d1f2666f3f8e67470. Please let me know if there are any follow-ups.
Thu, Aug 27
Feels like a hack, but I'm not strongly opposed either.
Cherry-picked to 11.x as 522d80ab553b42e2feadfd4178932069dfc51d3f.
Thanks for the update! I'm excited to get this in.
Wed, Aug 26
but we can merge this right away (IMHO)
It is up to Hans if he has some time. But I think I covered almost all new features (+ complex for NVPTX), so after the update it can be merged with 11.x release.
Tue, Aug 25
Should this be mentioned in the release notes?
Would you like to add a mention of this in the lld release notes?
Would you like to add a mention of this in docs/ReleaseNotes.rst? Thanks.
Should this be mentioned in the release notes for llvm 11? Please send a patch :-)
I'll land tomorrow unless Alexandre beats me to it.
Pushed to 11.x as 4d16d8dfe50eb45545e844c3c9acafd363637dad
Seems reasonable to me.
Lucas, this seems to have casued https://bugs.llvm.org/show_bug.cgi?id=47001. Can you take a look? (I would cc you on the bug, but I couldn't find your email in bugzilla.)
I'm curious about the background here, though. When would lld::coff::link be called successively? Could we have a test for this?
D70378 covers all this, at least for the COFF driver.