From owner-freebsd-toolchain@FreeBSD.ORG Wed Jan 22 17:27:52 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 438E4D58; Wed, 22 Jan 2014 17:27:52 +0000 (UTC) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D7A991F23; Wed, 22 Jan 2014 17:27:51 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 93D9A4001E; Wed, 22 Jan 2014 18:27:49 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 89B1540019; Wed, 22 Jan 2014 18:27:49 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (unknown [94.254.45.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id C0E8E40017; Wed, 22 Jan 2014 18:27:46 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3f8YTt2r1wz8ggx; Wed, 22 Jan 2014 18:27:46 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id as3BICPIvN8k; Wed, 22 Jan 2014 18:27:43 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [10.1.0.4]) by mx.daemonic.se (Postfix) with ESMTPS id 3f8YTp2tGmz8gh0; Wed, 22 Jan 2014 18:27:42 +0100 (CET) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:1::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 3f8YTp2M6qz9Cvr; Wed, 22 Jan 2014 18:27:42 +0100 (CET) Message-ID: <52DFFF8E.70000@daemonic.se> Date: Wed, 22 Jan 2014 18:27:42 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Yamaya Takashi Subject: Re: [CFT] Update to clang 3.4 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> <50EAAC3C-2D38-4409-B525-2608D39BFE70@FreeBSD.org> <52DFCCFF.8080002@daemonic.se> <52DFFF20.9000809@kbh.biglobe.ne.jp> In-Reply-To: <52DFFF20.9000809@kbh.biglobe.ne.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-toolchain@freebsd.org, Dimitry Andric 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: Wed, 22 Jan 2014 17:27:52 -0000 On 01/22/14 18:25, Yamaya Takashi wrote: > On 2014/01/22 22:51, Niclas Zeising wrote: >> On 01/12/14 17:21, Dimitry Andric wrote: >>> On 12 Jan 2014, at 13:12, Yamaya Takashi wrote: >>>> buildworld is failed when WITH_LLDB= >>> 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. >>> >>> >>>> some ports cannot build. >>>> >>>> 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=c++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_alias.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=1 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 >>>> -D_FILE_OFFSET_BITS=64 -DHAVE_SOCKADDR_LEN=1 -Wall -DBSD=1 -O2 -pipe >>>> -Qunused-arguments -march=native -fPIC -fno-strict-aliasing -std=c++11 >>>> -Wno-c++11-narrowing -stdlib=libc++ -Wno-deprecated RTSPRegisterSender.cpp >>>> RTSPClient.cpp:916:25: error: comparison between pointer and integer >>>> ('const char *' and 'int') >>>> if (&line[paramIndex] == '\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=native -fno-strict-aliasing -std=c++11 >>>> -Wno-c++11-narrowing -stdlib=libc++ -fvisibility=hidden -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_hidden.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=return-type -Wtype-limits >>>> -Wempty-body -Werror=conversion-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=native -O3 >>>> -fno-strict-aliasing -std=c++11 -Wno-c++11-narrowing -stdlib=libc++ >>>> -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pipe >>>> -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/jsoptparse.cpp:256:22: >>>> error: comparison between pointer and integer ('char *' and 'int') >>>> if (value[0] == '\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? >>> >> I'm probably late to the party, as always... But, have you or Yamaya >> Takashi tried to punt these issues to the respective port managers for >> investigation? >> Regards! > I have patches for libproxy, liveMedia, mp4v2 and thunderbird. > > Send them to the respective maintainer. I've already sent a patch for thunderbird though, since I found one in their bugzilla. Regards! -- Niclas