public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Iain Sandoe <iain@sandoe.co.uk>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Nathan Sidwell <nathan@acm.org>, Jason Merrill <jason@redhat.com>
Subject: Re: Function signatures in extern "C".
Date: Sun, 6 Sep 2020 21:23:55 +0100	[thread overview]
Message-ID: <CAH6eHdQGe1mUGac+W4+36fv-uH6ns95Eg_yPzCg3tTNTP5TAkw@mail.gmail.com> (raw)
In-Reply-To: <3EED366A-21C9-47E9-89B0-BBDAF0AE740D@sandoe.co.uk>

On Sun, 6 Sep 2020 at 16:23, Iain Sandoe <iain@sandoe.co.uk> wrote:
>
> Hi
>
> 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.


> 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. It's probably worth adding a comment about that in the test.

Maybe the test should give a compile-time error and XFAIL, but fixing
the declaration doesn't seem right.

  reply	other threads:[~2020-09-06 20:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-06 15:22 Iain Sandoe
2020-09-06 20:23 ` Jonathan Wakely [this message]
2020-09-06 20:43   ` Iain Sandoe
2020-09-06 23:05     ` Nathan Sidwell
2020-09-07  8:16       ` Iain Sandoe
2020-09-07  9:27         ` Jonathan Wakely
2020-09-07  9:34           ` Jakub Jelinek
2020-09-07 10:29             ` Jonathan Wakely
2020-09-10  7:58             ` Florian Weimer
2020-09-07  9:38           ` Iain Sandoe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAH6eHdQGe1mUGac+W4+36fv-uH6ns95Eg_yPzCg3tTNTP5TAkw@mail.gmail.com \
    --to=jwakely.gcc@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=iain@sandoe.co.uk \
    --cc=jason@redhat.com \
    --cc=nathan@acm.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).