ojhunt wrote: > > > > > @zahiraam @AaronBallman a different option would be to add a signed > > > > > vs unsigned storage option to the `OPTION` and `BENIGN_ENUM_LANGOPT` > > > > > macros so we can store negative enumerations safely > > > > > > > > > > > > I think I would prefer this solution. We need to be able to set the > > > > evaluation method to a value (-1) when it can't be known from the > > > > target or when the value of `ffp-eval-method` is inconsistent with the > > > > target. > > > > > > > > > Could we shift all the values, so `FEM_Indeterminable` is `0`? > > > > > > I don't think so. In practice on Linux systems, they use > > `__FLT_EVAL_METHOD__` to control the type of `float_t` and `double_t`. > > Things like this: > > Oh shoot, I forgot this was tied to `__FLT_EVAL_METHOD__`
As far as I can make out this isn't an automatic mapping, so we can always just set it correctly, but more importantly, I cannot see how it is not currently broken - loading FEM_Indeterminate should not (in principle) be sign extending. How do I get clang into the FEM_Indeterminate mode? As far as I can make out, we currently have a single test for `__FLT_EVAL_METHOD__ == -1` and it does not get run/checked https://github.com/llvm/llvm-project/pull/137661 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
