This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:

#ifdef __cplusplus
namespace __cxxabiv1


  // __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

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 ( mattering either.

Mark, can you explain where/how this matters? Or clarify what you mean

"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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]