From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 06:50:54 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CFD49A3 for ; Sun, 22 Mar 2015 06:50:54 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE838698 for ; Sun, 22 Mar 2015 06:50:53 +0000 (UTC) Received: (qmail 10855 invoked from network); 22 Mar 2015 06:50:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2015 06:50:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 22 Mar 2015 02:50:51 -0400 (EDT) Received: (qmail 823 invoked from network); 22 Mar 2015 06:50:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Mar 2015 06:50:51 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 0D1D51C43AF; Sat, 21 Mar 2015 23:50:49 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT -r276514's ncurses .vs gcc5-based buildworld: the generated lib_gen.c has problems Date: Sat, 21 Mar 2015 23:50:49 -0700 Message-Id: <65C07062-4CB6-4AAD-B5EC-63A9952CA496@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 06:50:54 -0000 Basic context (more details later): I ran into the below while exploring FreeBSD via a powerpc64 context. = But unlike most things I've run into this is probably not powerpc64 (or = powerpc) context specific. Nor does it appear to be as simple as the = out-of-order and/or incomplete includes issue that I ran into. gcc5 use is not likely where anyone is focused either. Still I figured I'd send out this note about the oddity as a FYI. > # dmesg | head > ... > FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 05:15:23 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... (I used powerpc64-xtoolchain-gcc in a powerpc64 context to self-host, = WITHOUT_CLANG=3D WITHOUT_LLDB=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D = WITHOUT_BOOT=3D WITHOUT_LIB32=3D .) > # freebsd-version -ku; uname -apKU = = 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat = Mar 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 > make -j 8 \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITH_BOOT=3D WITH_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 For the context set by the following in order to use gcc5/g++5/... : > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > # > # > # For trying gcc5... > # > CC=3D/usr/local/bin/gcc5 > CXX=3D/usr/local/bin/g++5 > CPP=3D/usr/local/bin/cpp5 > AS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/as > R=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ar > LD=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ld > NM=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/nm > OBJCOPY=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy > OBJDUMP=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump > RANLIB=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib > SIZE=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/size > STRINGS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/strings The problem when gcc5 was used: > /usr/local/bin/gcc5 -O2 -pipe -I. = -I/usr/obj/usr/srcC/lib/ncurses/ncurses/../ncurses = -I/usr/srcC/lib/ncurses/ncurses/../ncurses = -I/usr/srcC/lib/ncurses/ncurses/../ncurses = -I/usr/srcC/lib/ncurses/ncurses/../../../contrib/ncurses/include = -I/usr/srcC/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses -Wall = -DNDEBUG -DHAVE_CONFIG_H -DFREEBSD_NATIVE -DTERMIOS -std=3Dgnu99 = -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W = -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c lib_gen.c -o = lib_gen.o > _2624.c:754:3: error: "_Bool" after # is not a positive integer > In file included from = /usr/srcC/lib/ncurses/ncurses/../../../contrib/ncurses/ncurses/curses.priv= .h:313:0, > from lib_gen.c:19: > _2624.c:755:2: error: expected ')' before 'int' > *** Error code 1 >=20 > Stop. > make[4]: stopped in /usr/srcC/lib/ncurses/ncurses > *** Error code 1 Comparing the tail of the generated lib_gen.c from another 11.0-CURRENT = (non-gcc5) tree that I have around... First the tail from that other tree (the normal one): > # tail -20 lib_gen.c | more > T((T_CALLED("getmaxy(%p)"), (const void *)z)); returnCode(((z) = ? ((z)->_maxy + 1) : (-1))); > } >=20 >=20 > NCURSES_EXPORT(int) (getparx) (const WINDOW * z) > { > T((T_CALLED("getparx(%p)"), (const void *)z)); returnCode(((z) = ? (z)->_parx : (-1))); > } >=20 >=20 > NCURSES_EXPORT(int) (getpary) (const WINDOW * z) > { > T((T_CALLED("getpary(%p)"), (const void *)z)); returnCode(((z) = ? (z)->_pary : (-1))); > } >=20 >=20 > NCURSES_EXPORT(NCURSES_BOOL) (mouse_trafo) (int * a1, int * a2, = NCURSES_BOOL z) > { > T((T_CALLED("mouse_trafo(%p,%p,%#lx)"), (const void *)a1, = (const void *)a2, (long)z)); returnBool(wmouse_trafo(stdscr,a1,a2,z)); > } Then the tail for the generated file from the gcc5 based tree (the odd = one): > # tail -20 lib_gen.c >=20 >=20 > NCURSES_EXPORT(int) (getpary) (const WINDOW * z) > { > T((T_CALLED("getpary(%p)"), (const void *)z)); returnCode(((z) ? = (z)->_pary : (-1))); > } >=20 >=20 >=20 > # 753 "_2624.c" 3 4 > NCURSES_BOOL=20 > # 753 "_2624.c" > mouse_trafo (int * a1, int * a2,=20 > # 753 "_2624.c" 3 4 > NCURSES_BOOL=20 > # 753 "_2624.c" > z) > { > T((T_CALLED("mouse_trafo(%p,%p,%#lx)"), (const void *)a1, (const = void *)a2, (long)z)); returnBool(wmouse_trafo(stdscr,a1,a2,z)); > } Context details: # more /etc/make.conf WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D # svnlite info /usr/srcC/ Path: /usr/srcC Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # svnlite info /usr/ports/lang/gcc5 Path: /usr/ports/lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 09:17:10 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0195912B for ; Sun, 22 Mar 2015 09:17:09 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADA7C6DB for ; Sun, 22 Mar 2015 09:17:08 +0000 (UTC) Received: (qmail 5128 invoked from network); 22 Mar 2015 09:17:07 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Mar 2015 09:17:07 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 22 Mar 2015 05:17:07 -0400 (EDT) Received: (qmail 31190 invoked from network); 22 Mar 2015 09:17:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Mar 2015 09:17:07 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 51A9E1C43AF; Sun, 22 Mar 2015 02:17:05 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: A libc++ .depend status mismatch between /usr/src/Makefile.inc1 and bsd.prog.mk for ${X_COMPILER_TYPE} == gcc? Date: Sun, 22 Mar 2015 02:17:04 -0700 Message-Id: <4E9596C3-375E-42DE-ABA3-5066BE3756C5@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 09:17:10 -0000 Basic context: > # dmesg | head > ... > FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar 21 05:15:23 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... (I used powerpc64-xtoolchain-gcc in a powerpc64 context to self-host, = WITHOUT_CLANG=3D WITHOUT_LLDB=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D = WITHOUT_BOOT=3D WITHOUT_LIB32=3D . powerpc64-xtoolchain-gcc did not = provide itself with a libstdc++ of its own.) > # freebsd-version -ku; uname -apKU = 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat = Mar 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > # > # For trying powerpc64-xtoolchain-gcc... > # (Force stages that do not use XCC, XCXX, XCPP to > # also use powerpc64-xtoolchain.gcc's programs.) > # > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > # > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > # spans being-built and (failing finding those directories) live and = so for > # -DNO_CLEAN after being-built ones are in place and the results = depend on > # self-hosting where the two are sufficiently compatibile. > # > # I've used .../. paths below so I can tell use of these from other = sources of paths. > # > # Actually only appropriate for for _includes _libraries _depend = everything build32 : > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > # > # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools = _cleanobj _obj _build-tools _cross-tools : > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # > # But for self-hosting in a cross tools like manor sometimes having = both can work. The problem: /usr/src/Makefile.inc1 has the following code for cross compilation = contexts: > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 > .else > ... In essence having gcc based XCXX cross compilers (X_COMPILER_TYPE) use = libc++'s headers and library for XCXX with gnu++11 (so implicitly c++11) = enabled. libstdc++ is not used. [Note: atf-c++ did did not get automatic header access from the above = for some reason but my /etc/src.conf assignments covered that case.] bsd.prog.mk has the following contrasting code: > .if defined(PROG) > _EXTRADEPEND: > .if defined(LDFLAGS) && !empty(LDFLAGS:M-nostdlib) > .if defined(DPADD) && !empty(DPADD) > echo ${PROG_FULL}: ${DPADD} >> ${DEPENDFILE} > .endif > .else > echo ${PROG_FULL}: ${LIBC} ${DPADD} >> ${DEPENDFILE} > .if defined(PROG_CXX) > .if ${COMPILER_TYPE} =3D=3D "clang" && = empty(CXXFLAGS:M-stdlib=3Dlibstdc++) > echo ${PROG_FULL}: ${LIBCPLUSPLUS} >> ${DEPENDFILE} > .else > echo ${PROG_FULL}: ${LIBSTDCPLUSPLUS} >> ${DEPENDFILE} > .endif > .endif > .endif > .endif [There is no direct tie between X_COMPILER_TYPE and COMPILER_TYPE in = general but with my /etc/src.conf there is.] In essence (other than -nostdlib and also non-c++ code): Only when COMPILER_TYPE for c++ indicates clang explicitly (without = there being a -stdlib=3Dlibstdc++) is a libc++ dependency written out. = The other c++ cases without -nostdlib always write out a libstdc++ = dependency. My powerpc64-xtoolchain-gcc buildworld buildkernel logs do not show = libc++ additions to .depend files. But they do show the following (from grep activity), although not = necessarily from the above code in every case: echo gperf: /usr/lib/libstdc++.a >> .depend echo grodvi: /usr/lib/libstdc++.a >> .depend echo addftinfo: /usr/lib/libstdc++.a >> .depend echo groff: /usr/lib/libstdc++.a >> .depend echo hpftodit: /usr/lib/libstdc++.a >> .depend echo grn: /usr/lib/libstdc++.a >> .depend ... echo troff: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo hpftodit: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo tests_test: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> = .depend.tests_test echo indxbib: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo lkbib: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo utils_test: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> = .depend.utils_test echo lookbib: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo tfmtodit: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend echo cpp_helpers: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> = .depend.cpp_helpers echo users: /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a >> .depend Some stale .depend notices for libstdc++.a are also generated (more grep = activity): make[5]: /usr/obj/usr/srcC/libexec/atf/atf-check/.depend, 105: ignoring = stale .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[5]: /usr/obj/usr/srcC/libexec/atf/atf-sh/.depend, 89: ignoring = stale .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[4]: /usr/obj/usr/srcC/sbin/devd/.depend, 99: ignoring stale .depend = for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[8]: /usr/obj/usr/srcC/gnu/usr.bin/groff/src/devices/grodvi/.depend, = 34: ignoring stale .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[8]: = /usr/obj/usr/srcC/gnu/usr.bin/groff/src/devices/grohtml/.depend, 151: = ignoring stale .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[8]: /usr/obj/usr/srcC/gnu/usr.bin/groff/src/devices/grolbp/.depend, = 36: ignoring stale .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a ... make[4]: /usr/obj/usr/srcC/usr.bin/users/.depend, 77: ignoring stale = .depend for /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: = /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.atf_c++_test, 197: = ignoring stale .depend.atf_c++_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.build_test, = 199: ignoring stale .depend.build_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.check_test, = 204: ignoring stale .depend.check_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.macros_test, = 201: ignoring stale .depend.macros_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.tests_test, = 187: ignoring stale .depend.tests_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: /usr/obj/usr/srcC/lib/atf/libatf-c++/tests/.depend.utils_test, = 186: ignoring stale .depend.utils_test for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a make[7]: = /usr/obj/usr/srcC/lib/atf/tests/test-programs/.depend.cpp_helpers, 95: = ignoring stale .depend.cpp_helpers for = /usr/obj/usr/srcC/tmp/usr/lib/libstdc++.a Context details: # more /etc/make.conf=20 WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D # svnlite info /usr/srcC/ Path: . Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # svnlite status /usr/srcC/ --no-ignore ? /usr/srcC/.snap M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h M /usr/srcC/lib/libpjdlog/pjdlog.c ? /usr/srcC/restoresymtable M /usr/srcC/sys/ddb/db_main.c M /usr/srcC/sys/ddb/db_script.c ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/srcC/sys/powerpc/conf/GENERICvtsc ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c M /usr/srcC/sys/powerpc/ofw/ofwcall64.S =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 21:02:59 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39361B3; Sun, 22 Mar 2015 21:02:59 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C4024798; Sun, 22 Mar 2015 21:02:58 +0000 (UTC) Received: by lagg8 with SMTP id g8so120704244lag.1; Sun, 22 Mar 2015 14:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=QfmWkRN5Fl2Wf9XElIglde6sdrnsLBq2kJPTO7FY43k=; b=fH86xQF3n+Vbcv9maDHUHMGPQA0rd4gnnx9+vTRTs9Ud/D9gKSlZlih9ovUDbbW6Np QsFthcknYIOE2aHLIhzVGAX67/GFuRQMaMgvzBmzY85dG7FN0NHTd6yMgTuTvBbeLJZL CmEAP5vY+NpF1YfVmnnFOsPc8xMm7eC6ikIaSBp/1i6Z0BeJFiuUhz67qCqpUjgUZwOP jlxuHCuzZfcarQeSWSp5nxGeb0xsFBaNgwSbbfRQtScFpttYDq68Z9loNqbNoXgCWTSw C/4u0SIFCj0qZPGbM2ZJEx1aoDjRZ+sK8+tkSPJ/GYIPBAGaWWu4Btk9YJXoWc2RCwCE 1JMw== MIME-Version: 1.0 X-Received: by 10.112.223.7 with SMTP id qq7mr81441963lbc.81.1427058176678; Sun, 22 Mar 2015 14:02:56 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.82.164 with HTTP; Sun, 22 Mar 2015 14:02:56 -0700 (PDT) In-Reply-To: <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> Date: Sun, 22 Mar 2015 14:02:56 -0700 X-Google-Sender-Auth: tgE9gRRCr953zeFtkM5q5VYXZh0 Message-ID: Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 From: Craig Rodrigues To: "jenkins-admin@freebsd.org" , freebsd-current Current , "freebsd-testing@freebsd.org" , freebsd-toolchain@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 21:02:59 -0000 On Sun, Mar 22, 2015 at 11:26 AM, wrote: > See > 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 From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 21:03:57 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B5A401F2; Sun, 22 Mar 2015 21:03:57 +0000 (UTC) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76CA67A6; Sun, 22 Mar 2015 21:03:57 +0000 (UTC) Received: by pabxg6 with SMTP id xg6so156998519pab.0; Sun, 22 Mar 2015 14:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GaN6pm5V1eHaodeICvzChrHs/JYk2irjzDvVngnf+IY=; b=Bc2+uICEiefB+7C9sLo5rLLCmMAQESJ020fqqKpGY/jOBwgs2CjIhGEQdAYD2eFXcS pfYiF7uI+zYoMDm4xCG3qUqVPn/ymYCJDQzPRRA/uLBCQT41Sr7Rs0fwokdiOlYsv1iK n5uHA9MINjI5qXmW+NW3vjh0yNmuZveq1qUUEITZZ3rhRkqiWaNOBonizI7770ZDRpsx /WSwZtuJo90OF4jAiKQ7HS5wuLP8tSdtUpmoxRbV5CIVFnT/Q8dj05EV2YrokF0d/Uq1 r/6XuVMgXyQWEOgtbBzFRxIOEoHStFEa1liRyrKfr3ETf+OSF2jFrSD2vwvR0BidjIVD qCLg== X-Received: by 10.68.143.227 with SMTP id sh3mr14952002pbb.166.1427058236996; Sun, 22 Mar 2015 14:03:56 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:7544:258:ce3d:185a? ([2601:8:ab80:7d6:7544:258:ce3d:185a]) by mx.google.com with ESMTPSA id lr1sm14825850pab.39.2015.03.22.14.03.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 14:03:56 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_901EC205-2D1E-4777-B4AD-2C7189EA400D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 From: Garrett Cooper In-Reply-To: Date: Sun, 22 Mar 2015 14:03:53 -0700 Message-Id: <97AAE9BA-C748-4E8E-8DAF-20C145BCC0CD@gmail.com> References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 21:03:57 -0000 --Apple-Mail=_901EC205-2D1E-4777-B4AD-2C7189EA400D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Mar 22, 2015, at 14:02, Craig Rodrigues wrote: > On Sun, Mar 22, 2015 at 11:26 AM, wrote: > >> See >> > > 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! --Apple-Mail=_901EC205-2D1E-4777-B4AD-2C7189EA400D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVDy46AAoJEMZr5QU6S73euwwH/ROWznnMtty1kQl1kyReLqtV 7jdtDECAVrG23TyO2rcxqU1c61NHTYo5RztwKTQhexDHI58xcrnfWrXfrafDVXAy FjrD2MgKL4T8wtrFwPwV0aKPsDFEYBOgWGzmfsWNdTTGmUYyIZXCZ3HBgi5YrSXR kAYzXb3j+k1B6095njceqoRkFlrlkWK+2ZJKg+2M8GHZrdukLQSGLPEuXamxkqSQ RjoOb9H5XUt63c/uzRvOKmilomhlE0bdNbT47UDF1aeT1HNjpeW5SHS8I9IOM9vo xhDhKzGyPmoXD7rkZOjNN3MB7P/9G0YgnRMIsp2ElweNnKSg94yiFWMXC4Konm8= =eLQE -----END PGP SIGNATURE----- --Apple-Mail=_901EC205-2D1E-4777-B4AD-2C7189EA400D-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 21:23:51 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 933AAC75; Sun, 22 Mar 2015 21:23:51 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46F36983; Sun, 22 Mar 2015 21:23:51 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b11b:b36a:c2e8:f12e] (unknown [IPv6:2001:7b8:3a7:0:b11b:b36a:c2e8:f12e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 76CEB5C4C; Sun, 22 Mar 2015 22:23:41 +0100 (CET) Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6462D90B-46B0-43F8-9FF1-609FA2EB4A90"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: Date: Sun, 22 Mar 2015 22:23:30 +0100 Message-Id: References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 21:23:51 -0000 --Apple-Mail=_6462D90B-46B0-43F8-9FF1-609FA2EB4A90 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 22 Mar 2015, at 22:02, Craig Rodrigues wrote: > > On Sun, Mar 22, 2015 at 11:26 AM, wrote: > >> See >> > > 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 --Apple-Mail=_6462D90B-46B0-43F8-9FF1-609FA2EB4A90 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlUPMtwACgkQsF6jCi4glqN6HgCg7DTYA/komyK13OWbbDYo4nxx QaUAoKvbdLwLKUDPGRpXU6EA9RdhPofH =WhMV -----END PGP SIGNATURE----- --Apple-Mail=_6462D90B-46B0-43F8-9FF1-609FA2EB4A90-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 21:29:47 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 158C1E9C; Sun, 22 Mar 2015 21:29:47 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE03F9C2; Sun, 22 Mar 2015 21:29:46 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b11b:b36a:c2e8:f12e] (unknown [IPv6:2001:7b8:3a7:0:b11b:b36a:c2e8:f12e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C15E35C4C; Sun, 22 Mar 2015 22:29:44 +0100 (CET) Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1B247339-B440-44BF-81CB-2C53DA7C0EB4"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: Date: Sun, 22 Mar 2015 22:29:43 +0100 Message-Id: <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 21:29:47 -0000 --Apple-Mail=_1B247339-B440-44BF-81CB-2C53DA7C0EB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 22 Mar 2015, at 22:23, Dimitry Andric wrote: >=20 > On 22 Mar 2015, at 22:02, Craig Rodrigues wrote: >>=20 >> On Sun, Mar 22, 2015 at 11:26 AM, wrote: >>=20 >>> See >>>=20 >>=20 >> Can someone with toolchain expertise look at this? >> After the clang 3.6.1 import, /bin/expr behaves differently. >>=20 >> With clang 3.5.0: >>=20 >> # expr 4611686018427387904 + 4611686018427387904 >> expr: overflow >>=20 >> With clang 3.6.1: >>=20 >> # expr 4611686018427387904 + 4611686018427387904 >> -9223372036854775808 >=20 > It works fine for me: >=20 > $ /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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- bin/expr/Makefile (revision 280156) +++ bin/expr/Makefile (working copy) @@ -6,6 +6,9 @@ PROG=3D expr SRCS=3D expr.y YFLAGS=3D +# expr relies on signed integer wrapping +CFLAGS+=3D -fwrapv + NO_WMISSING_VARIABLE_DECLARATIONS=3D .if ${MK_TESTS} !=3D "no" -Dimitry --Apple-Mail=_1B247339-B440-44BF-81CB-2C53DA7C0EB4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlUPNEcACgkQsF6jCi4glqP5HwCeKYgKWHDn47Xr4qJQROpKmJo5 jxYAoO+QWs7JjiiTgzGMaXmRrepUcuHD =pRHL -----END PGP SIGNATURE----- --Apple-Mail=_1B247339-B440-44BF-81CB-2C53DA7C0EB4-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 21:33:01 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5EE0E3; Sun, 22 Mar 2015 21:33:01 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FBF6A72; Sun, 22 Mar 2015 21:33:01 +0000 (UTC) Received: by lbbrr9 with SMTP id rr9so42186406lbb.0; Sun, 22 Mar 2015 14:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Gx3r0ha82yDviFrhVbvVDE+vg24lBDCrOmqdvrxIflw=; b=mTs5DGfm1LNQCkdnCH+QwTlZnOMfENUsdwKDJcCudhT1yeqHBsqJtAiVnO7JvanEal BMzxsvS4N4NArnTvS02Ursk8mEC0CrD97GwJcbvyS77Wln+Mfdc7VLqVLAA3wOd4myBy +CRyQGOR+OigRpyoIWblAvQEPjB9y84qP5VWGGI5aTLiLy9a01TD6dKzHI2Avjq72bew Qky4onzZ0Bv/buNvtKZ9ugVKude+twVSmTN92XnyXvNynpieO+uEci153gRYJcdZ9wMm lFvNd0w15S0t5SQ6MD9EKOLvx2QPQ1eSutijkDui43CSR4M32xK+SfqeR6ypTsi3SzCs 5FtA== MIME-Version: 1.0 X-Received: by 10.152.3.42 with SMTP id 10mr80677543laz.84.1427059979554; Sun, 22 Mar 2015 14:32:59 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.82.164 with HTTP; Sun, 22 Mar 2015 14:32:59 -0700 (PDT) In-Reply-To: <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> Date: Sun, 22 Mar 2015 14:32:59 -0700 X-Google-Sender-Auth: 64PjJ_U7jWUfawIxHSroAkBtAPA Message-ID: Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 From: Craig Rodrigues To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 21:33:02 -0000 On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric 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 From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 21:36:18 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DC70480; Sun, 22 Mar 2015 21:36:18 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9B514AB7; Sun, 22 Mar 2015 21:36:17 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b11b:b36a:c2e8:f12e] (unknown [IPv6:2001:7b8:3a7:0:b11b:b36a:c2e8:f12e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0CD355C4C; Sun, 22 Mar 2015 22:36:15 +0100 (CET) Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C4B1A8DE-DE41-4ED5-BDEB-8B71E05450F7"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: Date: Sun, 22 Mar 2015 22:36:14 +0100 Message-Id: <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 21:36:18 -0000 --Apple-Mail=_C4B1A8DE-DE41-4ED5-BDEB-8B71E05450F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 22 Mar 2015, at 22:32, Craig Rodrigues wrote: >=20 > On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric = wrote: >=20 > Ah right, that was on i386, on amd64 it does result in -2^63. It is = indeed caused by reliance on signed integer wrapping. >=20 > This diff should fix it, without rewriting the utility: >=20 > Index: bin/expr/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- bin/expr/Makefile (revision 280156) > +++ bin/expr/Makefile (working copy) > @@ -6,6 +6,9 @@ PROG=3D expr > SRCS=3D expr.y > YFLAGS=3D >=20 > +# expr relies on signed integer wrapping > +CFLAGS+=3D -fwrapv > + > NO_WMISSING_VARIABLE_DECLARATIONS=3D >=20 > .if ${MK_TESTS} !=3D "no" >=20 >=20 > Well, another alternative is to patch expr.y: >=20 > Index: expr.y > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- expr.y (revision 280353) > +++ expr.y (working copy) > @@ -393,7 +393,7 @@ > } >=20 > 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 @@ > } >=20 > 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 =3D=3D INTMAX_MIN && a < 0) >=20 >=20 > There were already some patches previously done to this > file to add "volatile", so maybe this would be OK to do. >=20 > 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 --Apple-Mail=_C4B1A8DE-DE41-4ED5-BDEB-8B71E05450F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlUPNc4ACgkQsF6jCi4glqO/9wCfbYOH487q9/Xe+cpNxEuEGkNU G78An3RQijg4XLH7Ca2YhJS7gyMCgzIQ =rYXe -----END PGP SIGNATURE----- --Apple-Mail=_C4B1A8DE-DE41-4ED5-BDEB-8B71E05450F7-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 21:37:31 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFE216EF; Sun, 22 Mar 2015 21:37:31 +0000 (UTC) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6B550AC3; Sun, 22 Mar 2015 21:37:31 +0000 (UTC) Received: by pabxg6 with SMTP id xg6so157560019pab.0; Sun, 22 Mar 2015 14:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AnCijlR/ZSj7VqR8tlOleZ1dNaysWJNmoyDTkbs+5cI=; b=NERHttlR76bRFiuJFjTcHV6R+0BiriEfYt4dM948+HHxX13EFVtp0kHC9swf2Zp6Jn fB+nTH+x34D4b29o8zPo5AvDPOwKsmS4ECiXo1WFAFFMoSwxMYSneZpDkoYpkerW62qY iTmKdlbv9v/zv2kBprXoCPeSumnD0GO65vEtHblxruxxS1y/tcO5BgnqHb2HhQiZWvbD dulzRnegFHsrODOyDr35VWo1sE0RHAp6JGuZCCcg9PozOxUcqxLUGSW+oE4uFCF9v8VY kTdocJ/aQb90D8ffFWelio6fcKafIvy6686MC7saWczi2pksLgtKO7K3k/IOBPyN6NJ1 wUtg== X-Received: by 10.66.154.17 with SMTP id vk17mr205034907pab.5.1427060251000; Sun, 22 Mar 2015 14:37:31 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:7544:258:ce3d:185a? ([2601:8:ab80:7d6:7544:258:ce3d:185a]) by mx.google.com with ESMTPSA id jh2sm5157475pbb.25.2015.03.22.14.37.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 14:37:30 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_304F0F11-EC28-4252-9E60-0A9BD13758EF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 From: Garrett Cooper In-Reply-To: <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> Date: Sun, 22 Mar 2015 14:37:28 -0700 Message-Id: <3E288A39-D7DB-458A-B425-8B449DD57E35@gmail.com> References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 21:37:31 -0000 --Apple-Mail=_304F0F11-EC28-4252-9E60-0A9BD13758EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 22, 2015, at 14:36, Dimitry Andric wrote: > On 22 Mar 2015, at 22:32, Craig Rodrigues wrote: >>=20 >> On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric = wrote: >>=20 >> Ah right, that was on i386, on amd64 it does result in -2^63. It is = indeed caused by reliance on signed integer wrapping. >>=20 >> This diff should fix it, without rewriting the utility: >>=20 >> Index: bin/expr/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- bin/expr/Makefile (revision 280156) >> +++ bin/expr/Makefile (working copy) >> @@ -6,6 +6,9 @@ PROG=3D expr >> SRCS=3D expr.y >> YFLAGS=3D >>=20 >> +# expr relies on signed integer wrapping >> +CFLAGS+=3D -fwrapv >> + >> NO_WMISSING_VARIABLE_DECLARATIONS=3D >>=20 >> .if ${MK_TESTS} !=3D "no" >>=20 >>=20 >> Well, another alternative is to patch expr.y: >>=20 >> Index: expr.y >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- expr.y (revision 280353) >> +++ expr.y (working copy) >> @@ -393,7 +393,7 @@ >> } >>=20 >> 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 @@ >> } >>=20 >> 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 =3D=3D INTMAX_MIN && a < 0) >>=20 >>=20 >> There were already some patches previously done to this >> file to add "volatile", so maybe this would be OK to do. >>=20 >> What do you think? >=20 > 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 =97 what changed in the past week that changed the = behavior of expr? Thanks! --Apple-Mail=_304F0F11-EC28-4252-9E60-0A9BD13758EF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVDzYYAAoJEMZr5QU6S73eHW0H/RWRCspXwSZo7vbqsy6iRuOU 3Sr+rFduyTFuY1/TTnbLZYEUG/RmzS0hHDzw78r9XGh/5omjsiVXCIbV0GPIP07r Xy3T2qAuSdTi140mwcJMDCXpQQPXhtrIw4y1ZkrMJEe1+fVuOldRAPJJfiI5hJMC SnKLvAxhQ/KdQVTkB/DUN9XvZ2TeWRlinChGNA4Ca+5UoPZlHYI+cQWcybsSyQEA Z3Fho4XY3Tt8O6SUKramxaE638WgTD+0TWTxcz2kCo+hSdJnZ0T5cF9xQNb6DwR0 XzMoWsnOJVRgB7N3TDb5FhdBgJLYX8rwkwL0/ByAmoyc9r8oGlMlT8XtF/gxHNw= =DmrI -----END PGP SIGNATURE----- --Apple-Mail=_304F0F11-EC28-4252-9E60-0A9BD13758EF-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 22:01:27 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74909E09; Sun, 22 Mar 2015 22:01:27 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0409D8E; Sun, 22 Mar 2015 22:01:26 +0000 (UTC) Received: by lagg8 with SMTP id g8so121216876lag.1; Sun, 22 Mar 2015 15:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iL70EmHePH1o/E5SGc4YhyCEgj/7f3plGUrw3c0qOFk=; b=CUvBRllErHmA0TfSDH2IOgqajuzqjlfPvQYalo6cNNDR5+ZzcRKcmqSrJD6F2nRIGf Zx/6W4CH32SFhCxy6I5z+SL8b1OE3qggu9VUdewJnVQpOITYFipoEjV3p0reiHhnpsy7 lsRro7+zCUN7Ib+r07w8PlyYNcaMonF9zYRTmp8sQ+6FHTVQMaB2/tsRRslKtK4XtGTl PyDbpRVL8Rb2alTRccClnti2Y6ZCm/hnq6YSm2bvUwGp7hdgzlDar8Li1rEV9L6mY00C wdr2nkCnOvVs9aA+tcjYt5BO547twbo4atvci3MTjsUlZFeTyg/HAv6uf1src84MybhD giFQ== MIME-Version: 1.0 X-Received: by 10.152.3.42 with SMTP id 10mr80747513laz.84.1427061685096; Sun, 22 Mar 2015 15:01:25 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.82.164 with HTTP; Sun, 22 Mar 2015 15:01:25 -0700 (PDT) In-Reply-To: <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> Date: Sun, 22 Mar 2015 15:01:25 -0700 X-Google-Sender-Auth: ZYeQeFL3AW0rAaA67H01MfnpFQo Message-ID: Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 From: Craig Rodrigues To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 22:01:27 -0000 On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric wrote: > On 22 Mar 2015, at 22:32, Craig Rodrigues wrote: > > > > On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric 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 From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 22:04:04 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89BD6F71; Sun, 22 Mar 2015 22:04:04 +0000 (UTC) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4545DDA9; Sun, 22 Mar 2015 22:04:04 +0000 (UTC) Received: by pdnc3 with SMTP id c3so167254832pdn.0; Sun, 22 Mar 2015 15:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=0H9njTI3ohQspDWEx/Iy5IEuOhSr4VzatijPpGIKmzU=; b=y4+s18PMd7MSejTm0cNf2+gSWk9E2lC2x6Ww2FRvBH9SAUz81EYWOj6y3ks/xbFvy1 SHgsipzlYFVO9/pP9gXYSY0NfkuCAP29T4wacdygHe+n0Y4E3ePOJSBVed/MG2JBvi2E /2zcA+Xf6RVb41SK84//czCMZ2LDuIhj0Z0vXuG7KwI6hwW8wzfpzI9nnryS0uzqufIi UCwyLhyleauItKfxTYbo8Rok8zugQ8kOS+sajYSQuryb+F1j6yhl+QpRXNbUMAZSIDoa vKT16kOKsKrt1NKkge6VgQLb8DaV44ZbMoOJyJa5hgtY0C/+F3GTds6HamQLcP2pa3+w XlXw== X-Received: by 10.68.163.101 with SMTP id yh5mr15494328pbb.92.1427061843888; Sun, 22 Mar 2015 15:04:03 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:7544:258:ce3d:185a? ([2601:8:ab80:7d6:7544:258:ce3d:185a]) by mx.google.com with ESMTPSA id pu9sm14829192pdb.49.2015.03.22.15.04.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 15:04:03 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_72593F52-BBFE-4F0E-87BF-012C28BD9D22"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 From: Garrett Cooper In-Reply-To: Date: Sun, 22 Mar 2015 15:04:02 -0700 Message-Id: <08BB20A2-7B71-4ECF-B246-F3096CABA5E9@gmail.com> References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-testing@freebsd.org" , "jenkins-admin@freebsd.org" , freebsd-current Current , Dimitry Andric , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 22:04:04 -0000 --Apple-Mail=_72593F52-BBFE-4F0E-87BF-012C28BD9D22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 22, 2015, at 15:01, Craig Rodrigues wrote: ... > OK, converting expr.y to use unsigned integers would require a bit of = work. >=20 > Can you commit your patch to the Makefile? It fixes the problem for = now. +1 I=92d still like to know why clang 3.5 doesn=92t have this behavior = though =97 there might be other potential issues lurking around that = need to be solved (either here, in ports, or both). Thanks! --Apple-Mail=_72593F52-BBFE-4F0E-87BF-012C28BD9D22 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVDzxSAAoJEMZr5QU6S73ecAwH/07zmJK44HOANECcgXC63Xgy 2TVGP3kd1OtbkQ83Vl/bYoJb1QpAyc9pQwneeB4/8BQ2mowWv2tdNrj+d+fdaL0I Ib9eJBhfsPvEfSxZnoRNHaD0cSAxFnqy3IWYN2LzBc6bvgWsQfsVph96Ytt8w77U ZeNo1+KtWETtgy0uvR/Aw4b+hkggN96xTIWrnOpZTiA9ikSaE4HLq+C1xY42LwdE ARUv+emCFs6JI9QsCNcTvlBEyUKXWNI1dWiFOX/2OwA7jB07zFETBteTYpOtjayO Lb/oN91K+E4zT4MSSjZB8DuzA7SgLpgaLLTsrlOQSNxF/UGrKqJeXQSRphdXqKI= =0mqv -----END PGP SIGNATURE----- --Apple-Mail=_72593F52-BBFE-4F0E-87BF-012C28BD9D22-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 22:09:58 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 906A927A; Sun, 22 Mar 2015 22:09:58 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F432DDE; Sun, 22 Mar 2015 22:09:57 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b11b:b36a:c2e8:f12e] (unknown [IPv6:2001:7b8:3a7:0:b11b:b36a:c2e8:f12e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 44E495C4C; Sun, 22 Mar 2015 23:09:54 +0100 (CET) Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6336E6D8-6C10-4D78-BE7A-09B4801AA740"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: <08BB20A2-7B71-4ECF-B246-F3096CABA5E9@gmail.com> Date: Sun, 22 Mar 2015 23:09:40 +0100 Message-Id: <72ABF177-320F-4CB1-8B05-36B133714C55@FreeBSD.org> References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> <08BB20A2-7B71-4ECF-B246-F3096CABA5E9@gmail.com> To: Garrett Cooper X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 22:09:58 -0000 --Apple-Mail=_6336E6D8-6C10-4D78-BE7A-09B4801AA740 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 22 Mar 2015, at 23:04, Garrett Cooper wrote: >=20 > On Mar 22, 2015, at 15:01, Craig Rodrigues = wrote: >=20 > ... >=20 >> OK, converting expr.y to use unsigned integers would require a bit of = work. >>=20 >> Can you commit your patch to the Makefile? It fixes the problem for = now. >=20 > +1 >=20 > I=92d still like to know why clang 3.5 doesn=92t have this behavior = though =97 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 --Apple-Mail=_6336E6D8-6C10-4D78-BE7A-09B4801AA740 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlUPPbEACgkQsF6jCi4glqO+EQCfRV0coLqzbq/b7W2YbXnWWhiA wwUAnjhvUfeCwftSkCrah8o/tttHyjk3 =PUdl -----END PGP SIGNATURE----- --Apple-Mail=_6336E6D8-6C10-4D78-BE7A-09B4801AA740-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 22:11:26 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A778B4A1; Sun, 22 Mar 2015 22:11:26 +0000 (UTC) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 628E1E8D; Sun, 22 Mar 2015 22:11:26 +0000 (UTC) Received: by pdnc3 with SMTP id c3so167378325pdn.0; Sun, 22 Mar 2015 15:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cUvNI2mNl/LLuCKDsxT+AGYmKAIaaSwQ81n136ydiwM=; b=WMXxwk6JCW/YUTCrCCIvBtsEBqSDMUg77fQp+5GoV8tSA9RCBscnn+ikw16ddDNdP2 49+T3ZlPmSsYtavSpY+vNd+yXuxaHpobG3YzhCbJFcJvgZQGnEwvDdLNumWfK1F4Chnr 7c1wHb5v+4Sih/AR1zDhlebxhHbY0GW1Mac0rSQUcaOqTgBs+Rd6PlFu4mbLLPFOESUm k8aefepY/3P/lqI1/xJVf00z7qZkLPYZmN2pa908moE1U9uU8LZ5kXjkRJUwnwdwwDHN FRD2pkoxrZF9DXLLBHLxZOkiNTfoaiONmUJbjl4zVnb5Q7osg9O4ey6TVrp2c4xgta1K M7WA== X-Received: by 10.68.97.65 with SMTP id dy1mr15499666pbb.10.1427062285909; Sun, 22 Mar 2015 15:11:25 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:7544:258:ce3d:185a? ([2601:8:ab80:7d6:7544:258:ce3d:185a]) by mx.google.com with ESMTPSA id ha5sm5194700pbb.34.2015.03.22.15.11.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Mar 2015 15:11:25 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_029FC81D-E914-4D1C-8C87-527A0BE03AA8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 From: Garrett Cooper In-Reply-To: <72ABF177-320F-4CB1-8B05-36B133714C55@FreeBSD.org> Date: Sun, 22 Mar 2015 15:11:22 -0700 Message-Id: References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> <08BB20A2-7B71-4ECF-B246-F3096CABA5E9@gmail.com> <72ABF177-320F-4CB1-8B05-36B133714C55@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1878.6) Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 22:11:26 -0000 --Apple-Mail=_029FC81D-E914-4D1C-8C87-527A0BE03AA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 22, 2015, at 15:09, Dimitry Andric wrote: > On 22 Mar 2015, at 23:04, Garrett Cooper = wrote: >>=20 >> On Mar 22, 2015, at 15:01, Craig Rodrigues = wrote: >>=20 >> ... >>=20 >>> OK, converting expr.y to use unsigned integers would require a bit = of work. >>>=20 >>> Can you commit your patch to the Makefile? It fixes the problem for = now. >>=20 >> +1 >>=20 >> I=92d still like to know why clang 3.5 doesn=92t have this behavior = though =97 there might be other potential issues lurking around that = need to be solved (either here, in ports, or both). >=20 > Because this version optimizes better around undefined behavior. = There > are most likely many issues lurking around, and most certainly in = ports. >=20 > I would recommend using UBSan to tackle this kind of thing. I hope this got a ports tinderbox run first=85 Adding UBSan to tinderbox = runs for toolchain upgrades [in the future] might be a good idea. --Apple-Mail=_029FC81D-E914-4D1C-8C87-527A0BE03AA8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVDz4KAAoJEMZr5QU6S73e3rcH/1ZT6l5PyKPV3xGX0YGSjSPn J2bSOr8vpBx60voNtrHLslpsqUQEDVXGSing0mhXxHDNx4+QzZqCvP6N3BRXr02c mYm/ikZBJ0fE6AjplOKX4DrVUh65PEGnp9+9z/3XezBebvQKmdbt2Uo3mHfQUQcq 08wj/nc5wtpf2W3bcCDE6iYU1bwWDZYpbwlTQjCpegzWW2Q+EDYMdIE2bEXkEBmq up55M5pVqbIhelY1D/d5BlW/PYDGKop5JDDmH8STiG1eSBNuUJtv6T/9+3inVZAk y9iWvP0GzkE+oD8mJOKVZ1MFF/Z24qzH0VszhWvdBW41r4aIVyj4SK5UFtTTnCY= =jFNA -----END PGP SIGNATURE----- --Apple-Mail=_029FC81D-E914-4D1C-8C87-527A0BE03AA8-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 22:19:25 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0171E820; Sun, 22 Mar 2015 22:19:24 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74C41EBE; Sun, 22 Mar 2015 22:19:24 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b11b:b36a:c2e8:f12e] (unknown [IPv6:2001:7b8:3a7:0:b11b:b36a:c2e8:f12e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A0C745C4D; Sun, 22 Mar 2015 23:19:21 +0100 (CET) Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A2E23188-C424-494C-B941-7BF4A9BACA97"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: Date: Sun, 22 Mar 2015 23:19:20 +0100 Message-Id: References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> <08BB20A2-7B71-4ECF-B246-F3096CABA5E9@gmail.com> <72ABF177-320F-4CB1-8B05-36B133714C55@FreeBSD.org> To: Garrett Cooper X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 22:19:25 -0000 --Apple-Mail=_A2E23188-C424-494C-B941-7BF4A9BACA97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 22 Mar 2015, at 23:11, Garrett Cooper wrote: >=20 > On Mar 22, 2015, at 15:09, Dimitry Andric wrote: >=20 >> On 22 Mar 2015, at 23:04, Garrett Cooper = wrote: >>>=20 >>> On Mar 22, 2015, at 15:01, Craig Rodrigues = wrote: >>>=20 >>> ... >>>=20 >>>> OK, converting expr.y to use unsigned integers would require a bit = of work. >>>>=20 >>>> Can you commit your patch to the Makefile? It fixes the problem = for now. >>>=20 >>> +1 >>>=20 >>> I=92d still like to know why clang 3.5 doesn=92t have this behavior = though =97 there might be other potential issues lurking around that = need to be solved (either here, in ports, or both). >>=20 >> Because this version optimizes better around undefined behavior. = There >> are most likely many issues lurking around, and most certainly in = ports. >>=20 >> I would recommend using UBSan to tackle this kind of thing. >=20 > I hope this got a ports tinderbox run first=85 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 --Apple-Mail=_A2E23188-C424-494C-B941-7BF4A9BACA97 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlUPP+gACgkQsF6jCi4glqNNQgCdEyuU258imuu7h+koQkg2q/B0 SWEAmwaAd9VLhiRiz2+5Th9OyPxyxlGO =lsge -----END PGP SIGNATURE----- --Apple-Mail=_A2E23188-C424-494C-B941-7BF4A9BACA97-- From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 22 23:21:50 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0D952C8; Sun, 22 Mar 2015 23:21:50 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 709046E4; Sun, 22 Mar 2015 23:21:50 +0000 (UTC) Received: by lagg8 with SMTP id g8so121918103lag.1; Sun, 22 Mar 2015 16:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oiL2vrrT5PIPZmTnbWngtkHzy9QqKDZJBZC84uZyYuY=; b=DtVxJii3lPpTB9gvNoD5P/GsN5aVPCecKp7QQ7ptYTaGC5KHErdztA4vS+HxYozjZB U5xDP9p3on8BWcS8gkiF5Kpc2qWHkD/JNnuxyK5M2sRdQVxZYMR/H8FhKxYawjTntd56 Fs/KfCLIuJ0fZ25hyU0hVZj8Cr4lcNu+OAoEsrf9epJ2/SamvMfEKkg8veQPSdWBMszT IS525yyZq61UOG29223zyzVgBG9IdDKpBFAh9yt2uAyUblBagPVPvEBnCBIV31lICaPT oLUt9VzfaMB67zoEqmOgILQhX1QiV5uHA3eqjYYHukTSDwHrwMOg0c8B4tjYcb1Ud/ek /oBg== MIME-Version: 1.0 X-Received: by 10.152.234.108 with SMTP id ud12mr61998006lac.81.1427066508535; Sun, 22 Mar 2015 16:21:48 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.82.164 with HTTP; Sun, 22 Mar 2015 16:21:48 -0700 (PDT) In-Reply-To: References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> Date: Sun, 22 Mar 2015 16:21:48 -0700 X-Google-Sender-Auth: ZPKE2ILuCH-vTojAgLI-Pf3tUDA Message-ID: Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 From: Craig Rodrigues To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , freebsd-current Current , "jenkins-admin@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 23:21:51 -0000 On Sun, Mar 22, 2015 at 3:01 PM, Craig Rodrigues wrote: > > > On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric wrote: > >> On 22 Mar 2015, at 22:32, Craig Rodrigues wrote: >> > >> > On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric >> 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 From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 23 00:49:22 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA0CE954; Mon, 23 Mar 2015 00:49:22 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B69AEEA; Mon, 23 Mar 2015 00:49:22 +0000 (UTC) Received: by labto5 with SMTP id to5so14939710lab.0; Sun, 22 Mar 2015 17:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=ZCoAY1/5cFcgWaBdLgZ6QlzDlswQ1DsKlqkGQdyizRE=; b=So4D2A59QFCSC6XwiN6sBPMuDI/kEIe2S9scZaMfl5coecBKE8dwD7r4D1TUa20CqU PCSbyRzI9eV/1x90HIslj4ujg2cjKPmRp5LgoXgWeJVmbjxp9GYegEAY5WzCsSKkKwQh lO93w7LPniThnbiK829y3689f8pxrnXcXMhd1/T5HNj+vjPL4eC3dwZuOHIwGE4n/J2E Mdz2GiQ+uoxrbn7zltDhyhJ3kppVHxHLp/uBZu9VCKIgAlhF2mRc6+EuHpCj88rfuAsG 5muCqikmyfv5xhB03JVjg3/Lt3S9yqx9IPdy9TU4gj0NsvMDXZzUavcCt2vbzPI5aQpL ZT/g== MIME-Version: 1.0 X-Received: by 10.112.17.8 with SMTP id k8mr10631215lbd.26.1427071760150; Sun, 22 Mar 2015 17:49:20 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.82.164 with HTTP; Sun, 22 Mar 2015 17:49:20 -0700 (PDT) Date: Sun, 22 Mar 2015 17:49:20 -0700 X-Google-Sender-Auth: vupqQNDAKvrWzmb2PRHLUB3LrjA Message-ID: Subject: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import From: Craig Rodrigues To: freebsd-toolchain@freebsd.org, "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 00:49:23 -0000 Hi, I tried to build HEAD with gcc 4.9.1 after the latest clang 3.6.0 import, and am getting new build failures related to C++ such as: /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:881:87: error: use of deleted function 'clang::Sema::TypoExprState::TypoExprState(const clang::Sema::TypoExprState&)' sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T1>())) == 1 See full build logs here: https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/21/console Any ideas what the problem might be? Thanks. -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 23 04:56:42 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F355805 for ; Mon, 23 Mar 2015 04:56:42 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7C18ADC for ; Mon, 23 Mar 2015 04:56:41 +0000 (UTC) Received: (qmail 24276 invoked from network); 23 Mar 2015 04:56:34 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 23 Mar 2015 04:56:34 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 23 Mar 2015 00:56:34 -0400 (EDT) Received: (qmail 22843 invoked from network); 23 Mar 2015 04:56:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Mar 2015 04:56:33 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id C76B31C43BE; Sun, 22 Mar 2015 21:56:26 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import Date: Sun, 22 Mar 2015 21:56:31 -0700 Message-Id: <96AD8046-52B1-455F-A07B-39FA8CADF80D@dsl-only.net> To: rodrigc@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 04:56:42 -0000 I'd sent out a note Saturday for this for powerpc64-xtoolchain-gcc and = its powerpc64-gcc port: use of CROSS_TOOLCHAIN=3Dpowerpc64-gcc used on a = powerpc64. No solution, just notes about what was going on after looking = at the source code related to the messages. If you care, see: > CROSS_TOOLCHAIN=3Dpowerpc64-gcc mishandles "Substitution Failure Is = Not An Error" when compiling clang and stops the build ( = https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001506.ht= ml ) > = sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T= 1>())) > =3D=3D 1 is the core place involved in your example and mine but the order of = compilation for my context means a different starting place that ended = up using the above. lang/gcc5 did the same when I later tried it. I doubt that host-type or TARGET or TARGET_ARCH matter. I doubt = xtoolchain vs. normal port matters. I expect that the issue spans a = range of g++ versions. Unfortunately that probably also means that the effectively = "Substitution Failure of this kind Is An Error" rule now in use will = probably be around for a while: it is likely not some local accident = that has a quick fix. The best case is if it is simple but each = version/variant needs to release with the change. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 23 07:13:03 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CC3616B; Mon, 23 Mar 2015 07:13:03 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0692F9D0; Mon, 23 Mar 2015 07:13:03 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b11b:b36a:c2e8:f12e] (unknown [IPv6:2001:7b8:3a7:0:b11b:b36a:c2e8:f12e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C0EC75C4D; Mon, 23 Mar 2015 08:12:58 +0100 (CET) Subject: Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_01478318-A03E-4546-90F2-CAF8BC69E45E"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: Date: Mon, 23 Mar 2015 08:12:48 +0100 Message-Id: <5F90BE99-E82C-4444-9E4C-5963B40AA3B0@FreeBSD.org> References: To: Craig Rodrigues X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-testing@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 07:13:03 -0000 --Apple-Mail=_01478318-A03E-4546-90F2-CAF8BC69E45E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 23 Mar 2015, at 01:49, Craig Rodrigues wrote: >=20 > Hi, >=20 > I tried to build HEAD with gcc 4.9.1 after the latest clang 3.6.0 = import, > and am getting > new build failures related to C++ such as: >=20 > = /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_extern= al_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:881:87: > error: use of deleted function > 'clang::Sema::TypoExprState::TypoExprState(const > clang::Sema::TypoExprState&)' >=20 > = sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T= 1>())) > =3D=3D 1 >=20 > See full build logs here: > = https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/21/con= sole >=20 > Any ideas what the problem might be? Yes, this is a bug in libc++, when compiling it with newer versions of gcc. I reported this upstream some time ago: https://llvm.org/PR22771 Still haven't had enough time to test Eric Fiselier's patch for it. I hope I see the bottom of my TODO list anytime soon... -Dimitry --Apple-Mail=_01478318-A03E-4546-90F2-CAF8BC69E45E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlUPvPkACgkQsF6jCi4glqM44QCggtP/UKqPA8Ab8U42C88CrM9Y 1JAAnjrQ7BSCcnZedVr+rW0GpMWFRqBp =jUkP -----END PGP SIGNATURE----- --Apple-Mail=_01478318-A03E-4546-90F2-CAF8BC69E45E-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 23 09:39:30 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC3F2F5A; Mon, 23 Mar 2015 09:39:30 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C361C94; Mon, 23 Mar 2015 09:39:29 +0000 (UTC) Received: from [192.168.0.7] (cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61]) (authenticated bits=0) by theravensnest.org (8.15.1/8.14.9) with ESMTPSA id t2N9b8Ld024621 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 09:38:23 GMT (envelope-from theraven@FreeBSD.org) X-Authentication-Warning: theravensnest.org: Host cpc16-cmbg15-2-0-cust60.5-4.cable.virginm.net [86.5.162.61] claimed to be [192.168.0.7] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867 From: David Chisnall In-Reply-To: Date: Mon, 23 Mar 2015 09:33:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1669399171.13.1427029129760.JavaMail.jenkins@jenkins-9.freebsd.org> <799490341.14.1427048792932.JavaMail.jenkins@jenkins-9.freebsd.org> <494AEF4B-0AF8-449A-9B41-9AC4F4552AF0@FreeBSD.org> <864EB4DB-2DF7-4294-9498-95E54E6B49CC@FreeBSD.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-testing@freebsd.org" , "jenkins-admin@freebsd.org" , freebsd-current Current , Dimitry Andric , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 09:39:30 -0000 On 22 Mar 2015, at 22:01, Craig Rodrigues wrote: >=20 >> 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. >>=20 >=20 > OK, converting expr.y to use unsigned integers would require a bit of = work. Note that clang has, for a few releases, had builtins that allow = overflow-checked operations and will generate very efficient code. In = op_times, I believe the following should work: long long mul; #if __has_builtin(__builtin_smulll_overflow) if (__builtin_smulll_overflow(a->u.i, b->u.i, &mul)) errx(ERR_EXIT, "overflow");=20 #else mul =3D a->u.i * b->u.i; #endif r =3D make_integer(mul); I don't know if recent versions of gcc implement these builtins yet. I = think they were added to clang around 3.4, possibly slightly earlier. =20= David From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 23 17:26:45 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98194EAD for ; Mon, 23 Mar 2015 17:26:45 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F9B0E69 for ; Mon, 23 Mar 2015 17:26:44 +0000 (UTC) Received: (qmail 9972 invoked from network); 23 Mar 2015 17:00:03 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 23 Mar 2015 17:00:03 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 23 Mar 2015 13:00:03 -0400 (EDT) Received: (qmail 23977 invoked from network); 23 Mar 2015 17:00:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Mar 2015 17:00:03 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 7DCB11C43A6; Mon, 23 Mar 2015 09:59:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: CROSS_TOOLCHAIN=powerpc64-gcc mishandles "Substitution Failure Is Not An Error" when compiling clang and stops the build From: Mark Millard In-Reply-To: <52182692-C48C-4438-8AF1-318828E8F966@dsl-only.net> Date: Mon, 23 Mar 2015 10:00:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2C8146E7-B814-4F40-BEB0-224CF79C0BBD@dsl-only.net> References: <52182692-C48C-4438-8AF1-318828E8F966@dsl-only.net> To: freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:26:45 -0000 https://llvm.org/bugs/show_bug.cgi?id=3D22771 from Dimitry Andric's = submittal of the problem indicates that the libc++ code is not a = "Substitution Failure Is Not An Error" context and so is wrong. (C is = certainly simpler than C++ for identifying what applies where.) They have an improvement but Richard Smith's tiny test case shows it is = not yet correct: > Here's a testcase that fails with Clang: >=20 > #define __has_feature(x) 0 > #include > class X { X(const X&); }; > bool b =3D std::is_convertible::value; >=20 > (Using a public deleted copy constructor fails similarly.) in that both the original code and the improvement fail to compile the = above but instead treat it as an error. (Dimitry Andric tested the = improvement and https://llvm.org/bugs/show_bug.cgi?id=3D22771 shows the = error that he got.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-20, at 11:27 PM, Mark Millard = wrote: Basic context: > # dmesg | head > ... > FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \ > WITH_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 For the context set by: > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > WITH_LIBCPLUSPLUS=3D > # > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > # spans being-built and (failing finding those directories) live and = so for > # -DNO_CLEAN after being-built ones are in place depends on = self-hodsting > # where the two are sufficient compatibile. > # > # I've used .../. paths so I can tell use of these from other sources = of paths. > # > # Actually only appropriate for for _includes _libraries _depend = everything build32 : > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > # > # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools = _cleanobj _obj _build-tools _cross-tools : > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # > # But for self-hosting in a cross tools like manor sometimes having = both can work. > # > NO_WERROR=3D The problem: (Somewhat reformatted text...) > In file included from /usr/include/c++/v1/./algorithm:625:0, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringRef.h:13, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:17, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Supp= ort/SpecialCaseList.h:51, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:17: > /usr/include/c++/v1/./type_traits: >=20 > In instantiation of 'struct std::__1::__is_convertible&, = llvm::StringMap, 0u, 0u>': > /usr/include/c++/v1/./type_traits:943:62: > required from >=20 > 'struct std::__1::is_convertible&, = llvm::StringMap >' > /usr/include/c++/v1/./utility:269:77: > required by >=20 > substitution of 'template std::__1::pair<_T1, = _T2>::pair(const std::__1::pair<_U1, _U2>&, typename = std::__1::enable_if<(std::__1::is_convertible::value && = std::__1::is_convertible::value)>::type*) [with _U1 =3D = llvm::StringRef; _U2 =3D llvm::StringMap]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:371:55: > required from >=20 > 'llvm::StringMap::MapEntryTy& = llvm::StringMap::GetOrCreateValue(llvm::StringRef, = InitTy) [with InitTy =3D llvm::StringMap; = ValueTy =3D llvm::StringMap; AllocatorTy =3D= llvm::MallocAllocator; llvm::StringMap::MapEntryTy =3D = llvm::StringMapEntry >]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:375:43: > required from >=20 > 'llvm::StringMap::MapEntryTy& = llvm::StringMap::GetOrCreateValue(llvm::StringRef) = [with ValueTy =3D llvm::StringMap; = AllocatorTy =3D llvm::MallocAllocator; llvm::StringMap::MapEntryTy =3D = llvm::StringMapEntry >]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:299:32: > required from >=20 > 'ValueTy& llvm::StringMap::operator[](llvm::StringRef) [with ValueTy =3D = llvm::StringMap; AllocatorTy =3D = llvm::MallocAllocator]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:120:21: > required from >=20 > here > /usr/include/c++/v1/./type_traits:881:87: error: use of deleted = function 'llvm::StringMap::StringMap(const = llvm::StringMap&)' > = sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T= 1>())) =3D=3D 1 > = ^ and a little more... > In file included from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Supp= ort/SpecialCaseList.h:51:0, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:17: > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:226:7: > note: 'llvm::StringMap::StringMap(const = llvm::StringMap&)' is implicitly declared = as deleted because 'llvm::StringMap' = declares a move constructor or move assignment operator > class StringMap : public StringMapImpl { > ^ where... > namespace __is_convertible_imp > { > template char __test(_Tp); > template __two __test(...); > #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES > template _Tp&& __source(); > #else =20 > template typename remove_reference<_Tp>::type& __source(); > #endif >=20 > ... > } In other words: > __is_convertible_imp::__source&>() is a function returning llvm::StringMap&& = (an r-value reference, not a universal one). (I'm presuming rvalue = references but the overall point is the same even for const = llvm::StringMap& as the return type.) As for __is_convertible_imp::__test: > = __is_convertible_imp::__test= > > (llvm::StringMap) is a function returning a value of type char that is used when the = argument can be passed into a = llvm::StringMap type of parameter. Failure = of this to be possible is not of itself an error ("substitution failure = is not an error" for selecting template functions): it just means that = other example definitions of __is_convertible_imp::__test functions may = be used to match the argument instead. and > = __is_convertible_imp::__test= >(...) is a function returning a value of type __two for all potential, valid = argument lists. (_T2 is actually ignored.) When both = __is_convertible_imp::__test's are non-errors the prior one is picked by = the language rules: a better parameter vs. argument match. Note that the status of deleted copy constructors can contribute to if > = __is_convertible_imp::__test= > > (llvm::StringMap) is a match for the convertibility classifications and it is not an error = for them to do so. The size of the selected = __is_convertible_imp::__test= >'s result type indicates the is-convertible status (sizeof(char) !=3D = sizeof(__two)) and the sizeof use means that overall the expression is a = constexpr (compile time constant) that is based on the type analysis by = the compiler, with no actual constructions happening. But the powerpc64-gcc 4.9.1 compiler is not applying the principle of = "substitution failure is not an error" and is not using the implicitly = deleted-status to cause a mis-match for: > = __is_convertible_imp::__test= > > (llvm::StringMap) So the compiler rejects the code for supposed use of an implicitly = deleted StringMap(const StringMap &RHS) constructor. This is a wrong = classification for the code. It appears that powerpc64-gcc (gcc 4.9.1) is not up to compiling = 11.0-CURRENT -r279514's clang/llvm as-is. Context details, mostly applying to both gcc 4.2.1 based world/kernel = with powperpc-gcc in use for cross compiling and gcc 4.9.1 based = world/kernel: powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. CROSS_TOOLCHAIN=3Dpowerpc64-gcc use does not allow -melf32ppc_fbsd for = WITH_BOOT=3D and WITH_LIB32=3D build activity to use. Even if there was = a powerpc-xtoolchain-gcc (and powerpc-gcc) around then selectively doing = just the WITH_BOOT=3D and WITH_LIB32=3D would still not seem a natural = fit. In my experiments at times for the 4.9.1 based live-world I've placed = the following symbolic links: > # ls -FPal /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Mar 19 03:47 /usr/lib/libstdc++.a@ -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Mar 19 03:47 /usr/lib/libstdc++.so@ -> = libc++.so >=20 > # ls -FPal /usr/bin/gcc /usr/bin/g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc For example csu/powerpc64/... uses "gcc" directly, ignoring XCC and CC. The CC, CXX, and CPP in... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > ... that essentially duplicate the XCC, XCXX, XCPP assignments from = CROSS_TOOLCHAIN=3Dpowerpc64-gcc are there because otherwise various = stages do not use the cross tools (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). Originally I was = investigating how far I could get without involving gcc 4.2.1 and what = would be involved. In the running world built-via-powerpc64-gcc environment /etc/src.conf = having ... > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu+=3D1= 1 -L/usr/obj/usr/srcC/lib/libc++/. is used because otherwise (for example)... > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -fpic -DPIC -O2 = -pipe -DHAVE_CONFIG_H -I/usr/srcC/contrib/atf = -I/usr/srcC/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H = -fstack-protector -Wsyste > m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wpointer-arith -Wno-uninitialized -c = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp -o application.So ends up with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. from lack of -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. in CXXFLAGS = and the like. This is despite the /usr/srcC/Makefile.inc1 logic (that = ends up inactive/ineffective for some reason): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 As for /etc/make.conf it looks like... > # more /etc/make.conf > #CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > #CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > #CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > #CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > #X_COMPILER_TYPE=3Dgcc > # CXFLAGS For normal powerpc64-gcc use... > # AVOID during the buildworld/buildkernel activities: > # _includes _libraries _depend everything build32. > # See /etc/src.conf for example buildworld/buildkernel > # values for that context. > #CXXFLAGS+=3D-I/usr/include/c++/v1 -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++ > # > #CC=3D/usr/local/bin/gcc5 > #CXX=3D/usr/local/bin/g++5 > #CPP=3D/usr/local/bin/cpp5 > #CC=3D/usr/local/bin/clang36 > #CXX=3D/usr/local/bin/clang++36 > #CPP=3D/usr/local/bin/clang-cpp36 > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D (Some of the comments show how gcc5/g++5 use was temporarily forced = while rebuilding powerpc64-gcc from a booted world that had been built = based on powerpc64-gcc in a gcc 4.2.1 world.) > # svnlite info /usr/srcC/ > Path: /usr/srcC > Working Copy Root Path: /usr/srcC > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279514 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 279514 > Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) > # svnlite status /usr/srcC/ --no-ignore > ? /usr/srcC/.snap > M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > ? /usr/srcC/restoresymtable > M /usr/srcC/sys/ddb/db_main.c > M /usr/srcC/sys/ddb/db_script.c > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c > M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h does not matter if clang building is not involved. = It needed a friend declaration to gain access to a private field, = otherwise compilation stopped. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later (-r279760) than the rest of the unmodified source code. This is in = order to remove ambiguous overload issues. > # svnlite info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: dbn > Last Changed Rev: 381120 > Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015) I have gcc5 and clang36 ports installed. I've made no use of clang36. On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete = its installation because powerpc64-gcc fails to complete its = installation. The problems were 4 mismatched file names and one file = also not put into staging. I copied appropriate files to the missing = names and place and from that status the installation was able to = continue and complete via postmaster with -C (as long as powerpc64-gcc = was not in use rebuilding itself: some other compiler was in use for = that activity instead). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 24 05:47:27 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55EB2B64 for ; Tue, 24 Mar 2015 05:47:27 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D061BC6F for ; Tue, 24 Mar 2015 05:47:25 +0000 (UTC) Received: (qmail 1067 invoked from network); 24 Mar 2015 05:47:19 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Mar 2015 05:47:19 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 24 Mar 2015 01:47:19 -0400 (EDT) Received: (qmail 26159 invoked from network); 24 Mar 2015 05:47:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Mar 2015 05:47:18 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 87ED21C43A2; Mon, 23 Mar 2015 22:47:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import [what N2255 suggests] From: Mark Millard In-Reply-To: <96AD8046-52B1-455F-A07B-39FA8CADF80D@dsl-only.net> Date: Mon, 23 Mar 2015 22:47:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96AD8046-52B1-455F-A07B-39FA8CADF80D@dsl-only.net> To: rodrigc@FreeBSD.org, Dimitry Andric X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 05:47:27 -0000 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html has = the following note about std::is_convertible : > Library implementor's note: Except for the protected/private access = checks, and the ambiguity checks, this specification is completely = implementable in C++03 (even without rvalue references). However it is = intended that this be implemented with compiler help to get the access = and ambiguity checks correct. This note would seem to apply to examples like Richard Smith's tiny test = case listed in https://llvm.org/bugs/show_bug.cgi?id=3D22771 : > Here's a testcase that fails with Clang: >=20 > #define __has_feature(x) 0 > #include > class X { X(const X&); }; > bool b =3D std::is_convertible::value; >=20 > (Using a public deleted copy constructor fails similarly.) It sounds like there are going to be limitations to any library-only = solution (i.e., to any fallback implementation of std::is_convertible). So for a failing fallback test example to matter likely requires that = the failure not depend on accessibility checks or ambiguity checks. Might it be that the improvement that was being tested is sufficient = given the general limitations on library-only code solutions? Going the other way: if one wants code (such as llvm/clang source) to = survive environments that need to use a library-only fallback then that = code needs to avoid depending on accessibility or ambiguity properties = for its direct or indirect use of std::is_convertible. I do not know = what criteria llvm/clang uses for such issues. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-22, at 09:56 PM, Mark Millard = wrote: I'd sent out a note Saturday for this for powerpc64-xtoolchain-gcc and = its powerpc64-gcc port: use of CROSS_TOOLCHAIN=3Dpowerpc64-gcc used on a = powerpc64. No solution, just notes about what was going on after looking = at the source code related to the messages. If you care, see: > CROSS_TOOLCHAIN=3Dpowerpc64-gcc mishandles "Substitution Failure Is = Not An Error" when compiling clang and stops the build ( = https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001506.ht= ml ) > = sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T= 1>())) > =3D=3D 1 is the core place involved in your example and mine but the order of = compilation for my context means a different starting place that ended = up using the above. lang/gcc5 did the same when I later tried it. I doubt that host-type or TARGET or TARGET_ARCH matter. I doubt = xtoolchain vs. normal port matters. I expect that the issue spans a = range of g++ versions. Unfortunately that probably also means that the effectively = "Substitution Failure of this kind Is An Error" rule now in use will = probably be around for a while: it is likely not some local accident = that has a quick fix. The best case is if it is simple but each = version/variant needs to release with the change. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 25 03:18:03 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B816D85B; Wed, 25 Mar 2015 03:18:03 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 27C5A85D; Wed, 25 Mar 2015 03:18:03 +0000 (UTC) Received: by labe2 with SMTP id e2so9464197lab.3; Tue, 24 Mar 2015 20:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=E92csWhiKNxWS43fpdGDbKfHFe4cZVaaP63qhQ2BJb8=; b=HKCZoAZZ4AqBBNw4gqOIMdLyB+7O2O0a5Ax9BHwHS7Yuta11scMA25ImlkLQa7N3Vw yF0zsPy2fLHtYHPwxu7lBZiip9988EzgDEXLgkmQGON0QFg4SWsCe2SMGzdAFUhkkTta rvIQOo8NFbrs2Wa5pfTsxoG97U1HQmgNpgPApjbh679sTbXz2hg741Th2yhDZtpNfkd1 d8hwHwLbf+Snx3NA33hwK7zRpCa70qNOF+MHh6OggOL6qRKMU8gULyg3q5KFCGETMNn/ dA0+BDuI6h1ovQLiUIoqjqV6pT+KjX+XQtgcx2S0SQAL/2J3VRBUBl3XF8pDWNNM3Edy bmrQ== MIME-Version: 1.0 X-Received: by 10.112.140.38 with SMTP id rd6mr6399718lbb.116.1427253480841; Tue, 24 Mar 2015 20:18:00 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.108.168 with HTTP; Tue, 24 Mar 2015 20:18:00 -0700 (PDT) In-Reply-To: References: <1857A2A3-0C19-4F52-BCAF-6C72FE7D8DF3@FreeBSD.org> Date: Tue, 24 Mar 2015 20:18:00 -0700 X-Google-Sender-Auth: VwrNYb59ny0Lp_Jp1cXjO4K7JWU Message-ID: Subject: Re: Failed to build with external toolchain From: Craig Rodrigues To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 03:18:03 -0000 On Sat, Mar 7, 2015 at 3:48 PM, Dimitry Andric wrote: > On 07 Mar 2015, at 21:12, Craig Rodrigues wrote: > > I ran the build again and this time I am getting errors about undefined > > symbol utimensat(): > > > > > https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/14/console > > > > Any ideas? > > It's linking against the wrong libc, the one from the FreeBSD-10 host > system, which does not have utimensat(): > > --- cp --- > /usr/local/bin/x86_64-portbld-freebsd10.0-gcc -isystem > /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include > -L/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/lib > -O2 -pipe -DVM_AND_BUFFER_CACHE_SYNCHRONIZED -D_ACL_PRIVATE -std=gnu99 > -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o cp cp.o > utils.o > [...] > utils.o: In function `setfile': > utils.c:(.text+0x83): undefined reference to `utimensat' > utils.c:(.text+0x1ce): undefined reference to `utimensat' > utils.c:(.text+0x38c): undefined reference to `utimensat' > collect2: error: ld returned 1 exit status > > There should probably be a --sysroot flag in there, pointing to the > ${WORLDTMP} built during the earlier stages. > > For some reason, this flag is not added for gcc, in Makefile.inc1. No > idea why that was done. > > -Dimitry > > I eliminated the problem with this patch: Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 280353) +++ Makefile.inc1 (working copy) @@ -381,9 +381,9 @@ TARGET_ABI?= unknown TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0 XCFLAGS+= -target ${TARGET_TRIPLE} +.endif XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} -.endif .else .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX}) BFLAGS+= -B${CROSS_BINUTILS_PREFIX} This sets --sysroot when doing CROSS_TOOLCHAIN for both clang *or* gcc. Right now, --sysroot is only set for clang. I did a "make universe" and "make buildworld CROSS_TOOLCHAIN_PREFIX=/usr/bin/" Is it OK if I commit it? -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 25 03:39:33 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF7D8A81 for ; Wed, 25 Mar 2015 03:39:33 +0000 (UTC) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 753D4A35 for ; Wed, 25 Mar 2015 03:39:33 +0000 (UTC) Received: by pacwe9 with SMTP id we9so14471620pac.1 for ; Tue, 24 Mar 2015 20:39:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=OlQsQ5HeT1DaljqbvmkocyFw4OAXFUUtYiIXLYCOI60=; b=HKM/DD4YzC2+xfFkNc2fjECV4pJRgLyRwAkQEVqAF4cnOMRO8EtZ4h6XfiToCac0ui kDaHgZrcjKSMjHJ9rqScWnn1G2YIHIxbK5+XQys/QBIW5yYYQ2+dp5tjGNclWpxdK+Gy xzMxMxSEaTpEglraSBKxLSwGe/E+rnJ3CGnF1lTgQHznQ28Dbv6AP7obRUtmpcaMgx0o u+YD9l0pmoWj/N0LWrrPFPA19xE9vmxgvIPtBQpAEP947o9bByoBGC3JovA32O5j5TZl 4u7LQTSTTkr3M7ihptgDujZRHZCDdmYPj89UUJuV0tL6P6+vNwxR59fPLr0PFnjEd27v ML9g== X-Gm-Message-State: ALoCoQmQV7ybLbPg8DazavAtiU9rPSgniHsDdxsxwmMk/sKnKOdTJEvgInBlEhoDH5uNBrq6ZJSc X-Received: by 10.66.63.72 with SMTP id e8mr12842657pas.3.1427254767117; Tue, 24 Mar 2015 20:39:27 -0700 (PDT) Received: from lgmc-adee.corp.netflix.com ([69.53.236.236]) by mx.google.com with ESMTPSA id v7sm759745pds.72.2015.03.24.20.39.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 20:39:26 -0700 (PDT) Sender: Warner Losh Subject: Re: Failed to build with external toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_641C2192-3CD7-4E25-B1D7-F00B73C5AFA3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: Date: Tue, 24 Mar 2015 21:39:23 -0600 Message-Id: References: <1857A2A3-0C19-4F52-BCAF-6C72FE7D8DF3@FreeBSD.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-testing@freebsd.org" , freebsd-toolchain@freebsd.org, Dimitry Andric X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 03:39:33 -0000 --Apple-Mail=_641C2192-3CD7-4E25-B1D7-F00B73C5AFA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 24, 2015, at 9:18 PM, Craig Rodrigues = wrote: >=20 > On Sat, Mar 7, 2015 at 3:48 PM, Dimitry Andric = wrote: >=20 >> On 07 Mar 2015, at 21:12, Craig Rodrigues = wrote: >>> I ran the build again and this time I am getting errors about = undefined >>> symbol utimensat(): >>>=20 >>>=20 >> = https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/14/con= sole >>>=20 >>> Any ideas? >>=20 >> It's linking against the wrong libc, the one from the FreeBSD-10 host >> system, which does not have utimensat(): >>=20 >> --- cp --- >> /usr/local/bin/x86_64-portbld-freebsd10.0-gcc -isystem >> = /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_extern= al_toolchain_gcc/tmp/usr/include >> = -L/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_exte= rnal_toolchain_gcc/tmp/usr/lib >> -O2 -pipe -DVM_AND_BUFFER_CACHE_SYNCHRONIZED -D_ACL_PRIVATE = -std=3Dgnu99 >> -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W >> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch = -Wshadow >> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline = -Wnested-externs >> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o cp = cp.o >> utils.o >> [...] >> utils.o: In function `setfile': >> utils.c:(.text+0x83): undefined reference to `utimensat' >> utils.c:(.text+0x1ce): undefined reference to `utimensat' >> utils.c:(.text+0x38c): undefined reference to `utimensat' >> collect2: error: ld returned 1 exit status >>=20 >> There should probably be a --sysroot flag in there, pointing to the >> ${WORLDTMP} built during the earlier stages. >>=20 >> For some reason, this flag is not added for gcc, in Makefile.inc1. = No >> idea why that was done. >>=20 >> -Dimitry >>=20 >> I eliminated the problem with this patch: >=20 > Index: Makefile.inc1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Makefile.inc1 (revision 280353) > +++ Makefile.inc1 (working copy) > @@ -381,9 +381,9 @@ > TARGET_ABI?=3D unknown > TARGET_TRIPLE?=3D > ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0 > XCFLAGS+=3D -target ${TARGET_TRIPLE} > +.endif > XCFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} > XCXXFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} > -.endif > .else > .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX}) > BFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} >=20 >=20 > This sets --sysroot when doing CROSS_TOOLCHAIN for both clang *or* = gcc. > Right now, --sysroot is only set for clang. >=20 > I did a "make universe" and "make buildworld > CROSS_TOOLCHAIN_PREFIX=3D/usr/bin/" >=20 > Is it OK if I commit it? No. The in-tree gcc doesn=E2=80=99t grok =E2=80=94sysroot. We assume that version gcc 4.2.1 is special and our in-tree compiler = elsewhere, so please add a check for that and just go ahead and duplicate those two = lines. Eg +.else if ${COMPILER_VERSION} > 40201 +XCFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} +XCXXFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} .endif Warner --Apple-Mail=_641C2192-3CD7-4E25-B1D7-F00B73C5AFA3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVEi3rAAoJEGwc0Sh9sBEARtkQAJzItEx8Yklzea9yHxdSS2RS 187LYuMKib7kOUHszlU2A6OmksDHAGyVhkQby9DIhozhSGy8ON64Ncmxf9BiudQi WrF7Q5+zW1Pb4FJFnn52E5EuEzyNnoE+f8ryFYNz73RuXgqKm7fVDMeQCQXRDWu9 lVeN479524mJZgkM6kC8tB2UpgHNd42vEpaV02s39qxAUHQrOSW9PE1cmJeufBU9 NjSZmklaHJKckRAYbcX5JKSAcjPPj5nY4zU0VoODMaMbt7h85zNLRjAqSb0MM1KJ OX7ylaqp/Or7JYTI7UliwKSKbw8U0gqiYdCB3Tr458NFc+KHbmKQvBFpb9UAYAtU bQXDBWzfQMzxrHtFgRO5Y6nLEPfZbCcvbQLhoGyhivcnzkB3VCQvbpfnMlBYgwHx 2RhymvBSgNlHglM2FDtWoA2nCl6DYHtKjMNNJOpvLJajUfNvzxVh8YvZJatdsSr9 +HvzNS3YgOznVRHCnMh6FS2g21fJbhD9hzS1Pqa5TgJmEy17MOI6Xw5PIlVtCcAS B0RYLL0CRL20h6ylyEQTwHj0rTd6TF/Y71fG1kmvknHBHKWV75FmBp8sXZVKMrWh 4x5obOd6t8gZx7MMF9Wn2WYtMKDQr8F08g59bQFFm4r7Uho9GSPW+CrepQU2Z1aI FBlqfZj+wVOLitpeNqze =79L+ -----END PGP SIGNATURE----- --Apple-Mail=_641C2192-3CD7-4E25-B1D7-F00B73C5AFA3-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 25 21:27:10 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD1C08B9 for ; Wed, 25 Mar 2015 21:27:10 +0000 (UTC) Received: from asp.reflexion.net (outbound-243.asp.reflexion.net [69.84.129.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 995B0616 for ; Wed, 25 Mar 2015 21:27:09 +0000 (UTC) Received: (qmail 5808 invoked from network); 25 Mar 2015 21:20:29 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Mar 2015 21:20:29 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 25 Mar 2015 17:20:29 -0400 (EDT) Received: (qmail 31358 invoked from network); 25 Mar 2015 21:20:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Mar 2015 21:20:28 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 6F8091C43AE; Wed, 25 Mar 2015 14:20:23 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT -r279514's lib/csu/powerpc64/ vs. cross builds/port builds Date: Wed, 25 Mar 2015 14:20:26 -0700 Message-Id: <52A95085-A438-4503-BCB3-0D07DDE89F9C@dsl-only.net> To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:27:10 -0000 I've been experimenting with buildworld/buildkernel based on = powerpc64-xtoolchain-gcc (and with lang/gcc49) used under powerpc64 and = under powerpc builds. I started from the special case of working under = powerpc64 11.0-CURRENT (a self hosting cross compile for = powerpc64-xtoolchain-gcc use). Then I switched to starting from powerpc = (non-64) 11.0-CURRENT. Overall this results in 3 lib/csu/powerpc64/... subject area for notes = so far... The first one is based on: > # XXX: See the log for r232932 as to why the above -mlongcall is = needed. Since > # clang doesn't support -mlongcall, and testing shows a clang linked = with a > # clang-built csu segfaults, this must currently be compiled with gcc. = Once > # clang supports -mlongcall, or we get a fixed ld, this can be = revisited. > CC:=3D gcc > COMPILER_TYPE:=3D gcc This is forcing of using the path's first-found "gcc" (typically the = system's 4.2.1). This overrides any XCC assignment for a cross tool = chain and also overrides CC assignments for ports based that would pick = out a gcc compiler instead of clang (such as lang/gcc49's 4.9.3). I would expect that this sort of thing should be conditional on clang = being in use --if cross compilers and ports-based builds are to be = supported. (I may well have wondered outside where this tier 2 environment intends = to go.) Note: 10.1-STABLE does not have the forced gcc usage in its = lib/csu/powerpc64/Makefile. Just to continue my experiment I changed the CC assignment to find the = gcc that I was trying to use in order to see what else might show up. A second subject area is: Even when the host/default gcc or other gcc is = to be used it would need to be told of the target environment, both for = C compiles and for assembler use. Currently this does not happen when = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 is used from a powerpc (non-64) = host. If from powerpc (non-64) I try to build for powerpc64 I get complaints = about assembler notation associated with TOC use and notation that has @ = (at sign) in use. =46rom machine/asm.h there is the definition of the = notation: > #ifdef __powerpc64__ > #define TOC_REF(name) __CONCAT(.L,name) > #define TOC_ENTRY(name) \ > .section ".toc","aw"; \ > TOC_REF(name): \ > .tc name[TC],name >=20 > #define _ENTRY(name) \ > .section ".text"; \ > .p2align 2; \ > .globl name; \ > .section ".opd","aw"; \ > .p2align 3; \ > name: \ > .quad DOT_LABEL(name),.TOC.@tocbase,0; \ > .previous; \ > .p2align 4; \ > TYPE_ENTRY(name) \ > DOT_LABEL(name): >=20 > #define _END(name) \ > .long 0; \ > .byte 0,0,0,0,0,0,0,0; \ > END_SIZE(name) > #else /* !__powerpc64__ */ > #define _ENTRY(name) \ > .text; \ > .p2align 4; \ > .globl name; \ > .type name,@function; \ > name: > #define _END(name) > #endif /* __powerpc64__ */ The lack of __powerppc64__ being defined explains the parsing problems = when the host is powerpc (non-64), despite TARGET_ARCH=3Dpowerpc64 use. = (I've not dealt with this issue yet.) I'll note that the TOC related parsing issue exists outside /lib/csu/... = as well, such as assembling lib/libc/powerpc64/sys/brk.S . So this may = not be a local lib/csu/... problem with just a local solution for using = powerpc (non-64) builds to target TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc64. =46rom looking around it seems that this subject area might well also = apply to 10.1-STABLE. A 3rd subject area is picking files from /usr/include/sys/ and = /usr/include/machine/ by default vs. from ${WORLDTMP}/usr/include/sys/ = and ${WORLDTMP}/usr/include/machine/ vs. not finding various files at = all. As stands the CFLAGS are assigned by: > CFLAGS+=3D -I${.CURDIR}/../common \ > -I${.CURDIR}/../../libc/include \ > -mlongcall Looking where that suggests for libc... > # ls lib/libc/include=20 > block_abi.h errlst.h isc namespace.h = nscachedcli.h port_after.h reentrant.h spinlock.h > compat.h fpmath.h libc_private.h nscache.h = nss_tls.h port_before.h resolv_mt.h un-namespace.h >=20 libc_private.h is used and is not in /usr/include/ or in = ${WORLDTMP}/usr/include. So there is a reason to reference this area. But there is use of (via grep): > lib/csu/powerpc64/crt1.c:#include > lib/csu/powerpc64/crti.S:#include > lib/csu/powerpc64/crtn.S:#include which are not covered by the -I's directory trees and were not found for = the cross compiler usage. For the powerpc (non-64) host gcc it implicitly looks in /usr/include = areas but cross compilers and ports compilers are not likely to look = there automatically, more likely looking someplace like = /usr/local/include which has no /usr/local/include/sys/ or = /usr/local/include/machine/ . Grabbing machine/asm.h from the host machine type's = /usr/include/machine/asm.h could be way wrong when the host in not a = powerpc variant. Both sys/cdefs.h and machine/asm.h could have old-vintage issues from = using /usr/include/ instead of ${WORLDTMP}/usr/include/ as the basis for = finding the files. (I'm not claiming likely changes.) I used the following to get rid of those missing-include errors for a = compiler/assembler that does not automatically look in /usr/include/ : > CFLAGS+=3D -I${.CURDIR}/../common \ > -I${WORLDTMP}/usr/include \ > -I${.CURDIR}/../../libc/include \ > -mlongcall That used where libc_private.h is only when a file is not found in the = more normal ${WORLDTMP}/usr/include/... area. Of course when the host = gcc is used /usr/include/... is still potentially referenced. I have not tried any use of --sysroot or other such to control the = behavior. What I did may not have the best of behaviors. Parts of this subject area likely applies to the 10.1-STABLE context as = well form what I see looking its Makefile. I've not dealt with the __powerpc64__-missing issues for TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc64 on powerpc (non-64) yet. That could be masking = more things for me to find. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 26 08:12:48 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14E7B2F4; Thu, 26 Mar 2015 08:12:48 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82AEFF4A; Thu, 26 Mar 2015 08:12:47 +0000 (UTC) Received: by labe2 with SMTP id e2so39198737lab.3; Thu, 26 Mar 2015 01:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gMMvSyGSI7z+Zoabnwo8vrQpsmZxvQDjgP0SGRYGM7Q=; b=bh0fC3q5g2p03B0TmX/KI9L6Ad7AZfawrSxKjOJWzEBzEUygJKtFejIVMoeaZKGzMJ 4T5yIIaYBynTXeNWO9bkijsijsuvATE5n/M9xRm7okkciONmOyP2wDAZmmCl54de8Rog Ao3SRFAyyjJFEXUD1L98rPUwZsRVRU/ppjnwYtKAKs4c/iIfutUEdgNfmrZqn+cSpogN XYzauWBaJP7mCQXERVQICdTi8QytWqR37QxDt+AvoBBZaUR5d1frO1kiz8DhdPXz159m Fa5pdOtp04AvTNDtIIw4P/mj056IQkmcuMUA4HLUSM7cqYpPHHHjE8BugPVLIsMTD3G/ GepQ== MIME-Version: 1.0 X-Received: by 10.152.6.71 with SMTP id y7mr12071184lay.116.1427357565563; Thu, 26 Mar 2015 01:12:45 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.108.168 with HTTP; Thu, 26 Mar 2015 01:12:45 -0700 (PDT) In-Reply-To: References: <1857A2A3-0C19-4F52-BCAF-6C72FE7D8DF3@FreeBSD.org> Date: Thu, 26 Mar 2015 01:12:45 -0700 X-Google-Sender-Auth: 60bBjmpzhI5JM2RKs5w61nHOFNY Message-ID: Subject: Re: Failed to build with external toolchain From: Craig Rodrigues To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 08:12:48 -0000 On Tue, Mar 24, 2015 at 8:39 PM, Warner Losh wrote: > > > No. The in-tree gcc doesn't grok --sysroot. > > We assume that version gcc 4.2.1 is special and our in-tree compiler > elsewhere, > so please add a check for that and just go ahead and duplicate those two > lines. > > Eg > > +.else if ${COMPILER_VERSION} > 40201 > +XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} > +XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} > .endif > > The following worked for me. Is it OK to commit? Index: Makefile.inc1 =================================================================== --- Makefile.inc1 (revision 280353) +++ Makefile.inc1 (working copy) @@ -375,10 +375,14 @@ .endif .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11 -L${WORLDTMP}/../lib/libc++ DEPFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 +.if ${COMPILER_VERSION} > 40201 +XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} +XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} +.endif .else TARGET_ABI?= unknown TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0 XCFLAGS+= -target ${TARGET_TRIPLE} XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 26 18:47:19 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5DD64E3 for ; Thu, 26 Mar 2015 18:47:19 +0000 (UTC) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABB877F9 for ; Thu, 26 Mar 2015 18:47:19 +0000 (UTC) Received: by pacwe9 with SMTP id we9so71004146pac.1 for ; Thu, 26 Mar 2015 11:47:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=0ElUQpL8X92qD8gzZFUaPzJ/155Xxu/s0Dv7DbIVXqI=; b=VjPmeLf9yqVDiFzsDYYq6Rfq7un9jo+Q1Y5PRUZyuQTLSZ9nUx9uBg9a5L9Q5xa6q+ oUthH65ISzl3VUouTgkmRy96p1lodLtPlkXmLw6t8aiE6ERP9L0pXRYfYwDfJgInUY64 TwsUuRF+H7+3zf3H+uN02NUSA+mNPPit01DLvfq+1+fbWSBWKSbKlO0WUEox94JNB+YD odeyqkFptfMBCfqPkAfq0Ct+8qVSdWblRDci87gZNSNXVD3QhxkBdqWIqAu9qtxgHA7O WNHTaYOA9wGRVVDu1eVh2cga92MbqP0ZJp3Oz+T8YQz5CBlYi9gldqUhP7KZlQu4eygJ bKlw== X-Gm-Message-State: ALoCoQlkgTE4DnTMSzLmyxyt68YNFccCgmf9gcBboPyPOSb3u102BtFBPNSTkvEuif2NXkmQDM7N X-Received: by 10.68.113.161 with SMTP id iz1mr28976698pbb.30.1427395633669; Thu, 26 Mar 2015 11:47:13 -0700 (PDT) Received: from [10.64.25.105] ([69.53.236.236]) by mx.google.com with ESMTPSA id pr1sm6290423pbc.66.2015.03.26.11.47.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Mar 2015 11:47:12 -0700 (PDT) Sender: Warner Losh Subject: Re: Failed to build with external toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_53C848BF-B03D-4A9E-BD33-490E9A632FF2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Warner Losh In-Reply-To: Date: Thu, 26 Mar 2015 12:47:26 -0600 Message-Id: <1A90C16A-1A23-4EFD-BB61-0E956C8CB49D@bsdimp.com> References: <1857A2A3-0C19-4F52-BCAF-6C72FE7D8DF3@FreeBSD.org> To: Craig Rodrigues X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-testing@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:47:20 -0000 --Apple-Mail=_53C848BF-B03D-4A9E-BD33-490E9A632FF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Mar 26, 2015, at 2:12 AM, Craig Rodrigues = wrote: >=20 >=20 >=20 > On Tue, Mar 24, 2015 at 8:39 PM, Warner Losh wrote: >=20 >=20 > No. The in-tree gcc doesn=92t grok =97sysroot. >=20 > We assume that version gcc 4.2.1 is special and our in-tree compiler = elsewhere, > so please add a check for that and just go ahead and duplicate those = two lines. >=20 > Eg >=20 > +.else if ${COMPILER_VERSION} > 40201 > +XCFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} > +XCXXFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} > .endif >=20 >=20 > The following worked for me. Is it OK to commit? >=20 > Index: Makefile.inc1 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- Makefile.inc1 (revision 280353) > +++ Makefile.inc1 (working copy) > @@ -375,10 +375,14 @@ > .endif > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 > +.if ${COMPILER_VERSION} > 40201 > +XCFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} > +XCXXFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} > +.endif > .else > TARGET_ABI?=3D unknown > TARGET_TRIPLE?=3D = ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0 > XCFLAGS+=3D -target ${TARGET_TRIPLE} > XCFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} OK. I have a bit of egg on my face=85 The test is for X_COMPILER_TYPE, so COMPILER_VERSION isn=92t relevant. = It=92s always outside the tree. So your original patch is correct. Please go ahead and commit that and = accept my apologies for the wild goose chase. Warner --Apple-Mail=_53C848BF-B03D-4A9E-BD33-490E9A632FF2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVFFQ+AAoJEGwc0Sh9sBEAyi0QAKD7MsHe58oHThFw0Du2jmRi 9Y2qpVuaWa3RmHVRb1cZewowtxWOIGnaFE8MWWSd8S0PE3gaO8nOzzUQV9FndMHp FETLvRX7bL0I+sJ/nZwQt4Sb4oOH4hv5KgoeXz/aShO5MKdAFOp7CjG6iLlkpGwg qts/d313jeeqkPBiwtAMhtXzVIW8LALHF0YyEE6bGlyO9k9f9ZLCVgZmFF+sNN1x S+I9qGNI3Oum3eTJ36uHMQmteJbKjIf1HgqMlhlms0UAJRUcKBlKQuqMExRGCtu/ 1AWL66smfYe2ofFutsFlmTVSXs/yNdDz0dwpbcYx2OgUMEH2h6ngNtRIgXyRj6fK eIouQp5/WKrMg6dgVibkPX923MOfG2xAJ3YmhlM13kq+s6ilocJ4GrZ75zDitdAg bDabyuMMRU2CF2qWQgDKPo69ICEcORrnG6rC5gjJNjR+c0F6LUejfYnxYs8Sui81 AMhGRBWv8I6V6vPC0jX1BamsM7dtTD+u0OKVFlc8GaiZJteRrk+U/WhFD7rHNxcC +L4t6zjh/2q/fXkxTfIPXWqzsAAPBa2KI/EOPvwxebIy/bjbz3g08fzZzAB/sDdy Olty3pnjETZbnsKxI9VVgJzc+DIumRjlnJyIgVWUhIEaFfEabQRmKobIdAzdp/ON /9rdAMWvh8v/9Qz92EIX =t/wk -----END PGP SIGNATURE----- --Apple-Mail=_53C848BF-B03D-4A9E-BD33-490E9A632FF2-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 27 00:39:55 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0E64A1A; Fri, 27 Mar 2015 00:39:54 +0000 (UTC) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58690388; Fri, 27 Mar 2015 00:39:54 +0000 (UTC) Received: by labto5 with SMTP id to5so59090870lab.0; Thu, 26 Mar 2015 17:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=+zVipZEMxyzje19wJgm8QnlC9QlpwCB2DR7uG828yz0=; b=TgA2Yz2y07cc6qOQJ8wKlPGQ8cDZ9ymomWaMjUxKVpbkgVTmyv5Yh+EMZZ41HzkiYF XEuuzZA01skWhZbb+xx+QA6DCm7uEdVn/UzE+niubd0WQd0vws8s3y33UHEtMp0xv7E5 9ATUN/3Fkjno9i3+ev0OqUa23Zz4wsEVqI8FwiX75UaiBuEe+bCXrJpoXOGg78t8KCTU rpuennbaEno62CXYhlOF+LsnD/v0o8Dnr7ztVTOZ5RUb9joNTAbY9QqFpn76BAjjhYWj lkYNW/rFbl7dzdt0bp1SfG+H+XN2JmYD1dsReYqVFMJEeODTjCqKwzkN4hZlxzGSjFHG rsRQ== MIME-Version: 1.0 X-Received: by 10.112.146.70 with SMTP id ta6mr15875326lbb.59.1427416790989; Thu, 26 Mar 2015 17:39:50 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.108.168 with HTTP; Thu, 26 Mar 2015 17:39:50 -0700 (PDT) In-Reply-To: <1A90C16A-1A23-4EFD-BB61-0E956C8CB49D@bsdimp.com> References: <1857A2A3-0C19-4F52-BCAF-6C72FE7D8DF3@FreeBSD.org> <1A90C16A-1A23-4EFD-BB61-0E956C8CB49D@bsdimp.com> Date: Thu, 26 Mar 2015 17:39:50 -0700 X-Google-Sender-Auth: gMJikbBQ6KlcTCkMQfJyA7WT6N4 Message-ID: Subject: Re: Failed to build with external toolchain From: Craig Rodrigues To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 00:39:55 -0000 On Thu, Mar 26, 2015 at 11:47 AM, Warner Losh wrote: > > > On Mar 26, 2015, at 2:12 AM, Craig Rodrigues > wrote: > > OK. I have a bit of egg on my face... > > The test is for X_COMPILER_TYPE, so COMPILER_VERSION isn't relevant. It's > always outside the tree. > So your original patch is correct. Please go ahead and commit that and > accept my apologies for the wild goose chase. > Okee dokee, I committed my original patch: http://lists.freebsd.org/pipermail/svn-src-all/2015-March/101492.html No worries about geese. External toolchain support is important to the future of FreeBSD, and I appreciate your work. I'm just trying to help as best I can by testing things, reporting problems, and fixing things where I can. -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 27 15:26:10 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40249B74 for ; Fri, 27 Mar 2015 15:26:10 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21E21372 for ; Fri, 27 Mar 2015 15:26:10 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2RFQ9Ll004814 for ; Fri, 27 Mar 2015 15:26:09 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2RFQ9jB004813; Fri, 27 Mar 2015 15:26:09 GMT (envelope-from root) Date: Fri, 27 Mar 2015 15:26:09 +0000 To: freebsd-toolchain@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Request, 5 lines] D2156: Switch to ELF toolchain readelf Message-ID: X-Priority: 3 Thread-Topic: D2156: Switch to ELF toolchain readelf X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Thread-Index: ZWFkMTA4MTdiZGZmMTA5ZWZhZDAyYzE2ZjY0 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 15:26:10 -0000 emaste created this revision. emaste added a reviewer: imp. emaste added a subscriber: freebsd-toolchain. REVISION SUMMARY ELF toolchain readelf lacked some functionality at the time other tools (like size, strip, nm, etc.) were switched over to the ELF toolchain versions. This has been addressed as of the latest update, so we should be able to use it as well. TEST PLAN - Ports exp-run - ad-hoc comparison of output against in-tree binutils readelf REVISION DETAIL https://reviews.freebsd.org/D2156 AFFECTED FILES gnu/usr.bin/binutils/Makefile usr.bin/Makefile To: emaste, imp Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 27 16:07:51 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2610EF72 for ; Fri, 27 Mar 2015 16:07:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 071C2AD0 for ; Fri, 27 Mar 2015 16:07:51 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2RG7oUI050118 for ; Fri, 27 Mar 2015 16:07:50 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2RG7oj1050117; Fri, 27 Mar 2015 16:07:50 GMT (envelope-from root) Date: Fri, 27 Mar 2015 16:07:50 +0000 To: freebsd-toolchain@freebsd.org From: "imp (Warner Losh)" Subject: [Differential] [Accepted] D2156: Switch to ELF toolchain readelf Message-ID: <3c7e4049cb0fdfff928690dae9f42913@localhost.localdomain> X-Priority: 3 Thread-Topic: D2156: Switch to ELF toolchain readelf X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZWFkMTA4MTdiZGZmMTA5ZWZhZDAyYzE2ZjY0IFUVgFY= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 16:07:51 -0000 imp accepted this revision. imp added a comment. This revision is now accepted and ready to land. Looks good REVISION DETAIL https://reviews.freebsd.org/D2156 To: emaste, imp Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 27 16:28:33 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BF556E0 for ; Fri, 27 Mar 2015 16:28:33 +0000 (UTC) Received: from asp.reflexion.net (outbound-243.asp.reflexion.net [69.84.129.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7705DCF for ; Fri, 27 Mar 2015 16:28:31 +0000 (UTC) Received: (qmail 31656 invoked from network); 27 Mar 2015 16:28:30 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Mar 2015 16:28:30 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 27 Mar 2015 12:28:30 -0400 (EDT) Received: (qmail 22363 invoked from network); 27 Mar 2015 16:28:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Mar 2015 16:28:30 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 794111C43A6; Fri, 27 Mar 2015 09:28:26 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859 vs. updating to head snaphot -r280598 Date: Fri, 27 Mar 2015 09:28:28 -0700 References: <24B7C687-9147-42F1-AE49-92F93DC85AA8@dsl-only.net> To: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org Message-Id: <2114397E-B46A-4DF3-BAE4-59DA4D548C1B@dsl-only.net> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 16:28:33 -0000 About the below Miacheal Tuexen wrote back: > I guess there is something wrong with the build system / Makefiles = such that the entries in the search path for include files are in the = wrong order. I don't think this is related to the concrete patch you are = referring to. It only exposes the problem. As I see, you experience = similar problems in other situations to. >=20 > Maybe someone knowing the build system has to look into it. And it = seems to be somewhat platform specific, since I have not observed this = problem when testing the build on amd64 and arm. >=20 > Best regards > Michael =3D=3D=3D Mark Millard markmi at dsl-only.net Begin forwarded message: From: Mark Millard Subject: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c = -r279859 vs. updating to head snaphot -r280598 Date: 2015-March-26 at 07:36:01 PM PDT Cc: FreeBSD PowerPC ML To: freebsd-current@freebsd.org, tuexen@freebsd.org Basic context: # freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar = 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 The problem: Summary of the details that are listed later. Both of the following = exist: /usr/src/sys/netinet/sctp.h /usr/include/netinet/sctp.h The first can be newer than the 2nd during buildworld. The buildworld compile of /head/lib/libc/net/sctp_sys_calls.c from an = updated /usr/src can/does end up using the second instead of the first, = at least for the powerpc64-xtoolchain-gcc style of buildworld activity = that I am trying. The recent addition of SCTP_MAX_CWND ends up with its definition missing = because of this: during the build /usr/include/netinet/sctp.h ends up = being the file included and the compile fails from the missing = additional definition. Either the #include paths in /head/lib/libc/net/sctp_sys_calls.c or the = command line arguments should force the /usr/src/sys/netinet/sctp.h = vintage file to be found. The 3 netinet/ relevant includes are shown = below... > ... > #include > #include > #include > #include More than sctp.h might have such issues since there are 3 netinet/ = include paths in /head/lib/libc/net/sctp_sys_calls.c . I have not checked for other .c files with similar issues for = usage during buildworld. The problem details: /head/lib/libc/net/sctp_sys_calls.c -r279859 added: > case SCTP_MAX_CWND: > ((struct sctp_assoc_value *)arg)->assoc_id =3D id; > break; and head (20150325 r280598) contains it. But the SCTP_MAX_CWND reference blocks buildworld (for at least = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = (powerpc64-xtoolchain=3Dgcc) use): > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 = -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include = -I/usr/src/lib/libc/powerpc64 -DNLS -D__DBINTERFACE_PRIVATE = -I/usr/src/lib/libc/../../contrib/gdtoa = -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 = -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE = -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd = -I/usr/src/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION = -I/usr/src/lib/libc/../../contrib/tzcode/stdtime = -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES = -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING = -DSYMBOL_VERSIONING -DSYSCALL_COMPAT -std=3Dgnu99 -fstack-protector = -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized = -Wno-pointer-sign -c /usr/src/lib/libc/net/sctp_sys_calls.c -o = sctp_sys_calls.So >=20 > /usr/src/lib/libc/net/sctp_sys_calls.c: In function 'sctp_opt_info': > /usr/src/lib/libc/net/sctp_sys_calls.c:386:7: error: 'SCTP_MAX_CWND' = undeclared (first use in this function) > case SCTP_MAX_CWND: ^ Looking to see where usage and definitions might be in /usr/src for = -r280598 ... > # pwd > /usr/src > $ find . \( -type d -name .svn -prune \) -or \( -type f -exec grep = SCTP_MAX_CWND {} \; -print \) | more > case SCTP_MAX_CWND: > ./lib/libc/net/sctp_sys_calls.c > case SCTP_MAX_CWND: > case SCTP_MAX_CWND: > ./sys/netinet/sctp_usrreq.c > #define SCTP_MAX_CWND 0x00000032 > ./sys/netinet/sctp.h And looking at the list of includes in = /head/lib/libc/net/sctp_sys_calls.c for -r279859 shows: > #include > __FBSDID("$FreeBSD$"); >=20 > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include That there was no complaint about sctp.h being missing suggests that a = was found but did not contain a SCTP_MAX_CWND = definition: so a different one than the above find/grep reported. Using a find to report other sctp.h files shows: > # find / \( -type d -name .svn -prune \) -or \( -type f -name sctp.h = -print \) | more > /usr/src/sys/netinet/sctp.h > /usr/include/netinet/sctp.h The diff of those shows the problem if the wrong file is found and used: > # diff /usr/include/netinet/sctp.h /usr/src/sys/netinet/sctp.h > 34c34 > < __FBSDID("$FreeBSD: head/sys/netinet/sctp.h 269945 2014-08-13 = 15:50:16Z tuexen $"); > --- >> __FBSDID("$FreeBSD: head/sys/netinet/sctp.h 279859 2015-03-10 = 19:49:25Z tuexen $"); > 130a131 >> #define SCTP_MAX_CWND 0x00000032 Context details: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc=20 > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # svnlite info /usr/src > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 280615 > Node Kind: directory > Schedule: normal > Last Changed Author: hselasky > Last Changed Rev: 280598 > Last Changed Date: 2015-03-25 06:32:27 -0700 (Wed, 25 Mar 2015) signals.h and pthread.h have been updated to more recent than -r280598 = in order to avoid the __nonnull issues that exist as of -r280598. > # svnlite st /usr/src --no-ignore > ? /usr/src/.snap > ? /usr/src/restoresymtable > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/ofw/ofwcall64.S (The .c/.S changes are tied to a PowerMac-G5-specific boot-problem fix = and getting information from early boot failures if I get any more. The = GENERIC's remove ps3 in order to have both vt and sc at the same = time.) > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. (The above and just below experiments with mostly(?) avoiding use of gcc = 4.2.1, even for CC/CXX/CPP contexts.) > # ls -FPal /usr/bin/g[+c]* > lrwxr-xr-x 1 root wheel 48 Mar 20 02:03 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > # more /etc/make.conf > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 27 16:32:46 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6FF5AA4 for ; Fri, 27 Mar 2015 16:32:46 +0000 (UTC) Received: from asp.reflexion.net (outbound-243.asp.reflexion.net [69.84.129.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8089EEC4 for ; Fri, 27 Mar 2015 16:32:46 +0000 (UTC) Received: (qmail 11916 invoked from network); 27 Mar 2015 16:32:45 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Mar 2015 16:32:45 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 27 Mar 2015 12:32:45 -0400 (EDT) Received: (qmail 24925 invoked from network); 27 Mar 2015 16:32:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Mar 2015 16:32:45 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 5DE841C439E; Fri, 27 Mar 2015 09:32:41 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: 11.0-CURRENT: SBUF_INCLUDENUL, /head/sys/kern/subr_sbuf.c -r280193 vs. updating to head snaphot -r280598 Date: Fri, 27 Mar 2015 09:32:43 -0700 References: To: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org Message-Id: <7E2A4AC1-9C67-4029-A59F-E6902AE35380@dsl-only.net> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 16:32:46 -0000 About the below Ian Lepore wrote: > This and the other similar reports on current@ appear to be problems > with the xtoolchain ports, not the base build system, and probably > should have been reported to the port's maintainer, or on ports@. Or > perhaps it's some sort of usage error, I don't know anything about the > xtoolchain stuff. In any case, there doesn't seem to be anything = wrong > with the base build using the supported build mechanisms. =3D=3D=3D Mark Millard markmi at dsl-only.net Begin forwarded message: Subject: 11.0-CURRENT: SBUF_INCLUDENUL, /head/sys/kern/subr_sbuf.c = -r280193 vs. updating to head snaphot -r280598 From: Mark Millard Date: 2015-March-26 at 09:15:46 PM PDT Cc: FreeBSD PowerPC ML To: freebsd-current@freebsd.org, Ian Lepore Basic context: # freebsd-version -ku; uname -apKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r279514M: Sat Mar = 21 05:15:23 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 The problem: Summary of the details that are listed later. Both of the following = exist: /usr/src/sys/sys/sbuf.h /usr/include/sys/sbuf.h The first can be newer than the 2nd during buildworld. The buildworld compile of /head/sys/kern/subr_sbuf.c from an updated = /usr/src can/does end up using the second instead of the first, at least = for the powerpc64-xtoolchain-gcc style of buildworld activity that I am = trying. The recent addition of SBUF_INCLUDENUL use ends up with its definition = missing because of this: during the build /usr/include/sys/sbuf.h ends = up being the file included and the compile fails from the missing = additional definition. Either the #include paths in /head/sys/kern/subr_sbuf.c or the command = line arguments should force the /usr/src/sys/sys/sbuf.h vintage file to = be found. The /head/sys/kern/subr_sbuf.c relevant includes are shown = below... > #include > __FBSDID("$FreeBSD: head/sys/kern/subr_sbuf.c 280193 2015-03-17 = 21:00:31Z ian $"); >=20 > #include >=20 > #ifdef _KERNEL > #include > #include > #include > #include > #include > #include > #include > #else /* _KERNEL */ > #include > #include > #include > #include > #include > #include > #endif /* _KERNEL */ >=20 > #include I have not checked for other .c files with similar issues for = usage during buildworld. The problem details: /head/sys/kern/subr_sbuf.c -r280193 added: > #define SBUF_NULINCLUDED(s) ((s)->s_flags & SBUF_INCLUDENUL) and head (20150325 r280598) contains it. But the SBUF_INCLUDENUL reference blocks buildworld (for at least = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = (powerpc64-xtoolchain=3Dgcc) use): > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -fpic -DPIC -O2 = -pipe -std=3Dgnu99 -fstack-protector -Wsystem-headers -Wall = -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes = -Wmissing-pro > totypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings = -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts = -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition > -Wno-pointer-sign -c /usr/src/lib/libsbuf/../../sys/kern/subr_sbuf.c = -o subr_sbuf.So > ... > /usr/src/lib/libsbuf/../../sys/kern/subr_sbuf.c:73:45: error: = 'SBUF_INCLUDENUL' undeclared (first use in this function) > #define SBUF_NULINCLUDED(s) ((s)->s_flags & SBUF_INCLUDENUL) > ^ Looking to see where SBUF_INCLUDENUL usage and definitions might be in = /usr/src for -r280598 ... > # pwd > /usr/src > # find . \( -type d -name .svn -prune \) -or \( -type f -exec grep = SBUF_INCLUDENUL {} \; -print \) | more > .It Dv SBUF_INCLUDENUL > ./share/man/man9/sbuf.9 > #define SBUF_INCLUDENUL 0x00000002 /* nulterm byte is counted in = len */ > ./sys/sys/sbuf.h > sbuf_clear_flags(&sbuf, SBUF_INCLUDENUL); > ./sys/vm/uma_core.c > SBUF_INCLUDENUL); > ./sys/netinet/tcp_hostcache.c > sbuf_clear_flags(&sbuf, SBUF_INCLUDENUL); > ./sys/kern/kern_malloc.c > SBUF_INCLUDENUL); > ./sys/kern/kern_cons.c > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > ./sys/kern/kern_descrip.c > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > sbuf_clear_flags(&sb, SBUF_INCLUDENUL); > ./sys/kern/kern_proc.c > sbuf_new(&sb, NULL, 256, SBUF_AUTOEXTEND | SBUF_INCLUDENUL); > ./sys/kern/kern_et.c > sbuf_new(&sb, NULL, 128, SBUF_AUTOEXTEND | SBUF_INCLUDENUL); > ./sys/kern/kern_fail.c > s =3D sbuf_new(s, buf, length, SBUF_FIXEDLEN | = SBUF_INCLUDENUL); > ./sys/kern/kern_sysctl.c > #define SBUF_NULINCLUDED(s) ((s)->s_flags & SBUF_INCLUDENUL) > ./sys/kern/subr_sbuf.c Looking at the list of includes in /head/lib/libc/net/sctp_sys_calls.c = for -r280193 shows: > #include > __FBSDID("$FreeBSD: head/sys/kern/subr_sbuf.c 280193 2015-03-17 = 21:00:31Z ian $"); >=20 > #include >=20 > #ifdef _KERNEL > #include > #include > #include > #include > #include > #include > #include > #else /* _KERNEL */ > #include > #include > #include > #include > #include > #include > #endif /* _KERNEL */ >=20 > #include That there was no complaint about sbuf.h being missing suggests that a = was found but did not contain a SBUF_INCLUDENUL definition: = so a different one than the above find/grep reported. Using a find to report other sctp.h files shows: > # find /usr/include \( -type d -name .svn -prune \) -or \( -type f = -name sbuf.h -print \) | more > /usr/include/sys/sbuf.h The diff of the two variants shows the problem if the wrong file is = found and used: > # diff /usr/include/sys/sbuf.h /usr/src/sys/sys/sbuf.h > 28c28 > < * $FreeBSD: head/sys/sys/sbuf.h 269179 2014-07-28 07:20:22Z = gahr $ > --- >> * $FreeBSD: head/sys/sys/sbuf.h 279992 2015-03-14 16:02:11Z ian = $ > 50a51 >> #define SBUF_INCLUDENUL 0x00000002 /* nulterm byte is = counted in len */ > 66a68,70 >> int sbuf_get_flags(struct sbuf *); >> void sbuf_clear_flags(struct sbuf *, int); >> void sbuf_set_flags(struct sbuf *, int); Context details: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc=20 > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # svnlite info /usr/src > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 280615 > Node Kind: directory > Schedule: normal > Last Changed Author: hselasky > Last Changed Rev: 280598 > Last Changed Date: 2015-03-25 06:32:27 -0700 (Wed, 25 Mar 2015) signals.h and pthread.h have been updated to more recent than -r280598 = in order to avoid the __nonnull issues that exist as of -r280598. > # svnlite st /usr/src --no-ignore > ? /usr/src/.snap > ? /usr/src/restoresymtable > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/src/sys/powerpc/conf/GENERICvtsc > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/ofw/ofwcall64.S (The .c/.S changes are tied to a PowerMac-G5-specific boot-problem fix = and getting information from early boot failures if I get any more. The = GENERIC's remove ps3 in order to have both vt and sc at the same = time.) > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. (The above and just below experiments with mostly(?) avoiding use of gcc = 4.2.1, even for CC/CXX/CPP contexts.) > # ls -FPal /usr/bin/g[+c]* > lrwxr-xr-x 1 root wheel 48 Mar 20 02:03 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > # more /etc/make.conf > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 27 18:33:31 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03546181 for ; Fri, 27 Mar 2015 18:33:31 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D7AF6FF for ; Fri, 27 Mar 2015 18:33:30 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2RIXUeT007802 for ; Fri, 27 Mar 2015 18:33:30 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2RIXUGp007799; Fri, 27 Mar 2015 18:33:30 GMT (envelope-from root) Date: Fri, 27 Mar 2015 18:33:30 +0000 To: freebsd-toolchain@freebsd.org From: "bapt (Baptiste Daroussin)" Subject: [Differential] [Accepted] D2156: Switch to ELF toolchain readelf Message-ID: X-Priority: 3 Thread-Topic: D2156: Switch to ELF toolchain readelf X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZWFkMTA4MTdiZGZmMTA5ZWZhZDAyYzE2ZjY0IFUVono= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 18:33:31 -0000 bapt accepted this revision. bapt added a reviewer: bapt. REVISION DETAIL https://reviews.freebsd.org/D2156 To: emaste, imp, bapt Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 27 18:39:34 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E01C2313 for ; Fri, 27 Mar 2015 18:39:34 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8BF114B for ; Fri, 27 Mar 2015 18:39:34 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2RIdYDn012598 for ; Fri, 27 Mar 2015 18:39:34 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2RIdY1Q012597; Fri, 27 Mar 2015 18:39:34 GMT (envelope-from root) Date: Fri, 27 Mar 2015 18:39:34 +0000 To: freebsd-toolchain@freebsd.org From: "emaste (Ed Maste)" Subject: [Differential] [Commented On] D2156: Switch to ELF toolchain readelf Message-ID: <89a51dcb2b32c0d23cf8ea9e368ecc44@localhost.localdomain> X-Priority: 3 Thread-Topic: D2156: Switch to ELF toolchain readelf X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZWFkMTA4MTdiZGZmMTA5ZWZhZDAyYzE2ZjY0IFUVo+Y= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 18:39:35 -0000 emaste added a comment. exp-run is here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198950 REVISION DETAIL https://reviews.freebsd.org/D2156 To: emaste, imp, bapt Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 27 20:56:01 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DDA9A18 for ; Fri, 27 Mar 2015 20:56:01 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1DE5162C for ; Fri, 27 Mar 2015 20:56:01 +0000 (UTC) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t2RKu0Hl058868 for ; Fri, 27 Mar 2015 20:56:00 GMT (envelope-from root@phabric-backend.isc.freebsd.org) Received: (from root@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t2RKu0QU058867; Fri, 27 Mar 2015 20:56:00 GMT (envelope-from root) Date: Fri, 27 Mar 2015 20:56:00 +0000 To: freebsd-toolchain@freebsd.org From: "rpaulo (Rui Paulo)" Subject: [Differential] [Accepted] D2156: Switch to ELF toolchain readelf Message-ID: <6ddd036e77430189391ada78437baad1@localhost.localdomain> X-Priority: 3 Thread-Topic: D2156: Switch to ELF toolchain readelf X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: ZWFkMTA4MTdiZGZmMTA5ZWZhZDAyYzE2ZjY0IFUVw+A= X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 20:56:01 -0000 rpaulo accepted this revision. rpaulo added a reviewer: rpaulo. REVISION DETAIL https://reviews.freebsd.org/D2156 To: emaste, imp, bapt, rpaulo Cc: freebsd-toolchain From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 28 04:26:17 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05AE7E27; Sat, 28 Mar 2015 04:26:17 +0000 (UTC) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78514A42; Sat, 28 Mar 2015 04:26:16 +0000 (UTC) Received: by lbbug6 with SMTP id ug6so76259007lbb.3; Fri, 27 Mar 2015 21:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4b6gUUQjtzA0ePVC8D8lFrIXvvNnGc9Dnkk9KQDfG0A=; b=I0/vz5LQ97LoE6thFDkGZgQLUNoE9ukh3Ab8/B5uBvmSW0EC4uazW3hWLZFJbR9O1E TT+RvQf8ZrL35JPfT3PFLqs0V3TM+qt9ikNy7tweD9vPRwx4Gn1U4UIFXorr9lOM8Fr4 ashyuTvGjInInJmmYZFUDCRHZYn0cNVHLhRBV8oa/JI7WSB4xfGPqGX3mF4Irp57T1wF +N1tJ5nlzBKbhPFPqc0NrUPs6FFTMQgsRZOQ3aYqxiqWQn1tb/udj0juXZa9mM2Tt93C di8ZwZeaEw27pX+AIjgIgRdGYUUiHUMfr5JMrD/A+c7c1Iix2lDia+GE0OPa0Bwy8pjY +3bQ== MIME-Version: 1.0 X-Received: by 10.112.170.132 with SMTP id am4mr20044985lbc.89.1427516774253; Fri, 27 Mar 2015 21:26:14 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.108.168 with HTTP; Fri, 27 Mar 2015 21:26:14 -0700 (PDT) In-Reply-To: <5F90BE99-E82C-4444-9E4C-5963B40AA3B0@FreeBSD.org> References: <5F90BE99-E82C-4444-9E4C-5963B40AA3B0@FreeBSD.org> Date: Fri, 27 Mar 2015 21:26:14 -0700 X-Google-Sender-Auth: 1xzIwwiPc1pnDYDnuJXFlBnYn6E Message-ID: Subject: Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import From: Craig Rodrigues To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 04:26:17 -0000 On Mon, Mar 23, 2015 at 12:12 AM, Dimitry Andric wrote: > On 23 Mar 2015, at 01:49, Craig Rodrigues wrote: > > > > Hi, > > > > I tried to build HEAD with gcc 4.9.1 after the latest clang 3.6.0 import, > > and am getting > > new build failures related to C++ such as: > > > > > /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:881:87: > > error: use of deleted function > > 'clang::Sema::TypoExprState::TypoExprState(const > > clang::Sema::TypoExprState&)' > > > > > sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T1>())) > > == 1 > > > > See full build logs here: > > > https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/21/console > > > > Any ideas what the problem might be? > > Yes, this is a bug in libc++, when compiling it with newer versions of > gcc. I reported this upstream some time ago: https://llvm.org/PR22771 > > Still haven't had enough time to test Eric Fiselier's patch for it. I > hope I see the bottom of my TODO list anytime soon... > > -Dimitry > > Eric Fiselier's patch in http://reviews.llvm.org/D8461 works for me. I could compile libc++ with gcc 4.9 with this patch. There are other gcc 4.9 compilation problems, but I will report those separately. -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 28 05:03:13 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97A24240 for ; Sat, 28 Mar 2015 05:03:13 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E3A1D9A for ; Sat, 28 Mar 2015 05:03:13 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so95490560ied.1 for ; Fri, 27 Mar 2015 22:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=8FqUt/Z+tTiFtJHFaSsBnY5x8g227mxjah3DJJPgpTc=; b=lgBp8zaruRkvaZp5nxaRgL6YaNEkvRMpYSkZp5Oa0CW6LOXWcDfUvsbYUr9HFFbXwE dRoEr9PgWFK+Jp66UEU1hdc5eNnQZLivcDfHSXTP5i0265dUdzNIMNNlFvNmBRaPHcKU Ik89psK3zqRsamrnqSOrgL+ovZaa+tcWf8uRwrxAqSsTS5wSxTeh+YA2KpqI3dLg1Ijf z+gmSAB3RbvwgDWtpGrYLx4Y2zfnL7myjoY6ijNxSVALnG91M8koO5KiamLPn6aVRoip rcoJojty2+aBqOALWUkgOgipPDk1g28Eat1+EzeqohJV5HXKLGSTG2X0RJR37ODkPSlb RAiA== MIME-Version: 1.0 X-Received: by 10.50.109.228 with SMTP id hv4mr3133115igb.45.1427518992609; Fri, 27 Mar 2015 22:03:12 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.36.71.203 with HTTP; Fri, 27 Mar 2015 22:03:12 -0700 (PDT) Date: Fri, 27 Mar 2015 22:03:12 -0700 X-Google-Sender-Auth: k6a0L05Fdrfj0yRnx8n-j09D68o Message-ID: Subject: lldb compilation problem with gcc 4.9 From: Craig Rodrigues To: freebsd-toolchain@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 05:03:13 -0000 Hi, I had problems compiling lldb with gcc 4.9. See problem description plus patch which I submitted upstream: https://llvm.org/bugs/show_bug.cgi?id=23051 -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 28 17:06:13 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4690218C for ; Sat, 28 Mar 2015 17:06:13 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA4EAB7E for ; Sat, 28 Mar 2015 17:06:12 +0000 (UTC) Received: by lbbug6 with SMTP id ug6so82627809lbb.3 for ; Sat, 28 Mar 2015 10:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=833YlgU14H3f7dRtMtBKoaYXbOUmE95UvGsZXE5leXc=; b=VdZdlaI5xVdFmCQd3oCA+x7NR+mDU0vaq0kQpR8VWjml3/xOpRLgOhQRlavUTlMj+d Bxm5VHyUfgA2PGIcpPv+VPyHvvFQ4ktsUnXMqZAnzur4/1rZnpXckn+RtWLO6kkEuOnD Uv8X5IMqpPz975S9RRk9zFyglyfrRCEIUmZzYtpjxyG4VQuxN0oCJro13aI2Xn0/myH2 ZxHgy1VI/M3NLMbkLnIuadW4Z0IwOcygwm4X/3jDheO0uAAZXt2lzizRU+5HuZqPKk1N 69Sj4P7JMXKJ03XIuxwmnwP3+CtVCXmQuf9lTL91UFhjmXe2RPwxxFG0RDsb67Hf3Zr6 26VA== MIME-Version: 1.0 X-Received: by 10.112.223.7 with SMTP id qq7mr22146582lbc.81.1427562370922; Sat, 28 Mar 2015 10:06:10 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.108.168 with HTTP; Sat, 28 Mar 2015 10:06:10 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 Mar 2015 10:06:10 -0700 X-Google-Sender-Auth: h3ninDSUJXQxHPvjGL628_9lmN4 Message-ID: Subject: Re: lldb compilation problem with gcc 4.9 From: Craig Rodrigues To: freebsd-toolchain@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 17:06:13 -0000 On Fri, Mar 27, 2015 at 10:03 PM, Craig Rodrigues wrote: > Hi, > > I had problems compiling lldb with gcc 4.9. > > See problem description plus patch which I submitted upstream: > > https://llvm.org/bugs/show_bug.cgi?id=23051 > > My patch was accepted upstream: http://llvm.org/viewvc/llvm-project?view=revision&revision=233478 -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 28 21:34:12 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBB49B80; Sat, 28 Mar 2015 21:34:12 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A66FC7A; Sat, 28 Mar 2015 21:34:12 +0000 (UTC) Received: by lbbug6 with SMTP id ug6so84709600lbb.3; Sat, 28 Mar 2015 14:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=OgbkIbOFWrdqPE+apjwN29yOXJwS8M0SP6KaRwvLeCs=; b=qvZNuq/k/uOKcUFa23WYCPHQtJTPvcZ3wzNYft8J8bg5YgjSqNhCJKdvJ/vgMQly6W yQqnKJ+AAfuAwKXgvbru/AhPed2RqQ1R+wEen2/aOm8jNcBrK+Pn0oDo4a9c5/l07kKy nLqTFlLuhc7ELmZKLmpkANNOxnyI3lw3ZBFU7CqQIYqqXA0gbDNSRHKM5nskCCLgRtQK YmmPE+osbxBW6zs5uvjFIuZ4G9Bk2b5u/Rc2c1MJoQS596FtQGxdKK6Y75wg/gH/miKW 2NFD3d9Os2t5qvO9BWogtgTN6AgE/J29JNmt2hXjM3yXlALVwf9fxVfNO0MeMMib6Wqj cCAQ== MIME-Version: 1.0 X-Received: by 10.112.223.7 with SMTP id qq7mr22810094lbc.81.1427578450162; Sat, 28 Mar 2015 14:34:10 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.108.168 with HTTP; Sat, 28 Mar 2015 14:34:10 -0700 (PDT) Date: Sat, 28 Mar 2015 14:34:10 -0700 X-Google-Sender-Auth: 4JG9f52w8XTCZXdAbPe68XHCrho Message-ID: Subject: Failed to build rescue with gcc 4.9 From: Craig Rodrigues To: freebsd-toolchain@freebsd.org, "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 21:34:13 -0000 Hi, The build host VM that I used was FreeBSD 10.1-RELEASE, amd64. I took this patch for libc++ and applied it to my tree: http://reviews.llvm.org/D8461 I used this script to build with gcc 4.9: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh Building rescue failed. You can see the full build log here: https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/26/console The relevant section seems to be this: --- rescue --- /usr/local/bin/x86_64-portbld-freebsd10.0-gcc -isystem /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp -B/usr/local/x86_64-freebsd/bin/ -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo sleep.lo stty.lo sync.lo test.lo rcp.lo csh.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo less.lo xz.lo tar.lo vi.lo id.lo zdb.lo chroot.lo chown.lo /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/exec.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/getusershell.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/login_class.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/popen.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/rcmdsh.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/sysctl.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/system.o -lcrypt -ledit -ljail -lkvm -ll -ltermcapw -lutil -lxo -lalias -lcam -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs -lnvpair -lpthread -luutil -lumem -lgeom -lbsdxml -lkiconv -lmt -lsbuf -lufs -lz -lbz2 -larchive -lcrypto -lmd -lm cat.lo: file not recognized: File truncated collect2: error: ld returned 1 exit status *** [rescue] Error code 1 make[5]: stopped in /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue 1 error I double checked. cat.lo is not a truncated file. # ls -l cat.lo ; file cat.lo -rw-r--r-- 1 jenkins wheel 13112 Mar 28 21:17 cat.lo cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped Any ideas? -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 28 22:53:54 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17AFE3BD; Sat, 28 Mar 2015 22:53:54 +0000 (UTC) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BDF06C7; Sat, 28 Mar 2015 22:53:53 +0000 (UTC) Received: by labe2 with SMTP id e2so93762702lab.3; Sat, 28 Mar 2015 15:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=4I/yP7elJuvILz1n7cnBqDvVD3qop+0TZg+qpf9x0YM=; b=S7QAA+be+bLigQnbX98+doBmKyrPq0g4ny06Na65QoyfIYz6SvWM5BV9SPGlVUF20r j5v+Yd+Tkyrq/VuBiXC/SuSp506jYDe/+AqT0Ksa/KbJRBeFu0v2rJcoVun64iqeaNco 3/xsscKMtXxZtdOHllJTljaxUO2odSok0zfZn9rDN5wOki9LWUzECj49OOetl7xnIsLp RdsLxhGPQgJGL3BEhuZ9p1YqnU4F2wiIIpcSlkBWMXCqIN/eHLT4ogxfxcj3KA9SoGr6 42Tzjh0V4LdVah3q/aBeyIDs3y3PmMHaopvSqWuZKdu4Y617NeQGKCXMJg1dTMDjFz7o cRUQ== MIME-Version: 1.0 X-Received: by 10.112.140.38 with SMTP id rd6mr22774465lbb.116.1427583231652; Sat, 28 Mar 2015 15:53:51 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.108.168 with HTTP; Sat, 28 Mar 2015 15:53:51 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 Mar 2015 15:53:51 -0700 X-Google-Sender-Auth: Z43gx8DvnBJmElDzd8RODXngl5c Message-ID: Subject: Re: Failed to build rescue with gcc 4.9 From: Craig Rodrigues To: freebsd-toolchain@freebsd.org, "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 22:53:54 -0000 On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues wrote: > > > I double checked. cat.lo is not a truncated file. > # ls -l cat.lo ; file cat.lo > -rw-r--r-- 1 jenkins wheel 13112 Mar 28 21:17 cat.lo > cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped > > Hmm, so file reports that it is an ELF file, but readelf barfs on the file. I have the file here for anyone who wants to look at it: http://people.freebsd.org/~rodrigc/cat.lo # file cat.lo ; readelf -a cat.lo cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped readelf: Error: Unable to read in 0x40 bytes of section headers ELF Header: Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - FreeBSD ABI Version: 0 Type: REL (Relocatable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 51092930964640 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 19 Section header string table index: 16 readelf: Error: Unable to read in 0x4c0 bytes of section headers readelf: Error: Section headers are not available! Abort trap (core dumped) -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 28 23:05:48 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7161B859; Sat, 28 Mar 2015 23:05:48 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF169847; Sat, 28 Mar 2015 23:05:47 +0000 (UTC) Received: by labto5 with SMTP id to5so94212365lab.0; Sat, 28 Mar 2015 16:05:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=L/LsqcRVtBWz+wxvMpth4zMtU4ZX03xxs+kpAhXx9u0=; b=tShmgGrUo7ujrhkFFlNNhhLHd0cCBLxST9IsQ14TkGix/4614qx+mhyK3lfMB2ggG7 QF7yjtGzDHpGEqp5JZnAPv4ed20UkyBRlRRGroiAvjQyc5xPdlZZwXb9KaAIdkYD1dun mgUGE7WZ3tGmCFrObVqb3GLIIULe+o/0b5zX02dujiy5+MThDRjrfyqDmdDtM0Lwgl+k 2PDVYWm5b6yPV17gG/2UqBno76Nu2lMRAbbTOTFXAWDKBm+Mhi/i9Hfgp3My3sfCDmRy WMpcAeU8z07+hCtLs64HGDZKU5RGdJpSMza5mDYnIPr68yOc6KjDsSHoxnlCO8MKI+OF ndZw== MIME-Version: 1.0 X-Received: by 10.112.223.7 with SMTP id qq7mr23016607lbc.81.1427583945855; Sat, 28 Mar 2015 16:05:45 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.108.168 with HTTP; Sat, 28 Mar 2015 16:05:45 -0700 (PDT) Date: Sat, 28 Mar 2015 16:05:45 -0700 X-Google-Sender-Auth: -zFerbF32r6NNSrjCGcuQAC8M0E Message-ID: Subject: Fails to build sys/i386/boot2 with gcc 4.9 From: Craig Rodrigues To: freebsd-toolchain@freebsd.org, "freebsd-testing@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 23:05:48 -0000 Hi, To work around the problems build rescue, this time I used a build host running FreeBSD-CURRENT at svn revision r280353 I took this patch for libc++ and applied it to my tree: http://reviews.llvm.org/D8461 I used this script to build with gcc 4.9: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh Buildling sys/i386/boot2 failed: ===> sys/boot/i386/boot2 (all) objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.000034 secs (14989607 bytes/sec) /usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem /usr/obj/opt2/branches/head/tmp/usr/include -L/usr/obj/opt2/branches/head/tmp/usr/lib --sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/ -fomit-frame-pointer -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/opt2/branches/head/sys/boot/i386/boot2/../../common -I/opt2/branches/head/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline -march=i386 -ffreestanding -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -std=gnu99 -Os -fno-guess-branch-probability -fno-unit-at-a-time --param max-inline-insns-single=100 -mpreferred-stack-boundary=2 -S -o boot2.s.tmp /opt2/branches/head/sys/boot/i386/boot2/boot2.c /opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'parse': /opt2/branches/head/sys/boot/i386/boot2/boot2.c:484:6: warning: suggest parentheses around assignment used as truth value [-Wparentheses] if (k = ep - arg) { ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c: In function 'load': /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining failed in call to 'xfsread': call is unlikely and code size would grow [-Winline] xfsread(ufs_ino_t inode, void *buf, size_t nbyte) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:334:9: warning: called from here [-Winline] if (xfsread(ino, &hdr, sizeof(hdr))) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining failed in call to 'xfsread': call is unlikely and code size would grow [-Winline] xfsread(ufs_ino_t inode, void *buf, size_t nbyte) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:341:6: warning: called from here [-Winline] if (xfsread(ino, p, hdr.ex.a_text)) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining failed in call to 'xfsread': call is unlikely and code size would grow [-Winline] xfsread(ufs_ino_t inode, void *buf, size_t nbyte) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:344:6: warning: called from here [-Winline] if (xfsread(ino, p, hdr.ex.a_data)) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining failed in call to 'xfsread': call is unlikely and code size would grow [-Winline] xfsread(ufs_ino_t inode, void *buf, size_t nbyte) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:349:10: warning: called from here [-Winline] if (xfsread(ino, ep + j, sizeof(ep[0]))) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining failed in call to 'xfsread': call is unlikely and code size would grow [-Winline] xfsread(ufs_ino_t inode, void *buf, size_t nbyte) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:357:10: warning: called from here [-Winline] if (xfsread(ino, p, ep[i].p_filesz)) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining failed in call to 'xfsread': call is unlikely and code size would grow [-Winline] xfsread(ufs_ino_t inode, void *buf, size_t nbyte) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:365:10: warning: called from here [-Winline] if (xfsread(ino, &es, sizeof(es))) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:187:1: warning: inlining failed in call to 'xfsread': call is unlikely and code size would grow [-Winline] xfsread(ufs_ino_t inode, void *buf, size_t nbyte) ^ /opt2/branches/head/sys/boot/i386/boot2/boot2.c:371:7: warning: called from here [-Winline] if (xfsread(ino, p, es[i].sh_size)) ^ sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp /usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem /usr/obj/opt2/branches/head/tmp/usr/include -L/usr/obj/opt2/branches/head/tmp/usr/lib --sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/ -m32 -c boot2.s /usr/local/bin/x86_64-portbld-freebsd11.0-gcc -isystem /usr/obj/opt2/branches/head/tmp/usr/include -L/usr/obj/opt2/branches/head/tmp/usr/lib --sysroot=/usr/obj/opt2/branches/head/tmp -B/usr/local/x86_64-freebsd/bin/ -fomit-frame-pointer -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/opt2/branches/head/sys/boot/i386/boot2/../../common -I/opt2/branches/head/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline -march=i386 -ffreestanding -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -std=gnu99 -Os -fno-guess-branch-probability -fno-unit-at-a-time --param max-inline-insns-single=100 -mpreferred-stack-boundary=2 -m32 -c /opt2/branches/head/sys/boot/i386/boot2/sio.S -o sio.o /usr/local/x86_64-freebsd/bin/ld -static -N --gc-sections -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/opt2/branches/head/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/opt2/branches/head/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=195f text=0 data=0 bss=0 entry=0 output: fmt=bin size=21ef text=200 data=1fef org=0 entry=0 -1007 bytes available *** Error code 1 Stop. make[6]: stopped in /opt2/branches/head/sys/boot/i386/boot2 *** Error code 1 Stop. make[5]: stopped in /opt2/branches/head/sys/boot/i386 *** Error code 1 Stop. make[4]: stopped in /opt2/branches/head/sys/boot *** Error code 1 Stop. make[3]: stopped in /opt2/branches/head/sys *** Error code 1 Stop. make[2]: stopped in /opt2/branches/head *** Error code 1 Stop. make[1]: stopped in /opt2/branches/head *** Error code 1 Stop. make: stopped in /opt2/branches/head Script done on Sat Mar 28 13:44:24 2015 -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 28 23:34:08 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 560DAF15; Sat, 28 Mar 2015 23:34:08 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 106CBB77; Sat, 28 Mar 2015 23:34:08 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::81a8:baf0:98fb:d610] (unknown [IPv6:2001:7b8:3a7:0:81a8:baf0:98fb:d610]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6EF6F5C2E; Sun, 29 Mar 2015 00:34:00 +0100 (CET) Subject: Re: Fails to build sys/i386/boot2 with gcc 4.9 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7FBCFB16-3962-4838-B230-2ABD3225C862"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: Dimitry Andric In-Reply-To: Date: Sun, 29 Mar 2015 00:33:54 +0100 Message-Id: <20683705-0EBA-4B8F-A0CE-9C06B8003BBE@FreeBSD.org> References: To: Craig Rodrigues X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-testing@freebsd.org" , FreeBSD Toolchain X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 23:34:08 -0000 --Apple-Mail=_7FBCFB16-3962-4838-B230-2ABD3225C862 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Mar 2015, at 00:05, Craig Rodrigues wrote: >=20 > To work around the problems build rescue, this time I used a build = host > running FreeBSD-CURRENT at svn revision r280353 >=20 > I took this patch for libc++ and applied it to my tree: >=20 > http://reviews.llvm.org/D8461 I've only got one minor remark left on that fix, which is that it doesn't work for gcc 4.7. Once we either say that version of gcc is just buggy and can't be helped, or have some other way of fixing the original problem, I'll import it. > I used this script to build with gcc 4.9: >=20 > = https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-buil= d.sh >=20 > Buildling sys/i386/boot2 failed: ... > output: fmt=3Dbin size=3D21ef text=3D200 data=3D1fef org=3D0 entry=3D0 > -1007 bytes available > *** Error code 1 Oof, this is going to be hard to fix. For some reason, boot2 is one of those programs that keeps getting worse (i.e. larger) with *each* new compiler version, be it gcc or clang! The last few times when we imported a new clang version, we had to jump through several hoops, and attempted to shrink the code again with various cleanups. Even then, we don't have a lot of headroom. If it is now also becoming a problem with gcc 4.9, we should really start looking for a more permanent solution, e.g.: * Getting rid of the 7680 byte limit (seems to be impossible?) * Rewrite most of (or all of) boot2 in assembly -Dimitry --Apple-Mail=_7FBCFB16-3962-4838-B230-2ABD3225C862 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.27 iEYEARECAAYFAlUXOmcACgkQsF6jCi4glqOMOgCfZVgxqN6KtSCY0LxCHNtlSpfd pCkAn0jJHcKrPrKJ8l3n8MVC6dbFX+OW =ZNCv -----END PGP SIGNATURE----- --Apple-Mail=_7FBCFB16-3962-4838-B230-2ABD3225C862--