[all-commits] [llvm/llvm-project] 4d165a: In fast-math mode, when unsafe math optimizations ...

[Zahira Ammarguellat via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4d165ad7d9b3395a59c287ef60542b4de3a4d95a
      https://github.com/llvm/llvm-project/commit/4d165ad7d9b3395a59c287ef60542b4de3a4d95a
  Author: Zahira Ammarguellat <zahira.ammarguellat at intel.com>
  Date:   2022-04-05 (Tue, 05 Apr 2022)

  Changed paths:
    M clang/include/clang/Basic/DiagnosticFrontendKinds.td
    M clang/include/clang/Basic/DiagnosticSemaKinds.td
    M clang/lib/Frontend/CompilerInvocation.cpp
    M clang/lib/Sema/SemaAttr.cpp
    M clang/test/CodeGen/X86/32bit-behavior.c
    A clang/test/Driver/eval-method-with-unsafe-math.c
    A clang/test/Sema/eval-method-with-unsafe-math.c

  Log Message:
  -----------
  In fast-math mode, when unsafe math optimizations are enabled, the
compiler is allowed to use optimizations that allow reassociation and
transformations that don’t guaranty accuracy.
For example (x+y)+z is transformed into x+(y+z) . Although
mathematically equivalent, these two expressions may not lead to the
same final result due to errors of summation.
Or x/x is transformed into 1.0 but x could be 0.0, INF or NaN. And so
this transformation also may not lead to the same final result.
Setting the eval method 'ffp-eval-method' or via '#pragma clang fp
eval_method' in this mode, doesn’t have any effect.
This patch adds code to warn the user of this.

Differential Revision: https://reviews.llvm.org/D122155