This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Bug in highest_pow2_factor
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: mark at codesourcery dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 2 May 02 17:26:01 EDT
- Subject: Re: Bug in highest_pow2_factor
We have lots of potential regressions. I'm going to concern myself
with the ones we know about. We'll fix the ones we don't know about
when we know about them. Show me a C, Objective-C, C++, Java, or
Fortran program that behaves worse than it did before.
This is a very pragmatic attitude: if someone finds it compiling their
code, we fix it. If they're maniacal enough to come with a crazy test
case, we fix it. If nobody finds it in real code, and nobody cares
enough to come up with the crazy test case, I figure it doesn't matter
too much.
Well, I have an *Ada* case that is a "regression" if you define that as
meaning something that used to work and doesn't anymore. It's only
"potential" for the other languages. I suppose if I spent enough time,
I could indeed construct a case, but it isn't clear it's worth the time.
> I thought of limiting it to BIGGEST_ALIGNMENT (or actually
> HIGH_OFILE_ALIGNMENT, or whatever it's called), but I'm not sure
> there's a point in that.
It's a reasonable definition of "small".
Yes, but only for the *outermost* call, not necessarily the recursive calls.
Well, then why do you say it makes sense to return a signed quantity?
As I said, I could argue in either direction, so I'll agree that making it
unsigned is reasonable.
That, by the way, would also fix this bug without the change I
proposed. Is that something reasonable for 3.1?