underexposed snapshots

2012-09-15 Thread Randy Bush
ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i guess things are moving around. any idea where i can get the latest tag=. randy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current

Re: underexposed snapshots

2012-09-15 Thread Randy Bush
Randy Bush wrote: ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i guess things are moving around. any idea where i can get the latest tag=. cut and paste error ftp://ftp.freebsd.org/pub/FreeBSD/snapshots ___

Re: underexposed snapshots

2012-09-15 Thread Garrett Cooper
On Fri, Sep 14, 2012 at 11:43 PM, Randy Bush ra...@psg.com wrote: ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i guess things are moving around. any idea where i can get the latest tag=. Latest tag is 9.1-RC1:

Re: underexposed snapshots

2012-09-15 Thread Randy Bush
ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i guess things are moving around. any idea where i can get the latest tag=. Latest tag is 9.1-RC1: ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/9.1-RC1/ , etc. this is for an i386 running 10-current randy

Re: underexposed snapshots

2012-09-15 Thread Joel Dahl
On 15-09-2012 15:43, Randy Bush wrote: ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i guess things are moving around. any idea where i can get the latest tag=. https://pub.allbsd.org/FreeBSD-snapshots/ -- Joel ___

Re: underexposed snapshots

2012-09-15 Thread Garrett Cooper
On Fri, Sep 14, 2012 at 11:55 PM, Randy Bush ra...@psg.com wrote: ftp://ftp.FreeBSD.org/pub/FreeBSD/ISO-IMAGES-arch is a bit empty. i guess things are moving around. any idea where i can get the latest tag=. Latest tag is 9.1-RC1:

Re: underexposed snapshots

2012-09-15 Thread Randy Bush
As I said, this is the latest snapshot. Long story short is that the old process was changed before 9.0 and releng hasn't caught up with the new process yet in a sustainable manner (at least, not executing it on a regular basis). If you have interest in making sure regular (monthly) releases

Re: freebsd-current Digest, Vol 465, Issue 5

2012-09-15 Thread Thomas Mueller
[-- Attachment #1 --] [-- Type: text/plain, Encoding: base64, Size: 49K --] Help - Reply message - From: freebsd-current-requ...@freebsd.org To: freebsd-current@freebsd.org Subject: freebsd-current Digest, Vol 465, Issue 5 Date: Thu, Sep 13, 2012 8:00 am (and much more) This

Re: Clang as default compiler November 4th

2012-09-15 Thread Roman Divacky
LLVM by default turns these: case LibFunc::copysign: case LibFunc::copysignf: case LibFunc::copysignl: case LibFunc::fabs: case LibFunc::fabsf: case LibFunc::fabsl: case LibFunc::sin: case LibFunc::sinf: case LibFunc::sinl: case LibFunc::cos: case

Re: Clang as default compiler November 4th

2012-09-15 Thread Tijl Coosemans
On 15-09-2012 03:06, Steve Kargl wrote: On Fri, Sep 14, 2012 at 05:18:08PM -0700, Steve Kargl wrote: A third class of failure appears to be that clang emits i387 fpu instructions for at least sinf and cosf instead of calls to the library routines. AFAIK, the library routines are faster and

Re: Clang as default compiler November 4th

2012-09-15 Thread Roman Divacky
Fwiw, this seems to have been fixed as of a few minutes ago. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150720.html Steve, can you please test llvm/clang from (their) svn and report back? We can import a newer snapshot if all is ok. Thank you. On Fri, Sep 14, 2012 at

Re: Clang as default compiler November 4th

2012-09-15 Thread Tijl Coosemans
On 15-09-2012 14:48, Roman Divacky wrote: Fwiw, this seems to have been fixed as of a few minutes ago. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150720.html Steve, can you please test llvm/clang from (their) svn and report back? We can import a newer snapshot if

Re: Clang as default compiler November 4th

2012-09-15 Thread Roman Divacky
Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 If so I believe the issue is fixed. On Sat, Sep 15, 2012 at 03:48:38PM +0200, Tijl Coosemans wrote: On 15-09-2012 14:48, Roman Divacky wrote: Fwiw, this seems to have been fixed as of a few minutes ago.

Re: Clang as default compiler November 4th

2012-09-15 Thread Tijl Coosemans
On 15-09-2012 16:09, Roman Divacky wrote: Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 Yes, that's what the libm call returns. signature.asc Description: OpenPGP digital signature

Re: Clang as default compiler November 4th

2012-09-15 Thread Mehmet Erol Sanliturk
On Sat, Sep 15, 2012 at 7:30 AM, Tijl Coosemans t...@coosemans.org wrote: On 15-09-2012 16:09, Roman Divacky wrote: Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 Yes, that's what the libm call returns. The following is a result in Fedora 17

Re: Clang as default compiler November 4th

2012-09-15 Thread Mehmet Erol Sanliturk
On Sat, Sep 15, 2012 at 7:30 AM, Tijl Coosemans t...@coosemans.org wrote: On 15-09-2012 16:09, Roman Divacky wrote: Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 Yes, that's what the libm call returns. Linux z 3.5.3-1.fc17.x86_64 #1 SMP

Re: Clang as default compiler November 4th

2012-09-15 Thread Warner Losh
On Sep 15, 2012, at 3:14 AM, Roman Divacky wrote: LLVM by default turns these: case LibFunc::copysign: case LibFunc::copysignf: case LibFunc::copysignl: case LibFunc::fabs: case LibFunc::fabsf: case LibFunc::fabsl: case LibFunc::sin: case LibFunc::sinf:

Re: Clang as default compiler November 4th

2012-09-15 Thread Dimitry Andric
On 2012-09-15 16:30, Tijl Coosemans wrote: On 15-09-2012 16:09, Roman Divacky wrote: Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 Yes, that's what the libm call returns. Fix committed in http://svn.freebsd.org/changeset/base/240531.

Re: Clang as default compiler November 4th

2012-09-15 Thread Steve Kargl
On Sat, Sep 15, 2012 at 07:18:28PM +0200, Dimitry Andric wrote: On 2012-09-15 16:30, Tijl Coosemans wrote: On 15-09-2012 16:09, Roman Divacky wrote: Is this correct? lev ~$ ./cos 1.23456789e20 6.031937e-01 -9.629173e-02 2.814722e-01 Yes, that's what the libm call returns. Fix

Compiler performance tests on FreeBSD 10.0-CURRENT

2012-09-15 Thread Dimitry Andric
Hi all, By request, I performed a series of kernel performance tests on FreeBSD 10.0-CURRENT, particularly comparing the runtime performance of GENERIC kernels compiled by gcc 4.2.1 and by clang 3.2. The attached text file[1] contains more information about the tests, some semi-cooked

Re: Compiler performance tests on FreeBSD 10.0-CURRENT

2012-09-15 Thread Luigi Rizzo
On Sun, Sep 16, 2012 at 12:34:45AM +0200, Dimitry Andric wrote: Hi all, By request, I performed a series of kernel performance tests on FreeBSD 10.0-CURRENT, particularly comparing the runtime performance of GENERIC kernels compiled by gcc 4.2.1 and by clang 3.2. the fact that the

Re: Compiler performance tests on FreeBSD 10.0-CURRENT

2012-09-15 Thread Dimitry Andric
On 2012-09-16 01:22, Luigi Rizzo wrote: ... the fact that the difference is so small is interesting, and it might almost suggests that the test is dominated by other factors than the compiler. Yes, this result was more or less what I expected: runtime performance is probably related more to

Re: Compiler performance tests on FreeBSD 10.0-CURRENT

2012-09-15 Thread Konstantin Belousov
On Sun, Sep 16, 2012 at 12:34:45AM +0200, Dimitry Andric wrote: Hi all, By request, I performed a series of kernel performance tests on FreeBSD 10.0-CURRENT, particularly comparing the runtime performance of GENERIC kernels compiled by gcc 4.2.1 and by clang 3.2. The attached text file[1]

Re: Compiler performance tests on FreeBSD 10.0-CURRENT

2012-09-15 Thread Garrett Cooper
On Sat, Sep 15, 2012 at 10:19 PM, Konstantin Belousov kostik...@gmail.com wrote: On Sun, Sep 16, 2012 at 12:34:45AM +0200, Dimitry Andric wrote: Hi all, By request, I performed a series of kernel performance tests on FreeBSD 10.0-CURRENT, particularly comparing the runtime performance of