------- Comment #4 from enrio at online dot no 2009-10-23 10:06 -------
In my example code there is a pointer to a struct that has an array as the
first member. I appears that the compiler treats the pointer as a pointer to
this first member, and flags a loop that writes outside the first member
already at the first iteration. The code uses an integer offset from the
pointer, and the pointer itself is not changed.
If the members are reordered so that an unsigned char member becomes the first
one, the warning goes away. (But the example comes from a driver, and the
struct maps hardware registers, so it cannot be reordered at a whim.)
If the loop is modified so that it begins within the array, the warning goes
away, even the iterator has a constant end condition - outside the array.
If the loop is modified so that it begins exactly at the first byte after the
array, there are four warnings rather than three. It makes me wonder if the
compiler is generating code that does access the memory locations intended.
Since we got the strict aliasing optimizations, we probably should learn to
rewrite such old code using a union, or properly accessing the structure
members one by one. I just tried the union approach:
union mac_u {
struct mac_regs regs;
u8 bytes[sizeof(struct mac_regs)];
};
I changed the function argument to a pointer to this union rather than to a
struct mac_regs, initialized the local pointer variable from the 'bytes' union
member, and the warning went away. This appears to be the way to properly tell
the compiler how one plans to use the pointer.
Also if the pointer is incremented to point directly at the bytes of interest
rather than being indexed, the warning goes away.
--
enrio at online dot no changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |enrio at online dot no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37130
