On 21/01/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On Sun, 2007-01-21 at 01:49 -0500, Richard Stallman wrote:
> It would be nice to have such a construct in GNU C, something that
> could be used in a macro expansion, and would turn off _all_ warnings
> for the code within the construct.
http:
Eric Botcazou wrote:
Since GNU Ada already has a pragma Warnings On/Off, if more than
one front-end define it may be it's worth having a flag
going through the backend to suppress backend warnings too.
There is already TREE_NO_WARNING and the Ada compiler sets it on entities
subject to pragma
> Since GNU Ada already has a pragma Warnings On/Off, if more than
> one front-end define it may be it's worth having a flag
> going through the backend to suppress backend warnings too.
There is already TREE_NO_WARNING and the Ada compiler sets it on entities
subject to pragma Warnings (entity,
Laurent GUERBY wrote:
Since GNU Ada already has a pragma Warnings On/Off, if more than
one front-end define it may be it's worth having a flag
going through the backend to suppress backend warnings too.
Laurent
Note that the Warnings On/Off in GNAT works on syntactic positions
of flags, not
On Sat, 2007-01-20 at 22:59 -0800, Andrew Pinski wrote:
> On Sun, 2007-01-21 at 01:49 -0500, Richard Stallman wrote:
> > It would be nice to have such a construct in GNU C, something that
> > could be used in a macro expansion, and would turn off _all_ warnings
> > for the code within the construct
> It would be nice to have such a construct in GNU C, something that
> could be used in a macro expansion, and would turn off _all_ warnings
> for the code within the construct.
Similar to __extension__?
I agree that's a good idea.
Andrew Pinski wrote:
On Sun, 2007-01-21 at 01:49 -0500, Richard Stallman wrote:
It would be nice to have such a construct in GNU C, something that
could be used in a macro expansion, and would turn off _all_ warnings
for the code within the construct.
http://gcc.gnu.org/onlinedocs/gcc/Diagnost
On Sun, 2007-01-21 at 01:49 -0500, Richard Stallman wrote:
> It would be nice to have such a construct in GNU C, something that
> could be used in a macro expansion, and would turn off _all_ warnings
> for the code within the construct.
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
Bu
Nevertheless, I (and others seem to agree) would like to name that
particular warning, so it can be enabled/disabled. Also, there is a
similar warning for unsigned >= 0 and unsigned < 0 in -Wextra. There
are bug reports about the inconsistency (http://gcc.gnu.org/PR23587).
So,
On 19/01/07, Richard Stallman <[EMAIL PROTECTED]> wrote:
No. This is an undocumented, unnamed, unconditional warning.
We are working on fixing those for GCC 4.3 :-)
Could you explain what that means? What exactly is the problem that
you are talking about fixing? What change is planned
No. This is an undocumented, unnamed, unconditional warning.
We are working on fixing those for GCC 4.3 :-)
Could you explain what that means? What exactly is the problem that
you are talking about fixing? What change is planned?
On 18/01/07, Richard Stallman <[EMAIL PROTECTED]> wrote:
Is this documented as a way to avoid problems with that warning?
No. This is an undocumented, unnamed, unconditional warning.
We are working on fixing those for GCC 4.3 :-)
Cheers,
Manuel.
I think this warning is starting to happen for valid code because of
64-bit machines.
You can avoid it by using unsigned types. I think that something like
this will do the trick:
#define FIXNUM_OVERFLOW_P(i)\
((unsigned long long)(i) > M
Richard Stallman <[EMAIL PROTECTED]> writes:
> In Emacs we have a macro that tends to produce the warning
>
>comparison is always false due to limited range of data type
>
> when compiling for 64-bit machines. EMACS_INT is 64 bits
> in that case. Here is the macro:
>
> #define FIXNUM_OVER
Richard Stallman wrote:
If not, I think one ought to be implemented. I have a suggestion for
what it could look like:
#define FIXNUM_OVERFLOW_P(i) \
((EMACS_INT)(int)(i) > MOST_POSITIVE_FIXNUM \
|| (EMACS_INT)(int)(i) < MOST_NEGATIVE_FIXNUM)
The casts to int could be interpreted as meanin
15 matches
Mail list logo
