From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.wavenetuk.net (smtp.wavenetuk.net [195.26.36.10]) by sourceware.org (Postfix) with ESMTP id 897143851C2A for ; Mon, 7 Sep 2020 08:18:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 897143851C2A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=iain@sandoe.co.uk Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com [81.138.1.83]) by smtp1.wavenetuk.net (Postfix) with ESMTPA id 93FF81201181; Mon, 7 Sep 2020 09:18:00 +0100 (BST) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Function signatures in extern "C". From: Iain Sandoe In-Reply-To: <1a3dcc56-d25e-c914-03fd-cab42199dd91@acm.org> Date: Mon, 7 Sep 2020 09:16:53 +0100 Cc: Jonathan Wakely , "gcc@gcc.gnu.org" , Jason Merrill Content-Transfer-Encoding: 8bit Message-Id: <27DB0C17-1CA4-4D4D-96AC-92AC8DA84DA4@sandoe.co.uk> References: <3EED366A-21C9-47E9-89B0-BBDAF0AE740D@sandoe.co.uk> <812FAC2E-43A1-4FD9-B734-EDD491723677@sandoe.co.uk> <1a3dcc56-d25e-c914-03fd-cab42199dd91@acm.org> To: Nathan Sidwell X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00, KAM_COUK, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KHOP_HELO_FCRDNS, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 08:18:03 -0000 Nathan Sidwell wrote: > GCC has an extension on machaines with cxx_implicit_extern_c (what used > to be !NO_IMPLICIT_EXTERN_C). > > On such targets we'll treat 'extern "C" void Foo ()' as-if the argument > list is variadic. (or something approximating that) > > perhaps that is confusing things? maybe that’s the underlying reason for failing to diagnose the wrong code. > On 9/6/20 4:43 PM, Iain Sandoe wrote: >> Jonathan Wakely via Gcc wrote: >>> On Sun, 6 Sep 2020 at 16:23, Iain Sandoe wrote: >>>> g++.dg/abi/guard3.C >>>> >>>> has: >>>> >>>> extern "C" int __cxa_guard_acquire(); >>>> >>>> Which might not be a suitable declaration, depending on how the ‘extern >>>> “C”’ is supposed to affect the function signature generated. >>>> >>>> IF, the extern C should make this parse as a “K&R” style function - then >>>> the TYPE_ARG_TYPES should be NULL (and the testcase is OK). >>>> >>>> However, we are parsing the decl as int __cxa_guard_acquire(void) >>>> (i.e. C++ >>>> rules on the empty parens), which makes the testcase not OK. >>> >>> That is the correct parse. Using extern "C" doesn't mean the code is >>> C, it only affects mangling. It still has to follow C++ rules. >>> >>> In practice you can still link to the definition, because its name is >>> just "__cxa_guard_acquire" irrespective of what parameter list is >>> present in the declaration. >> Linking isn’t the problem in this case. >> The problem is that we arrive at “expand_call” with a function decl that >> says f(void) .. and a call parmeter list containing a pointer type. >> We happily pass the pointer in the place of the ‘void’ - because the code >> only counts the number of entries and there’s one - so it happens to work. >> .. that’s not true in the general case and for all calling conventions. that is, “expand_call” does not expect to have to handle the case that the compiler is telling it conflicting information. AFAICT, that’s reasonable, I was unable to find a way to write normal user code [at least, C-family] that the compiler would accept producing this set of conditions (it seems that cases in this category have to be generated by the compiler internally). >>> But PR 45603 is ice-on-invalid triggered by the incorrect declaration >>> of __cxa_guard_acquire. So the incorrect declaration is what >>> originally reproduced the bug, and "fixing" it would make the test >>> useless. >> Ah OK. So, IIUC we’ve replaced an ICE-on-invalid with an “accepts invalid”, it seems? >>> It's probably worth adding a comment about that in the test. >> Yes - that would help (will add it to my TODO). Perhaps the PR should be reopened with “accepts invalid”? thanks Iain