[Scummvm-devel] Wii & Gamecube (resp. PowerPC) vs. unaligned memory access
Johannes Schickel
lordhoto at scummvm.org
Sun May 8 18:33:05 CEST 2011
> 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
More information about the Scummvm-devel
mailing list