Re: Prototype libatomic

Richard Henderson wrote: > So, I've got something put together. I think it should be fairly scalable. [...] > Comments welcome. Andrew, didn't you say you had some code as well, but > didn't want to argue with autofoo? I think Andrew's version is attached to http://gcc.gnu.org/wiki/Atomic/GCCM

Re: [4.7 regression?] HImode 'smax' RTL generation

On 13 March 2012 22:36, Frédéric RISS wrote: > In 4.7, the COND_EXPR has become a GIMPLE_TERNARY_RHS rhs_class, meaning > that it won't use the expand_assigment path in expand_gimple_stmt_1, but > will use straight expression expansion which will generate control flow > RTL for the COND_EXPR. > >

Re: [4.7 regression?] HImode 'smax' RTL generation

On Wed, Mar 14, 2012 at 11:39 AM, Frederic Riss wrote: > On 13 March 2012 22:36, Frédéric RISS wrote: >> In 4.7, the COND_EXPR has become a GIMPLE_TERNARY_RHS rhs_class, meaning >> that it won't use the expand_assigment path in expand_gimple_stmt_1, but >> will use straight expression expansion w

Re: peephole2+dead reg info after reload?

> Hi, > > I'm trying to make some peephole2 optimizations working (gcc 4.6.1), but > it seems the REG_DEAD information is lost during or after reload. > > In the following peephole2 definition, peep2_reg_dead_p returns false, > whereas REG_DEAD information is correctly set before reload for > ope

Second GCC 4.7.0 Release Candidate available from gcc.gnu.org

GCC 4.7.0 Release Candidate available from gcc.gnu.org A second release candidate for GCC 4.7.0 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314 and shortly its mirrors. It has been generated from SVN revision 185376. I have so far bootstrapped and tested the release

Re: Prototype libatomic

On 03/13/2012 08:02 PM, Richard Henderson wrote: So, I've got something put together. I think it should be fairly scalable. As a test I've thrown in some ARM overrides. See git://repo.or.cz/gcc/rth.git rth/libatomic which is a gcc tree with a libatomic subdir. Comments welcome. Andrew, d

Regarding my previous email

Hi gcc.gnu.org Team, I am not sure if you were able to receive my previous email because I did not get a response. Our system experienced a problem a few days ago and I just want to make sure that my email has been sent. Looking forward to hearing from you. Best Regards, Katy

PRE_GCC3_DWARF_FRAME_REGISTERS

Hello, The rs6000 and cr16 backends and unwinding code have a define for the DWARF frame register for pre-GCC3 compatibility (PRE_GCC3_DWARF_FRAME_REGISTERS): gcc/doc/tm.texi.in:@defmac PRE_GCC3_DWARF_FRAME_REGISTERS gcc/doc/tm.texi:@defmac PRE_GCC3_DWARF_FRAME_REGISTERS gcc/config/rs6000/rs6000.

Re: [4.7 regression?] HImode 'smax' RTL generation

On 14 March 2012 11:48, Richard Guenther wrote: > On Wed, Mar 14, 2012 at 11:39 AM, Frederic Riss > wrote: >> Doing that at expansion time looks like papering over some other issue >> though. > > Can you check where the COND_EXPR is introduced?  That place should > be fixed to properly fold. Q

Re: The state of glibc libm

On 2012-02-29 17:17:17 +, Joseph S. Myers wrote: > (a) Most libm functions are not correctly rounded - and do not make an > attempt at being correctly rounded. > > A full fix would likely require new (automatically generated and tuned) > implementations such as proposed at >

Re: The state of glibc libm

On Wed, 14 Mar 2012, Vincent Lefevre wrote: > For double-double (IBM long double), I don't think the notion of > correct rounding makes much sense anyway. Actually the double-double > arithmetic is mainly useful for the basic operations in order to be > able to implement elementary functions accur

Re: The state of glibc libm

On 03/14/2012 08:30 AM, Vincent Lefevre wrote: (b) Where functions do make attempts at being correctly rounded (especially the IBM Accurate Mathematical Library functions), they tend to be sufficiently slow that the slowness attracts bug reports. Again, this would likely be addressed by new im

Re: The state of glibc libm

On Wed, 14 Mar 2012, Jeff Law wrote: > On 03/14/2012 08:30 AM, Vincent Lefevre wrote: > > > > > (b) Where functions do make attempts at being correctly rounded > > > (especially the IBM Accurate Mathematical Library functions), they tend to > > > be sufficiently slow that the slowness attracts bu

Re: Prototype libatomic

On 03/14/12 05:03, Andrew MacLeod wrote: > I had taken that code, split it into more manageable source files > that weren't so macro driven and much easier to maintain, added some > testcases to verify the build, and was trying to figure out how to > configure and build libatomic as a standalone li

Re: The state of glibc libm

On 03/14/2012 10:30 AM, Joseph S. Myers wrote: I'd say that "better performance with the potential loss of accuracy" should be covered by -ffast-math - that GCC should generate direct use of fsin/fcos instructions for sin/cos for -O2 -funsafe-math-optimizations on x86_64, as it does on x86, unle

Re: Prototype libatomic

One of the things I want to make sure is that the library can be easily extended in a generic way (ie not target dependant) as needs change. Ie, initiually we are simply guaranteeing atomic operations and fall back to a lock. I expect in the not too distant future other sorts of guarantees ma

Re: Prototype libatomic

On 03/14/12 11:14, Andrew MacLeod wrote: > Perhaps those can fall into the config directory as well? ie config/TM or > config/forwardprogress? Hmm. Yes, I think so. Place a new copy of load_g.c in config/tm and that will override the one at the top-level. A mere matter of adjusting the sear

gcc-frontend tracer and a perlscript htmltags.pl

Hi, I would like to send a gcc-frontend tracer and a perlscript called htmltags.pl that takes the trace and creates a nice dhtml page. The source is here: http://cfw.sourceforge.net/htmltags.html an example of the output is here: http://cfw.sourceforge.net/htmltag/init_32.c.pinfo.html There is a h

Re: Prototype libatomic

On Tuesday 13 of March 2012 17:02:01 Richard Henderson wrote: > So, I've got something put together. I think it should be fairly scalable. > As a test I've thrown in some ARM overrides. > > See > > git://repo.or.cz/gcc/rth.git rth/libatomic > > which is a gcc tree with a libatomic subdir. >

Re: Prototype libatomic

On 03/14/12 11:54, Paweł Sikora wrote: > is this yet another libatomic implementation better than atomic_ops? > > http://www.hpl.hp.com/research/linux/atomic_ops/ > https://github.com/ivmai/libatomic_ops/ My implementation is targeted at the requirements of C++11. The projects you reference are n

Re: Prototype libatomic

Stupid evolution and autodetection of html format emails..., gcc bounced the reply... On 03/14/2012 02:54 PM, Paweł Sikora wrote: On Tuesday 13 of March 2012 17:02:01 Richard Henderson wrote: So, I've got something put together. I think it should be fairly scalable. As a test I've thrown in s

Re: Prototype libatomic

On 03/14/2012 03:06 PM, Andrew MacLeod wrote: No comment on whether its better or worse than any other library, but once we have one in place in the toolchain, everyone is welcome to enhance it with a better implementation. Heh, not to say that rth's implementation isn't a good one :-)...

Re: The state of glibc libm

Jeff Law writes: > On 03/14/2012 10:30 AM, Joseph S. Myers wrote: >> >> I'd say that "better performance with the potential loss of accuracy" >> should be covered by -ffast-math - that GCC should generate direct use of >> fsin/fcos instructions for sin/cos for -O2 -funsafe-math-optimizations on >

Re: The state of glibc libm

On Wed, 14 Mar 2012, Joseph S. Myers wrote: I'd say that "better performance with the potential loss of accuracy" should be covered by -ffast-math - that GCC should generate direct use of fsin/fcos instructions for sin/cos for -O2 -funsafe-math-optimizations on x86_64, as it does on x86, unless

Re: The state of glibc libm

On Wed, 14 Mar 2012, Andi Kleen wrote: > One big win alone on 32bit x86 would be to use a SSE ABI for libm > by default. I haven't checked, but I'd hope x32 does that as a better 32-bit ABI for newer x86 processors. -- Joseph S. Myers jos...@codesourcery.com

Re: The state of glibc libm

On Wed, 14 Mar 2012, Marc Glisse wrote: > On Wed, 14 Mar 2012, Joseph S. Myers wrote: > > > I'd say that "better performance with the potential loss of accuracy" > > should be covered by -ffast-math - that GCC should generate direct use of > > fsin/fcos instructions for sin/cos for -O2 -funsafe-m

Re: The state of glibc libm

On Wed, Mar 14, 2012 at 09:04:53PM +, Joseph S. Myers wrote: > On Wed, 14 Mar 2012, Andi Kleen wrote: > > > One big win alone on 32bit x86 would be to use a SSE ABI for libm > > by default. > > I haven't checked, but I'd hope x32 does that as a better 32-bit ABI for > newer x86 processors.

Re: The state of glibc libm

From: Jeff Law Date: Wed, 14 Mar 2012 10:41:27 -0600 > The better performance with potential loss of accuracy is an across > the board request, it's not just a sin/cos issue. All the trig, exp, > pow, log, etc, which I don't think are necessarily covered by using > the old x87 fp unit. This is

Re: The state of glibc libm

On 2012-03-14 14:40:06 +, Joseph S. Myers wrote: > On Wed, 14 Mar 2012, Vincent Lefevre wrote: > > > For double-double (IBM long double), I don't think the notion of > > correct rounding makes much sense anyway. Actually the double-double > > arithmetic is mainly useful for the basic operation