er types of padding (padding in
long double, padding bytes/bits in structs/unions) in the future? Maybe
even normalization of pointers (randomly aligning misaligned pointers)?
--
Alexander Cherepanov
On 2016-06-08 10:29, Richard Biener wrote:
On Wed, Jun 8, 2016 at 8:36 AM, Alexander Cherepanov
wrote:
[skip]
But my question is about the following example:
--
#include
int main()
{
_Bool b;
*(char *)&b =
On 2016-06-08 17:37, Martin Sebor wrote:
On 06/08/2016 12:36 AM, Alexander Cherepanov wrote:
Hi!
If a variable of type _Bool contains something different from 0 and 1
its use amounts to UB in gcc and clang. There is a couple of examples in
[1] ([2] is also interesting).
[1] https://github.com
On 2016-06-13 22:51, Joseph Myers wrote:
On Mon, 13 Jun 2016, Alexander Cherepanov wrote:
Thanks for the info. IMHO this part of DR 260 has even more serious
consequences than the part about pointer provenance. It effectively prohibits
manual byte-by-byte (or any non-atomic) copying of objects
On 2016-06-14 00:13, Joseph Myers wrote:
On Tue, 14 Jun 2016, Alexander Cherepanov wrote:
The problem is that parts of representations of two different ordinary values
can form a trap representation.
Oh, you're talking about normalizing the destination rather than the
source of the
//llvm.org/docs/LangRef.html#undefined-values .
I don't see gcc treating padding in long double as indeterminate in the
same way as in structs but clang seems to treat them equally.
--
Alexander Cherepanov
,0xc(%rsi)
2e: 8b 47 0cmov0xc(%rdi),%eax
Is this behavior fully intentional, is the first example optimized too
aggressively, is an optimization missed in the second example, or is the
situation more complex?
--
Alexander Cherepanov
