[Bug c/66622] New: -Wsign-conversion does not take advantage of data flow analysis

[Bug c/66622] New: -Wsign-conversion does not take advantage of data flow analysis

[john.marshall at sanger dot ac.uk]

[-- 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".

[Bug c/66622] -Wsign-conversion does not take advantage of data flow analysis

[miyuki at gcc dot gnu.org]

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).