zanmato1984 commented on code in PR #46124:
URL: https://github.com/apache/arrow/pull/46124#discussion_r2049525910
##########
cpp/src/arrow/compute/row/compare_internal.cc:
##########
@@ -276,12 +276,13 @@ void KeyCompare::CompareVarBinaryColumnToRowHelper(
int32_t tail_length = length - j * 8;
uint64_t tail_mask = ~0ULL >> (64 - 8 * tail_length);
uint64_t key_left = 0;
- std::memcpy(&key_left, key_left_ptr + j, tail_length);
+ const uint8_t* src_bytes = reinterpret_cast<const uint8_t*>(key_left_ptr
+ j);
+ std::memcpy(&key_left, src_bytes, tail_length);
uint64_t key_right = key_right_ptr[j];
result_or |= tail_mask & (key_left ^ key_right);
}
int result = result_or == 0 ? 0xff : 0;
- result *= (length_left == length_right ? 1 : 0);
Review Comment:
Yeah, so to summarize, I have three concerns:
1. Why does the sanitizer complain about a line that seems to be totally
innocent? (I currently assume it's because the compiler
optimization/reordering.)
2. It's still not totally clear to me where these misaligned loads are
originated. For instance, `memcpy` is supposed alignment-safe thus should not
cause any alignment violation even under a sanitizer. Well by looking at the
code more, I'm suspecting the warning in `compare_internal.cc:284:30` is caused
by
https://github.com/apache/arrow/blob/cc56a5e78eeede2715f12b6ca61ebea741f38f60/cpp/src/arrow/compute/row/compare_internal.cc#L280C16-L280C25
(compiler reordering counted, of course). But still no clue on the warning in
`light_array_internal.cc:618:25`.
3. Withe the two concerns above, I wonder if we have a reproducible case for
us to validate our fix?
Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscr...@arrow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
