[PATCH] D149645: [clang][Interp] Optionally cast comparison result to non-bool

Erich Keane via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue May 2 06:35:23 PDT 2023


erichkeane added a comment.

In D149645#4312190 <https://reviews.llvm.org/D149645#4312190>, @tbaeder wrote:

> In D149645#4312162 <https://reviews.llvm.org/D149645#4312162>, @erichkeane wrote:
>
>> For C, should we instead be teaching our boolean operations to understand it might be int?  I fear this will end up causing conversion problems later, such as with:
>>
>> `int F = 1 > 2;`.  We won't end up having a conversion operation there, since the RHS is already `int`, for the LHS.
>
> The result of `1 > 2` is int, yes. That's what this patch does - it converts the `Boolean` we create to the `int` the AST (and thus all the intepreter code inspecting it) expects.
>
> The AST has no `IntegralToBool` cast in the example, but that doesn't matter for this patch; it just fixes the types on the stack to correspond to what the later code expects. I'm not opposed to adding a target type to the comparison ops, but I'm not sure if the additional complexity is worth it.

That is pretty simplified, but I guess I'm concerned about situations where the next action is an assignment or other integer action in the constant expression evaluator. ARE you able to handle things like:

`_Static_assert( (5 > 4) + (3 > 2) == 2, "");` in C mode (where this change is needed?)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149645/new/

https://reviews.llvm.org/D149645



More information about the cfe-commits mailing list