This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: _Bool and trap representations
- From: Alexander Cherepanov <ch3root at openwall dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 8 Jun 2016 11:04:27 +0300
- Subject: Re: _Bool and trap representations
- Authentication-results: sourceware.org; auth=none
- References: <5757BCD9 dot 9070407 at openwall dot com> <CAFiYyc3Fqj_vL4af6dfGSvkV4GhWT2JTWvJzOaQQ8JN_Qrk+Bw at mail dot gmail dot com>
On 2016-06-08 10:29, Richard Biener wrote:
On Wed, Jun 8, 2016 at 8:36 AM, Alexander Cherepanov
<ch3root@openwall.com> wrote:
[skip]
But my question is about the following example:
----------------------------------------------------------------------
#include <stdio.h>
int main()
{
_Bool b;
*(char *)&b = 123;
printf("%d\n", *(char *)&b);
}
----------------------------------------------------------------------
Results:
----------------------------------------------------------------------
$ gcc -std=c11 -pedantic -Wall -Wextra test.c && ./a.out
123
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
1
----------------------------------------------------------------------
[skip]
Another explanation is that this is a bug. It manifests itself at the time
we re-write 'b' into SSA form, disregarding the fact that we access it
via a type that while matching in size does not match in precision.
Oh, that's much more boring outcome:-)
Can you open a bugreport?
Sure, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71452 .
--
Alexander Cherepanov