Samuel Thibault, on Thu 25 Feb 2016 15:23:13 +0100, wrote:
> > As there are accesses to variables shared between different threads,
> > should these be re-written to use GCC's atomic/sync load/store builtins
> > with appropriate semantics?
>
> The current way seems unsafe at least between update_w
Hello,
Thomas Schwinge, on Tue 29 Mar 2016 23:19:09 +0200, wrote:
> On Wed, 24 Feb 2016 23:46:36 +0100, I wrote:
> > On Sat, 19 Sep 2015 14:00:23 +0200, Samuel Thibault
> > wrote:
> > > On Linux, -p and -pg do not make gcc link against libc_p.a, only
> > > -profile does (as documented in r11246)
Hi!
On Wed, 24 Feb 2016 23:46:36 +0100, I wrote:
> On Sat, 19 Sep 2015 14:00:23 +0200, Samuel Thibault
> wrote:
> > On Linux, -p and -pg do not make gcc link against libc_p.a, only
> > -profile does (as documented in r11246), and thus people expect -p
>
> (Yo, 20 years ago...)
>
> > and -pg to
Samuel Thibault, on Thu 25 Feb 2016 00:18:21 +0100, wrote:
> Thomas Schwinge, on Wed 24 Feb 2016 23:46:36 +0100, wrote:
> > I guess getting -D_REENTRANT for -pthread won't do us any harm?
>
> It won't.
(Actually we've been using this in Debian for a long time).
Samuel
Thomas Schwinge, on Thu 25 Feb 2016 15:05:21 +0100, wrote:
> Should we move the initialization of profil_reply_port elsewhere, or be
> prepared for profil_reply_port to be MACH_PORT_NULL in
> sysdeps/mach/hurd/profil.c:fetch_samples (by returning early?), or not
> call fetch_samples from sysdeps/ma
Hi!
On Wed, 24 Feb 2016 23:46:36 +0100, I wrote:
> On Sat, 19 Sep 2015 14:00:23 +0200, Samuel Thibault
> wrote:
> > On Linux, -p and -pg do not make gcc link against libc_p.a, only
> > -profile does (as documented in r11246), and thus people expect -p
>
> (Yo, 20 years ago...)
Now looking at g
Thomas Schwinge, on Wed 24 Feb 2016 23:46:36 +0100, wrote:
> I guess getting -D_REENTRANT for -pthread won't do us any harm?
It won't.
> > --- gcc/config/i386/gnu.h.orig 2015-09-17 21:41:13.0 +
> > +++ gcc/config/i386/gnu.h 2015-09-17 23:03:57.0 +
> > @@ -27,11 +27,
Hi!
Sorry for the late answer...
On Sat, 19 Sep 2015 14:00:23 +0200, Samuel Thibault
wrote:
> On Linux, -p and -pg do not make gcc link against libc_p.a, only
> -profile does (as documented in r11246), and thus people expect -p
(Yo, 20 years ago...)
> and -pg to work without libc_p.a installe
Ping?
Samuel Thibault, on Sun 11 Oct 2015 20:29:10 +0200, wrote:
> Ping?
>
> (I don't have commit access)
>
> Samuel Thibault, le Sat 19 Sep 2015 14:00:23 +0200, a écrit :
> > On Linux, -p and -pg do not make gcc link against libc_p.a, only
> > -profile does (as documented in r11246), and thus p
Hi Samuel!
On Sat, 19 Sep 2015 14:00:23 +0200, Samuel Thibault
wrote:
> On Linux, -p and -pg do not make gcc link against libc_p.a, only
> -profile does (as documented in r11246), and thus people expect -p
> and -pg to work without libc_p.a installed (it is actually even not
> available any more
Ping?
(I don't have commit access)
Samuel Thibault, le Sat 19 Sep 2015 14:00:23 +0200, a écrit :
> On Linux, -p and -pg do not make gcc link against libc_p.a, only
> -profile does (as documented in r11246), and thus people expect -p
> and -pg to work without libc_p.a installed (it is actually eve
Ping?
Samuel Thibault, le Sat 19 Sep 2015 14:00:23 +0200, a écrit :
> On Linux, -p and -pg do not make gcc link against libc_p.a, only
> -profile does (as documented in r11246), and thus people expect -p
> and -pg to work without libc_p.a installed (it is actually even not
> available any more in
On Linux, -p and -pg do not make gcc link against libc_p.a, only
-profile does (as documented in r11246), and thus people expect -p
and -pg to work without libc_p.a installed (it is actually even not
available any more in Debian). We should thus rather make the Hurd port
do the same to avoid build
13 matches
Mail list logo
