Final suggestion after feedback on IRC:

```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: do not 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 (implies -fassociative-math, -fno-signed-zeros, -freciprocal-math)
# -ffast-math: has no effect on optimizations (as opposed to with GCC), provides preprocessor macro __FAST_MATH_, but does imply -ffinite-math-only -funsafe-math-optimizations
#
# 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', 'fsigned-zeros', 'fhonor-infinities', 'fhonor-nans', 'fno-unsafe-math-optimizations', 'fno-fast-math'],
    'precise': ['fno-associative-math', 'fno-reciprocal-math', 'fno-unsafe-math-optimizations'],
    'defaultprec': [],
    'loose': ['ffast-math', 'fno-unsafe-math-optimizations'],
    'veryloose': ['ffast-math'],
```