From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27372 invoked by alias); 17 Feb 2003 16:56:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 27338 invoked by uid 71); 17 Feb 2003 16:56:01 -0000 Date: Mon, 17 Feb 2003 16:56:00 -0000 Message-ID: <20030217165601.27327.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Wolfgang Bangerth Subject: Re: middle-end/9725: Invalid dependency determination Reply-To: Wolfgang Bangerth X-SW-Source: 2003-02/txt/msg00720.txt.bz2 List-Id: The following reply was made to PR middle-end/9725; it has been noted by GNATS. From: Wolfgang Bangerth To: Jan Beulich Cc: gcc-bugs@gcc.gnu.org, Subject: Re: middle-end/9725: Invalid dependency determination Date: Mon, 17 Feb 2003 10:49:29 -0600 (CST) > I was fearing you would say this. But I can in no way agree - the code > presented is valid C, and hence should work at any optimization level. What makes you think so? gcc's info pages show `-fstrict-aliasing' Allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++), this activates optimizations based on the type of expressions. In particular, an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same. For example, an `unsigned int' can alias an `int', but not a `void*' or a `double'. A character type may alias any other type. In your code you try to pretend that a variable of type "struct S" resides at the place of a long long. That's exactly the case that's covered above, which in turn exactly parallels what the standard says. W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ticam.utexas.edu www: http://www.ticam.utexas.edu/~bangerth/