lkml.org 
[lkml]   [1996]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: gcc 2.7.2 common subexpression bug with possible kernel imp
On 10 Apr 96 at 10:49, Tom May wrote:

> Hi,
>
> I just sent a bug report and patch to bug-gcc concerning a problem in
> gcc 2.7.2 common subexpression elimination that has possible
> implications in the linux kernel. Until it is fixed, I would
> recommend compiling with the "-fno-cse-skip-blocks" switch. This bug
> may exist in earlier compilers also, but I don't know for sure.
>
[...]
> Example: The test for `p->len == 0' is being deleted by cse because of
> the `p->len = 0' a few lines earlier. This is incorrect, because
> __memcpy() may clobber that memory.
>
> extern inline void * __memcpy(void * to, const void * from, unsigned n)
> {
[...]
> }
>
> struct thing {
> int len;
> int data;
> };
>
> void spud (struct thing *in, int copy)
> {
> unsigned char buf[sizeof(struct thing)+40];
> struct thing * p = (struct thing*)buf;

This is a classical aliasing situation; you are modifying *p
indirectly via buf. I think almost every compiler assumes
"no-pointer-aliasing" when optimizing; otherwise it's very hard to
optimize.

>
> p->len = 0;
> if (copy)
> __memcpy (buf, in, sizeof(struct thing) + in->len);

__memcpy (p, in, sizeof(struct thing) + in->len);

What about that solution?

> if (p->len == 0)
> {
> p->len = 1;
> }
> }
>
> That's all for now.
> Tom.

Ulrich


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.032 / U:1.996 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site