It seems that clang can't do complex arithmetic.
Not to worry gcc in base can't do it either.
/*
* The C99 standard intends x+I*y to be used for this, but x+I*y is
* currently unusable because gcc introduces many overflow,
* underflow, sign and efficiency bugs by rewriting I*y as
* (0.0+I)*(y+
On Tue, Nov 02, 2010 at 07:32:35PM +0100, Roman Divacky wrote:
> this reproduces with TOT clang/llvm. Can you please file
> a bug against clang?
>
> http://llvm.org/bugs/
>
> they generally fix things very fast. thank you!
>
Well, I would submit a bug report, but apparently
one needs to
On Tue, Nov 02, 2010 at 09:05:11PM +0100, Ed Schouten wrote:
> * Steve Kargl , 20101102 20:27:
> > Well, I would submit a bug report, but apparently
> > one needs to know some secret incantation to do so.
>
> Behold, magic:
>
> http://llvm.org/bugs/show_bug
On Thu, Nov 11, 2010 at 04:52:43PM +0100, Ed Schouten wrote:
> Hello all,
>
> I just committed libcompiler_rt.a to HEAD. Even though I don't expect
> serious issues -- especially not on the tier 1 architectures -- be sure
> to contact me in case something goes wrong. I hooked it up to the build
>
How does one build an executable for profiling with clang?
clang -o testf -O2 -march=native -pipe -static -pg -I/usr/local/include -I../mp
testf.c -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -L/usr/home/kargl/work/lib
-lm_clang_p
clang: warning: the clang compiler does not support '-pg'
I suppo
On Tue, Jan 18, 2011 at 03:32:05PM +0100, Roman Divacky wrote:
> On Mon, Jan 17, 2011 at 10:44:11AM -0800, Steve Kargl wrote:
> > How does one build an executable for profiling with clang?
>
> LLVM (and thus clang) does not support GPROF profiling.
>
> > clang -o testf
On Tue, Jan 18, 2011 at 06:16:57PM +0100, Roman Divacky wrote:
> On Tue, Jan 18, 2011 at 04:43:13PM +0200, Kostik Belousov wrote:
> > On Tue, Jan 18, 2011 at 03:32:05PM +0100, Roman Divacky wrote:
> > > On Mon, Jan 17, 2011 at 10:44:11AM -0800, Steve Kargl wrote:
> > &
On Wed, Jan 19, 2011 at 11:18:22AM +0100, Hans Ottevanger wrote:
> On 01/18/11 22:12, Roman Divacky wrote:
> >On Tue, Jan 18, 2011 at 09:35:17AM -0800, Steve Kargl wrote:
> >>On Tue, Jan 18, 2011 at 06:16:57PM +0100, Roman Divacky wrote:
> >>>On Tue, Jan 18, 20
On Wed, Jan 19, 2011 at 11:44:48AM +0100, Roman Divacky wrote:
> On Wed, Jan 19, 2011 at 11:18:22AM +0100, Hans Ottevanger wrote:
> > On 01/18/11 22:12, Roman Divacky wrote:
> > >On Tue, Jan 18, 2011 at 09:35:17AM -0800, Steve Kargl wrote:
> > >>On Tue, Jan 18, 2
On Thu, Jan 20, 2011 at 07:54:49PM +0100, Roman Divacky wrote:
>
> ok, I sat down and implemented what Hans Ottevanger told me to do :)
>
> http://lev.vlakno.cz/~rdivacky/clang-gprof.patch
>
Wow. Thanks.
I tried applying your patch to
% svn update
At revision 217661.
% cd /usr/src/c
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
>
> > Another issue with the switch, which seems to be not only not addressed,
> > but even not talked about, is the performance impact of t
On Tue, Sep 11, 2012 at 02:52:20PM +0200, Erik Cederstrand wrote:
> Den 11/09/2012 kl. 14.38 skrev Roman Divacky :
> > By the nature of "developing the OS" we are forced to use compilers and
> > toolchains. Recently I saw you submitting/committing patches with .byte
> > sequences because our defaul
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 FreeB
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 exa
On Tue, Sep 11, 2012 at 11:42:53AM -0500, Mark Felder wrote:
> On Tue, 11 Sep 2012 09:10:24 -0500, Michael Butler
> wrote:
>
> >- From the link (http://math-atlas.sourceforge.net/errata.html#WhatComp)
> >that Steve Kargl referenced (dated July 2012).
>
>
>
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 appl
On Tue, Sep 11, 2012 at 07:19:48PM +0200, Roman Divacky wrote:
> On Tue, Sep 11, 2012 at 08:12:30AM -0700, Steve Kargl wrote:
> >
> > I'm not sure if anyone has done any extensive testing.
> > I've started to run some of my test codes to compare
> > certain fu
On Wed, Sep 12, 2012 at 04:42:27PM -0500, Nathan Whitehorn wrote:
> On 09/11/12 09:56, Dimitry Andric wrote:
> >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
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 poi
On Thu, Sep 13, 2012 at 06:25:37PM +0200, Stefan Farfeleder wrote:
> On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote:
> > clang -O2 -pipe -march=opteron -O0 -lm test-cexp.c -o test-cexp
> > test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported,
>
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.
>
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.
>
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 cal
On Sat, Sep 22, 2012 at 02:20:14PM +0300, Konstantin Belousov wrote:
> On Fri, Sep 21, 2012 at 11:39:40PM +0200, Dimitry Andric wrote:
> > Hi all,
> >
> > As a followup to my previous post about the performance of FreeBSD 10.0
> > kernels compiled with different compilers (clang and gcc), I did an
On Tue, May 28, 2013 at 07:10:23PM +0100, David Chisnall wrote:
> On 28 May 2013, at 18:40, Warner Losh wrote:
>
> > That's not going to happen soon. While it works OK for amd64, there's still
> > many bugs in its ARM support and even more in its MIPS support. There's 0
> > chance it will be go
On Tue, May 28, 2013 at 01:01:00PM -0700, Rui Paulo wrote:
> On 28 May 2013, at 12:54, Steve Kargl
> wrote:
> > On Tue, May 28, 2013 at 07:10:23PM +0100, David Chisnall wrote:
> >> On 28 May 2013, at 18:40, Warner Losh wrote:
> >>
> >>> That's
On Wed, May 29, 2013 at 09:47:52AM +0100, David Chisnall wrote:
> On 29 May 2013, at 07:57, Andriy Gapon wrote:
>
> > In fact, I am of opinion that while such bugs exist gcc should be crowned
> > back
> > as a default compiler.
>
> Seriously? Your show stopper bug is that, very occasionally, c
On Fri, Aug 23, 2013 at 03:02:18PM +0400, Boris Samorodov wrote:
> 23.08.2013 13:16, David Chisnall ??:
>
>> I have a patch that I intend to commit before the 10.0 code
>> slush that removes GCC and libstdc++ from the default build
>> on platforms where clang is the system compiler. We de
On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote:
>
> > And i found PR about clang and mplayer: ports/176272
> > This PR contains log with build error log.
>
> Please file clang bugs at http://llvm.org/bugs/
>
As if this is go
On Sun, Aug 25, 2013 at 11:08:57AM +0100, David Chisnall wrote:
> On 25 Aug 2013, at 00:06, Steve Kargl
> wrote:
>
> > On Sat, Aug 24, 2013 at 11:44:38PM +0100, David Chisnall wrote:
> >> On 24 Aug 2013, at 23:42, Slawa Olhovchenkov wrote:
> >>
> >&g
On Fri, Aug 30, 2013 at 06:38:41AM -0700, Tim Kientzle wrote:
>
> On 30 Aug 2013, at 08:56, Jonathan Anderson wrote:
>
> > ... then people wanting to compile the base system with gcc/g++ ...
>
>
> I'm still curious *why* some people want this?
>
Buildworld completes in 1/4th the amount of ti
On Fri, Aug 30, 2013 at 08:33:21AM +0100, David Chisnall wrote:
> On 29 Aug 2013, at 18:44, John Baldwin wrote:
>
> > default every time, that we're telling people not to use, won't help with
> > that...
> >
> > This is your worst argument as clang is known to take far longer than GCC
> > to bu
It appears that clang developers have chosen the naive
complex division algorithm, and it does not matter whether
one turns CX_LIMITED_RANGE on or off. This means that
if one uses clang with complex types, one must be careful
with the range of values allowed in complex division. In
other words,
On Thu, Aug 28, 2014 at 07:02:55PM +0200, Ed Schouten wrote:
>
> small number of patches to build with this flag, I am also going to
> add -Wthread-safety to WARNS=6, to make sure it won't regress. I'm
> also planning on MFC'ing at least the changes to , so it
> is at least possible to write porta
On Sat, Aug 30, 2014 at 07:33:27AM +0200, Ed Schouten wrote:
>
> On 28 August 2014 19:34, Ed Schouten wrote:
> > My gut feeling is that impact is minimal. Buildworlds seem to take
> > approximately the same time, mainly because we don't have that many
> > annotated objects/functions/expressions.
What's the current status for running clang on sparc64?
In particular, flame.freebsd.org is running 10.1-PRERELEASE
compiled with gcc 4.2.1. Any chance that clanf can be
made available on flame?
--
Steve
___
freebsd-toolchain@freebsd.org mailing list
h
On Sat, Sep 13, 2014 at 10:23:22AM +0200, Roman Divacky wrote:
> On Thu, Sep 11, 2014 at 05:04:06PM -0700, Steve Kargl wrote:
> > What's the current status for running clang on sparc64?
>
> Last time we played with this (february?) it was able to compile
> a seemingly wo
#include
#include
int
main(void)
{
uint16_t i;
i = 0x3ff0+63; printf("%x\n", i);
i = 0x3ff1+63; printf("%x\n", i);
i = 0x3ff2+63; printf("%x\n", i);
i = 0x3ff3+63; printf("%x\n", i);
i = 0x3ff4+63; printf("%x\n", i);
i = 0x3ff4+63; printf("
On Sun, Sep 21, 2014 at 06:38:48PM -0700, Rui Paulo wrote:
> On Sep 21, 2014, at 18:19, Steve Kargl
> wrote:
> >
> > #include
> > #include
> >
> > int
> > main(void)
> > {
> > uint16_t i;
> > i = 0x3ff0+63; printf(&qu
On Mon, Sep 22, 2014 at 08:46:07AM +0300, Andriy Gapon wrote:
> On 22/09/2014 05:20, Rui Paulo wrote:
> > On Sep 21, 2014, at 18:48, Steve Kargl
> > wrote:
> >> On Sun, Sep 21, 2014 at 06:38:48PM -0700, Rui Paulo wrote:
> >>> On Sep 21, 2014,
On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote:
> ===> lib/libdpv (depend)
> rm -f .depend
> CC='cc ' mkdep -f .depend -a-I/usr/src/lib/libdpv -std=gnu99
> /usr/src/lib
> /libdpv/dialog_util.c /usr/src/lib/libdpv/dialogrc.c
> /usr/src/lib/libdpv/dprompt
> c /usr/src/lib/libdpv/dpv.c
If anyone is interesting fixing FreeBSD's C compiler, it
would be appreciated.
% cat foo.c
#include
#include
void
foo(int i)
{
if (i < 0)
goto whoops;
if (i == 0)
printf("foo\n");
if (i > 0)
goto corrupt;
return;
whoops:
printf("whoops\n");
return
corr
Consider this small piece of code:
#include
#include
float
foo()
{
static const volatile float tiny = 1.e-30f;
return (tiny * tiny);
}
int
main(void)
{
float x;
feclearexcept(FE_ALL_EXCEPT);
x = foo();
if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: ");
pri
On Sun, Mar 13, 2016 at 09:03:57PM +0100, Dimitry Andric wrote:
> On 13 Mar 2016, at 19:25, Steve Kargl
> wrote:
> >
> > Consider this small piece of code:
> >
> > #include
> > #include
> >
> > float
> > foo()
> > {
> >
On Mon, Mar 14, 2016 at 01:02:20AM +0100, Dimitry Andric wrote:
> On 13 Mar 2016, at 21:10, Steve Kargl
> wrote:
> > Thanks for the quick reply. But, it must be using an 80-bit
> > extended double instead of a double for storage. This variation
> >
> > #inclu
On Mon, Mar 14, 2016 at 01:02:20AM +0100, Dimitry Andric wrote:
>
> $ gcc -O overflow-iter.c -o overflow-iter-gcc -lm
> $ ./overflow-iter-gcc
> FE_OVERFLOW: x = inf after 1024 iterations
> $ gcc -O2 overflow-iter.c -o overflow-iter-gcc -lm
> $ ./overflow-iter-gcc
> FE_OVERFLOW: x = inf after 16384
On Mon, Mar 14, 2016 at 08:23:33PM +0100, Dimitry Andric wrote:
>
> Maybe this is a usable workaround for libm.
>
Thanks for looking into this. I just read the audit
trail at llvm.org. Searching the clang user manual
turns up
The support for standard C in clang is feature-complete
excep
On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote:
> On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote:
> >
> > FreeBSD-ports could avoid libquadmath issues by building gcc
> > without it. See --without-libquadmath or --without-quadmath (I
> > don&#
On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote:
> On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote:
> >
> > Freebsd-ports could also use a wrapper:
> > % cat ~/bin/gfc7
> > #! /bin/sh
> > DIR=`id -P sgk | sed 's/\:/\
On Wed, Aug 17, 2016 at 06:12:51PM -0400, Diane Bruce wrote:
> On Wed, Aug 17, 2016 at 02:17:10PM -0700, Steve Kargl wrote:
> > On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote:
> > > On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote:
> > > >
&g
On Thu, Aug 18, 2016 at 02:48:28PM +0200, Dimitry Andric wrote:
> On 18 Aug 2016, at 11:15, Tijl Coosemans wrote:
> >
> > On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl
> > wrote:
> ...
> >> % ldconfig -r | grep libgcc
> >>6:-lgcc_s.1 =>
On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:
> >
> > For example, on one of my systems, I now have these:
> >
> > /usr/local/lib/gcc47/libgcc_s.so.1
> > /usr/local/lib/gcc48/libgcc_s.so.1
> > /usr/local/lib/gcc49/libgcc_s.so.1
> > /usr/local/lib/gcc5/libgcc_s.so.1
> > /usr/loca
On Thu, Aug 18, 2016 at 07:58:01PM -0400, Diane Bruce wrote:
> On Thu, Aug 18, 2016 at 04:50:49PM -0700, Steve Kargl wrote:
> > On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote:
> > > >
> > > > For example, on one of my systems, I now have th
% which cpp
/usr/bin/cpp
troutmask:kargl[408] cpp --version
FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM
4.0.0)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
troutmask:kargl[409] cpp --help |grep trad
-traditional-cppEnable so
On Sat, May 20, 2017 at 11:39:14AM -0600, Ian Lepore wrote:
> On Fri, 2017-05-19 at 17:07 -0700, Steve Kargl wrote:
> > % which cpp
> > /usr/bin/cpp
> > troutmask:kargl[408] cpp --version
> > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on
> &g
On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
>
> On Nov 2, 2017, at 15:44, Mark Millard wrote:
>
> >> Author: bdrewery
> >> Date: Thu Nov 2 22:23:00 2017
> >> New Revision: 325347
> >> URL:
> >> https://svnweb.freebsd.org/changeset/base/325347
> >>
> >>
> >> Log:
> >> Somet
On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
>
>
> > On Nov 2, 2017, at 18:49, Steve Kargl
> > wrote:
> >
> >> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
> >>
> >> On Nov 2, 2017, at 15:44, Mark Millar
On Thu, Nov 02, 2017 at 07:41:21PM -0700, Bryan Drewery wrote:
>
> Are you accusing me of lying?
>
Nope. I'm stating the obvious. If you are using
META_MODE and you do "make buildwould" that is
equivalent to "make -DNO_CLEAN buildworld", which
means you did not rebuild the *world*.
When I s
When building gcc file gcc/config/freebsd.c contains
#define TARGET_LIBC_HAS_FUNCTION no_c99_libc_has_function
In targhook.c, one finds
/* By default we assume that c99 functions are present at the runtime,
but sincos is not. */
bool
default_libc_has_function (enum function_class fn_class)
{
On Thu, Jan 31, 2019 at 09:32:11AM -0700, Warner Losh wrote:
> On Wed, Jan 30, 2019 at 11:33 PM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
> > Should/can TARGET_LIBC_HAS_FUNCTION be updated to at least
> > default_libc_has_function? More importantly
I have
% uname -a
FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r343477 MOBILE i386
% dmesg | more
...
FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM
7.0.1)
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CP
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:
> On 10 Feb 2019, at 06:00, Steve Kargl
> wrote:
> >
> > I have
> >
> > % uname -a
> > FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r343477 MOBILE i386
> >
> > % dmesg | mo
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:
> On 10 Feb 2019, at 06:00, Steve Kargl
> wrote:
> >
> > If I add 'CFLAGS+=-march=native -mtune=native', I can build
> > world and kernel without a problem. If I try to build
> >
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:
> On 10 Feb 2019, at 06:00, Steve Kargl
> wrote:
> >
> > If I add 'CFLAGS+=-march=native -mtune=native', I can build
> > world and kernel without a problem. If I try to build
> >
On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:
> On 10 Feb 2019, at 06:00, Steve Kargl
> wrote:
>
> How did you arrive at the conclusion that this has anything to do with
> the specific compiler? From these errors, I think it is more likely
> someth
On Sun, Feb 10, 2019 at 11:13:09AM -0800, Mark Millard wrote:
>
> On 2019-Feb-10, at 10:46, Steve Kargl
> wrote:
> >
> > On Sun, Feb 10, 2019 at 12:03:55PM +0100, Dimitry Andric wrote:
> >> On 10 Feb 2019, at 06:00, Steve Kargl >> troutmask.apl.washingto
Having set CFLAGS+=-march=native -mtune=native and trying to
force qt5-gui configure with -sse2 option, I have a config.summary
that contains (my in-line comments ***)
Build type: freebsd-clang (i386, CPU features: )
*** What? ***
Compiler: clang 7.0.1
Configuration: compile_examples largefi
All,
There seems to an optimization bug with clang on
% uname -a
FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386
IOW, if you do numerica work on i386, you may want to check your
results.
The program demonstrating the issue is at the end of this email.
gcc8 --version
gcc8
On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
> All,
>
> There seems to an optimization bug with clang on
>
> % uname -a
> FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386
>
> IOW, if you do numerica work on i386, you may want
On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
>
> cc -O -fno-builtin -o z a.c -lm && ./z
> cc -O2 -fno-builtin -o z a.c -lm && ./z
> cc -O3 -fno-builtin -o z a.c -lm && ./z
>
>
> Max ULP: 23.061242
> Count: 39 (# of ULP tha
On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
>
> gcc8 --version
> gcc8 (FreeBSD Ports Collection) 8.3.0
>
> gcc8 -fno-builtin -o z a.c -lm && ./z
> gcc8 -O -fno-builtin -o z a.c -lm && ./z
> gcc8 -O2 -fno-builtin -o z a.c -lm && ./
On Wed, Mar 13, 2019 at 04:41:51PM +0100, Hans Petter Selasky wrote:
> On 3/13/19 4:16 PM, Steve Kargl wrote:
> > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
> >>
> >> gcc8 --version
> >> gcc8 (FreeBSD Ports Collection) 8.3.0
> >&g
On Wed, Mar 13, 2019 at 04:56:26PM +0100, Hans Petter Selasky wrote:
> On 3/13/19 4:50 PM, Steve Kargl wrote:
> > Using sin() and cos() directly as in
> >
> > /* Double precision csinh() without using C's double complex.s */
> > void
> > dp_csinh(doub
On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote:
> On 3/13/19 8:16 AM, Steve Kargl wrote:
> > On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
> >>
> >> gcc8 --version
> >> gcc8 (FreeBSD Ports Collection) 8.3.0
> >>
> >&
On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote:
> On 3/13/19 9:40 AM, Steve Kargl wrote:
> > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote:
> >> On 3/13/19 8:16 AM, Steve Kargl wrote:
> >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve K
On Wed, Mar 13, 2019 at 10:40:28AM -0700, Conrad Meyer wrote:
> Hi John,
>
> On Wed, Mar 13, 2019 at 10:17 AM John Baldwin wrote:
> > One issue I'm aware of is that clang does not have any support for the
> > special arrangement FreeBSD/i386 uses where it uses different precision
> > for register
On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote:
> On 3/13/19 9:40 AM, Steve Kargl wrote:
> > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote:
> >> On 3/13/19 8:16 AM, Steve Kargl wrote:
> >>> On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve K
On Wed, Mar 13, 2019 at 02:24:55PM -0700, Steve Kargl wrote:
> On Wed, Mar 13, 2019 at 10:16:12AM -0700, John Baldwin wrote:
> > On 3/13/19 9:40 AM, Steve Kargl wrote:
> > > On Wed, Mar 13, 2019 at 09:32:57AM -0700, John Baldwin wrote:
> > >> On 3/13/19 8:16 AM, Ste
On Wed, Mar 13, 2019 at 11:30:07PM -0700, Steve Kargl wrote:
>
> Spent a couple hours wandering in contrib/llvm. Have no idea
> how to fix clang to actually work on i386/387. Any ideas
> would be welcomed.
>
> AFAICT, all libm float routines need to be modified to con
On Fri, Mar 15, 2019 at 05:50:37AM +1100, Peter Jeremy wrote:
> On 2019-Mar-13 23:30:07 -0700, Steve Kargl
> wrote:
> >AFAICT, all libm float routines need to be modified to conditional
> >include ieeefp.h and call fpsetprec(FP_PD). This will work around
> >issues is FP
On Tue, Mar 12, 2019 at 07:45:41PM -0700, Steve Kargl wrote:
> All,
>
> There seems to an optimization bug with clang on
>
> % uname -a
> FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r344653 MOBILE i386
>
> IOW, if you do numerica work on i386, you may want to che
TL;DR summary: clang is broken for numerical on i686 FreeBSD.
% uname -a
FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r361834M:
Fri Jun 5 08:49:26 PDT 2020 obj/usr/src/i386.i386/sys/MOBILE i386
% which clang
/usr/bin/clang
% clang --version
FreeBSD clang version 10.0.1 (g...@github.com:
On Mon, Sep 07, 2020 at 07:10:02PM -0700, Steve Kargl wrote:
>
> Interval tested for exp2f: [1,8]
>ulp <= 0.5: 0.056% 14072 | 0.056% 14072
> 0.5 < ulp < 0.6: 0.000% 8 | 0.056% 14080
> 3.0 < ulp < 0.0: 99.944% 25151744
On Mon, Sep 07, 2020 at 07:55:13PM -0700, Steve Kargl wrote:
> On Mon, Sep 07, 2020 at 07:10:02PM -0700, Steve Kargl wrote:
> >
> > Interval tested for exp2f: [1,8]
> >ulp <= 0.5: 0.056% 14072 | 0.056% 14072
> > 0.5 < ulp < 0.6: 0.000%
On Tue, Sep 08, 2020 at 09:11:50PM +0200, Dimitry Andric wrote:
> On 8 Sep 2020, at 19:47, Steve Kargl
> wrote:
> >
> > I think I've found the problem, and it appears to be
> > due to a change byt Openlibm developers to the file
> > math_private.h copi
85 matches
Mail list logo
