=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?utf-8?q?Félix?= Cloutier <[email protected]>,
=?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.
----------------
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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
