[Bug c/58303] New: C99 union initializers new union members clobber earlier data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58303
Bug ID: 58303
Summary: C99 union initializers new union members clobber
earlier data
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: darrenrjenkins at gmail dot com
If using C99 initializers on a union, and using different union members.
The later members seem to clobber the previous members data.
I haven't looked at the standards with respect to this, but it seems wrong.
#include stdio.h
typedef struct
{
int a;
int b;
} a_t;
typedef struct
{
int c;
int d;
} b_t;
typedef union
{
a_t a;
b_t b;
} c_t;
void main( int argc, char *argv[] )
{
c_t var = { .a.a = 4, .b.d = 7 };
printf( .a.a = %d .b.d = %d\n, var.a.a, var.b.d );
}
[Bug rtl-optimization/45813] alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813 --- Comment #7 from Darren Jenkins darrenrjenkins at gmail dot com 2010-09-29 07:46:54 UTC --- OK CrossWorks don't use/ship the GCC compiler driver. So I guess all the usefull information I can give is from the c compiler: cc1 --version GNU C (GCC) version 4.4.4 (arm-unknown-elf) compiled by GNU C version 3.4.4 (mingw special), GMP version 4.3.2 version 2.4.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
[Bug rtl-optimization/45813] alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813
--- Comment #3 from Darren Jenkins darrenrjenkins at gmail dot com 2010-09-28
23:07:08 UTC ---
unsigned short ReadLE16U( volatile unsigned char * ptr )
{
unsigned short value;
unsigned char * bytes = (unsigned char *)value;
bytes[0] = ptr[0];
bytes[1] = ptr[1];
return value;
}
Gives me the same erroneous results.
The compiler I am using is part of Rowley CrossWorks for ARM 2.0.7 which
claims to be an unmodified GCC 4.4.4
http://www.rowley.co.uk/crossworks/gpl_sources.htm
cc1 --version
GNU C (GCC) version 4.4.4 (arm-unknown-elf)
compiled by GNU C version 3.4.4 (mingw special), GMP version 4.3.2
version 2.4.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
What gets passed to the compiler seems to be :
C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM
2.0/gcc/bin/cc1 -fmessage-length=0 -mcpu=arm7tdmi-s -mthumb -mthumb-interwork
-mlittle-endian -mfpu=vfp -mfloat-abi=soft -nostdinc -isystemC:/Program Files
(x86)/Rowley Associates Limited/CrossWorks for ARM 2.0/include
-isystemC:/Users/DarrenJenkins/AppData/Local/Rowley Associates
Limited/CrossWorks for ARM/packages/include -I. -I../.. -I../../include
-I../../system -I../../LwIP -I../../LwIP/include -I../../LwIP/include/lwip
-I../../LwIP/include/ipv4 -I../../NXP_Lib -I../../fat_file_system -I../../usb
-I../../usb/UsbHost/Include -I../../Macro -D__ARM_ARCH_4T__ -D__CROSSWORKS_ARM
-D__CROSSWORKS_MAJOR_VERSION=2 -D__CROSSWORKS_MINOR_VERSION=0
-D__CROSSWORKS_REVISION=7 -D__TARGET_PROCESSOR=LPC2468 -DNESTED_INTERRUPTS
-DSRAM_EXCEPTIONS -D__THUMB -D__FLASH_BUILD
-DOSCILLATOR_CLOCK_FREQUENCY=1200 -DDEBUG -MD THUMB Flash
Debug/usbhost_lpc2468.d -MQ THUMB Flash Debug/usbhost_lpc2468.o -quiet -Wall
-fno-omit-frame-pointer -fno-schedule-insns2 -gdwarf-2 -Os -fno-dwarf2-cfi-asm
-fno-builtin -ffunction-sections -fdata-sections
C:/Users/DarrenJenkins/Documents/NXP_darren/src/projects/Darren/../../usb/UsbHost/Host/usbhost_lpc2468.c
-o C:/Users/DarrenJenkins/Documents/NXP_darren/src/projects/Darren/THUMB Flash
Debug/usbhost_lpc2468.asm
and
C:/Program Files (x86)/Rowley Associates Limited/CrossWorks for ARM
2.0/gcc/bin/as --traditional-format -mcpu=arm7tdmi-s -mthumb -mthumb-interwork
-EL -mfpu=vfp -mfloat-abi=soft
C:/Users/DarrenJenkins/Documents/NXP_darren/src/projects/Darren/THUMB Flash
Debug/usbhost_lpc2468.asm -o
C:/Users/DarrenJenkins/Documents/NXP_darren/src/projects/Darren/THUMB Flash
Debug/usbhost_lpc2468.o
Yell out if you would like to know anything else.
[Bug rtl-optimization/45813] alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813 --- Comment #5 from Darren Jenkins darrenrjenkins at gmail dot com 2010-09-29 03:33:27 UTC --- Please show us the output of gcc -v, we want to see how the compiler was configured (wrt certain defaults etc). Also, when you invoke the compiler we want to see the exact options YOU supply to it; right now it's difficult to separate your options from what the compiler driver passes to the backend. This is a little difficult as the compiler is part of a whole development/build environment thing, and I can't find an executable called gcc in it. I will investigate how it is put together and see what I can find out.
[Bug rtl-optimization/45813] alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813 --- Comment #6 from Darren Jenkins darrenrjenkins at gmail dot com 2010-09-29 03:55:39 UTC --- Also if I don't use -fno-omit-frame-pointer the code seems to be generated correctly
[Bug rtl-optimization/45813] New: alias analysis problem ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45813
Summary: alias analysis problem ?
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: darrenrjenk...@gmail.com
I think I am having some wrong code generated due to a compiler bug.
I am compiling for ARM/Thumb.
USB_INT16U ReadLE16U ( volatile USB_INT08U *pmem )
{
USB_INT16U val;
USB_INT08U *bytes = (USB_INT08U *)val;
bytes[0] = pmem[0];
bytes[1] = pmem[1];
return (val);
}
gives me
B580push {r7, lr}
B081sub sp, #4
AF00add r7, sp, #0
1CBBadds r3, r7, #2
7802ldrb r2, [r0, #0]
701Astrb r2, [r3, #0]
7842ldrb r2, [r0, #1]
8818ldrh r0, [r3, #0]
46BDmov sp, r7
B001add sp, #4
BC80pop {r7}
BC02pop {r1}
4708bx r1
Which reads the second byte into r2 but does not store it on the stack, so the
second byte of val is returned uninitialized.
It looks like the alias analysis knows that bytes points to val but doesn't
know that bytes+1 points to a part of val also, so optimizes it away.
Yell out if you need any more information
[Bug target/30282] Optimization flag -O1 -fschedule-insns2 cause red zone to be used when there is none
--- Comment #13 from darrenrjenkins at gmail dot com 2010-09-22 00:20
---
I seem to be getting this bug on arm thumb also
USB_INT16U ReadLE16U ( volatile USB_INT08U *pmem )
{
USB_INT16U val;
USB_INT08U *bytes = (USB_INT08U *)val;
bytes[0] = pmem[0];
bytes[1] = pmem[1];
return val;
}
B580push {r7, lr}
B081sub sp, #4
7802ldrb r2, [r0, #0]
AF00add r7, sp, #0
1CBBadds r3, r7, #2
701Astrb r2, [r3, #0]
46BDmov sp, r7
B001add sp, #4
7842ldrb r2, [r0, #1]
8818ldrh r0, [r3, #0]
BC80pop {r7}
BC02pop {r1}
4708bx r1
This happens on both 4.4.4 and 4.5.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282
