From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15086 invoked by alias); 26 Sep 2006 15:33:39 -0000 Received: (qmail 14802 invoked by uid 48); 26 Sep 2006 15:33:29 -0000 Date: Tue, 26 Sep 2006 15:33:00 -0000 Message-ID: <20060926153329.14801.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/msg02464.txt.bz2 List-Id: ------- Comment #37 from acahalan at gmail dot com 2006-09-26 15:33 ------- (In reply to comment #36) > > Evidence: this bug has existed for ages, meanwhile aliasing violations keep > > getting reported as compiler bugs. > This bug (PR28778) has only existed for the last two major releases which is > not ages. IMHO that qualifies as "ages". If the bug has survived that long, it can't be all that major. People have learned that -fno-strict-aliasing is the cure-all for mystery 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. > > And Aliasing rules in C have existed now for at least 17 years. Your point? Fact: strict aliasing horrifies most software developers. The wording in a seriously expensive ISO document doesn't change the simple fact that people don't write code that way. Books intended to teach the language don't mention this "feature" of the language. I don't just mean "Learn C in 5 days", but college textbooks as well. > > 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. > > Again, aliasing in C has to do with accesses and nothing to the type of > pointers. I know. I'm perfectly clear on that. You don't need to remind me. If the example code had used (char*), the bug would not have shown itself. Great. Most real-world code would use (void*) for this. That breaks. If (void*) is treated the same as (char*) though, the bug goes away. That is, an access to "void" (which is pretty much impossible except for computed goto) should be considered to be something which could happen and which could alias with anything. Probably this fixes 99% of the real-world occurances of this bug. Given such a change, the remaining bug is an insignificant violation of the C standard. For the next release it can be either ignored or addressed by having both -std=c99 and -std=c89 disable strict aliasing. > > BTW, in the testcase, the following line should generate a warning: > > > > glChoosePixelFormat((GLint*)blist); > > Why there is nothing questionable about it until glChoosePixelFormat deferences > the agrument in the wrong type. It's not illegal, and thus not an error, but it damn well is questionable. Normal people cast to/from (void*), because this comes free in C or because it seems clean to use (void*) as the generic pointer type. People trying to avoid aliasing problems cast to/form (char*), and use (char*) as the generic pointer type. Other casts between pointers to types not allowed to alias are highly suspect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28778