[clang] [clang] Implement -fstrict-bool (PR #160790)

[via cfe-commits]

=?utf-8?q?Félix?= Cloutier <fcloutier at apple.com>,
=?utf-8?q?Félix?= Cloutier <fcloutier at apple.com>,
=?utf-8?q?Félix?= Cloutier <fcloutier at apple.com>,
=?utf-8?q?Félix?= Cloutier <fcloutier at apple.com>,
=?utf-8?q?Félix?= Cloutier <fcloutier at apple.com>,
=?utf-8?q?Félix?= Cloutier <fcloutier at apple.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/160790 at github.com>


================
@@ -2312,6 +2312,30 @@ are listed below.
    additional function arity information (for supported targets). See
    :doc:`ControlFlowIntegrity` for more details.
 
+.. option:: -fstrict-bool
+
+    ``bool`` values are stored to memory as 8-bit values on most targets. C and
+    C++ specify that it is undefined behavior to put a value other than 0 or 1
+    in the storage of a ``bool`` value, and with ``-fstrict-bool``, Clang
+    leverages this knowledge for optimization opportunities. When this
+    assumption is violated, for instance if invalid data is ``memcpy``ed over a
+    ``bool``, the optimized code can lead to memory corruption.
+    ``-fstrict-bool`` is enabled by default.
+
+.. option:: -fno-strict-bool[={truncate|nonzero}]
+
+    Disable optimizations based on the assumption that all ``bool`` values,
+    which are typically represented as 8-bit integers in memory, only ever
+    contain bit patterns 0 or 1. When ``=truncate`` is specified, a ``bool`` is
+    true if its least significant bit is set, and false otherwise. When
+    ``=nonzero`` is specified, a ``bool`` is true when any bit is set, and
+    false otherwise. The default is ``=truncate``, but this could change in
+    future releases.
----------------
workingjubilee wrote:

I don't agree with what you are saying, @apple-fcloutier, because your abstract reasoning doesn't really matter much from the outside view of another language's compiler. When we implement "C interop", we are forced to not implement compatibility against some abstract notion of C, but against the specifics of a dominant compiler's implementation. That is true even when those specifics blatantly flout the language standard. Otherwise, it's useless in practice. This flag functionally serves as explicitly blessing a pattern in C code, so unless we luck out and no one uses it, it *will* become an interop consideration. As a result, I expect it will simply magnify the problem it hopes to defend against when we consider its impact across language boundaries, as this diff here doesn't affect any other language's compiler. Maybe that doesn't matter now for mono-language projects, but your claim that this flag cannot affect the de facto ABI implementation that we must conform to seems bizarre to me.

https://github.com/llvm/llvm-project/pull/160790