Nathan Sidwell <nat...@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 <i...@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
