- User Since
- Apr 30 2013, 5:34 PM (312 w, 1 d)
Wed, Apr 17
Thu, Apr 11
Mon, Apr 8
Tue, Mar 26
Looks great! Thanks.
Mar 21 2019
Mar 12 2019
Mar 11 2019
Mar 9 2019
Feb 25 2019
Feb 24 2019
Feb 19 2019
LGTM, but you should probably wait to hear from someone else as well
Is it expected that the test output is sensitive to reverse iteration?
It sounds to me more like an issue with the code than with how the test is expressed.
Feb 13 2019
Feb 12 2019
What is the motivation to change this now?
Feb 6 2019
Could we sanitize the list of LLVM_ENABLE_PROJECTS and error for unknown entries?
Feb 5 2019
@dexonsmith: I'm not sure why a new differential should be created? I updated reviewers in this one.
Feb 2 2019
Thanks for fixing this!
Jan 30 2019
Jan 29 2019
You can avoid the git status pollution by adding the build directory to .git/info/exclude.
Jan 28 2019
LGTM, but for one comment that requires a fix I believe (lld on Windows)
Jan 27 2019
Jan 26 2019
Jan 24 2019
Jan 18 2019
Jan 16 2019
Jan 15 2019
I don't want to give the impression I'm stalling this just for the sake of being difficult, and since it is easier to talk "with code" I quickly wrote this: https://reviews.llvm.org/D56770 . This *not* a patch intended to be submitted, it is just a stripped-down version of how I'd phrase/structure it intended to support my arguments in this thread. Note that I would intentionally left out any compiler minimum bump out of the policy upgrade change, as these are conceptually separate change anyway.
Also the two levels (warnings vs errors) is not appropriate to accomplish what you're describing.
I don't understand what you're asking to change here
One release cycle with deprecating the version we're about to remove support for using a discardable cmake error seems like a good idea in general: we should encode this in the policy as well.
Jan 14 2019
Jan 11 2019
I'd like to see docs/GettingStarted.rst updated to include some language from what Chandler mentioned. In particular upgrading a toolchain has to be *motivated* by explicit benefits, and the toolchains dropped must be evaluated with respect to the general availability for the users.
Jan 10 2019
What about creating a new macrothat carry the semantic we're looking for here: "LLVM_KEEP_FOR_DEBUG"?
We can conditionally define it based on NDEBUG or add a CMake flag for it that is enabled in debug build (the latter has the advantage that it would allow to turn it on even in release builds when needing to debug these)
Nov 26 2018
Nov 25 2018
(should fix PR39780 https://bugs.llvm.org/show_bug.cgi?id=39780 )
Oct 22 2018
If we go with this document moving forward, I would first purge it so that it reflects the current situation. Otherwise we could also just archive it and start a new one with the actual action plan.
I feel adding more stuff here will be a bit confusing moving forward.
Sep 13 2018
Sep 10 2018
@kristina both bfd and lld are adding the .a extension when you pass a lib through -l. Similarly to -llibfoo won't work, -lfoo.a will lead the linker to look for libfoo.a.a
Aug 20 2018
Aug 16 2018
Aug 8 2018
Jul 31 2018
I'm worried, however, about generating a bunch more code than needed from clang in the hopes that the compiler will clean it up later.
Jul 30 2018
I'm curious: isn't the kind of optimization we should expect LLVM to provide?
Jul 25 2018
but declarations cannot be internal.
Jul 10 2018
std::map is usually fairly slow, have you considered sorting at the time you write to the file instead? That would add a slow step when writing the files but wouldn't affect any in-memory operation.
Feb 19 2018
Feb 16 2018
@hans : this needs to go in LLVM 6.0, is it OK?
Feb 15 2018
I quickly put a patch to change the encoding, may be easier to discuss with code at hand: https://reviews.llvm.org/D43348
(I didn't try to build it, just a quick draft)
Feb 14 2018
Feb 13 2018
Actually if we're making this change, we consider that bitcode generated between the introduction of the new fast-math flags and now isn't supported anymore.
If so then we could instead of bumping a version, change the encoding of the FMF record (or create a new record type), so that the old encoding is upgraded but not the new one.
That would seem to me to be more in line with the usual handling of such situation in the bitcode.