Bug 37038 - Bogus warning from GCC
Summary: Bogus warning from GCC
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: ada (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: 4.5.0
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2008-08-06 14:47 UTC by Samuel Tardieu
Modified: 2009-10-06 11:37 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-08-10 20:35:03


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel Tardieu 2008-08-06 14:47:36 UTC
With trunk GCC, SVN revision 138798.

The following program (t.adb), when compiled with "gcc -O2", gives:

t.adb: In function ‘T’:
t.adb:6: warning: comparison always false due to limited range of data type

(probably emitted by the backend as "-gnatv" doesn't show the caret position)

Note that the warning points onto the line containing 'Pos, not the comparison itself. And this is bogus, as if "X" contains "2#11xxxxxx#" (two high bits set), then right shifting it by 6 positions (it is unsigned) will give "3", which corresponds to "White".

Moreover, despites the warning, the generated code is correct and returns "0" when the two high bits are set and "1" otherwise.

with Interfaces; use Interfaces;

function T (X : Unsigned_8) return Integer
is
   type Color is (None, Red, Blue, White);
   V : constant Color := Color'Val (Shift_Right (X, 6));
begin
   if V = White then
      return 0;
   else
      return 1;
   end if;
end T;
Comment 1 Samuel Tardieu 2008-08-06 14:49:36 UTC
(read "the line containing 'Val", not "'Pos")
Comment 2 Samuel Tardieu 2008-08-06 15:39:25 UTC
The warning comes from a range check which is emitted by Gigi. The backend knows that this check is useless, and warns about it. As far as I can tell, there is no way to suppress the warning in shorten_compare (c-common.c), except by setting a global option (OPT_Wtype_limits) to false.
Comment 3 pinskia@gmail.com 2008-08-06 15:46:11 UTC
Subject: Re:  Bogus warning from GCC



Sent from my iPhone

On Aug 6, 2008, at 8:39, "sam at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org 
 > wrote:

>
>
> ------- Comment #2 from sam at gcc dot gnu dot org  2008-08-06 15:39  
> -------
> The warning comes from a range check which is emitted by Gigi. The  
> backend
> knows that this check is useless, and warns about it. As far as I  
> can tell,
> there is no way to suppress the warning in shorten_compare (c- 
> common.c), except
> by setting a global option (OPT_Wtype_limits) to false.

C-common.c being included by the Ada front-end???? That is a c front- 
end file.

-- Pinski


>
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37038
>
Comment 4 Samuel Tardieu 2008-08-06 16:57:26 UTC
Andrew, you're right, I got confused by the build_binary_op() which is present both in ada/gcc-interface/utils2.c and c-typeck.c, and that the warning appears as is in c-common.c.

The warning is likely to come from tree-vrp.c.
Comment 5 Andrew Pinski 2008-08-10 20:17:23 UTC
(In reply to comment #4)
> The warning is likely to come from tree-vrp.c.

The only place which emits this warning is from c-common.c so I think someone needs to debug this a little bit.  Place a breakpoint on warning and then look at the backtrace to figure out where the warning is coming from.  If it is truly coming from c-common.c, then the Ada front-end is wrong to include that source at all.
Comment 6 Samuel Tardieu 2008-08-10 20:30:47 UTC
Subject: Re:  Bogus warning from GCC

>> The warning is likely to come from tree-vrp.c.

> The only place which emits this warning is from c-common.c so I
> think someone needs to debug this a little bit.  Place a breakpoint
> on warning and then look at the backtrace to figure out where the
> warning is coming from.  If it is truly coming from c-common.c, then
> the Ada front-end is wrong to include that source at all.

As I wrote, it must be coming from tree-vrp.c: the warning message is
split on two lines there, which is why I didn't catch it either the
first time I looked for it.

Comment 7 Andrew Pinski 2008-08-10 20:34:56 UTC
Oh I see it now:
      /* If the comparison is being folded and the operand on the LHS
         is being compared against a constant value that is outside of
         the natural range of OP0's type, then the predicate will
         always fold regardless of the value of OP0.  If -Wtype-limits
         was specified, emit a warning.  */

So the trick should be is set TREE_NO_WARNING on the comparison in the front-end and then have VRP check that (if it is possible to do so now after the tuples merge :( ).
Comment 8 Samuel Tardieu 2009-10-06 11:37:01 UTC
The issue is no longer present in trunk. Closing as fixed.