Re: warnings compiling Emacs 22 on amd64

[Stefan Monnier]

>> If the argument i is of type int (32bit), then the compiler is sufficiently
>> clever to infer that the comparisons will always return the same value
>> (even though we cast that value to EMACS_INT (64bit) in between).

> Is it really that smart?  Will it also be that smart if we do some
> arithmetics, like `(EMACS_INT)i + 0L' or `(EMACS_INT)i*1L'?

Could be, or maybe not.  My guess is that the optimization scheme uses an
abstract domain where integer values are approximated by bounds (so a char
is approximated by [-128..127]), so "+1" should be handled just fine (after
conversion to EMACS_INT this same char is still [-128..127] and since "1"
is most likely approximated by [1..1], then the sum of the two will be
approximated by [-127..128]).

But why should it matter whether it does or not?

>> > If FIXNUM_OVERFLOW_P should always return zero on 64-bit machines,
>> It shouldn't.  There are a few sites where it does, tho.
> Are these few cases those for which the argument of FIXNUM_OVERFLOW_P
> is an int (rather than a long)?

At least these, maybe others as well.

>> > Does this fix the problem?
>> What problem?
> The warning messages.

>> There is no problem other than unhelpful warnings.
>> The warnings basically say "hey guys, I found an optimization opportunity"
>> and we're very happy that gcc does the optimization: it saves us from trying
>> to write ugly and brittle code such as the one above.  Too bad gcc is a bit
>> noisy in this case.  We can probably remove those warnings with the
>> right -Wno-foo invocation.

> I don't think we want to remove this warning in general with -W-no-*
> because it could point out bugs, and I don't think we like to see
> warnings where the code is correct.  You are free to think otherwise,
> of course, but please let us try to resolve that anyway.

I agree with the intention but I wouldn't want to "fix" the warnings by
applying the optimization by hand, unless the code after optimization is
just as clean and maintainable.


        Stefan