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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
