From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13040 invoked by alias); 27 Jul 2005 22:23:11 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 13030 invoked by uid 22791); 27 Jul 2005 22:23:08 -0000 Received: from yosemite.airs.com (HELO yosemite.airs.com) (205.217.158.180) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Wed, 27 Jul 2005 22:23:08 +0000 Received: (qmail 20380 invoked by uid 10); 27 Jul 2005 22:23:05 -0000 Received: (qmail 3046 invoked by uid 500); 27 Jul 2005 22:22:58 -0000 Mail-Followup-To: gcc-help@gcc.gnu.org, truedfx@gentoo.org To: =?utf-8?b?SGFyYWxkIHZhbiBExLNr?= Cc: gcc-help@gcc.gnu.org Subject: Re: -fstrict-aliasing, -Wstrict-aliasing=2, and indirect conversions References: <42E6CE1E.3080200@gentoo.org> <42E7FB56.6010205@gentoo.org> From: Ian Lance Taylor Date: Wed, 27 Jul 2005 22:23:00 -0000 In-Reply-To: <42E7FB56.6010205@gentoo.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2005-07/txt/msg00304.txt.bz2 Harald van D=C4=B3k writes: > Thank you for your quick reply. Your patch has been very helpful. It > doesn't seem to catch these similar cases, though: >=20 > int main() { > int a =3D 1; >=20 > void *p1 =3D (void *) &a; > * (short *) p1 =3D 2; >=20 > char *p2 =3D (char *) &a; > * (short *) p2 =3D 3; >=20 > return a; > } >=20 > This still returns 1 without a warning. (I am now using > 4.1.0-20050723, so that I could try your patch.) That is true. I'm frankly not too sure what should be done. If we enable the warnings for these cases, the effect will be to warn about almost every type cast which is not to or from void* or char*. That doesn't seem very useful. On the other hand strict aliasing is a serious problem. Perhaps the problem is that the warning currently triggers on the cast, but should perhaps somehow trigger on the dereference. I think the bug occurs if you have these statements: P2 =3D (TYPE *) P1; *P1; *P2; in some order in the same function. However, I don't know whether the compiler has the data structures we would need to efficiently determine whether this happens. Could you please open a bugzilla PR for this at http://gcc.gnu.org/bugzilla/ ? That way at least the issue will get recorded. Thanks. Ian