This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [v3] libstdc++/29095
> Yes, this way thinks are a bit cleaner, but if you look at the audit
> trail, I think people (Mark, Andrew) slightly prefer keeping
> __cxa_cdtor_type with C++ linkage, when compiling in C++ mode, to be
> safe. Or I'm misunderstanding the discussion?
Hmm. I see this in:
config/cpu/generic/cxxabi_tweaks.h
#ifdef __cplusplus
namespace __cxxabiv1
{
#endif
...
// __cxa_vec_ctor has void return type.
typedef void __cxa_vec_ctor_return_type;
#define _GLIBCXX_CXA_VEC_CTOR_RETURN(x) return
// Constructors and destructors do not return a value.
typedef void __cxa_cdtor_return_type;
...
#ifdef __cplusplus
} // namespace __cxxabiv1
#endif
So I see this issue as one of forgetting to specify the language. (see
comments #1 and #3). In this case, I say let's try to be consistent
with the rest of the IA64 spec and specify as "C". I do not see why
this makes a difference for this particular type at all, as it's
specifying a return type or a function argument and this is not mangled
as part of the "C" function names for the signatures in cxxabi.h
anyway. I don't see other uses for this type (vec.cc) mattering either.
Mark, can you explain where/how this matters? Or clarify what you mean
by:
"The language linkage of the type is supposed to matter in some cases
-- but G++ doesn't implement that, so I don't think the difference is
observable in GNU C++."
My preference would be to make the patch as proposed by me and then
wrap the cxxabi_tweaks.h file in extern C as well. Then at least things
are done consistently WRT IA64 spec.
-benjamin