> #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 mail
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
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 can
> 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 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
> #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 do
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 f
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
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 would
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 a
> 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
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.
Wh
>> > 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
>
> 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
> 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
th
> 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.
>> 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 i
> 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: warnin
> 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 o
> 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 no
>>> 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 s
>> 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.
???
> if (foo = bar) ...
>
>gcc warns that you may have
>> 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
>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 w
>>> 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 t
>> 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:
#defin
>> 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
>> 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
> arith
> 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
> 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
> 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
>> 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
>> 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
>
>> /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 o
> 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
> 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'
> /home/pot/gn
> Date: Mon, 04 Dec 2006 11:48:15 +0100
> From: Francesco Potorti` <[EMAIL PROTECTED]>
>
> 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 PR
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)
I identified the reason for the first one and posted it on emacs-devel,
where I am going to follow up the answer I got. I plan to consider the
other
38 matches
Mail list logo
