Re: Function signatures in extern "C".

[Iain Sandoe <iain@sandoe.co.uk>]

Nathan Sidwell <nathan@acm.org> 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 <gcc@gcc.gnu.org> wrote:
>>> On Sun, 6 Sep 2020 at 16:23, Iain Sandoe <iain@sandoe.co.uk> 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