From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16580 invoked by alias); 3 Jul 2005 12:12:54 -0000 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 Received: (qmail 16558 invoked by uid 48); 3 Jul 2005 12:12:48 -0000 Date: Sun, 03 Jul 2005 12:12:00 -0000 Message-ID: <20050703121248.16557.qmail@sourceware.org> From: "gcc2eran at tromer dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050514140942.21568.rguenth@gcc.gnu.org> References: <20050514140942.21568.rguenth@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted X-Bugzilla-Reason: CC X-SW-Source: 2005-07/txt/msg00268.txt.bz2 List-Id: ------- Additional Comments From gcc2eran at tromer dot org 2005-07-03 12:12 ------- To make it easier to evaluate my claim, here are all messages in the thread linked from comment 1 that seemingly contradicy comment 9: Nathan Sidwell: http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html Dale Johannesen: http://gcc.gnu.org/ml/gcc/2005-05/msg00090.html Andrew Haley: http://gcc.gnu.org/ml/gcc/2005-05/msg00144.html All of these, I am sorry to say, misinterpret the standard since they misconstrue the meaning of the term "object" in the C type system. They assume that the object's type is determined by the way it was created (which is indeed the usual meaning in other languages), whereas the standard quite clearly defines an object's type to be determined by the lvalue referencing it. To give one example of this confusion, here is what Dale Johannesen said: "the standard consistently talks about the type of the object, not the type of the lvalue, when describing volatile." And here is what N1124 [6.3.2.1/1] says: "When an object is said to have a particular type, the type is specified by the lvalue used to designate the object." See my point? I admit to earning my language lawyer diploma on languages other than C, but the evidence in comment 9 seems very firm to me. Does anyone see any flaw in it? If not, then shouldn't this bug be reopened? Hey, we should be *happy* that we found a standard-compliance excluse to fix the code-breaking regression and make those casts work like everybody wanted! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568