=?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.
----------------
AaronBallman wrote:
> With that said, I don't think we can say this is an ABI break without
> implying that code built with -fstrict-bool, -fno-strict-bool=truncate and
> -fno-strict-bool=nonzero are each mutually ABI-incompatible
I think they are by definition. `-fno-strict-bool=truncated` has a different
value representation from `-fno-strict-bool=nonzero`.
> we need to conclude that sharing broken bools across an ABI boundary is still
> undefined, and therefore it's not an ABI break if the observed bool value for
> a given bit pattern (other than 0 or 1) changes.
I don't think that follows, but I also don't think it matters because we seem
to be in agreement that changing the behavior from `truncate` to `nonzero` or
vice versa can silently change the behavior of code and therefore is a bad
thing for us to tell users we're possibly going to do to them in the future. I
think this is a bog standard "different options in different TUs is a bad idea
when linking things together" situation otherwise.
https://github.com/llvm/llvm-project/pull/160790
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
