From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12447 invoked by alias); 29 Apr 2014 07:12:17 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 12410 invoked by uid 48); 29 Apr 2014 07:12:13 -0000 From: "vogt at linux dot vnet.ibm.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/60995] New: gccgo ignores .a files with "/SYM64/" symbol table Date: Tue, 29 Apr 2014 07:12:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Version: 4.10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vogt at linux dot vnet.ibm.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com 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: 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-04/txt/msg02113.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60995 Bug ID: 60995 Summary: gccgo ignores .a files with "/SYM64/" symbol table Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: vogt at linux dot vnet.ibm.com On platforms where ar generates .a files with a "/SYM64/" symbol table (e.g. s390x), gccgo cannot extract Go export data from such files. This is becau= se import-archive.cc:Archive_file::interpret_header() does not recognize the special file name "/SYM64/ " and treats it as an extended name and fails with two error messages: error: .../libfoo.a: bad extended name index at 8 error: .../libfoo.a exists but does not contain any Go export data This is easy to fix by recognizing "/SYM64/<9*space>" as a symbol table by inserting something like this before the final "else" in interpret_header(): > else if (hdr->ar_name[1] =3D=3D 'S' && hdr->ar_name[2] =3D=3D 'Y' > && hdr->ar_name[3] =3D=3D 'M' && hdr->ar_name[4] =3D=3D '6' > && hdr->ar_name[5] =3D=3D '4' && hdr->ar_name[6] =3D=3D '/' > && hdr->ar_name[7] =3D=3D ' ' > ) > { > // 64-bit symbol table. > pname->clear(); > } Note: Same problem as this one: http://code.google.com/p/go/issues/detail?id=3D6383 >>From gcc-bugs-return-450095-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 29 07:20:23 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 20036 invoked by alias); 29 Apr 2014 07:20:21 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 19998 invoked by uid 48); 29 Apr 2014 07:20:15 -0000 From: "trippels at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier Date: Tue, 29 Apr 2014 07:20: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.10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: trippels at gcc dot gnu.org X-Bugzilla-Status: RESOLVED 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: In-Reply-To: References: 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-04/txt/msg02115.txt.bz2 Content-length: 619 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60994 --- Comment #2 from Markus Trippelsdorf --- (In reply to Markus Trippelsdorf from comment #1) > Implicit enum to int conversion is not provided for a scoped enumeration. That said it is strange that gcc also rejects a plain enum: markus@x4 /tmp % cat foo.cpp enum A { n =3D 3 }; int foo() { int A; return A::n; } markus@x4 /tmp % g++ -c -std=3Dc++11 -O3 foo.cpp foo.cpp: In function =E2=80=98int foo()=E2=80=99: foo.cpp:10:10: error: =E2=80=98A=E2=80=99 is not a class, namespace, or enu= meration return A::n; ^ >>From gcc-bugs-return-450096-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Apr 29 07:21:13 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 21769 invoked by alias); 29 Apr 2014 07:21:13 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 21734 invoked by uid 48); 29 Apr 2014 07:21:08 -0000 From: "momchil.velikov at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier Date: Tue, 29 Apr 2014 07:21: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.10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: momchil.velikov at gmail dot com X-Bugzilla-Status: RESOLVED 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: In-Reply-To: References: 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-04/txt/msg02116.txt.bz2 Content-length: 879 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994 --- Comment #3 from Momchil Velikov --- (In reply to Markus Trippelsdorf from comment #1) > Implicit enum to int conversion is not provided for a scoped enumeration. This is not the reported error. In fact, the correct output of the compiler would be to report the invalid implicit conversion. It does not. With explicit conversion to int, the compiler still gives an error, but the error message is not helpful and obscures the cause of the problem, i.e., compiling this: enum struct A { n = 3 }; int foo() { int A; return int(A::n); } results in: b.cc: In function 'int foo()': b.cc:10:10: error: expected primary-expression before 'int' return int(A::n); ^ b.cc:10:10: error: expected ';' before 'int' b.cc:10:10: error: expected primary-expression before 'int'