[Scummvm-devel] Broken Sword 2 problem

[Willem Jan Palenstijn]

On Wed, Sep 01, 2010 at 03:20:34PM +0300, yotam barnoy wrote:
> On Wed, Sep 1, 2010 at 3:06 PM, Willem Jan Palenstijn <wjp at usecode.org> wrote:
> >
> > Hm, I'm not convinced. The only access to that memory is through this
> > Unaligned32 struct, as far as this code is concerned, so there shouldn't be
> > any aliasing.
> 
> When the compiler optimizes for example header.h's getLogicLevel() and
> setLogicLevel() in BS2, we have a byte *_addr ie. a byte array. But
> when it's accessed via READ_LE_UINT32, a struct is aliased onto it.
> The compiler assumes they can't be in the same place in memory and
> optimizes getLogicLevel(), returning the same value without bothering
> to read it again.

But the byte array itself isn't accessed directly at all. It's only accessed
via this struct, so the question if things alias with this byte array itself
shouldn't be relevant. I think. :-)

(And don't char/byte arrays alias with everything anyway as an exception?)

> > But the __may_alias__ you mention does sound like it would likely be safer.
> > (And it does work for the example I was trying.) Do you know in which
> > version of gcc it was added? The oldest one if I have easily available is
> > 4.1.2 and it works there.
> 
> It works here as well.
> Not sure exactly how old it is, but I found a reference on google
> using __may_alias__ that's for gcc 3.3, though it seems at that point
> they hadn't turned on strict aliasing by default for -O2 and -O3.

Ok, that sounds good. This Unaligned struct is in a #elif defined(__GNUC__) &&
(__GNUC__ >= 4) block in endian.h, so adding __may_alias__ shouldn't be an
issue then.


-Willem Jan