This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Request of new __attribute__ for switch statements (elimination of the bounds check)
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>,Kevin Lawton <kevinlawton2001 at yahoo dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 15 Oct 2002 17:49:29 -0700
- Subject: Re: Request of new __attribute__ for switch statements (elimination of the bounds check)
- References: <20021015032827.GA15067@codesourcery.com> <Pine.LNX.4.33.0210151625490.20702-100000@wotan.suse.de>
On Tue, Oct 15, 2002 at 04:32:34PM +0200, Michael Matz wrote:
> Well, if you have data corruption, hmm, well, you're screwed ;-) The same
> happens, when you access a pointer retrieved from corrupted memory.
Sure. The question is how _soon_ you will be screwed to the point
that the program crashes. Ideally this happens as soon after the
actual data corruption event as possible.
(If I had a nickel for every time I've wanted a "step backward"
command in gdb...)
> > This does not mean that your idea is a bad one; the attribute could be
> > used for stricter type checking and more effective warnings, which is
> > a good thing. I just don't like the idea of using it to optimize out
> > bounds checks.
>
> Why not? Possibility for data corruption is no argument for not doing
> things. Remember also, that there are other syntactic means to enable
> certain optimizations, 'restrict' or __builtin_expect for example.
It's just that I see removing the bounds checks on a switch statement
as a marginal optimization compared to the risk. I've never seen a
switch be the bottleneck in anything.
Your mileage may vary.
zw