zahiraam 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
See issue https://github.com/llvm/llvm-project/issues/137600 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
