This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH] Fix PR target/24071


Eric Botcazou wrote:

The scenario has just been replayed on the 4.2 branch: the fix for PR 29426 totally breaks the C++ compiler on Solaris 2.6 and probably damages it on Solaris 7, 8 and 9 too. So I think it's time to tackle the underlying problem, i.e. that __gthread_active_p () is not accurate on Solaris; Benjamin summarized the problem in the PR.

I'm glad you're going after this. (Parenthetically, I remember reporting a CVS problem because fnmatch on Solaris 2.4 (2.5.1?) existed, but returned -1 and set ENOSYS, which confused autoconf's checks. So, I feel your pain.)


+/* On Solaris 2.6 up to version 9, the libc exposes a POSIX threads interface
+   even if -pthreads (or -threads) is not specified.  It is dummy and most

"It is dummy" isn't grammatical. "The functions are dummies and most return an error value" would be better.


+static inline int
+__gthread_active_p (void)
+{
+  static pthread_mutex_t __gthread_active_mutex = PTHREAD_MUTEX_INITIALIZER;
+  static pthread_once_t __gthread_active_once = PTHREAD_ONCE_INIT;
+
+  if (__gthread_active < 0)
+    {
+      if (__gthrw_(pthread_once))
+	{
+	  /* Ironically enough we cannot let several threads concurrently
+	     run precisely because pthread_once wouldn't behave evenly.  */

I would say:


/* If this really is a threaded program, then we must ensure that __gthread_trigger is completed before we exit this block, so that we are sure that __gthread_active has been set to 1. */

+	  __gthrw_(pthread_mutex_lock) (&__gthread_active_mutex);
+	  __gthrw_(pthread_once) (&__gthread_active_once, __gthread_trigger);
+	  __gthrw_(pthread_mutex_unlock) (&__gthread_active_mutex);
+	}
+      __gthread_active++;
+    }

The increment is tricky, but OK.


The alternative would be, inside the mutex:

  if (__gthread_active < 0) {
    __gthread_active = 0;
    __gthrw_(pthread_once) (...);
  }

and then, instead of "__gthread_active++":

  else
    __gthread_active = 0;

That would make it more obvious that __gthread_active starts out -1, and then becomes 0, and then (sometimes) becomes 1. Your version makes me scratch my head wondering if __gthread_active can ever be > 1. (Answer: yes, if three threads reacth __gthread_active_p at once; __gthread_trigger will be called once, and all the threads will increment __gthread_active_p, which is harmless, but confusing.)

It's up to you which version you go with. Either is fine for mainline and for 4.2.

Thanks,

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


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