Harald van Dijk

Sorry, but that looks like a very wrong approach to me. The code you're modifying in your last commit was already correct, and this new version means we no longer...

> Which makes me think that in both cases, if we have the choice between two object with the same size + offset value, then choosing the one with the...

The problem is not limited to the case where remaining object sizes are equal though, it's just that those are easiest to come up with test cases for. Consider: ```c++...

> Indeed. Looks like my previous approach which propagates the constant (negative) offset would have worked in that situation. But it couldn't work with a dynamic negative offset! You're right,...

Nice work! Using a new class rather than extending `SizeOffsetAPInt` is probably good, it helps maintain compatibility, which is a plus if it means we can also backport this to...

I did write in my previous comment: > However, if `ExactSizeFromOffset` is restored to handle that case, it then becomes important to ensure that nothing calls `ObjectSizeOffsetVisitor::compute` with `Options.EvalMode =...

> @hvdijk I don't suppose you're wanting to try building native-cpu SYCL-CTS with this patch? I believe it should now do the right thing 🤞 . Thanks, I'll run tests...

The testing on Native CPU completed and showed no regressions. I think the added `sycl/test/check_device_code/char_builtins.cpp` test that is failing on Windows might possibly be better done as an E2E test?...

Thanks, I forgot there was also an issue open about this. For default features, this was fixed by #15259. For non-default flags, I will double-check soon and either update this...

For non-default flags, this is not yet fixed. Taking an arbitrary "Hello, world!" SYCL program and compiling as ``` $ clang++ --target=riscv64-linux-gnu -mabi=lp64 -L /home/harald/dpcppllvm/build/riscv64-linux/lib -fsycl hello.cpp /usr/bin/riscv64-linux-gnu-ld: /tmp/hello-44d0f2.o: can't...