#define FIXNUM_OVERFLOW_P(i) \
((EMACS_INT)(int)(i) MOST_POSITIVE_FIXNUM \
|| (EMACS_INT)(int)(i) MOST_NEGATIVE_FIXNUM)
This would break code where `i' is a long.
Yes, that is true.
___
emacs-pretest-bug mailing
Kevin Gallagher [EMAIL PROTECTED] writes:
Some compilers support the use of #pragma directives to disable
certain warnings it would
otherwise generate for the lines wrapped within those specific #pragma
directives. Perhaps
GCC could be extended to support this.
I think this, or some
Richard Stallman [EMAIL PROTECTED] writes:
I think we should demand some way to turn off the warning in specific
places. Does GCC have a feature to turn off warnings in a specific
piece of code? I don't remember. It would be a good feature to have.
However, a specific feature just for
#define FIXNUM_OVERFLOW_P(i) \
((EMACS_INT)(int)(i) MOST_POSITIVE_FIXNUM \
|| (EMACS_INT)(int)(i) MOST_NEGATIVE_FIXNUM)
This would break code where `i' is a long.
In any case, the first thing to do is to bring it to the attention of the
gcc maintainers. Even if they don't
From: Richard Stallman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
Date: Tue, 16 Jan 2007 00:16:54 -0500
I think we should demand some way to turn off the warning in specific
places. Does GCC have a feature to turn off warnings in a specific
piece
From: Stefan Monnier [EMAIL PROTECTED]
Date: Tue, 16 Jan 2007 09:50:01 -0500
Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
In any case, the first thing to do is to bring it to the attention of the
gcc maintainers. Even if they don't provide any workaround, it's important
that they know
Some compilers support the use of #pragma directives to disable certain
warnings it would
otherwise generate for the lines wrapped within those specific #pragma
directives. Perhaps
GCC could be extended to support this.
There's a big flaw in the design of #pragma: macros
I wrote to the GCC developers about the issue.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
It's just a bad workaround which may work for now. The warning may come
back with additional optimizations in gcc (either in the future or maybe
even already now with a higher optimization level).
The problem is gcc's, really.
If it is a bug in GCC, we need to report the bug.
From: Richard Stallman [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
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
I think we should demand some way to turn off the warning in specific
places. Does GCC have a feature to turn off warnings in a specific
piece of code? I don't remember. It would be a good feature to have.
However, a specific feature just for this kind of warning would also
be useful. I have
Richard Stallman wrote:
I think we should demand some way to turn off the warning in specific
places. Does GCC have a feature to turn off warnings in a specific
piece of code? I don't remember. It would be a good feature to have.
However, a specific feature just for this kind of warning
editfns.c: In function 'Fuser_uid':
editfns.c:1317: warning: comparison is always false due to limited range of
data type
process.c: In function 'Fdelete_process':
process.c:820: warning: comparison is always false due to limited range of
data type
I think I fixed these now in the CVS,
I think I fixed these now in the CVS, please take a look.
It's just a bad workaround which may work for now. The warning may come
back with additional optimizations in gcc (either in the future or maybe
even already now with a higher optimization level).
The problem is gcc's, really.
Date: Sun, 14 Jan 2007 12:35:04 +0100
From: Francesco Potorti` [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
I think I fixed these now in the CVS, please take a look.
Yes, the warnings have disappeared.
The workaround is to define a variable of type EMACS_INT, assign to it
the value
Cc: Francesco Potorti` [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
From: Stefan Monnier [EMAIL PROTECTED]
Date: Sun, 14 Jan 2007 09:53:07 -0500
I think I fixed these now in the CVS, please take a look.
It's just a bad workaround
What's bad about it?
The warning may come back with
I think I fixed these now in the CVS, please take a look.
It's just a bad workaround
What's bad about it?
Makes the code heavier. But it's pretty minor, indeed. It's definitely the
best workaround we have seen so far.
The warning may come back with additional optimizations in gcc
Are you
gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I.
-I/home/pot/gnu/emacs-22.0.91/src -D_BSD_SOURCE -g -O2 -Wno-pointer-sign
editfns.c
editfns.c: In function 'Fuser_uid':
editfns.c:1317: warning: comparison is always false due to limited range of
data type
editfns.c:1317: warning:
Date: Mon, 11 Dec 2006 13:25:13 +0100
From: Francesco Potorti` [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
/home/pot/gnu/emacs-22.0.91/src/prefix-args.c: In function 'main':
/home/pot/gnu/emacs-22.0.91/src/prefix-args.c:64: warning: incompatible
implicit declaration of built-in
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?
Apparently, yes. But also enough stupid that it
Will it also be that smart if we do some
arithmetics, like `(EMACS_INT)i + 0L' or `(EMACS_INT)i*1L'?
Will try that and see if it is useful to make the warning go away.
No, it changes nothing: the compiler is too clever, but not enough :-)
But, rereading it:
#define
We can probably remove those warnings with the right -Wno-foo
invocation.
No, that would mask out other possible cases when the warning is
significant.
But since this warning is about something which is not itself a bug, either
gcc provides a way to annotate the code to indicate that this is
But since this warning is about something which is not itself a bug, either
gcc provides a way to annotate the code to indicate that this is not a bug
(like the use of double-parens to turn off the warning about assignment in
an `if'), or there's not much we can do about it (other than try to work
But since this warning is about something which is not itself a bug, either
gcc provides a way to annotate the code to indicate that this is not a bug
(like the use of double-parens to turn off the warning about assignment in
an `if'), or there's not much we can do about it (other than try to
I looked at the gcc 4.1 info page, and I found no warnings to turn off
that are specific for this case (I looked for the string compar).
Yes, I believe there's no way. Which is why I think the least bad course
is -Wno-foo.
???
Oops, sorry, I misunderstood at first reading. We should ask
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
From: Stefan Monnier [EMAIL PROTECTED]
Date: Mon, 11 Dec 2006 23:48:43 -0500
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
/home/pot/gnu/emacs-22.0.91/src/prefix-args.c: In function 'main':
/home/pot/gnu/emacs-22.0.91/src/prefix-args.c:64: warning: incompatible
implicit declaration of built-in function 'exit'
/home/pot/gnu/emacs-22.0.91/src/prefix-args.c:73: warning: incompatible
implicit declaration of
process.c: In function 'Fsignal_process':
process.c:6114: warning: cast from pointer to integer of different size
I think this is a real bug. Please try this patch:
2006-12-09 Eli Zaretskii [EMAIL PROTECTED]
* process.c (Fsignal_process): Doc fix. Use XFLOAT_DATA to
extract
I get these warnings during compilation on x86_64-unknown-linux-gnu with
Debian testing with gcc (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)
[...]
gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I.
-I/home/pot/gnu/emacs-22.0.91/src -D_BSD_SOURCE -g -O2 -Wno-pointer-sign
Date: Mon, 11 Dec 2006 13:43:17 +0100
From: Francesco Potorti` [EMAIL PROTECTED]
Cc: emacs-pretest-bug@gnu.org
The reason why those warnings are there is that a comparison is made
between an int (32 bits) or a short (16 bits) and a constant long (64 bits).
Are you talking about the
Are you talking about the comparison in FIXNUM_OVERFLOW_P? If so,
where's the 32-bit int and the 64-bit long in that macro? I must be
missing something, because what I see there is a comparison between
two values which are both cast to EMACS_INT, which makes them both of
type long.
If the
Cc: Francesco Potorti` [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
From: Stefan Monnier [EMAIL PROTECTED]
Date: Mon, 11 Dec 2006 17:52:44 -0500
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
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,
Date: Mon, 04 Dec 2006 11:48:15 +0100
From: Francesco Potorti` [EMAIL PROTECTED]
/home/pot/gnu/emacs-22.0.91/src/prefix-args.c: In function 'main':
/home/pot/gnu/emacs-22.0.91/src/prefix-args.c:64: warning: incompatible
implicit declaration of built-in function 'exit'
Date: Mon, 04 Dec 2006 11:48:15 +0100
From: Francesco Potorti` [EMAIL PROTECTED]
I get these warnings during compilation on x86_64-unknown-linux-gnu with
Debian testing with gcc (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)
[...]
gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I.
35 matches
Mail list logo
