Re: Thread-safe profiling

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> On Mar 14, 2007, at 2:30 PM, Jan Hubicka wrote:
> 
> >>Hi,
> >>
> >>On the course of implementing this I hit some bugs in the  
> >>expansion code
> >>of these builtins and the i386 backend, which are also fixed by this
> >>patch.
> >
> >This would be probably worth backporting separately to release
> >branch(es).
> >
> 
> I agree. I'd like to see it at least to 4.2, probably 4.1 for the  
> various linux distros. :)

Mark, this is technically not a regression, but still wrong code bug.
Would it be OK for 4.1/4.2? (I would say that the fix is safe and it
affects only the originally misoptimized builtin)
> 
> >
> >The patch seems OK overall, but I don't see any handling of targets  
> >that
> >don't support synchronization primitives.  I think at least
> >-fthread-safe-profiling option should give a sorry here and we  
> >should be
> >able to build libgcov so probably we need to ifdef the thread safe
> >variants out somehow if building on such targets leads to
> >sorry/ICE/whatever evil it should lead to.
> >
> 
> Probably.
> 
> >Also I think the call profiling won't work, since it uses a global
> >variable to figure out from where the function was called.  I think we
> >probably need a thread local storage here, that should not be that bad
> >(it is one variable per compilation unit).
> 
> With the emutls stuff it should be able to work even on targets without
> TLS at least.

As pointed out by Richard on IRC, the TLS bits are already in the
patch, so this seems to be OK. My apologizes for false alarm :)

Honza
> 
> -eric