* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
@ 2011-06-15 18:16 ` manu at gcc dot gnu.org
2012-03-24 7:50 ` DeusExSophismata at gmail dot com
` (14 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: manu at gcc dot gnu.org @ 2011-06-15 18:16 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
2011-06-15 18:16 ` [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare manu at gcc dot gnu.org
@ 2012-03-24 7:50 ` DeusExSophismata at gmail dot com
2012-04-16 10:44 ` manu at gcc dot gnu.org
` (13 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: DeusExSophismata at gmail dot com @ 2012-03-24 7:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
2011-06-15 18:16 ` [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare manu at gcc dot gnu.org
2012-03-24 7:50 ` DeusExSophismata at gmail dot com
@ 2012-04-16 10:44 ` manu at gcc dot gnu.org
2013-05-20 13:23 ` paolo.carlini at oracle dot com
` (12 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-16 10:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2012-04-16 10:44 ` manu at gcc dot gnu.org
@ 2013-05-20 13:23 ` paolo.carlini at oracle dot com
2015-01-07 11:11 ` manu at gcc dot gnu.org
` (11 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: paolo.carlini at oracle dot com @ 2013-05-20 13:23 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2013-05-20 13:23 ` paolo.carlini at oracle dot com
@ 2015-01-07 11:11 ` manu at gcc dot gnu.org
2015-06-22 10:41 ` manu at gcc dot gnu.org
` (10 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: manu at gcc dot gnu.org @ 2015-01-07 11:11 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2015-01-07 11:11 ` manu at gcc dot gnu.org
@ 2015-06-22 10:41 ` manu at gcc dot gnu.org
2020-05-06 8:45 ` kretz at kde dot org
` (9 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: manu at gcc dot gnu.org @ 2015-06-22 10:41 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2015-06-22 10:41 ` manu at gcc dot gnu.org
@ 2020-05-06 8:45 ` kretz at kde dot org
2020-05-06 8:46 ` kretz at kde dot org
` (8 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: kretz at kde dot org @ 2020-05-06 8:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2020-05-06 8:45 ` kretz at kde dot org
@ 2020-05-06 8:46 ` kretz at kde dot org
2020-11-03 4:14 ` egallager at gcc dot gnu.org
` (7 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: kretz at kde dot org @ 2020-05-06 8:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2020-05-06 8:46 ` kretz at kde dot org
@ 2020-11-03 4:14 ` egallager at gcc dot gnu.org
2021-06-28 13:01 ` inkerman42 at gmail dot com
` (6 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: egallager at gcc dot gnu.org @ 2020-11-03 4:14 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2020-11-03 4:14 ` egallager at gcc dot gnu.org
@ 2021-06-28 13:01 ` inkerman42 at gmail dot com
2021-06-28 13:51 ` mkretz at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: inkerman42 at gmail dot com @ 2021-06-28 13:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2021-06-28 13:01 ` inkerman42 at gmail dot com
@ 2021-06-28 13:51 ` mkretz at gcc dot gnu.org
2021-06-28 14:13 ` vincent-gcc at vinc17 dot net
` (4 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: mkretz at gcc dot gnu.org @ 2021-06-28 13:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2021-06-28 13:51 ` mkretz at gcc dot gnu.org
@ 2021-06-28 14:13 ` vincent-gcc at vinc17 dot net
2021-06-28 14:30 ` mkretz at gcc dot gnu.org
` (3 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2021-06-28 14:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2021-06-28 14:13 ` vincent-gcc at vinc17 dot net
@ 2021-06-28 14:30 ` mkretz at gcc dot gnu.org
2021-06-28 14:53 ` vincent-gcc at vinc17 dot net
` (2 subsequent siblings)
15 siblings, 0 replies; 19+ messages in thread
From: mkretz at gcc dot gnu.org @ 2021-06-28 14:30 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2021-06-28 14:30 ` mkretz at gcc dot gnu.org
@ 2021-06-28 14:53 ` vincent-gcc at vinc17 dot net
2021-06-28 15:07 ` mkretz at gcc dot gnu.org
2021-06-28 15:33 ` vincent-gcc at vinc17 dot net
15 siblings, 0 replies; 19+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2021-06-28 14:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2021-06-28 14:53 ` vincent-gcc at vinc17 dot net
@ 2021-06-28 15:07 ` mkretz at gcc dot gnu.org
2021-06-28 15:33 ` vincent-gcc at vinc17 dot net
15 siblings, 0 replies; 19+ messages in thread
From: mkretz at gcc dot gnu.org @ 2021-06-28 15:07 UTC (permalink / raw)
To: gcc-bugs
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. :)
^ permalink raw reply [flat|nested] 19+ messages in thread* [Bug c/38470] value range propagation (VRP) would improve -Wsign-compare
[not found] <bug-38470-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2021-06-28 15:07 ` mkretz at gcc dot gnu.org
@ 2021-06-28 15:33 ` vincent-gcc at vinc17 dot net
15 siblings, 0 replies; 19+ messages in thread
From: vincent-gcc at vinc17 dot net @ 2021-06-28 15:33 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 19+ messages in thread