[Scummvm-devel] Wii & Gamecube (resp. PowerPC) vs. unaligned memory access

[Johannes Schickel]

> Regarding 3: According to some googling, the "may_alias" attribute has been
> around since GCC 3.3 (and "packed" since 2.x). Any reason we restrict this
> codepath in endian.h to GCC 4.x ? And out of curiosity, why the trick with
> the packed struct (a comment in endian.h explaining that would be helpful
> for future generations, too ;).
> 

As explained in the comments above the code you talk about starting with gcc 
4.0, the code generators should output CPU specific instructions for unaligned 
data with the code used in that path. Since the idea behind that code path was 
back then to use the (probably) more efficient CPU specific instructions it was 
only limited to alignment requiring CPU types. The aliasing might have been a 
problem which was overlooked (or not occuring!) for the non-alignment code 
path.

In fact our READ_FOO/WRITE_FOO inline functions might be unproblemtatic in 
some cases:

- They are used on character "arrays" (thus uint8 * etc.), since a character 
type is allowed to alias every other type
- They are used on the respective uint16/int16 type in case of READ_UINT16 or 
uint32/int32 type in case of READ_UINT32

In any case it might be safer to just not enforce ANSI aliasing rules. So I 
have no problem passing -fno-strict-aliasing for g++.

> Anybody know what the status here is with regards to clang, MSVC, ICC, ...
> ?
> 

icpc (Intel's C++ compiler) supports non-ansi-aliasing rules too and it 
defaults to that. In fact it supports many of the gcc option arguments, thus 
when we pass -fstrict-aliasing, it also assumes we conform to ANSI's aliasing 
rules. Since we do not pass -fstrict-aliasing (or I am too blind to see where) 
all that shouldn't be an issue for icpc, especially since icpc does not 
enabled -fstrict-aliasing with optimization levels like g++ does.

Furthermore icc/icpc does not support "__may_alias__", at least it says it's 
ignored in the tests I made.

Like g++ icpc supports printing warnings when the aliasing rules might be 
violated, but it seems it throws out a whole lot of false positives. At least 
it warns about instances like these:

../git_scummvm/base/plugins.cpp(388) (col. 15): warning #2102: violation of 
ansi-alias rules
../git_scummvm/base/plugins.cpp(388) (col. 15): warning #2102: violation of 
ansi-alias rules

I suspect it might use plain C rules here and thus throw warnings in case C++ 
has different rules.

I wrote a different mail to -devel a bit earlier which had attachments 
including the warning output of both g++ and icpc about aliasing rule 
breakage, but it seems it was too big for -devel (it awaits moderator approval 
now and I am not sure whether anyone ever checks those mails ;-P), thus I 
dropped this mail now just to avoid any mails missing.

// Johannes