gcc-4.7-20111022 fails to build on PA-RISC

Jonathan Wakely jwakely.gcc@gmail.com
Sun Oct 30 19:10:00 GMT 2011


On 30 October 2011 18:28, Daniel Krügler wrote:
>> My initial idea would have been to change the member initializer to
>>
>> struct mutex {
>>  pthread_mutex_t m{ };
>>  mutex() = default;
>> };
>>
>> which should no longer use copy-initialization but direct-initialization.
>> But the compiler produces the same error. I believe, this is a compiler
>> defect in regard to handling brace-or-equal-initializers, though.

I did try that, but didn't get as far as realising that might be a bug
in the front end.

Unfortunately in the real case the initializer is an opaque macro,
PTHREAD_MUTEX_INITIALIZER, which could be something unsuitable for
that syntax, such as an integer constant.

The only reliable way to use that macro is:

pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;

which requires copy-init.

We could use a configure test to determine if it's safe to do:

pthread_mutex_t m PTHREAD_MUTEX_INITIALIZER;

but I'm not sure that's preferable to just using the init functions
instead of the macros for affected platforms.

> I would go even further and would argue that the current code should
> also be well-formed, because the effect of writing
>
> pthread_mutex_t m = { };
>
> is to initialize the subobject __spinlock "from an empty initializer list",
> which also is no copy-initialization.

The real code the example was reduced from (the Linuxthreads
implementation of pthread.h) doesn't have an empty initialization
list, so although it would be good to fix any front end bugs, it
doesn't necessarily help solve the std::mutex problem.



More information about the Libstdc++ mailing list