From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7492 invoked by alias); 26 Sep 2006 14:17:01 -0000 Received: (qmail 7412 invoked by uid 48); 26 Sep 2006 14:16:52 -0000 Date: Tue, 26 Sep 2006 14:17:00 -0000 Message-ID: <20060926141652.7408.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/28778] [4.0/4.1/4.2 Regression] alias bug with cast and call clobbered In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "acahalan at gmail dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-09/txt/msg02455.txt.bz2 List-Id: ------- Comment #35 from acahalan at gmail dot com 2006-09-26 14:16 ------- (In reply to comment #34) > Subject: Re: [4.0/4.1/4.2 Regression] alias > bug with cast and call clobbered > > On Tue, 2006-09-26 at 04:44 +0000, acahalan at gmail dot com wrote: > > > > Although it wouldn't work for the example code, extending the aliasing behavior > > of (char*) to (void*) would fix the problem for LOTS of code out in the wild. > > People normally use a (void*) when they want a generic pointer type to play > > casting games with. This is a case where the C standard is very far from the > > reality of how people write code. The example code is fairly unusual. > > But C aliasing is not based on pointers but on accesses so it is wrong > to it that way. It's also wrong to assume that unions can be used for type punning, but so what? It is allowed by gcc. Most real-world code doesn't use unions and definitely doesn't do like the example above. Typically (void*) is used for passing things around, and there are also the trivial aliasing cases which gcc can warn about. (if you can warn about it, you can instead do what the programmer wanted) Evidence: this bug has existed for ages, meanwhile aliasing violations keep getting reported as compiler bugs. Since gcc introduced strict aliasing, I've worked at three places doing software development. All were embedded/OS related, so I would say the people are/were hard-core programmers with a clue. Everybody is shocked when I explain strict-aliasing, and all but one have been horrified. So, to get back to this bug specifically: treating a (void*) arg the same as a (char*) arg will cover up the problem for nearly everyone. Sadly it won't fix the example given, which is legit to a language lawyer and a nonsense piece of shit to any normal programmer. Oh well. By treating (void*) the same as (char*), you can demote the bug severity greatly and move on. BTW, in the testcase, the following line should generate a warning: glChoosePixelFormat((GLint*)blist); I don't get any warning at all, even with -Wstrict-aliasing=2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778