[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warnings compiling Emacs 22 on amd64

From: Eli Zaretskii
Subject: Re: warnings compiling Emacs 22 on amd64
Date: Mon, 15 Jan 2007 23:48:10 +0200

> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
> Date: Mon, 15 Jan 2007 09:58:09 -0500
>     The problem is gcc's, really.
> If it is a bug in GCC, we need to report the bug.
> What exactly is the bug?

I doubt that you'd be able to convince the GCC developers that this is
a bug; more likely it's a misfeature.  But it would be good if this
warning could be suppressed by default, and only appear under -Wall or
some other warning option.

The problem is that when presented with a code like this:

      if ((int)foo > (int)SHRT_MAX || (int)foo < (int)SHRT_MIN)

where `foo' is declared `short', GCC complains about the fact that the
comparison is always false, because it is smart enough to notice that
a short variable `foo' cannot be possibly outside valid limits for a
short.  Even casting to int, as above, doesn't help: GCC is too smart.

This misfeature makes it impossible to write portable macros that need
to work with different implementations of the same typedef that have
different widths on different platforms.  A case in point is our
definition of FIXNUM_OVERFLOW_P:

    #define FIXNUM_OVERFLOW_P(i) \

This triggers the warnings shown below on 64-bit machines, where
EMACS_INT is a 64-bit wide integral type, if this macro is called with
`i' that is a 32-bit int.

Here, try compiling the following nonsense:

    #include <limits.h>

    int bar (short foo)
      if ((int)foo > (int)SHRT_MAX || (int)foo < (int)SHRT_MIN)
        return 1;
      return 0;

and you will see this:

  ttt.c: In function `bar':
  ttt.c:5: warning: comparison is always false due to limited range of data type
  ttt.c:5: warning: comparison is always false due to limited range of data type

(Btw, Stefan, you were wrong: this warning is issued even under -O0,
so it has nothing to do with optimizations.)

My workaround is to assign the value in question to the wider type,
like this:

    int bar (short foo)
      int ifoo = foo;
      if (ifoo > (int)SHRT_MAX || ifoo < (int)SHRT_MIN)
        return 1;
      return 0;

This avoids the warning, and under -O2 should produce the same code.
Of course, if GCC insists on being too smart to our peril, the warning
will resurface some day.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]