- User Since
- Apr 30 2013, 5:34 PM (233 w, 21 h)
Wed, Oct 11
Mon, Oct 2
Sun, Oct 1
Thu, Sep 28
Wed, Sep 27
Ideally, I think all the headers would hide the method behind #ifdef LLVM_ENABLE_DUMP , so that it wouldn't be a linker failure but a compile time failure!
Thanks for fixing this :)
Tue, Sep 26
Can you elaborate why this script is desirable/needed?
Mon, Sep 18
Sep 17 2017
Did you check ld64 in Xcode 9? I think ld64 was fixed to append the suffix as well.
Sep 4 2017
Sep 1 2017
Aug 31 2017
Aug 28 2017
I don't mind where you install it, but we can also assume that someone who use this Dockerfile intends to use clang, so why not adding it to to update-alternatives as well, and even making it default for /usr/bin/c++ and /usr/bin/cc?
Aug 27 2017
I'd like to also see a testcase for the situation where we trigger the emission of a declaration with an available_externally definition and then find we need to promote it to a "full" definition:
Aug 25 2017
Aug 24 2017
Would this be all obsolete with git repos?
Aug 20 2017
Aug 17 2017
Bi-weekly ping! (@rsmith)
Aug 14 2017
Seems fine to me. Adding @dexonsmith (I don't know who maintain libc++ at Apple right now)
Aug 9 2017
Is this something that is affecting clang-5.0 backward compatibility with clang-4.0?
(adding @hansw for visibility)
Aug 8 2017
Aug 7 2017
Aug 5 2017
Aug 4 2017
Address Richard's comment
Aug 3 2017
I'll leave the final approval to Teresa.
When the working set size is determined to be huge, disable peeling to avoid bloating the working set further.
Ping again @rsmith (or anyone else)
Aug 2 2017
Jul 31 2017
Jul 30 2017
It seems to me to conceptually belong to the backend. Why isn't this part of CodeGenPrepare (or injected by the target as part of its pre-ISel IR passes)?
Jul 26 2017
Jul 25 2017
they had to be emitted linkonce_odr in all the destination modules (even if they weren't used by an alias) rather than as available_externally - causing extra object size.
Jul 24 2017
Weekly ping! (@rsmith)
Here is the current output:
Jul 21 2017
Jul 20 2017
Thanks, that's a very good start! Few comments inline, I didn't understand everything.
Thanks, I'm glad to see this coming!
Oh great you just committed :) We were on the same line! I just wanted to make sure you were not waiting for me. Thanks.
Note: I approved in the first place because my comment was so minor that you could fix it (or not) and move on with committing directly without another round of review.
Jul 17 2017
@rsmith: post-C++-commitee-meeting ping ;)
Jul 14 2017
Jul 13 2017
Thanks, very clear :)
Teresa: can you describe a bit more how we end up importing two summaries for the same GUID? I would expect that after importing one, we don't even come to try to import another since we already have one.
Jul 12 2017
Jul 11 2017
With @sanjoy approval of langref, LGTM.
Jul 10 2017
Jul 9 2017
Missing test showing the import happening on critical and not without. Right now the test you provided only shows that the "critical" flag is encoded in the binary. The change in the function importer is not tested, unless I missed something.
The context and the motivation is *still* not clear to me. To begin why do we need the *names* when doing the thin link?
As Teresa mentioned, please abandon this revision and recreate a new one.
Fix issues around mutable fields and regression on "internal", add more testing.
When we used an std::map originally it was because we needed the ordering. Have you checked that we don't iterate on any instance of this map?