kees wrote:
Okay, I'm trying to isolate subtopics here.
AFAICT these are resolved:
- type specialization for `_Generic`: yes, `int` is separate from `__ob_trap
int`
- type specialization for templates: yes, `int` is separate from `__ob_trap int`
Open, with my proposed outcomes with rationale:
kees wrote:
> please cc me on the email thread regarding a video call. FYI, I'll be at '25
> dev mtng.
>
> I think there is some confusion in this thread about how to tell the compiler
> about intentional data loss.
>
> The UX I like the most is something like the following:
>
> ```c
> void
kees wrote:
In looking at what's here, I suddenly realize that I think we accidentally
deviated a bit on naming, in that the trap behavior got named "no_wrap" which
is ambiguous. For example, a future overflow resolution behavior can be added
like "saturate", which isn't wrapping either, and s
@@ -2885,7 +2885,7 @@ static bool CheckedIntArithmetic(EvalInfo &Info, const
Expr *E,
APSInt Value(Op(LHS.extend(BitWidth), RHS.extend(BitWidth)), false);
Result = Value.trunc(LHS.getBitWidth());
- if (Result.extend(BitWidth) != Value) {
+ if (Result.extend(BitWidth) !=
kees wrote:
> FWIW, this _currently_ doesn't compile
>
> ```c
> $ cat test.c
> void foo(int some) {
> int __ob_trap big = some;
> char __ob_wrap byte = big; // is this supposed to wrap or trap? I say wrap
> -- we're describing how "byte" behaves
> }
>
> $ clang test.c -foverflow-behavior-t
kees wrote:
I think this got fixed by commit
https://github.com/llvm/llvm-project/commit/1395d4315bf49be64817b79e3863d183bb28c3e1
?
https://github.com/llvm/llvm-project/pull/162571
___
lldb-commits mailing list
[email protected]
https://lis
kees wrote:
> > This one, however, I think it not what we want, but I may be missing
> > something.
> > ```
> > int __ob_trap src = bigger_than_255;
> > ...
> > char dest = src;
> > ```
>
> I don't think that's correct, it's equivalent to saying
>
> ```
> int64 __ob_trap src = bigger_than_2_to
kees wrote:
> You would only get a trap when you get a narrowing conversion, maybe that
> should only be the case for _implicit_ conversions? e.g
> `(int)some_obt_qualified_64bit_type` - I'm not sure I like that as to me it
> feels like the idiomatic casting behaviour would silently truncate,
kees wrote:
tl;dr: I think I understand what you're saying and I think I'm convinced...
We seem to be talking about different things. I'm trying to understand what
you're describing. It looks like you're trying to say that values that are
stored in an OBT variable carry their OB-ness permanent
kees wrote:
@JustinStitt were looking over things, and I stumbled over something here...
> Thanks. So IIUC, the rule is:
>
> 1. If the type of either operand of an arithmetic operator is `__ob_trap`,
> the operator traps on overflow, and the result type is `__ob_trap`.
This is correct and wh
kees wrote:
Would it be reasonable to split this into two phases?
1) this PR, but with standard promotion semantics and instrumented casting.
2) new PR that adds a type qualifier named `__strict` or
`__no_implicit_promotion` that forces annotated types to not be involved in
implicit promotion
11 matches
Mail list logo
