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
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
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
f
> 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 reall
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.
>
> M
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
#Î58-9799932-79731320-7-484
> "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 outpu
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;
Also : http://gcc.gnu.org/ml/gcc-help/2010-02/msg00153.html
>
> I was surprised to see this pop up during make install :
>
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
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
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 librar
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 th
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
> 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 "/".
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=/ ?
It should work, it just seems "wrong" for a native compiler to have a sysroot...
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 c
19 matches
Mail list logo
