From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3005 invoked by alias); 18 Nov 2007 14:44:36 -0000 Received: (qmail 2886 invoked by uid 48); 18 Nov 2007 14:44:26 -0000 Date: Sun, 18 Nov 2007 14:44:00 -0000 Message-ID: <20071118144426.2884.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/28581] Illegal loading the address of a label with -O2 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "sparc64 at rediffmail dot com" 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: 2007-11/txt/msg01682.txt.bz2 ------- Comment #11 from sparc64 at rediffmail dot com 2007-11-18 14:44 ------- > I agree that we should clarify the documentation if we definitely rule the > code as being invalid. Since "&&" is a C extension, I believe one can reserve the right to limit how long it extends. But this limitation, which hits only when "optimization" kicks in is very very misleading. And, I find such a limitation spoiling the whole idea of having the extension. For example, the original post posted by "inaoka" tries to pass a pointer loaded with "&&" extension. And, he has run into trouble. The point here is that the "Optimization" rule is very quick to rule out that the usage of "&&" is only for "goto"s. This precludes a beautiful C extension from being as beautiful as it ought to be. It would be really nice on the part of GCC developers to fix this. I am sure this must be a very small thing to fix (apologies if not). Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581