From owner-freebsd-toolchain@FreeBSD.ORG Sun Jan 12 16:21:25 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C6C7F60 for ; Sun, 12 Jan 2014 16:21:25 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 041461E05 for ; Sun, 12 Jan 2014 16:21:24 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::45d8:cd15:7900:2480] (unknown [IPv6:2001:7b8:3a7:0:45d8:cd15:7900:2480]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id A29205C43; Sun, 12 Jan 2014 17:21:20 +0100 (CET) Subject: Re: [CFT] Update to clang 3.4 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: multipart/signed; boundary="Apple-Mail=_093027C5-5A31-42A5-AF71-770BA8D2E3EB"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.1 (6062eb4) From: Dimitry Andric In-Reply-To: <52D286BE.7000102@kbh.biglobe.ne.jp> Date: Sun, 12 Jan 2014 17:21:10 +0100 Message-Id: <50EAAC3C-2D38-4409-B525-2608D39BFE70@FreeBSD.org> References: <541C998A-071A-4917-9D91-DD00CB0E2689@FreeBSD.org> <63BD3165-A62E-4FE7-9817-4A2692584916@bsdimp.com> <264FAA6E-871A-48AF-A8D9-EC431A537195@FreeBSD.org> <6766B735-98CB-4F1D-B3B5-A43D81BB558A@FreeBSD.org> <52D286BE.7000102@kbh.biglobe.ne.jp> To: Yamaya Takashi X-Mailer: Apple Mail (2.1827) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 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, 12 Jan 2014 16:21:25 -0000 --Apple-Mail=_093027C5-5A31-42A5-AF71-770BA8D2E3EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 12 Jan 2014, at 13:12, Yamaya Takashi = wrote: > buildworld is failed when WITH_LLDB=3D Yes, this is a known issue. I discussed it with Ed Maste. Clang 3.4 will have to be imported first, afterwards we can fix lldb. =20 > some ports cannot build. >=20 > reason1: clang cannot handle some options. > (libmad build) > cc: error: unknown argument: '-fforce-addr' > cc: error: unknown argument: '-fthread-jumps' > cc: error: unknown argument: '-fcse-follow-jumps' > cc: error: unknown argument: '-fcse-skip-blocks' > cc: error: unknown argument: '-fregmove' > cc: error: unknown argument: '-fschedule-insns2' > (libtheora build) > cc: error: unknown argument: '-fforce-addr' > (poppler build) > c++: error: unknown argument: '-fno-check-new' > (py27-sqlite build) > cc: error: unknown argument: '-R/usr/local/lib' > (tbb build) > c++: error: unknown argument: '-fno-schedule-insns2' > (gstreamer-ffmpeg build) > cc: error: unknown argument: '-fno-force-addr' Indeed, this is likely the most troublesome aspect of the upgrade. Most of the above options, like "-fcse-follow-jumps", "-fno-check-new", etc are gcc-specific, and will never be supported by clang. These options will have to be removed, or made conditional on the compiler. The -R option is not a compiler option, but an ld option, and is also ambiguous: ld interprets it as --just-symbols when it is followed by the name of a file, but as -rpath when it is followed by the name of a directory. In all cases, this should be replaced with -Wl,-rpath. > reason2: c++ -std=3Dc++11 detect bad c++ code which older clang cannot = detect. > (libproxy build) > = /usr/ports/net/libproxy/work/libproxy-0.4.6/libproxy/modules/wpad_dns_alia= s.cpp:30:23: > error: cannot initialize return object of type 'libproxy::url *' with = an > rvalue of type 'bool' > if (lasturl) return false; > ^~~~~ > (liveMedia build) I have not looked in detail at this one, but this looks like a simple bug. The code should not return a boolean when the return type of the function is a libproxy::url pointer. Should be easy to fix. The new C++11 rules make it possible to avoid 'casting' a false value to a NULL pointer, and clang 3.4 detects this. > c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include > -I. -DBSD=3D1 -DSOCKLEN_T=3Dsocklen_t -D_LARGEFILE_SOURCE=3D1 > -D_FILE_OFFSET_BITS=3D64 -DHAVE_SOCKADDR_LEN=3D1 -Wall -DBSD=3D1 -O2 = -pipe > -Qunused-arguments -march=3Dnative -fPIC -fno-strict-aliasing = -std=3Dc++11 > -Wno-c++11-narrowing -stdlib=3Dlibc++ -Wno-deprecated = RTSPRegisterSender.cpp > RTSPClient.cpp:916:25: error: comparison between pointer and integer > ('const char *' and 'int') > if (&line[paramIndex] =3D=3D '\0') return False; // the header is = assumed > to be bad if it has no parameters > ~~~~~~~~~~~~~~~~~ ^ ~~~~ > (mp4v2 build) This looks like an incorrect comparison: a pointer is compared with a literal character. Should be easy to fix. > c++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -O2 > -pipe -Qunused-arguments -march=3Dnative -fno-strict-aliasing = -std=3Dc++11=20 > -Wno-c++11-narrowing -stdlib=3Dlibc++ -fvisibility=3Dhidden -c > src/mp4container.cpp -fPIC -DPIC -o src/.libs/mp4container.o > src/mp4.cpp:679:20: error: cannot initialize return object of type > 'mp4v2_ismacrypParams *' (aka 'mp4v2_ismacryp_session_params *') with = an > rvalue of type 'MP4TrackId' (aka 'unsigned int') > return MP4_INVALID_TRACK_ID; > ^~~~~~~~~~~~~~~~~~~~ > ./include/mp4v2/general.h:45:33: note: expanded from macro > 'MP4_INVALID_TRACK_ID' > #define MP4_INVALID_TRACK_ID ((MP4TrackId)0) /**< Constant: > invalid MP4TrackId. */ > ^~~~~~~~~~~~~~~ > (thunderbird build) Again, an attempt is made to use an incorrect type for the return value of a function. Either the value should be explicitly cast to the correct type (mp4v2_ismacrypParams *), or the MP4_INVALID_TRACK_ID define should be fixed to be of the correct type. > clang++ -o jsoptparse.o -c -I../../../dist/system_wrappers_js = -include > = /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/config/gcc_hidd= en.h > -DEXPORT_JS_API -DIMPL_MFBT -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT > -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src -I.. > -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell -I. > -I../../../dist/include -I/usr/local/include/nspr -fPIC > -Qunused-arguments -isystem/usr/local/include -Qunused-arguments = -Wall > -Wpointer-arith -Woverloaded-virtual -Werror=3Dreturn-type = -Wtype-limits > -Wempty-body -Werror=3Dconversion-null -Wsign-compare > -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof > -Wno-unknown-warning-option -Wno-return-type-c-linkage > -Wno-mismatched-tags -O2 -pipe -Qunused-arguments -march=3Dnative -O3 > -fno-strict-aliasing -std=3Dc++11 -Wno-c++11-narrowing -stdlib=3Dlibc++ > -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pipe=20 > -DNDEBUG -DTRIMMED -O2 -O3 -fomit-frame-pointer -Qunused-arguments > -isystem/usr/local/include -DMOZILLA_CLIENT -include ../js-confdefs.h > -MD -MP -MF .deps/jsoptparse.o.pp /usr/ports/mail/thunderbir > d/work/comm-esr24/mozilla/js/src/shell/jsoptparse.cpp > = /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell/jsoptpars= e.cpp:256:22: > error: comparison between pointer and integer ('char *' and 'int') > if (value[0] =3D=3D '\0') > ~~~~~~~~ ^ ~~~~ Like the mp4v2 build, this is probably a simple bug. The code should not compare a pointer to an integer. Most likely, the right side was supposed to be NULL instead? -Dimitry --Apple-Mail=_093027C5-5A31-42A5-AF71-770BA8D2E3EB 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.22 (Darwin) iEUEARECAAYFAlLSwPsACgkQsF6jCi4glqMQ+QCVFKJS3pAtQZgyH5I3eSm85zBG JwCeOyiKMQHqPouMqPHkinL4aTOmDDE= =9mC9 -----END PGP SIGNATURE----- --Apple-Mail=_093027C5-5A31-42A5-AF71-770BA8D2E3EB--