public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "tromey at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61162] New: possibly bad error location with -Wc++-compat
Date: Tue, 13 May 2014 03:37:00 -0000	[thread overview]
Message-ID: <bug-61162-4@http.gcc.gnu.org/bugzilla/> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6153 bytes --]

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

            Bug ID: 61162
           Summary: possibly bad error location with -Wc++-compat
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tromey at gcc dot gnu.org

Consider this source:

enum e { ZERO = 0, ONE };

enum e e_val;

void f(void)
{
  e_val = 0;
}


Compile with -Wc++-compat:

bapiya. gcc -Wc++-compat --syntax-only r.c
r.c: In function ‘f’:
r.c:7:3: warning: enum conversion in assignment is invalid in C++
[-Wc++-compat]
   e_val = 0;
   ^


I think perhaps using the location of the "=" would be preferable.
>From gcc-bugs-return-451393-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 13 03:51:22 2014
Return-Path: <gcc-bugs-return-451393-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6815 invoked by alias); 13 May 2014 03:51:21 -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 6802 invoked by uid 48); 13 May 2014 03:51:19 -0000
From: "hstong at ca dot ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61163] New: Placement arguments shared between allocation and deallocation even when copies prohibited
Date: Tue, 13 May 2014 03:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hstong at ca dot ibm.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-61163-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-05/txt/msg01085.txt.bz2
Content-length: 3480

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

            Bug ID: 61163
           Summary: Placement arguments shared between allocation and
                    deallocation even when copies prohibited
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hstong at ca dot ibm.com

In N3290 subclause 5.3.4 [expr.new] paragraph 21, the leeway to reuse the same
copy of the initialized parameter for both the call to the allocation function
and the call to the deallocation function is prefaced with "[i]f the
implementation is allowed to make a copy".
Since, in the case below, list initialization does not involve copying
following the call to the converting constructor, there is no copying to speak
of and the leeway is not given.
GCC performs the reuse anyway.

### SOURCE:> cat gccListInitNewPlacement.cc
extern "C" int printf(const char *, ...);

struct A {
   A(const A &) = delete;
   A(A &&) = delete;

   A(int) : x(0) { printf("%s\n", __PRETTY_FUNCTION__); }
   ~A() { printf("%s\n", __PRETTY_FUNCTION__); }

   int x;
};

struct B {
   static void *operator new(decltype(sizeof(0)) sz, A a) {
      printf("%d %s\n", a.x++, __PRETTY_FUNCTION__);
      return ::operator new(sz);
   }

   static void operator delete(void *ptr, A a) {
      printf("%d %s\n", a.x++, __PRETTY_FUNCTION__);
      return ::operator delete(ptr);
   }

   B() { throw 0; }
};

int main() {
   try { new ({0}) B; } catch(...) { }
}


### COMPILER INVOCATION:> g++ -std=c++11 -pedantic-errors -Wall -Wextra
gccListInitNewPlacement.cc -o gccListInitNewPlacement


### OUTPUT FROM RESULTING BINARY:> ./gccListInitNewPlacement
A::A(int)
0 static void* B::operator new(long unsigned int, A)
1 static void B::operator delete(void*, A)
A::~A()


### EXPECTED OUTPUT:
A::A(int)
0 static void* B::operator new(long unsigned int, A)
A::A(int)
0 static void B::operator delete(void*, A)
A::~A()
A::~A()


### VERSION INFO:> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-3/src/gcc-4.8.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-3/src/gcc-4.8.2
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --enable-shared
--enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs
--enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-tune=generic
--enable-languages­a,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --libexecdir=/usr/lib
Thread model: posix
gcc version 4.8.2 (GCC)


             reply	other threads:[~2014-05-13  3:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13  3:37 tromey at gcc dot gnu.org [this message]
2014-05-13  5:10 ` [Bug c/61162] " tromey at gcc dot gnu.org
2014-05-13  6:44 ` tromey at gcc dot gnu.org
2014-05-13  7:46 ` mpolacek at gcc dot gnu.org
2014-05-13 15:50 ` tromey at gcc dot gnu.org
2014-05-13 17:41 ` mpolacek at gcc dot gnu.org
2014-05-13 17:57 ` mpolacek at gcc dot gnu.org
2014-06-25 12:43 ` mpolacek at gcc dot gnu.org
2014-06-25 12:44 ` mpolacek at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-61162-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).