@gribozavr: OK, so `-ffinite-math-only` is implid by `-ffast-math` (and `-fno-honor-nans` and `-fno-honor-infinities` are implied by `-ffinite-math-only` already).

So, this is my corrected suggestion, with added comments:

```python
# -fassociative-math: allow re-association of operands in series of floating-point operations, violates the ISO C and C++ language standard by possibly changing computation result
# -freciprocal-math: allow optimizations to use the reciprocal of an argument rather than perform division
# -fsigned-zeros: allow optimizations to treat the sign of a zero argument or result as insignificant
# -fhonor-infinities: disallow optimizations to assume that arguments and results are not +/- Infs
# -fhonor-nans: disallow optimizations to assume that arguments and results are not +/- NaNs
# -ffinite-math-only: allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs (equivalent to -fno-honor-nans -fno-honor-infinities)
# -funsafe-math-optimizations: allow unsafe math optimizations
# -ffast-math: has no effect on optimizations (as opposed to with GCC), provides preprocessor macro __FAST_MATH_, but does imply -ffinite-math-only
#
# strict, precise and defaultprec are all ISO C++ and IEEE complaint, but we explicitly specify details flags for strict and precise for robustness against future changes

    'strict': ['fno-associative-math', 'fno-reciprocal-math', 'fno-signed-zeros', 'fhonor-infinities', 'fhonor-nans', 'fno-unsafe-math-optimizations', 'no-fast-math'],
    'precise': ['fno-associative-math', 'fno-reciprocal-math', 'fno-unsafe-math-optimizations'],
    'defaultprec': [],
    'loose': ['ffast-math'],
    'veryloose': ['ffast-math', 'fassociative-math', 'freciprocal-math', 'funsafe-math-optimizations'],
```

@gribozavr: Does this seems acceptable for you?