svn commit: r335812 - head/sys/dev/iwn

2018-06-29 Thread Eitan Adler
Author: eadler
Date: Sat Jun 30 04:30:08 2018
New Revision: 335812
URL: https://svnweb.freebsd.org/changeset/base/335812

Log:
  iwn: Add the missing IWN_SDID_6035_5 subdevice
  
  Obtained from:Haiku (da166fc6469b98397de98a7ccc13b82a3cd3b290)

Modified:
  head/sys/dev/iwn/if_iwn.c
  head/sys/dev/iwn/if_iwn_devid.h

Modified: head/sys/dev/iwn/if_iwn.c
==
--- head/sys/dev/iwn/if_iwn.c   Sat Jun 30 01:04:37 2018(r335811)
+++ head/sys/dev/iwn/if_iwn.c   Sat Jun 30 04:30:08 2018(r335812)
@@ -862,6 +862,7 @@ iwn_config_specific(struct iwn_softc *sc, uint16_t pid
case IWN_SDID_6035_2:
case IWN_SDID_6035_3:
case IWN_SDID_6035_4:
+   case IWN_SDID_6035_5:
sc->fwname = "iwn6000g2bfw";
sc->limits = _sensitivity_limits;
sc->base_params = _6235_base_params;

Modified: head/sys/dev/iwn/if_iwn_devid.h
==
--- head/sys/dev/iwn/if_iwn_devid.h Sat Jun 30 01:04:37 2018
(r335811)
+++ head/sys/dev/iwn/if_iwn_devid.h Sat Jun 30 04:30:08 2018
(r335812)
@@ -170,6 +170,7 @@
 #defineIWN_SDID_6035_2 0x4260
 #defineIWN_SDID_6035_3 0x4460
 #defineIWN_SDID_6035_4 0x4860
+#defineIWN_SDID_6035_5 0x5260
 /*
  * --
  * Device ID for 1030 and 6030 Series
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-29 Thread Ryan Libby
[Re-sending from my subscription address, sorry for the spam]

On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin  wrote:
> On 6/28/18 7:54 PM, Mark Millard wrote:
>> On 2018-Jun-28, at 6:04 PM, Mark Millard  wrote:
>>
>>> On 2018-Jun-28, at 5:39 PM, Mark Millard  wrote:
>>>
 [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
 for FreeBSD-head-amd64-gcc. It looked to me like the most likely
 breaking-change was the following but I've not tried personal
 builds to confirm.
 ]
>
> So this is a bit complicated and I'm not sure what the correct fix is.
>
> What is happening is that the  shipped with GCC is now being used
> after this change instead of sys/x86/include/float.h.  A sledgehammer approach
> would be to remove float.h from the GCC package (we currently don't install
> the float.h for the base system clang either).  However, looking at this
> in more detail, it seems that x86/include/float.h is also busted in some
> ways.
>
> First, the #error I don't understand how it is happening.  The GCC float.h
> defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just
> like the x86 float.h:
>
> # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP
> #define __LDBL_MAX_EXP__ 16384
>
> I even hacked catrigl.c to add the following lines before the #error
> check:
>
> LDBL_MAX_EXP_ = LDBL_MAX_EXP
> LDBL_MANT_DIG_ = LDBL_MANT_DIG
>
> #if LDBL_MAX_EXP != 0x4000
> #error "Unsupported long double format"
> #endif
>
> And the -E output is:
>
> DBL_MAX_EXP_ = 16384
> LDBL_MANT_DIG_ = 53
>
> # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error 
> "U
> nsupported long double format"
>  #error "Unsupported long double format"
>   ^
>
> Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which
> it must be since the x86 float.h uses '16384' not '0x4000' as the value).
>

Isn't this just the unsupported LDBL_MANT_DIG you're hitting here?  Note
line 93.  I reused the same error message for LDBL_MAX_EXP :/

> However, LDBL_MANT_DIG of 53 is a bit more fun.  We have a comment about the
> initial FPU control word in sys/amd64/include/fpu.h that reads thus:
>
> /*
>  * The hardware default control word for i387's and later coprocessors is
>  * 0x37F, giving:
>  *
>  *  round to nearest
>  *  64-bit precision
>  *  all exceptions masked.
>  *
>  * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc
>  * because of the difference between memory and fpu register stack arguments.
>  * If its using an intermediate fpu register, it has 80/64 bits to work
>  * with.  If it uses memory, it has 64/53 bits to work with.  However,
>  * gcc is aware of this and goes to a fair bit of trouble to make the
>  * best use of it.
>  *
>  * This is mostly academic for AMD64, because the ABI prefers the use
>  * SSE2 based math.  For FreeBSD/amd64, we go with the default settings.
>  */
> #define __INITIAL_FPUCW__   0x037F
> #define __INITIAL_FPUCW_I386__  0x127F
> #define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__
> #define __INITIAL_MXCSR__   0x1F80
> #define __INITIAL_MXCSR_MASK__  0xFFBF
>
> GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in
> __LDBL_MANT_DIG__ being set to 53 instead of 64:
>
> /* FreeBSD sets the rounding precision of the FPU to 53 bits.  Let the
>compiler get the contents of  and std::numeric_limits correct.  */
> #undef TARGET_96_ROUND_53_LONG_DOUBLE
> #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT)
>
> clang seems unaware of this as it reports all the same values for
> LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64
> but not i386):
>
> # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__'
> #define __LDBL_MAX__ 1.18973149535723176502e+4932L
> #define __LDBL_MIN__ 3.36210314311209350626e-4932L
> # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__'
> #define __LDBL_MAX__ 1.18973149535723176502e+4932L
> #define __LDBL_MIN__ 3.36210314311209350626e-4932L
> # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__'
> #define __LDBL_MAX__ 1.18973149535723176502e+4932L
> #define __LDBL_MIN__ 3.36210314311209350626e-4932L
> # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep 
> 'LDBL_(MIN|MAX)__'
> #define __LDBL_MAX__ 1.1897314953572316e+4932L
> #define __LDBL_MIN__ 3.3621031431120935e-4932L
>
> The x86/include/float.h header though reports the MIN/MAX values somewhere
> in between the two ranges for both amd64 and i386 while reporting an
> LDBL_MANT_DIG of 64:
>
> #define LDBL_MANT_DIG   64
> #define LDBL_MIN3.3621031431120935063E-4932L
> #define LDBL_MAX1.1897314953572317650E+4932L
>
> I guess for now I will remove float.h from the amd64-gcc pkg-plist, but we
> should really be fixing our tree to work with compiler-provided language
> headers when at all possible.  It's not clear to me if amd64 should be
> using the compiler provided values of things like LDBL_MIN/MAX either btw.
>
> 

svn commit: r335811 - head/share/misc

2018-06-29 Thread Eitan Adler
Author: eadler
Date: Sat Jun 30 01:04:37 2018
New Revision: 335811
URL: https://svnweb.freebsd.org/changeset/base/335811

Log:
  bsd-family-tree: Announce DragonFly version 5.2.2
  
  Obtained from:https://www.dragonflybsd.org/release52/

Modified:
  head/share/misc/bsd-family-tree

Modified: head/share/misc/bsd-family-tree
==
--- head/share/misc/bsd-family-tree Sat Jun 30 01:02:59 2018
(r335810)
+++ head/share/misc/bsd-family-tree Sat Jun 30 01:04:37 2018
(r335811)
@@ -372,6 +372,7 @@ FreeBSD 5.2   |  | |  
  | |  | |  v   |   |
  | |  | |  |   |   DragonFly 5.2.1
  | |  | |  v   |   |
+ | |  | |  |   |   DragonFly 5.2.2
  |  FreeBSD   | |  |   |
  |   11.2 | |  |   |
  | v  | |  |   |
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335810 - head/share/misc

2018-06-29 Thread Eitan Adler
Author: eadler
Date: Sat Jun 30 01:02:59 2018
New Revision: 335810
URL: https://svnweb.freebsd.org/changeset/base/335810

Log:
  bsd-family-tree: Announce DragonFly version 5.2.2
  
  Obtained from:https://www.dragonflybsd.org/release52/

Modified:
  head/share/misc/bsd-family-tree

Modified: head/share/misc/bsd-family-tree
==
--- head/share/misc/bsd-family-tree Fri Jun 29 23:48:30 2018
(r335809)
+++ head/share/misc/bsd-family-tree Sat Jun 30 01:02:59 2018
(r335810)
@@ -748,6 +748,7 @@ NetBSD 7.1.22018-03-15 [NBD]
 OpenBSD 6.32018-04-02 [OBD]
 DragonFly 5.2.02018-04-10 [DFB]
 DragonFly 5.2.12018-05-20 [DFB]
+DragonFly 5.2.22018-06-18 [DFB]
 FreeBSD 11.2   2018-06-27 [FBD]
 
 Bibliography
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-29 Thread Mark Millard via svn-src-head
On 2018-Jun-29, at 2:37 PM, Mark Millard  wrote:

> [I expect this is more than just amd64-gcc related but that is all
> that ci.freebsd.org normally builds via a devel/*-gcc .]
> 
> On 2018-Jun-29, at 10:38 AM, John Baldwin  wrote:
> 
>> On 6/28/18 7:54 PM, Mark Millard wrote:
>>> On 2018-Jun-28, at 6:04 PM, Mark Millard  wrote:
>>> 
 On 2018-Jun-28, at 5:39 PM, Mark Millard  wrote:
 
 . . .
 Later below expand the failing and previoly good commands, one
 option per line. The summary of the distinction in content is
 a one line difference, the working example ( -r335773 )had the
 option:
 
 -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
 
 but the failing one did not. Working ( -r335773 ) is shown first.
 
 --- catrigl.o ---
 /usr/local/bin/x86_64-unknown-freebsd11.1-gcc
 -DCOMPAT_32BIT
 -march=i686
 -mmmx
 -msse
 -msse2
 -m32
 -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32
 --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp
 -B/usr/local/x86_64-unknown-freebsd11.1/bin/
 -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32
 -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
 -O2
 -pipe
 -I/workspace/src/lib/msun/x86
 -I/workspace/src/lib/msun/ld80
 -I/workspace/src/lib/msun/i387
 -I/workspace/src/lib/msun/src
 -I/workspace/src/lib/libc/include
 -I/workspace/src/lib/libc/i386
 . . .
 
 --- catrigl.o ---
 /usr/local/bin/x86_64-unknown-freebsd11.1-gcc
 -DCOMPAT_32BIT
 -march=i686
 -mmmx
 -msse
 -msse2
 -m32
 -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32
 --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp
 -B/usr/local/x86_64-unknown-freebsd11.1/bin/
 -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32
 -O2
 -pipe
 -I/workspace/src/lib/msun/x86
 -I/workspace/src/lib/msun/ld80
 -I/workspace/src/lib/msun/i387
 -I/workspace/src/lib/msun/src
 -I/workspace/src/lib/libc/include 
 -I/workspace/src/lib/libc/i386
 . . .
>>> 
>>> 
>>> For the report:
>>> 
 The xtoolchain GCC packages have not required these flags since ports
 commits r465416 and r466701
>>> 
>>> Looking at 
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText
>>> there is:
>>> 
 Updating FreeBSD repository catalogue...
 FreeBSD repository is up to date.
 All repositories are up to date.
 The following 6 package(s) will be affected (of 0 checked):
 
 New packages to be INSTALLED:
amd64-xtoolchain-gcc: 0.4_1
amd64-gcc: 6.4.0
mpfr: 4.0.1
gmp: 6.1.2
mpc: 1.1.0_1
amd64-binutils: 2.30_3,1
>>> 
>>> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834
>>> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ).
>>> 
>>> This indicates that -r465416 and -r466701 did not cause:
>>> 
>>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp
>>> 
>>> to lead to include files being looked up in:
>>> 
>>> /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>> 
>>> Thus there appears to still be a need for:
>>> 
>>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>> 
>>> unless more is done to the devel/*-gcc to make them look
>>> in that additional place automatically (based on --sysroot).
>> 
>> --sysroot does work, and you can verify it by doing the following:
>> 
>> % touch empty.c
>> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c
>> Using built-in specs.
>> COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc
>> Target: x86_64-unknown-freebsd11.2
>> ...
>> ignoring nonexistent directory 
>> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed"
>> ignoring nonexistent directory 
>> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include
>> /usr/include
>> End of search list.
>> ...
>> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c  --sysroot=/foo
>> Using built-in specs.
>> COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc
>> Target: x86_64-unknown-freebsd11.2
>> ...
>> ignoring nonexistent directory 
>> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed"
>> ignoring nonexistent directory 
>> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include"
>> ignoring nonexistent directory "/foo/usr/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include
>> End of search list.
>> 
>> I will see if I can reproduce the failure locally.
> 
> The:
> 
> ignoring nonexistent directory "/foo/usr/include"
> 
> 

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-29 Thread Ryan Libby
On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin  wrote:
> On 6/28/18 7:54 PM, Mark Millard wrote:
>> On 2018-Jun-28, at 6:04 PM, Mark Millard  wrote:
>>
>>> On 2018-Jun-28, at 5:39 PM, Mark Millard  wrote:
>>>
 [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
 for FreeBSD-head-amd64-gcc. It looked to me like the most likely
 breaking-change was the following but I've not tried personal
 builds to confirm.
 ]
>
> So this is a bit complicated and I'm not sure what the correct fix is.
>
> What is happening is that the  shipped with GCC is now being used
> after this change instead of sys/x86/include/float.h.  A sledgehammer approach
> would be to remove float.h from the GCC package (we currently don't install
> the float.h for the base system clang either).  However, looking at this
> in more detail, it seems that x86/include/float.h is also busted in some
> ways.
>
> First, the #error I don't understand how it is happening.  The GCC float.h
> defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just
> like the x86 float.h:
>
> # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP
> #define __LDBL_MAX_EXP__ 16384
>
> I even hacked catrigl.c to add the following lines before the #error
> check:
>
> LDBL_MAX_EXP_ = LDBL_MAX_EXP
> LDBL_MANT_DIG_ = LDBL_MANT_DIG
>
> #if LDBL_MAX_EXP != 0x4000
> #error "Unsupported long double format"
> #endif
>
> And the -E output is:
>
> DBL_MAX_EXP_ = 16384
> LDBL_MANT_DIG_ = 53
>
> # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error 
> "U
> nsupported long double format"
>  #error "Unsupported long double format"
>   ^
>
> Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which
> it must be since the x86 float.h uses '16384' not '0x4000' as the value).
>

Isn't this just the unsupported LDBL_MANT_DIG you're hitting here?  Note
line 93.  I reused the same error message for LDBL_MAX_EXP :/

> However, LDBL_MANT_DIG of 53 is a bit more fun.  We have a comment about the
> initial FPU control word in sys/amd64/include/fpu.h that reads thus:
>
> /*
>  * The hardware default control word for i387's and later coprocessors is
>  * 0x37F, giving:
>  *
>  *  round to nearest
>  *  64-bit precision
>  *  all exceptions masked.
>  *
>  * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc
>  * because of the difference between memory and fpu register stack arguments.
>  * If its using an intermediate fpu register, it has 80/64 bits to work
>  * with.  If it uses memory, it has 64/53 bits to work with.  However,
>  * gcc is aware of this and goes to a fair bit of trouble to make the
>  * best use of it.
>  *
>  * This is mostly academic for AMD64, because the ABI prefers the use
>  * SSE2 based math.  For FreeBSD/amd64, we go with the default settings.
>  */
> #define __INITIAL_FPUCW__   0x037F
> #define __INITIAL_FPUCW_I386__  0x127F
> #define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__
> #define __INITIAL_MXCSR__   0x1F80
> #define __INITIAL_MXCSR_MASK__  0xFFBF
>
> GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in
> __LDBL_MANT_DIG__ being set to 53 instead of 64:
>
> /* FreeBSD sets the rounding precision of the FPU to 53 bits.  Let the
>compiler get the contents of  and std::numeric_limits correct.  */
> #undef TARGET_96_ROUND_53_LONG_DOUBLE
> #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT)
>
> clang seems unaware of this as it reports all the same values for
> LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64
> but not i386):
>
> # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__'
> #define __LDBL_MAX__ 1.18973149535723176502e+4932L
> #define __LDBL_MIN__ 3.36210314311209350626e-4932L
> # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__'
> #define __LDBL_MAX__ 1.18973149535723176502e+4932L
> #define __LDBL_MIN__ 3.36210314311209350626e-4932L
> # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__'
> #define __LDBL_MAX__ 1.18973149535723176502e+4932L
> #define __LDBL_MIN__ 3.36210314311209350626e-4932L
> # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep 
> 'LDBL_(MIN|MAX)__'
> #define __LDBL_MAX__ 1.1897314953572316e+4932L
> #define __LDBL_MIN__ 3.3621031431120935e-4932L
>
> The x86/include/float.h header though reports the MIN/MAX values somewhere
> in between the two ranges for both amd64 and i386 while reporting an
> LDBL_MANT_DIG of 64:
>
> #define LDBL_MANT_DIG   64
> #define LDBL_MIN3.3621031431120935063E-4932L
> #define LDBL_MAX1.1897314953572317650E+4932L
>
> I guess for now I will remove float.h from the amd64-gcc pkg-plist, but we
> should really be fixing our tree to work with compiler-provided language
> headers when at all possible.  It's not clear to me if amd64 should be
> using the compiler provided values of things like LDBL_MIN/MAX either btw.
>
> --
> John Baldwin
> 

svn commit: r335809 - in head/sys/contrib/dev/acpica: . common compiler components/hardware components/namespace include

2018-06-29 Thread Jung-uk Kim
Author: jkim
Date: Fri Jun 29 23:48:30 2018
New Revision: 335809
URL: https://svnweb.freebsd.org/changeset/base/335809

Log:
  MFV:  r335802
  
  Merge ACPICA 20180629.

Modified:
  head/sys/contrib/dev/acpica/changes.txt
  head/sys/contrib/dev/acpica/common/dmextern.c
  head/sys/contrib/dev/acpica/compiler/aslglobal.h
  head/sys/contrib/dev/acpica/compiler/aslhelpers.y
  head/sys/contrib/dev/acpica/compiler/aslload.c
  head/sys/contrib/dev/acpica/compiler/aslmain.c
  head/sys/contrib/dev/acpica/compiler/aslmessages.c
  head/sys/contrib/dev/acpica/compiler/aslmessages.h
  head/sys/contrib/dev/acpica/compiler/asloptions.c
  head/sys/contrib/dev/acpica/compiler/aslparser.y
  head/sys/contrib/dev/acpica/compiler/aslprimaries.y
  head/sys/contrib/dev/acpica/compiler/asltransform.c
  head/sys/contrib/dev/acpica/compiler/asltypes.y
  head/sys/contrib/dev/acpica/components/hardware/hwxfsleep.c
  head/sys/contrib/dev/acpica/components/namespace/nsaccess.c
  head/sys/contrib/dev/acpica/components/namespace/nseval.c
  head/sys/contrib/dev/acpica/components/namespace/nssearch.c
  head/sys/contrib/dev/acpica/include/aclocal.h
  head/sys/contrib/dev/acpica/include/acpixf.h
Directory Properties:
  head/sys/contrib/dev/acpica/   (props changed)

Modified: head/sys/contrib/dev/acpica/changes.txt
==
--- head/sys/contrib/dev/acpica/changes.txt Fri Jun 29 22:24:41 2018
(r335808)
+++ head/sys/contrib/dev/acpica/changes.txt Fri Jun 29 23:48:30 2018
(r335809)
@@ -1,4 +1,63 @@
 
+29 June 2018. Summary of changes for version 20180629:
+
+
+1) iASL Compiler/Disassembler and Tools:
+
+iASL: Fixed a regression related to the use of the ASL External 
+statement. Error checking for the use of the External() statement has 
+been relaxed. Previously, a restriction on the use of External meant that 
+the referenced named object was required to be defined in a different 
+table (an SSDT). Thus it would be an error to declare an object as an 
+external and then define the same named object in the same table. For 
+example:
+DefinitionBlock (...)
+{
+External (DEV1)
+Device (DEV1){...} // This was an error
+}
+However, this behavior has caused regressions in some existing ASL code, 
+because there is code that depends on named objects and externals (with 
+the same name) being declared in the same table. This change will allow 
+the ASL code above to compile without errors or warnings.
+
+iASL: Implemented ASL language extensions for four operators to make some 
+of their arguments optional instead of required:
+1) Field (RegionName, AccessType, LockRule, UpdateRule)
+2) BankField (RegionName, BankName, BankValue,
+AccessType, LockRule, UpdateRule)
+3) IndexField (IndexName, DataName,
+AccessType, LockRule, UpdateRule)
+For the Field operators above, the AccessType, LockRule, and UpdateRule 
+are now optional arguments. The default values are:
+AccessType: AnyAcc
+LockRule:   NoLock
+UpdateRule: Preserve
+4) Mutex (MutexName, SyncLevel)
+For this operator, the SyncLevel argument is now optional. This argument 
+is rarely used in any meaningful way by ASL code, and thus it makes sense 
+to make it optional. The default value is:
+SyncLevel:  0
+
+iASL: Attempted use of the ASL Unload() operator now results in the 
+following warning:
+"Unload is not supported by all operating systems"
+This is in fact very true, and the Unload operator may be completely 
+deprecated in the near future.
+
+AcpiExec: Fixed a regression for the -fi option (Namespace initialization 
+file. Recent changes in the ACPICA module-level code support altered the 
+table load/initialization sequence . This means that the table load has 
+become a large method execution of the table itself. If Operation Region 
+Fields are used within any module-level code and the -fi option was 
+specified, the initialization values were populated only after the table 
+had completely finished loading (and thus the module-level code had 
+already been executed). This change moves the initialization of objects 
+listed in the initialization file to before the table is executed as a 
+method. Field unit values are now initialized before the table execution 
+is performed.
+
+
 31 May 2018. Summary of changes for version 20180531:
 
 

Modified: head/sys/contrib/dev/acpica/common/dmextern.c
==
--- head/sys/contrib/dev/acpica/common/dmextern.c   Fri Jun 29 22:24:41 
2018(r335808)
+++ head/sys/contrib/dev/acpica/common/dmextern.c   Fri Jun 29 23:48:30 
2018(r335809)
@@ -538,7 +538,7 @@ AcpiDmGetExternalsFromFile (
 
 /* Each line defines a method */
 
-while (fgets (St

svn commit: r335808 - in head/sys/ufs: ffs ufs

2018-06-29 Thread Kirk McKusick
Author: mckusick
Date: Fri Jun 29 22:24:41 2018
New Revision: 335808
URL: https://svnweb.freebsd.org/changeset/base/335808

Log:
  Create um_flags in the ufsmount structure to hold flags for a UFS filesystem.
  Convert integer structure flags to use um_flags:
  
int um_candelete;   /* devvp supports TRIM */
int um_writesuspended;  /* suspension in progress */
  
  become:
  
  #define UM_CANDELETE  0x0001  /* devvp supports TRIM */
  #define UM_WRITESUSPENDED 0x0002  /* suspension in progress */
  
  This is in preparation for adding other flags to indicate forcible
  unmount in progress after a disk failure and possibly forcible
  downgrade to read-only.
  
  No functional change intended.
  
  Sponsored by: Netflix

Modified:
  head/sys/ufs/ffs/ffs_alloc.c
  head/sys/ufs/ffs/ffs_suspend.c
  head/sys/ufs/ffs/ffs_vfsops.c
  head/sys/ufs/ufs/ufsmount.h

Modified: head/sys/ufs/ffs/ffs_alloc.c
==
--- head/sys/ufs/ffs/ffs_alloc.cFri Jun 29 22:10:40 2018
(r335807)
+++ head/sys/ufs/ffs/ffs_alloc.cFri Jun 29 22:24:41 2018
(r335808)
@@ -495,7 +495,7 @@ ffs_reallocblks(ap)
 * optimization. Also skip if reallocblks has been disabled globally.
 */
ump = ap->a_vp->v_mount->mnt_data;
-   if (ump->um_candelete || doreallocblks == 0)
+   if (((ump->um_flags) & UM_CANDELETE) != 0 || doreallocblks == 0)
return (ENOSPC);
 
/*
@@ -2322,7 +2322,7 @@ ffs_blkfree(ump, fs, devvp, bno, size, inum, vtype, de
 * Nothing to delay if TRIM is disabled, or the operation is
 * performed on the snapshot.
 */
-   if (!ump->um_candelete || devvp->v_type == VREG) {
+   if (((ump->um_flags) & UM_CANDELETE) == 0 || devvp->v_type == VREG) {
ffs_blkfree_cg(ump, fs, devvp, bno, size, inum, dephd);
return;
}

Modified: head/sys/ufs/ffs/ffs_suspend.c
==
--- head/sys/ufs/ffs/ffs_suspend.c  Fri Jun 29 22:10:40 2018
(r335807)
+++ head/sys/ufs/ffs/ffs_suspend.c  Fri Jun 29 22:24:41 2018
(r335808)
@@ -78,7 +78,7 @@ ffs_susp_suspended(struct mount *mp)
sx_assert(_susp_lock, SA_LOCKED);
 
ump = VFSTOUFS(mp);
-   if (ump->um_writesuspended)
+   if ((ump->um_flags & UM_WRITESUSPENDED) != 0)
return (1);
return (0);
 }
@@ -210,7 +210,7 @@ ffs_susp_suspend(struct mount *mp)
if ((error = vfs_write_suspend(mp, VS_SKIP_UNMOUNT)) != 0)
return (error);
 
-   ump->um_writesuspended = 1;
+   ump->um_flags |= UM_WRITESUSPENDED;
 
return (0);
 }
@@ -255,7 +255,7 @@ ffs_susp_dtor(void *data)
 
vfs_write_resume(mp, 0);
vfs_unbusy(mp);
-   ump->um_writesuspended = 0;
+   ump->um_flags &= ~UM_WRITESUSPENDED;
 
sx_xunlock(_susp_lock);
 }

Modified: head/sys/ufs/ffs/ffs_vfsops.c
==
--- head/sys/ufs/ffs/ffs_vfsops.c   Fri Jun 29 22:10:40 2018
(r335807)
+++ head/sys/ufs/ffs/ffs_vfsops.c   Fri Jun 29 22:24:41 2018
(r335808)
@@ -770,6 +770,7 @@ ffs_mountfs(devvp, mp, td)
struct ucred *cred;
struct g_consumer *cp;
struct mount *nmp;
+   int candelete;
 
fs = NULL;
ump = NULL;
@@ -960,8 +961,10 @@ ffs_mountfs(devvp, mp, td)
if ((fs->fs_flags & FS_TRIM) != 0) {
len = sizeof(int);
if (g_io_getattr("GEOM::candelete", cp, ,
-   >um_candelete) == 0) {
-   if (!ump->um_candelete)
+   ) == 0) {
+   if (candelete)
+   ump->um_flags |= UM_CANDELETE;
+   else
printf("WARNING: %s: TRIM flag on fs but disk "
"does not support TRIM\n",
mp->mnt_stat.f_mntonname);
@@ -969,9 +972,8 @@ ffs_mountfs(devvp, mp, td)
printf("WARNING: %s: TRIM flag on fs but disk does "
"not confirm that it supports TRIM\n",
mp->mnt_stat.f_mntonname);
-   ump->um_candelete = 0;
}
-   if (ump->um_candelete) {
+   if (((ump->um_flags) & UM_CANDELETE) != 0) {
ump->um_trim_tq = taskqueue_create("trim", M_WAITOK,
taskqueue_thread_enqueue, >um_trim_tq);
taskqueue_start_threads(>um_trim_tq, 1, PVFS,

Modified: head/sys/ufs/ufs/ufsmount.h
==
--- head/sys/ufs/ufs/ufsmount.h Fri Jun 29 22:10:40 2018(r335807)

Re: svn commit: r335690 - head/sys/kern

2018-06-29 Thread Devin Teske


> On Jun 28, 2018, at 12:36 AM, Warner Losh  wrote:
> 
> 
> 
> On Thu, Jun 28, 2018 at 12:54 AM, Devin Teske  > wrote:
> 
>> On Jun 27, 2018, at 7:35 PM, Warner Losh > > wrote:
>> 
>> 
>> 
>> On Wed, Jun 27, 2018 at 8:14 PM, Devin Teske > > wrote:
>> 
>>> On Jun 27, 2018, at 6:58 PM, Warner Losh >> > wrote:
>>> 
>>> 
>>> 
>>> On Wed, Jun 27, 2018 at 7:49 PM, Devin Teske >> > wrote:
>>> 
 On Jun 27, 2018, at 5:59 PM, Warner Losh >>> > wrote:
 
 
 
 On Wed, Jun 27, 2018 at 5:52 PM, Gleb Smirnoff >>> > wrote:
 On Wed, Jun 27, 2018 at 04:11:09AM +, Warner Losh wrote:
 W> Author: imp
 W> Date: Wed Jun 27 04:11:09 2018
 W> New Revision: 335690
 W> URL: https://svnweb.freebsd.org/changeset/base/335690 
 
 W> 
 W> Log:
 W>   Fix devctl generation for core files.
 W>   
 W>   We have a problem with vn_fullpath_global when the file exists. Work
 W>   around it by printing the full path if the core file name starts with 
 /,
 W>   or current working directory followed by the filename if not.
 
 Is this going to work when a core is dumped not at current working 
 directory,
 but at absolute path? e.g. kern.corefile=/var/log/cores/%N.core
 
 Yes. That works.
  
 Looks like the vn_fullpath_global needs to be fixed rather than problem
 workarounded.
 
 It can't be fixed reliably. FreeBSD does not and cannot map a vnode to a 
 name. The only reason we're able to at all is due to the name cache. And 
 when we recreate a file, we invalidate the name cache. And even if we 
 fixed that, there's no guarantee the name cache won't get flushed before 
 we translate the name Linux can do this because it keeps the path name 
 associated with the inode. FreeBSD simply doesn't.
 
>>> 
>>> They said it couldn't be done, but I personally have done it ...
>>> 
>>> I map vnodes to full paths in dwatch. It's not impossible, just implausibly 
>>> hard.
>>> 
>>> I derived my formula by reading the C code which was very twisty-turny and 
>>> rather hard to read at times (and I have been using C since 1998 on 
>>> everything from AIX and OSF/1 to HP/UX, Cygwin, MinGW, FreeBSD, countless 
>>> Linux-like things, IRIX, and a God-awful remainder of many others; the 
>>> vnode code was an adventure to say the least).
>>> 
>>> You're welcome to see how it's done in /usr/libexec/dwatch/vop_create
>>> 
>>> I load up a clause-local variable named "path" with a path constructed from 
>>> a pointer to a vnode structure argument to VOP_CREATE(9).
>>> 
>>> The D code could easily be rewritten back into C to walk the vnode to 
>>> completion (compared to the D code which is bounded by depth-limit since 
>>> DTrace doesn't provide loops; so you have to, as I have done, use a 
>>> higher-level language wrapper to repeat the code to some desired limit; 
>>> dwatch defaulting to 64 for directory depth limit).
>>> 
>>> Compared this, say, to vfssnoop.d from Chapter 5 of the DTrace book which 
>>> utilizes the vfs:namei:lookup: probes. My approach in dwatch is far more 
>>> accurate, produces full paths, and I've benchmarked it at lower overhead 
>>> with better results.
>>> 
>>> Maybe some of this can be useful? If not, just ignore me.
>>> 
>>> IMHO, there's no benefit from the crazy hoops than the super simple 
>>> heuristic I did: if the path starts with / print it. If the path doesn't 
>>> print cwd / and then the path.
>>> 
>>> I look forward to seeing your conversion of the D to C that works, even 
>>> when there's namespace cache pressure.
>>> 
>> 
>> I was looking at the output of "dwatch -dX vop_create" (the -d flag to 
>> dwatch causes the generated dwatch to be printed instead of executed) and 
>> thinking to myself:
>> 
>> I could easily convert this, as I can recognize the flattened loop 
>> structure. However, not many people will be able to do it. I wasn't really 
>> volunteering, but now I'm curious what other people see when they run 
>> "dwatch -dX vop_create". If it's half as bad as I think it is, then I'll 
>> gladly do it -- but will have to balance it against work priorities.
>> 
>> We don't have the data you do in vop_create anymore, just the vp at the 
>> point in the code where we want to do the reverse translation... But we also 
>> have a name that's been filled in from the template and cwd, which gives us 
>> almost the same thing as we'd hoped to dig out of the name cache...
>> 
> 
> Given:
> 
>   struct vnode *vp, const char *fi_name
> 
> Here's a rough (not optimized; unchecked) crack at a C equivalent:
> 
> Thanks, but this code suffers from the same problem that vn_fullpath_global() 
> suffers from: we clear out parts of the cache when we open an 

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-29 Thread Mark Millard via svn-src-head
[I expect this is more than just amd64-gcc related but that is all
that ci.freebsd.org normally builds via a devel/*-gcc .]

On 2018-Jun-29, at 10:38 AM, John Baldwin  wrote:

> On 6/28/18 7:54 PM, Mark Millard wrote:
>> On 2018-Jun-28, at 6:04 PM, Mark Millard  wrote:
>> 
>>> On 2018-Jun-28, at 5:39 PM, Mark Millard  wrote:
>>> 
>>> . . .
>>> Later below expand the failing and previoly good commands, one
>>> option per line. The summary of the distinction in content is
>>> a one line difference, the working example ( -r335773 )had the
>>> option:
>>> 
>>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>> 
>>> but the failing one did not. Working ( -r335773 ) is shown first.
>>> 
>>> --- catrigl.o ---
>>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc
>>> -DCOMPAT_32BIT
>>> -march=i686
>>> -mmmx
>>> -msse
>>> -msse2
>>> -m32
>>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32
>>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp
>>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/
>>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32
>>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>> -O2
>>> -pipe
>>> -I/workspace/src/lib/msun/x86
>>> -I/workspace/src/lib/msun/ld80
>>> -I/workspace/src/lib/msun/i387
>>> -I/workspace/src/lib/msun/src
>>> -I/workspace/src/lib/libc/include
>>> -I/workspace/src/lib/libc/i386
>>> . . .
>>> 
>>> --- catrigl.o ---
>>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc
>>> -DCOMPAT_32BIT
>>> -march=i686
>>> -mmmx
>>> -msse
>>> -msse2
>>> -m32
>>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32
>>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp
>>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/
>>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32
>>> -O2
>>> -pipe
>>> -I/workspace/src/lib/msun/x86
>>> -I/workspace/src/lib/msun/ld80
>>> -I/workspace/src/lib/msun/i387
>>> -I/workspace/src/lib/msun/src
>>> -I/workspace/src/lib/libc/include 
>>> -I/workspace/src/lib/libc/i386
>>> . . .
>> 
>> 
>> For the report:
>> 
>>> The xtoolchain GCC packages have not required these flags since ports
>>>  commits r465416 and r466701
>> 
>> Looking at https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText
>> there is:
>> 
>>> Updating FreeBSD repository catalogue...
>>> FreeBSD repository is up to date.
>>> All repositories are up to date.
>>> The following 6 package(s) will be affected (of 0 checked):
>>> 
>>> New packages to be INSTALLED:
>>> amd64-xtoolchain-gcc: 0.4_1
>>> amd64-gcc: 6.4.0
>>> mpfr: 4.0.1
>>> gmp: 6.1.2
>>> mpc: 1.1.0_1
>>> amd64-binutils: 2.30_3,1
>> 
>> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834
>> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ).
>> 
>> This indicates that -r465416 and -r466701 did not cause:
>> 
>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp
>> 
>> to lead to include files being looked up in:
>> 
>> /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>> 
>> Thus there appears to still be a need for:
>> 
>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>> 
>> unless more is done to the devel/*-gcc to make them look
>> in that additional place automatically (based on --sysroot).
> 
> --sysroot does work, and you can verify it by doing the following:
> 
> % touch empty.c
> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c
> Using built-in specs.
> COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc
> Target: x86_64-unknown-freebsd11.2
> ...
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include
> /usr/include
> End of search list.
> ...
> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c  --sysroot=/foo
> Using built-in specs.
> COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc
> Target: x86_64-unknown-freebsd11.2
> ...
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed"
> ignoring nonexistent directory 
> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include"
> ignoring nonexistent directory "/foo/usr/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include
> End of search list.
> 
> I will see if I can reproduce the failure locally.

The:

ignoring nonexistent directory "/foo/usr/include"

means that the order of the search alternatives was not shown
("search starts here"). That is what I expect is different.

It will take a while before I'll have a build from either
before or after the 

svn commit: r335805 - head

2018-06-29 Thread Alex Richardson
Author: arichardson
Date: Fri Jun 29 21:15:26 2018
New Revision: 335805
URL: https://svnweb.freebsd.org/changeset/base/335805

Log:
  Don't change directory owner to root when building with -DNO_ROOT
  
  Currently the mtree calls in Makefile.inc1 all change the directory owner
  to match the spec file. However, we should not be doing this during
  distributeworld if -DNO_ROOT is passed. Additionally, when creating the
  WORLDTMP directory hierachy there is no need to change the owner to root so
  we now always pass the -W flag when populating WORLDTMP.
  
  This is also required for building FreeBSD on Linux/Mac since the required
  groups/users will not exist there which is how I discovered this issue.
  
  Reviewed By:  emaste, bdrewery, imp
  Approved By:  brooks (mentor)
  Differential Revision: https://reviews.freebsd.org/D14185

Modified:
  head/Makefile.inc1
  head/Makefile.libcompat

Modified: head/Makefile.inc1
==
--- head/Makefile.inc1  Fri Jun 29 21:15:17 2018(r335804)
+++ head/Makefile.inc1  Fri Jun 29 21:15:26 2018(r335805)
@@ -852,6 +852,19 @@ IMAKE_INSTALL= INSTALL="install ${INSTALLFLAGS}"
 IMAKE_MTREE=   MTREE_CMD="mtree ${MTREEFLAGS}"
 .endif
 
+DESTDIR_MTREEFLAGS=-deU
+# When creating worldtmp we don't need to set the directories as owned by root
+# so we also pass -W
+WORLDTMP_MTREEFLAGS=   -deUW
+.if defined(NO_ROOT)
+# When building with -DNO_ROOT we shouldn't be changing the directories
+# that are created by mtree to be owned by root/wheel.
+DESTDIR_MTREEFLAGS+=   -W
+.endif
+MTREE?=mtree
+WORLDTMP_MTREE=${MTREE} ${WORLDTMP_MTREEFLAGS}
+DESTDIR_MTREE= ${MTREE} ${DESTDIR_MTREEFLAGS}
+
 # kernel stage
 KMAKEENV=  ${WMAKEENV:NSYSROOT=*}
 KMAKE= ${KMAKEENV} ${MAKE} ${.MAKEFLAGS} ${KERNEL_FLAGS} 
KERNEL=${INSTKERNNAME}
@@ -954,23 +967,23 @@ _worldtmp: .PHONY
 lib lib/casper lib/geom usr legacy/bin legacy/usr
mkdir -p ${WORLDTMP}/${_dir}
 .endfor
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.usr.dist \
+   ${WORLDTMP_MTREE} -f ${.CURDIR}/etc/mtree/BSD.usr.dist \
-p ${WORLDTMP}/legacy/usr >/dev/null
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \
+   ${WORLDTMP_MTREE} -f ${.CURDIR}/etc/mtree/BSD.include.dist \
-p ${WORLDTMP}/legacy/usr/include >/dev/null
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.usr.dist \
+   ${WORLDTMP_MTREE} -f ${.CURDIR}/etc/mtree/BSD.usr.dist \
-p ${WORLDTMP}/usr >/dev/null
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \
+   ${WORLDTMP_MTREE} -f ${.CURDIR}/etc/mtree/BSD.include.dist \
-p ${WORLDTMP}/usr/include >/dev/null
ln -sf ${.CURDIR}/sys ${WORLDTMP}
 .if ${MK_DEBUG_FILES} != "no"
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+   ${WORLDTMP_MTREE} -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
-p ${WORLDTMP}/legacy/usr/lib >/dev/null
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+   ${WORLDTMP_MTREE} -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
-p ${WORLDTMP}/usr/lib >/dev/null
 .endif
 .for _mtree in ${LOCAL_MTREE}
-   mtree -deU -f ${.CURDIR}/${_mtree} -p ${WORLDTMP} > /dev/null
+   ${WORLDTMP_MTREE} -f ${.CURDIR}/${_mtree} -p ${WORLDTMP} > /dev/null
 .endfor
 _legacy:
@echo
@@ -1274,42 +1287,42 @@ distributeworld installworld stageworld: _installcheck
 .if make(distributeworld)
 .for dist in ${EXTRA_DISTRIBUTIONS}
-mkdir ${DESTDIR}/${DISTDIR}/${dist}
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.root.dist \
+   ${DESTDIR_MTREE} -f ${.CURDIR}/etc/mtree/BSD.root.dist \
-p ${DESTDIR}/${DISTDIR}/${dist} >/dev/null
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.usr.dist \
+   ${DESTDIR_MTREE} -f ${.CURDIR}/etc/mtree/BSD.usr.dist \
-p ${DESTDIR}/${DISTDIR}/${dist}/usr >/dev/null
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.include.dist \
+   ${DESTDIR_MTREE} -f ${.CURDIR}/etc/mtree/BSD.include.dist \
-p ${DESTDIR}/${DISTDIR}/${dist}/usr/include >/dev/null
 .if ${MK_DEBUG_FILES} != "no"
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
+   ${DESTDIR_MTREE} -f ${.CURDIR}/etc/mtree/BSD.debug.dist \
-p ${DESTDIR}/${DISTDIR}/${dist}/usr/lib >/dev/null
 .endif
 .if defined(LIBCOMPAT)
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.lib${libcompat}.dist \
+   ${DESTDIR_MTREE} -f ${.CURDIR}/etc/mtree/BSD.lib${libcompat}.dist \
-p ${DESTDIR}/${DISTDIR}/${dist}/usr >/dev/null
 .if ${MK_DEBUG_FILES} != "no"
-   mtree -deU -f ${.CURDIR}/etc/mtree/BSD.lib${libcompat}.dist \
+   ${DESTDIR_MTREE} -f ${.CURDIR}/etc/mtree/BSD.lib${libcompat}.dist \
-p ${DESTDIR}/${DISTDIR}/${dist}/usr/lib/debug/usr >/dev/null
 .endif
 .endif
 .if ${MK_TESTS} != "no" && ${dist} == "tests"
-mkdir -p ${DESTDIR}/${DISTDIR}/${dist}${TESTSBASE}
-   mtree -deU -f 

svn commit: r335804 - in head: etc usr.sbin/rmt

2018-06-29 Thread Alex Richardson
Author: arichardson
Date: Fri Jun 29 21:15:17 2018
New Revision: 335804
URL: https://svnweb.freebsd.org/changeset/base/335804

Log:
  Fix missing files in METALOG with -DNO_ROOT
  
  By using INSTALL_LINK instead of calling ln during install the files
  end up in the METALOG file as well if we use -DNO_ROOT and will be
  included in a disk image when using makefs with METALOG as the input.
  The other file that was not included in METALOG was /var/db/services.db
  which is now also included for -DNO_ROOT.
  
  Approved By:  brooks (mentor)
  Differential Revision: https://reviews.freebsd.org/D15665

Modified:
  head/etc/Makefile
  head/usr.sbin/rmt/Makefile

Modified: head/etc/Makefile
==
--- head/etc/Makefile   Fri Jun 29 20:17:47 2018(r335803)
+++ head/etc/Makefile   Fri Jun 29 21:15:17 2018(r335804)
@@ -213,6 +213,7 @@ distribution:
echo "./etc/passwd type=file mode=0644 uname=root gname=wheel"; 
\
echo "./etc/pwd.db type=file mode=0644 uname=root gname=wheel"; 
\
echo "./etc/spwd.db type=file mode=0600 uname=root 
gname=wheel"; \
+   echo "./var/db/services.db type=file mode=0644 uname=root 
gname=wheel"; \
) | ${METALOG.add}
 .endif
 .if ${MK_AUTOFS} != "no"
@@ -270,7 +271,7 @@ distribution:
${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \
dot.profile ${DESTDIR}/root/.profile; \
rm -f ${DESTDIR}/.profile; \
-   ln ${DESTDIR}/root/.profile ${DESTDIR}/.profile
+   ${INSTALL_LINK} ${DESTDIR}/root/.profile ${DESTDIR}/.profile
 .if ${MK_TCSH} != "no"
cd ${.CURDIR}/root; \
${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \
@@ -278,14 +279,14 @@ distribution:
${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \
dot.login ${DESTDIR}/root/.login; \
rm -f ${DESTDIR}/.cshrc; \
-   ln ${DESTDIR}/root/.cshrc ${DESTDIR}/.cshrc
+   ${INSTALL_LINK} ${DESTDIR}/root/.cshrc ${DESTDIR}/.cshrc
 .endif
 .if ${MK_MAIL} != "no"
cd ${.CURDIR}/mail; ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m 644 \
${ETCMAIL} ${DESTDIR}/etc/mail
if [ -d ${DESTDIR}/etc/mail -a -f ${DESTDIR}/etc/mail/aliases -a \
  ! -f ${DESTDIR}/etc/aliases ]; then \
-   ln -s mail/aliases ${DESTDIR}/etc/aliases; \
+   ${INSTALL_SYMLINK} mail/aliases ${DESTDIR}/etc/aliases; \
fi
 .endif
${INSTALL} -o ${BINOWN} -g operator -m 664 /dev/null \

Modified: head/usr.sbin/rmt/Makefile
==
--- head/usr.sbin/rmt/Makefile  Fri Jun 29 20:17:47 2018(r335803)
+++ head/usr.sbin/rmt/Makefile  Fri Jun 29 21:15:17 2018(r335804)
@@ -7,6 +7,6 @@ MAN=rmt.8
 # called from /usr/src/etc/Makefile
 etc-rmt:
rm -f ${DESTDIR}/etc/rmt
-   ln -s ..${BINDIR}/rmt ${DESTDIR}/etc/rmt
+   ${INSTALL_RSYMLINK} ..${BINDIR}/rmt ${DESTDIR}/etc/rmt
 
 .include 
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-29 Thread John Baldwin
On 6/28/18 7:54 PM, Mark Millard wrote:
> On 2018-Jun-28, at 6:04 PM, Mark Millard  wrote:
> 
>> On 2018-Jun-28, at 5:39 PM, Mark Millard  wrote:
>>
>>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
>>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
>>> breaking-change was the following but I've not tried personal
>>> builds to confirm.
>>> ]

So this is a bit complicated and I'm not sure what the correct fix is.

What is happening is that the  shipped with GCC is now being used
after this change instead of sys/x86/include/float.h.  A sledgehammer approach
would be to remove float.h from the GCC package (we currently don't install
the float.h for the base system clang either).  However, looking at this
in more detail, it seems that x86/include/float.h is also busted in some
ways.

First, the #error I don't understand how it is happening.  The GCC float.h
defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just
like the x86 float.h:

# x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP
#define __LDBL_MAX_EXP__ 16384

I even hacked catrigl.c to add the following lines before the #error
check:

LDBL_MAX_EXP_ = LDBL_MAX_EXP
LDBL_MANT_DIG_ = LDBL_MANT_DIG

#if LDBL_MAX_EXP != 0x4000
#error "Unsupported long double format"
#endif

And the -E output is:

DBL_MAX_EXP_ = 16384
LDBL_MANT_DIG_ = 53

# 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error "U
nsupported long double format"
 #error "Unsupported long double format"
  ^

Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which
it must be since the x86 float.h uses '16384' not '0x4000' as the value).

However, LDBL_MANT_DIG of 53 is a bit more fun.  We have a comment about the
initial FPU control word in sys/amd64/include/fpu.h that reads thus:

/*
 * The hardware default control word for i387's and later coprocessors is
 * 0x37F, giving:
 *
 *  round to nearest
 *  64-bit precision
 *  all exceptions masked.
 *
 * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc
 * because of the difference between memory and fpu register stack arguments.
 * If its using an intermediate fpu register, it has 80/64 bits to work
 * with.  If it uses memory, it has 64/53 bits to work with.  However,
 * gcc is aware of this and goes to a fair bit of trouble to make the
 * best use of it.
 *
 * This is mostly academic for AMD64, because the ABI prefers the use
 * SSE2 based math.  For FreeBSD/amd64, we go with the default settings.
 */
#define __INITIAL_FPUCW__   0x037F
#define __INITIAL_FPUCW_I386__  0x127F
#define __INITIAL_NPXCW__   __INITIAL_FPUCW_I386__
#define __INITIAL_MXCSR__   0x1F80
#define __INITIAL_MXCSR_MASK__  0xFFBF

GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in
__LDBL_MANT_DIG__ being set to 53 instead of 64:

/* FreeBSD sets the rounding precision of the FPU to 53 bits.  Let the
   compiler get the contents of  and std::numeric_limits correct.  */
#undef TARGET_96_ROUND_53_LONG_DOUBLE
#define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT)

clang seems unaware of this as it reports all the same values for
LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64
but not i386):

# cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__'
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
# cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__'
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
# x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__'
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
# x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__'
#define __LDBL_MAX__ 1.1897314953572316e+4932L
#define __LDBL_MIN__ 3.3621031431120935e-4932L

The x86/include/float.h header though reports the MIN/MAX values somewhere
in between the two ranges for both amd64 and i386 while reporting an
LDBL_MANT_DIG of 64:

#define LDBL_MANT_DIG   64
#define LDBL_MIN3.3621031431120935063E-4932L
#define LDBL_MAX1.1897314953572317650E+4932L

I guess for now I will remove float.h from the amd64-gcc pkg-plist, but we
should really be fixing our tree to work with compiler-provided language
headers when at all possible.  It's not clear to me if amd64 should be
using the compiler provided values of things like LDBL_MIN/MAX either btw.

-- 
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335801 - head/sys/powerpc/powernv

2018-06-29 Thread Justin Hibbits
Author: jhibbits
Date: Fri Jun 29 19:35:25 2018
New Revision: 335801
URL: https://svnweb.freebsd.org/changeset/base/335801

Log:
  Support multiple OPAL consoles, and don't crash if uart is not stdout
  
  Summary: If the chosen console is not the OPAL uart, but OPAL uart devices
  exist, the console device doesn't attach properly, and faults in the interrupt
  handler, with a NULL pointer dereference.  To fix this, and as a byproduct, 
also
  support multiple OPAL consoles, refactor to have the console getc callback use
  the appropriate softc instead of the global console_sc, which may be NULL in 
the
  case of a different device being the console.
  
  Reviewed by:  nwhitehorn
  Differential Revision: https://reviews.freebsd.org/D16071

Modified:
  head/sys/powerpc/powernv/opal_console.c

Modified: head/sys/powerpc/powernv/opal_console.c
==
--- head/sys/powerpc/powernv/opal_console.c Fri Jun 29 18:45:29 2018
(r335800)
+++ head/sys/powerpc/powernv/opal_console.c Fri Jun 29 19:35:25 2018
(r335801)
@@ -70,14 +70,14 @@ struct uart_opal_softc {
char opal_inbuf[16];
uint64_t inbuflen;
uint8_t outseqno;
+#if defined(KDB)
+   int alt_break_state;
+#endif
 };
 
 static struct uart_opal_softc  *console_sc = NULL;
+static struct consdev *stdout_cp;
 
-#if defined(KDB)
-static int alt_break_state;
-#endif
-
 enum {
OPAL_RAW, OPAL_HVSI
 };
@@ -112,6 +112,7 @@ static driver_t uart_opal_driver = {
  
 DRIVER_MODULE(uart_opal, opalcons, uart_opal_driver, uart_devclass, 0, 0);
 
+static int uart_opal_getc(struct uart_opal_softc *sc);
 static cn_probe_t uart_opal_cnprobe;
 static cn_init_t uart_opal_cninit;
 static cn_term_t uart_opal_cnterm;
@@ -248,6 +249,8 @@ uart_opal_cnprobe(struct consdev *cp)
 
cp->cn_pri = CN_NORMAL;
console_sc = 
+   cp->cn_arg = console_sc;
+   stdout_cp = cp;
return;

 fail:
@@ -262,23 +265,25 @@ uart_opal_attach(device_t dev)
int unit;
 
sc = device_get_softc(dev);
-   sc->dev = dev;
sc->node = ofw_bus_get_node(dev);
uart_opal_probe_node(sc);
 
unit = device_get_unit(dev);
-   sc->tp = tty_alloc(_opal_tty_class, sc);
mtx_init(>sc_mtx, device_get_nameunit(dev), NULL,
MTX_SPIN | MTX_QUIET | MTX_NOWITNESS);
 
if (console_sc != NULL && console_sc->vtermid == sc->vtermid) {
device_printf(dev, "console\n");
-   sc->outseqno = console_sc->outseqno;
-   console_sc = sc;
+   device_set_softc(dev, console_sc);
+   sc = console_sc;
sprintf(uart_opal_consdev.cn_name, "ttyu%r", unit);
-   tty_init_console(sc->tp, 0);
}
+   sc->tp = tty_alloc(_opal_tty_class, sc);
 
+   if (console_sc == sc)
+   tty_init_console(sc->tp, 0);
+
+   sc->dev = dev;
sc->irqrid = 0;
sc->irqres = bus_alloc_resource_any(dev, SYS_RES_IRQ, >irqrid,
RF_ACTIVE | RF_SHAREABLE);
@@ -419,14 +424,20 @@ uart_opal_put(struct uart_opal_softc *sc, void *buffer
 static int
 uart_opal_cngetc(struct consdev *cp)
 {
+   return (uart_opal_getc(cp->cn_arg));
+}
+
+static int
+uart_opal_getc(struct uart_opal_softc *sc)
+{
unsigned char c;
int retval;
 
-   retval = uart_opal_get(console_sc, , 1);
+   retval = uart_opal_get(sc, , 1);
if (retval != 1)
return (-1);
 #if defined(KDB)
-   kdb_alt_break(c, _break_state);
+   kdb_alt_break(c, >alt_break_state);
 #endif
 
return (c);
@@ -444,7 +455,7 @@ uart_opal_cnputc(struct consdev *cp, int c)
opal_call(OPAL_POLL_EVENTS, NULL);
}
}
-   uart_opal_put(console_sc, , 1);
+   uart_opal_put(cp->cn_arg, , 1);
 }
 
 static void
@@ -478,7 +489,7 @@ uart_opal_intr(void *v)
int c;
 
tty_lock(tp);
-   while ((c = uart_opal_cngetc(NULL)) > 0)
+   while ((c = uart_opal_getc(sc)) > 0)
ttydisc_rint(tp, c, 0);
ttydisc_rint_done(tp);
tty_unlock(tp);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335800 - head/sys/conf

2018-06-29 Thread Ed Maste
Author: emaste
Date: Fri Jun 29 18:45:29 2018
New Revision: 335800
URL: https://svnweb.freebsd.org/changeset/base/335800

Log:
  newvers.sh: avoid possibly invalid relative directory
  
  Previously newvers.sh passed --work-tree=${VCSDIR}/.. when invoking git.
  When using git worktree .git is actually a file, not a directory, and
  .git/.. is not a valid path.  Although it appears git handles this
  internally (perhaps it normalizes the path first), it is simple enough
  for the script to store both the working tree top-level directory and
  the VCS (.git) directory, so do so.
  
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/conf/newvers.sh

Modified: head/sys/conf/newvers.sh
==
--- head/sys/conf/newvers.shFri Jun 29 17:51:35 2018(r335799)
+++ head/sys/conf/newvers.shFri Jun 29 18:45:29 2018(r335800)
@@ -65,7 +65,8 @@ findvcs()
cd ${SYSDIR}/..
while [ $(pwd) != "/" ]; do
if [ -e "./$1" ]; then
-   VCSDIR=$(pwd)"/$1"
+   VCSTOP=$(pwd)
+   VCSDIR=${VCSTOP}"/$1"
cd ${savedir}
return 0
fi
@@ -239,7 +240,7 @@ if [ -n "$git_cmd" ] ; then
if [ -n "$git_b" ] ; then
git="${git}(${git_b})"
fi
-   if $git_cmd --work-tree=${VCSDIR}/.. diff-index \
+   if $git_cmd --work-tree=${VCSTOP} diff-index \
--name-only HEAD | read dummy; then
git="${git}-dirty"
modified=true
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335799 - in head: contrib/compiler-rt/lib/sanitizer_common contrib/libc++/include contrib/libc++/src/support/runtime contrib/llvm/include/llvm/CodeGen contrib/llvm/include/llvm/IR cont...

2018-06-29 Thread Dimitry Andric
Author: dim
Date: Fri Jun 29 17:51:35 2018
New Revision: 335799
URL: https://svnweb.freebsd.org/changeset/base/335799

Log:
  Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
  6.0.1 release (upstream r335540).
  
  Relnotes: yes
  MFC after:2 weeks

Modified:
  
head/contrib/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cc
  head/contrib/libc++/include/list
  head/contrib/libc++/src/support/runtime/exception_libcxxabi.ipp
  head/contrib/llvm/include/llvm/CodeGen/TargetInstrInfo.h
  head/contrib/llvm/include/llvm/IR/IntrinsicsPowerPC.td
  head/contrib/llvm/lib/Analysis/GlobalsModRef.cpp
  head/contrib/llvm/lib/Analysis/MemorySSA.cpp
  head/contrib/llvm/lib/CodeGen/IfConversion.cpp
  head/contrib/llvm/lib/CodeGen/LiveDebugVariables.cpp
  head/contrib/llvm/lib/CodeGen/MachineBlockPlacement.cpp
  head/contrib/llvm/lib/CodeGen/PeepholeOptimizer.cpp
  head/contrib/llvm/lib/CodeGen/TargetInstrInfo.cpp
  head/contrib/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
  head/contrib/llvm/lib/IR/Core.cpp
  head/contrib/llvm/lib/MC/MCObjectFileInfo.cpp
  head/contrib/llvm/lib/Support/Host.cpp
  head/contrib/llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
  head/contrib/llvm/lib/Target/AArch64/AArch64FalkorHWPFFix.cpp
  head/contrib/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
  head/contrib/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  head/contrib/llvm/lib/Target/AArch64/AArch64InstrInfo.td
  head/contrib/llvm/lib/Target/AMDGPU/AMDGPUTargetMachine.cpp
  head/contrib/llvm/lib/Target/AMDGPU/SIISelLowering.cpp
  head/contrib/llvm/lib/Target/AMDGPU/SIInstructions.td
  head/contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
  head/contrib/llvm/lib/Target/ARM/ARMComputeBlockSize.cpp
  head/contrib/llvm/lib/Target/Mips/AsmParser/MipsAsmParser.cpp
  head/contrib/llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp
  head/contrib/llvm/lib/Target/Mips/MicroMips32r6InstrInfo.td
  head/contrib/llvm/lib/Target/Mips/MicroMipsInstrInfo.td
  head/contrib/llvm/lib/Target/Mips/Mips.td
  head/contrib/llvm/lib/Target/Mips/Mips32r6InstrInfo.td
  head/contrib/llvm/lib/Target/Mips/Mips64InstrInfo.td
  head/contrib/llvm/lib/Target/Mips/Mips64r6InstrInfo.td
  head/contrib/llvm/lib/Target/Mips/MipsDSPInstrFormats.td
  head/contrib/llvm/lib/Target/Mips/MipsFastISel.cpp
  head/contrib/llvm/lib/Target/Mips/MipsISelLowering.cpp
  head/contrib/llvm/lib/Target/Mips/MipsInstrFormats.td
  head/contrib/llvm/lib/Target/Mips/MipsInstrInfo.cpp
  head/contrib/llvm/lib/Target/Mips/MipsInstrInfo.td
  head/contrib/llvm/lib/Target/Mips/MipsLongBranch.cpp
  head/contrib/llvm/lib/Target/Mips/MipsSEISelLowering.cpp
  head/contrib/llvm/lib/Target/Mips/MipsSubtarget.cpp
  head/contrib/llvm/lib/Target/Mips/MipsSubtarget.h
  head/contrib/llvm/lib/Target/NVPTX/NVPTXTargetMachine.cpp
  head/contrib/llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  head/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.cpp
  head/contrib/llvm/lib/Target/X86/X86DomainReassignment.cpp
  head/contrib/llvm/lib/Target/X86/X86FastISel.cpp
  head/contrib/llvm/lib/Target/X86/X86FlagsCopyLowering.cpp
  head/contrib/llvm/lib/Target/X86/X86InstrArithmetic.td
  head/contrib/llvm/lib/Transforms/IPO/ArgumentPromotion.cpp
  head/contrib/llvm/lib/Transforms/IPO/DeadArgumentElimination.cpp
  head/contrib/llvm/lib/Transforms/IPO/GlobalOpt.cpp
  head/contrib/llvm/lib/Transforms/IPO/MergeFunctions.cpp
  head/contrib/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
  head/contrib/llvm/lib/Transforms/Scalar/CallSiteSplitting.cpp
  head/contrib/llvm/lib/Transforms/Scalar/DivRemPairs.cpp
  head/contrib/llvm/lib/Transforms/Scalar/JumpThreading.cpp
  head/contrib/llvm/lib/Transforms/Scalar/SCCP.cpp
  head/contrib/llvm/lib/Transforms/Utils/FunctionComparator.cpp
  head/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticDriverKinds.td
  head/contrib/llvm/tools/clang/include/clang/Basic/DiagnosticSemaKinds.td
  head/contrib/llvm/tools/clang/include/clang/Driver/CLCompatOptions.td
  head/contrib/llvm/tools/clang/include/clang/Driver/Options.td
  head/contrib/llvm/tools/clang/lib/AST/ExprConstant.cpp
  head/contrib/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp
  head/contrib/llvm/tools/clang/lib/Basic/Targets/AArch64.cpp
  head/contrib/llvm/tools/clang/lib/Basic/Targets/Mips.h
  head/contrib/llvm/tools/clang/lib/Basic/Version.cpp
  head/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp
  head/contrib/llvm/tools/clang/lib/Driver/Driver.cpp
  head/contrib/llvm/tools/clang/lib/Driver/ToolChains/Arch/Mips.cpp
  head/contrib/llvm/tools/clang/lib/Driver/ToolChains/Arch/Mips.h
  head/contrib/llvm/tools/clang/lib/Driver/ToolChains/Clang.cpp
  head/contrib/llvm/tools/clang/lib/Driver/ToolChains/CrossWindows.cpp
  head/contrib/llvm/tools/clang/lib/Driver/ToolChains/MinGW.cpp
  head/contrib/llvm/tools/clang/lib/Frontend/ASTUnit.cpp
  head/contrib/llvm/tools/clang/lib/Frontend/CompilerInvocation.cpp
  

Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

2018-06-29 Thread John Baldwin
On 6/28/18 7:54 PM, Mark Millard wrote:
> On 2018-Jun-28, at 6:04 PM, Mark Millard  wrote:
> 
>> On 2018-Jun-28, at 5:39 PM, Mark Millard  wrote:
>>
>>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
>>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
>>> breaking-change was the following but I've not tried personal
>>> builds to confirm.
>>> ]
>>>
>>> It looks to me that:
>>>
 Author: jhb
 Date: Thu Jun 28 21:26:14 2018
 New Revision: 335782
 URL: 
 https://svnweb.freebsd.org/changeset/base/335782


 Log:
 Remove the various build flag hacks for GCC cross-compile.

 The xtoolchain GCC packages have not required these flags since ports
 commits r465416 and r466701.  The in-tree GCC 4.2.1 has also been patched
 in r335716 and r335717 to correctly honor --sysroot when looking for
 includes and libraries.

 Reviewed by:   bdrewery
 Sponsored by:  DARPA / AFRL
 Differential Revision: 
 https://reviews.freebsd.org/D16055
>>> . . .
>>>
>>> broke ci.freebsd.org's FreeBSD-head-amd64-gcc build.
>>>
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText shows:
>>>
>>> --- catrigl.o ---
>>> /usr/local/bin/x86_64-unknown-freebsd11.1-gcc -DCOMPAT_32BIT -march=i686 
>>> -mmmx -msse -msse2 -m32  
>>> -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32  
>>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp  
>>> -B/usr/local/x86_64-unknown-freebsd11.1/bin/ 
>>> -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32  -O2 
>>> -pipe -I/workspace/src/lib/msun/x86 -I/workspace/src/lib/msun/ld80 
>>> -I/workspace/src/lib/msun/i387 -I/workspace/src/lib/msun/src 
>>> -I/workspace/src/lib/libc/include  -I/workspace/src/lib/libc/i386  -g -MD  
>>> -MF.depend.catrigl.o -MTcatrigl.o -std=gnu99 -fstack-protector-strong 
>>> -Wsystem-headers -Werror -Wno-pointer-sign -Wno-error=address 
>>> -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare 
>>> -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare 
>>> -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses 
>>> -Wno-error=strict-aliasing -Wno-error=uninitialized 
>>> -Wno-error=unused-but-set-variable -Wno-error=unuse
 d-function -Wno-error=unused-value -Wno-error=misleading-indentation 
-Wno-error=nonnull-compare -Wno-error=shift-negative-value 
-Wno-error=tautological-compare -Wno-error=unused-const-variable 
-Wno-unknown-pragmas -c /workspace/src/lib/msun/src/catrigl.c -o catrigl.o
>>> /workspace/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported long 
>>> double format"
>>> #error "Unsupported long double format"
>>> ^
>>> /workspace/src/lib/msun/src/catrigl.c: In function 'casinhl':
>>> /workspace/src/lib/msun/src/catrigl.c:190:35: error: 'm_ln2' undeclared 
>>> (first use in this function)
>>>   w = clog_for_large_values(z) + m_ln2;
>>>  ^
>>> /workspace/src/lib/msun/src/catrigl.c:190:35: note: each undeclared 
>>> identifier is reported only once for each function it appears in
>>> /workspace/src/lib/msun/src/catrigl.c:202:11: error: 'SQRT_6_EPSILON' 
>>> undeclared (first use in this function)
>>> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4)
>>>  ^~
>>> /workspace/src/lib/msun/src/catrigl.c: In function 'cacosl':
>>> /workspace/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' undeclared 
>>> (first use in this function)
>>>  ry = creall(w) + m_ln2;
>>>   ^
>>> /workspace/src/lib/msun/src/catrigl.c:261:11: error: 'SQRT_6_EPSILON' 
>>> undeclared (first use in this function)
>>> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4)
>>>  ^~
>>> In file included from /workspace/src/lib/msun/src/catrigl.c:45:0:
>>> /workspace/src/lib/msun/src/catrigl.c: In function 'clog_for_large_values':
>>> /workspace/src/lib/msun/src/catrigl.c:316:34: error: 'm_e' undeclared 
>>> (first use in this function)
>>>  return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1,
>>> ^
>>> /workspace/src/lib/msun/src/catrigl.c:316:11: error: '__builtin_complex' 
>>> operand not of real binary floating-point type
>>>  return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1,
>>>  ^
>>> /workspace/src/lib/msun/src/catrigl.c: In function 'catanhl':
>>> /workspace/src/lib/msun/src/catrigl.c:390:11: error: 'SQRT_3_EPSILON' 
>>> undeclared (first use in this function)
>>> if (ax < SQRT_3_EPSILON / 2 && ay < SQRT_3_EPSILON / 2) {
>>>  ^~
>>> /workspace/src/lib/msun/src/catrigl.c:396:9: error: 'm_ln2' undeclared 
>>> (first use in this function)
>>>  rx = (m_ln2 - logl(ay)) / 2;
>>>^
>>> *** [catrigl.o] Error code 1
>>
>> Later below expand the failing and previoly good commands, one
>> option per line. The summary of the distinction in content is
>> a one line difference, the working example ( 

svn commit: r335797 - head/share/mk

2018-06-29 Thread Brooks Davis
Author: brooks
Date: Fri Jun 29 16:07:56 2018
New Revision: 335797
URL: https://svnweb.freebsd.org/changeset/base/335797

Log:
  Correct link metadata created when installing with -DNO_ROOT.
  
  Explicitly specify owner/group/mode metadata when creating links.
  
  More consistently use INSTALL_SYMLINK to install symlinks.
  
  Reviewed by:  bdrewery
  Sponsored by: DARPA, AFRL
  Differential Revision:https://reviews.freebsd.org/D11231

Modified:
  head/share/mk/bsd.README
  head/share/mk/bsd.lib.mk
  head/share/mk/bsd.man.mk
  head/share/mk/bsd.own.mk
  head/share/mk/bsd.prog.mk

Modified: head/share/mk/bsd.README
==
--- head/share/mk/bsd.READMEFri Jun 29 14:51:36 2018(r335796)
+++ head/share/mk/bsd.READMEFri Jun 29 16:07:56 2018(r335797)
@@ -225,6 +225,24 @@ MANMODEManual mode.
 
 MANOWN Manual owner.
 
+INSTALL_LINK   Command to install a hard link.
+
+INSTALL_SYMLINKCommand to install a symbolic link.
+
+INSTALL_RSYMLINK   Command to install a relative symbolic link.
+
+LINKOWNOwner of hard links created by INSTALL_LINK.
+
+LINKGRPGroup of hard links created by INSTALL_LINK.
+
+LINKMODE   Mode of hard links created by INSTALL_LINK.
+
+SYMLINKOWN Owner of hard links created by INSTALL_[R]SYMLINK.
+
+SYMLINKGRP Group of hard links created by INSTALL_[R]SYMLINK.
+
+SYMLINKMODEMode of hard links created by INSTALL_[R]SYMLINK.
+
 This file is generally useful when building your own Makefiles so that
 they use the same default owners etc. as the rest of the tree.
 
@@ -320,6 +338,13 @@ LINKS  The list of binary links; should be 
full pathna
 
LINKS=  /bin/test /bin/[
 
+LINKOWNOwner of links created with LINKS [${BINOWN}].
+
+LINKGRPGroup of links created with LINKS [${BINGRP}].
+
+LINKMODE   Mode of links created with LINKS [${BINMODE}].
+
+
 MANManual pages.  If no MAN variable is defined,
"MAN=${PROG}.1" is assumed. See bsd.man.mk for more details.
 
@@ -528,6 +553,21 @@ LIB_CXXThe name of the library to build. It 
also cau
of LIB if LIB is also set.  Both a shared and static library
will be built.  NO_PIC can be set to only build a static
library.
+
+LINKS  The list of binary links; should be full pathnames, the
+   linked-to file coming first, followed by the linked
+   file.  The files are hard-linked.  For example, to link
+   /bin/test and /bin/[, use:
+
+   LINKS=  /bin/test /bin/[
+
+LINKOWNOwner of links created with LINKS [${LIBOWN}].
+
+LINKGRPGroup of links created with LINKS [${LIBGRP}].
+
+LINKMODE   Mode of links created with LINKS [${LIBMODE}].
+
+LINTLIBDIR Target directory for lint libraries.
 
 MANThe manual pages to be installed. See bsd.man.mk for more
details.

Modified: head/share/mk/bsd.lib.mk
==
--- head/share/mk/bsd.lib.mkFri Jun 29 14:51:36 2018(r335796)
+++ head/share/mk/bsd.lib.mkFri Jun 29 16:07:56 2018(r335797)
@@ -275,7 +275,7 @@ ${SHLIB_NAME_FULL}: ${SOBJS}
@${ECHO} building shared library ${SHLIB_NAME}
@rm -f ${SHLIB_NAME} ${SHLIB_LINK}
 .if defined(SHLIB_LINK) && !commands(${SHLIB_LINK:R}.ld) && ${MK_DEBUG_FILES} 
== "no"
-   @${INSTALL_SYMLINK} ${TAG_ARGS:D${TAG_ARGS},development} ${SHLIB_NAME} 
${SHLIB_LINK}
+   @${INSTALL_LIBSYMLINK} ${TAG_ARGS:D${TAG_ARGS},development} 
${SHLIB_NAME} ${SHLIB_LINK}
 .endif
${_LD:N${CCACHE_BIN}} ${LDFLAGS} ${SSP_CFLAGS} ${SOLINKOPTS} \
-o ${.TARGET} -Wl,-soname,${SONAME} \
@@ -291,7 +291,7 @@ ${SHLIB_NAME}: ${SHLIB_NAME_FULL} ${SHLIB_NAME}.debug
${OBJCOPY} --strip-debug --add-gnu-debuglink=${SHLIB_NAME}.debug \
${SHLIB_NAME_FULL} ${.TARGET}
 .if defined(SHLIB_LINK) && !commands(${SHLIB_LINK:R}.ld)
-   @${INSTALL_SYMLINK} ${TAG_ARGS:D${TAG_ARGS},development} ${SHLIB_NAME} 
${SHLIB_LINK}
+   @${INSTALL_LIBSYMLINK} ${TAG_ARGS:D${TAG_ARGS},development} 
${SHLIB_NAME} ${SHLIB_LINK}
 .endif
 
 ${SHLIB_NAME}.debug: ${SHLIB_NAME_FULL}
@@ -398,7 +398,7 @@ _libinstall:
${_INSTALLFLAGS} ${SHLIB_LINK:R}.ld \
${DESTDIR}${_LIBDIR}/${SHLIB_LINK}
 .for _SHLIB_LINK_LINK in ${SHLIB_LDSCRIPT_LINKS}
-   ${INSTALL_SYMLINK} ${SHLIB_LINK} 
${DESTDIR}${_LIBDIR}/${_SHLIB_LINK_LINK}
+   ${INSTALL_LIBSYMLINK} ${SHLIB_LINK} 
${DESTDIR}${_LIBDIR}/${_SHLIB_LINK_LINK}
 .endfor
 .else
 .if ${_SHLIBDIR} == ${_LIBDIR}
@@ -437,6 +437,11 @@ _libinstall:
 .include 
 .endif
 
+LINKOWN?=  ${LIBOWN}
+LINKGRP?=  ${LIBGRP}
+LINKMODE?= ${LIBMODE}
+SYMLINKOWN?=   ${LIBOWN}
+SYMLINKGRP?=   

Re: head -r335795 broke the builds for ci.freebsd.org 's FreeBSD-head-{amd64,i386,powerpc,risc64,sparc64}-build

2018-06-29 Thread Sean Bruno


On 06/29/18 08:50, Mark Millard wrote:
> Side note:
> 
> All I get for the lists that I normally look at is:
> 
> Error 503 Backend fetch failed
> 
> Backend status: Backend fetch failed
> 
> Transaction ID: . . .


I think I fixed that about an hour ago.  Try again.

sean



signature.asc
Description: OpenPGP digital signature


svn commit: r335796 - head/sys/netipsec

2018-06-29 Thread Ed Maste
Author: emaste
Date: Fri Jun 29 14:51:36 2018
New Revision: 335796
URL: https://svnweb.freebsd.org/changeset/base/335796

Log:
  r335795 build fix: make static functions static
  
  -Werror,-Wmissing-prototypes makes this an error otherwise.
  
  MFC with: 335795
  Sponsored by: The FreeBSD Foundation

Modified:
  head/sys/netipsec/key_debug.c

Modified: head/sys/netipsec/key_debug.c
==
--- head/sys/netipsec/key_debug.c   Fri Jun 29 13:59:33 2018
(r335795)
+++ head/sys/netipsec/key_debug.c   Fri Jun 29 14:51:36 2018
(r335796)
@@ -85,7 +85,7 @@ static void kdebug_sadb_x_natt(struct sadb_ext *);
 
 /* NOTE: host byte order */
 
-const char*
+static const char*
 kdebug_sadb_type(uint8_t type)
 {
 #defineSADB_NAME(n)case SADB_ ## n: return (#n)
@@ -120,7 +120,7 @@ kdebug_sadb_type(uint8_t type)
 #undef SADB_NAME
 }
 
-const char*
+static const char*
 kdebug_sadb_exttype(uint16_t type)
 {
 #defineEXT_NAME(n) case SADB_EXT_ ## n: return (#n)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


head -r335795 broke the builds for ci.freebsd.org 's FreeBSD-head-{amd64,i386,powerpc,risc64,sparc64}-build

2018-06-29 Thread Mark Millard via svn-src-head


clang example:
( https://ci.freebsd.org/job/FreeBSD-head-amd64-build/9257/consoleText )

--- key_debug.o ---
/usr/src/sys/netipsec/key_debug.c:89:1: error: no previous prototype for 
function 'kdebug_sadb_type' [-Werror,-Wmissing-prototypes]
kdebug_sadb_type(uint8_t type)
^
/usr/src/sys/netipsec/key_debug.c:124:1: error: no previous prototype for 
function 'kdebug_sadb_exttype' [-Werror,-Wmissing-prototypes]
kdebug_sadb_exttype(uint16_t type)
^
2 errors generated.
*** [key_debug.o] Error code 1


gcc 4.2.1 example:
( https://ci.freebsd.org/job/FreeBSD-head-sparc64-build/8445/consoleText )

--- key_debug.o ---
cc1: warnings being treated as errors
/usr/src/sys/netipsec/key_debug.c:90: warning: no previous prototype for 
'kdebug_sadb_type' [-Wmissing-prototypes]
/usr/src/sys/netipsec/key_debug.c:125: warning: no previous prototype for 
'kdebug_sadb_exttype' [-Wmissing-prototypes]
*** [key_debug.o] Error code 1



Side note:

All I get for the lists that I normally look at is:

Error 503 Backend fetch failed

Backend status: Backend fetch failed

Transaction ID: . . .


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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


svn commit: r335795 - head/sys/netipsec

2018-06-29 Thread Andrey V. Elsukov
Author: ae
Date: Fri Jun 29 13:59:33 2018
New Revision: 335795
URL: https://svnweb.freebsd.org/changeset/base/335795

Log:
  Make debug output produced by `setkey -x` command a more human readable.
  
  Add text names of SADB message types and extension headers to the output.
  
  Obtained from:Yandex LLC
  MFC after:2 weeks
  Sponsored by: Yandex LLC
  Differential Revision:https://reviews.freebsd.org/D16036

Modified:
  head/sys/netipsec/key_debug.c

Modified: head/sys/netipsec/key_debug.c
==
--- head/sys/netipsec/key_debug.c   Fri Jun 29 12:41:36 2018
(r335794)
+++ head/sys/netipsec/key_debug.c   Fri Jun 29 13:59:33 2018
(r335795)
@@ -85,6 +85,85 @@ static void kdebug_sadb_x_natt(struct sadb_ext *);
 
 /* NOTE: host byte order */
 
+const char*
+kdebug_sadb_type(uint8_t type)
+{
+#defineSADB_NAME(n)case SADB_ ## n: return (#n)
+
+   switch (type) {
+   SADB_NAME(RESERVED);
+   SADB_NAME(GETSPI);
+   SADB_NAME(UPDATE);
+   SADB_NAME(ADD);
+   SADB_NAME(DELETE);
+   SADB_NAME(GET);
+   SADB_NAME(ACQUIRE);
+   SADB_NAME(REGISTER);
+   SADB_NAME(EXPIRE);
+   SADB_NAME(FLUSH);
+   SADB_NAME(DUMP);
+   SADB_NAME(X_PROMISC);
+   SADB_NAME(X_PCHANGE);
+   SADB_NAME(X_SPDUPDATE);
+   SADB_NAME(X_SPDADD);
+   SADB_NAME(X_SPDDELETE);
+   SADB_NAME(X_SPDGET);
+   SADB_NAME(X_SPDACQUIRE);
+   SADB_NAME(X_SPDDUMP);
+   SADB_NAME(X_SPDFLUSH);
+   SADB_NAME(X_SPDSETIDX);
+   SADB_NAME(X_SPDEXPIRE);
+   SADB_NAME(X_SPDDELETE2);
+   default:
+   return ("UNKNOWN");
+   }
+#undef SADB_NAME
+}
+
+const char*
+kdebug_sadb_exttype(uint16_t type)
+{
+#defineEXT_NAME(n) case SADB_EXT_ ## n: return (#n)
+#defineX_NAME(n)   case SADB_X_EXT_ ## n: return (#n)
+
+   switch (type) {
+   EXT_NAME(RESERVED);
+   EXT_NAME(SA);
+   EXT_NAME(LIFETIME_CURRENT);
+   EXT_NAME(LIFETIME_HARD);
+   EXT_NAME(LIFETIME_SOFT);
+   EXT_NAME(ADDRESS_SRC);
+   EXT_NAME(ADDRESS_DST);
+   EXT_NAME(ADDRESS_PROXY);
+   EXT_NAME(KEY_AUTH);
+   EXT_NAME(KEY_ENCRYPT);
+   EXT_NAME(IDENTITY_SRC);
+   EXT_NAME(IDENTITY_DST);
+   EXT_NAME(SENSITIVITY);
+   EXT_NAME(PROPOSAL);
+   EXT_NAME(SUPPORTED_AUTH);
+   EXT_NAME(SUPPORTED_ENCRYPT);
+   EXT_NAME(SPIRANGE);
+   X_NAME(KMPRIVATE);
+   X_NAME(POLICY);
+   X_NAME(SA2);
+   X_NAME(NAT_T_TYPE);
+   X_NAME(NAT_T_SPORT);
+   X_NAME(NAT_T_DPORT);
+   X_NAME(NAT_T_OAI);
+   X_NAME(NAT_T_OAR);
+   X_NAME(NAT_T_FRAG);
+   X_NAME(SA_REPLAY);
+   X_NAME(NEW_ADDRESS_SRC);
+   X_NAME(NEW_ADDRESS_DST);
+   default:
+   return ("UNKNOWN");
+   };
+#undef EXT_NAME
+#undef X_NAME
+}
+
+
 /* %%%: about struct sadb_msg */
 void
 kdebug_sadb(struct sadb_msg *base)
@@ -96,8 +175,9 @@ kdebug_sadb(struct sadb_msg *base)
if (base == NULL)
panic("%s: NULL pointer was passed.\n", __func__);
 
-   printf("sadb_msg{ version=%u type=%u errno=%u satype=%u\n",
+   printf("sadb_msg{ version=%u type=%u(%s) errno=%u satype=%u\n",
base->sadb_msg_version, base->sadb_msg_type,
+   kdebug_sadb_type(base->sadb_msg_type),
base->sadb_msg_errno, base->sadb_msg_satype);
printf("  len=%u reserved=%u seq=%u pid=%u\n",
base->sadb_msg_len, base->sadb_msg_reserved,
@@ -107,8 +187,9 @@ kdebug_sadb(struct sadb_msg *base)
ext = (struct sadb_ext *)((caddr_t)base + sizeof(struct sadb_msg));
 
while (tlen > 0) {
-   printf("sadb_ext{ len=%u type=%u }\n",
-   ext->sadb_ext_len, ext->sadb_ext_type);
+   printf("sadb_ext{ len=%u type=%u(%s) }\n",
+   ext->sadb_ext_len, ext->sadb_ext_type,
+   kdebug_sadb_exttype(ext->sadb_ext_type));
 
if (ext->sadb_ext_len == 0) {
printf("%s: invalid ext_len=0 was passed.\n", __func__);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335794 - head/sys/fs/nfsserver

2018-06-29 Thread Rick Macklem
Author: rmacklem
Date: Fri Jun 29 12:41:36 2018
New Revision: 335794
URL: https://svnweb.freebsd.org/changeset/base/335794

Log:
  Fix the pNFS server for a case where mirror level equals number of DSs.
  
  If a pNFS service was set up where the number of DSs equals the mirror level
  and then a DS was disabled, the service would create files with duplicate
  entries for the same DS. This bug occurred because I didn't realize that
  TAILQ_FOREACH_FROM() would start at the beginning of the list when the
  inital value of the variable was NULL.
  This patch also changes the pNFS server DS file creation code so that it
  creates entrie(s) with 0.0.0.0 IP address when it cannot create mirror level
  files due to lack of DSs.
  The patch only affects the pNFS service and only when it was created with
  a number of DSs equal to the mirror level and mirroring is enabled.

Modified:
  head/sys/fs/nfsserver/nfs_nfsdport.c

Modified: head/sys/fs/nfsserver/nfs_nfsdport.c
==
--- head/sys/fs/nfsserver/nfs_nfsdport.cFri Jun 29 10:55:42 2018
(r335793)
+++ head/sys/fs/nfsserver/nfs_nfsdport.cFri Jun 29 12:41:36 2018
(r335794)
@@ -3859,8 +3859,8 @@ nfsrv_pnfscreate(struct vnode *vp, struct vattr *vap, 
i = dsdir[0] = ds->nfsdev_nextdir;
ds->nfsdev_nextdir = (ds->nfsdev_nextdir + 1) % nfsrv_dsdirsize;
dvp[0] = ds->nfsdev_dsdir[i];
-   if (nfsrv_maxpnfsmirror > 1) {
-   mds = TAILQ_NEXT(ds, nfsdev_list);
+   mds = TAILQ_NEXT(ds, nfsdev_list);
+   if (nfsrv_maxpnfsmirror > 1 && mds != NULL) {
TAILQ_FOREACH_FROM(mds, _devidhead, nfsdev_list) {
if (mds->nfsdev_nmp != NULL) {
dsdir[mirrorcnt] = i;
@@ -3879,7 +3879,8 @@ nfsrv_pnfscreate(struct vnode *vp, struct vattr *vap, 
if (mirrorcnt > 1)
tdsc = dsc = malloc(sizeof(*dsc) * (mirrorcnt - 1), M_TEMP,
M_WAITOK | M_ZERO);
-   tpf = pf = malloc(sizeof(*pf) * mirrorcnt, M_TEMP, M_WAITOK | M_ZERO);
+   tpf = pf = malloc(sizeof(*pf) * nfsrv_maxpnfsmirror, M_TEMP, M_WAITOK |
+   M_ZERO);
 
error = nfsvno_getfh(vp, , p);
if (error == 0)
@@ -3987,11 +3988,27 @@ nfsrv_pnfscreate(struct vnode *vp, struct vattr *vap, 
NFSFREECRED(tcred);
if (error == 0) {
ASSERT_VOP_ELOCKED(vp, "nfsrv_pnfscreate vp");
+
+   NFSD_DEBUG(4, "nfsrv_pnfscreate: mirrorcnt=%d maxmirror=%d\n",
+   mirrorcnt, nfsrv_maxpnfsmirror);
+   /*
+* For all mirrors that couldn't be created, fill in the
+* *pf structure, but with an IP address == 0.0.0.0.
+*/
+   tpf = pf + mirrorcnt;
+   for (i = mirrorcnt; i < nfsrv_maxpnfsmirror; i++, tpf++) {
+   *tpf = *pf;
+   tpf->dsf_sin.sin_family = AF_INET;
+   tpf->dsf_sin.sin_len = sizeof(struct sockaddr_in);
+   tpf->dsf_sin.sin_addr.s_addr = 0;
+   tpf->dsf_sin.sin_port = 0;
+   }
+
error = vn_start_write(vp, , V_WAIT);
if (error == 0) {
error = vn_extattr_set(vp, IO_NODELOCKED,
EXTATTR_NAMESPACE_SYSTEM, "pnfsd.dsfile",
-   sizeof(*pf) * mirrorcnt, (char *)pf, p);
+   sizeof(*pf) * nfsrv_maxpnfsmirror, (char *)pf, p);
if (error == 0)
error = vn_extattr_set(vp, IO_NODELOCKED,
EXTATTR_NAMESPACE_SYSTEM, "pnfsd.dsattr",
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


svn commit: r335793 - head/sys/riscv/conf

2018-06-29 Thread Ruslan Bukin
Author: br
Date: Fri Jun 29 10:55:42 2018
New Revision: 335793
URL: https://svnweb.freebsd.org/changeset/base/335793

Log:
  Include UART driver since it is now provided in QEMU.
  
  Sponsored by: DARPA, AFRL

Modified:
  head/sys/riscv/conf/GENERIC

Modified: head/sys/riscv/conf/GENERIC
==
--- head/sys/riscv/conf/GENERIC Fri Jun 29 04:52:27 2018(r335792)
+++ head/sys/riscv/conf/GENERIC Fri Jun 29 10:55:42 2018(r335793)
@@ -88,6 +88,10 @@ device   vtnet   # VirtIO 
Ethernet device
 device virtio_blk  # VirtIO Block device
 device virtio_mmio # VirtIO MMIO bus
 
+# Serial (COM) ports
+device uart# Generic UART driver
+device uart_ns8250 # ns8250-type UART driver
+
 # Uncomment for memory disk
 # options  MD_ROOT
 # options  MD_ROOT_SIZE=32768  # 32MB ram disk
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"


Re: svn commit: r335765 - head/sys/sys

2018-06-29 Thread Bruce Evans

On Thu, 28 Jun 2018, David Bright wrote:


Log:
 Remove potential identifier conflict in the EV_SET macro.

 PR43905 pointed out a problem with the EV_SET macro if the passed
 struct kevent pointer were specified with an expression with side
 effects (e.g., "kevp++"). This was fixed in rS110241, but by using a
 local block that defined an internal variable (named "kevp") to get
 the pointer value once. This worked, but could cause issues if an
 existing variable named "kevp" is in scope. To avoid that issue,
 jilles@ pointed out that "C99 compound literals and designated
 initializers allow doing this cleanly using a macro". This change
 incorporates that suggestion, essentially verbatim from jilles@
 comment on PR43905, except retaining the old definition for pre-C99 or
 non-STDC (e.g., C++) compilers.


This in unnecessarily elaborate and unportable.  It is reported to be broken
for gcc.  It leaves the non-C99 case as broken as before (not actually very
broken).  It has many style bugs.


Modified: head/sys/sys/event.h
==
--- head/sys/sys/event.hThu Jun 28 15:30:51 2018(r335764)
+++ head/sys/sys/event.hThu Jun 28 17:01:04 2018(r335765)
@@ -49,7 +49,26 @@
#define EVFILT_EMPTY(-13)   /* empty send socket buf */
#define EVFILT_SYSCOUNT 13

+#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L


Style bug: testing if an identifier is defined before using it in a cpp
expression.  Only broken compilers need this.  Some compilers have a
-Wundef flag to enable the brokenness.  IIRC, this brokenness is turned
back off by default for system headers, but -Wsystem-headers gives full
warnings for system headers too and FreeBSD is supposed to use the latter
so as to inhibit errors in system headers.

 has the same style bug for this particular identifier.
However, sys/types.h doesn't have this style bug for this identifier.

The style bug is especially not needed for this identifier because all
C90 and later compilers define this identifier, and there aren't many
other compilers.  The others are probably old and also don't support a
-Wundef flag to break themselves.


#define EV_SET(kevp_, a, b, c, d, e, f) do {\
+*(kevp_) = (struct kevent){\


Style bug: beginning of 4-column indentations.


+   .ident = (a),   \
+   .filter = (b),  \
+   ...
+}; \


Style bug: further 4-column indentations.


+} while(0)
+#else /* Pre-C99 or not STDC (e.g., C++) */
+/* The definition of the local variable kevp could possibly conflict
+ * with a user-defined value passed in parameters a-f.
+ */


It only conflicts because it is name is in the user namespace.  It should
be well known that variables in macros must be named beginning with _2_
underscores (or 1 underscore an an upper case letter for an uglier name).
1 underscore suffices for must implementation names (e.g., for function
parameters and struct members) because most names are in an inner score
that can't conflict.  The variable is in an inner scope here too.  However,
the -Wshadow option asks for warnings about for shadowed variables even
in inner scopes.


+#define EV_SET(kevp_, a, b, c, d, e, f) do {   \
struct kevent *kevp = (kevp_);  \
(kevp)->ident = (a); \
(kevp)->filter = (b);\


This has mounds of old style bugs, mostly created by the wrong fix in
r110241.  After r110241, there is no problem except -Wshadow warnings
a variable named kenvp.  However, kenvp might be a macro expanding to
'syntax error' or 'macro programmer's common bug #2'

Before r110241, there was no local variable; the arg was named kevp
and it was used directly.  This had macro programmer's common bug #1
(side effects).  Except, EV_SET() is an unsafe macro by the convention
that unsafe macros are spelled in upper case, so it is the caller's
responsibility to avoid side effects.

r110241 changed this to macro programmer's common bug #2 (namespace
error) and added many style bugs.  it added underscores to all the
wrong places -- to the end of the arg name instead of to the beginning
of the variable name.  This allowed it to not change the uses of the
variable.  However, all these uses became style bugs (bogus parentheses).
Even before r110241, this macro didn't have macro programmer's common
bug #0 (missing parentheses around args).

This part of the macro also gices an example of normal style (8-column
indentation), except it doesn't have a tab after #define or a blank line
after the declarations.

Correct fix:

#define EV_SET(kevp, a, b, c, d, e, f) do { \
struct kevent *__kevp = (kevp); \
\
__kevp->ident = (a); \
__kevp->filter = (b);\