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
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
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
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
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.
On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote:
On Thu, Sep 13, 2012 at 09:32:12AM -0600, Ian Lepore wrote:
On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote:
In regards to my initial post in this thread, I was just trying
to assess whether any benchmarks have been
On Fri, Sep 14, 2012 at 03:23:19PM -0500, Brooks Davis wrote:
On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote:
ok 1 - cexp zero
Abort trap (core dumped)
*** [tests] Error code 134
Stop in /usr/src/tools/regression/lib/msun.
Prompted by this post, I did a bit of testing
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 more accurate.
Yep. Clang has
On Thu, Sep 13, 2012 at 08:21:31AM +0200, Pietro Cerutti wrote:
On 2012-Sep-11, 23:29, Doug Barton wrote:
What we need to do is what I and others have been asking to do for
years. We need to designate a modern version of gcc (no less than 4.6)
as the official default ports compiler, and
On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote:
In regards to my initial post in this thread, I was just trying
to assess whether any benchmarks have been performed on FreeBSD
for floating point generated by clang. Other than the limited
testing that I've done, it appears that the
On Thu, Sep 13, 2012 at 09:32:12AM -0600, Ian Lepore wrote:
On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote:
In regards to my initial post in this thread, I was just trying
to assess whether any benchmarks have been performed on FreeBSD
for floating point generated by clang. Other
On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote:
At the moment the ports maintainers don't give much about if their ports
build with CLANG or not because they're not forced to.
I think this is a mis-representation.
Adding the requirement your ports must work on clang is adding an
On 09/11/2012 02:52 AM, Erik Cederstrand wrote:
So can we do a sweep on the ports tree and mark the 2232 ports with
USE_GCC=4.2 until they can actually build with clang?
Unfortunately it isn't that simple. We already have a statistically
significant number of ports that don't even compile with
On 09/11/2012 11:15 PM, Mark Linimon wrote:
On Tue, Sep 11, 2012 at 11:27:50AM +0200, Lars Engels wrote:
At the moment the ports maintainers don't give much about if their ports
build with CLANG or not because they're not forced to.
I think this is a mis-representation.
Adding the
Den 12/09/2012 kl. 11.29 skrev Doug Barton do...@freebsd.org:
On 09/11/2012 02:52 AM, Erik Cederstrand wrote:
So can we do a sweep on the ports tree and mark the 2232 ports with
USE_GCC=4.2 until they can actually build with clang?
Unfortunately it isn't that simple. We already have a
On 12 Sep 2012, at 10:09, Doug Barton wrote:
Also, users who actually are helping with testing clang for ports
continue to report runtime problems, even with things that build fine.
I hope that you are encouraging maintainers of ports that don't work as
expected with clang to submit bug
On Tue, 11 Sep 2012, Erik Cederstrand wrote:
So can we do a sweep on the ports tree and mark the 2232 ports with
USE_GCC=4.2 until they can actually build with clang? This could allow
the clang switch to proceed. Hopefully, waiting for GCC to compile just
to install some tiny port will be
I'd add one more thing that needs fixing:
Clang should default to c89 mode when invoked as cc. I had a patch to do this,
but I seem to have misplaced it. I'll try to find or rewrite it in the next
couple of days.
A lot of the ports failures I saw were due to ports using cc as the default C
On 11 Sep 2012, at 09:18, Dimitry Andric wrote:
So I am a bit reluctant to change clang's default standard to c89,
unless clang upstream agrees with this. In the interest of prodding
people to update their software, I would rather have the default stay
c99, personally. :)
I'm not proposing
On Mon, Sep 10, 2012 at 10:54:04PM -0700, Doug Barton wrote:
As of last week, 4,680 ports out of 23,857 failed to build with clang on
9-amd64. That's almost a 20% failure rate. Until we have better support
for either building ports with clang, or have better support for the
idea of a ports
On 09/11/2012 02:27 AM, Lars Engels wrote:
On Mon, Sep 10, 2012 at 10:54:04PM -0700, Doug Barton wrote:
As of last week, 4,680 ports out of 23,857 failed to build with clang on
9-amd64. That's almost a 20% failure rate. Until we have better support
for either building ports with clang, or have
On Mon, Sep 10, 2012 at 04:12:07PM -0500, Brooks Davis wrote:
[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]
I do not see how removing current@ can be done, toolchain@ is not
relevant for this discussion. Proposed is not a local change in the
tl;dr: Clang will become the default compiler for x86 architectures on
2012-11-04
There was a chorus of voices talking about ports already. My POV
is that suggesting to 'fix remaining ports to work with clang' is
just a nonsense. You are proposing to fork the development of all the
On Tue, Sep 11, 2012 at 03:21:22PM +0300, Konstantin Belousov wrote:
On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote:
tl;dr: Clang will become the default compiler for x86 architectures on
2012-11-04
There was a chorus of voices talking about ports already. My POV
Roman,
Den 11/09/2012 kl. 14.38 skrev Roman Divacky rdiva...@freebsd.org:
Upstream developers almost never use gcc4.2.1 as we do. So right now the
ports maintainer must check whats wrong in the case the (upgraded) port
doesnt compile with our in-tree gcc.
It can be trivial
On Tue, Sep 11, 2012 at 01:45:18PM +0300, Konstantin Belousov wrote:
On Mon, Sep 10, 2012 at 04:12:07PM -0500, Brooks Davis wrote:
For the past several years we've been working towards migrating from
GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD
10.0 with Clang as
On 2012-09-11 15:24, Steve Kargl wrote:
...
How fast clang builds world in comparison to gcc is irrelevant.
Not at all irrelevant: this proposal is about changing the default
compiler for the FreeBSD system itself, not for all software out there.
If certain software performs significantly
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/11/12 09:44, Christer Solskogen wrote:
On Tue, Sep 11, 2012 at 3:32 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
Interest twist of history. GCC is not abandonware.
Correct, but GCC 4.2.1 is.
While this may be true, I'm not
On 11-09-2012 16:10, Dimitry Andric wrote:
On 2012-09-11 15:24, Steve Kargl wrote:
What is important is whether software built with clang functions
correctly. See for example,
http://math-atlas.sourceforge.net/errata.html#WhatComp
Yes, maths support, specifically precision, is admittedly
On 11 Sep 2012 13:22, Konstantin Belousov kostik...@gmail.com wrote:
On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote:
tl;dr: Clang will become the default compiler for x86 architectures
on 2012-11-04
There was a chorus of voices talking about ports already. My POV
is
On 2012-09-11 16:27, Tijl Coosemans wrote: On 11-09-2012 16:10, Dimitry Andric
wrote:
...
Yes, maths support, specifically precision, is admittedly still one of
clang's (really llvm's) weaker points. It is currently not really a
high priority item for upstream.
This is obviously something
On Tue, Sep 11, 2012 at 7:21 AM, Konstantin Belousov
kostik...@gmail.com wrote:
snip
Can you, please, read what I wrote ? Fixing _ports_ to compile with
clang is plain wrong. Upstream developers use gcc almost always for
development and testing. Establishing another constant cost on the
On Tue, Sep 11, 2012 at 04:10:13PM +0200, Dimitry Andric wrote:
On 2012-09-11 15:24, Steve Kargl wrote:
...
How fast clang builds world in comparison to gcc is irrelevant.
Not at all irrelevant: this proposal is about changing the default
compiler for the FreeBSD system itself, not for all
On Tue, Sep 11, 2012 at 04:27:55PM +0200, Tijl Coosemans wrote:
On 11-09-2012 16:10, Dimitry Andric wrote:
On 2012-09-11 15:24, Steve Kargl wrote:
What is important is whether software built with clang functions
correctly. See for example,
On Tue, 11 Sep 2012, Konstantin Belousov wrote:
On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote:
We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent
the most other ports from compiling together prevent ports from
compilation. So if we fixed those
On Tue, Sep 11, 2012 at 08:12:30AM -0700, Steve Kargl wrote:
On Tue, Sep 11, 2012 at 04:27:55PM +0200, Tijl Coosemans wrote:
On 11-09-2012 16:10, Dimitry Andric wrote:
On 2012-09-11 15:24, Steve Kargl wrote:
What is important is whether software built with clang functions
correctly.
On Tue, Sep 11, 2012 at 12:14:09PM -0500, Mark Felder wrote:
Clang produces incorrect code vs Clang's floating point has
issues are two different arguments.
Wow. clang produces incorrect floating point code, and
that's somehow just an issue with floating point.
For a mathematical
[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]
For the past several years we've been working towards migrating from
GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD
10.0 with Clang as the default compiler on i386 and amd64
On Mon, 10 Sep 2012, Brooks Davis wrote:
[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]
For the past several years we've been working towards migrating from
GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD
10.0 with
On Mon, Sep 10, 2012 at 5:01 PM, Brooks Davis bro...@freebsd.org wrote:
On Mon, Sep 10, 2012 at 05:22:37PM -0400, Daniel Eischen wrote:
On Mon, 10 Sep 2012, Brooks Davis wrote:
[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]
For the
On 09/10/12 14:22, Daniel Eischen wrote:
On Mon, 10 Sep 2012, Brooks Davis wrote:
[Please confine your replies to toolch...@freebsd.org to keep the thread
on the most relevant list.]
For the past several years we've been working towards migrating from
GCC to Clang/LLVM as our default
41 matches
Mail list logo
