From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18690 invoked by alias); 15 Oct 2002 20:13:32 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 18681 invoked from network); 15 Oct 2002 20:13:32 -0000 Received: from unknown (HELO web80311.mail.yahoo.com) (66.218.79.27) by sources.redhat.com with SMTP; 15 Oct 2002 20:13:32 -0000 Message-ID: <20021015201332.21851.qmail@web80311.mail.yahoo.com> Received: from [65.90.116.89] by web80311.mail.yahoo.com via HTTP; Tue, 15 Oct 2002 13:13:32 PDT Date: Tue, 15 Oct 2002 14:06:00 -0000 From: Kevin Lawton Subject: Re: Request of new __attribute__ for switch statements (elimination of the bounds check) To: Jamie Lokier , Michael Matz Cc: gcc@gcc.gnu.org In-Reply-To: <20021015200247.GA31811@bjl1.asuk.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-10/txt/msg00864.txt.bz2 For the most efficient solution here, if one could narrow down to being compiled only on GCC, I'd use computed gotos. This gets rid of the limit check altogether and let's me calculate the branch address as early as possible to optimize the CPU's speculation. The compiler may be able to do some of this however. But the real issue is in trying to play nice with non-GCC compilers. If whatever solution implemented, requires anything extensions other than something that can disappear easily with a macro (like the __attribute__ directives can), then nothing has been solved. The __attibute_ angle is simple, I can exactly tell the compiler when I care to have it applied (maybe only one case in all the code), and it disappears quickly with an #ifdef'd macro. Which makes it play nice with "other" compilers. -Kevin --- Jamie Lokier wrote: > Michael Matz wrote: > > On Tue, 15 Oct 2002, Jamie Lokier wrote: > > > [... strict enum proposal ...] > > > > > > (It would be appropriate to add a warning when an enum with this > > > attribute is converted to an integer). > > > > That's not the problematic direction. I can't see why converting such an > > enum to an integer would be dangerous. But converting _to_ such an enum > > should get a warning. > > Good point. (I was thinking of enum arithmetic like `CAT | DOG' being > disallowed for strict enums -- I believe that is defined for standard enums). > > -- Jamie __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com