=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/[email protected]>
================
@@ -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.
----------------
apple-fcloutier wrote:
I think that we can agree to disagree and move on because ABI break or not,
given an option labeled "don't break my code from under my feet", continuing to
break code from under people's feet would be rude.
My point regarding ABI is that it's not a contract just between clang and
clang, it's a contract for an entire platform, including for clang linking with
the outputs of other clangs, other C compilers, and other compilers for other
languages, and for how clang-compiled programs interpret bits that were
serialized across the board. From that perspective, we need to write rules that
show `-fno-strict-bool` is backwards compatible with the ABI. We can do that by
saying "-fno-strict-bool is a backstop, it is not a license to start putting
any value you want inside of booleans". Under this rule (which is basically the
same as today's), then it's not an ABI break to change the interpretation of an
illegal bit pattern because the ABI holds you to nothing.
https://github.com/llvm/llvm-project/pull/160790
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
