Re: pthread related breakage (mainline)

["Giovanni Bajo" <giovannibajo@libero.it>]

Jason Merrill <jason@redhat.com> wrote:

> Indeed, reverting your patch fixes the bootstrap.  I'll go ahead and check
> that in.  .


I tested that patch so many times I can't believe it still caused breakage.
See: http://gcc.gnu.org/ml/gcc-patches/2003-11/msg01725.html. I wonder how my
linux bootstrap succeeded. Probably I had pthreads disabled for some reason.

My sincere apologies to everybody.


> Perhaps we should try a different approach to fixing the using testcase

To me, it seems that we're only dealing with fallouts, where there was code not
prepared to handle overloaded function in the first place (and not even testing
properly for the condition), and thus probably already broken per-se. The first
breakage with libjava was totally my fault, since I didn't know exactly the
testing procedures. This was a little more delicate since it appears only on
some platforms.

Anyway, if you have a different idea, just let me know, I can try to work out
something. Building always overload sets looked to me like the clean,
orthogonal way to solve the issue.


> The problem is that
> the #pragma weaks for the pthread functions are now being ignored, because
> handle_pragma_weak expects an affected function to be the
> identifier_global_value of its name, and now it isn't.

... which, if I understand correctly, means that #pragma weaks are already
broken in the first place for really overloaded functions, right? Would you
please give me a hint on where to put my hands to fix this? It seems everything
is handled in C frontend.

Giovanni Bajo