On Tue, 4 Oct 2005, Leopold Toetsch via RT wrote:

> On Oct 4, 2005, at 19:06, Andrew Dougherty wrote:

> >   src/inter_create.c:400: warning: dereferencing type-punned pointer 
> > will
> >       break strict-aliasing rules
> 
> The line reads:
> 
>          LVALUE_CAST(char *, p) += ALIGNED_CTX_SIZE;
> 
> The intent is of course, to bump the context pointer by the needed 
> size. The problem is that the needed size does not correlate with the 
> size of the struct.
> 
> Anyway, does:
> 
>     p = (struct Parrot_Context *) ( (char *) p + ALIGNED_CTX_SIZE );
> 
> help, or better is it "more correct"?

While this does indeed replace the warning by a different warning ("cast 
increases required alignment of target type"), it doesn't fix the problem 
-- parrot still panics.  (And since we're not accessing the memory through 
a (char *), I'm not sure it should make any difference.  I'm not a 
language lawyer, and I haven't read the standard closely.)

Anyway, from what I've been able to gather, gcc's warnings on aliasing are 
neither complete nor always 100% on-the-mark.  In this case, for example, 
I took the apparently offending function, moved it to a different file 
(inter_create2.c) and recompiled that function with and without 
-fno-strict-aliasing.  It made no difference.  However, recompiling the 
remaining functions in inter_create.c with -fno-strict-aliasing *did* make 
the problem go away.

So the compiler's doing some optimization somewhere else in the file that 
it's not warning about, and that optimization only happens with 
-fstrict-aliasing.  I suspect by continuing my divide and conquer strategy 
on inter_create.c, one could probably isolate it to a single function, and 
then, perhaps, understand whether it's a compiler optimizer error or 
whether it's a programming error.

Since this can be reproduced with gcc-3.4 on Intel, I'd appreciate it if 
someone with a faster machine and/or a deeper understanding of what the 
code is actually trying to do could hunt it down.

> We have a lot of similar code e.g. inside GC, where pointers to PMCs or 
> to PObjs are icnremented by the actual size of the object and not by 
> the size of some structure.

Yes, I know, but I'm not fluent enough with parrot's internals to follow 
it well, so I get lost every time I try to dig in deeply.

-- 
    Andy Dougherty              [EMAIL PROTECTED]

Reply via email to