JustinStitt wrote:
> Either always returning false (wrapping to uint8_t), or trapping in the
> overflow (?) check due to early narrowing, or returning false incorrectly but
> only if obt is enabled, and if obt is not enabled the only overflow exists on
> the promoted, but that can be prevented with:
>
> ```c++
> uint8_t __obt_trap_wrapper u;
> if (__UINT32_T_MAX__ - u < some_other_value)
> return;
> if (u + some_other_value > 0xff) {
>
> }
> ```
>
> But now even that overflow test is incorrect, no matter how or when the
> truncation happens: the overflow test now traps in some cases and produces
> incorrect false results in others.
@ojhunt For what it's worth, check out
https://github.com/llvm/llvm-project/pull/100272 and
https://github.com/llvm/llvm-project/pull/104889 and
https://github.com/llvm/llvm-project/pull/105709 (all related to Overflow
Pattern Exclusions) `-fsanitize-undefined-ignore-overflow-pattern=`. In some
instances, we can tinker with instrumentation for common overflow idioms, even
trumping OBT annotations.
Anyways, it is clear we cannot move forward with any of the current
non-traditional narrowing rules. The question is where do we go from here?
@rjmccall suggested [some
models](https://discourse.llvm.org/t/rfc-v2-clang-introduce-overflowbehaviortypes-for-wrapping-and-non-wrapping-arithmetic/86507/42?u=justinstitt)
in the RFC recently and @ojhunt has suggested more traditional and more strict
options as well. My estimate from reading everyone's feedback is that there are
maybe 3 or 4 different approaches.
Of the approaches, most suggest that OBTs should behave more like regular
arithmetic. Certain models mentioned by @kees and @ojhunt introduce strict
typing -- involving manual casts to strip or add behavior; a rust-style
approach. Everything must be the same bitwidth, signed ness and OBT kind. This
particular strictness seems hard to adopt in the Linux kernel but removes 99%
of mathematical ambiguity. Other models (like [wraps attribute
feature](https://github.com/llvm/llvm-project/pull/86618) I tried to land 1.5
years ago) involve persisting OBT kind through the usual arithmetic conversions
and using them to trap on truncation.
>From what I've read, most agree that `wrap` and `trap` should have the same
>semantics regardless of specific arithmetic model. However, I think there is
>some merit in considering different behaviors between `wrap` and `trap`. We
>could enforce a strict model, similar to what I mentioned above, for `trap`
>types and a more relaxed model for `wrap` types. I am also not opposed to some
>`__ob_strict_trap` or something like that, this allows for easier adoption
>from mature codebases.
We should schedule a meeting, when does the Clang Area Team meet next? Can we
hijack part of that meeting? @AaronBallman
https://github.com/llvm/llvm-project/pull/148914
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
