From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) by sourceware.org (Postfix) with ESMTPS id B880D3851C09 for ; Sun, 6 Sep 2020 23:05:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B880D3851C09 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=acm.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nathanmsidwell@gmail.com Received: by mail-qv1-xf30.google.com with SMTP id db4so5717048qvb.4 for ; Sun, 06 Sep 2020 16:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WLGJnUgrsoxB+29XwyO1gCgrStTjA1QuuqypINq31EE=; b=ozabeix/tJI6N1xuWb/wLAhbEzVBaZUSbOkPEVttcKz/SpgXIePL94c+jebwZc4HiM hA4wX8urwNab/3EvyGij7q9RyqZkGcnSYqLgiJ/7KrUJSlNsv5Ev40NcUpTkPG2L61Dw WJsN+8OQv2wq1p644OTqzYU1PFip6uKVef9Q/NbeALgpZHf2DqWGeodEh/Yhd2bbO79C wgFAPJ2/RXy2FoQo7IFk02qoVBqxs4xazpUAydQHLXo5Mf3sjK0UbxSnPRnAVd1rlF2H wK+mpEWpBgrWNxLkHyQ27AXinnj0qr+VoELmA8lGFFkv2Pa7m2O29H7Kwq5k9YCuMHYU HnjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WLGJnUgrsoxB+29XwyO1gCgrStTjA1QuuqypINq31EE=; b=MUlVlmyGurcQoKv74SF3zBIPr2hp/Lkqf3K2LR+Rgr9Q4rOPER8bevFf5czPeqU7oa PNS1c791t42eqnIk4Ju+AK9e7OksPL1yp7DbkayJvzUHMWScL5CCrydoyHAf4OmEtqOm aum4ggompcfJuaYTUVC86Ql844hWyGugLVXHlgccx5pNkJCOJiR2gO9XOaVbGDaYBUl9 ZFrTHk0FOtpj8aUGJ1B63T5PQ2uWf/Lm696sOAS0KgqVlIC8e9somZmKgE6rFJPh/pv7 sAWyN0wRekgoeMszvcn9+9RBT0MeNzzWm/TIxVotYEoqL+R0rT0KWo5aPpaxmohIIxuc yzCQ== X-Gm-Message-State: AOAM530EpGThCd+G7b4HyRm9yppkyYQXRYkT6dfvsz9aVxZmDjhdfrXX GDncJmB4M8asdqoqrqyIY08= X-Google-Smtp-Source: ABdhPJxrqnJy+BcieoLZbrJgwVFdLRt50yRrMpjw9E+HaQyPZAioogbh7QDX5iUB+A0I1eoQpMo75A== X-Received: by 2002:ad4:42b3:: with SMTP id e19mr15751217qvr.6.1599433515548; Sun, 06 Sep 2020 16:05:15 -0700 (PDT) Received: from ?IPv6:2601:181:c400:1050::5? ([2601:181:c400:1050::5]) by smtp.googlemail.com with ESMTPSA id p20sm2142638qtk.21.2020.09.06.16.05.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Sep 2020 16:05:14 -0700 (PDT) Sender: Nathan Sidwell Subject: Re: Function signatures in extern "C". To: Iain Sandoe , Jonathan Wakely Cc: "gcc@gcc.gnu.org" , Jason Merrill References: <3EED366A-21C9-47E9-89B0-BBDAF0AE740D@sandoe.co.uk> <812FAC2E-43A1-4FD9-B734-EDD491723677@sandoe.co.uk> From: Nathan Sidwell Message-ID: <1a3dcc56-d25e-c914-03fd-cab42199dd91@acm.org> Date: Sun, 6 Sep 2020 19:05:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <812FAC2E-43A1-4FD9-B734-EDD491723677@sandoe.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Sun, 06 Sep 2020 23:05:18 -0000 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? nathan 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. > > (this is what I mean by it happens to work by luck below). > >>> This means that the declaration is now misleading (and it’s just luck that >>> expand_call happens to count the length of the TYPE_ARG_TYPES  list without >>> looking to see what the types are) - in this case it happens to work out >>> from this luck - since there’s only one arg so the length of the void args >>> list agrees with what we want. >>> >>> —— >>> >>> So .. the question is “which is wrong, the test-case or the assignment of >>> the TYPE_ARG_TYPES”? >>> >>> [we can’t easily diagnose this at this point, but I do have a patch to >>> diagnose the case where we pass a void-list to expand_call and then try to >>> expand a call to the callee with an inappropriate set of parms] >>> >>> (it’s trivial to fix the test-case  as extern "C" int >>> __cxa_guard_acquire(__UINT64_TYPE__ *);, I guess) >> >> 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. > >> It's probably worth adding a comment about that in the test. > > Yes - that would help (will add it to my TODO). >> >> Maybe the test should give a compile-time error and XFAIL, but fixing >> the declaration doesn't seem right. > > I guess (because the code is invalid) there’s not much motivation to make it > more robust - e.g. diagnose the mismatch in the call(s) synthesized to > __cxa_guard_acquire. > > It seems we only try to build these function decl(s) once - lazily - so that a > wrong one will persist for the whole TU (and we don’t seem to check that > the decl matches the itanium ABI - perhaps that’s intentional tho). > > cheers > Iain > > -- Nathan Sidwell