date:20120528

On 05/27/2012 07:05, Dmitry Marakasov wrote:
> Hi!
> 
> I'm running a little pet project of improving completeness of
> tools/build/mk/OptionalObsoleteFiles.inc file and thus delete-old*
> targets with regard to all possible WITHOUT_* knobs.
> 
> E.g. when WITHOUT_foo is defined in src.conf, make delete-old should
> remove related files completely, to make a system look exactly like
> it's world was installed with that knob set.
> 
> First of all, an automatic script to check for leftovers after
> delete-old for all possible knobs is available from [2]. Feel free
> to run in on different architectures and FreeBSD branches; I'm
> currently running it on amd64. I also think that it should be run
> during preparation of each FreeBSD release.
> 
> There are some questions I'd like to discuss.
> 
> 1) named config file var/named/etc/namedb/named.conf was intentionally
> left out from OptionalObsoleteFiles.inc, so I did the same for other
> configs which may be changed by users.

That's one reason to omit it. Another is that the bind ports use the
same set of config files.


-- 

This .signature sanitized for your protection
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Repeated build failures in expr due to yyparse

2012-05-28 Thread Bjoern A. Zeeb

On 28. May 2012, at 08:42 , Konstantin Belousov wrote:

> On Sun, May 27, 2012 at 11:14:40PM +, Bjoern A. Zeeb wrote:
>> Running a make -s -j5 buildworld;  cleaned the entire obj tree meanwhile.
>> Builds are running on a slightly older HEAD thought with an updated libc
>> and some headers.
>> 
>> I can reproduce this all the time.  Buildworld at this stage should be
>> self-contained, right?  So why is it failing?
> Can it be because you broke your system by 'updating libc and some headers' ?
> The cross-tools build is conditional on the host system OSRELDATE (see
> OSRELDATE and BOOTSTRAPPING story in src/Makefile.inc1). The new yacc
> bootstrap build is enabled only if your __FreeBSD_version is less then
> 113. So if the host yacc is older (before recent import), but system
> headers identify the host as newer, you get an error.
> 
> Why did you 'updated libc and some headers' at all ?

I needed to update headers to be able to recompile ifconfig after some
additions; then got bitten by that not compiling as libc didn't include
the symbol for _ThreadRuneLocale yet but the header was already picked up.
So had to re-do libc as well.

Doing a make clean cleandepend obj depend all install for expr and yacc
has helped and re-starting buildworld succeeded.

So /usr/include/osrealdate.h being updated was the culprit most likely.
*grml* fragile stuff.  I can see the point though.

/bz

-- 
Bjoern A. Zeeb You have to have visions!
   It does not matter how good you are. It matters what good you do!

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OptionalObsoleteFiles.inc completeness

On 2012-May-27 18:05:41 +0400, Dmitry Marakasov  wrote:
>2) Is this ok to backport the list from current to stable branches? Pro
>- it's really simple, con - it will contain files never installed with
>this (old) branch.

Another con:  "make delete-old" on -current takes about 2 orders of
magnitude longer to run than on 8.x.  I would prefer to see some
effort put into speeding it up before it was backported.

-- 
Peter Jeremy

pgptJtyQZ4Lv8.pgp
Description: PGP signature

Re: Use of C99 extra long double math functions after r236148

2012-05-28 Thread Rainer Hurling

On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 05:35, Rainer Hurling wrote:

First I should note that I am by no means an expert in C / C++ or C99
standards. So my comments are only on a level of someone who is using
FreeBSD for scientific purposes like GIS and math applications and who
is the maintainer of some scientific ports (like math/saga).

Yesterday r236148 (Allow inclusion of libc++ to work after including
math.h) was comitted to head, many thanks.

Does this mean, that extra long double functions like acoshl, expm1l or log1pl are now
"really implemented"? As far as I understand, they had only been declared
before?

They are still not implemented. The header in libc++ provides wrappers around
these functions for C++, but if they are not declared then the compiler throws an error. Now
there is a linker error if they are used, but if they are not used then it works irrespective of
whether you just include or do undefined things like include first.

Ok, that's what I had supposed. Because the main difference between
r236147 and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest
is more a type of binning?

If this is right, are they usable on a recent CURRENT, built with gcc42 (system
compiler), by ports which use gcc46 (not clang)? If not, are there any plans to
implement these functions in the near future?

I think they're one of the last bits of C99 / C11 that anyone actually cares
about (C11 unicode support being another), so they'll probably get done at some
point, but doing them correctly is nontrivial, except on platforms where double
and long double are the same.

Yes, I agree. These outstanding long double math functions (like log1pl)
and better unicode support are really needed for some important third
party projects like R or SAGA GIS.

In the past I have read several times discussions about the correctness
of long double functions on FreeBSD. Some drafts have been dismissed
because of there inaccuracy in special cases. Also was discussed to get
missing libm routines from NetBSD [1]. It appears as if we have to wait
some more time ...

The use of C99 extra long double functions would be of interest for example for
programs like math/R, especially its upcoming releases.

I would be very wary of anything that depends on long double. The C spec makes
no constraints on the range of float, double, or long double, but by convention
on most platforms float is an IEEE 754 32-bit floating point value and double
is 64-bit. No such conventions apply to long doubles and I know of (widely
deployed) platforms where they are 64 bits, 80 bits and 128 bits, respectively.
I believe on PowerPC FreeBSD actually gets it wrong and uses 64 bits even
though the platform ABI spec recommends using 128 bits. x86 uses 80-bit x87
values (although sizeof(long double) may be 16 because they have some padding
bytes in memory). If your program is tolerant of a potential variation in
precision between 64 bits and 128 bits, then it is probably tolerant of just
using doubles.

Yes, I think in most cases math/R is tolerant enough of just using
doubles. But in the near future they plan to implement much more of the
C99 stuff and their tolerance to offer workarounds for FreeBSD shrinks
from release to release [2]. So these problems will increase :-(

Many thanks for your fast und well explained answer, I really appreciate it.

Rainer

David

[1]
http://lists.freebsd.org/pipermail/freebsd-standards/2011-February/002119.html

[2] https://stat.ethz.ch/pipermail/r-devel/2012-May/064128.html

And some more places I found interesting about C99 and FreeBSD

[3] http://www.freebsd.org/projects/c99/index.html

[4] http://wiki.freebsd.org/MissingMathStuff

[5] http://marc.info/?l=freebsd-standards&m=123158761305427

[6]
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/028030.html

[7]
http://www.koders.com/c/fid164FD2F50C9AAA63119A641875824455B3AE6B55.aspx?s=log1pl.c

[8] http://www.mail-archive.com/bug-gnulib@gnu.org/msg26571.html

[9] http://leaf.dragonflybsd.org/mailarchive/commits/2011-12/msg00190.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

2012-05-28 Thread David Chisnall

On 28 May 2012, at 13:30, Rainer Hurling wrote:

> On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:
>> On 28 May 2012, at 05:35, Rainer Hurling wrote:
> 
> Ok, that's what I had supposed. Because the main difference between r236147 
> and r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a 
> type of binning?

Yes, it's just about making libc++'s cmath header compile, nothing more.  

> Yes, I agree. These outstanding long double math functions (like log1pl) and 
> better unicode support are really needed for some important third party 
> projects like R or SAGA GIS.

I very much doubt that anything is using the C11 unicode stuff yet, since no 
compiler or libc currently supports it...

> In the past I have read several times discussions about the correctness of 
> long double functions on FreeBSD. Some drafts have been dismissed because of 
> there inaccuracy in special cases. Also was discussed to get missing libm 
> routines from NetBSD [1]. It appears as if we have to wait some more time ...

I thought we did pull in some NetBSD libm stuff recently.  Not sure what the 
status of that is, you'd need to check with das@.

> Yes, I think in most cases math/R is tolerant enough of just using doubles. 
> But in the near future they plan to implement much more of the C99 stuff and 
> their tolerance to offer workarounds for FreeBSD shrinks from release to 
> release [2]. So these problems will increase :-(

Reading that email, it seems that they would prefer a function that exists and 
returns the wrong result to one that does not exist.  If this is really the 
attitude of the developers of R, then I shall make absolutely certain that I 
avoid using R for anything where I actually care about the results, and would 
strongly encourage everyone else to do the same.  

In general, (sane) people use the long double versions because they need the 
extra precision and care about the result.  We could easily implement the long 
double versions now as toy versions that just called the double versions, but 
that would upset a lot of people who actually care about accuracy, who are the 
main target audience for these functions.  

David___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 9-stable regression: 'cbb0: Warning: Bus reset timeout'

2012-05-28 Thread Lars Engels

On Fri, May 25, 2012 at 09:52:15AM -0700, Adrian Chadd wrote:
> To respond to my own mail again:
> 
> * should the cardbus slot peripherals be detached and reattached upon
> resume? Or should it be just suspend/resumed?
> * here's what I see during suspend:
> 
> 
> wlan1: link state changed to DOWN
> [100741]: ieee80211_reset_bss: iv_bss=0xc969e000, new iv_bss=0xc96a5000
> [100480] cbb0: Opening memory:
> [100480] ath1: detached
> pci0:21:0:0: Transition from D0 to D2
> [100480] pci21: failed to set ACPI power state D2 on
> \\_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER
> [100480] vga0: saving 4612 bytes of video state
> [100480] vga0: saving color palette
> [100480] pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP0:
> AE_BAD_PARAMETER
> [100480] pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP1:
> AE_BAD_PARAMETER
> [100480] pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP2:
> AE_BAD_PARAMETER
> [100480] pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP3:
> AE_BAD_PARAMETER
> 
> .. would someone with some ACPI clue please help me figure out how
> broken the ACPI code in my T60 BIOS is? :)

I am also seeing this on my Thinkpad X200 running 10-CURRENT amd64:
pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP0: AE_BAD_PARAMETER
pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP1: AE_BAD_PARAMETER
pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP3: AE_BAD_PARAMETER
CPU0: local APIC error 0x40



pgpYyZNyHj5VO.pgp
Description: PGP signature

Re: New Xorg: graphics/dri: fails to compile with CLANG: nouveau_array.c:49:16: error: illegal storage class on function, *extract_u = EXTRACT(char, unsigned, 1);

2012-05-28 Thread Volodymyr Kostyrko


Dimitry Andric wrote:

On 2012-04-28 13:12, Volodymyr Kostyrko wrote:

O. Hartmann wrote:

Is there in "official" way to get this fixed with CLANG? I see that
files folder in graphics/dri is missing, so none of the  fixes for both
the faulty source files


I think the patch should go to graphics/libGL.

cd /usr/ports/graphics/libGL/files
fetch -rao -
'http://cgit.freedesktop.org/mesa/mesa/patch/?id=4aa1ac5fe94b5696095229ee3568bf4fa7cfed95'
| sed -e 's|^--- a/src|--- src|' -e 's|^+++ b/src|+++ src|'>  patch-nouveau

Should do.


Please try this patch (lightly tested):

http://www.andric.com/freebsd/clang/clangports-graphics-libGL-3.diff


Works for me. Could this one be commited? It looks better then my quick 
hack.


--
Sphinx of black quartz judge my vow.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

2012-05-28 Thread Rainer Hurling


On 28.05.2012 14:49 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 13:30, Rainer Hurling wrote:


On 28.05.2012 10:41 (UTC+1), David Chisnall wrote:

On 28 May 2012, at 05:35, Rainer Hurling wrote:


Ok, that's what I had supposed. Because the main difference between r236147 and 
r2136148 seems to be the define of _MATH_EXTRA_H_, the rest is more a type of 
binning?


Yes, it's just about making libc++'s cmath header compile, nothing more.


I see, thanks.


Yes, I agree. These outstanding long double math functions (like log1pl) and 
better unicode support are really needed for some important third party 
projects like R or SAGA GIS.


I very much doubt that anything is using the C11 unicode stuff yet, since no 
compiler or libc currently supports it...


Of course you are right with C11 unicode stuff.

I thougt more about my actual problems to get the right charset 
conversions between different apps, i.e. qgis <-> wxgtk29 <-> saga gis. 
Or using Gnome apps (utf8) on windowmaker using ISO8859-15. But this is 
OT here, sorry.



In the past I have read several times discussions about the correctness of long 
double functions on FreeBSD. Some drafts have been dismissed because of there 
inaccuracy in special cases. Also was discussed to get missing libm routines 
from NetBSD [1]. It appears as if we have to wait some more time ...


I thought we did pull in some NetBSD libm stuff recently.  Not sure what the 
status of that is, you'd need to check with das@.


I am not aware of it and will have a look. But this did not implement 
the missing long double functions.



Yes, I think in most cases math/R is tolerant enough of just using doubles. But 
in the near future they plan to implement much more of the C99 stuff and their 
tolerance to offer workarounds for FreeBSD shrinks from release to release [2]. 
So these problems will increase :-(


Reading that email, it seems that they would prefer a function that exists and 
returns the wrong result to one that does not exist.  If this is really the 
attitude of the developers of R, then I shall make absolutely certain that I 
avoid using R for anything where I actually care about the results, and would 
strongly encourage everyone else to do the same.


This was a statement of just one (though not unimportant) person from 
the R Core team. I don't think that this is the only view of R Core 
developers. On the other hand he is the person, who actually did most of 
the stuff within R for years now to circumvent the problems running on 
FreeBSD.



In general, (sane) people use the long double versions because they need the 
extra precision and care about the result.  We could easily implement the long 
double versions now as toy versions that just called the double versions, but 
that would upset a lot of people who actually care about accuracy, who are the 
main target audience for these functions.


It seems to be a general trend (outside of FreeBSD) to implement more 
and more stuff at the cost of quality. I am certain that for many 
FreeBSD users accuracy is more important than completeness, especially 
for scientists.


Nevertheless this policy brings some problems in the real world ;-)

Thanks again for your thoughts,
Rainer


David

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

One thing that could be done is to have a "math/cephes" port that adds 
the extra C99 math functions.  This is already done in the math/sage 
port, using a rather clever patch due to Peter Jeremy, that applies to 
the cephes code.


What it would do is to create a /usr/local/lib/libm.so that would 
provide the extra functions not currently included in /lib/libm.so, and 
then link in /lib/libm.so as well.  It would also create its own 
/usr/local/include/math.h and /usr/local/include/complex.h as well.


What do you guys think?  Do you want someone to start experimenting with 
this idea?  I could do it, but probably not for a little while.


Stephen

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OptionalObsoleteFiles.inc completeness

2012-05-28 Thread Jakub Lach

I'm pro improving completeness, as most people are
really surprised when after setting WITHOUT* they
are left with old cruft from first install, what's more
important- it's getting left "as is" with all possible
(security) bugs.

Just be careful, as after recent expansion it looked 
here like setting WITHOUT_GCC= was breaking 
gcc47 from ports also, but couldn't really reproduce
it reliably.

--
View this message in context: 
http://freebsd.1045724.n5.nabble.com/OptionalObsoleteFiles-inc-completeness-tp5712560p5712976.html
Sent from the freebsd-current mailing list archive at Nabble.com.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Kernel builds failing with lots of "failed to retrieve array bounds" errors

2012-05-28 Thread Dimitry Andric

On 2012-05-24 22:50, Sevan / Venture37 wrote:
> On 24/05/2012 20:21, Dimitry Andric wrote:
>> I've seen these too, and it seems clang produces debug info which
>> ctfconvert can't handle, for some reason.  However, in my case, the
>> kernel build doesn't abort at all, it continues and all the object files
>> seem to work just fine.
> 
> Updated to r235926 & kernel build completed successfully.

Note, in r236149 I have pulled in a change from upstream clang, which
should fix the root cause of the "failed to retrieve array bounds"
messages.

For flexible array members (e.g. arrays at the end of a struct with no
specified size), clang didn't produce correct debug information.  This
confused ctfconvert, causing it to bail out.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OptionalObsoleteFiles.inc completeness

* Doug Barton (do...@freebsd.org) wrote:

> > I'm running a little pet project of improving completeness of
> > tools/build/mk/OptionalObsoleteFiles.inc file and thus delete-old*
> > targets with regard to all possible WITHOUT_* knobs.
> > 
> > E.g. when WITHOUT_foo is defined in src.conf, make delete-old should
> > remove related files completely, to make a system look exactly like
> > it's world was installed with that knob set.
> > 
> > First of all, an automatic script to check for leftovers after
> > delete-old for all possible knobs is available from [2]. Feel free
> > to run in on different architectures and FreeBSD branches; I'm
> > currently running it on amd64. I also think that it should be run
> > during preparation of each FreeBSD release.
> > 
> > There are some questions I'd like to discuss.
> > 
> > 1) named config file var/named/etc/namedb/named.conf was intentionally
> > left out from OptionalObsoleteFiles.inc, so I did the same for other
> > configs which may be changed by users.
> 
> That's one reason to omit it. Another is that the bind ports use the
> same set of config files.

But putting in under OLD_CONFIGS+= would still be ok?

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OptionalObsoleteFiles.inc completeness

* Peter Jeremy (pe...@rulingia.com) wrote:

> >2) Is this ok to backport the list from current to stable branches? Pro
> >- it's really simple, con - it will contain files never installed with
> >this (old) branch.
> 
> Another con:  "make delete-old" on -current takes about 2 orders of
> magnitude longer to run than on 8.x.  I would prefer to see some
> effort put into speeding it up before it was backported.

Is that really a reason while it is still under 4 seconds and is not
usually run more often than updates (which take minutes if not hours)?

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Repeated build failures in expr due to yyparse

2012-05-28 Thread Dimitry Andric

On 2012-05-28 11:21, Bjoern A. Zeeb wrote:
...
> I needed to update headers to be able to recompile ifconfig after some
> additions; then got bitten by that not compiling as libc didn't include
> the symbol for _ThreadRuneLocale yet but the header was already picked up.
> So had to re-do libc as well.
> 
> Doing a make clean cleandepend obj depend all install for expr and yacc
> has helped and re-starting buildworld succeeded.
> 
> So /usr/include/osrealdate.h being updated was the culprit most likely.
> *grml* fragile stuff.  I can see the point though.

See also this thread by bapt:

  http://lists.freebsd.org/pipermail/freebsd-arch/2012-May/012592.html

Maybe a FORCE_BOOTSTRAP_ALL option would be nice. :)
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OptionalObsoleteFiles.inc completeness

On 05/28/2012 12:52, Dmitry Marakasov wrote:
> * Doug Barton (do...@freebsd.org) wrote:
> 
>>> I'm running a little pet project of improving completeness of
>>> tools/build/mk/OptionalObsoleteFiles.inc file and thus delete-old*
>>> targets with regard to all possible WITHOUT_* knobs.
>>>
>>> E.g. when WITHOUT_foo is defined in src.conf, make delete-old should
>>> remove related files completely, to make a system look exactly like
>>> it's world was installed with that knob set.
>>>
>>> First of all, an automatic script to check for leftovers after
>>> delete-old for all possible knobs is available from [2]. Feel free
>>> to run in on different architectures and FreeBSD branches; I'm
>>> currently running it on amd64. I also think that it should be run
>>> during preparation of each FreeBSD release.
>>>
>>> There are some questions I'd like to discuss.
>>>
>>> 1) named config file var/named/etc/namedb/named.conf was intentionally
>>> left out from OptionalObsoleteFiles.inc, so I did the same for other
>>> configs which may be changed by users.
>>
>> That's one reason to omit it. Another is that the bind ports use the
>> same set of config files.
> 
> But putting in under OLD_CONFIGS+= would still be ok?

I have no idea, I don't use the Obsolete stuff, don't like it, and have
said since the beginning that it's the totally wrong approach to this
issue. The numerous problems we've had with it ever since it was
introduced seem to bear me out. :)

My point is, until such time as we remove BIND from the base (or I add
the config files as a port) I do not want the named config files removed
from a user's system.

Thanks,

Doug

-- 

This .signature sanitized for your protection
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OptionalObsoleteFiles.inc completeness

On 2012-May-28 23:55:42 +0400, Dmitry Marakasov  wrote:
>* Peter Jeremy (pe...@rulingia.com) wrote:
>
>> >2) Is this ok to backport the list from current to stable branches? Pro
>> >- it's really simple, con - it will contain files never installed with
>> >this (old) branch.
>> 
>> Another con:  "make delete-old" on -current takes about 2 orders of
>> magnitude longer to run than on 8.x.  I would prefer to see some
>> effort put into speeding it up before it was backported.
>
>Is that really a reason while it is still under 4 seconds and is not
>usually run more often than updates (which take minutes if not hours)?

My experience is that it now takes about 2½ minutes on 10.x with warm
caches, compared to less than 1 second on 8.x.  For most of that time,
there's no output and there's no warning of the increased time.  I
actually wrote about the poor performance here a couple of weeks ago.

-- 
Peter Jeremy


pgpj1hAqZ4ktC.pgp
Description: PGP signature

Re: OptionalObsoleteFiles.inc completeness

2012-05-28 Thread Alexander Leidinger

On Mon, 28 May 2012 12:59:17 -0700 Doug Barton 
wrote:

> this issue. The numerous problems we've had with it ever since it was
> introduced seem to bear me out. :)

Can you list them? A missing obsolete file doesn't count.

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OptionalObsoleteFiles.inc completeness

2012-05-28 Thread Alexander Leidinger

On Tue, 29 May 2012 06:04:03 +1000 Peter Jeremy 
wrote:

> My experience is that it now takes about 2½ minutes on 10.x with warm
> caches, compared to less than 1 second on 8.x.  For most of that time,
> there's no output and there's no warning of the increased time.  I
> actually wrote about the poor performance here a couple of weeks ago.

One solution may be to remove some really old files. If we assume that
we only support updates to major version X from the last release of
major version X-1 we could maybe remove everything which was already
obsolete in major version X-1 (or X-2 if you want to play safe).

Bye,
Alexander.

-- 
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org   netchild @ FreeBSD.org  : PGP ID = 72077137
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OptionalObsoleteFiles.inc completeness

On 05/28/2012 13:23, Alexander Leidinger wrote:
> On Mon, 28 May 2012 12:59:17 -0700 Doug Barton 
> wrote:
> 
>> this issue. The numerous problems we've had with it ever since it was
>> introduced seem to bear me out. :)
> 
> Can you list them? A missing obsolete file doesn't count.

It doesn't catch things it needs to
It catches things it shouldn't
The current incarnation is painfully slow (so I've heard)
... and the biggest problem ...
It needs to be updated manually

Doug

-- 

This .signature sanitized for your protection
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
> One thing that could be done is to have a "math/cephes" port that adds 
> the extra C99 math functions.  This is already done in the math/sage 
> port, using a rather clever patch due to Peter Jeremy, that applies to 
> the cephes code.
> 
> What it would do is to create a /usr/local/lib/libm.so that would 
> provide the extra functions not currently included in /lib/libm.so, and 
> then link in /lib/libm.so as well.  It would also create its own 
> /usr/local/include/math.h and /usr/local/include/complex.h as well.
> 
> What do you guys think?  Do you want someone to start experimenting with 
> this idea?  I could do it, but probably not for a little while.
> 

This is a horrible, horrible, horrible idea.  Have you
looked at the cephes code, particularly the complex.h
functions?

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148


On 05/28/2012 03:31 PM, Steve Kargl wrote:

On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:

One thing that could be done is to have a "math/cephes" port that adds
the extra C99 math functions.  This is already done in the math/sage
port, using a rather clever patch due to Peter Jeremy, that applies to
the cephes code.

What it would do is to create a /usr/local/lib/libm.so that would
provide the extra functions not currently included in /lib/libm.so, and
then link in /lib/libm.so as well.  It would also create its own
/usr/local/include/math.h and /usr/local/include/complex.h as well.

What do you guys think?  Do you want someone to start experimenting with
this idea?  I could do it, but probably not for a little while.



This is a horrible, horrible, horrible idea.  Have you
looked at the cephes code, particularly the complex.h
functions?


I have only taken a very cursory look.  What should I specifically look 
for in seeing that the code is bad?


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith  
wrote:
>One thing that could be done is to have a "math/cephes" port that adds 
>the extra C99 math functions.  This is already done in the math/sage 
>port, using a rather clever patch due to Peter Jeremy, that applies to 
>the cephes code.
>
>What it would do is to create a /usr/local/lib/libm.so that would 
>provide the extra functions not currently included in /lib/libm.so, and 
>then link in /lib/libm.so as well.  It would also create its own 
>/usr/local/include/math.h and /usr/local/include/complex.h as well.

Basically, as long as the compiler searches /usr/local/{include,lib}
before the base include/lib then ,  and -lm give
the application a complete C99 math implementation by using base
functions where they exist and cephes functions where they don't.

The patch I wrote for sage can be found at
http://trac.sagemath.org/sage_trac/ticket/9543
If there's any interest, I could produce a port for this.

Another option would be to import cephes into base and use it to
provide the missing C99 functions.  Cephes includes copyright notices
but the closest I can find to a license is:
"   Some software in this archive may be from the book _Methods and
 Programs for Mathematical Functions_ (Prentice-Hall or Simon & Schuster
 International, 1989) or from the Cephes Mathematical Library, a
 commercial product. In either event, it is copyrighted by the author.
 What you see here may be used freely but it comes with no support or
 guarantee."

-- 
Peter Jeremy

pgpYmCz2gMd3i.pgp
Description: PGP signature

Re: Use of C99 extra long double math functions after r236148

On 2012-May-28 13:31:59 -0700, Steve Kargl  
wrote:
>On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
>> One thing that could be done is to have a "math/cephes" port that adds 
>> the extra C99 math functions.  This is already done in the math/sage 
>> port, using a rather clever patch due to Peter Jeremy, that applies to 
>> the cephes code.
...
>This is a horrible, horrible, horrible idea.  Have you
>looked at the cephes code, particularly the complex.h
>functions?

The cephes code is somewhat a mess layout-wise.  Algorithmetically,
it seems somewhat variable - some functions are implemented (hopefully
correctly) using semi-numerical techniques, whereas others just use
mathematical identities which will result in precision loss - though
most of the functions include accuracy information.

I agree it would be far preferable to have a properly validated C99
libm with all functions having maximum errors of a no more than a few
LSB over their complete domain, as well as correct support for signed
zeroes, infinities and signalling and non-signalling NaNs but that is
a non-trivial undertaking.

In the interim, how should FreeBSD handle apps that want a C99 libm?
1) Fail to build them
2) Provide possibly imperfect fallbacks for the unimplemented bits.

If someone (I don't have the expertise) wants to identify the cephes
functions that are sub-standard, we can include link-time warnings
(as done for eg gets(3)) when they are used.

-- 
Peter Jeremy

pgpcG5SKNkFm9.pgp
Description: PGP signature

Re: OptionalObsoleteFiles.inc completeness

* Doug Barton (do...@freebsd.org) wrote:

> >> this issue. The numerous problems we've had with it ever since it was
> >> introduced seem to bear me out. :)
> > 
> > Can you list them? A missing obsolete file doesn't count.
> 
> It doesn't catch things it needs to
> It catches things it shouldn't
> The current incarnation is painfully slow (so I've heard)
>   ... and the biggest problem ...
> It needs to be updated manually

Pretty true. Still I'd like to fix what we have now, than not to
have a useful feature.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:
> On 05/28/2012 03:31 PM, Steve Kargl wrote:
> >On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
> >>One thing that could be done is to have a "math/cephes" port that adds
> >>the extra C99 math functions.  This is already done in the math/sage
> >>port, using a rather clever patch due to Peter Jeremy, that applies to
> >>the cephes code.
> >>
> >>What it would do is to create a /usr/local/lib/libm.so that would
> >>provide the extra functions not currently included in /lib/libm.so, and
> >>then link in /lib/libm.so as well.  It would also create its own
> >>/usr/local/include/math.h and /usr/local/include/complex.h as well.
> >>
> >>What do you guys think?  Do you want someone to start experimenting with
> >>this idea?  I could do it, but probably not for a little while.
> >>
> >
> >This is a horrible, horrible, horrible idea.  Have you
> >looked at the cephes code, particularly the complex.h
> >functions?
> 
> I have only taken a very cursory look.  What should I specifically look 
> for in seeing that the code is bad?

Well, to start with, the extra C99 math functions that
are missing in libm include a few for the long double type
and many (if not most) of the complex functions for any
type.  Cephes at best will give you float, double, and ld80, but
not ld128 versions of the functions.  Then, there is fun little fact
that neither (base) gcc nor clang nor gcc less than 4.6 does
complex arithematic correctly; so, one needs to jump through
hoops to get the correct answer (See Annex G in n1256.pdf).
One item of particular importance in Annex G is the behavior
of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
NaN.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OptionalObsoleteFiles.inc completeness

* Peter Jeremy (pe...@rulingia.com) wrote:

> >> >2) Is this ok to backport the list from current to stable branches? Pro
> >> >- it's really simple, con - it will contain files never installed with
> >> >this (old) branch.
> >> 
> >> Another con:  "make delete-old" on -current takes about 2 orders of
> >> magnitude longer to run than on 8.x.  I would prefer to see some
> >> effort put into speeding it up before it was backported.
> >
> >Is that really a reason while it is still under 4 seconds and is not
> >usually run more often than updates (which take minutes if not hours)?
> 
> My experience is that it now takes about 2½ minutes on 10.x with warm
> caches, compared to less than 1 second on 8.x.

Now = after applying my patch or after changing system? Which knobs
were enabled?

OptionalObsoleteFiles.inc is 3x larger after the patch - it's expected
for things to become 3x slower, but definitely not 250x.

> For most of that time, there's no output and there's no warning
> of the increased time. I actually wrote about the poor performance
> here a couple of weeks ago.

Then you should try to profile it - my script basically runs
delete-old delete-old-libs for every knob (131 of them), and it
hadn't taken more than 4 seconds even once.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

On Tue, May 29, 2012 at 08:04:36AM +1000, Peter Jeremy wrote:
> On 2012-May-28 13:31:59 -0700, Steve Kargl 
>  wrote:
> >On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
> >> One thing that could be done is to have a "math/cephes" port that adds 
> >> the extra C99 math functions.  This is already done in the math/sage 
> >> port, using a rather clever patch due to Peter Jeremy, that applies to 
> >> the cephes code.
> ...
> >This is a horrible, horrible, horrible idea.  Have you
> >looked at the cephes code, particularly the complex.h
> >functions?
> 
> The cephes code is somewhat a mess layout-wise.  Algorithmetically,
> it seems somewhat variable - some functions are implemented (hopefully
> correctly) using semi-numerical techniques, whereas others just use
> mathematical identities which will result in precision loss - though
> most of the functions include accuracy information.
> 
> I agree it would be far preferable to have a properly validated C99
> libm with all functions having maximum errors of a no more than a few
> LSB over their complete domain, as well as correct support for signed
> zeroes, infinities and signalling and non-signalling NaNs but that is
> a non-trivial undertaking.
> 
> In the interim, how should FreeBSD handle apps that want a C99 libm?
> 1) Fail to build them
> 2) Provide possibly imperfect fallbacks for the unimplemented bits.
> 
> If someone (I don't have the expertise) wants to identify the cephes
> functions that are sub-standard, we can include link-time warnings
> (as done for eg gets(3)) when they are used.

Given that cephes was written years before C99 was even
conceived, I suspect all functions are sub-standard.  For
example, AFAIK, none of the long double functions are
appropriate for any platform that has an 128-bit long double;
as cephes was written for an Intel 80-bit format.

If portmgr or a port maintainer wants to use a library with
untested implementations of missing libm functions, please do
not put it into /usr/local/lib and call it libm.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

On Tue, May 29, 2012 at 07:05:07AM +1000, Peter Jeremy wrote:
> On 2012-May-28 11:01:24 -0500, Stephen Montgomery-Smith 
>  wrote:
> >One thing that could be done is to have a "math/cephes" port that adds 
> >the extra C99 math functions.  This is already done in the math/sage 
> >port, using a rather clever patch due to Peter Jeremy, that applies to 
> >the cephes code.
> >
> >What it would do is to create a /usr/local/lib/libm.so that would 
> >provide the extra functions not currently included in /lib/libm.so, and 
> >then link in /lib/libm.so as well.  It would also create its own 
> >/usr/local/include/math.h and /usr/local/include/complex.h as well.
> 
> Basically, as long as the compiler searches /usr/local/{include,lib}
> before the base include/lib then ,  and -lm give
> the application a complete C99 math implementation by using base
> functions where they exist and cephes functions where they don't.
> 
> The patch I wrote for sage can be found at
> http://trac.sagemath.org/sage_trac/ticket/9543
> If there's any interest, I could produce a port for this.
> 
> Another option would be to import cephes into base and use it to
> provide the missing C99 functions.  Cephes includes copyright notices
> but the closest I can find to a license is:
> "   Some software in this archive may be from the book _Methods and
>  Programs for Mathematical Functions_ (Prentice-Hall or Simon & Schuster
>  International, 1989) or from the Cephes Mathematical Library, a
>  commercial product. In either event, it is copyrighted by the author.
>  What you see here may be used freely but it comes with no support or
>  guarantee."

Please talk to das@ (although I believe he's finishing up his
dissertation).  I recall that he's stated that he looked into
using cephes, and concluded that it is not suitable for libm.

Note there is also

http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147599

which I've also objected to importing into libm.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148


On 05/28/2012 05:17 PM, Steve Kargl wrote:

On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:

On 05/28/2012 03:31 PM, Steve Kargl wrote:

On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:

One thing that could be done is to have a "math/cephes" port that adds
the extra C99 math functions.  This is already done in the math/sage
port, using a rather clever patch due to Peter Jeremy, that applies to
the cephes code.

What it would do is to create a /usr/local/lib/libm.so that would
provide the extra functions not currently included in /lib/libm.so, and
then link in /lib/libm.so as well.  It would also create its own
/usr/local/include/math.h and /usr/local/include/complex.h as well.

What do you guys think?  Do you want someone to start experimenting with
this idea?  I could do it, but probably not for a little while.



This is a horrible, horrible, horrible idea.  Have you
looked at the cephes code, particularly the complex.h
functions?


I have only taken a very cursory look.  What should I specifically look
for in seeing that the code is bad?


Well, to start with, the extra C99 math functions that
are missing in libm include a few for the long double type
and many (if not most) of the complex functions for any
type.  Cephes at best will give you float, double, and ld80, but
not ld128 versions of the functions.  Then, there is fun little fact
that neither (base) gcc nor clang nor gcc less than 4.6 does
complex arithematic correctly; so, one needs to jump through
hoops to get the correct answer (See Annex G in n1256.pdf).
One item of particular importance in Annex G is the behavior
of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
NaN.



IMHO these problems are definitely not bad enough to avoid making a 
math/cephes port.  I for one would definitely like to have some kind of 
implementation of ccosh, even if it gets a few things wrong when it is 
fed Nan or I*Inf or such like as its input.  I mean, if clang or gcc46 
doesn't even get this right, how can we expect better from libm?


Also, a really nice thing about Jeremy's patch is that it automatically 
detects which functions are already included in the base libm, and only 
adds functions not already in libm.


And ld80 is better than nothing if ld128 isn't available.

I would avoid cephes only if it got some of the answers horribly wrong 
(as in erf(100) being something like -14232 as the openoffice 
implementation of the erf function used to report).


I say, lets go ahead and add a math/cephes port.

By the way, do you have an opinion on the complex functions used in 
Linux?  (I tried reading the glibc code, but I could only find chains of 
macros and functions calling each other, and I could never find where 
the actual work was performed.)


___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

On Mon, May 28, 2012 at 06:03:37PM -0500, Stephen Montgomery-Smith wrote:
> On 05/28/2012 05:17 PM, Steve Kargl wrote:
> >On Mon, May 28, 2012 at 04:19:22PM -0500, Stephen Montgomery-Smith wrote:
> >>On 05/28/2012 03:31 PM, Steve Kargl wrote:
> >>>On Mon, May 28, 2012 at 11:01:24AM -0500, Stephen Montgomery-Smith wrote:
> One thing that could be done is to have a "math/cephes" port that adds
> the extra C99 math functions.  This is already done in the math/sage
> port, using a rather clever patch due to Peter Jeremy, that applies to
> the cephes code.
> 
> What it would do is to create a /usr/local/lib/libm.so that would
> provide the extra functions not currently included in /lib/libm.so, and
> then link in /lib/libm.so as well.  It would also create its own
> /usr/local/include/math.h and /usr/local/include/complex.h as well.
> 
> What do you guys think?  Do you want someone to start experimenting with
> this idea?  I could do it, but probably not for a little while.
> 
> >>>
> >>>This is a horrible, horrible, horrible idea.  Have you
> >>>looked at the cephes code, particularly the complex.h
> >>>functions?
> >>
> >>I have only taken a very cursory look.  What should I specifically look
> >>for in seeing that the code is bad?
> >
> >Well, to start with, the extra C99 math functions that
> >are missing in libm include a few for the long double type
> >and many (if not most) of the complex functions for any
> >type.  Cephes at best will give you float, double, and ld80, but
> >not ld128 versions of the functions.  Then, there is fun little fact
> >that neither (base) gcc nor clang nor gcc less than 4.6 does
> >complex arithematic correctly; so, one needs to jump through
> >hoops to get the correct answer (See Annex G in n1256.pdf).
> >One item of particular importance in Annex G is the behavior
> >of the functions for Re(z) and/or Im(z) being +-0, +-Inf, and
> >NaN.
> >
> 
> IMHO these problems are definitely not bad enough to avoid making a 
> math/cephes port.  I for one would definitely like to have some kind of 
> implementation of ccosh, even if it gets a few things wrong when it is 
> fed Nan or I*Inf or such like as its input.  I mean, if clang or gcc46 
> doesn't even get this right, how can we expect better from libm?

Search the llvm and gcc bug databases, I'm the person that informed
both that they can't deal with complex arithematic correctly.

Interesting that you mention ccosh.

>From clog.c in http://www.netlib.org/cephes/cmath.tgz

void
ccosh (z, w)
 cmplx *z, *w;
{
  double x, y;
  x = z->r;
  y = z->i;
  w->r = cosh (x) * cos (y);
  w->i = sinh (x) * sin (y);
}

>From clog.c in http://www.netlib.org/cephes/c9x-complex

double complex
ccosh (z)
 double complex z;
{
  double complex w;
  double x, y;

  x = creal(z);
  y = cimag(z);
  w = cosh (x) * cos (y)  +  (sinh (x) * sin (y)) * I;
  return (w);
}

See math_private.h about the above. 

And, finally,

:
/*-
 * Copyright (c) 2005 Bruce D. Evans and Steven G. Kargl
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice unmodified, this list of conditions, and the following
 *disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
 * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/*
 * Hyperbolic cosine of a complex argument z = x + i y.
 *
 * cosh(z) = cosh(x+iy)
 * = cosh(x) cos(y) + i sinh(x) sin(y).
 *
 * Exceptional values are noted in the comments within the source code.
 * These values and the return value were taken from n1124.pdf.
 */

#include 
__FBSDID("$FreeBSD: head/lib/msun/src/s_ccosh.c 226599 2011-10-21 06:29:32Z das 
$");

#include 
#include 

#include "math_private.h"

static const double huge = 0x1p1023;

double complex
ccosh(double complex z)
{
double x, y, h;
int32_t hx, hy, ix, iy, lx, ly;

x = creal(z);
y = cimag(z);

EXTRACT_WORDS(hx, lx, x);

Re: Use of C99 extra long double math functions after r236148


On 05/28/2012 06:30 PM, Steve Kargl wrote:




From clog.c in http://www.netlib.org/cephes/c9x-complex


double complex
ccosh (z)
  double complex z;
{
   double complex w;
   double x, y;

   x = creal(z);
   y = cimag(z);
   w = cosh (x) * cos (y)  +  (sinh (x) * sin (y)) * I;
   return (w);
}

See math_private.h about the above.



I looked in math_private.h - I presume you meant 
lib/msun/src/math_private.h.  I wasn't able to find anything about ccosh 
there.


I think that for a rough and ready ccosh, this is high enough quality 
for a math/cephes port.


I do agree that it might not be high enough quality to make FreeBSD base.

(Although I don't think I have ever been in a situation where I would 
have been tripped up by a transcendental function that responded 
incorrectly to exceptional input.)





And, finally,


Yes, it is very nice.



Who's writing the code to test the implementations?  That is
better much the problem.  Without testing, one might get an
implementation that appears to work until it doesn't!  It took
me 3+ years to get sqrtl() into libm, but bde and das (and
myself) wanted to make sure the code worked.


Fair enough if we are talking about the base system.


I haven't looked at glibc code in years, because I hack on libm
when I can.  I do not want to run into questions about whether
my code is tainted by the gpl.



They had similar lists of exceptions.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

On Mon, May 28, 2012 at 06:44:42PM -0500, Stephen Montgomery-Smith wrote:
> On 05/28/2012 06:30 PM, Steve Kargl wrote:
> 
> >
> >>From clog.c in http://www.netlib.org/cephes/c9x-complex
> >
> >double complex
> >ccosh (z)
> >  double complex z;
> >{
> >   double complex w;
> >   double x, y;
> >
> >   x = creal(z);
> >   y = cimag(z);
> >   w = cosh (x) * cos (y)  +  (sinh (x) * sin (y)) * I;
> >   return (w);
> >}
> >
> >See math_private.h about the above.
> >
> 
> I looked in math_private.h - I presume you meant 
> lib/msun/src/math_private.h.  I wasn't able to find anything about ccosh 
> there.
> 
> I think that for a rough and ready ccosh, this is high enough quality 
> for a math/cephes port.

That's the problem.  It is not acceptable (imo).  The comment in
math_private.h that is relevant is

/*
 * Inline functions that can be used to construct complex values.
 *
 * The C99 standard intends x+I*y to be used for this, but x+I*y is
 * currently unusable in general since gcc introduces many overflow,
 * underflow, sign and efficiency bugs by rewriting I*y as
 * (0.0+I)*(y+0.0*I) and laboriously computing the full complex product.
 * In particular, I*Inf is corrupted to NaN+I*Inf, and I*-0 is corrupted
 * to -0.0+I*0.0.
 */

Those wrong +-0 mean you may up end up on the worng riemann sheet,
and that NaN propagates.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

CURRENT: buildworld fails

2012-05-28 Thread 山谷崇史

I had same problem, but I resolved it.

Maybe, your sort (/usr/bin/sort) is broken.

cd /usr/src
make update
cd usr.bin/sort
make obj depend all install

Then, sort is changed.

make cleandir cleandir
make buildworld
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OptionalObsoleteFiles.inc completeness

On 5/28/2012 3:05 PM, Dmitry Marakasov wrote:
> * Doug Barton (do...@freebsd.org) wrote:
> 
 this issue. The numerous problems we've had with it ever since it was
 introduced seem to bear me out. :)
>>>
>>> Can you list them? A missing obsolete file doesn't count.
>>
>> It doesn't catch things it needs to
>> It catches things it shouldn't
>> The current incarnation is painfully slow (so I've heard)
>>  ... and the biggest problem ...
>> It needs to be updated manually
> 
> Pretty true. Still I'd like to fix what we have now, than not to
> have a useful feature.

A question was raised about named.conf, so I answered it. A question was
raised about why I don't like/use Obsolete, so I answered it. At no
point did I say "don't work on Obsolete."

That said, my concern about this is the same as my concern about effort
being placed into other less-than-desirable solutions.

1. The effort could be better placed elsewhere
2. The fact that $SOMEONE is working on $SOMETHING gives people a warm
fuzzy feeling that has a tendency to diminish the urgency towards
putting real fixes to real problems.

So once again, I'm not saying "don't do it." But since someone actually
asked for my opinion ... :)

Doug

-- 

This .signature sanitized for your protection
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: CURRENT: buildworld fails

2012-05-28 Thread Oleg Moskalenko

So, the newer sort works fine, and the older sort does not work ? Did I get 
your correctly ?

Thanks
Oleg

> -Original Message-
> From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-
> curr...@freebsd.org] On Behalf Of 
> Sent: Monday, May 28, 2012 8:45 PM
> To: freebsd-current@freebsd.org
> Subject: CURRENT: buildworld fails
> 
> I had same problem, but I resolved it.
> 
> Maybe, your sort (/usr/bin/sort) is broken.
> 
> cd /usr/src
> make update
> cd usr.bin/sort
> make obj depend all install
> 
> Then, sort is changed.
> 
> make cleandir cleandir
> make buildworld
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-
> unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148

On 2012-May-28 15:54:06 -0700, Steve Kargl  
wrote:
>Given that cephes was written years before C99 was even
>conceived, I suspect all functions are sub-standard.

Well, most of cephes was written before C99.  The C99 parts of
cephes were written to turn it into a complete C99 implementation.

>  For
>example, AFAIK, none of the long double functions are
>appropriate for any platform that has an 128-bit long double;
>as cephes was written for an Intel 80-bit format.

FreeBSD currently supports:
64-bit long doubles on ARM, MIPS and PowerPC;
80-bit long doubles on amd64, i386 and iA64;
128-bit long doubles on SPARC.

The lack of LD128 in cephes therefore only affects one (not widely
used) platform.  The lack of even de facto standards for long
double mean that any applications wanting to use them already need
to cope with at least a 2:1 precision range.

>If portmgr or a port maintainer wants to use a library with
>untested implementations of missing libm functions, please do
>not put it into /usr/local/lib and call it libm.

There some test code in cephes.  Can you point me to a suitable test
suite for LD80 and LD128?  The reason for calling it libm is to avoid
having to hack every consumer to add an additional library.

On 2012-May-28 16:30:35 -0700, Steve Kargl  
wrote:
>Who's writing the code to test the implementations?  That is
>better much the problem.  Without testing, one might get an
>implementation that appears to work until it doesn't!

That is equally true of the rest of FreeBSD.  The list of open PRs
suggests that FreeBSD still has a fair way to go before reaching
perfection.  And, most of this thread has been about using this code
in ports - where the bar is much lower.  Who is writing the code to
test all the other ports?  What is so special about this particular
proposed port that it needs to come with solid-gold credentials?

>  It took
>me 3+ years to get sqrtl() into libm, but bde and das (and
>myself) wanted to make sure the code worked.

Last time I checked (a couple of years ago), FreeBSD was missing 65
C99 libm functions.  At 3 years per function, we should have C99
support available early in the 23rd century - which may be a bit late.

On 2012-May-28 22:03:43 -0500, Stephen Montgomery-Smith  
wrote:
>1.  By being so picky about being so precise, FreeBSD is behind the time 
>line in rolling out a usable set of C99 functions.

And at the current rate, we'll all be long dead before they are
available.  Whilst I'd far prefer to have a properly verifed library
function, I think we are better off with an implementation that has
some caveats regarding edge-case behaviour than having nothing.

>In the end, I do think it is good to ultimately settle on good C99 
>compliant code.  But having something intermediate that mostly works is 
>better than nothing.  Especially if it exists only in the ports, and not 
>in the base code.

I agree with this sentiment.

What do people do on other free OSs?  Does a tested open source C99
libm exist anywhere?  glibc implements cpow(x,y) as cexp(y*clog(x))
and cephes does better than that.  Is FreeBSD wasting its time writing
"correct" C99 code because all the libm consumers expect no better
than what glibc offers?

I agree that writing correct libm functions is hard.  I think a lot of
the problem is that it's a mix of lots of boilerplate code testing for
special conditions and edge cases that is boring to write and fiddly
to get right, together with a kernel that is a pile of polynomial
evaluations full of magic numbers that needs specialist skills to
write.  If we could get someone with the relevant skills to formally
list all the special conditions & edge cases for each function, it
should be possible to generate both the library C code and test cases
from that - which would remove a lot of the tedium.

-- 
Peter Jeremy

pgpUnZGDcc79l.pgp
Description: PGP signature

Re: Use of C99 extra long double math functions after r236148

On Tue, May 29, 2012 at 02:56:13PM +1000, Peter Jeremy wrote:
> On 2012-May-28 15:54:06 -0700, Steve Kargl 
>  wrote:
> 
> There some test code in cephes.  Can you point me to a suitable test
> suite for LD80 and LD128?  The reason for calling it libm is to avoid
> having to hack every consumer to add an additional library.

I can't point you to test code.  When I work on a function,
I write test code.

> >  It took
> >me 3+ years to get sqrtl() into libm, but bde and das (and
> >myself) wanted to make sure the code worked.
> 
> Last time I checked (a couple of years ago), FreeBSD was missing 65
> C99 libm functions.  At 3 years per function, we should have C99
> support available early in the 23rd century - which may be a bit late.

sqrtl() is a bit special in that IEEE 754 requires that
it have no more than 0.5 ULP for all arguments in all
roundng modes.  As to other functions, I've been trying
for 10+ years to get some of these into FreeBSD.  I can
assure you that there has never been a rush of people
volunteering to help or a rush of people willing to fund
the development of the necessary code. 

> 
> On 2012-May-28 22:03:43 -0500, Stephen Montgomery-Smith 
>  wrote:
> >1.  By being so picky about being so precise, FreeBSD is behind the time 
> >line in rolling out a usable set of C99 functions.
> 
> And at the current rate, we'll all be long dead before they are
> available.

It seems you've had "a couple of years" to implement one or
more of the missing functions.  Yes, we'll all be dead before
libm is C99 ready because no one, other than bde@, das@ and
myself, has been willing to actually help write the code.  I
know that at least one of those three people has had no time
in the last year or two work on libm. 

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Use of C99 extra long double math functions after r236148