Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On 22 Mar 2015, at 23:11, Garrett Cooper yaneurab...@gmail.com wrote: On Mar 22, 2015, at 15:09, Dimitry Andric d...@freebsd.org wrote: On 22 Mar 2015, at 23:04, Garrett Cooper yaneurab...@gmail.com wrote: On Mar 22, 2015, at 15:01, Craig Rodrigues rodr...@freebsd.org wrote: ... OK, converting expr.y to use unsigned integers would require a bit of work. Can you commit your patch to the Makefile? It fixes the problem for now. +1 I’d still like to know why clang 3.5 doesn’t have this behavior though — there might be other potential issues lurking around that need to be solved (either here, in ports, or both). Because this version optimizes better around undefined behavior. There are most likely many issues lurking around, and most certainly in ports. I would recommend using UBSan to tackle this kind of thing. I hope this got a ports tinderbox run first… It is called an exp-run in ports land, but that only really tests whether ports *build* successfully. For most ports, there is no good way of testing them, certainly not if they don't have their own testing facilities. That said, I have built quite a number of ports with 3.6.0, even before the import, and saw zero problems until now. Then again, I'm just one user, and that is a very low sample size. ;) I don't expect a great many problems with integer wrapping though. You have to realize that quite a lot of open source projects already went through this phase, when gcc started optimizing integer wrapping a few years ago. We are just slowly catching up. Adding UBSan to tinderbox runs for toolchain upgrades [in the future] might be a good idea. Maybe, but please note that both ASan and UBSan are still beta-ish under FreeBSD, there will most likely be bumps along the road. Any bug reports in that area are welcome. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Sun, Mar 22, 2015 at 3:01 PM, Craig Rodrigues rodr...@freebsd.org
wrote:
On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric d...@freebsd.org wrote:
On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org
wrote:
Ah right, that was on i386, on amd64 it does result in -2^63. It is
indeed caused by reliance on signed integer wrapping.
This diff should fix it, without rewriting the utility:
Index: bin/expr/Makefile
===
--- bin/expr/Makefile (revision 280156)
+++ bin/expr/Makefile (working copy)
@@ -6,6 +6,9 @@ PROG= expr
SRCS= expr.y
YFLAGS=
+# expr relies on signed integer wrapping
+CFLAGS+= -fwrapv
+
NO_WMISSING_VARIABLE_DECLARATIONS=
.if ${MK_TESTS} != no
Well, another alternative is to patch expr.y:
Index: expr.y
===
--- expr.y (revision 280353)
+++ expr.y (working copy)
@@ -393,7 +393,7 @@
}
void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/*
* sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
}
void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN a 0)
There were already some patches previously done to this
file to add volatile, so maybe this would be OK to do.
What do you think?
Volatile is not the solution, it is completely orthogonal. The correct
way would be to use unsigned integers, for which wrapping is defined,
then convert those back and forth when presenting the results to the
user.
OK, converting expr.y to use unsigned integers would require a bit of work.
Can you commit your patch to the Makefile? It fixes the problem for now.
Thanks for committing the fix. I wasn't aware of this topic, but it is
explained
quite nicely in this LLVM blog post:
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html#signed_overflow
Do you think we should further change expr.y with something like this:
Index: expr.y
===
--- expr.y (revision 280357)
+++ expr.y (working copy)
@@ -445,12 +445,13 @@
}
/*
- * We depend on undefined behaviour giving a result (in r).
- * To test this result, pass it as volatile. This prevents
- * optimizing away of the test based on the undefined behaviour.
+ * We depend on undefined signed integer overflow behaviour
+ * giving a result (in r).
+ * This file must be compiled with the -fwrapv compiler
+ * flag which forces defined behavior for signed integer overflow.
*/
void
-assert_times(intmax_t a, intmax_t b, volatile intmax_t r)
+assert_times(intmax_t a, intmax_t b, intmax_t r)
{
/*
* If the first operand is 0, no overflow is possible,
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Broadwell Support FreeBSD 10.1
I have a 4th gen core i3 running PC-BSD 10.1 in which I let the installer do its thing. It uses zfs for / but it's not encrypted. It gave me the laptop's native res which I think is 1366 x 768. I have a 4th gen desktop installed the same way which is giving me 1920x1080. I'm not sure how it dealt with the hard drive. I'd have to check. Marek Novotny https://github.com/marek-novotny On 03/22/2015 04:49 PM, Glen Barber wrote: On Sun, Mar 22, 2015 at 04:32:06PM -0700, Marek Novotny wrote: New to this group, and new to FreeBSD via PC-BSD. Really like it so far. Sorry if this has been asked to death already. Levono has their new T450 with the 5th gen intel Broadwell i5 processor. I bought it with the hopes of running PC-BSD latest version on it. It uses intel 5500 graphics as well. Any potential issues using this?? You won't be able to use accelerated graphics. I have the T540p which has the i7-4800MQ, and am quite happy with running FreeBSD CURRENT on it. I don't care about accelerated graphics too much, though. One nit with the laptop is I needed to use an external USB flash drive to store /boot on an MBR partition, because my hard drives are GPT-partitioned using ZFS on '/' on GELI-encrypted providers. Otherwise, I have noticed that using the /boot on the GPT disk enforces low resolution graphics (640x480 IIRC). By using a USB flash drive for /boot, I can get 1920x1080 resolution (one of the many reasons for choosing this laptop). (I've been meaning to put this into the FreeBSD Wiki, but EBUSY.) Glen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #866
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/866/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has stdarg.h after printf.h
On 22 Mar 2015, at 03:45, Mark Millard mar...@dsl-only.net wrote: ... Looking at the sources suggests that stdarg.h is explicitly in the #include sequence too late to guarantee va_args a definition at the point of its use in #include printf.h : stdarg.h is #include'd in pjdlog.c in the line after #include printf.h and printf.h itself does not (directly) include stdarg.h . /usr/include/printf.h (the LOOK HERE is my message editing) : ... #include stdio.h #include wchar.h /// LOOK HERE for lack of stdarg.h ... int __xvprintf(FILE *fp, const char *fmt0, va_list ap); ... /usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message editing) : ... #include sys/cdefs.h __FBSDID($FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 09:41:06Z pjd $); #include sys/types.h #include sys/socket.h #include sys/un.h #include netinet/in.h #include arpa/inet.h #include assert.h #include errno.h #include libutil.h #include limits.h #include printf.h /// LOOK HERE #include stdarg.h /// LOOK HERE for stdarg.h vs. printf.h order You should be able to include standard headers (or at least, headers in /usr/include) in any order, and printf.h includes stdio.h, which then defines the correct types. However, there is a problem in the gcc ports. What happens, is that the gcc port uses its *own* munged versions of stdio.h and stdarg.h, and includes them instead of the system versions. For example, the gcc 4.7 port has this fixed version of stdio.h: /usr/local/lib/gcc47/gcc/i386-portbld-freebsd11.0/4.7.4/include-fixed/stdio.h which explicitly *disables* our declaration of __va_list (the type which va_list is based on): typedef __va_list __not_va_list__; For functions like vprintf(), it replaces __va_list by a GNU builtin variant, for example: int vprintf(const char * __restrict, __gnuc_va_list); However, it does not properly declare the regular va_list type, and then things break in interesting ways. I think the ports should not attempt to fix our include files. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 11.0-CURRENT -r276514: lib/libpjdlog/pjdlog.c has stdarg.h after printf.h
Dimitry Adnric wrote: You should be able to include standard headers (or at least, headers in /usr/include) in any order, and printf.h includes stdio.h, which then defines the correct types. Another of the ANSI/ISO-C rules is: You must include a standard header before you refer to anything that it officially defines or declares. (The Standard C Library by P. J. Plauger, Copyright 1992, page 7, 3rd bullet under using headers.) Part of that status is tied to the following: In a correct ANSI/ISO-C implementation stdio.h defines one or more synonyms for va_list using names from the class of reserved-to-implementation names in order to declare vprintf, vfprintf, and vsprintf. But stdio.h does not declare va_list itself. No ANSI/ISO-C header is allowed to declare/define extra official-public-name items that are only officially from other headers. (Page 12.) [There are also 2 more major principles for standard headers: mutual independence (so order-independence) and idempotent status (repeatability).] Only stdargs.h is allowed to declare that exact name (va_list) --the synonym with the official, public name. va_list is one of many things with this private-name vs public-name synonym structure in ANSI/ISO-C. printf.h is not one of the 24 (C99) or so ANSI/ISO-C standard headers (by name). Nor is __xvprintf from the C standard. So the #include printf that I referenced is violating the standard by referring to something from stdargs.h before that header has been included. The existing source code is in error relative to ANSI/ISO-C. Also: Using the order #include stdarg.h #include printf.h in pjdlog.c does get rid of the problem. (As it should, per the above.) But I do not know that there is any official claim that the environment is to strictly follow ANSI/ISO-C for such points. There may be other principles instead. How comprehensive/complete is /usr/include header analogy to the ANSI/ISO-C rules? Does FreeBSD bother with having the private-named synonyms for headers that do not official declare/define something? Is FreeBSD as explicit as ANSI/ISO-C about where official definitions are and are not in headers? (Idempotent headers are the easier part to set up. Mutual-independence gets into private-named synonym techniques in order to deal with public names being only in the official places.) (ANSI/ISO-C does have examples of some specific things explicitly being declared/defined (public names) in more than one header: more examples where using reserved-name guard macros to gain idempotent status and order independence can be done.) Note: Much of my background information for this and the terminology that I use is from The Standard C Library by P. J. Plauger, Copyright 1992. But I've not noticed any later ANSI/ISO material indicating the the above has changed status in more recent vintages of the standard. I could be wrong since I've not tried to be comprehensive about analyzing changes. === Mark Millard markmi at dsl-only.net On 2015-Mar-22, at 05:14 AM, Dimitry Andric dim at FreeBSD.org wrote: On 22 Mar 2015, at 03:45, Mark Millard markmi at dsl-only.net wrote: ... Looking at the sources suggests that stdarg.h is explicitly in the #include sequence too late to guarantee va_args a definition at the point of its use in #include printf.h : stdarg.h is #include'd in pjdlog.c in the line after #include printf.h and printf.h itself does not (directly) include stdarg.h . /usr/include/printf.h (the LOOK HERE is my message editing) : ... #include stdio.h #include wchar.h /// LOOK HERE for lack of stdarg.h ... int __xvprintf(FILE *fp, const char *fmt0, va_list ap); ... /usr/srcC/lib/libpjdlog/pjdlog.c (the LOOK HERE's are my message editing) : ... #include sys/cdefs.h __FBSDID($FreeBSD: head/lib/libpjdlog/pjdlog.c 258791 2013-12-01 09:41:06Z pjd $); #include sys/types.h #include sys/socket.h #include sys/un.h #include netinet/in.h #include arpa/inet.h #include assert.h #include errno.h #include libutil.h #include limits.h #include printf.h /// LOOK HERE #include stdarg.h /// LOOK HERE for stdarg.h vs. printf.h order You should be able to include standard headers (or at least, headers in /usr/include) in any order, and printf.h includes stdio.h, which then defines the correct types. However, there is a problem in the gcc ports. What happens, is that the gcc port uses its *own* munged versions of stdio.h and stdarg.h, and includes them instead of the system versions. For example, the gcc 4.7 port has this fixed version of stdio.h: /usr/local/lib/gcc47/gcc/i386-portbld-freebsd11.0/4.7.4/include-fixed/stdio.h which explicitly *disables* our declaration of __va_list (the type which va_list is based on): typedef __va_list __not_va_list__; For functions like vprintf(), it replaces __va_list by a GNU builtin variant, for example: int vprintf(const char * __restrict, __gnuc_va_list); However, it does not properly
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #868
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/868/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Early panic at boot: exclusive sleep mutex hdac1 (HDA driver mutex) ...
On Thu, Mar 19, 2015 at 07:23:19AM -0700, David Wolfskill wrote: As noted in a thread on -mobile yesterday, I'm replacing my long-serving Dell M4400 laptop with a newer model (M4800) -- you can see -mobile archives for additional details if you're interested. What prompted this note was: * When I tried to boot head/i386, I got a rather quick panic (well before any file systems were mounted -- and before any swap space was allocated, so I didn't have a place for a crash dump. ... I was able to copy over a GENERIC head/r280342 kernel from my build machine to the laptop; that booted, and I was then able to do a source upgrade on the laptop: FreeBSD g1-254.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1546 r280342M/280343:1100066: Sun Mar 22 10:45:54 PDT 2015 r...@g1-254.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 So I should be able to resume daily tracking of head on my laptop. :-) (I also reviewed my kernel config file; it turns out that all of the sound-related stuff had been commented out, so I removed all of those lines: all other things being equal, I prefer simpler.) Peace, david -- David H. Wolfskill da...@catwhisker.org Those who murder in the name of God or prophet are blasphemous cowards. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpgaoesoG5S7.pgp Description: PGP signature
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On 22 Mar 2015, at 22:02, Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Mar 22, 2015 at 11:26 AM, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/867/ Can someone with toolchain expertise look at this? After the clang 3.6.1 import, /bin/expr behaves differently. With clang 3.5.0: # expr 4611686018427387904 + 4611686018427387904 expr: overflow With clang 3.6.1: # expr 4611686018427387904 + 4611686018427387904 -9223372036854775808 It works fine for me: $ /usr/obj/usr/src/bin/expr/expr 4611686018427387904 + 4611686018427387904 expr: overflow Are you using any special compilation flags? That said, having taken a quick look at expr.y, it does seem to rely on signed integer wrapping. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On 22 Mar 2015, at 22:23, Dimitry Andric d...@freebsd.org wrote:
On 22 Mar 2015, at 22:02, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Mar 22, 2015 at 11:26 AM, jenkins-ad...@freebsd.org wrote:
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/867/
Can someone with toolchain expertise look at this?
After the clang 3.6.1 import, /bin/expr behaves differently.
With clang 3.5.0:
# expr 4611686018427387904 + 4611686018427387904
expr: overflow
With clang 3.6.1:
# expr 4611686018427387904 + 4611686018427387904
-9223372036854775808
It works fine for me:
$ /usr/obj/usr/src/bin/expr/expr 4611686018427387904 + 4611686018427387904
expr: overflow
Ah right, that was on i386, on amd64 it does result in -2^63. It is indeed
caused by reliance on signed integer wrapping.
This diff should fix it, without rewriting the utility:
Index: bin/expr/Makefile
===
--- bin/expr/Makefile (revision 280156)
+++ bin/expr/Makefile (working copy)
@@ -6,6 +6,9 @@ PROG= expr
SRCS= expr.y
YFLAGS=
+# expr relies on signed integer wrapping
+CFLAGS+= -fwrapv
+
NO_WMISSING_VARIABLE_DECLARATIONS=
.if ${MK_TESTS} != no
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Mar 22, 2015, at 14:36, Dimitry Andric d...@freebsd.org wrote:
On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
Ah right, that was on i386, on amd64 it does result in -2^63. It is indeed
caused by reliance on signed integer wrapping.
This diff should fix it, without rewriting the utility:
Index: bin/expr/Makefile
===
--- bin/expr/Makefile (revision 280156)
+++ bin/expr/Makefile (working copy)
@@ -6,6 +6,9 @@ PROG= expr
SRCS= expr.y
YFLAGS=
+# expr relies on signed integer wrapping
+CFLAGS+= -fwrapv
+
NO_WMISSING_VARIABLE_DECLARATIONS=
.if ${MK_TESTS} != no
Well, another alternative is to patch expr.y:
Index: expr.y
===
--- expr.y (revision 280353)
+++ expr.y (working copy)
@@ -393,7 +393,7 @@
}
void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/*
* sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
}
void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN a 0)
There were already some patches previously done to this
file to add volatile, so maybe this would be OK to do.
What do you think?
Volatile is not the solution, it is completely orthogonal. The correct
way would be to use unsigned integers, for which wrapping is defined,
then convert those back and forth when presenting the results to the
user.
Before doing that — what changed in the past week that changed the behavior of
expr?
Thanks!
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Sun, Mar 22, 2015 at 11:26 AM, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/867/ Can someone with toolchain expertise look at this? After the clang 3.6.1 import, /bin/expr behaves differently. With clang 3.5.0: # expr 4611686018427387904 + 4611686018427387904 expr: overflow With clang 3.6.1: # expr 4611686018427387904 + 4611686018427387904 -9223372036854775808 -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Mar 22, 2015, at 14:02, Craig Rodrigues rodr...@freebsd.org wrote: On Sun, Mar 22, 2015 at 11:26 AM, jenkins-ad...@freebsd.org wrote: See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/867/ Can someone with toolchain expertise look at this? After the clang 3.6.1 import, /bin/expr behaves differently. With clang 3.5.0: # expr 4611686018427387904 + 4611686018427387904 expr: overflow With clang 3.6.1: # expr 4611686018427387904 + 4611686018427387904 -9223372036854775808 I suspect -fwrapv is at fault, but I need to do some digging first.. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
Ah right, that was on i386, on amd64 it does result in -2^63. It is indeed
caused by reliance on signed integer wrapping.
This diff should fix it, without rewriting the utility:
Index: bin/expr/Makefile
===
--- bin/expr/Makefile (revision 280156)
+++ bin/expr/Makefile (working copy)
@@ -6,6 +6,9 @@ PROG= expr
SRCS= expr.y
YFLAGS=
+# expr relies on signed integer wrapping
+CFLAGS+= -fwrapv
+
NO_WMISSING_VARIABLE_DECLARATIONS=
.if ${MK_TESTS} != no
Well, another alternative is to patch expr.y:
Index: expr.y
===
--- expr.y (revision 280353)
+++ expr.y (working copy)
@@ -393,7 +393,7 @@
}
void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/*
* sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
}
void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN a 0)
There were already some patches previously done to this
file to add volatile, so maybe this would be OK to do.
What do you think?
Volatile is not the solution, it is completely orthogonal. The correct
way would be to use unsigned integers, for which wrapping is defined,
then convert those back and forth when presenting the results to the
user.
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/867/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
Ah right, that was on i386, on amd64 it does result in -2^63. It is
indeed caused by reliance on signed integer wrapping.
This diff should fix it, without rewriting the utility:
Index: bin/expr/Makefile
===
--- bin/expr/Makefile (revision 280156)
+++ bin/expr/Makefile (working copy)
@@ -6,6 +6,9 @@ PROG= expr
SRCS= expr.y
YFLAGS=
+# expr relies on signed integer wrapping
+CFLAGS+= -fwrapv
+
NO_WMISSING_VARIABLE_DECLARATIONS=
.if ${MK_TESTS} != no
Well, another alternative is to patch expr.y:
Index: expr.y
===
--- expr.y (revision 280353)
+++ expr.y (working copy)
@@ -393,7 +393,7 @@
}
void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/*
* sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
}
void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN a 0)
There were already some patches previously done to this
file to add volatile, so maybe this would be OK to do.
What do you think?
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric d...@freebsd.org wrote:
On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
Ah right, that was on i386, on amd64 it does result in -2^63. It is
indeed caused by reliance on signed integer wrapping.
This diff should fix it, without rewriting the utility:
Index: bin/expr/Makefile
===
--- bin/expr/Makefile (revision 280156)
+++ bin/expr/Makefile (working copy)
@@ -6,6 +6,9 @@ PROG= expr
SRCS= expr.y
YFLAGS=
+# expr relies on signed integer wrapping
+CFLAGS+= -fwrapv
+
NO_WMISSING_VARIABLE_DECLARATIONS=
.if ${MK_TESTS} != no
Well, another alternative is to patch expr.y:
Index: expr.y
===
--- expr.y (revision 280353)
+++ expr.y (working copy)
@@ -393,7 +393,7 @@
}
void
-assert_plus(intmax_t a, intmax_t b, intmax_t r)
+assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/*
* sum of two positive numbers must be positive,
@@ -420,7 +420,7 @@
}
void
-assert_minus(intmax_t a, intmax_t b, intmax_t r)
+assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
{
/* special case subtraction of INTMAX_MIN */
if (b == INTMAX_MIN a 0)
There were already some patches previously done to this
file to add volatile, so maybe this would be OK to do.
What do you think?
Volatile is not the solution, it is completely orthogonal. The correct
way would be to use unsigned integers, for which wrapping is defined,
then convert those back and forth when presenting the results to the
user.
OK, converting expr.y to use unsigned integers would require a bit of work.
Can you commit your patch to the Makefile? It fixes the problem for now.
--
Craig
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Mar 22, 2015, at 15:01, Craig Rodrigues rodr...@freebsd.org wrote: ... OK, converting expr.y to use unsigned integers would require a bit of work. Can you commit your patch to the Makefile? It fixes the problem for now. +1 I’d still like to know why clang 3.5 doesn’t have this behavior though — there might be other potential issues lurking around that need to be solved (either here, in ports, or both). Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Broadwell Support FreeBSD 10.1
On Mon, Mar 23, 2015 at 12:32 AM, Marek Novotny marek.novo...@marspolar.com wrote: Hi group, New to this group, and new to FreeBSD via PC-BSD. Really like it so far. Sorry if this has been asked to death already. Levono has their new T450 with the 5th gen intel Broadwell i5 processor. I bought it with the hopes of running PC-BSD latest version on it. It uses intel 5500 graphics as well. Any potential issues using this?? Not really, FreeBSD neither have haswell (Gen 4) support. https://wiki.freebsd.org/Graphics -- Marek Novotny https://github.com/marek-novotny ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Atheros AR9460 and Acer Aspire V17 Nitro on FreeBSD 11 not working
ok, then hm, where's the gpio pin configured.. -a On 21 March 2015 at 21:55, Miguel Clara miguelmcl...@gmail.com wrote: On March 22, 2015 4:19:23 AM WET, Adrian Chadd adr...@freebsd.org wrote: Ok, so I'd cycle that rfkill gpio from 1 - uhm, whatever the max for that thing is (16?) Each time: ifconfig wlan0 down sysctl dev.ath.0.rfkill=X ifconfig wlan0 up ifconfig wlan0 list scan See if it sees anything. It seems to accept only 0 and 1. I'll have to play with that tomorrow as its almost 5am here. But it seems to show no scan results with either 0 or 1 (when running just scan... list scan works the first time.. but its not really re-scaning) -adrian -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #865
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/865/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: What's the official method to test the build now?
On Mar 21, 2015, at 5:32, Ryan Stone ryst...@gmail.com wrote: I still see the compile errors that I reported here: https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054803.html It affects these builds: sparc64 LINT kernel failed, check _.sparc64.LINT for details powerpc LINT kernel failed, check _.powerpc.LINT for details powerpc LINT64 kernel failed, check _.powerpc.LINT64 for details i386 LINT-NOINET kernel failed, check _.i386.LINT-NOINET for details i386 LINT-NOINET6 kernel failed, check _.i386.LINT-NOINET6 for details i386 LINT kernel failed, check _.i386.LINT for details i386 LINT-NOIP kernel failed, check _.i386.LINT-NOIP for details i386 LINT-VIMAGE kernel failed, check _.i386.LINT-VIMAGE for details The only issues I ran into were with ixl(4) on powerpc* using ref10-amd64.freebsd.org: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198805 . I think the other issues have been solved. Thanks! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On 22 Mar 2015, at 23:04, Garrett Cooper yaneurab...@gmail.com wrote: On Mar 22, 2015, at 15:01, Craig Rodrigues rodr...@freebsd.org wrote: ... OK, converting expr.y to use unsigned integers would require a bit of work. Can you commit your patch to the Makefile? It fixes the problem for now. +1 I’d still like to know why clang 3.5 doesn’t have this behavior though — there might be other potential issues lurking around that need to be solved (either here, in ports, or both). Because this version optimizes better around undefined behavior. There are most likely many issues lurking around, and most certainly in ports. I would recommend using UBSan to tackle this kind of thing. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867
On Mar 22, 2015, at 15:09, Dimitry Andric d...@freebsd.org wrote: On 22 Mar 2015, at 23:04, Garrett Cooper yaneurab...@gmail.com wrote: On Mar 22, 2015, at 15:01, Craig Rodrigues rodr...@freebsd.org wrote: ... OK, converting expr.y to use unsigned integers would require a bit of work. Can you commit your patch to the Makefile? It fixes the problem for now. +1 I’d still like to know why clang 3.5 doesn’t have this behavior though — there might be other potential issues lurking around that need to be solved (either here, in ports, or both). Because this version optimizes better around undefined behavior. There are most likely many issues lurking around, and most certainly in ports. I would recommend using UBSan to tackle this kind of thing. I hope this got a ports tinderbox run first… Adding UBSan to tinderbox runs for toolchain upgrades [in the future] might be a good idea. signature.asc Description: Message signed with OpenPGP using GPGMail
Broadwell Support FreeBSD 10.1
Hi group, New to this group, and new to FreeBSD via PC-BSD. Really like it so far. Sorry if this has been asked to death already. Levono has their new T450 with the 5th gen intel Broadwell i5 processor. I bought it with the hopes of running PC-BSD latest version on it. It uses intel 5500 graphics as well. Any potential issues using this?? -- Marek Novotny https://github.com/marek-novotny ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Broadwell Support FreeBSD 10.1
On Sun, Mar 22, 2015 at 04:32:06PM -0700, Marek Novotny wrote: New to this group, and new to FreeBSD via PC-BSD. Really like it so far. Sorry if this has been asked to death already. Levono has their new T450 with the 5th gen intel Broadwell i5 processor. I bought it with the hopes of running PC-BSD latest version on it. It uses intel 5500 graphics as well. Any potential issues using this?? You won't be able to use accelerated graphics. I have the T540p which has the i7-4800MQ, and am quite happy with running FreeBSD CURRENT on it. I don't care about accelerated graphics too much, though. One nit with the laptop is I needed to use an external USB flash drive to store /boot on an MBR partition, because my hard drives are GPT-partitioned using ZFS on '/' on GELI-encrypted providers. Otherwise, I have noticed that using the /boot on the GPT disk enforces low resolution graphics (640x480 IIRC). By using a USB flash drive for /boot, I can get 1920x1080 resolution (one of the many reasons for choosing this laptop). (I've been meaning to put this into the FreeBSD Wiki, but EBUSY.) Glen pgpyozg4V7PRp.pgp Description: PGP signature
Re: Broadwell Support FreeBSD 10.1
Thanks! Marek Novotny https://github.com/marek-novotny On 03/22/2015 04:42 PM, Oliver Pinter wrote: On Mon, Mar 23, 2015 at 12:32 AM, Marek Novotny marek.novo...@marspolar.com wrote: Hi group, New to this group, and new to FreeBSD via PC-BSD. Really like it so far. Sorry if this has been asked to death already. Levono has their new T450 with the 5th gen intel Broadwell i5 processor. I bought it with the hopes of running PC-BSD latest version on it. It uses intel 5500 graphics as well. Any potential issues using this?? Not really, FreeBSD neither have haswell (Gen 4) support. https://wiki.freebsd.org/Graphics -- Marek Novotny https://github.com/marek-novotny ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is still unstable: FreeBSD_HEAD-tests2 #869
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/869/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Broadwell Support FreeBSD 10.1
What a coincidence, I'm looking at getting a Broadwell micro PC. I'm looking at this Broadwell model: http://www.gigabyte.com.au/products/product-page.aspx?pid=4888#ov At the moment, I don't mind not having X but I would like it eventually, is there any idea on when Iris Pro support would be done? If not for a while are discrete Nvidia cards such as the 760 ( Which another model has ) which I can find in http://www.gigabyte.com.au/products/product-page.aspx?pid=5156#ov stable? Last time I used X with a GTX680 it would crash twice a week. Cheers, Brendan. On Mon, Mar 23, 2015 at 10:58 AM, Marek Novotny marek.novo...@marspolar.com wrote: I have a 4th gen core i3 running PC-BSD 10.1 in which I let the installer do its thing. It uses zfs for / but it's not encrypted. It gave me the laptop's native res which I think is 1366 x 768. I have a 4th gen desktop installed the same way which is giving me 1920x1080. I'm not sure how it dealt with the hard drive. I'd have to check. Marek Novotny https://github.com/marek-novotny On 03/22/2015 04:49 PM, Glen Barber wrote: On Sun, Mar 22, 2015 at 04:32:06PM -0700, Marek Novotny wrote: New to this group, and new to FreeBSD via PC-BSD. Really like it so far. Sorry if this has been asked to death already. Levono has their new T450 with the 5th gen intel Broadwell i5 processor. I bought it with the hopes of running PC-BSD latest version on it. It uses intel 5500 graphics as well. Any potential issues using this?? You won't be able to use accelerated graphics. I have the T540p which has the i7-4800MQ, and am quite happy with running FreeBSD CURRENT on it. I don't care about accelerated graphics too much, though. One nit with the laptop is I needed to use an external USB flash drive to store /boot on an MBR partition, because my hard drives are GPT-partitioned using ZFS on '/' on GELI-encrypted providers. Otherwise, I have noticed that using the /boot on the GPT disk enforces low resolution graphics (640x480 IIRC). By using a USB flash drive for /boot, I can get 1920x1080 resolution (one of the many reasons for choosing this laptop). (I've been meaning to put this into the FreeBSD Wiki, but EBUSY.) Glen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Jenkins build is back to stable : FreeBSD_HEAD-tests2 #870
See https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests2/870/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
bsdinstall and current (possible stable) snapshots
Hi Devin,
Recently I'm trying to install FreeBSD CURRENT from bootonly image
( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
stage, bootonly doesn't contain base, kernel,etc distributions but it contain
manifest file.
On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
fetched files. I suppose it will be fine with RELEASE bootonly iso but not with
stable/current.
there is 2 ways how we can handle it:
1) download remote MANIFEST if spotted checksum mismatch and trying to use it
2) allow user to continue installation with 'broken' distributions
I had to first put 10.1 then update it to HEAD :(
What do you think ?
--
wbr, tiger
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstall and current (possible stable) snapshots
On Mon, 23 Mar 2015 08:47:38 +0300
Sergey V. Dyatko sergey.dya...@gmail.com wrote:
Hi Devin,
Recently I'm trying to install FreeBSD CURRENT from bootonly image
( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
stage, bootonly doesn't contain base, kernel,etc distributions but it contain
manifest file.
On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
fetched files. I suppose it will be fine with RELEASE bootonly iso but not
with stable/current.
there is 2 ways how we can handle it:
1) download remote MANIFEST if spotted checksum mismatch and trying to use it
2) allow user to continue installation with 'broken' distributions
I had to first put 10.1 then update it to HEAD :(
What do you think ?
replying to myself :)
possible way. #3:
distribution filenames must contain svn revision. On checksum stage we can easy
check does local MANIFEST actual or we must use remote file...
--
wbr, tiger
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: bsdinstall and current (possible stable) snapshots
On 2015-03-23 01:52, Sergey V. Dyatko wrote:
On Mon, 23 Mar 2015 08:47:38 +0300
Sergey V. Dyatko sergey.dya...@gmail.com wrote:
Hi Devin,
Recently I'm trying to install FreeBSD CURRENT from bootonly image
( FreeBSD-11.0-CURRENT-amd64-20150302-r279514-bootonly.iso)
on IBM HS22 blade via bladecenter's kvm but I faced with problem on checksum
stage, bootonly doesn't contain base, kernel,etc distributions but it contain
manifest file.
On mirrors we have pub/FreeBSD/snapshots/${ARCH}/11.0-CURRENT/*txz and
MANIFEST, sha256 sums from _local_ manifest doesn't match sha256 sums for
fetched files. I suppose it will be fine with RELEASE bootonly iso but not
with stable/current.
there is 2 ways how we can handle it:
1) download remote MANIFEST if spotted checksum mismatch and trying to use it
2) allow user to continue installation with 'broken' distributions
I had to first put 10.1 then update it to HEAD :(
What do you think ?
replying to myself :)
possible way. #3:
distribution filenames must contain svn revision. On checksum stage we can
easy
check does local MANIFEST actual or we must use remote file...
--
wbr, tiger
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
I have worked around this by doing:
mount -t tmpfs tmpfs /usr/freebsd-dist
This hides the MANIFEST file shipped on the bootonly image, and when
there is no local MANIFEST to compare it, it fetches one from FTP along
with the dist files, and just works.
I am unsure what the best way to handle this properly is though.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
