https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
Pádraig Brady P at draigBrady dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-05
11:31:03 UTC ---
Author: manu
Date: Sat May 5 11:30:57 2012
New Revision: 187194
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187194
Log:
2012-05-05 Manuel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #22 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-05-05
11:32:30 UTC ---
Author: manu
Date: Sat May 5 11:32:26 2012
New Revision: 187195
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187195
Log:
2012-05-05 Manuel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
Marc Glisse marc.glisse at normalesup dot org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-28
12:32:49 UTC ---
(In reply to comment #9)
For : x=INT_MIN x=INT_MAX
the code creates a range for x=INT_MIN, another range for x=INT_MAX, merges
them into a single
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #11 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
12:33:26 UTC ---
(In reply to comment #9)
It forgets to check first whether the first 2 ranges are trivial.
Or easier, instead of checking:
if (TREE_CODE (tem)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-28
12:37:06 UTC ---
(In reply to comment #11)
(In reply to comment #9)
It forgets to check first whether the first 2 ranges are trivial.
Or easier, instead of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #13 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
12:40:14 UTC ---
(In reply to comment #10)
But there is something strange, because it is warning it is always false,
which is obviously not true. So I think at some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-28
12:49:57 UTC ---
(In reply to comment #13)
Except that this version would warn for xINT_MIN xINT_MAX, whereas this
belongs to other warnings. So testing the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #15 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
12:55:28 UTC ---
(In reply to comment #14)
(In reply to comment #13)
Except that this version would warn for xINT_MIN xINT_MAX, whereas this
belongs to other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-28
13:07:41 UTC ---
(In reply to comment #15)
No, there could be a warning that the first test is always false, another one
that the second one is always false, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #17 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
18:49:49 UTC ---
(In reply to comment #16)
I understand now, and I think you are right. We don't have a warning for
((int)x) INT_MIN or ((int)x) INT_MAX but I think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #18 from eggert at gnu dot org 2012-04-28 21:53:30 UTC ---
(In reply to comment #17)
I expect the remaining false positives to be very
rare. i=INT_MINisomething or iINT_MIN||isomething are common, but
iINT_MINisomething seems less
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #19 from Marc Glisse marc.glisse at normalesup dot org 2012-04-28
22:16:55 UTC ---
(In reply to comment #18)
I'm afraid that false positives would still be likely.
For example, suppose we're on a platform where
INT_MAX = LONG_MAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #20 from eggert at gnu dot org 2012-04-28 22:40:27 UTC ---
(In reply to comment #19)
intmax_t i = (whatever);
if (INT_MAX i i = LONG_MAX)
Have you actually seen that?
No, I just now invented that example. It was based on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #8 from eggert at gnu dot org 2011-07-15 03:01:42 UTC ---
The problem persists in GCC 4.6.1 (x86-64):
$ cat t.c
long long
emacs_lseek (int fd, long long offset, int whence)
{
return -1-9223372036854775807LL = offset offset =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
eggert at gnu dot org changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment
--- Comment #4 from muntyan at fastmail dot fm 2010-09-23 06:52 ---
Me too. This is real code, from xdgmime library (errno doesn't matter)
long retval = -1;
...
if ((retval INT_MIN) || (retval INT_MAX) || (errno != 0))
return -1;
--
--- Comment #5 from manu at gcc dot gnu dot org 2010-09-23 08:13 ---
(In reply to comment #4)
Me too. This is real code, from xdgmime library (errno doesn't matter)
long retval = -1;
...
if ((retval INT_MIN) || (retval INT_MAX) || (errno != 0))
return
--- Comment #6 from manu at gcc dot gnu dot org 2010-09-23 08:24 ---
I don't get a warning in trunk r159764. I think I fixed a similar bug during
4.6.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #3 from P at draigBrady dot com 2010-04-22 00:37 ---
I've confirmed that this is _not_ an issue with the previous
gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-17 11:03 ---
$ gcc-4.5 -Wlogical-op t.c -S -B.
t.c: In function 'main':
t.c:11:4: warning: logical 'and' of mutually exclusive tests is always false
confirmed. It should warn ... is always true.
--
rguenth at gcc dot gnu
--- Comment #2 from P at draigBrady dot com 2010-04-17 17:40 ---
Well the warning should at least change.
However the logical operation itself is not an issue,
so I think a warning should not be issued at all.
I.E. if TOP and BOT are defined as a narrower range
then we don't get a
23 matches
Mail list logo
