From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31282 invoked by alias); 21 Apr 2014 19:39:01 -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 31201 invoked by uid 48); 21 Apr 2014 19:38:58 -0000 From: "harald at gigawatt dot nl" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/2316] g++ fails to overload on language linkage Date: Mon, 21 Apr 2014 19:39: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: 2.97 X-Bugzilla-Keywords: ABI, accepts-invalid, rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: harald at gigawatt dot nl 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: 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/msg01451.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D2316 --- Comment #53 from Harald van Dijk --- (In reply to Marc Glisse from comment #52) > (In reply to Harald van Dijk from comment #51) > > extern "C" { void f(); } > > typedef void t(); > > t f, *g =3D f; // valid redeclaration of f, invalid initialisation of g >=20 > Fun! What's fun is that in getting this working, I found not only had I accident= ally introduced a bug (already fixed -- the typedef got changed, instead of only= the function's type), but that exact same bug also affects in Sun C++. > > extern "C" t f; // invalid redeclaration of f >=20 > I am not 100% sure about that one. It redeclares f as void(), where the previous declaration gave it type void= () extern "C", and the special exception in [dcl.link] to inherit a previous declaration's linkage (both of the name and of the type) doesn't apply when= the linkage is explicitly specified, right? > > Linkage conflicts with built-in declarations of functions are also a bi= t of > > a problem: >=20 > Yes, as I said in comment #38 and comment #39, giving builtin functions t= he > right linkage is a big missing part of the patch. I've got this part working, and found it much easier to reverse the logic: = all code using build_function_type gets a C function type. It required just a f= ew more changes of build_function_type to build_function_type2 in the C++ frontend. > > implementing this as described makes GCC fail to compile, >=20 > At least in the version of the patch that is attached to the PR, gcc tries > to accept almost anything except in some pedantic mode. The goal is to av= oid > breaking every code on earth, or the patch has no chance of ever being > accepted. I've given it a try on a large number of packages (including Firefox, Chrom= ium, Qt+KDE), and I'm down to five categories of hard errors, four of which IMO should be warnings, but comments on that would be welcome. 1: extern "C" typedef void (*fpt1)() __attribute__((noreturn)); void f1(); fpt1 fp1 =3D f1; // error: invalid conversion from =E2=80=98void (*)()=E2= =80=99 to =E2=80=98fpt1 {aka void (*)()__attribute__((noreturn)) extern "C"}=E2=80=99 [-fpermissive] This should work, with a warning. The logic to allow an implicit conversion= to the corresponding function type with different linkage doesn't work when the attributes differ. 2: extern "C" typedef void (*fpt2)(); template void f2(); fpt2 fp2 =3D f2; // error: no matches converting function =E2=80=98f2= =E2=80=99 to type =E2=80=98fpt2 {aka void (*)() extern "C"}=E2=80=99 This should work, with a warning. This possibly has the same underlying cau= se as what I reported as PR60531, namely that f2 is considered an overloa= ded function even though it isn't. 3: extern "C" void f3(); template struct S3 { }; template struct S3; This should work, with a warning. I was worried this might cause a conflict between a C function template argument and a C++ function template argument with the same name, but that cannot ever happen, the only possible way that they could get the same mangled name is if the code is already invalid for other reasons. 4: extern "C" void f4(); struct S4 { S4(void()); private: S4(const S4 &); }; S4 s4(f4); This should work, with a warning, but only after all standard means of constructing S4 have failed. In particular, if another constructor is added that can accept f4's type (say S4(...), or S4(bool)), the other constructor needs to be picked. 5: extern "C" void f5(void()); void f5(void()); void g5() { long p =3D (long)f5; } This should be considered acceptable breakage. The function f5 in question = is actually atexit, which in current glibc is not an overloaded function, but would become an overloaded function, as specified in the standard. Taking i= ts address without any context doesn't give enough information to determine wh= ich overload's address should be taken (even though they both have the same address). P.S.: the patch here contains a comment questioning the validity of extern = "C" template aliases. I think that a _lot_ more is valid than is currently accepted: 7.5p1: All function types, function names with external linkage, and variable names with external linkage have a language linkage. 14p4: A template name has linkage (3.5). A non-member function template can have internal linkage; any other template name shall have external linkage. [...= ] A template, a template explicit specialization (14.7.3), and a class template partial specialization shall not have C linkage. A static template function has internal linkage, so doesn't have external linkage, so doesn't have language linkage, so never has C linkage, even if = it appears in an extern "C" block. Template classes and template aliases aren't function types, so also never have language linkage, so never have C linkag= e. The restriction on class template partial specializations suggests that this isn't what the standard intends (they never have C linkage, so why specify = that they cannot have C linkage?), but it's useful, and I don't see any other interpretation based on the actual wording, so that is what I've implemente= d. This avoids the need for some of the uses of template aliases in libstdc++.= If desired, the useful templates that were previously rejected could get a ped= warn rather than a hard error. >>From gcc-bugs-return-449432-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 21 19:41:27 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 1270 invoked by alias); 21 Apr 2014 19:41:27 -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 1239 invoked by uid 48); 21 Apr 2014 19:41:24 -0000 From: "jvdelisle at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/59513] [4.7/4.8/4.9] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE Date: Mon, 21 Apr 2014 19:41:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libfortran X-Bugzilla-Version: 4.7.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jvdelisle at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.4 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/msg01452.txt.bz2 Content-length: 181 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 --- Comment #12 from Jerry DeLisle --- Dominique, any progress on this one? Shall I look into it?