https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65500
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to dave.anglin from comment #1) > At one time, GCC was permissive about system header issues, particularly > when they aren't > really a problem. Is this still the case? It is, yes, but this specific diagnostic is an error not just a warning and it doesn't get disabled in system headers. > It looks like an include hack would fix but there's probably more issues > like this. I think this isn't a widespread problem. We only use these PTHREAD_XXX_INITIALIZER macros in a handful of places, and the other ones have been there for some time without problems. The choices seem to be: 1) Add an autoconf check to see if we can use the PTHREAD_RWLOCK_INITIALIZER macro in this way, so that it falls back to the constructor+destructor if the INITIALIZER macro can't be used. 2) Change the front-end to suppress narrowing errors in system headers. 3) Use fixincludes to change either the definition of __LWP_RWLOCK_VALID to (short)0x8c91 or change the definition of PTHREAD_RWLOCK_INITIALIZER to use (short)__LWP_RWLOCK_VALID I don't like (1) because it would be a bit fragile and could introduce silent ABI issues. If a later release of HPUX changes the INITIALIZER macro to avoid the narrowing conversion, or if a later release of G++ does (2), then the result of the autoconf check would change and would silently change whether a std::shared_timed_mutex uses a constructor/destructor or not. Different translation units built by different versions of GCC would disagree on how to construct the objects. Neither (1) nor (2) helps user code that wants to do: pthread_rwlock_t lock = PTHREAD_RWLOCK_INITIALIZER; which presumably fails with the same error when using g++ -std=c++11. So I think a fixincludes to cast the constant to (short) is the best option. If __LWP_RWLOCK_T is only used in the definition of PTHREAD_RWLOCK_INITIALIZER then changing its definition is probably the simplest: #define __LWP_RWLOCK_VALID (short)0x8c91 I don't have any HPUX machines to try that with, would you be able to?
