https://github.com/awilfox created
https://github.com/llvm/llvm-project/pull/111995
On big-endian systems, narrow casting will read the higher bits of the value.
LazyOffsetPtr's `getAddressOfPointer` returns the address-of `Ptr` which was
unconditionally a 64-bit value. On 32-bit big endian
awilfox wrote:
This patch has been tested on 32-bit PowerPC, 64-bit PowerPC, and 64-bit x86_64
(ensuring it doesn't change any behaviour on LE systems) - the entire Clang
test suite passed on all three platforms.
https://github.com/llvm/llvm-project/pull/111995
awilfox wrote:
I feel like the messages being highlighted in the CI formatter need work
anyway. I was hoping the community would have a suggestion on better wording.
However, I will be glad to reformat those lines in that manner if this wording
should stay.
https://github.com/llvm/llvm-proj
awilfox wrote:
I'll run a full test on the ppc32 builder now and report back. Thanks for this
work.
https://github.com/llvm/llvm-project/pull/112927
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
awilfox wrote:
> Btw, if you submit a fix, it would be great if it could be backported to the
> 18 and 19 branches.
I think the 18 branch may already be closed. This is what we are shipping in
Adélie for 18:
[big-endian-32.patch](https://github.com/user-attachments/files/17404400/big-endian-
@@ -326,25 +326,25 @@ struct LazyOffsetPtr {
///
/// If the low bit is clear, a pointer to the AST node. If the low
/// bit is set, the upper 63 bits are the offset.
- mutable uint64_t Ptr = 0;
+ mutable uintptr_t Ptr = 0;
public:
LazyOffsetPtr() = default;
- exp
awilfox wrote:
> This violates aliasing rules and doesn't work at all on big-endian 64-bit
> systems where the pointer is stored in the second four bytes of the uint64_t.
Your sizes aren't correct in the description here. This issue occurs on big
endian 32-bit systems, and the pointer is stor
