Re: warnings compiling Emacs 22 on amd64
> #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 list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
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
Re: warnings compiling Emacs 22 on amd64
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't use it. (It is not recognized in macro expansions at all.) In effect, the #pragma interface is inadequate for just about any purpose that you might imagine using it for. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 about such problems. 100% agreement. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 of code? I don't remember. It would be a good feature to have. I don't think GCC has something like this. But even if it had, such features in other compilers either reference a warning by its code (something like W4589), or by the command-line switch that turns that warning off globally. The former is both ugly and unreadable, to say nothing of maintainability. The latter requires that a command-line option exist to control the warning, which in this particular case we don't have. > However, a specific feature just for this kind of warning would also > be useful. I have an idea for what it could look like: an extra cast. > > if ((int)(short)foo > (int)SHRT_MAX || (int)(short)foo < (int)SHRT_MIN) This won't work in the context such as our FIXNUM_OVERFLOW_P macro, since it is specifically needs to DTRT when `foo' is not a short, but int or long. But even if this worked, I think it obfuscates the code too much. I don't know what important situations triggered the introduction of this warning at such a basic level of diagnostics, but the result is that GCC now flags perfectly valid and legitimate code as questionable. I think this is unacceptable when GCC runs without any "-Wxxx" option. So I think we should ask GCC maintainers to produce this warning only under -Wall. I think this is the best alternative, on balance. Tests like the above are about the only valid way in C to test the width of data types, so GCC should not flag it as suspicious unless asked to. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> #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 provide any workaround, it's important that they know about such problems. Otherwise they may be tempted to add warnings for code like int x = 3; int y = SOME_MACRO (x); if (y > 6) ... where SOME_MACRO may end up just returning `x' depending on some compilation flag. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
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 this kind of warning would also > be useful. I have an idea for what it could look like: an extra cast. > > if ((int)(short)foo > (int)SHRT_MAX || (int)(short)foo < (int)SHRT_MIN) > > (short) would be a way of saying "yes I know this is a short", and > this could suppress the warning. > > What do you think of that feature? So you would define #define FIXNUM_OVERFLOW_P(i) \ ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ || (EMACS_INT) (i) < MOST_NEGATIVE_FIXNUM) as #define FIXNUM_OVERFLOW_P(i) \ ((EMACS_INT)(int)(i) > MOST_POSITIVE_FIXNUM \ || (EMACS_INT)(int)(i) < MOST_NEGATIVE_FIXNUM) Looks fine to me. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
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 other in line compiler directive, is a better > way to instruct the compiler > how to behave, rather than a modification of the source code itself. The problem with a #pragma is that you need to wrap every _use_ of the macro, rather than localizing the trickery to the macro definition. Of course, if you could define it like this: #define MACRO(i) \ #pragma specific_warning_off\ macro definition here\ #pragma specific_warning_on it would be ok to use a pragma. But how would that work if you write something like var = MACRO(i) Hmmm... -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
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 also be useful. I have an idea for what it could look like: an extra cast. if ((int)(short)foo > (int)SHRT_MAX || (int)(short)foo < (int)SHRT_MIN) (short) would be a way of saying "yes I know this is a short", and this could suppress the warning. What do you think of that feature? 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 other in line compiler directive, is a better way to instruct the compiler how to behave, rather than a modification of the source code itself. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
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 an idea for what it could look like: an extra cast. if ((int)(short)foo > (int)SHRT_MAX || (int)(short)foo < (int)SHRT_MIN) (short) would be a way of saying "yes I know this is a short", and this could suppress the warning. What do you think of that feature? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 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) \
((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \
|| (EMACS_INT) (i) < MOST_NEGATIVE_FIXNUM)
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
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.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
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. What exactly is the bug? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> > 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 saying that the warnings we saw (before my changes) would not > appear under -O0? Quite likely. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 additional optimizations in gcc Are you saying that the warnings we saw (before my changes) would not appear under -O0? > The problem is gcc's, really. True; but I don't see any practical way of talking GCC developers out of this attitude. And I dislike bogus warnings, because tolerance to them makes it easy to miss real warnings. So we are stuck with these half-measures, for now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 that causes the warning in FIXNUM_OVERFLOW_P (the value that might be shorter than EMACS_INT on some platforms), and then use the EMACS_INT variable in FIXNUM_OVERFLOW_P. Not very elegant, but effective. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> 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, please take a look. Yes, the warnings have disappeared. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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: comparison is always false due to limited range of > data type > editfns.c: In function 'Fuser_real_uid': > editfns.c:1325: warning: comparison is always false due to limited range of > data type > editfns.c:1325: warning: comparison is always false due to limited range of > data type > > 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 > fns.c > fns.c: In function 'maybe_resize_hash_table': > fns.c:4684: warning: comparison is always false due to limited range of data > type > > 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 > process.c: In function 'Fdelete_process': > process.c:820: warning: comparison is always false due to limited range of > data type > process.c:820: warning: comparison is always false due to limited range of > data type > process.c:830: warning: comparison is always false due to limited range of > data type > process.c:830: warning: comparison is always false due to limited range of > data type > process.c: In function 'Fprocess_id': > process.c:917: warning: comparison is always false due to limited range of > data type > process.c:917: warning: comparison is always false due to limited range of > data type > process.c:6441: warning: comparison is always false due to limited range of > data type > process.c:6441: warning: comparison is always false due to limited range of > data type I think I fixed these now in the CVS, please take a look. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 function 'exit' > >> /home/pot/gnu/emacs-22.0.91/src/prefix-args.c:73: warning: incompatible > >> implicit declaration of built-in function 'exit' > > > >Do these warnings go away if you #include in prefix-args.c? > > Yes, they go away. I had not tried that myself because apparently > prefix-args.c was written to be compilable on everything, even when > stdlib.h is not there, but times are changing, so I think your change is > the way to go. I installed a change that includes stdlib.h only if STDC_HEADERS is defined in config.h. I think this should be safe on all platforms. Thanks for reporting this and for testing the fix. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 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? Because if we understand that, we could devise a way to defeat the warning. > 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. I don't see how it can be less maintainable than it is now, what with the multi-layered macros we sprinkle everywhere. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>>> 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 the gcc people what thet recommend. >> if (foo = bar) ... >> >> gcc warns that you may have meant == instead of =, so if you really meant = >> you can just write >> >> if ((foo = bar)) ... > Probably this is just because it is then clear that the logical expression > is the result of the expression inside the parentheses. I mean, not in > fact a special case for gcc. Probably, yes. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> 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 meant == instead of =, so if you really meant = >you can just write > > if ((foo = bar)) ... Probably this is just because it is then clear that the logical expression is the result of the expression inside the parentheses. I mean, not in fact a special case for gcc. In fact, I'd say it is good programming practice enclosing assignments in parentheses when the result is what you want. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> 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 >> around it by making the code ugly, less robust, and maybe even less >> efficient: after all the warning here is output specifically when gcc finds >> an optimization). > First I tried to work around it by making the code slightly more > complex, but still clear. However, I failed. > 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. > As far as code annotations are concerned, I don't know where to look: I > had never heard of the double parenthesis trick, nor was I able to find > it in the gcc info page. Can't remember where I saw it, but if you do if (foo = bar) ... gcc warns that you may have meant == instead of =, so if you really meant = you can just write if ((foo = bar)) ... and gcc will then keep quiet. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>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 >around it by making the code ugly, less robust, and maybe even less >efficient: after all the warning here is output specifically when gcc finds >an optimization). First I tried to work around it by making the code slightly more complex, but still clear. However, I failed. 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"). As far as code annotations are concerned, I don't know where to look: I had never heard of the double parenthesis trick, nor was I able to find it in the gcc info page. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>>> 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 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 around it by making the code ugly, less robust, and maybe even less efficient: after all the warning here is output specifically when gcc finds an optimization). Turning off such warnings is not such a big deal. There are thousand more such warnings that are currently "turned off" for the reason that either they're too difficult to figure out or nobody has thought of writing them yet. The warning just says "hey, I've found a piece of code that's silly", but in the case where that piece of code is the result of macro-expansion (or function inlining, or other such code manipulation), it is often very much normal and the result of good coding practices. So I believe the problem is with the warning which is not careful enough to see how that code came about. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> 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 FIXNUM_OVERFLOW_P(i) \ ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ || (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM) What is the purpose of casting (i) to EMACS_INT? The cast is redundant, unless (sizeof(i) > sizeof(EMACS_INT)). Or unless (i) is floating point. In both cases, the cast should not be there, I suppose. In my case, removing the casts apparently changes nothing, and the warnings are always there. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> 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 makes that comparison when it is useless (as I tried to have it understand using sizeof()). > 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. >> > 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)? No, it will always return 0 if (sizeof(i) < sizeof(EMACS_INT)), but it may not return 0 if (i) has the same or greater size than EMACS_INT. On amd64, this happens when (i) is long. >> There is no problem other than unhelpful warnings. Well, that's exactly the problem :-) Having spurious warnings should be avoided, if at all possible. >> 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> 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 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 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'? > > 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)? > > 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 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). > If FIXNUM_OVERFLOW_P should always return zero on 64-bit machines, It shouldn't. There are a few sites where it does, tho. > then how about changing FIXNUM_OVERFLOW_P so that it's a constant on > 64-bit machines? For example: > #ifdef _LP64 > # define FIXNUM_OVERFLOW_P(i) 0 > #else > # define FIXNUM_OVERFLOW_P(i) \ > ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ > || (EMACS_INT) (i) < MOST_NEGATIVE_FIXNUM) > #endif > Does this fix the problem? What problem? 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. > (But I still would like to understand why the comparison is always > true.) It's only "always true" in some specific contexts. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 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. > Such a comparison is useless, because the compiler knows that the > constant long is always bigger than the int, due to its size. I tried > to avoid the comparison by changing the FIXNUM_OVERFLOW_P macro like > this: > > #define FIXNUM_OVERFLOW_P(i) \ > (sizeof(i) >= sizeof(EMACS_INT) \ >&& ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ >|| (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM)) > > that is, by adding a test on sizeof at the beginning. However, this has > no effect and the following warnings are always there: If FIXNUM_OVERFLOW_P should always return zero on 64-bit machines, then how about changing FIXNUM_OVERFLOW_P so that it's a constant on 64-bit machines? For example: #ifdef _LP64 # define FIXNUM_OVERFLOW_P(i) 0 #else # define FIXNUM_OVERFLOW_P(i) \ ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ || (EMACS_INT) (i) < MOST_NEGATIVE_FIXNUM) #endif Does this fix the problem? (But I still would like to understand why the comparison is always true.) > Doing like this: > > #define FIXNUM_OVERFLOW_P(i) \ > ((sizeof(i) < sizeof(EMACS_INT)) ? 0 \ >: ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ >|| (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM)) > > still changes nothing. Apparently the compiler runs the second test > even if the first one fails, and so issues a warning. I don't think the code is ``run'', but it is definitely analyzed by the parser, and that is when you get the warning. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> 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 >> 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: comparison is always false due to limited range of >> data type >> editfns.c: In function 'Fuser_real_uid': >> editfns.c:1325: warning: comparison is always false due to limited range of >> data type >> editfns.c:1325: warning: comparison is always false due to limited range of >> data type > >These and other similar warnings seem all to come from the use of >MOST_POSITIVE_FIXNUM and MOST_NEGATIVE_FIXNUM. Do these warnings go >away if you modify those two macros as below? > >#define MOST_NEGATIVE_FIXNUM - ((EMACS_INT) (1 << (VALBITS - 1))) >#define MOST_POSITIVE_FIXNUM ((EMACS_INT) (1 << (VALBITS - 1) - 1)) No, those definitions are wrong: on amd64, EMACS_INT is a long, so the above is wrong because 1 is an int and is shifted by more than its size. The way things are defined now, that is: #define MOST_NEGATIVE_FIXNUM- ((EMACS_INT) 1 << (VALBITS - 1)) #define MOST_POSITIVE_FIXNUM(((EMACS_INT) 1 << (VALBITS - 1)) - 1) is correct as far as I can see, because 1 is cast to long, then shifted, which yields a long. The reason why thos ewarnings are there is that a comparison is made between an int (32 bits) or a short (16 bits) and a constant long (64 bits). Such a comparison is useless, because the compiler knows that the constant long is always bigger than the int, due to its size. I tried to avoid the comparison by changing the FIXNUM_OVERFLOW_P macro like this: #define FIXNUM_OVERFLOW_P(i) \ (sizeof(i) >= sizeof(EMACS_INT) \ && ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ || (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM)) that is, by adding a test on sizeof at the beginning. However, this has no effect and the following warnings are always there: 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: comparison is always false due to limited range of data type editfns.c: In function 'Fuser_real_uid': editfns.c:1325: warning: comparison is always false due to limited range of data type editfns.c:1325: warning: comparison is always false due to limited range of data type 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 fns.c fns.c: In function 'maybe_resize_hash_table': fns.c:4684: warning: comparison is always false due to limited range of data type 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 process.c: In function 'Fdelete_process': process.c:820: warning: comparison is always false due to limited range of data type process.c:820: warning: comparison is always false due to limited range of data type process.c:830: warning: comparison is always false due to limited range of data type process.c:830: warning: comparison is always false due to limited range of data type process.c: In function 'Fprocess_id': process.c:917: warning: comparison is always false due to limited range of data type process.c:917: warning: comparison is always false due to limited range of data type process.c: In function 'sigchld_handler': process.c:6441: warning: comparison is always false due to limited range of data type process.c:6441: warning: comparison is always false due to limited range of data type Doing like this: #define FIXNUM_OVERFLOW_P(i) \ ((sizeof(i) < sizeof(EMACS_INT)) ? 0 \ : ((EMACS_INT)(i) > MOST_POSITIVE_FIXNUM \ || (EMACS_INT)(i) < MOST_NEGATIVE_FIXNUM)) still changes nothing. Apparently the compiler runs the second test even if the first one fails, and so issues a warning. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> 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 the process ID from a Lisp float. The warning went away, and the compilation proceeded successfully. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
>> /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 built-in function 'exit' > >Do these warnings go away if you #include in prefix-args.c? Yes, they go away. I had not tried that myself because apparently prefix-args.c was written to be compilable on everything, even when stdlib.h is not there, but times are changing, so I think your change is the way to go. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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. > -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: comparison is always false due to limited range of > data type > editfns.c: In function 'Fuser_real_uid': > editfns.c:1325: warning: comparison is always false due to limited range of > data type > editfns.c:1325: warning: comparison is always false due to limited range of > data type These and other similar warnings seem all to come from the use of MOST_POSITIVE_FIXNUM and MOST_NEGATIVE_FIXNUM. Do these warnings go away if you modify those two macros as below? #define MOST_NEGATIVE_FIXNUM- ((EMACS_INT) (1 << (VALBITS - 1))) #define MOST_POSITIVE_FIXNUM((EMACS_INT) (1 << (VALBITS - 1) - 1)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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/gnu/emacs-22.0.91/src/prefix-args.c:73: warning: incompatible > implicit declaration of built-in function 'exit' Do these warnings go away if you #include in prefix-args.c? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: warnings compiling Emacs 22 on amd64
> 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 PROTECTED]>
* process.c (Fsignal_process): Doc fix. Use XFLOAT_DATA to
extract the process ID from a Lisp float.
Index: src/process.c
===
RCS file: /cvsroot/emacs/emacs/src/process.c,v
retrieving revision 1.493
diff -u -p -r1.493 process.c
--- src/process.c 7 Dec 2006 11:12:21 - 1.493
+++ src/process.c 9 Dec 2006 21:59:32 -
@@ -6102,7 +6102,7 @@ If PROCESS is a network process, resume
DEFUN ("signal-process", Fsignal_process, Ssignal_process,
2, 2, "sProcess (name or number): \nnSignal code: ",
doc: /* Send PROCESS the signal with code SIGCODE.
-PROCESS may also be an integer specifying the process id of the
+PROCESS may also be a number specifying the process id of the
process to signal; in this case, the process need not be a child of
this Emacs.
SIGCODE may be an integer, or a symbol whose name is a signal name. */)
@@ -6119,7 +6119,7 @@ SIGCODE may be an integer, or a symbol w
if (FLOATP (process))
{
- pid = (pid_t) XFLOAT (process);
+ pid = (pid_t) XFLOAT_DATA (process);
goto got_it;
}
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
warnings compiling Emacs 22 on amd64
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 warnings too, but that may take time, so if anyone else considers this and gives me patches to try, I will. 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 dispnew.c dispnew.c: In function 'init_display': dispnew.c:6895: warning: overflow in implicit constant conversion dispnew.c:6896: warning: overflow in implicit constant conversion 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: comparison is always false due to limited range of data type editfns.c: In function 'Fuser_real_uid': editfns.c:1325: warning: comparison is always false due to limited range of data type editfns.c:1325: warning: comparison is always false due to limited range of data type 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 fns.c fns.c: In function 'maybe_resize_hash_table': fns.c:4684: warning: comparison is always false due to limited range of data type 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 process.c: In function 'Fdelete_process': process.c:820: warning: comparison is always false due to limited range of data type process.c:820: warning: comparison is always false due to limited range of data type process.c:830: warning: comparison is always false due to limited range of data type process.c:830: warning: comparison is always false due to limited range of data type process.c: In function 'Fprocess_id': process.c:917: warning: comparison is always false due to limited range of data type process.c:917: warning: comparison is always false due to limited range of data type process.c: In function 'Fsignal_process': process.c:6114: warning: cast from pointer to integer of different size process.c: In function 'sigchld_handler': process.c:6441: warning: comparison is always false due to limited range of data type process.c:6441: warning: comparison is always false due to limited range of data type gcc -Demacs -DHAVE_CONFIG_H -I. -I/home/pot/gnu/emacs-22.0.91/src -D_BSD_SOURCE -g -O2 -Wno-pointer-sign -Wl,-znocombreloc /home/pot/gnu/emacs-22.0.91/src/prefix-args.c -o prefix-args /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 built-in function 'exit' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
