From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2018 invoked by alias); 6 Aug 2010 13:55:30 -0000 Received: (qmail 1955 invoked by uid 48); 6 Aug 2010 13:55:17 -0000 Date: Fri, 06 Aug 2010 13:55:00 -0000 Message-ID: <20100806135517.1954.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c/45204] gcc generates incorrect code In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenth at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00420.txt.bz2 ------- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-06 13:55 ------- (In reply to comment #3) > Maybe I should add that the 0.6.0-beta1 release in GIT passed uintptr_t - sized > structures by value and the compiler spotted the aliasing, which is why I > introduced the pointer -> uintptr_t -> pointer hacks to begin with. > > Without passing structs by value the compiler doesn't report the aliasing > problems. > > I'm being sincere when I say that if the compiler really can't spot aliasing > problems then -fno-strict-aliasing should be on by default. The compiler can spot all aliasing that is permitted by the language standard. If you are writing non-C code then you need to tell that to the compiler via -fno-strict-aliasing. Merely adding hacks to avoid the diagnostic (which can't be perfect, if we could detect the aliasing we wouldn't optimize based on the fact that it isn't there). -- rguenth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45204