Re: reducing build times; selecting specific clang targets

[Ed Schouten]

Hi Michael,

2017-12-09 4:57 GMT+01:00 Michael Butler :
> As clang builds for multiple targets unconditionally, it takes *days* to
> build on one of my devices (700MHz Pentium-3).
>
> Is there a way to restrict the build targets to i386 only? If not, can we
> implement one?

Regardless of the discussion of how and whether this may be
implemented, do take into consideration that the target specific bits
in Clang only account for a minority of the build time. It is not as
if Clang is literally built multiple times, once for every
architecture. The build will likely still take several days, even if
this got fixed.

Have you considered doing builds on some other system and copying the
results over? According to Wikipedia, they stopped producing Pentium
III CPUs 14 years ago. Using these systems to do actual builds sounds
like a waste of electricity.

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

reducing build times; selecting specific clang targets

[Michael Butler]

As clang builds for multiple targets unconditionally, it takes *days* to 
build on one of my devices (700MHz Pentium-3).


Is there a way to restrict the build targets to i386 only? If not, can 
we implement one?


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

Re: GPTZFSBOOT in Current r326622 has problems

[Warner Losh]

On Fri, Dec 8, 2017 at 7:31 PM, Thomas Laus  wrote:

> Warner Losh [i...@bsdimp.com] wrote:
> > Looks like  -DEFI_ZFS_BOOT was dropped from boot1.c in r326589. I've
> fixed
> > it in r326714.
> >
> Warren:
>
> I just completed a buildworld on r326720 and it failed to boot again
> with a hex dump and BTX failure.  I can take a photograph and post it
> somewhere of the hex dump if it would provide additional information.
> I can also send you an email with the photo attached.
>
>
Clean build?

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

Re: GPTZFSBOOT in Current r326622 has problems

[Thomas Laus]

Warner Losh [i...@bsdimp.com] wrote:
> Looks like  -DEFI_ZFS_BOOT was dropped from boot1.c in r326589. I've fixed
> it in r326714.
>
Warren:

I just completed a buildworld on r326720 and it failed to boot again
with a hex dump and BTX failure.  I can take a photograph and post it
somewhere of the hex dump if it would provide additional information.
I can also send you an email with the photo attached.

Tom

-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[PATCH] Document powl and tgammal kludges

[Steve Kargl]

The following patch documents the remaining kludges that
theraven@ committed in r255294 on 2013-09-06.  I have
cleaned up all of the others, but powl and tgammal remain. 
ngie@ seems to have documented the existence of powl with
r290605, but did not document the rather poor numerical
accuracy of the result.  tgammal remains undocumented.  As it
is unlikely that theraven@ will document the nature of his
kludge nor the existence of tgammal,  I have have prepared
a patch that documents the expected numerical accuracy in BUGS
sections, and have also documented tgammal.


Index: msun/man/exp.3
===
--- msun/man/exp.3  (revision 2046)
+++ msun/man/exp.3  (working copy)
@@ -28,7 +28,7 @@
 .\" from: @(#)exp.36.12 (Berkeley) 7/31/91
 .\" $FreeBSD: head/lib/msun/man/exp.3 290606 2015-11-09 10:41:27Z ngie $
 .\"
-.Dd November 9, 2015
+.Dd December 8, 2017
 .Dt EXP 3
 .Os
 .Sh NAME
@@ -180,6 +180,15 @@
 then \*(Na**0 = 1 too because x**0 = 1 for all finite
 and infinite x, i.e., independently of x.
 .El
+.Sh BUGS
+To conform with newer C/C++ standards, a stub implementation for
+.Nm powl
+was committed to the math library, where
+.Nm powl
+is mapped to
+.Nm pow .
+Thus, the numerical accuracy is at most that of the 53-bit double
+precision implementation.
 .Sh SEE ALSO
 .Xr fenv 3 ,
 .Xr ldexp 3 ,
Index: msun/man/lgamma.3
===
--- msun/man/lgamma.3   (revision 2046)
+++ msun/man/lgamma.3   (working copy)
@@ -28,7 +28,7 @@
 .\" from: @(#)lgamma.3 6.6 (Berkeley) 12/3/92
 .\" $FreeBSD: head/lib/msun/man/lgamma.3 282015 2015-04-26 11:35:07Z bapt $
 .\"
-.Dd September 12, 2014
+.Dd December 8, 2017
 .Dt LGAMMA 3
 .Os
 .Sh NAME
@@ -43,7 +43,8 @@
 .Nm gammaf ,
 .Nm gammaf_r ,
 .Nm tgamma ,
-.Nm tgammaf
+.Nm tgammaf ,
+.Nm tgammal ,
 .Nd log gamma functions, gamma function
 .Sh LIBRARY
 .Lb libm
@@ -76,6 +77,8 @@
 .Fn tgamma "double x"
 .Ft float
 .Fn tgammaf "float x"
+.Ft "long double"
+.Fn tgammal "long double x"
 .Sh DESCRIPTION
 .Fn lgamma x ,
 .Fn lgammaf x ,
@@ -106,9 +109,10 @@
 but the caller must provide an integer to store the sign of \(*G(x).
 .Pp
 The
-.Fn tgamma x
+.Fn tgamma x ,
+.Fn tgammaf x ,
 and
-.Fn tgammaf x
+.Fn tgammal x
 functions return \(*G(x), with no effect on
 .Fa signgam .
 .Pp
@@ -166,6 +170,15 @@
 For large non-integer negative values,
 .Fn tgamma
 will underflow.
+.Sh BUGS
+To conform with newer C/C++ standards, a stub implementation for
+.Nm tgammal
+was committed to the math library, where
+.Nm tgammal
+is mapped to
+.Nm tgammal .
+Thus, the numerical accuracy is at most that of the 53-bit double
+precision implementation.
 .Sh SEE ALSO
 .Xr math 3
 .Sh STANDARDS
@@ -174,8 +187,9 @@
 .Fn lgammaf ,
 .Fn lgammal ,
 .Fn tgamma ,
+.Fn tgammaf ,
 and
-.Fn tgammaf
+.Fn tgammal
 functions are expected to conform to
 .St -isoC-99 .
 .Sh HISTORY


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

Re: GPTZFSBOOT in Current r326622 has problems

[Warner Losh]

Looks like  -DEFI_ZFS_BOOT was dropped from boot1.c in r326589. I've fixed
it in r326714.

Warner

On Thu, Dec 7, 2017 at 5:44 AM, Thomas Laus  wrote:

> On 12/06/17 19:38, Warner Losh wrote:
> >
> > OK. Still a fair number of changes, including changes to geli to fix
> > warnings...
> >
> > 326585-326594 is a flurry of changes. Then another in the 326609-326610
> > range. There's one other trivial one. I'd wager that if '500 works, the
> > breakage will be somewhere in the first range, which suggests 326590
> > might be a good, next pivot. There's also a few just after '500 that
> > might break things as well if I messed something up. '504 and '507 both
> > touch this stuff directly...
> >
> Warren:
>
> I reverted my system back to r326585 and 'stand' still won't compile;  I
> get this output:
>
> --- g_eli_hmac.o ---
> In file included from /usr/src/sys/geom/eli/g_eli_hmac.c:46:
> In file included from /usr/src/sys/geom/eli/g_eli.h:49:
> /usr/include/stdio.h:267:12: error: type specifier missing, defaults to
> 'int' [-Werror,-Wimplicit-int]
> char*gets(char *);
>   ^
> /usr/include/stdio.h:267:7: error: expected parameter declarator
> char*gets(char *);
>  ^
> /usr/src/stand/libsa/stand.h:271:28: note: expanded from macro 'gets'
> #define gets(x) ngets((x), 0)
>^
> In file included from /usr/src/sys/geom/eli/g_eli_hmac.c:46:
> In file included from /usr/src/sys/geom/eli/g_eli.h:49:
> /usr/include/stdio.h:267:7: error: expected ')'
> /usr/src/stand/libsa/stand.h:271:28: note: expanded from macro 'gets'
> #define gets(x) ngets((x), 0)
>^
> /usr/include/stdio.h:267:7: note: to match this '('
> /usr/src/stand/libsa/stand.h:271:22: note: expanded from macro 'gets'
> #define gets(x) ngets((x), 0)
>  ^
> In file included from /usr/src/sys/geom/eli/g_eli_hmac.c:46:
> In file included from /usr/src/sys/geom/eli/g_eli.h:49:
> /usr/include/stdio.h:267:7: error: conflicting types for 'ngets'
> char*gets(char *);
>  ^
> /usr/src/stand/libsa/stand.h:271:17: note: expanded from macro 'gets'
> #define gets(x) ngets((x), 0)
> ^
> /usr/src/stand/libsa/stand.h:270:13: note: previous declaration is here
> extern void ngets(char *, int);
> ^
> In file included from /usr/src/sys/geom/eli/g_eli_hmac.c:46:
> In file included from /usr/src/sys/geom/eli/g_eli.h:49:
> /usr/include/stdio.h:271:6: error: conflicting types for 'putchar'
> int  putchar(int);
>  ^
> /usr/src/stand/libsa/stand.h:382:14: note: previous declaration is here
> extern void putchar(int);
> ^
> In file included from /usr/src/sys/geom/eli/g_eli_hmac.c:46:
> In file included from /usr/src/sys/geom/eli/g_eli.h:49:
> /usr/include/stdio.h:286:6: error: conflicting types for 'vprintf'
> int  vprintf(const char * __restrict, __va_list);
>  ^
> /usr/src/stand/libsa/stand.h:262:13: note: previous declaration is here
> extern void vprintf(const char *fmt, __va_list);
> ^
> In file included from /usr/src/sys/geom/eli/g_eli_hmac.c:46:
> /usr/src/stand/libsa/stand.h:265:13: note: previous declaration is here
> extern void vsprintf(char *buf, const char *cfmt, __va_list);
> ^
> 7 errors generated.
> *** [g_eli_hmac.o] Error code 1
>
> make[1]: stopped in /usr/src/stand/geli
> 1 error
>
> make[1]: stopped in /usr/src/stand/geli
> *** [all_subdir_geli] Error code 2
>
> make: stopped in /usr/src/stand
> 1 error
>
> make: stopped in /usr/src/stand
>
>
> Tom
>
> --
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Breakage with sys.kern.ptrace_test.{ptrace__parent_sees_exit_after_child_debugger, parent_sees_exit_after_unrelated_debugger} after r325719:325721

[Mark Johnston]

On Thu, Nov 16, 2017 at 09:07:56AM -0800, Ngie Cooper (yaneurabeya) wrote:
> Hi Mateusz,
>   Per Jenkins, these two tests are broken after r325719:325721: 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-test/4987/ 
>  .
> Thanks,
> -Ngie

Ping? These tests are still failing.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: valloric YCM [header definitions]

[Gary Jennejohn]

On Fri, 8 Dec 2017 21:23:04 +0800
blubee blubeeme  wrote:

> On Wed, Dec 6, 2017 at 2:18 AM, blubee blubeeme  wrote:
> 
> > I'm looking for where the u_int, u_long headers are defined?
> >

These are not headers, they're typedefs.

These are defined in /usr/include/sys/types.h.  This is the standard
loacation for globally used typedefs.

> > for instance MOD_LOAD, UNLOAD, ENOTSUP along with u_int and u_long aren't
> > being picked up by libclang
> >

Errors like ENOTSUP are defined in /usr/include/sys/errno.h.  This is
the standard location for globally used error codes.

> > module_t isn't being found either but I located that header file in
> > /usr/include/sys/module.h
> >
> > snd_modevent(module_t mod, int type, void *data)
> > {
> >
> > switch (type) {
> > case MOD_LOAD:
> > break;
> > case MOD_UNLOAD:
> > break;
> > default:
> > return (ENOTSUP);
> > break;
> > }
> > return 0;
> > }
> >
> > Anyone here uses YCM?
> >

[snip]

Apparently not.

You seem to have all the usual include paths in the list.  No idea
why it's not working.

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

Re: valloric YCM [header definitions]

[Hans Petter Selasky]

On 12/08/17 14:23, blubee blubeeme wrote:

On Wed, Dec 6, 2017 at 2:18 AM, blubee blubeeme  wrote:


Hi,

These questions are better off at questi...@freebsd.org :-)


I'm looking for where the u_int, u_long headers are defined?


Anyway, it appears you are having some fun figuring out how the FreeBSD 
sources are organized.


Everything in /usr/include is only meant for user-space.

Integer types are defined by  and  .

grep -rE "^typedef.*u_int" /usr/include/



for instance MOD_LOAD, UNLOAD, ENOTSUP along with u_int and u_long aren't
being picked up by libclang

module_t isn't being found either but I located that header file in
/usr/include/sys/module.h

snd_modevent(module_t mod, int type, void *data)
{

switch (type) {
case MOD_LOAD:
break;
case MOD_UNLOAD:
break;
default:
return (ENOTSUP);
break;
}
return 0;
}

Anyone here uses YCM?



I recommend not compiling kernel code outside the Makefile environment.

Examples of valid kernel-side Makefiles you find in /usr/src/sys/modules

make -C /usr/src/sys/modules/sound clean
make -C /usr/src/sys/modules/sound depend
make -C /usr/src/sys/modules/sound all


Here's a verbose output of my global ycm_config. I hard coded the values
to test but still some headers like u_int, u_long and the above mentioned
MOD_* aren't being picked up.


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

Re: valloric YCM [header definitions]

[blubee blubeeme]

On Wed, Dec 6, 2017 at 2:18 AM, blubee blubeeme  wrote:

> I'm looking for where the u_int, u_long headers are defined?
>
> for instance MOD_LOAD, UNLOAD, ENOTSUP along with u_int and u_long aren't
> being picked up by libclang
>
> module_t isn't being found either but I located that header file in
> /usr/include/sys/module.h
>
> snd_modevent(module_t mod, int type, void *data)
> {
>
> switch (type) {
> case MOD_LOAD:
> break;
> case MOD_UNLOAD:
> break;
> default:
> return (ENOTSUP);
> break;
> }
> return 0;
> }
>
> Anyone here uses YCM?
>
> Here's a verbose output of my global ycm_config. I hard coded the values
> to test but still some headers like u_int, u_long and the above mentioned
> MOD_* aren't being picked up.
>
> Any ideas why?
>
> '-std=c99',
> '-x',
> 'c',
> '-I',
> '/usr/local/include',
> '-I',
> '/usr/include',
> '-I',
> '/usr/include/teken',
> '-I',
> '/usr/include/geom',
> '-I',
> '/usr/include/netgraph',
> '-I',
> '/usr/include/isofs',
> '-I',
> '/usr/include/net80211',
> '-I',
> '/usr/include/gssapi',
> '-I',
> '/usr/include/xlocale',
> '-I',
> '/usr/include/netpfil',
> '-I',
> '/usr/include/gcc',
> '-I',
> '/usr/include/bsnmp',
> '-I',
> '/usr/include/libxo',
> '-I',
> '/usr/include/ssp',
> '-I',
> '/usr/include/devdctl',
> '-I',
> '/usr/include/security',
> '-I',
> '/usr/include/crypto',
> '-I',
> '/usr/include/cam',
> '-I',
> '/usr/include/rdma',
> '-I',
> '/usr/include/infiniband',
> '-I',
> '/usr/include/rpcsvc',
> '-I',
> '/usr/include/atf-c',
> '-I',
> '/usr/include/netnatm',
> '-I',
> '/usr/include/ufs',
> '-I',
> '/usr/include/edit',
> '-I',
> '/usr/include/nfsserver',
> '-I',
> '/usr/include/netsmb',
> '-I',
> '/usr/include/gnu',
> '-I',
> '/usr/include/net',
> '-I',
> '/usr/include/private',
> '-I',
> '/usr/include/nfsclient',
> '-I',
> '/usr/include/openssl',
> '-I',
> '/usr/include/libmilter',
> '-I',
> '/usr/include/atf-c++',
> '-I',
> '/usr/include/netinet6',
> '-I',
> '/usr/include/x86',
> '-I',
> '/usr/include/dev',
> '-I',
> '/usr/include/bsm',
> '-I',
> '/usr/include/netipsec',
> '-I',
> '/usr/include/netinet',
> '-I',
> '/usr/include/krb5',
> '-I',
> '/usr/include/casper',
> '-I',
> '/usr/include/protocols',
> '-I',
> '/usr/include/lib80211',
> '-I',
> '/usr/include/arpa',
> '-I',
> '/usr/include/pcap',
> '-I',
> '/usr/include/nfs',
> '-I',
> '/usr/include/machine',
> '-I',
> '/usr/include/fs',
> '-I',
> '/usr/include/sys',
> '-I',
> '/usr/include/rpc',
> '-I',
> '/usr/include/kadm5',
> '-I',
> '/usr/include/vm',
> '-I',
> '/usr/include/c++',
> '-I',
> '/usr/include/lzma',
> '-I',
> '/sys',
> '-I',
> '/dev',
> '-I',
> '/usr/src',
>
>
There's no one on this mailing list that uses YCM for their FreeBSD
development?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"