This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Strict aliasing-related bug even with optimizations disabled
- From: Jonathon Reinhart <jonathon dot reinhart at gmail dot com>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 17 Mar 2018 14:40:52 -0400
- Subject: Strict aliasing-related bug even with optimizations disabled
This was originally posted on Stack Overflow:
https://stackoverflow.com/a/49339771/119527
The following program:
#include <stdio.h>
static void pshort(short val)
{
printf("0x%hx ", val);
}
int main(void)
{
short A[] = {1, 2, 3, 4, 5, 6};
#define EXP ((short*)((char*)A + 7))
short *p = EXP;
short q = *EXP;
pshort(*p);
pshort(q);
pshort(*EXP);
printf("\n");
return 0;
}
...when compiled on x86-64 with
gcc -O0 -fno-strict-aliasing -g -Wall -Werror endian.c
...produces the following unexpected output
0x500 0x500 0x4
...on all available versions of GCC, from 4.9 thru 7.3.1.
It appears that GCC is actually generating different code when the
expression is used directly as an argument, versus when used with
intermediate variables.
The language lawyers declared that UB is UB. But -fno-strict-aliasing
seems to be ineffective here, and this feels like a bug.
Jonathon Reinhart