[Bug c/61162] New: possibly bad error location with -Wc++-compat

[Bug c/61162] New: possibly bad error location with -Wc++-compat

[tromey at gcc dot gnu.org]

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

[Bug c/61162] possibly bad error location with -Wc++-compat

[tromey at gcc dot gnu.org]

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

--- Comment #2 from Tom Tromey <tromey at gcc dot gnu.org> ---
Note that it is also wrong for a conversion diagnosed
in a "return":

enum e { ZERO = 0, ONE };

enum e f(void)
{
  return 0;
}


barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:5:3: warning: enum conversion in return is invalid in C++ [-Wc++-compat]
   return 0;
   ^


I think it should point to the expression.
>From gcc-bugs-return-451397-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 13 05:32:21 2014
Return-Path: <gcc-bugs-return-451397-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5198 invoked by alias); 13 May 2014 05:32:20 -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 5166 invoked by uid 48); 13 May 2014 05:32:15 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61162] possibly bad error location with -Wc++-compat
Date: Tue, 13 May 2014 05:32: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61162-4-dGSjFUeZEl@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61162-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61162-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/msg01089.txt.bz2
Content-length: 208

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I posted a patch, but the location for a return stmt will need more surgery
than that.

[Bug c/61162] possibly bad error location with -Wc++-compat

[tromey at gcc dot gnu.org]

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

--- Comment #4 from Tom Tromey <tromey at gcc dot gnu.org> ---
Note that it is also wrong in the initializer case.

enum e f(void)
{
  enum e result = 0;

  return result;
}


barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:5:8: warning: enum conversion in initialization is invalid in C++
[-Wc++-compat]
   enum e result = 0;
        ^
>From gcc-bugs-return-451403-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 13 06:46:33 2014
Return-Path: <gcc-bugs-return-451403-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12936 invoked by alias); 13 May 2014 06:46:33 -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 12885 invoked by uid 48); 13 May 2014 06:46:28 -0000
From: "tromey at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61162] possibly bad error location with -Wc++-compat
Date: Tue, 13 May 2014 06:46: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tromey at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61162-4-cMalXNNWUA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61162-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61162-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-05/txt/msg01095.txt.bz2
Content-length: 590

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

--- Comment #5 from Tom Tromey <tromey at gcc dot gnu.org> ---
But, curiously, in this case it points to the RHS of the assignment
(I still tend to think the "=" is the best location):

extern void *alloc (void);

int *f (void) {
  int *r = alloc ();
  return r;
}

barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:4:12: warning: request for implicit conversion from ‘void *’ to ‘int *’ not
permitted in C++ [-Wc++-compat]
   int *r = alloc ();
            ^
>From gcc-bugs-return-451404-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 13 07:22:34 2014
Return-Path: <gcc-bugs-return-451404-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5193 invoked by alias); 13 May 2014 07:22:34 -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 4708 invoked by uid 48); 13 May 2014 07:22:28 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
Date: Tue, 13 May 2014 07:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: ice-on-valid-code, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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: 4.9.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc target_milestone everconfirmed
Message-ID: <bug-61160-4-mj7MnIHRTR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61160-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61160-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/msg01096.txt.bz2
Content-length: 661

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-05-13
                 CC|                            |jakub at gcc dot gnu.org
   Target Milestone|---                         |4.9.1
     Ever confirmed|0                           |1

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r202145 (aka speculative devirtualization addition).

[Bug c/61162] possibly bad error location with -Wc++-compat

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #4)
> Note that it is also wrong in the initializer case.

Right, my patch fixes this too.


(In reply to Tom Tromey from comment #5)
> But, curiously, in this case it points to the RHS of the assignment

Yeah, this warning comes from a different spot than the previous ones.

> (I still tend to think the "=" is the best location):
> 
> extern void *alloc (void);
> 
> int *f (void) {
>   int *r = alloc ();
>   return r;
> }
> 
> barimba. gcc --syntax-only -Wc++-compat r.c
> r.c: In function ‘f’:
> r.c:4:12: warning: request for implicit conversion from ‘void *’ to ‘int *’
> not permitted in C++ [-Wc++-compat]
>    int *r = alloc ();
>             ^

I'd prefer the RHS location here; it's the RHS that's being converted.
>From gcc-bugs-return-451407-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 13 07:50:03 2014
Return-Path: <gcc-bugs-return-451407-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20808 invoked by alias); 13 May 2014 07:50:03 -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 20360 invoked by uid 48); 13 May 2014 07:49:58 -0000
From: "tromey at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61162] possibly bad error location with -Wc++-compat
Date: Tue, 13 May 2014 07: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tromey at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61162-4-C8jwVKuLJO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61162-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61162-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/msg01099.txt.bz2
Content-length: 602

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

--- Comment #7 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #6)

> I'd prefer the RHS location here; it's the RHS that's being converted.

I was hoping to automate some conversion from C to C++ using
the error locations.
So from this perspective, something relatively consistent would be nice.
It could be the RHS or it could be the "=", for my purposes they
are equally good.  I tend to think of the "=" as being the "reason
for the conversion", but I wouldn't want to make any claims for it
beyond that.

[Bug c/61162] possibly bad error location with -Wc++-compat

[tromey at gcc dot gnu.org]

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

--- Comment #9 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #8)

> If you point to '=', then the macro expansion note will not appear in your
> other example (PR61165).

Yeah, I still think the '=' is preferable.
I think it lets one know exactly where to insert a cast.
>From gcc-bugs-return-451489-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 13 15:51:17 2014
Return-Path: <gcc-bugs-return-451489-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8848 invoked by alias); 13 May 2014 15:51:17 -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 8178 invoked by uid 48); 13 May 2014 15:51:10 -0000
From: "tony.theodore at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc -> clang)
Date: Tue, 13 May 2014 15:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tony.theodore at gmail 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:
Message-ID: <bug-60981-4-KGmKFtYHkP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60981-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60981-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/msg01181.txt.bz2
Content-length: 1574

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`981

--- Comment #6 from Tony Theodore <tony.theodore at gmail dot com> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #4)
> > --- Comment #3 from Tony Theodore <tony.theodore at gmail dot com> ---
> > I'm building a cross compiler with:
>
> It would have helped enormously if you'd stated so in the first place.

Apologies.

> > Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
> > Target: x86_64-apple-darwin13.1.0
> > Thread model: posix
>
> On Mac OS X 10.7, gcc -v *does accept* -static-libgcc, though, although
> it's also LLVM-based.  No idea why they changed this in 10.9.

Up till LLVM 3.3 there was a gcc plugin called DragonEgg which used gcc as a
front-end and LLVM as the back-end. Now "gcc" is basically an alias for the
clang front-end.

> Your proposed patch has two problems, unfortunately:
>
> * Don't check for $GCC.  I don't care who the compiler thinks he is as
>   long as it accepts -static-libgcc.
>
> * The gcc version check is wrong: -static-libgcc goes back way long
>   (even 2.95 and perhaps even before).  It did apply to
>   -static-libstdc++, though I don't know what a version check buys us if
>   the compiler accepts the option.

Thanks for the explanation, that make sense.

> Please try the attached patch instead.  Manual testing with Oracle
> Studio cc (which doesn't accept -static-libgcc) and gcc gave the correct
> results.

I can confirm that this works with all three mingw targets (after installing
autoconf 2.64) - thank you very much!

Cheers,

Tony

[Bug c/61162] possibly bad error location with -Wc++-compat

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Tue May 13 17:41:12 2014
New Revision: 210393

URL: http://gcc.gnu.org/viewcvs?rev=210393&root=gcc&view=rev
Log:
    PR c/61162
    * c-typeck.c (convert_for_assignment): Pass location to
    WARN_FOR_ASSIGNMENT instead of input_location.

    * gcc.dg/pr61162.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr61162.c
Modified:
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-typeck.c
    trunk/gcc/testsuite/ChangeLog

[Bug c/61162] possibly bad error location with -Wc++-compat

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Not marking this as fixed yet, we should probably address the column info for
return stmts.

[Bug c/61162] possibly bad error location with -Wc++-compat

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Wed Jun 25 12:43:05 2014
New Revision: 211978

URL: https://gcc.gnu.org/viewcvs?rev=211978&root=gcc&view=rev
Log:
    PR c/61162
    * c-parser.c (c_parser_statement_after_labels): Pass the location of
    the return expression to c_finish_return.

    * gcc.dg/pr61162.c: Adjust dg-warning.
    * gcc.dg/pr61162-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr61162-2.c
Modified:
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-parser.c
    trunk/gcc/c/c-typeck.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/pr61162.c

[Bug c/61162] possibly bad error location with -Wc++-compat

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #13 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Should be fixed now.