Re: pthread related breakage (mainline)

Re: pthread related breakage (mainline)

[Giovanni Bajo]

Giovanni Bajo <giovannibajo@libero.it> wrote:

>> 2003-10-09  Nathanael Nerode  <neroden@gcc.gnu.org>
>>
>>     * config.gcc: Remove redundant thread_file setting clauses for
>>     various *-*-linux* targets.
>
> I reverted this patch and I'm bootstrapping now. For reference, it's:
> http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00715.html
> cvs diff -u -r 1.394 -r 1.395 config.gcc | patch -R
>
> Let's see if it helps.

Alas it doesn't. I also reverted this:

2003-10-08  Nathanael Nerode  <neroden@gcc.gnu.org>

    * config.gcc: Don't accept --enable-threads=pthreads.  Clean
    up related case statements.
    * configure.in: Don't accept --enable-threads=pthreads,
    decosf1, mach, or os2 (none of which work anyway).  Alphabetize
    supported thread files in case clause.
    * configure: Regenerate.

and bootstrap is still broken. I'll try reverting also the third Paolo
suggested now.

Giovanni Bajo

Re: pthread related breakage (mainline)

[Paolo Carlini]

Giovanni Bajo wrote:

>and bootstrap is still broken. I'll try reverting also the third Paolo
>suggested now.
>  
>
Hi Giovanni. Consider, however, that I'm not a configury expert and 
didn't actually analyze the content of those patches. Perhaps, it's 
something more recent, perhaps it's a complex interaction between old 
and recent commits. I can only tell one thing for sure: nothing threads 
related changed in the libstdc++-v3 directory and if  I revert the 
compiler to three days ago:

    cvs -z9 update -D "3 days ago"

and then the library:

    cvs -z9 update -A

everything is OK, just done on x86_64.

Paolo.

Re: pthread related breakage (mainline)

[Paolo Carlini]

Paolo Carlini wrote:

>    cvs -z9 update -D "3 days ago"

Also OK for -D "2 days ago"...

Now checking -D "1 day ago".

Paolo.

Re: pthread related breakage (mainline)

[Paolo Carlini]

Paolo Carlini wrote:

> Now checking -D "1 day ago".

BROKEN!

Now checking -D "36 hours ago".

Paolo.

Re: pthread related breakage (mainline)

[Janis Johnson]

On Mon, Dec 08, 2003 at 07:49:00PM +0100, Paolo Carlini wrote:
> Paolo Carlini wrote:
> 
> > Now checking -D "1 day ago".
> 
> BROKEN!
> 
> Now checking -D "36 hours ago".

Sounds like you need automated regression hunting tools.

Janis

Culprits... (Re: pthread related breakage (mainline))

[Paolo Carlini]

Janis Johnson wrote:

> Sounds like you need automated regression hunting tools.

Yes ;) Could you possibly help?

But we are already quite close: the breakage happened between 36 and
24 hours ago, and the candidates are the changes to gcc/aclocal.m4,
gcc/configure and gcc/configure.in that happened in that time span.

Just a couple of commits: can you help pinpointing the exact one?

2003-12-07 Nathanael Nerode <neroden@gcc.gnu.org>

    * configure.in, aclocal.m4: Revert to pre-2.5x conversion status.
    * configure: Regenerate with autoconf 2.13.

    * configure.in: Replace AC_INIT, AC_OUTPUT, AC_CANONICAL_SYSTEM
    with modern equivalents.
    * configure: Regenerate.

    * configure.in: Replace gcc_AC_CHECK_TYPE with AC_CHECK_TYPE.
    * aclocal.m4 (gcc_AC_CHECK_TYPE): Remove.
    * configure: Regenerate.

    * configure: Regenerate with (preferred) autoconf 2.57.
    * doc/install.texi: Note that 'gcc' is now a 2.57 directory.

2003-12-07 Nathanael Nerode <neroden@gcc.gnu.org>

    * configure.in: Make minimum necessary changes for autoconf 2.5x.
    * aclocal.m4: Make minimum necessary changes for autoconf 2.5x.
    * configure: Regenerate with autoconf 2.58.

Thanks!
Paolo.

Re: Culprits... (Re: pthread related breakage (mainline))

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

Paolo Carlini <pcarlini@unitus.it> writes:

> Janis Johnson wrote:
>
>> Sounds like you need automated regression hunting tools.
>
> Yes ;) Could you possibly help?
>
> But we are already quite close: the breakage happened between 36 and
> 24 hours ago, and the candidates are the changes to gcc/aclocal.m4,
> gcc/configure and gcc/configure.in that happened in that time span.
>
> Just a couple of commits: can you help pinpointing the exact one?

I gues it's this change but I'm double checking this right now...

--- ChangeLog   7 Dec 2003 14:13:53 -0000       2.1950
+++ ChangeLog   7 Dec 2003 16:12:26 -0000       2.1951
@@ -1,5 +1,8 @@
 2003-12-07  Nathanael Nerode  <neroden@gcc.gnu.org>
 
+       * configure.in, aclocal.m4: Revert to pre-2.5x conversion status.
+       * configure: Regenerate with autoconf 2.13.
+
        * configure.in: Replace AC_INIT, AC_OUTPUT, AC_CANONICAL_SYSTEM
        with modern equivalents.
        * configure: Regenerate.

So, somehow the reversion or the regeneration was not ok.

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: Culprits... (Re: pthread related breakage (mainline))

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

Andreas Jaeger <aj@suse.de> writes:

> I gues it's this change but I'm double checking this right now...
>
> --- ChangeLog   7 Dec 2003 14:13:53 -0000       2.1950
> +++ ChangeLog   7 Dec 2003 16:12:26 -0000       2.1951
> @@ -1,5 +1,8 @@
>  2003-12-07  Nathanael Nerode  <neroden@gcc.gnu.org>
>  
> +       * configure.in, aclocal.m4: Revert to pre-2.5x conversion status.
> +       * configure: Regenerate with autoconf 2.13.
> +
>         * configure.in: Replace AC_INIT, AC_OUTPUT, AC_CANONICAL_SYSTEM
>         with modern equivalents.
>         * configure: Regenerate.
>
> So, somehow the reversion or the regeneration was not ok.

Sorry Nerode for blaming your change - it was Giovanni's patch that
happened also in that range and I was too focused on this :-(

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

pthread related breakage (mainline)

[Gerald Pfeifer]

On i686-pc-linux-gnu (SUSE Linux 9.0) I'm getting the following bootstrap
failure for --enable-languages=c,c++,objc,java --disable-checking:

  ranlib libv3test.a
  `/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/scripts/testsuite_flags --build-cxx` -DHAVE_CONFIG_H -I. -I/cvs/gcc/libstdc++-v3/testsuite -I..  -I/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/include -I/cvs/gcc/libstdc++-v3/libsupc++ -O2 -g -O2  -g -O2 -D_GNU_SOURCE -c -o abi_check.o /cvs/gcc/libstdc++-v3/testsuite/abi_check.cc
  LD_RUN_PATH=${LD_RUN_PATH:+$LD_RUN_PATH:}/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src/.libs /bin/sh ../libtool --tag=CXX --mode=link `/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/scripts/testsuite_flags --build-cxx`  -g -O2 -D_GNU_SOURCE  -o abi_check  abi_check.o  -lm 
  mkdir .libs
  /tmp/OBJ-1208-0937/gcc/g++ -shared-libgcc -B/tmp/OBJ-1208-0937/gcc/ -nostdinc++ -B/suse/gp/gcc/i686-pc-linux-gnu/bin/ -B/suse/gp/gcc/i686-pc-linux-gnu/lib/ -isystem /suse/gp/gcc/i686-pc-linux-gnu/include -isystem /suse/gp/gcc/i686-pc-linux-gnu/sys-include -include bits/stdc++.h -g -O2 -D_GNU_SOURCE -o abi_check abi_check.o  -L/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src -L/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src/.libs -lm
  /tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `pthread_create'
  /tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `pthread_getspecific'
  /tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `pthread_once'
  /tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `pthread_key_create'
  /tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so: undefined reference to `pthread_setspecific'
  collect2: ld returned 1 exit status
  gmake[4]: *** [abi_check] Error 1
  gmake[4]: Leaving directory `/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/testsuite'
  gmake[3]: *** [all-recursive] Error 1
  gmake[3]: Leaving directory `/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3'
  gmake[2]: *** [all] Error 2
  gmake[2]: Leaving directory `/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3'
  gmake[1]: *** [all-target-libstdc++-v3] Error 2
  gmake[1]: Leaving directory `/tmp/OBJ-1208-0937'
  gmake: *** [bootstrap-lean] Error 2

On i386-unknown-freebsd4.8 build suceeds, similar problems arise during use:

  % cat x.cc
  #include <vector>

  using namespace std;

  main() {
    vector<int> i;
    }
  % gccvs x.cc
 /sw/freebsd4/gcc-current/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4/../../../libstdc++.so: undefined reference to `pthread_create'
 /sw/freebsd4/gcc-current/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4/../../../libstdc++.so: undefined reference to `pthread_getspecific'
 /sw/freebsd4/gcc-current/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4/../../../libstdc++.so: undefined reference to `pthread_once'
 /sw/freebsd4/gcc-current/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4/../../../libstdc++.so: undefined reference to `pthread_key_create'
 /sw/freebsd4/gcc-current/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4/../../../libstdc++.so: undefined reference to `pthread_mutex_unlock'
 /sw/freebsd4/gcc-current/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4/../../../libstdc++.so: undefined reference to `pthread_mutex_lock'
 /sw/freebsd4/gcc-current/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4/../../../libstdc++.so: undefined reference to `pthread_setspecific'
 collect2: ld returned 1 exit status

Gerald

Re: pthread related breakage (mainline)

[Eric Christopher]

>   /tmp/OBJ-1208-0937/gcc/g++ -shared-libgcc -B/tmp/OBJ-1208-0937/gcc/ -nostdinc++ -B/suse/gp/gcc/i686-pc-linux-gnu/bin/ -B/suse/gp/gcc/i686-pc-linux-gnu/lib/ -isystem /suse/gp/gcc/i686-pc-linux-gnu/include -isystem /suse/gp/gcc/i686-pc-linux-gnu/sys-include -include bits/stdc++.h -g -O2 -D_GNU_SOURCE -o abi_check abi_check.o  -L/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src -L/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src/.libs -lm

I saw this too a while back, but an update and a clean build fixed it...

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: pthread related breakage (mainline)

[Gerald Pfeifer]

On Mon, 8 Dec 2003, Eric Christopher wrote:
>>   /tmp/OBJ-1208-0937/gcc/g++ -shared-libgcc -B/tmp/OBJ-1208-0937/gcc/ -nostdinc++ -B/suse/gp/gcc/i686-pc-linux-gnu/bin/ -B/suse/gp/gcc/i686-pc-linux-gnu/lib/ -isystem /suse/gp/gcc/i686-pc-linux-gnu/include -isystem /suse/gp/gcc/i686-pc-linux-gnu/sys-include -include bits/stdc++.h -g -O2 -D_GNU_SOURCE -o abi_check abi_check.o  -L/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src -L/tmp/OBJ-1208-0937/i686-pc-linux-gnu/libstdc++-v3/src/.libs -lm
> I saw this too a while back, but an update and a clean build fixed it...

Not in this case:

  % cvs -q up -PAd -I\! -ICVS
  %

Giovanni noticed that there are in fact several reports of this in 
Bugzilla as well

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13330

(and then there's also the problem on FreeBSD, that only appears when
using the compiler).

Gerald

Re: pthread related breakage (mainline)

[Paolo Carlini]

Gerald Pfeifer wrote:

>Giovanni noticed that there are in fact several reports of this in 
>Bugzilla as well
>
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13330
>
>(and then there's also the problem on FreeBSD, that only appears when
>using the compiler).
>  
>
Hi everyone.

Is anyone able to estimate *when* the breakage started? For sure, there 
are *no* recent changes involving threads in the libstdc++-v3 directory 
proper!

Perhaps (just a guess!) something having to do with Nathanael Nerode 
toplevel build changes? There were many specifically targeting threads 
back in October, see gcc/Changelog

Paolo.

Re: pthread related breakage (mainline)

[Gerald Pfeifer]

On Mon, 8 Dec 2003, Paolo Carlini wrote:
>>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13330
>> (and then there's also the problem on FreeBSD, that only appears when
>> using the compiler).
> Is anyone able to estimate *when* the breakage started?

In the last 72 hours, I believe...

> Perhaps (just a guess!) something having to do with Nathanael Nerode
> toplevel build changes? There were many specifically targeting threads
> back in October, see gcc/Changelog

...definitely not that long ago (and surely less than one week).

Gerald

Re: pthread related breakage (mainline)

[Paolo Carlini]

Gerald Pfeifer wrote:

>On Mon, 8 Dec 2003, Paolo Carlini wrote:
>  
>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13330
>>>(and then there's also the problem on FreeBSD, that only appears when
>>>using the compiler).
>>>      
>>>
>>Is anyone able to estimate *when* the breakage started?
>>    
>>
>In the last 72 hours, I believe...
>  
>
I see.

Still, absolutely no changes in the libstdc++-v3 directory and many 
toplevel build changes, that I think should be carefully scrutinized: 
the "configury people" are doing a lot of work to move everywhere to 
autoconf 2.57.

Paolo.

Re: pthread related breakage (mainline)

[Giovanni Bajo]

Paolo Carlini <pcarlini@suse.de> wrote:

>>> Is anyone able to estimate *when* the breakage started?
>>>
>> In the last 72 hours, I believe...
>>
> I see.
>
> Still, absolutely no changes in the libstdc++-v3 directory and many
> toplevel build changes, that I think should be carefully scrutinized:
> the "configury people" are doing a lot of work to move everywhere to
> autoconf 2.57.

No, I don't think it's recent.
There is a report (linked within PR 13330) which is dated 2003-11-14. A linux
box I have access to started this failure about 2 weeks ago. A full clean +
update + rebuild fixed it for a few days, and now it's been back for at least
another week. Three days ago I installed a clean Linux RH9, and I was never
able to bootstrap GCC there because of this problem. This is when I submitted
the report.

Giovanni Bajo

Re: pthread related breakage (mainline)

[Paolo Carlini]

Giovanni Bajo wrote:

>No, I don't think it's recent.
>
In that case, let's double check these commits:

2003-10-09  Nathanael Nerode  <neroden@gcc.gnu.org>

    * config.gcc: Remove redundant thread_file setting clauses for
    various *-*-linux* targets.

2003-10-08  Nathanael Nerode  <neroden@gcc.gnu.org>

    * config.gcc: Don't accept --enable-threads=pthreads.  Clean
    up related case statements.
    * configure.in: Don't accept --enable-threads=pthreads,
    decosf1, mach, or os2 (none of which work anyway).  Alphabetize
    supported thread files in case clause.
    * configure: Regenerate.

2003-10-07  Nathanael Nerode  <neroden@gcc.gnu.org>

    * Makefile.in: Add more comments separating large conceptually
    separate sections.

    * configure.in: Clean up thread file logic.
    * configure: Regenerate.

Paolo.

Re: pthread related breakage (mainline)

[Giovanni Bajo]

Paolo Carlini <pcarlini@unitus.it> wrote:

> In that case, let's double check these commits:
> 
> 2003-10-09  Nathanael Nerode  <neroden@gcc.gnu.org>
> 
>     * config.gcc: Remove redundant thread_file setting clauses for
>     various *-*-linux* targets.

I reverted this patch and I'm bootstrapping now. For reference, it's:
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg00715.html
cvs diff -u -r 1.394 -r 1.395 config.gcc | patch -R

Let's see if it helps.

Giovanni Bajo

Re: pthread related breakage (mainline)

[Jason Merrill]

On Mon, 8 Dec 2003 14:02:25 +0100, "Giovanni Bajo" <giovannibajo@libero.it> wrote:

> No, I don't think it's recent.

I think it is--I think your overload patch broke it.  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.

Jason

Re: pthread related breakage (mainline)

[Jason Merrill]

On Mon, 08 Dec 2003 18:03:57 -0500, Jason Merrill <jason@redhat.com> wrote:

> On Mon, 8 Dec 2003 14:02:25 +0100, "Giovanni Bajo" <giovannibajo@libero.it> wrote:
>
>> No, I don't think it's recent.
>
> I think it is--I think your overload patch broke it.

Indeed, reverting your patch fixes the bootstrap.  I'll go ahead and check
that in.  Perhaps we should try a different approach to fixing the using
testcase.

Jason

Re: pthread related breakage (mainline)

[Giovanni Bajo]

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

Re: pthread related breakage (mainline)

[Jason Merrill]

On Tue, 9 Dec 2003 02:48:25 +0100, "Giovanni Bajo" <giovannibajo@libero.it> wrote:

>> 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?

True.  Which leads to the question of what we want #pragma weak to mean for
really overloaded functions.  I suppose the alternatives are either to make
all currently declared overloads weak or give an error.  I lean towards the
latter.  Which suggests that handle_pragma_weak could just give an error if
the lookup finds something that is not a decl.

> Would you please give me a hint on where to put my hands to fix this? It
> seems everything is handled in C frontend.

Let's go back to your original patch,

  http://gcc.gnu.org/ml/gcc-patches/2003-10/msg02572.html

Jason

Re: pthread related breakage (mainline)

[Giovanni Bajo]

Jason Merrill <jason@redhat.com> wrote:

> Let's go back to your original patch,
>   http://gcc.gnu.org/ml/gcc-patches/2003-10/msg02572.html

Sure. Retested with current HEAD on i686-pc-linux-gnu (rebuild v3 & libjava
nat, check-c++), no new regressions, and of course it fixes using9.C.
OK for mainline?

Giovanni Bajo



2003-12-09  Giovanni Bajo  <giovannibajo@gcc.gnu.org>

        PR c++/2294
        * name-lookup.c (push_overloaded_decl): always construct an OVERLOAD
        if the declaration comes from an using declaration.


Index: name-lookup.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/name-lookup.c,v
retrieving revision 1.25
diff -c -3 -p -r1.25 name-lookup.c
*** name-lookup.c       8 Dec 2003 23:15:30 -0000       1.25
--- name-lookup.c       9 Dec 2003 17:56:18 -0000
*************** push_overloaded_decl (tree decl, int fla
*** 2006,2012 ****
        }
      }

!   if (old || TREE_CODE (decl) == TEMPLATE_DECL)
      {
        if (old && TREE_CODE (old) != OVERLOAD)
        new_binding = ovl_cons (decl, ovl_cons (old, NULL_TREE));
--- 2006,2016 ----
        }
      }

!   if (old || TREE_CODE (decl) == TEMPLATE_DECL
!       /* If it's a using declaration, we always need to build an OVERLOAD,
!        because it's the only way to remember that the declaration comes
!        from 'using', and have the lookup behave correctly.  */
!       || (flags & PUSH_USING))
      {
        if (old && TREE_CODE (old) != OVERLOAD)
        new_binding = ovl_cons (decl, ovl_cons (old, NULL_TREE));

Re: pthread related breakage (mainline)

[Jason Merrill]

OK.

Jason

Re: pthread related breakage (mainline)

[Paolo Carlini]

Jason Merrill wrote:

>I think it is--I think your overload patch broke it.  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.
>  
>
Ah!

*Many* thanks Jason and sorry Nathanael for having suspected your 
changes... I couldn't imagine an interaction between threads and the C++ 
front end, poor me...

Paolo.

Re: pthread related breakage (mainline)

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@suse.de> writes:

| Jason Merrill wrote:
| 
| >I think it is--I think your overload patch broke it.  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.
| >
| Ah!
| 
| *Many* thanks Jason and sorry Nathanael for having suspected your
| changes... I couldn't imagine an interaction between threads and the
| C++ front end, poor me...

Did you say good abstractions? ;-) :-)

-- Gaby