[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jim at meyering dot net

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2011-06-15 18:15:44 UTC ---
*** Bug 49426 has been marked as a duplicate of this bug. ***

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[DeusExSophismata at gmail dot com]

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

David Stone <DeusExSophismata at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |DeusExSophismata at gmail
                   |                            |dot com

--- Comment #10 from David Stone <DeusExSophismata at gmail dot com> 2012-03-24 06:52:04 UTC ---
Simple self-contained test case:


unsigned f (int x) {
    return (x >= 0) ? x : -x;
}
int main () {
    return 0;
}


It seems like we could at least add a simple improvement that just checks for
simple comparisons to 0. That probably catches most code (I often do one set of
calculations for non-negative values, and another set for negative values) and
avoids a lot of problems of trying to track complex calculations for the
signedness of the result. I wouldn't be perfect, but it would be better than it
currently is.

Being able to detect cases like this is also an optimization opportunity,
because division with positive integers is simpler than division with negative
integers, for example. We could reuse code that detects that optimization
opportunity for this warning.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-16 10:43:44 UTC ---
(In reply to comment #10)
> It seems like we could at least add a simple improvement that just checks for
> simple comparisons to 0. That probably catches most code (I often do one set of

You are welcome to try: http://gcc.gnu.org/contribute.html

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[paolo.carlini at oracle dot com]

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

Bug 38470 depends on bug 23608, which changed state.

Bug 23608 Summary: constant propagation (CCP) would improve -Wsign-compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23608

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |patrick.pelissier at gmail dot com

--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
*** Bug 64518 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-472373-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 07 11:11:51 2015
Return-Path: <gcc-bugs-return-472373-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31817 invoked by alias); 7 Jan 2015 11:11:50 -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 31741 invoked by uid 48); 7 Jan 2015 11:11:44 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/64518] Warning about comparison between signed and unsigned can be useless in some cases
Date: Wed, 07 Jan 2015 11:11: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: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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-64518-4-tSCpBRfYtR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64518-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64518-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-01/txt/msg00367.txt.bz2
Content-length: 672

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

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

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Unfortunately, nobody so far has come up with any idea on how to fix this.

*** This bug has been marked as a duplicate of bug 38470 ***
>From gcc-bugs-return-472375-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jan 07 11:47:01 2015
Return-Path: <gcc-bugs-return-472375-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19760 invoked by alias); 7 Jan 2015 11:47:00 -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 19482 invoked by uid 48); 7 Jan 2015 11:46:55 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/64515] Segmentation fault during linker operation in gcc for arm-none-eabi
Date: Wed, 07 Jan 2015 11:47: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: 4.8.4
X-Bugzilla-Keywords: link-failure
X-Bugzilla-Severity: major
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: WAITING
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 cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-64515-4-0AfR4Wb50i@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64515-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64515-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-01/txt/msg00369.txt.bz2
Content-length: 668

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-01-07
                 CC|                            |mpolacek at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Preprocessed source is missing, but I think you should report this to your
vendor.  (And it's not a linker error.)

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john.marshall at sanger dot ac.uk

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
*** Bug 66622 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-489554-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 22 10:41:44 2015
Return-Path: <gcc-bugs-return-489554-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 62845 invoked by alias); 22 Jun 2015 10:41:43 -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 62722 invoked by uid 48); 22 Jun 2015 10:41:39 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/66622] -Wsign-conversion does not take advantage of data flow analysis
Date: Mon, 22 Jun 2015 10:41: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: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
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-66622-4-NqDhoQBI6P@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66622-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66622-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg01886.txt.bz2
Content-length: 1758

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

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

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
It would be great if someone tried to implement this someday, it doesn't seem
trivial though.

(In reply to Mikhail Maltsev from comment #1)
> Clang also gives false positive. EDG does not warn for such conversions
> (even unconditional).

As far as I can tell, if the warning is given in the FE by using some kind of
limited VRP (which is what Clang does), the number of false positives can only
decrease, since the worst that can happen is that the analysis is not powerful
enough. The main objection to this has been the extra compilation time that
this analysis may require just for a warning (with GCC being already too slow).

Implementing it in the middle-end seems to me worse, since, as you point out,
then you may increase the number of false positives and strange things may
happen once other optimizations transform the code (also, optimization may hide
valid warnings).

A third proposal that has been floated around is to somehow mark the statement
with the warning but not emit it until after optimization. If the warning
survives after the middle-end analysis, then it will be given. This approach
seems even more complex to me.

*** This bug has been marked as a duplicate of bug 38470 ***
>From gcc-bugs-return-489556-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 22 10:50:37 2015
Return-Path: <gcc-bugs-return-489556-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 83963 invoked by alias); 22 Jun 2015 10:50:37 -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 83916 invoked by uid 48); 22 Jun 2015 10:50:32 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/66613] error in evaluationg cexp
Date: Mon, 22 Jun 2015 10:50: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: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: WAITING
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: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-66613-4-CHQWdZdcdb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66613-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66613-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-06/txt/msg01888.txt.bz2
Content-length: 584

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-06-22
     Ever confirmed|0                           |1

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue could also be in gmp/mpfr/mpc or in the C library.

How did you compile (with what flags) anyway?

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[kretz at kde dot org]

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

Matthias Kretz (Vir) <kretz at kde dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kretz at kde dot org

--- Comment #21 from Matthias Kretz (Vir) <kretz at kde dot org> ---
Is it possible to insert a predicated warning-marker into the tree in the front
end? Basically "if signed object can be negative, emit OPT_Wsign_compare
warning". It could even strengthen the message if it detects that the signed
object is guaranteed to be negative.

Then the middle end can either drop the warning from the tree or emit it as
suggested by the front end.

Test case, showing that simply predicating the warning with `if (x < 0)` works:
https://godbolt.org/z/iFePwJ. However, -O2 would still show the warning.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[kretz at kde dot org]

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

--- Comment #22 from Matthias Kretz (Vir) <kretz at kde dot org> ---
(In reply to Matthias Kretz (Vir) from comment #21)
> However, -O2 would still show the warning.

I meant -O0 of course.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org,
                   |                            |msebor at gcc dot gnu.org

--- Comment #23 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Matthias Kretz (Vir) from comment #21)
> Is it possible to insert a predicated warning-marker into the tree in the
> front end? 

I think Martin Sebor was working on a __builtin_warning() function that would
work something like that; cc-ing him

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[inkerman42 at gmail dot com]

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

Piotr Engelking <inkerman42 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |inkerman42 at gmail dot com

--- Comment #24 from Piotr Engelking <inkerman42 at gmail dot com> ---
Created attachment 51071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51071&action=edit
not useful -Wsign-compare warning involving % operator

Another case where the feature would be useful:

extern int
f(short s, unsigned int u)
{
    return s == u % 100;
}

It would be nice if the compiler noticed that rhs is always within 0..SHRT_MAX,
so the comparison is not surprisingly affected by integer promotion.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[mkretz at gcc dot gnu.org]

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

--- Comment #25 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
(In reply to Piotr Engelking from comment #24)
> It would be nice if the compiler noticed that rhs is always within
> 0..SHRT_MAX, so the comparison is not surprisingly affected by integer
> promotion.

The problem is the LHS which can be negative and has to be promoted to
`unsigned int`. This promotion changes the value from s to UINT_MAX + 1 + s. I
don't think this example is a case where -Wsign-compare should be silent.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[vincent-gcc at vinc17 dot net]

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

--- Comment #26 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Matthias Kretz (Vir) from comment #25)
> (In reply to Piotr Engelking from comment #24)
> > It would be nice if the compiler noticed that rhs is always within
> > 0..SHRT_MAX, so the comparison is not surprisingly affected by integer
    ^^^^^^^^^^^
> > promotion.
> 
> The problem is the LHS which can be negative and has to be promoted to
> `unsigned int`. This promotion changes the value from s to UINT_MAX + 1 + s.
> I don't think this example is a case where -Wsign-compare should be silent.

But if I understand Piotr Engelking's point, UINT_MAX + 1 + s is not in the
range 0..SHRT_MAX mentioned above, thus cannot be equal to u % 100. Said
otherwise, the promotion has no visible effect here (if s is negative, then the
comparison will be false, as if promotion did not occur), so that there is no
need to warn.

That said, this is very specific code, and it might not be worth to handle it.
And IMHO, this is more than what this PR is about.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[mkretz at gcc dot gnu.org]

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

--- Comment #27 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #26)
> But if I understand Piotr Engelking's point, UINT_MAX + 1 + s is not in the
> range 0..SHRT_MAX mentioned above, thus cannot be equal to u % 100. Said
> otherwise, the promotion has no visible effect here (if s is negative, then
> the comparison will be false, as if promotion did not occur), so that there
> is no need to warn.

Fair enough. But how can the compiler be certain that the developer realized u
and u % 100 is unsigned? Maybe when (s)he wrote the code the expectation was
for the RHS to be within [-99..99].

> That said, this is very specific code, and it might not be worth to handle
> it. And IMHO, this is more than what this PR is about.

I tend to agree. It's a slightly different problem and IMHO not a 100% obvious
false positive.

I believe this PR should be about dropping the warning where signed -> unsigned
promotion or implicit conversion cannot change the value because the value
range of the signed variable is limited to values >= 0.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[vincent-gcc at vinc17 dot net]

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

--- Comment #28 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Matthias Kretz (Vir) from comment #27)
> Fair enough. But how can the compiler be certain that the developer realized
> u and u % 100 is unsigned? Maybe when (s)he wrote the code the expectation
> was for the RHS to be within [-99..99].

Indeed. (I never use % when its LHS can be either positive or negative, so that
I didn't think about this case.)

Now, the cause of the bug in such a case would be that the user messed up with
the signedness of u, not because he forgot about the promotion rule. This is
something rather different.

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[mkretz at gcc dot gnu.org]

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

--- Comment #29 from Matthias Kretz (Vir) <mkretz at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #28)
> (In reply to Matthias Kretz (Vir) from comment #27)
> > Fair enough. But how can the compiler be certain that the developer realized
> > u and u % 100 is unsigned? Maybe when (s)he wrote the code the expectation
> > was for the RHS to be within [-99..99].
> 
> Indeed. (I never use % when its LHS can be either positive or negative, so
> that I didn't think about this case.)

FWIW, personally I could use a warning whenever I use % on variables that can
potentially be negative. Because my mental model of % N is that I get a result
in [0..N-1]. I tried to fix it but my head is stubborn. ;)

> Now, the cause of the bug in such a case would be that the user messed up
> with the signedness of u, not because he forgot about the promotion rule.
> This is something rather different.

Right. But if that's the case wouldn't a warning about the unexpected promotion
be useful? (which -Wsign-compare happens to provide)

To reduce the noise, I won't argue this point any further and let whoever
actually implements a fix for the PR decide. :)

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[vincent-gcc at vinc17 dot net]

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

--- Comment #30 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Matthias Kretz (Vir) from comment #29)
> Right. But if that's the case wouldn't a warning about the unexpected
> promotion be useful? (which -Wsign-compare happens to provide)

Yes, and FYI, there were such platform-dependent bugs in GNU MPFR in the past
involving additions or subtractions (not comparisons). I added the following in
its README.dev file:

--------------------------------------------------------------------------
Avoid mixing signed and unsigned integer types, as this can lead signed
types to be automatically converted into unsigned types (usual arithmetic
conversions). If such a signed type contains a negative value, the result
may be incorrect on some platforms. With MPFR 2.x, this problem could
arise with mpfr_exp_t, which is signed, and mpfr_prec_t (mp_prec_t),
which was unsigned (it is now signed), meaning that in general, a cast
of a mpfr_prec_t to a mpfr_exp_t was needed.

Note that such bugs are difficult to detect because they may depend on
the platform (e.g., on LP64, 32-bit unsigned int + 64-bit long will give
a signed type, but on ILP32, 32-bit int + 32-bit unsigned long will give
an unsigned type, which may not be what is expected), but also on the
input values. So, do not rely on tests very much. However, if a test
works on 32 bits but fails on 64 bits in the extended exponent range
(or conversely), the cause may be related to the integer types (e.g. a
signness problem or an integer overflow due to different type sizes).

For instance, in MPFR, such issues were fixed in r1992 and r5588.

An example that will fail with 32-bit int and long:

    long long umd(void)
    {
      long a = 1;
      unsigned int b = 2;
      return a - b;
    }
--------------------------------------------------------------------------

So a warning for such operations would also be useful. But I'm not sure about
potential issues with false positives...

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[m dot j dot thayer at googlemail dot com]

------- Comment #8 from m dot j dot thayer at googlemail dot com  2010-02-24 14:16 -------
Of course.  I asked this without knowing much about compiler internals, but I
do have experience of users asking for "little" features which would involve
somewhat more work than they would like to think :)


-- 


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

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[manu at gcc dot gnu dot org]

------- Comment #7 from manu at gcc dot gnu dot org  2010-02-24 14:12 -------
(In reply to comment #5)
> Comment 3 describes what I meant.  And re comment 4, it is a "would be nice to
> have", obviously if it is too much pain to do then such is life.  Thanks in any
> case.

Please, do not understand me wrong. I totally agree it would be nice to have
and we should leave this open in case someone steps up to the task (patches
welcome, as they say). I was just commenting that you should not expect a quick
fix because it is more complex than it seems. And thanks for the report.


-- 


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

[Bug c/38470] value range propagation (VRP) would improve -Wsign-compare

[manu at gcc dot gnu dot org]

------- Comment #6 from manu at gcc dot gnu dot org  2010-02-24 14:11 -------
Fixing this is even more unlikely than fixing PR 23608, since the latter only
asks for constant propagation, but this one requires value range propagation.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |23608
            Summary|dataflow would improve -    |value range propagation
                   |Wsign-compare               |(VRP) would improve -Wsign-
                   |                            |compare


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