- User Since
- Sep 4 2015, 4:18 PM (229 w, 2 d)
Thu, Jan 23
Thanks! Looks good, just one minor typo in the documentation.
@jrtc27 This should probably also go in the release branch or was the commit that exposed the problem made after the branch point?
Wed, Jan 15
Tue, Jan 14
Move to if() above and update commment in test
Mon, Jan 13
Remove unncessary changes.
Sun, Jan 12
Looks good to me once the tests have been added and other reviewers are also happy.
Fri, Jan 10
Thu, Jan 9
Could we an overload that takes LLT instead and keep the boolean flag internal to the .cpp?
ping? I believe this is the last blocker before FreeBSD can move to using Clang+LLD for MIPS64 by default. It would be really nice to get this in for LLVM 10.
I'm fine with this workaround although I'm very surprised that the test is not working. Especially since deterministic-archive.test and replace-update.test also set TZ to get reproducible output
I was careful in the test to use TZ=UTC for all commands printing dates and it works fine for me in UTC+1 and in the UK which is currently UTC. Does the bot in question ignore the TZ variable?
Wed, Jan 8
Tue, Jan 7
Could we invert the boolean flag to be isFloat? I fear that calling it isInteger, will lead the the same problems that I tried to fix in that commit (calling .isInteger() returns false for pointers).
Mon, Jan 6
LGTM. Thanks for working on this feature!
Sun, Jan 5
- Add a test that the new alignment is propagated to e.g. llvm.memcpy
To do this emit a llvm.assume for pointer types and mark the builtin
as having an alloc_align attribute (although that does not seem to do anything)
Fri, Jan 3
Thu, Jan 2
- Fix typos caused by dodgy n key on my keyboard.
- Generate inbounds GEP. Also mention that values must point to the same allocation in the documentation.
- Clarify that correctly aligned values do not change.
What i'm asking is:
- Are these builtins designed (as per clang/docs/LanguageExtensions.rst) to only be passed pointers in-bounds to the allocated memory chunk (Logical pointer*), or any random bag of bits casted to pointer type (Physical Pointer*)?
- If Logical pointer, are they designed to also produce Logical pointer? Or Physical Pointer?
In my view you both input and output should be a Logical pointer. If you want random values, you should be aligning uintptr_t instead.
For CHERI we only need to support passing and creating valid pointers (i.e. with the capability tag bit set and valid bounds information).
Since the source pointer contains bounds information, it will never be possible to use the __builtin_align_up/down result to access memory from a different underlying allocation.
Improved code generation with a single GEP
Wed, Jan 1
- Also update the other codegen test
Address feedback: Avoid inttoptr by using ptrtoint + GEP instead.
- Address remaining comments
Tue, Dec 31
- Address feedback
If I understand this correctly existing check lines between off/on directives should be copied verbatim. Could you add one (that does not match the auto-generated content) to the disabled part of the test?
Could you also make this change to update_cc_test_checks.py?
Mon, Dec 30
Dec 20 2019
- Add documentation for the new alignment builtins
Dec 18 2019
Looks fine to me if @MaskRay is happy with it.
Also handle -h/-v as short options. Does the adjusted test look okay?
Dec 16 2019
I think it might be better to just always use sys.executable and skip the tests if the version is less than (3, 5).
Force UTC timezone for reproducible results
Drop unrelated change
Fix align32array -> &align32array typo in test
- Add support for constant-evaluating pointer values
- Add errors messages for constant evaluation
- Extend tests for constant evaluation
- Use ptrtoint+inttoptr instead of ptrmask as suggested by @lebedev.ri
- Fix SemaChecking.cpp
Dec 15 2019
If I build on macOS with cmake -GNinja -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_PROJECTS=llvm;clang;lld;compiler-rt;libcxx;libcxxabi -DBUILD_SHARED_LIBS=ON -DLLVM_ENABLE_MODULES=ON, I get lots of linker errors building e.g. libclangASTDiff.dylib due to using the internal ASTMatchers header inside the Tooling/Transformer headers.
Dec 14 2019
Dec 13 2019
Fix for UBSAN failure
Duplicate of D69722 with a worse python implementation.
Some minor comments, but generally looking good to me.
We have a few downstream tests that will really benefit from matching Hex upper/lower so looking forward to this landing.
Implement using the other overload
- Use separate .expected files for the --function-signature tests
- address comments