Re: The state of glibc libm
On Wed, Mar 14, 2012 at 10:47 PM, Andi Kleen wrote: > 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. > > x32 is not a mainstream option. SSE ABI entries for i?86 in glibc were rejected. I proposed them like 4-5 years ago to make -mfpmath=sse not suck. Richard. > -Andi > -- > a...@linux.intel.com -- Speaking for myself only.
Re: Prototype libatomic
On Wed, 2012-03-14 at 12:00 -0700, Richard Henderson wrote: > 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/ It's serves a similar purpose. libatomic_ops was library/header-only portable support for atomic operations. libatomic is the fallback library for a compiler that supports the C++11/C11 memory model and atomic types. libatomic_ops has a different set of memory orders, although for example acquire/release should be similar. If you're still using libatomic_ops, consider moving to the C++11/C11 memory model. > > My implementation is targeted at the requirements of C++11. > The projects you reference are not. Nonetheless, libatomic_ops can be an input for libatomic, although we cover a lot of arcs already in the GCC builtins and code generator. Torvald
Re: Prototype libatomic
On Wed, 2012-03-14 at 14:14 -0400, Andrew MacLeod wrote: > I expect in the not too distant future other sorts of guarantees may be > desired, such as various forms of forward progress guarantees to replace > the spin locks I will have a look at what's there, and can take care of the lock-based fallbacks if you want. Note that if we really want to look at progress guarantees again, we'll also have to consider: - how C++11 locks are implemented - how strong CAS is implemented on LL/SC architectures - how various (strong) atomic operations are implemented using CAS loops It might also mean that we have to take the OS scheduler's guarantees into account (so, do different things on different platforms). > and It'd be nice to have a TM version of the library as > well, so when hardware is available we can make good use of it. I don't think we should put a lot of effort into this right now because I don't see enough use cases for TM in libatomic. Typically, accessing more than one object atomically is the hard part in concurrent programming, not accessing a bigger-than-word-sized object atomically. With first-generation HTMs that don't have minimum capacity/progress guarantees, we can't guarantee more than a lock-based fallback anyway. If a programmer assumes that HTM is available, why not use transactions in the first place? Also, architectures with HTM support will likely have a full set of word-sized atomic operations too. If we actually see that users want have low-level atomic access to larger-than-word-sized and don't want to use locks or transactions for it, we can still add HTM support to libatomic. Torvald
Re: The state of glibc libm
> SSE ABI entries for i?86 in glibc were rejected. I proposed them like > 4-5 years ago to make -mfpmath=sse not suck. With the new libm hopefully this can be revisited. But there's the ABI and there's the internal implementation. My point was just that relying on x87 fully again does not really make sense anymore in 2012. -andi -- a...@linux.intel.com -- Speaking for myself only.
Re: The state of glibc libm
On Thu, Mar 15, 2012 at 3:17 PM, Andi Kleen wrote: >> SSE ABI entries for i?86 in glibc were rejected. I proposed them like >> 4-5 years ago to make -mfpmath=sse not suck. > > With the new libm hopefully this can be revisited. > > But there's the ABI and there's the internal implementation. > > My point was just that relying on x87 fully again does not really make > sense anymore in 2012. That's true, the return value shuffle to/from the x87 stack might not be too bad for performance, nor argument passing on the stack. Richard.
Re: The state of glibc libm
Hello! >>> SSE ABI entries for i?86 in glibc were rejected. ?I proposed them like >>> 4-5 years ago to make -mfpmath=sse not suck. >> >> With the new libm hopefully this can be revisited. >> >> But there's the ABI and there's the internal implementation. >> >> My point was just that relying on x87 fully again does not really make >> sense anymore in 2012. > > That's true, the return value shuffle to/from the x87 stack might not be > too bad for performance, nor argument passing on the stack. Can this issue be solved with alternative function entry points, in the same way ICC does? This way, we can pass values in SSE, not on the stack. Uros.
Linked-In Invitation to connect #12461513
#Î58-9799932-79731320-7-484
Re: The state of glibc libm
> "VL" == Vincent Lefevre writes: VL> sinf being slower than sin is surprising Some weeks back I wrote a simple app to output a couple of waveforms as float samples (I encased it in a tiny script which piped the output to sox to create a wav). I found that converting it to work on and output doubles improved performance from around 2.2 sec per minute of output to around 0.3 sec per minute for a simple tan(sin(t)) waveform. That is using glibc-2.14.1 on amd64 on a 2800MHz K10, compiled with gcc-4.6.2 with -O2 and the graphite -floop-... options. Some improvements have landed for the float versions of libm since. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6
strange error during make install of 4.6.3
I was surprised to see this pop up during make install : . . . rm -f /opt/bw/share/info/gcc.info if [ -f doc/gcc.info ]; then \ for f in doc/gcc.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /opt/bw/src/gcc-4.6.3/install-sh -c -m 644 $f /opt/bw/share/info/$realfile; \ chmod a-x /opt/bw/share/info/$realfile; \ done; \ else true; fi if /bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ if [ -f /opt/bw/share/info/gcc.info ]; then \ install-info --dir-file=/opt/bw/share/info/dir /opt/bw/share/info/gcc.info; \ else true; fi; \ else true; fi; if [ x = xinfo ]; then \ /opt/bw/src/gcc-4.6.3/missing makeinfo --split-size=500 --split-size=500 --no-split -I . -I ../../gcc-4.6.3/gcc/doc \ -I ../../gcc-4.6.3/gcc/doc/include -o doc/cppinternals.info ../../gcc-4.6.3/gcc/doc/cppinternals.texi; \ fi rm -f /opt/bw/share/info/cppinternals.info if [ -f doc/cppinternals.info ]; then \ for f in doc/cppinternals.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /opt/bw/src/gcc-4.6.3/install-sh -c -m 644 $f /opt/bw/share/info/$realfile; \ chmod a-x /opt/bw/share/info/$realfile; \ done; \ else true; fi if /bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ if [ -f /opt/bw/share/info/cppinternals.info ]; then \ install-info --dir-file=/opt/bw/share/info/dir /opt/bw/share/info/cppinternals.info; \ else true; fi; \ else true; fi; if [ x = xinfo ]; then \ /opt/bw/src/gcc-4.6.3/missing makeinfo --split-size=500 --split-size=500 --no-split -I ../../gcc-4.6.3/gcc/doc \ -I ../../gcc-4.6.3/gcc/doc/include -o doc/gccinstall.info ../../gcc-4.6.3/gcc/doc/install.texi; \ fi rm -f /opt/bw/share/info/gccinstall.info if [ -f doc/gccinstall.info ]; then \ for f in doc/gccinstall.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /opt/bw/src/gcc-4.6.3/install-sh -c -m 644 $f /opt/bw/share/info/$realfile; \ chmod a-x /opt/bw/share/info/$realfile; \ done; \ else true; fi if /bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ if [ -f /opt/bw/share/info/gccinstall.info ]; then \ install-info --dir-file=/opt/bw/share/info/dir /opt/bw/share/info/gccinstall.info; \ else true; fi; \ else true; fi; build/genhooks \ ../../gcc-4.6.3/gcc/doc/tm.texi.in > tmp-tm.texi case `echo X|tr X '\101'` in \ A) tr -d '\015' < tmp-tm.texi > tmp2-tm.texi ;; \ *) tr -d '\r' < tmp-tm.texi > tmp2-tm.texi ;; \ esac mv tmp2-tm.texi tmp-tm.texi /bin/bash ../../gcc-4.6.3/gcc/../move-if-change tmp-tm.texi tm.texi if [ x = xinfo ]; then \ /opt/bw/src/gcc-4.6.3/missing makeinfo --split-size=500 --split-size=500 --no-split -I . -I ../../gcc-4.6.3/gcc/doc \ -I ../../gcc-4.6.3/gcc/doc/include -o doc/gccint.info ../../gcc-4.6.3/gcc/doc/gccint.texi; \ fi rm -f /opt/bw/share/info/gccint.info if [ -f doc/gccint.info ]; then \ for f in doc/gccint.info*; do \ realfile=`echo $f | sed -e 's|.*/\([^/]*\)$|\1|'`; \ /opt/bw/src/gcc-4.6.3/install-sh -c -m 644 $f /opt/bw/share/info/$realfile; \ chmod a-x /opt/bw/share/info/$realfile; \ done; \ else true; fi if /bin/bash -c 'install-info --version' >/dev/null 2>&1; then \ if [ -f /opt/bw/share/info/gccint.info ]; then \ install-info --dir-file=/opt/bw/share/info/dir /opt/bw/share/info/gccint.info; \ else true; fi; \ else true; fi; gmake ada/doctools/xgnatugn gmake[3]: Entering directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' mkdir -p ada/doctools cp -p ../../gcc-4.6.3/gcc/ada/xgnatugn.adb ada/doctools cd ada/doctools && gnatmake -q xgnatugn gnatmake: "xgnatugn.ali" incompatible ALI file, please recompile gnatmake: "xgnatugn.adb" compilation error gmake[3]: *** [ada/doctools/xgnatugn] Error 4 gmake[3]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' gmake[2]: *** [doc/projects.texi] Error 2 gmake[2]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386/gcc' gmake[1]: *** [install-gcc] Error 2 gmake[1]: Leaving directory `/opt/bw/src/gcc-4.6.3-SunOS5.8-i386' gmake: *** [install] Error 2 $ Weird. Never saw that on sparc nor anywhere else. There is a pre-existing GCC 4.5.3 as that was the compiler used in stage 1 of the bootstrap. Any thoughts anyone ? dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: strange error during make install of 4.6.3
Also : http://gcc.gnu.org/ml/gcc-help/2010-02/msg00153.html > > I was surprised to see this pop up during make install : >
gcc-4.5-20120315 is now available
Snapshot gcc-4.5-20120315 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120315/ 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/gcc-4_5-branch revision 185445 You'll find: gcc-4.5-20120315.tar.bz2 Complete GCC MD5=603d68c46a6e47dcc700041926da4cac SHA1=02a01ef41c5b814b9b5f8645d78214c56e89f57c Diffs from 4.5-20120308 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Prototype libatomic
On 03/14/12 11:31, Richard Henderson wrote: > For my next trick: figuring out an Easy Way of utilizing IFUNCs, > so that we automatically make use of new cpu features without > recompilation... Dunno about "easy", but I can now generate a shared library that contains ifunc symbols. Gotta get that testsuite in now... r~
Re: Prototype libatomic
On 03/15/2012 07:52 PM, Richard Henderson wrote: On 03/14/12 11:31, Richard Henderson wrote: For my next trick: figuring out an Easy Way of utilizing IFUNCs, so that we automatically make use of new cpu features without recompilation... Dunno about "easy", but I can now generate a shared library that contains ifunc symbols. Gotta get that testsuite in now... A functional testcase would be to copy all the following files from testsuite/gcc.dg , compile them with -fno-atomics, and execute them linked with the library. That will test for proper execution of the library as well as all symbols being available. To test true atomicity requires the simulate-thread environment with an additional understanding of what your locks are so that the 'other_thread' process can't go and change something that is currently locked...Probably better left until later. Andrew atomic-compare-exchange-[1-5].c atomic-exchange-[1-5].c atomic-generic.c atomic-load-[1-5].c atomic-op-[1-5].c atomic-store-[1-5].c
target_header_dir vs host-x-host
configure has various ways of specifying the target headers for a cross-compiler. However, none of these work when you're cross-building a native (build!=host==target). Unfortunately, configure looks in $target_header_dir for target headers to determine various bits of functionality. What is the right way to tell the cross compiler which is cross-building the native, where the cross-built native headers are?
Re: target_header_dir vs host-x-host
DJ Delorie writes: > configure has various ways of specifying the target headers for a > cross-compiler. However, none of these work when you're > cross-building a native (build!=host==target). Unfortunately, > configure looks in $target_header_dir for target headers to determine > various bits of functionality. > > What is the right way to tell the cross compiler which is > cross-building the native, where the cross-built native headers are? My first try would be --with-build-sysroot. Does that fail in some way? Ian
Re: target_header_dir vs host-x-host
> My first try would be --with-build-sysroot. Does that fail in some way? It's ignored without --with-sysroot, but if you use --with-sysroot, the cross-built native *also* expects to use a sysroot, which means binutils must also be built with a sysroot, even if its "/".
Re: target_header_dir vs host-x-host
DJ Delorie writes: >> My first try would be --with-build-sysroot. Does that fail in some way? > > It's ignored without --with-sysroot, but if you use --with-sysroot, > the cross-built native *also* expects to use a sysroot, which means > binutils must also be built with a sysroot, even if its "/". OK, but what's wrong --with-sysroot=/ ? Ian
Re: target_header_dir vs host-x-host
> OK, but what's wrong --with-sysroot=/ ? It should work, it just seems "wrong" for a native compiler to have a sysroot...
Re: target_header_dir vs host-x-host
On Thu, Mar 15, 2012 at 9:50 PM, DJ Delorie wrote: > >> OK, but what's wrong --with-sysroot=/ ? > > It should work, it just seems "wrong" for a native compiler to have a > sysroot... I noticed that a lot of binutils tests fail if it is not compiled with --with-sysroot=/ . This is why I always compile my native/candian cross toolchains with --with-sysroot=/ . Thanks, Andrew Pinski
