My (first) suggestion:


```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
# -fhonor-nans: disallow optimizations to assume that arguments and results are not NaN
# -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_

    'strict': ['fno-associative-math', 'fno-reciprocal-math', 'fno-signed-zeros', 'fhonor-infinities', 'fhonor-nans', 'fno-unsafe-math-optimizations'],
    'precise': ['fno-associative-math', 'fno-reciprocal-math', 'fno-unsafe-math-optimizations'],
    'defaultprec': [],
    'loose': ['ffast-math', 'ffinite-math-only'],
    'veryloose': ['ffast-math', 'ffinite-math-only', 'fassociative-math', 'freciprocal-math', 'funsafe-math-optimizations'],
```

Maybe this warrants the GCC strictness options to be revised as well, since several of these flags are also available for GCC (e.g. `-ffast-math` and the flags it enables in GCC (`-funsafe-math-optimizations`, `-ffinite-math-only`, ...).

@stdweird: Your thoughts?