Messages in this thread | | | Date | Wed, 26 Feb 2003 17:22:13 -0500 | From | Jakub Jelinek <> | Subject | Re: Invalid compilation without -fno-strict-aliasing |
| |
On Wed, Feb 26, 2003 at 03:57:54PM -0500, Daniel Jacobowitz wrote: > > > > > if((stream + event_len) < ends) { > > > > > iwe->len = event_len; > > > > > memcpy(stream, (char *) iwe, event_len); > > > > > stream += event_len; > > > > > } > > > > > return stream;
> > > > The compiler is free to assume char *stream and struct iw_event *iwe > > > > point to separate areas of memory, due to strict aliasing.
No.
> Stream is not the same storage as iwe, so this is hardly the issue. > Writes to stream don't affect iwe. The problem was the assignment to > iwe->len being moved after the access, according to the report.
GCC can do that with -fstrict-aliasing: All calls to this inline function are done with constant event_len. E.g. in case of event_len = IW_EV_UINT_LEN, memcpy macro expands to __constant_memcpy which does: *(unsigned long *)to = *(const unsigned long *)from; *(1+(unsigned long *)to) = *(1+(const unsigned long *)from); iwe->len is unsigned short and the code writes the value as unsigned short (iwe->len = 8) and then reads the same memory as unsigned long (something = *(const unsigned long *)(char *)iwe). But those two types cannot alias and thus gcc can reorder them.
To fix that, __constant_memcpy would have to access the data through union, ir you could as well forget about __constant_memcpy and use __builtin_memcpy where gcc will take care about the constant copying.
Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |