This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Request of new __attribute__ for switch statements (elimination of the bounds check)


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 <egcs@tantalophile.demon.co.uk> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]