Thread safe functions from the C standard library

Hi, What functions from the GNU's C standard library ( libc ) are thread safe? Of a particular interest are transcendental functions ( like 'exp', 'sin' etc. ) - are they thread safe? Are there any requirements/guidelines/assurances regarding thread safety of functions from the C library?

Re: TLS on darwin

On 8 Dec 2008, at 21:09, Andrew Pinski wrote: On Mon, Dec 8, 2008 at 1:04 PM, IainS <[EMAIL PROTECTED] acoustics.co.uk> wrote: following on from http://gcc.gnu.org/ml/gcc/2008-05/msg00202.html As I mentioned; it is emulated. So it works, by default, though it is hm. At the moment it does

Re: [ARM] Implement __builtin_bswap32() via ARMv6 "rev" instruction

2008/12/8 Ian Lance Taylor <[EMAIL PROTECTED]>: > "Alexandre Pereira Nunes" <[EMAIL PROTECTED]> writes: > >> I can provide these, tough as for the copyright assignment, the >> document mentions I can declare the changes in public domain, and >> since I already published something (which may or m

Re: gcc -r

Ralf Corsepius <[EMAIL PROTECTED]> writes: > 1) Is "gcc -r" officially supported by gcc? > > It apparently works, but I can't find it documented anywhere in GCC's > documentation. When invoking the linker, a -r option on the command line will be passed to the linker. The same is true of -A, -d,

Re: gcc -r

On Tue, 2008-12-09 at 07:19 -0800, Ian Lance Taylor wrote: > Ralf Corsepius <[EMAIL PROTECTED]> writes: > > > 1) Is "gcc -r" officially supported by gcc? > > > > It apparently works, but I can't find it documented anywhere in GCC's > > documentation. > > When invoking the linker, a -r option on t

Re: Thread safe functions from the C standard library

David Livshin <[EMAIL PROTECTED]> writes: > What functions from the GNU's C standard library ( libc ) are thread > safe? Of a particular interest are transcendental functions ( like > exp', 'sin' etc. ) - are they thread safe? > > Are there any requirements/guidelines/assurances regarding thread >

Re: gcc -r

Ralf Corsepius <[EMAIL PROTECTED]> writes: > So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ? Ah, when you put the question like that, I would recommend "ld -r". This is the one case where you get no advantage from using the gcc driver to invoke the linker, and it can actually mess

inlining a virtual function

hi, The following is a simplification of my problem: struct Base { virtual void func() = 0; }; struct Derived : Base { inline void func() {...} }; Derived& d = ...; d.func(); This last call is not being inlined. Is this normal? (As I said my example is more complex, I didn't check if the abov

Re: Thread safe functions from the C standard library

Ian Lance Taylor wrote: David Livshin <[EMAIL PROTECTED]> writes: What functions from the GNU's C standard library ( libc ) are thread safe? Of a particular interest are transcendental functions ( like exp', 'sin' etc. ) - are they thread safe? Are there any requirements/guidelines/assuranc

Re: inlining a virtual function

Marco Correia <[EMAIL PROTECTED]> writes: > The following is a simplification of my problem: > > struct Base { virtual void func() = 0; }; > > struct Derived : Base { inline void func() {...} }; > > Derived& d = ...; > d.func(); > > This last call is not being inlined. Is this normal? (As I said m

Re: inlining a virtual function

Marco Correia wrote: hi, The following is a simplification of my problem: struct Base { virtual void func() = 0; }; struct Derived : Base { inline void func() {...} }; Derived& d = ...; d.func(); This last call is not being inlined. Is this normal? Yes. The compiler cannot know that d doesn'

Re: gcc -r

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > Ralf Corsepius <[EMAIL PROTECTED]> writes: > >> So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ? > > Ah, when you put the question like that, I would recommend "ld -r". > This is the one case where you get no advantage from using the gcc

Re: gcc -r

On Tue, 2008-12-09 at 08:10 -0800, Adam Nemet wrote: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > Ralf Corsepius <[EMAIL PROTECTED]> writes: > > > >> So what would you recommend: To use "gcc -r" or "gcc -Wl,-r" ? > > > > Ah, when you put the question like that, I would recommend "ld -r". > >

Re: gcc -r

Ralf Corsepius writes: > So, my questions actually were aiming at > > * whether > "gcc ... -nostdlib -r" > and > "gcc ... -nostdlib -Wl,-r" > are equivalent > > * if the fact that "gcc -r" appears to work, can be exploited or whether > this is a "random accident" and/or intentionally undocume

Re: Thread safe functions from the C standard library

David Livshin <[EMAIL PROTECTED]> writes: > I thought that "gcc" mailing list is appropriate as I need this > information in order to implement auto-parallelizer for the > gcc-generated code. How the gcc-supported parallelizer ( > "-ftree-parallelize-loops=n" ) treats the calls to library routines

Re: TLS on darwin

... is the problem one of SPECs ? I don't think so, unless we can key off -pthread or something. .. or does every single TLS case need a darwin-specific addition to reference -lgcc_eh ? We can add that via tls.exp. .. I guess also that target-supports.exp would need some modification to ac

GCC 4.4.0 Status Report (2008-11-27)

Status == The trunk remains Stage 4, so only fixes for regressions (and changes to documentation) are allowed. As stated previously, the GCC 4.4 branch will be created when there are no open P1s and the total number of P1, P2, and P3 regressions is under 100. We're close -- there are 5 P1s,

Re: TLS on darwin

A little additional info: PPC darwin8 (if configured --enable-tls --enable-threads) fails the check_effective_target_{tls, tls_runtime, tls_native} with a compiler ICE viz, for example: tls_native7888.c:3: internal compiler error: in rs6000_legitimize_tls_address, at config/rs6000/rs6000.

Re: GCC 4.4.0 Status Report (2008-11-27)

Hi, Is this one in the list? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440 Can Ada build on any Arm platform? arm-rtems had good test results for 4.3.2 but broke a few months ago. I suspect it doesn't build targeting any Arm. And I doubt this one is on the list but I am convinced somethin

�dv

Szia Pár napja kérdezted hogy nem e tudok egy jó letöltős oldalt. És én most találtam egyet. Tele van jobbnál jobb filmekkel, és olcsó! 1 db sms elküldése után 500 kb/sec-el töltöttem napokig a legújabb premier filmeket és meséket! Küldj most SMS-t,és 5 nap helyet,25-öt a

Re: GCC 4.4.0 Status Report (2008-11-27)

On Tue, Dec 9, 2008 at 9:12 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: > Hi, > > Is this one in the list? > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440 > > Can Ada build on any Arm platform? arm-rtems had > good test results for 4.3.2 but broke a few months ago. > I suspect it doesn't bu

Re: GCC 4.4.0 Status Report (2008-11-27)

Richard Guenther wrote: On Tue, Dec 9, 2008 at 9:12 PM, Joel Sherrill <[EMAIL PROTECTED]> wrote: Hi, Is this one in the list? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440 Can Ada build on any Arm platform? arm-rtems had good test results for 4.3.2 but broke a few months ago. I suspec

Re: GCC 4.4.0 Status Report (2008-11-27)

On 12/9/08, Joel Sherrill <[EMAIL PROTECTED]> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440 > > Can Ada build on any Arm platform? The only existing GNAT Ada compiler I could find for ARM (while thinking about doing it for the new Debian eabi port) is Adacore's Windows->Nucleus OS c

Re: GCC 4.4.0 Status Report (2008-11-27)

Martin Guy wrote: On 12/9/08, Joel Sherrill <[EMAIL PROTECTED]> wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440 Can Ada build on any Arm platform? The only existing GNAT Ada compiler I could find for ARM (while thinking about doing it for the new Debian eabi port) is Adacor

Re: GCC 4.4.0 Status Report (2008-11-27)

Mark Mitchell wrote: Status == The trunk remains Stage 4, so only fixes for regressions (and changes to documentation) are allowed. As stated previously, the GCC 4.4 branch will be created when there are no open P1s and the total number of P1, P2, and P3 regressions is under 100. We're clo

Re: GCC 4.4.0 Status Report (2008-11-27)

On Tue, 9 Dec 2008, Vladimir Makarov wrote: > Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit > before submitting patch removing the old register allocator. So nothing > prevents to remove the old RA. > > I am going to submit the patch removing the old RA for review to

Re: GCC 4.4.0 Status Report (2008-11-27)

Hans-Peter Nilsson wrote: On Tue, 9 Dec 2008, Vladimir Makarov wrote: Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit before submitting patch removing the old register allocator. So nothing prevents to remove the old RA. I am going to submit the patch removing t

Re: GCC 4.4.0 Status Report (2008-11-27)

On Tue, 9 Dec 2008, Vladimir Makarov wrote: > Hans-Peter Nilsson wrote: > > Vladimir, have you had chance to look at supporting > > LOAD_EXTEND_OP (implicit sign-extension) in IRA? > > > > I'm guessing no, but hope it's not forgotten. > It seems I m

Re: GCC 4.4.0 Status Report (2008-11-27)

On Tue, Dec 9, 2008 at 8:39 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote: > The other issue that remains is removing the old register allocator. > Vladimir, it's time to do this. What -- if anything -- is preventing > that? What about sched-ebb? Wasn't that supposed to be removed after the select

Re: GCC 4.4.0 Status Report (2008-11-27)

Hans-Peter Nilsson wrote: On Tue, 9 Dec 2008, Vladimir Makarov wrote: Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit before submitting patch removing the old register allocator. So nothing prevents to remove the old RA. I am going to submit the patch removing t