Sat, Jul 4
Sat, Jun 20
Fri, Jun 19
@tambre What compiler(s) did you test this with? It's breaking pretty much all of the bots because of unguarded concepts use (I think -- haven't looked thoroughly yet).
D77505 broke a bunch of bots. This fixes the regression.
Thu, Jun 18
Please commit this for me in case no one else has objections. I lack commit privileges.
Tue, Jun 16
ldionne: ping. From what I gather, building projects separately is still supported, but I remain unaware of an option to accomplish what I want without downsides. I'd really rather not keep a single out-of-tree patch for my use.
Jun 10 2020
Hopefully I've managed to address the comments correctly this time around.
Add test checking if the numbers are defined.
Jun 6 2020
I've addressed the comments.
May 30 2020
Fix some intrinsics not being marked as builtin due to being static in the headers.
Make some code easier to read, fix test for sigsetjmp in Sema/implicit-builtin-decl.c to reflect the original intent.
Unfortunately, I think this approach basically can't work, because we need to consider inheriting default arguments from a previous (or subsequent!) declaration before dropping default arguments preceding a pack. I think we will instead need to detect this situation when issuing the diagnostic for a parameter with a default argument followed by a parameter without one, and will need to make sure that all the parts of Clang that look at default arguments can cope with them being discontiguous.
May 29 2020
Fix typo in a comment.
May 23 2020
Weakened noexcept checking.
Remove memcpy overload tests from warn-fortify-source.c, which relied on identifier-based builtin identification.
Thanks for the reviews!
I believe this now handles all cases and with this we'll be standards-conforming in regard to DR777 and DR2233.
Handle multiple parameter packs interleaved with default values.
Mark DR777 as superseded by DR2233. Mark DR2233 as resolved.
Moved tests from dr7xx.cpp to dr22xx.cpp. Added note in dr7xx.cpp about DR777 being superseded.
Add more tests that cover bugs observed in other implementations and the deficiency in my first implementation.
Adding a few reviewers from D78427 so they can take a look at this too.
Borrow useful things from D78427:
- A test
- Version guard
- Double include test
May 22 2020
May 21 2020
May 17 2020
Thanks for the reviews and design pointers, John!
Semantic compatibility checking for C++ builtin redeclarations.
Remove some now unnecessary logic from getBuiltinID().
Update more tests. 4 tests still failing.
May 16 2020
Fix adding BuiltinAttr in C++ mode. Update one test.
Rework builtin declaration handling. Introduce BuiltinAttr.
May 13 2020
Simplify code, improve comments.
May 12 2020
May 7 2020
May 3 2020
This needs a bunch of additional tests. Specifically of the passing kind :-)
Add more tests, assert on ill-formed specialization
Apr 30 2020
ldionne: Ping. Per the mailing list thread it seems reasonable to support this scenario.
Apr 24 2020
Could someone please review this?
Apr 23 2020
It seems a NVIDIA Developer Program Membership is needed in order to download the TRM. I'm not sure if that is just a matter of creating an account, but without it I can't really verify that the architecture version and the features are correct and complete.
Remove SVE, add another check to parser test
Abandoning as there are good reasons to not add this.
Please land this for me as I lack commit privileges.
sdesmalen: Could you please take another look?
Apr 21 2020
Apr 18 2020
Add cacheline size per the technical reference manual
Apr 17 2020
Apr 16 2020
Remove SVE, fix formatting
rsmith: ping 2
Apr 15 2020
Apr 14 2020
Apr 11 2020
Remove cacheline size
Apr 10 2020
Actually, if we want to do that, I think that we should redo the build to remove LIBUNWIND_ENABLE_SHARED/LIBUNWIND_ENABLE_STATIC - they are supposed to be specified by the user as BUILD_SHARED_LIBS=[YES|NO] not as a single build as it is currently. But, that is beyond the scope of this change and more about the philosophical approach that you are suggesting here.
I agree with that in principle, and it has been a source of frustration/confusion about how we build things in the runtimes.
So, @tambre, is there anything that makes specifying CMAKE_POSITION_INDEPENDENT_CODE=ON in your cache not a viable option? Would it work? Would it introduce other complexity or weirdness into your build? I'm trying to weigh the options we have here.
Apr 9 2020
Apr 8 2020
I'll chime in on that. I just recently migrated the company I work for to LLVM, so I was only aware that building in a non-monorepo layout is unsupported now.
I'm fine with passing -DCMAKE_POSITION_INDEPENDENT_CODE=ON on the command line. I didn't think of that before @compnerd mentioned it.
I'll run a toolchain build tomorrow and try it.
Apr 7 2020
Fix floating point constraint tests, remove bad test
Added proper generalization for the DstSize > SrcSize aka SUBREG_TO_REG case. Also moved the missing comment to SrcSize > DstSize.
Tests now pass.
Generalized SUBREG_TO_REG logic
Add cache variable for LIBCXXABI_UNWIND_LIBRARY_PATH to improve discoverability and clarify usage.
Should we have some kind of test coverage that the values of these constants are correct?
Updated the comment.
Apr 6 2020
Add version macro
Emit undef lvalue, add throw CHECK to test
This actually breaks CodeGen/AArch64/f16-instructions.ll's test_select. Will investigate.
If you see anything incorrect in the current changes let me know. :)