This is on py3k, with gcc 4.4.3:

/home/antoine/py3k/__svn__/Modules/socketmodule.c: In function 'socket_gethostbyaddr':
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3238: warning: dereferencing pointer 'sa' does break strict-aliasing rules
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3208: note: initialized from here
/home/antoine/py3k/__svn__/Modules/socketmodule.c: In function 'socket_gethostbyname_ex':
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3183: warning: dereferencing pointer 'sa' does break strict-aliasing rules
/home/antoine/py3k/__svn__/Modules/socketmodule.c:3181: note: initialized from here

Same with gcc 4.4.4, in socket and another file:

Modules/_multiprocessing/multiprocessing.c: In function ‘multiprocessing_sendfd’:
Modules/_multiprocessing/multiprocessing.c:125: warning: dereferencing type-punned pointer will break strict-aliasing rules
Modules/_multiprocessing/multiprocessing.c: In function ‘multiprocessing_recvfd’:
Modules/_multiprocessing/multiprocessing.c:168: warning: dereferencing type-punned pointer will break strict-aliasing rules

I can't reproduce both these cases with gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 on i386 using the current default branch (70943:024827a9db64).

For reference, the warnings are partially explained here:

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-825

http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Warning-Options.html#index-Wstrict_002daliasing-337

I get these warnings with GCC (Ubuntu/Linaro 4.4.4-14ubuntu5)
4.4.5 [i386], plus an additional one from the new recvmsg() code.
I haven't tried GCC 4.5 or later, but as the docs imply, the
warnings will not appear in debugging builds.

I take it GCC is referring to C99 section 6.5, paragraphs 6 and 7
here, but I'm not sure exactly how much these are intended to
prohibit with regard to the (mis)use of unions, or how strictly
GCC actually enforces them.

The attached socket-aliasing-sas2sa.diff is enough to get rid of
the warnings with GCC 4.4.4 - it adds add a "struct sockaddr"
member to the sock_addr_t union type, changes the SAS2SA() macro
to take the address of this member instead of using a cast, and
modifies socket_gethostbyaddr() and socket_gethostbyname_ex() to
use SAS2SA() (sock_recvmsg_guts() already uses it).

Changing SAS2SA() also gets rid of most of the additional
warnings produced by the "aggressive" warning setting
-Wstrict-aliasing=2.  However, the gethostby* functions still
point to the union object with a pointer variable not matching
the type actually stored in it, which the GCC docs warn against.

To be more conservative, socket-aliasing-union-3.2.diff applies
on top to get rid of these pointers, and instead directly access
the union for each use other than providing a pointer argument to
a function.  socket-aliasing-union-recvmsg-3.3.diff does the same
for 3.3, and makes the complained-about line in
sock_recvmsg_guts() access the union directly as well.

One other consideration here is that the different sockaddr_*
struct types used are likely to come under the "common initial
sequence" rule for unions (C99 6.5.2.3, paragraph 5, or section
A8.3 of K&R 2nd ed.), which might make some more questionable
uses valid.  That said, technically POSIX appears to require only
that the s*_family members of the various sockaddr struct types
have the same offset and type, not that they form part of a
common initial sequence (s*_family need not be the first
structure member - the BSDs for instance place it second,
although it can still be part of a common initial sequence).

New changeset 683a1b1ff15d by Charles-François Natali in branch 'default':
Issue #8623: Fix some strict-aliasing warnings. Patch by David Watson.
http://hg.python.org/cpython/rev/683a1b1ff15d

Thanks for your patches, David.
I've only applied the first one: looking at the second one, I don't think they are really problems (-Wstrict-aliasing=2 is know for generating a lot of false positives).

This change probably should be backported to 3.2 branch.

> This change probably should be backported to 3.2 branch.

I'm not sure about this, I don't feel comfortable backporting a such
path which doesn't solve a "real world problem".

I think the time for backporting to 3.2 has passed. Is there anything else to do for this report?

The Modules/_multiprocessing/multiprocessing.c code was removed in 3.3 (Issue 12981). Therefore I am calling this fixed.