[Bug c++/61760] New: -Wconversion inconsistency between gcc and g++

[Bug c++/61760] New: -Wconversion inconsistency between gcc and g++

[js at alien8 dot de]

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

            Bug ID: 61760
           Summary: -Wconversion inconsistency between gcc and g++
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: js at alien8 dot de

Given the code:

unsigned char foo(unsigned char x)
{
    return x >> 1;
}

If you compile this with 'gcc -Wconversion -c foo.c', there is no warning. If
you compile it with 'g++ -Wconversion -c foo.c' you get:

foo.c:3:11: warning: conversion to ‘unsigned char’ from ‘int’ may alter its
value [-Wconversion]
  return x >> 1;

I would argue that the conversion warning is false in both cases, because there
is no information loss involved, even though the intermediate result is cast to
an int.

Is there a reason why g++ produces the warning here or is this a bug?

This happens using 4.8.3 and 4.9.1 20140706 (prerelease) on x86_64.
>From gcc-bugs-return-455977-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 09 18:10:51 2014
Return-Path: <gcc-bugs-return-455977-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7276 invoked by alias); 9 Jul 2014 18:10:51 -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 7224 invoked by uid 48); 9 Jul 2014 18:10:47 -0000
From: "kariya_mitsuru at hotmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/61761] New: [C++11] std::proj returns incorrect values
Date: Wed, 09 Jul 2014 18:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kariya_mitsuru at hotmail dot com
X-Bugzilla-Status: UNCONFIRMED
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
Message-ID: <bug-61761-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: 2014-07/txt/msg00568.txt.bz2
Content-length: 2099

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

            Bug ID: 61761
           Summary: [C++11] std::proj returns incorrect values
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kariya_mitsuru at hotmail dot com

std::proj returns incorrect values if _GLIBCXX_USE_C99_COMPLEX is not defined.

For example, std::proj(std::complex<double>(1, 2)) should be
std::complex<double>(1, 2) but libstdc++ returns
std::complex<double>(0.333333,0.666667).

If _GLIBCXX_USE_C99_COMPLEX is defined, the sample code below can show the
difference between a glibc version and a libstdc++ version.

============ sample source =======================================#include <iostream>
#include <complex>
#include <climits>

void check(const std::complex<double>& c)
{
  // libstdc++ version
  std::complex<double> r1 = std::__complex_proj(c);
  std::cout << "libstdc++ version : proj( " << c << " ) = " << r1 << std::endl;

  // glibc version
  std::complex<double> r2 = std::__complex_proj(c.__rep());
  std::cout << "glibc     version : proj( " << c << " ) = " << r2 << std::endl;
}

int main()
{
  check(std::complex<double>(1, 2));
  check(std::complex<double>(1, NAN));
}
============ sample output =======================================libstdc++ version : proj( (1,2) ) = (0.333333,0.666667)
glibc     version : proj( (1,2) ) = (1,2)
libstdc++ version : proj( (1,nan) ) = (nan,nan)
glibc     version : proj( (1,nan) ) = (1,nan)
==================================================================
According to C99 standard 7.3.9.4 (referenced from C++11 standard 26.4.7
[complex.value.ops] paragraph 8), "z projects to z except that all complex
infinities (even those with one infinite part and one NaN part) project to
positive infinity on the real axis."

Note that the glibc version 2.11 or below had the same bug.
(For std::complex<double>(1, NAN), the glibc version 2.18 or below had a
different bug.)

[Bug c++/61760] -Wconversion inconsistency between gcc and g++

[manu at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-07-09
                 CC|                            |manu at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
The C FE produces:

 <nop_expr 0x7ffff751dfe0
    type <integer_type 0x7ffff740a690 int public SI
        size <integer_cst 0x7ffff74088b8 constant 32>
        unit size <integer_cst 0x7ffff74088d0 constant 4>
        align 32 symtab 0 alias set -1 canonical type 0x7ffff740a690 precision
32 min <integer_cst 0x7ffff7408870 -2147483648> max <integer_cst 0x7ffff7408888
2147483647>
        pointer_to_this <pointer_type 0x7ffff7415738>>

    arg 0 <rshift_expr 0x7ffff750eac8
        type <integer_type 0x7ffff740a3f0 unsigned char public unsigned
string-flag QI
            size <integer_cst 0x7ffff7408768 constant 8>
            unit size <integer_cst 0x7ffff7408780 constant 1>
            align 8 symtab 0 alias set -1 canonical type 0x7ffff740a3f0
precision 8 min <integer_cst 0x7ffff7408798 0> max <integer_cst 0x7ffff7408738
255>>

        arg 0 <parm_decl 0x7ffff7531000 x type <integer_type 0x7ffff740a3f0
unsigned char>
            used unsigned QI file /home/manuel/test.c line 1 col 33 size
<integer_cst 0x7ffff7408768 8> unit size <integer_cst 0x7ffff7408780 1>
            align 8 context <function_decl 0x7ffff7514700 foo> arg-type
<integer_type 0x7ffff740a3f0 unsigned char>>
        arg 1 <integer_cst 0x7ffff7408a20 constant 1>>
    /home/manuel/test.c:3:12>

that is (int) (x >> 1).

The C++ FE produces:

 <rshift_expr 0x7ffff75603e8
    type <integer_type 0x7ffff740a690 int public SI
        size <integer_cst 0x7ffff7408a68 constant 32>
        unit size <integer_cst 0x7ffff7408a80 constant 4>
        align 32 symtab 0 alias set -1 canonical type 0x7ffff740a690 precision
32 min <integer_cst 0x7ffff7408a20 -2147483648> max <integer_cst 0x7ffff7408a38
2147483647>
        pointer_to_this <pointer_type 0x7ffff741c738>>

    arg 0 <nop_expr 0x7ffff7576220 type <integer_type 0x7ffff740a690 int>

        arg 0 <parm_decl 0x7ffff7577080 x type <integer_type 0x7ffff740a3f0
unsigned char>
            used unsigned QI file /home/manuel/test.c line 1 col 33
            size <integer_cst 0x7ffff7408918 constant 8>
            unit size <integer_cst 0x7ffff7408930 constant 1>
            align 8 context <function_decl 0x7ffff7567b00 foo>
            arg-type <integer_type 0x7ffff740a690 int>>>
    arg 1 <integer_cst 0x7ffff7408bd0 type <integer_type 0x7ffff740a690 int>
constant 1>
    /home/manuel/test.c:3:12>

that is (((int)x) >> 1)

I am not sure which one is more correct, but the latter prevents
unsafe_conversion_p from seeing that the implicit conversion cannot alter the
value.
>From gcc-bugs-return-455979-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 09 19:08:33 2014
Return-Path: <gcc-bugs-return-455979-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27680 invoked by alias); 9 Jul 2014 19:08:32 -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 27397 invoked by uid 48); 9 Jul 2014 19:08:22 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61760] -Wconversion inconsistency between gcc and g++
Date: Wed, 09 Jul 2014 19:08: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.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-61760-4-WrvmtRe9fI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61760-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61760-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: 2014-07/txt/msg00570.txt.bz2
Content-length: 512

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

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
I see now that the C FE has a FE optimization (short_shift in build_binary_op)
that the C++ FE doesn't have. The optimization is probably useless for code
generation, but for improving -Wconversion, it would need to be moved to
c-common.c and used in unsafe_conversion_p, like we do with shorten_binary_op.

I don't have time to work on this, so any help is welcome.
>From gcc-bugs-return-455980-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jul 09 19:08:51 2014
Return-Path: <gcc-bugs-return-455980-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28600 invoked by alias); 9 Jul 2014 19:08: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 28509 invoked by uid 48); 9 Jul 2014 19:08:45 -0000
From: "froydnj at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/61762] New: failure to optimize memcpy from constant string
Date: Wed, 09 Jul 2014 19:08:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: froydnj at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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
Message-ID: <bug-61762-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: 2014-07/txt/msg00571.txt.bz2
Content-length: 894

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

            Bug ID: 61762
           Summary: failure to optimize memcpy from constant string
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: froydnj at gcc dot gnu.org

There's probably a duplicate of this, but GCC HEAD on the following testcase:

unsigned int f()
{
  static const char string[] = "Private";

  unsigned int priv;
  __builtin_memcpy(&priv, &string[0], sizeof(priv));
  return priv;
}

produces for x86-64:

f:
.LFB0:
    .cfi_startproc
    movl    _ZZ1fvE6string(%rip), %eax
    ret
    .cfi_endproc

Compare clang (~3.0) for x86-64:

f:
.Ltmp0:
    .cfi_startproc
# BB#0:
    movl    $1986622032, %eax       # imm = 0x76697250
    ret