Re: kernel compile broken in latest HEAD
On Tue, 09 Jul 2013 22:39:40 +0200 Andreas Tobler wrote: > On 09.07.13 22:33, Alexander Leidinger wrote: > > Here's what I wrote as a reference: > > ---snip--- > > Does someone know what this is supposed to result in? > > > > I would assume as the unions are unnamed and no variable is declared > > inside the struct with it, that the size of the struct is the same > > as not having those unions inside the structs. > > > > If this is correct I would assume the correct fix would be to #if-0 > > them out. > > ---snip--- > > I did so and my kernelbuild is happy now. Yes, I do not use this > header at all. The linuxulator uses it for v4l2 compatibility. If you use skype, you use the header. The fix above is wrong (it changes the size of the structs with gcc and with clang). I will commit a fix in a few minutes. 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: SVN r252892: videodev2.h update breaks gcc compilation
On Sun, 07 Jul 2013 06:59:59 -0400 Michael Butler wrote: > The recent linux header update triggers the following error: > > In file included from /usr/src/sys/compat/linux/linux_ioctl.c:91: > /usr/src/sys/contrib/v4l/videodev2.h:430: warning: declaration does > not declare anything Can you please try a recent -current, I just committed a fix for this. Thanks, 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: kernel compile broken in latest HEAD
On Tue, 9 Jul 2013 17:32:33 +0200 Gary Jennejohn wrote: > I simply named them all x to get the kernel to compile, which > succeeded. I committed such a fix, can you please verify that it's ok for you? 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"
NFS panic: newnfs_copycred: negative nfsc_ngroups (client HEAD r253033, server 9.1-R)
I received this panic on the client while doing heavy parallel reads/writes over NFS. I only recently moved these files to NFS, so I don't know whether or not it's a recent regression. Client: HEAD r253033 Server: 9.1-R core.txt: http://people.freebsd.org/~bdrewery/nfs.txt fstab of related paths: > tank:/tank/distfiles/freebsd/mnt/distfiles nfs > rw,bg,noatime,intr,rsize=65536,wsize=65536,readahead=8,nfsv40 > 0 > tank:/usr/packages/ /mnt/all-packages nfs > > rw,bg,noatime,soft,retrycnt=3,rsize=65536,wsize=65536,readahead=8,nfsv40 > 0 Server: params on these paths: -maproot=root -network 10.10.0.0/16 tcpdump at the time: > 21:43:05.396585 IP 10.10.0.7.4180315003 > 10.10.0.5.2049: 168 getattr fh 0,4/2 > 21:43:05.396589 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > 48265029:48266477, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 > ecr 596674], length 1448 > 21:43:05.396603 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > 48266477:48267925, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 > ecr 596674], length 1448 > 21:43:05.396605 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack 48266477, > win 3916, options [nop,nop,TS val 596674 ecr 1950216660], length 0 > 21:43:05.396608 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > 48267925:48269373, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 > ecr 596674], length 1448 > 21:43:05.396621 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > 48269373:48270821, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 > ecr 596674], length 1448 > 21:43:05.396624 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack 48269373, > win 3870, options [nop,nop,TS val 596674 ecr 1950216660], length 0 > 21:43:05.396641 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > 48270821:48272269, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 > ecr 596674], length 1448 > 21:43:05.396653 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > 48272269:48273717, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 > ecr 596674], length 1448 > 21:43:05.396656 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack 48272269, > win 3825, options [nop,nop,TS val 596674 ecr 1950216660], length 0 > 21:43:05.396659 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > 48273717:48275165, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 > ecr 596674], length 1448 > 21:43:05.396671 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > 48275165:48276613, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 > ecr 596674], length 1448 > 21:43:05.396674 IP 10.10.0.7.946 > 10.10.0.5.2049: Flags [.], ack 48275165, > win 3780, options [nop,nop,TS val 596674 ecr 1950216660], length 0 > 21:43:05.396676 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > 48276613:48278061, ack 4394885, win 29124, options [nop,nop,TS val 1950216660 > ecr 596674], length 1448 > 21:43:05.396689 IP 10.10.0.5.2049 > 10.10.0.7.946: Flags [.], seq > 48278061:48279509, ack 4394885, win 29124, options [nop,nop,TS val > Write failed: Broken pipe I have nfsuserd running on both client/server. nfscbd is running. nfs_client_enable=yes in rc.conf. User lookups seem to work fine: > -rw-r--r-- 1 root bryan 1554804 Jul 6 10:50 > /mnt/distfiles/pkg-1.1.4.tar.xz I ran a find -ls on these paths and all files return a user/group. I am guessing there is a race condition with files being written and looking up the associated groups. -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ 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 compile broken in latest HEAD
On Wed, 10 Jul 2013 12:43:00 +0200 Alexander Leidinger wrote: > On Tue, 9 Jul 2013 17:32:33 +0200 > Gary Jennejohn wrote: > > > I simply named them all x to get the kernel to compile, which > > succeeded. > > I committed such a fix, can you please verify that it's ok for you? > Yup, it works. -- Gary Jennejohn ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
Hi -- [Upcoming code freeze in stable] On 2013-04-13 22:15, Michael Grimm wrote: On 13.04.2013, at 14:29, Kimmo Paasiala wrote: [great deal of simplification by ipv6_addrs_IF] Sorry to resurrect this thread but since nothing has happened in about three months I have to ask: What can I do to have this commited to HEAD? +1 Nowadays -where IPv6 becomes more and more available by ISPs- I *really* would like to see this simplification implemented, soon, very soon. The current scheme is way to much error prone, and, its a pain in the ass! Thanks for the patch, Michael Will that patch make it into 9.2? If I am not mistaken, that patch isn't in stable yet. Regards, Michael ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm wrote: Will that patch make it into 9.2? If I am not mistaken, that patch isn't in stable yet. I would also like to see this patch hit 9.x sooner than later. It's so painful when someone forgets to fix the alias numbering on servers with many, many IPv4 and IPv6 addresses... ___ 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"
"Stale NFS file handle" for NFS exported UFS from r252435
Hi, Upgrading a CURRENT amd64 pure UFS system (watson) from r249744 to r253007, I have hit the following: claude@zorglub$ mount_nfs watson:/home /mnt claude@zorglub$ /bin/ls /mnt/ claude doc.old ports.old sysref distfiles obj portsperso xorg-dev doc ports src xtrafiles claude@zorglub$ /bin/ls /mnt/claude ls: /mnt/claude: Stale NFS file handle claude@zorglub$ /bin/ls /mnt/ports.old CHANGES UPDATINGdns multimedia textproc COPYRIGHT accessibility editors net www ... some directories may be listed, for the others the result is "Stale NFS file handle" This exists for a 8.4-STABLE client system, for a 9.1-STABLE client system, and also with a local mount (localhost) on the server system itself. I checked with memsticks of official snapshots (to eliminate the influence of local patches and customized kernels), with the result: FreeBSD-10.0-CURRENT-amd64-20130630-r252387-memstick is not affected FreeBSD-10.0-CURRENT-amd64-20130707-r252887-memstick is affected Doing a binary search on the kernel source (without any patch) lead to the "culprit": -- Author: pfg Date: Mon Jul 1 03:00:15 2013 New Revision: 252435 URL: http://svnweb.freebsd.org/changeset/base/252435 Log: Change i_gen in UFS to an unsigned type. In UFS, i_gen is a random generated value and there is not way for it to be negative. Actually, the value of i_gen is just used to match bit patterns and it is of not consequence if the values are signed or not. Following other filesystems, set it to unsigned and use it as such, Discussed by: mckusick Reviewed by: mckusick (previous version) MFC after:4 weeks Modified: head/sys/ufs/ffs/ffs_vfsops.c head/sys/ufs/ufs/dinode.h head/sys/ufs/ufs/inode.h head/sys/ufs/ufs/ufs_extattr.c -- which is entirely UFS (not NFS) related. CCing pfg@ as the committer, and rmacklem@ just in case.. Thanks for your attention Claude Buisson ___ 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: "Stale NFS file handle" for NFS exported UFS from r252435
On 07/10/13 08:32, Claude Buisson wrote: > Hi, > > Upgrading a CURRENT amd64 pure UFS system (watson) from r249744 to > r253007, I have hit the following: > > claude@zorglub$ mount_nfs watson:/home /mnt > claude@zorglub$ /bin/ls /mnt/ > claude doc.old ports.old sysref > distfiles obj portsperso xorg-dev > doc ports src xtrafiles > claude@zorglub$ /bin/ls /mnt/claude > ls: /mnt/claude: Stale NFS file handle > claude@zorglub$ /bin/ls /mnt/ports.old > CHANGES UPDATINGdns multimedia textproc > COPYRIGHT accessibility editors net www > ... > > some directories may be listed, for the others the result is "Stale NFS > file handle" +1 I was trying to work out what this was .. thanks for identifying, imb ___ 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: Improved SYN Cookies: Looking for testers
Andre Oppermann wrote: > We have a SYN cookie implementation for quite some time now but it > has some limitations with current realities for window scaling and > SACK encoding the in the few available bits. > > This patch updates and improves SYN cookies mainly by: > > a) encoding of MSS, WSCALE (window scaling) and SACK into the ISN > (initial sequence number) without the use of timestamp bits. > > b) switching to the very fast and cryptographically strong SipHash-2-4 > hash MAC algorithm to protect the SYN cookie against forgery. > > The patch had been reviewed by dwmalone (cookies) and cperciva (siphash). > > Please find it here for testing: > > http://people.freebsd.org/~andre/syncookie-20130708.diff I've been using the patch for a couple of days and didn't notice any issues so far. Privoxy's regression tests continue to work as expected as well. BTW, I think kern/173309 could be closed. Fabian signature.asc Description: PGP signature
(follow-up) "Stale NFS file handle" for NFS exported UFS from r252435
On 07/10/2013 14:32, Claude Buisson wrote: Hi, Upgrading a CURRENT amd64 pure UFS system (watson) from r249744 to r253007, I have hit the following: claude@zorglub$ mount_nfs watson:/home /mnt claude@zorglub$ /bin/ls /mnt/ claude doc.old ports.old sysref distfiles obj portsperso xorg-dev doc ports src xtrafiles claude@zorglub$ /bin/ls /mnt/claude ls: /mnt/claude: Stale NFS file handle claude@zorglub$ /bin/ls /mnt/ports.old CHANGES UPDATINGdns multimedia textproc COPYRIGHT accessibility editors net www ... some directories may be listed, for the others the result is "Stale NFS file handle" This exists for a 8.4-STABLE client system, for a 9.1-STABLE client system, and also with a local mount (localhost) on the server system itself. I checked with memsticks of official snapshots (to eliminate the influence of local patches and customized kernels), with the result: FreeBSD-10.0-CURRENT-amd64-20130630-r252387-memstick is not affected FreeBSD-10.0-CURRENT-amd64-20130707-r252887-memstick is affected Doing a binary search on the kernel source (without any patch) lead to the "culprit": -- Author: pfg Date: Mon Jul 1 03:00:15 2013 New Revision: 252435 URL: http://svnweb.freebsd.org/changeset/base/252435 Log: Change i_gen in UFS to an unsigned type. In UFS, i_gen is a random generated value and there is not way for it to be negative. Actually, the value of i_gen is just used to match bit patterns and it is of not consequence if the values are signed or not. Following other filesystems, set it to unsigned and use it as such, Discussed by: mckusick Reviewed by:mckusick (previous version) MFC after: 4 weeks Modified: head/sys/ufs/ffs/ffs_vfsops.c head/sys/ufs/ufs/dinode.h head/sys/ufs/ufs/inode.h head/sys/ufs/ufs/ufs_extattr.c -- which is entirely UFS (not NFS) related. Reverting 252435 + 252437 and rebuilding the kernel seems to give back a working system. Claude Buisson ___ 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: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
Whe I try to compile the sources of a port in spe (devel/pocl), which
is now out as RC6, I receive this error shown below:
[...]
../vecmathlib/pocl/../vec_sse_double1.h:451:38: error:
conversion from 'int' to 'boolvec_t' (aka 'boolvec') is
ambiguous boolvec_t isinf() const { return std::isinf(v); }
^ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note:
candidate constructor boolvec(bvector_t x): v(x) {}
^
../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate
constructor boolvec(bool a): v(a) {}
[...]
Compilation is performed on the most recent CURRENT with CLANG 3.3 and
devel/llvm (which is obviously stuck with 3.2 for now) and option
switches -std=c++11 -stdlib=libc++.
As I was told, in standard C++11, isnan(), isinf() and fellows now
should return "bool", not int as this seems obviously the case as the
error documents and I was able to check with a small program.
Is this a bug in FreeBSD's implementation of libc++? Or am I doing
something wrong?
I'm new to C++/C++11.
Some advice or explanation could be helpful.
regards,
Oliver
signature.asc
Description: PGP signature
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
Hi,
On 10 Jul 2013, at 14:58, "O. Hartmann" wrote:
>
> Whe I try to compile the sources of a port in spe (devel/pocl), which
> is now out as RC6, I receive this error shown below:
>
> [...]
> ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error:
> conversion from 'int' to 'boolvec_t' (aka 'boolvec') is
> ambiguous boolvec_t isinf() const { return std::isinf(v); }
> ^ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note:
> candidate constructor boolvec(bvector_t x): v(x) {}
>^
> ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate
> constructor boolvec(bool a): v(a) {}
> [...]
>
> Compilation is performed on the most recent CURRENT with CLANG 3.3 and
> devel/llvm (which is obviously stuck with 3.2 for now) and option
> switches -std=c++11 -stdlib=libc++.
>
> As I was told, in standard C++11, isnan(), isinf() and fellows now
> should return "bool", not int as this seems obviously the case as the
> error documents and I was able to check with a small program.
>
> Is this a bug in FreeBSD's implementation of libc++? Or am I doing
> something wrong?
>
> I'm new to C++/C++11.
>
>
> Some advice or explanation could be helpful.
I believe that this is also causing some failures in the libc++ test suite and
is due to some interaction between our headers and the libc++ headers, but I
don't see where it is.
Our isnan implementation is a really ugly macro that looks like this:
#define>isnan(x)\
((sizeof (x) == sizeof (float)) ? __isnanf(x) \
: (sizeof (x) == sizeof (double)) ? isnan(x)\
: __isnanl(x))
The definition in the libc++ cmath header is:
#ifdef isnan
template
_LIBCPP_ALWAYS_INLINE
bool
__libcpp_isnan(_A1 __x) _NOEXCEPT
{
return isnan(__x);
}
#undef isnan
This should work correctly.
However...
I wonder if you are including math.h instead of ? That would show the
result that you appear to be seeing, which looks like the result of using the
isnan() macro rather than the isnan() function. If you have included
then the isnan() macro will have been defined.
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435
Hello guys; Thank for finding this, however ... On 10.07.2013 08:53, Claude Buisson wrote: On 07/10/2013 14:32, Claude Buisson wrote: Hi, Upgrading a CURRENT amd64 pure UFS system (watson) from r249744 to r253007, I have hit the following: claude@zorglub$ mount_nfs watson:/home /mnt claude@zorglub$ /bin/ls /mnt/ claude doc.old ports.old sysref distfiles obj portsperso xorg-dev doc ports src xtrafiles claude@zorglub$ /bin/ls /mnt/claude ls: /mnt/claude: Stale NFS file handle claude@zorglub$ /bin/ls /mnt/ports.old CHANGES UPDATINGdns multimedia textproc COPYRIGHT accessibility editors net www ... some directories may be listed, for the others the result is "Stale NFS file handle" This exists for a 8.4-STABLE client system, for a 9.1-STABLE client system, and also with a local mount (localhost) on the server system itself. I checked with memsticks of official snapshots (to eliminate the influence of local patches and customized kernels), with the result: FreeBSD-10.0-CURRENT-amd64-20130630-r252387-memstick is not affected FreeBSD-10.0-CURRENT-amd64-20130707-r252887-memstick is affected Doing a binary search on the kernel source (without any patch) lead to the "culprit": -- Author: pfg Date: Mon Jul 1 03:00:15 2013 New Revision: 252435 URL: http://svnweb.freebsd.org/changeset/base/252435 Log: Change i_gen in UFS to an unsigned type. In UFS, i_gen is a random generated value and there is not way for it to be negative. Actually, the value of i_gen is just used to match bit patterns and it is of not consequence if the values are signed or not. Following other filesystems, set it to unsigned and use it as such, Discussed by:mckusick Reviewed by:mckusick (previous version) MFC after:4 weeks Modified: head/sys/ufs/ffs/ffs_vfsops.c head/sys/ufs/ufs/dinode.h head/sys/ufs/ufs/inode.h head/sys/ufs/ufs/ufs_extattr.c -- which is entirely UFS (not NFS) related. Reverting 252435 + 252437 and rebuilding the kernel seems to give back a working system. Claude Buisson While I understand this change caused the issue and I am willing to revert it, I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I presume glusterfs) have unsigned i_gen. Pedro. ___ 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: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435
On 07/10/2013 17:05, Pedro Giffuni wrote: Hello guys; Thank for finding this, however ... While I understand this change caused the issue and I am willing to revert it, I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I presume glusterfs) have unsigned i_gen. I have the same thinking (and was rather astonished by the success of my try at reverting it): there is something somewhere in the NFS code which have not been synced with the UFS change. It is the reason I CC'ed rmacklem@ Pedro. Claude Buisson ___ 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: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435
On 10.07.2013 10:16, Claude Buisson wrote: On 07/10/2013 17:05, Pedro Giffuni wrote: Hello guys; Thank for finding this, however ... While I understand this change caused the issue and I am willing to revert it, I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I presume glusterfs) have unsigned i_gen. I have the same thinking (and was rather astonished by the success of my try at reverting it): there is something somewhere in the NFS code which have not been synced with the UFS change. It is the reason I CC'ed rmacklem@ There is an ongoing port of glusterfs, and glusterfs is known to use both NFS and fuse so I think we would have this problem sooner or later. I hope it's easy to find: I did a search for i_gen with opengrok before making this change and couldn't find any user. Fortunately I had no plans to merge the change for 9.2. Pedro. ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
On Wed, Jul 10, 2013 at 4:46 AM, Mark Felder wrote: > On Wed, 10 Jul 2013 06:44:12 -0500, Michael Grimm < > trash...@odo.in-berlin.de> wrote: > > Will that patch make it into 9.2? If I am not mistaken, that patch isn't >> in stable yet. >> > > I would also like to see this patch hit 9.x sooner than later. It's so > painful when someone forgets to fix the alias numbering on servers with > many, many IPv4 and IPv6 addresses... > Please, please, please, please, ...! Freeze is only two days away, so time for 9.2 is almost over and I can see no good reason NOT to get this done. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.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: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Wed, 10 Jul 2013 15:22:58 +0100
David Chisnall wrote:
> Hi,
>
> On 10 Jul 2013, at 14:58, "O. Hartmann"
> wrote:
>
> >
> > Whe I try to compile the sources of a port in spe (devel/pocl),
> > which is now out as RC6, I receive this error shown below:
> >
> > [...]
> > ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error:
> > conversion from 'int' to 'boolvec_t' (aka 'boolvec')
> > is ambiguous boolvec_t isinf() const { return std::isinf(v); }
> > ^ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note:
> > candidate constructor boolvec(bvector_t x): v(x) {}
> >^
> > ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate
> > constructor boolvec(bool a): v(a) {}
> > [...]
> >
> > Compilation is performed on the most recent CURRENT with CLANG 3.3
> > and devel/llvm (which is obviously stuck with 3.2 for now) and
> > option switches -std=c++11 -stdlib=libc++.
> >
> > As I was told, in standard C++11, isnan(), isinf() and fellows now
> > should return "bool", not int as this seems obviously the case as
> > the error documents and I was able to check with a small program.
> >
> > Is this a bug in FreeBSD's implementation of libc++? Or am I doing
> > something wrong?
> >
> > I'm new to C++/C++11.
> >
> >
> > Some advice or explanation could be helpful.
>
> I believe that this is also causing some failures in the libc++ test
> suite and is due to some interaction between our headers and the
> libc++ headers, but I don't see where it is.
>
> Our isnan implementation is a really ugly macro that looks like this:
>
> #define>isnan(x) \
> ((sizeof (x) == sizeof (float)) ? __isnanf(x) \
> : (sizeof (x) == sizeof (double)) ? isnan(x) \
> : __isnanl(x))
>
>
> The definition in the libc++ cmath header is:
>
> #ifdef isnan
>
> template
> _LIBCPP_ALWAYS_INLINE
> bool
> __libcpp_isnan(_A1 __x) _NOEXCEPT
> {
> return isnan(__x);
> }
>
> #undef isnan
>
> This should work correctly.
>
> However...
>
> I wonder if you are including math.h instead of ? That would
> show the result that you appear to be seeing, which looks like the
> result of using the isnan() macro rather than the isnan() function.
> If you have included then the isnan() macro will have been
> defined.
>
> David
>
Hi David,
thanks for the fast response.
The code I was told to check with is this:
#include
#include
#include
int
main(void)
{
std::cout << typeid(isnan(1.0)).name() << "\n";
}
If I compile it with
c++ -o testme -std=c++11 -stdlib=libc++ source.cc
and run the binary, the result is "i" which I interpret as "INT".
My OS is at
FreeBSD 10.0-CURRENT #4 r253138: Wed Jul 10 09:52:16 CEST 2013
Oliver
signature.asc
Description: PGP signature
Re: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435
On 10.07.2013 10:16, Claude Buisson wrote: On 07/10/2013 17:05, Pedro Giffuni wrote: Hello guys; Thank for finding this, however ... While I understand this change caused the issue and I am willing to revert it, I think the problem is actually in NFS. At least ext2/3/4 and fuse (so I presume glusterfs) have unsigned i_gen. I have the same thinking (and was rather astonished by the success of my try at reverting it): there is something somewhere in the NFS code which have not been synced with the UFS change. It is the reason I CC'ed rmacklem@ Pedro. Claude Buisson I found a missing type change. Can you try the attached patch? Cheers, Pedro. Index: sys/ufs/ufs/inode.h === --- sys/ufs/ufs/inode.h (revision 253159) +++ sys/ufs/ufs/inode.h (working copy) @@ -180,7 +180,7 @@ u_int16_t ufid_len; /* Length of structure. */ u_int16_t ufid_pad; /* Force 32-bit alignment. */ uint32_t ufid_ino; /* File number (ino). */ - int32_t ufid_gen; /* Generation number. */ + uint32_t ufid_gen; /* Generation number. */ }; #endif /* _KERNEL */ ___ 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: Deadlock in nullfs/zfs somewhere
On 9 July 2013 23:27, Andriy Gapon wrote: > on 09/07/2013 16:03 Adrian Chadd said the following: >> Does anyone have any ideas as to what's going on? > > Please provide output of 'thread apply all bt' from kgdb, then perhaps someone > might be able to tell. Done - http://people.freebsd.org/~adrian/ath/20130710-vm0-zfs-hang.txt adrian ___ 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"
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-07-10 15:29:52 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-10 15:29:52 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-10 15:29:52 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-10 15:29:52 - cleaning the object tree TB --- 2013-07-10 15:30:44 - /usr/local/bin/svn stat /src TB --- 2013-07-10 15:30:57 - At svn revision 253133 TB --- 2013-07-10 15:30:58 - building world TB --- 2013-07-10 15:30:58 - CROSS_BUILD_TESTING=YES TB --- 2013-07-10 15:30:58 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-10 15:30:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-10 15:30:58 - SRCCONF=/dev/null TB --- 2013-07-10 15:30:58 - TARGET=sparc64 TB --- 2013-07-10 15:30:58 - TARGET_ARCH=sparc64 TB --- 2013-07-10 15:30:58 - TZ=UTC TB --- 2013-07-10 15:30:58 - __MAKE_CONF=/dev/null TB --- 2013-07-10 15:30:58 - cd /src TB --- 2013-07-10 15:30:58 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Jul 10 15:31:05 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 10 16:40:27 UTC 2013 TB --- 2013-07-10 16:40:27 - generating LINT kernel config TB --- 2013-07-10 16:40:27 - cd /src/sys/sparc64/conf TB --- 2013-07-10 16:40:27 - /usr/bin/make -B LINT TB --- 2013-07-10 16:40:27 - cd /src/sys/sparc64/conf TB --- 2013-07-10 16:40:27 - /usr/sbin/config -m LINT TB --- 2013-07-10 16:40:27 - building LINT kernel TB --- 2013-07-10 16:40:27 - CROSS_BUILD_TESTING=YES TB --- 2013-07-10 16:40:27 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-10 16:40:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-10 16:40:27 - SRCCONF=/dev/null TB --- 2013-07-10 16:40:27 - TARGET=sparc64 TB --- 2013-07-10 16:40:27 - TARGET_ARCH=sparc64 TB --- 2013-07-10 16:40:27 - TZ=UTC TB --- 2013-07-10 16:40:27 - __MAKE_CONF=/dev/null TB --- 2013-07-10 16:40:27 - cd /src TB --- 2013-07-10 16:40:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 10 16:40:27 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-f
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On 10 Jul 2013, at 17:33, "O. Hartmann" wrote:
> Hi David,
>
> thanks for the fast response.
>
> The code I was told to check with is this:
>
> #include
> #include
> #include
>
> int
> main(void)
> {
>
>std::cout << typeid(isnan(1.0)).name() << "\n";
>
> }
>
>
> If I compile it with
>
> c++ -o testme -std=c++11 -stdlib=libc++ source.cc
>
> and run the binary, the result is "i" which I interpret as "INT".
I believe there is a bug, which is that the math.h things are being exposed but
shouldn't be, however it is not the bug that you think it is. Try this line
instead:
std::cout << typeid(std::isnan(1.0)).name() << "\n";
We have a libm function, isnan(), and a libc++ function, std::isnan(). The
former is detected if you do not specify a namespace. I am not sure what will
happen if you do:
#include
#include
#include
using namespace std;
int
main(void)
{
cout << typeid(isnan(1.0)).name() << "\n";
}
This is considered bad form, but does happen in some code. I am not certain
what the precedence rules are in this case and so I don't know what happens.
To properly fix this, we'd need to namespace the libm functions when including
math.h in C++. This would also include fixing tweaking the macros.
A fix for your code is to ensure isnan() and isinf() are explicitly namespaced.
Potentially, this may also work:
using std::isinf;
using std::isnan;
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: (follow-up) "Stale NFS file handle" for NFS exported UFS from r252435
On 07/10/2013 18:34, Pedro Giffuni wrote: I found a missing type change. Can you try the attached patch? SUCCESS !! Cheers, Pedro. Thanks (and apologies to rmacklem !) Claude Buisson ___ 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: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Wed, 10 Jul 2013 18:04:16 +0100
David Chisnall wrote:
> On 10 Jul 2013, at 17:33, "O. Hartmann"
> wrote:
>
> > Hi David,
> >
> > thanks for the fast response.
> >
> > The code I was told to check with is this:
> >
> > #include
> > #include
> > #include
> >
> > int
> > main(void)
> > {
> >
> >std::cout << typeid(isnan(1.0)).name() << "\n";
> >
> > }
> >
> >
> > If I compile it with
> >
> > c++ -o testme -std=c++11 -stdlib=libc++ source.cc
> >
> > and run the binary, the result is "i" which I interpret as "INT".
>
> I believe there is a bug, which is that the math.h things are being
> exposed but shouldn't be, however it is not the bug that you think it
> is. Try this line instead:
>
>std::cout << typeid(std::isnan(1.0)).name() << "\n";
>
> We have a libm function, isnan(), and a libc++ function,
> std::isnan(). The former is detected if you do not specify a
> namespace. I am not sure what will happen if you do:
>
> #include
> #include
> #include
> using namespace std;
>
> int
> main(void)
> {
>
>cout << typeid(isnan(1.0)).name() << "\n";
>
> }
>
> This is considered bad form, but does happen in some code. I am not
> certain what the precedence rules are in this case and so I don't
> know what happens.
>
> To properly fix this, we'd need to namespace the libm functions when
> including math.h in C++. This would also include fixing tweaking the
> macros.
>
> A fix for your code is to ensure isnan() and isinf() are explicitly
> namespaced. Potentially, this may also work:
>
> using std::isinf;
> using std::isnan;
>
> David
>
I tried in the test code I provided using
#include
#include
#include
int
main(void)
{
std::cout << typeid(std::isnan(1.0)).name() << "\n";
}
now std::isnan().
The result is the same, it flags "INT".
Using
#include
#include
#include
using namespace std;
int
main(void)
{
std::cout << typeid(std::isnan(1.0)).name() << "\n";
}
which is considered "bad coding" also results in "INT" (it gives "i").
So, is this woth a PR?
Oliver
signature.asc
Description: PGP signature
Re: Kernel crash during heavy disk access
> Date: Tue, 9 Jul 2013 18:29:01 -0700 > Subject: Re: Kernel crash during heavy disk access > From: Adrian Chadd > To: Benjamin Kaduk , Jeff Roberson , > Kirk McKusick > Cc: Eric Camachat , curr...@freebsd.org > > Well, best to tell kirk and jeffr. > > Jeffr wrote the journaling stuff. > > .. but I thought they knew there's still problems? > > -adrian Jeff has fixed all the journaling issues for which we have some way of reproducing them. We do still have some reports that there are "problems" but only a vague description and nothing that we can use to reproduce them on our systems. One of the inherit characteristics of any type of journaling is that once it thinks that it has fixed something, it never goes back and checks it again later. So, if there is some inconsistency that gets into your filesystem through media error or an earlier journaling bug, it will stay there and continue to plague you until a full fsck is run to clean it up. So, if you are getting filesystem related crashes, the first thing you should do is a full (fsck -f) check to make sure that you are starting from a clean state. After that, if you find that the journaling is not keeping it consistent, please send Jeff and me a report of what you are doing, what problems it creates, and most importantly transcript of a run of `fsck_ffs -d' first using the journal and then a second time with a full check (fsck_ffs -f -d) so that we can try to analyse what is going wrong. Note that you need to run fsck_ffs explicitly because the fsck front end will not pass the -d (debug output) flag through to fsck_ffs. Kirk McKusick > On 9 July 2013 17:48, Benjamin Kaduk wrote: >> On Tue, 9 Jul 2013, Adrian Chadd wrote: >> >>> On 9 July 2013 09:24, Eric Camachat wrote: On Mon, 2013-07-08 at 23:05 -0700, Adrian Chadd wrote: > > Hi, > > Try doing a full, non-journal fsck. > > -adrian Thank you, it fixed the problem! Does it mean journal didn't work? >>> >>> >>> Yup :( >> >> >> So, you are going to tell Kirk about it? >> >> -Ben ___ 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: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On 2013-07-10 20:32, O. Hartmann wrote:
> On Wed, 10 Jul 2013 18:04:16 +0100
> David Chisnall wrote:
>
>> On 10 Jul 2013, at 17:33, "O. Hartmann"
>> wrote:
>>
>>> Hi David,
>>>
>>> thanks for the fast response.
>>>
>>> The code I was told to check with is this:
>>>
>>> #include
>>> #include
>>> #include
>>>
>>> int
>>> main(void)
>>> {
>>>
>>>std::cout << typeid(isnan(1.0)).name() << "\n";
>>>
>>> }
>>>
>>>
>>> If I compile it with
>>>
>>> c++ -o testme -std=c++11 -stdlib=libc++ source.cc
>>>
>>> and run the binary, the result is "i" which I interpret as "INT".
>>
>> I believe there is a bug, which is that the math.h things are being
>> exposed but shouldn't be, however it is not the bug that you think it
>> is. Try this line instead:
>>
>>std::cout << typeid(std::isnan(1.0)).name() << "\n";
>>
>> We have a libm function, isnan(), and a libc++ function,
>> std::isnan(). The former is detected if you do not specify a
>> namespace. I am not sure what will happen if you do:
>>
>> #include
>> #include
>> #include
>> using namespace std;
>>
>> int
>> main(void)
>> {
>>
>>cout << typeid(isnan(1.0)).name() << "\n";
>>
>> }
>>
>> This is considered bad form, but does happen in some code. I am not
>> certain what the precedence rules are in this case and so I don't
>> know what happens.
>>
>> To properly fix this, we'd need to namespace the libm functions when
>> including math.h in C++. This would also include fixing tweaking the
>> macros.
>>
>> A fix for your code is to ensure isnan() and isinf() are explicitly
>> namespaced. Potentially, this may also work:
>>
>> using std::isinf;
>> using std::isnan;
>>
>> David
>>
>
> I tried in the test code I provided using
>
>
> #include
> #include
> #include
>
> int
> main(void)
> {
>
> std::cout << typeid(std::isnan(1.0)).name() << "\n";
>
> }
>
> now std::isnan().
>
> The result is the same, it flags "INT".
>
> Using
>
> #include
> #include
> #include
>
> using namespace std;
>
> int
> main(void)
> {
>
> std::cout << typeid(std::isnan(1.0)).name() << "\n";
>
> }
>
> which is considered "bad coding" also results in "INT" (it gives "i").
>
> So, is this woth a PR?
isnan is overloaded. There's "int isnan(double)" in math.h and
"bool isnan(arithmetic)" in cmath. When you call isnan(1.0),
isnan(double) is selected.
I think isnan(double) and isinf(double) in math.h should only be
visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999.
For C99 and higher there should only be the isnan/isinf macros.
CCed standards@.
signature.asc
Description: OpenPGP digital signature
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
< said: > I think isnan(double) and isinf(double) in math.h should only be > visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. > For C99 and higher there should only be the isnan/isinf macros. I believe you are correct. POSIX.1-2008 (which is aligned with C99) consistently calls isnan() a "macro", and gives a pseudo-prototype of int isnan(real-floating x); -GAWollman ___ 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 crash during heavy disk access
I still get issues with latest stable/9 and panics during or just after a bunch of disk IO. I can try to reproduce this if you'd like. -adrian ___ 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"
hacking - aio_sendfile()
Hiya, I've started writing an aio_sendfile() syscall. http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff Yes, the diff is against -HEAD and not stable/9. It's totally horrible, hackish and likely bad. I've only done some very, very basic testing to ensure it actually works; i haven't at all stress tested it out yet. It's also very naive - I'm not at all doing any checks to see whether I can short-cut to do the aio there and then; I'm always queuing the sendfile() op through the worker threads. That's likely stupid and inefficient in a lot of cases, but it at least gets the syscall up and working. I'd like some feedback and possibly some help in stress testing it to make sure it's functioning well. Thanks, -adrian ___ 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"
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-07-11 02:56:02 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-11 02:56:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-11 02:56:02 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-07-11 02:56:02 - cleaning the object tree TB --- 2013-07-11 02:56:56 - /usr/local/bin/svn stat /src TB --- 2013-07-11 02:57:06 - At svn revision 253161 TB --- 2013-07-11 02:57:07 - building world TB --- 2013-07-11 02:57:07 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 02:57:07 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 02:57:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 02:57:07 - SRCCONF=/dev/null TB --- 2013-07-11 02:57:07 - TARGET=sparc64 TB --- 2013-07-11 02:57:07 - TARGET_ARCH=sparc64 TB --- 2013-07-11 02:57:07 - TZ=UTC TB --- 2013-07-11 02:57:07 - __MAKE_CONF=/dev/null TB --- 2013-07-11 02:57:07 - cd /src TB --- 2013-07-11 02:57:07 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Jul 11 02:57:14 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jul 11 04:07:01 UTC 2013 TB --- 2013-07-11 04:07:01 - generating LINT kernel config TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf TB --- 2013-07-11 04:07:01 - /usr/bin/make -B LINT TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf TB --- 2013-07-11 04:07:01 - /usr/sbin/config -m LINT TB --- 2013-07-11 04:07:01 - building LINT kernel TB --- 2013-07-11 04:07:01 - CROSS_BUILD_TESTING=YES TB --- 2013-07-11 04:07:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-11 04:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-11 04:07:01 - SRCCONF=/dev/null TB --- 2013-07-11 04:07:01 - TARGET=sparc64 TB --- 2013-07-11 04:07:01 - TARGET_ARCH=sparc64 TB --- 2013-07-11 04:07:01 - TZ=UTC TB --- 2013-07-11 04:07:01 - __MAKE_CONF=/dev/null TB --- 2013-07-11 04:07:01 - cd /src TB --- 2013-07-11 04:07:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jul 11 04:07:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_monitor.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-f
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Wed, 10 Jul 2013, Garrett Wollman wrote: < said: I think isnan(double) and isinf(double) in math.h should only be visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999. For C99 and higher there should only be the isnan/isinf macros. I believe you are correct. POSIX.1-2008 (which is aligned with C99) consistently calls isnan() a "macro", and gives a pseudo-prototype of int isnan(real-floating x); Almost any macro may be implemented as a function, if no conforming program can tell the difference. It is impossible for technical reasons to implement isnan() as a macro (except on weird implementations where all real-floating types are physically the same). In the FreeBSD implementation, isnan() is a macro, but it is also a function, and the macro expands to the function in double precision: % #define isnan(x)\ % ((sizeof (x) == sizeof (float)) ? __isnanf(x) \ % : (sizeof (x) == sizeof (double)) ? isnan(x) \ % : __isnanl(x)) I don't see how any conforming program can access the isnan() function directly. It is just as protected as __isnan() would be. (isnan)() gives the function (the function prototype uses this), but conforming programs can't do that since the function might not exist. Maybe some non-conforming program like autoconfig reads or libm.a and creates a bug for C++. The FreeBSD isnan() implementation would be broken by removing the isnan() function from libm.a or ifdefing it in . Changing the function to __isnan() would cause compatibility problems. The function is intentionally named isnan() to reduce compatibility problems. OTOH, the all of the extern sub-functions that are currently used should bever never be used, since using them gives a very low quality of implementation: - the functions are very slow - the functions have names that confuse compilers and thus prevent compilers from replacing them by builtins. Currently, only gcc automatically replaces isnan() by __builtin_isnan(). This only works in double precision. So the FreeBSD implementation only works right in double precision too, only with gcc, __because__ it replaces the macro isnan(x) by the function isnan(x). The result is inline expansion, the same as if the macro isnan() is replaced by __builtin_isnan(). clang never does this automatic replacement, so it generates calls to the slow library functions. Other things go wrong for gcc in other precisions: - if is not included, then isnan(x) gives __builtin_isnan((double)x). This sort of works on x86, but is low quality since it is broken for signaling NaNs (see below). One of the main reasons reason for the existence of the classification macros is that simply converting the arg to a common type and classifying the result doesn't always work. - if is not included, then spelling the API isnanf() or isnanl() gives correct results but a warning about these APIs not being declared. These APIs are nonstandard but are converted to __builtin_isnan[fl] by gcc. - if is included, then: - if the API is spelled isnan(), then the macro converts to __isnanf() or __isnanl(). gcc doesn't understand these, and the slow extern functions are used. - if the API is spelled isnanf() or isnanl(), then the result is correct and the warning magically goes away. declares isnanf(), but gcc apparently declares both iff is included. gcc also optimizes isnanl() on a float arg to __builtin_isnanf(). - no function version can work in some cases, because any function version may have unwanted side effects. This is another of the main reason for the existence of these and other macros. The main unwanted side effect is signaling for signaling NaNs. C99 doesn't really support signaling NaNs, even with the IEC 60559 extensions, so almost anything is allowed for them. But IEEE 854 is fairly clear that isnan() and classification macros shouldn't raise any exceptions. IEEE 854 is even clearer that copying values without changing their representation should (shall?) not cause exceptions. But on i387, just loading a float or double value changes its representation and generates an exception for signaling NaNs, while just loading a long double value conforms to IEEE 854 and doesn't change its representation or generate an exception. Passing of args to functions may or may not load the values. ABIs may require a change of representation. On i387, passing of double args should go through the FPU for efficiency reasons, and this changes the representation twice to not even get back to the original (for signaling NaNs, it generates an exception and sets the quiet bit in the result; thus a classification function can never see a signaling NaN in double precision). So a high quality inplementation must not use function versions, and it must also use builtins that don't
Re: [head tinderbox] failure on sparc64/sparc64
I don't get why this is dying. any ideas? adrian On 10 July 2013 21:18, FreeBSD Tinderbox wrote: > TB --- 2013-07-11 02:56:02 - tinderbox 2.10 running on > freebsd-current.sentex.ca > TB --- 2013-07-11 02:56:02 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE > FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 > d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 > TB --- 2013-07-11 02:56:02 - starting HEAD tinderbox run for sparc64/sparc64 > TB --- 2013-07-11 02:56:02 - cleaning the object tree > TB --- 2013-07-11 02:56:56 - /usr/local/bin/svn stat /src > TB --- 2013-07-11 02:57:06 - At svn revision 253161 > TB --- 2013-07-11 02:57:07 - building world > TB --- 2013-07-11 02:57:07 - CROSS_BUILD_TESTING=YES > TB --- 2013-07-11 02:57:07 - MAKEOBJDIRPREFIX=/obj > TB --- 2013-07-11 02:57:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-07-11 02:57:07 - SRCCONF=/dev/null > TB --- 2013-07-11 02:57:07 - TARGET=sparc64 > TB --- 2013-07-11 02:57:07 - TARGET_ARCH=sparc64 > TB --- 2013-07-11 02:57:07 - TZ=UTC > TB --- 2013-07-11 02:57:07 - __MAKE_CONF=/dev/null > TB --- 2013-07-11 02:57:07 - cd /src > TB --- 2013-07-11 02:57:07 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Thu Jul 11 02:57:14 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jul 11 04:07:01 UTC 2013 > TB --- 2013-07-11 04:07:01 - generating LINT kernel config > TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf > TB --- 2013-07-11 04:07:01 - /usr/bin/make -B LINT > TB --- 2013-07-11 04:07:01 - cd /src/sys/sparc64/conf > TB --- 2013-07-11 04:07:01 - /usr/sbin/config -m LINT > TB --- 2013-07-11 04:07:01 - building LINT kernel > TB --- 2013-07-11 04:07:01 - CROSS_BUILD_TESTING=YES > TB --- 2013-07-11 04:07:01 - MAKEOBJDIRPREFIX=/obj > TB --- 2013-07-11 04:07:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2013-07-11 04:07:01 - SRCCONF=/dev/null > TB --- 2013-07-11 04:07:01 - TARGET=sparc64 > TB --- 2013-07-11 04:07:01 - TARGET_ARCH=sparc64 > TB --- 2013-07-11 04:07:01 - TZ=UTC > TB --- 2013-07-11 04:07:01 - __MAKE_CONF=/dev/null > TB --- 2013-07-11 04:07:01 - cd /src > TB --- 2013-07-11 04:07:01 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Jul 11 04:07:01 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything > [...] > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys > -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 > --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float > -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_mesh.c > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys > -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 > --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float > -ffreestanding -fstack-protector -Werror > /src/sys/net80211/ieee80211_monitor.c > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys > -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 > --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float > -ffreestanding -fstack-protector -Werror /src/sys/net80211/ieee80211_node.c > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-ex
Re: hacking - aio_sendfile()
On Wed, Jul 10, 2013 at 04:36:23PM -0700, Adrian Chadd wrote: > Hiya, > > I've started writing an aio_sendfile() syscall. > > http://people.freebsd.org/~adrian/ath/20130710-aio-sendfile-3.diff > > Yes, the diff is against -HEAD and not stable/9. > > It's totally horrible, hackish and likely bad. I've only done some > very, very basic testing to ensure it actually works; i haven't at all > stress tested it out yet. It's also very naive - I'm not at all doing > any checks to see whether I can short-cut to do the aio there and > then; I'm always queuing the sendfile() op through the worker threads. > That's likely stupid and inefficient in a lot of cases, but it at > least gets the syscall up and working. Yes, it is naive, but for different reason. The kern_sendfile() is synchronous function, it only completes after the other end of the network communication allows it. This means that calling kern_sendfile() from the aio thread blocks the thread indefinitely by unbounded sleep. Your implementation easily causes exhaustion of the aio thread pool, blocking the whole aio subsystem. It is known that our aio does not work for sockets for the same reason. I object against adding more code with the same defect. Proper route seems to rewrite aio for sockets using the upcalls. The same should be done for sendfile, if sendfile is given aio flavor. > > I'd like some feedback and possibly some help in stress testing it to > make sure it's functioning well. > > Thanks, > > > -adrian > ___ > 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" pgpGk5VC33yBq.pgp Description: PGP signature
