public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/66622] New: -Wsign-conversion does not take advantage of data flow analysis
@ 2015-06-22 8:29 john.marshall at sanger dot ac.uk
2015-06-22 10:28 ` [Bug c/66622] " miyuki at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: john.marshall at sanger dot ac.uk @ 2015-06-22 8:29 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4545 bytes --]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66622
Bug ID: 66622
Summary: -Wsign-conversion does not take advantage of data flow
analysis
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: john.marshall at sanger dot ac.uk
Target Milestone: ---
With GCC 5.1 built from gcc-5.1.0.tar.bz2 on OS X:
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc-5.1.0/configure --prefix=...
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 5.1.0 (GCC)
The following C program compiled with -Wsign-conversion produces a warning:
unsigned foo(int i) {
if (i < 0) return 0;
else return i;
}
$ gcc-5.1 -c -Wsign-conversion valueconv.c
valueconv.c: In function âfooâ:
valueconv.c:3:15: warning: conversion to âunsigned intâ from âintâ may change
the sign of the result [-Wsign-conversion]
else return i;
However if the compiler took advantage of the fact that i>=0 within the else,
it would realise the warning was a false positive.
>From gcc-bugs-return-489548-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 22 08:42:30 2015
Return-Path: <gcc-bugs-return-489548-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 90152 invoked by alias); 22 Jun 2015 08:42:30 -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 88373 invoked by uid 48); 22 Jun 2015 08:42:26 -0000
From: "david.sherwood at arm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/66623] New: Unsafe FP math reduction used in strict math mode
Date: Mon, 22 Jun 2015 08:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: david.sherwood at arm dot com
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created
Message-ID: <bug-66623-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/msg01880.txt.bz2
Content-length: 1439
https://gcc.gnu.org/bugzilla/show_bug.cgi?idf623
Bug ID: 66623
Summary: Unsafe FP math reduction used in strict math mode
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: david.sherwood at arm dot com
Target Milestone: ---
Created attachment 35825
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id5825&actioníit
Unsafe FP math reduction example
I've found a bug with reductions for Neon whereby we change the ordering
of FP computation in strict math mode. The example looks like this:
float foo (float *__restrict__ i)
{
float l = 0;
for (int a = 0; a < 4; a++)
for (int b = 0; b < 4; b++)
l += i[b];
return l;
}
when compiled with the flags
-O2 -ftree-vectorize -fno-inline -march=armv8-a
we generate the asm:
movi v0.4s, 0
mov x1, x0
mov w0, 0
.L2:
ldr s1, [x1, w0, sxtw 2]
add w0, w0, 1
cmp w0, 4
dup v1.4s, v1.s[0]
fadd v0.4s, v0.4s, v1.4s
bne .L2
faddp v0.4s, v0.4s, v0.4s
faddp v0.4s, v0.4s, v0.4s
which is (i[0] + i[1] + ...) + (i[0] + i[1] + ...) + ... We know that in
general
"(a + b) + (a + b)" is not guaranteed to be the same as "((a + b) + a) + b".
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug c/66622] -Wsign-conversion does not take advantage of data flow analysis
2015-06-22 8:29 [Bug c/66622] New: -Wsign-conversion does not take advantage of data flow analysis john.marshall at sanger dot ac.uk
@ 2015-06-22 10:28 ` miyuki at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: miyuki at gcc dot gnu.org @ 2015-06-22 10:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66622
Mikhail Maltsev <miyuki at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |diagnostic
CC| |miyuki at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #1 from Mikhail Maltsev <miyuki at gcc dot gnu.org> ---
That is possible to implement, but not easy. The compiler transforms code in
such a way that lots of information is lost and it's hard to tell which code
was written by user, and which was generated by the compiler. Very few warnings
are actually emitted at the stage when data flow (use-def chains and value
ranges) is known (for example -Wmaybe-uninitialized, but it has rather frequent
false positives:
https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=Wmaybe-uninitialized).
In your case the program will look like this at very early stage:
unsigned foo(int i)
{
unsigned result;
if (i < 0)
goto bb1;
else
goto bb2;
bb1:
result = 0;
return result;
bb2:
result = (unsigned)i;
return result;
}
Later it will be impossible to say, whether the conversion was introduced
explicitly by user, or by the compiler.
Clang also gives false positive. EDG does not warn for such conversions (even
unconditional).
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2015-06-22 10:28 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-22 8:29 [Bug c/66622] New: -Wsign-conversion does not take advantage of data flow analysis john.marshall at sanger dot ac.uk
2015-06-22 10:28 ` [Bug c/66622] " miyuki at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).