On Thu, 2012-03-08 at 08:13 +0100, Ingo Molnar wrote:
> * Alex Shi wrote:
>
> > On Wed, 2012-03-07 at 14:39 +0100, Ingo Molnar wrote:
> > > * Alex Shi wrote:
> > >
> > > > > I think the check should be (__alignof__(lock) <
> > > > > __alignof__(rwlock_t)), otherwise it will still pass when
>
Snapshot gcc-4.5-20120308 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120308/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I've observed another problem building libstdc++ with current glibc (given
the gets fix that is now in current libstdc++). I see errors of the form:
gthr-default.h:681:48: error: 'NULL' was not declared in this scope
which it appears did not appear before because pthread.h, included by
gthr-po
On Thu, Mar 8, 2012 at 12:38 AM, Jakub Jelinek wrote:
> On Wed, Mar 07, 2012 at 06:24:14PM -0800, Ollie Wild wrote:
>
> The reason why libgcc.a symbols are hidden is to avoid exporting those
> symbols from shared libraries for -static-libgcc etc. links.
> It used to cause big troubles, the symbols
On Thu, 8 Mar 2012, NightStrike wrote:
On Wed, Mar 7, 2012 at 10:12 AM, Marc Glisse wrote:
On Wed, 7 Mar 2012, NightStrike wrote:
Building gmp/mpfr/mpc in tree fails in the configure-stage1-mpc step
with the current version of mpfr version 3.1.0, out since last
October, and mpc, version 0.9,
On Wed, Mar 7, 2012 at 10:12 AM, Marc Glisse wrote:
> On Wed, 7 Mar 2012, NightStrike wrote:
>
>> Building gmp/mpfr/mpc in tree fails in the configure-stage1-mpc step
>> with the current version of mpfr version 3.1.0, out since last
>> October, and mpc, version 0.9, out since Feb of 2011. I'm gue
On 03/08/2012 11:47 AM, Richard Henderson wrote:
On 03/08/12 00:17, Sebastian Huber wrote:
thanks for the hints. Thus if we want to use the C++ atomic operations on
32-bit ARM in RTEMS we have to implement everything in
libgcc/config/arm/linux-atomic.c
and place it in e.g.
libgcc/config/arm
On 03/08/12 00:17, Sebastian Huber wrote:
> thanks for the hints. Thus if we want to use the C++ atomic operations on
> 32-bit ARM in RTEMS we have to implement everything in
>
> libgcc/config/arm/linux-atomic.c
>
> and place it in e.g.
>
> libgcc/config/arm/rtems-atomic.c
Possibly. It reall
On Thu, Mar 8, 2012 at 7:23 AM, H.J. Lu wrote:
>
> If I understand it correctly, the reason Google doesn't want libgcc_s.so
> is Google believes GPLv3 exception only applies to libgcc,a and libgcc_eh,a,
> not libgcc_s.so. If GPLv3 exception also applies to libgcc_s.so, Google
> may consider using
On Thu, Mar 8, 2012 at 12:38 AM, Jakub Jelinek wrote:
> On Wed, Mar 07, 2012 at 06:24:14PM -0800, Ollie Wild wrote:
>> For reasons outside the scope of this discussion, we're experimenting
>> with statically linking libgcc.a and libgcc_eh.a into dynamically
>> linked applications which depend on l
Hello all
I just merged the trunk (future 4.8, svn rev 185094 into the MELT branch.
This is the first merge of trunkk 4.8 into MELT.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bour
On Wed, Mar 07, 2012 at 06:24:14PM -0800, Ollie Wild wrote:
> For reasons outside the scope of this discussion, we're experimenting
> with statically linking libgcc.a and libgcc_eh.a into dynamically
> linked applications which depend on libc but no other dynamic
> libraries. To make this work, li
Hello Andrew and Richard,
On 03/07/2012 08:38 PM, Richard Henderson wrote:
On 03/07/12 10:44, Andrew MacLeod wrote:
> rth, you are familiar with how this part is suppose to hook up properly...
>
> I traced the code in expand_mem_thread_fence, and the sync_synchronize is
being emiited by:
>
>
13 matches
Mail list logo
