https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
Pádraig Brady changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #22 from Manuel López-Ibáñez 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=gcc&view=rev&rev=187195
Log:
2012-05-05 Manuel López-Ibáñez
PR c/4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #21 from Manuel López-Ibáñez 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=gcc&view=rev&rev=187194
Log:
2012-05-05 Manuel López-Ibáñez
PR c/4
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 ba
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #19 from Marc Glisse 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 < INTMAX_MAX. Then:
>
> intm
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_MIN&&isomething are common, but
> isomething seems less likely.
I'm afraid that fal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #17 from Marc Glisse 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 it should go to
> Wtype-lim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #16 from Manuel López-Ibáñez 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 adding a third warning th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #15 from Marc Glisse 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_MAX, whereas this
> > belongs to other warnings. So testing the triviality of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #14 from Manuel López-Ibáñez 2012-04-28
12:49:57 UTC ---
(In reply to comment #13)
>
> Except that this version would warn for xINT_MAX, whereas this
> belongs to other warnings. So testing the triviality of the first ranges seems
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #13 from Marc Glisse 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 moment it is doing some
> trans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #12 from Manuel López-Ibáñez 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 checking:
> if (TREE_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #11 from Marc Glisse 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) != INTEGER_CST)
it could check in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
--- Comment #10 from Manuel López-Ibáñez 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 range, checks that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43772
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
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 <= 92
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 #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 #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))
>
--- 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;
--
http://gcc.gnu.or
--- 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 #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 warni
--- 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
23 matches
Mail list logo
