[Bug c/37591] New: suppress "signed and unsigned" warnings when signed value known to be positive

[Bug c/37591] New: suppress "signed and unsigned" warnings when signed value known to be positive

[zackw at panix dot com]

In a case such as this, GCC ought to be able to prove that the signed variable
is positive and therefore suppress "signed and unsigned" warnings.  I see this
in both C and C++.

#define MAX(a,b) ((a) > (b) ? (a) : (b))
#define MIN(a,b) ((a) < (b) ? (a) : (b))

unsigned int
constrain(unsigned int index, unsigned int offset, unsigned int limit)
{
  int adj = index - offset;
  adj = MAX(adj, 0);
  return MIN(adj, limit); /* { dg-bogus "signed and unsigned" } */
}


-- 
           Summary: suppress "signed and unsigned" warnings when signed
                    value known to be positive
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: zackw at panix dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591

[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-09-19 20:55 -------
I think this needs to delay the warning until VRP time really but I don't see
how that can be done really.
Also the front-end does known that adj will only be positive, the middle-end
only knows during VRP really.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591

[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive

[zackw at panix dot com]

------- Comment #2 from zackw at panix dot com  2008-09-19 21:28 -------
I'd be fine with it being like uninitialized value warnings.  The false
positives here are *really* annoying.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591

[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2008-09-20 09:10 -------
This is the usual trade-off of doing warnings from the frontends...


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-09-20 09:10:32
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591

[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive

[manu at gcc dot gnu dot org]

------- Comment #4 from manu at gcc dot gnu dot org  2008-09-22 13:28 -------
I don't understand why this is not closed as wontfix. These warnings are coming
from the front-end. 

Unless we do one of the following:

a) some CCP and VRP in the FE, or
b) move the warnings to the middle-end,

this cannot be fixed. And the consensus seems to be that we do not want to do
either of them. And from the many problems we see with Wuninitialized, we
already know that moving the warnings to the middle-end causes a lot of
problems. Also, VRP is only enabled at -O2. And it does not work with sets,
only ranges, so the following will still not work:

adj = (flag) ? 0 : 2;
return MIN(adj, limit);

(I am sure that we have already, probably closed, a PR about this).


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591

[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive

[zackw at panix dot com]

------- Comment #5 from zackw at panix dot com  2008-09-22 15:46 -------
I'm not monitoring consensus of developers anymore, but I think we *should*
either move these warnings to the middle end or do some CCP/VRP in the front
ends.  The -Wuninitialized warnings are a lot less trouble than the
signed/unsigned warnings, right now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591

[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive

[manu at gcc dot gnu dot org]

------- Comment #6 from manu at gcc dot gnu dot org  2008-09-22 16:43 -------
Then, try to raise the issue in GCC and outline a clear plan. Otherwise, I
assure you this is going to stay as-is for the next 5-10 years because nobody
has a clear idea on how to tackle this in a way that pleases a majority. Also,
because it has an easy workaround: use a casting to unsigned.

Some starting points:

* Moving the warning to the middle-end is not going to avoid warning in this
testcase unless VRP is enabled. For -O0 and -O1, we will keep warning.

* Moving the warning to the middle-end means that we will warn/not warn
depending on the ordering of passes, missed optimisations, etc.

* Clang people claim that they can do a simple CCP pass very efficiently in the
FE. Perhaps we could do the same. However, we are currently moving
optimizations (such as folding) to later stages. In any case, VRP in the
front-end is what would be needed for this testcase. Is that even possible? Can
be done efficiently?

The same issues apply to many warnings: -Wconversion, -Wuninitialized,
-Wtype-limits. 

As Richard said: This is the usual trade-off of doing warnings from the
frontends versus from the middle-end. One gives consistency and speed but
frequent false positives, and the other gives more precision at the cost of
consistent results and more compilation time.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591

[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive

[daniel.marjamaki at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591

Daniel Marjamäki <daniel.marjamaki at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.marjamaki at gmail dot com

--- Comment #7 from Daniel Marjamäki <daniel.marjamaki at gmail dot com> ---
+1

This is very annoying.

My code is:

unsigned int dostuff();
void f(int x) {
  if (x >= 0 && x < dostuff()) {}
}

This kind of false positive is indirectly a security problem. People routinely
hide these false positives using casts or changed variable types etc. and that
cause bugs and hides other real warnings.

I'd vote for either removing this warning or fixing it.
>From gcc-bugs-return-491539-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 06 09:03:48 2015
Return-Path: <gcc-bugs-return-491539-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 58031 invoked by alias); 6 Jul 2015 09:03:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 57986 invoked by uid 48); 6 Jul 2015 09:03:43 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66774] Any optimization causes segfault on binary
Date: Mon, 06 Jul 2015 09:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-66774-4-3xuPED8vb3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66774-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66774-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg00429.txt.bz2
Content-length: 1275

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf774

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |trippels at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
In cases like this please build your code with -fsanitize=undefined.

code.cpp:58:39: runtime error: index 4 out of bounds for type 'int [4][2]'
code.cpp:58:42: runtime error: load of address 0x000000410b00 with insufficient
space for an object of type 'const int'
0x000000410b00: note: pointer points here
 01 00 00 00  ff ff 01 10 5f 05 a8 05  00 ab 05 05 00 00 b0 05  05 a8 05 00 ff
ff 01 11  b1 01 05 00
              ^
code.cpp:59:39: runtime error: index 4 out of bounds for type 'int [4][2]'
code.cpp:59:42: runtime error: load of address 0x000000410b04 with insufficient
space for an object of type 'const int'
0x000000410b04: note: pointer points here
  ff ff 01 10 5f 05 a8 05  00 ab 05 05 00 00 b0 05  05 a8 05 00 ff ff 01 11  b1
01 05 00 00 f8 07 cc

[Bug c/37591] suppress "signed and unsigned" warnings when signed value known to be positive

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
> I'd vote for either removing this warning or fixing it.

You can use the corresponding -Wno-* option to remove it.

There's no much point in voting on this or other bugs: What is needed is
someone brave enough to tackle the problem and figure out how to solve it in a
way that is accepted by the maintainers.
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

Comment #6 is as relevant today as it was 6 years ago. But perhaps simple cases
can be detected without any CCP or VRP in the FE. Someone needs to figure it
out.
>From gcc-bugs-return-491562-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 06 12:50:04 2015
Return-Path: <gcc-bugs-return-491562-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 119859 invoked by alias); 6 Jul 2015 12:50:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 119807 invoked by uid 55); 6 Jul 2015 12:49:59 -0000
From: "bernds at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66620] bfin: bfin.c: (hwloop_optimize): gcc_assert (JUMP_P (insn)) fails.
Date: Mon, 06 Jul 2015 12:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernds at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66620-4-sMGO6KFwyN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66620-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66620-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg00452.txt.bz2
Content-length: 520

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf620

--- Comment #13 from Bernd Schmidt <bernds at gcc dot gnu.org> ---
Author: bernds
Date: Mon Jul  6 12:49:26 2015
New Revision: 225453

URL: https://gcc.gnu.org/viewcvs?rev"5453&root=gcc&view=rev
Log:
Fix assert caused by bad cfg manipulation in bfin.

        PR target/66620
        * config/bfin/bfin.c (hwloop_optimize): Create new bb between jump and
        loop start when inserting LSETUP.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/bfin/bfin.c