[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #3 from sqrammi at hotmail dot com 2007-01-25 17:11 --- I've modified the source so that there are no warnings and (hopefully) no aliasing violations. The problem still occurs. Here is my line that I use to compile: arm-926ejs-linux-gnu-gcc -Wall -O2 -fno-strict-aliasing gcc4_arm_align_bug.c -o gccbug It happens with or without -static. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #4 from sqrammi at hotmail dot com 2007-01-25 17:12 --- Created an attachment (id=12956) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12956&action=view) Modified code - no warnings -- sqrammi at hotmail dot com changed: What|Removed |Added Attachment #12953|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #6 from sqrammi at hotmail dot com 2007-01-25 17:28 --- The problem is that the compiler is not either 1) automatically aligning the buffer so that the program actually works or 2) warning the user that their code is retarded and needs to be modified so that all the stacks fit to multiples of 32-bits. wpa_supplicant is wrought with code that does this, but I don't think the maintainers understand the problem because gcc doesn't complain, and the problem doesn't show up until runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #8 from sqrammi at hotmail dot com 2007-01-25 17:45 --- It would be easy to add support to the compiler to at least warn about char arrays of non-CPU-word-size length being placed on the stack, right? It wouldn't even have to be a warning that shows up unless -Wall (or it's own new -W flag) is specified. Either that, or there needs to be a flag that aligns each of the inlined functions' stacks on a CPU-word-size boundary that is turned on by default. I would strongly recommend a new warning flag like this so that the poop hits the fan a little earlier than runtime. There are many projects whose maintainers won't realize this problem in their code unless the compiler warns them. The better GCC gets at optimizing and inlining functions, the more likely this is to happen since developers currently don't think twice about doing a: char ssid[MAX_SSID_LEN+1]; etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #10 from sqrammi at hotmail dot com 2007-01-25 17:55 --- Great. That's perfect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #11 from sqrammi at hotmail dot com 2007-01-25 18:01 --- Thinking about it some more, this actually may be a bug in my Linux kernel configuration that fixes up unaligned accesses. It's probably trying to fix up for a big-endian system on my little-endian system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #12 from sqrammi at hotmail dot com 2007-01-26 21:10 --- This was confirmed to be a problem with alignment fixup in the kernel. Do an 'echo 2 > /proc/cpu/alignment' and misaligned accesses are fixed up, and this problem goes away. Misaligned accesses should IMHO not be completely ignored by default in the kernel, so I'll follow up with the ARM linux people. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug target/67246] MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67246 Jeff Hansen changed: What|Removed |Added CC||sqrammi at hotmail dot com --- Comment #8 from Jeff Hansen --- Why would this be a bug in the kernel? Why is gcc trying to load a word or short when it's a 4-bit bitfield?? So you're recommending that we add __attribute__((packed)) to the struct? Is there any other way/option to change this behavior?
[Bug target/67246] MIPS: lw (load word) is generated for byte bitfield, leading to unaligned access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67246 --- Comment #10 from Jeff Hansen --- So you're recommending that we add __attribute__((packed)) to the struct?
[Bug c/30581] New: Deeply inlined static functions break stack creation
I have confirmed this bug against 4.1.1 and 4.1.2 (4.1-20070115).
The attached program incorrectly sees h->b as 0x1000, instead of 0x0010 as it
should. I'm not sure if this is an endianness issue, but it only happens if
the stack is fairly complex. If I uncomment the align attribute, the program
outputs the correct value. My target CPU is a Marvell Feroceon, but any
arm926ejs should see this problem.
The toolchain was built using crosstool, using gcc-4.1.x and glibc 2.5. I can
supply anything necessary to build the toolchain.
arm-soft-oabi.dat:
KERNELCONFIG=`pwd`/arm-tls-oabi.config
TARGET=arm-926ejs-linux-gnu
GCC_EXTRA_CONFIG='--with-cpu=arm926ej-s --with-float=soft
"--enable-cxx-flags=-mcpu=arm926ej-s -msoft-float"'
GLIBC_EXTRA_CONFIG='--without-fp'
TARGET_CFLAGS=-O
gcc-4.1.x-glibc-2.5-nptl.dat:
BINUTILS_DIR=binutils-2.17.50.0.9
GCC_DIR=gcc-4.1-20070115
GLIBC_DIR=glibc-2.5
GLIBCPORTS_FILENAME=glibc-ports-2.5
GLIBC_ADDON_OPTIONS=ports,nptl
GDB_DIR=gdb-6.5
LINUX_DIR=linux-2.6.19.2
--
Summary: Deeply inlined static functions break stack creation
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sqrammi at hotmail dot com
GCC build triplet: arm-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: arm-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
[Bug c/30581] Deeply inlined static functions break stack creation
--- Comment #1 from sqrammi at hotmail dot com 2007-01-24 23:44 --- Created an attachment (id=12953) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12953&action=view) Source file to produce this bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30581
