Ahh, I see, the actual fix is not the variable, but the wrong order of operands in the assembly, I missed that.
Ah, I thought it was just a side note. You rarely miss stuff like that ;)

But the additional prototypes are still pointless ;-)

Btw, I'm all for enabling extra warnings, but the following ones seem not very useful or will probably create a lot of noise:
-Wunused-but-set-variable (we have this in many places)
-Wmaybe-uninitialized (gives too many warnings, since initializing something by passing it to a function cases this warning)
-Wmissing-prototypes (in the kernel no functions are declared static (wrong IMO, but that's how it is), which will lead to many warnings)
-Wmissing-declarations (see above)
-Wcast-align (explicitly casting to a higher alignment can be useful and there is no other way to avoid this warning)
-Wwrite-strings (I fear that we don't always use the const modifier properly to allow this)

-Wuninitialized is already implicitly defined by -Wall

The following additional warnings seem to be reasonable by a quick glance:
-Wframe-larger-than=len / -Wstack-usage=len (at least for kernel mode code)
-Wbad-function-cast
-Wsign-compare (enabled on MSVC by default)
-Wsign-conversion
-Wlogical-op
-Waggregate-return
-Winvalid-pch
NP, we need then to decide on the new set of warnings (that brings more benefits without creating noise/pointless diagnostics), fix the revealed issues, and after we're done, we proceed permanently with the set, so that the future check-ins would be subject to it. Fortunately, GCC has the same concept of disabling warnings for a code block (http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html) so we may use that if needed, in order to keep warnings that have just a few pointless places.

Sounds like a plan ?

Regards,
Amine.