From owner-freebsd-toolchain@FreeBSD.ORG Sun Sep 7 14:31:01 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 66BAEEE for ; Sun, 7 Sep 2014 14:31:01 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id 25E1D1D3B for ; Sun, 7 Sep 2014 14:31:00 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Sun, 7 Sep 2014 10:30:59 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Sun, 7 Sep 2014 07:30:58 -0700 From: "Sinha, Prokash" To: "freebsd-toolchain@freebsd.org" Subject: How to enable coverage option in the latest drop of clang/llvm Thread-Topic: How to enable coverage option in the latest drop of clang/llvm Thread-Index: AQHPyqhX6WYHefv+xkihoT1C9iNBKA== Date: Sun, 7 Sep 2014 14:30:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.142.185] Content-Type: text/plain; charset="us-ascii" Content-ID: <6C9A205F32ADC44D8E9BCFCCD65B0BFE@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Sep 2014 14:30:59.0668 (UTC) FILETIME=[57FF0140:01CFCAA8] 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, 07 Sep 2014 14:31:01 -0000 Hi All, Initially I was having problem compiling clang/llvm, then found some of the= compilation error. Now I can build it on freebsd 10. But I need to have the coverage option on. On Mac it is still there - bash$ clang --coverage main.c -### Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix "/usr/bin/clang" "-cc1" "-triple" "x86_64-apple-macosx10.8.0" "-emit-obj" = "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-main-file-name" "m= ain.c" "-mrelocation-model" "pic" "-pic-level" "2" "-mdisable-fp-elim" "-ma= sm-verbose" "-munwind-tables" "-target-cpu" "core2" "-target-linker-version= " "236.3" "-femit-coverage-notes" "-femit-coverage-data" "-resource-dir" "/= usr/bin/../lib/clang/5.1" "-fdebug-compilation-dir" "/fs/home/psinha/mystuf= f/pgms" "-ferror-limit" "19" "-fmessage-length" "80" "-stack-protector" "1"= "-mstackrealign" "-fblocks" "-fobjc-runtime=3Dmacosx-10.8.0" "-fencode-ext= ended-block-signature" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-= vectorize-slp" "-o" "/var/folders/65/gpz82csd1_s358m49000073r0001ry/T/main-= 746665.o" "-x" "c" "main.c" "/usr/bin/ld" "-demangle" "-dynamic" "-arch" "x86_64" "-macosx_version_min= " "10.8.0" "-o" "a.out" "/var/folders/65/gpz82csd1_s358m49000073r0001ry/T/m= ain-746665.o" "/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.profile_osx= .a" "-lSystem" "/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a" Thanks, prokash From owner-freebsd-toolchain@FreeBSD.ORG Mon Sep 8 15:26:13 2014 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A571205 for ; Mon, 8 Sep 2014 15:26:13 +0000 (UTC) Received: from mon-colo.panasas.com (mon-colo.panasas.com [209.166.131.137]) by mx1.freebsd.org (Postfix) with ESMTP id B9DA81CF1 for ; Mon, 8 Sep 2014 15:26:12 +0000 (UTC) Received: from seabiscuit.panasas.com ([172.17.132.204]) by mon-colo.panasas.com with Microsoft SMTPSVC(7.0.6001.18000); Mon, 8 Sep 2014 11:26:04 -0400 Received: from SEABISCUIT.int.panasas.com ([172.17.132.204]) by seabiscuit ([172.17.132.204]) with mapi id 14.03.0181.006; Mon, 8 Sep 2014 08:26:04 -0700 From: "Sinha, Prokash" To: "freebsd-toolchain@freebsd.org" Subject: Re: How to enable coverage option in the latest drop of clang/llvm Thread-Topic: How to enable coverage option in the latest drop of clang/llvm Thread-Index: AQHPyqhX6WYHefv+xkihoT1C9iNBKJv3XR+A Date: Mon, 8 Sep 2014 15:26:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.133.204] Content-Type: text/plain; charset="Windows-1252" Content-ID: <90A0BA71D33ED24493CEF6F27ADB7DC3@panasas.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Sep 2014 15:26:04.0833 (UTC) FILETIME=[3470E910:01CFCB79] 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, 08 Sep 2014 15:26:13 -0000 Can someone please enlighten me on this=85 __ The freebsd10 stable does not have the =97coverage option working. Wher= eas mac X with Xcode handles this as per my experiment. __ So I should have some flags or something from the configure options that= I can use to have this enabled. If not, then please help me understand this. Thanks -prokash From: , Prokash Sinha = > Date: Sunday, September 7, 2014 7:30 AM To: "freebsd-toolchain@freebsd.org" <= freebsd-toolchain@freebsd.org> Subject: How to enable coverage option in the latest drop of clang/llvm Hi All, Initially I was having problem compiling clang/llvm, then found some of the= compilation error. Now I can build it on freebsd 10. But I need to have the coverage option on. On Mac it is still there - bash$ clang --coverage main.c -### Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix "/usr/bin/clang" "-cc1" "-triple" "x86_64-apple-macosx10.8.0" "-emit-obj" = "-mrelax-all" "-disable-free" "-disable-llvm-verifier" "-main-file-name" "m= ain.c" "-mrelocation-model" "pic" "-pic-level" "2" "-mdisable-fp-elim" "-ma= sm-verbose" "-munwind-tables" "-target-cpu" "core2" "-target-linker-version= " "236.3" "-femit-coverage-notes" "-femit-coverage-data" "-resource-dir" "/= usr/bin/../lib/clang/5.1" "-fdebug-compilation-dir" "/fs/home/psinha/mystuf= f/pgms" "-ferror-limit" "19" "-fmessage-length" "80" "-stack-protector" "1"= "-mstackrealign" "-fblocks" "-fobjc-runtime=3Dmacosx-10.8.0" "-fencode-ext= ended-block-signature" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-= vectorize-slp" "-o" "/var/folders/65/gpz82csd1_s358m49000073r0001ry/T/main-= 746665.o" "-x" "c" "main.c" "/usr/bin/ld" "-demangle" "-dynamic" "-arch" "x86_64" "-macosx_version_min= " "10.8.0" "-o" "a.out" "/var/folders/65/gpz82csd1_s358m49000073r0001ry/T/m= ain-746665.o" "/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.profile_osx= .a" "-lSystem" "/usr/bin/../lib/clang/5.1/lib/darwin/libclang_rt.osx.a" Thanks, prokash From owner-freebsd-toolchain@FreeBSD.ORG Wed Sep 10 17:24:19 2014 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8737F57; Wed, 10 Sep 2014 17:24:19 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BBFF31D3; Wed, 10 Sep 2014 17:24:18 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA22498; Wed, 10 Sep 2014 20:24:17 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XRlcu-000N2y-Tz; Wed, 10 Sep 2014 20:24:16 +0300 Message-ID: <54108909.7050908@FreeBSD.org> Date: Wed, 10 Sep 2014 20:23:21 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-toolchain@FreeBSD.org, freebsd-dtrace@FreeBSD.org Subject: WITH_CTF vs -g Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 8bit 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, 10 Sep 2014 17:24:19 -0000 In my opinion WITH_CTF should imply -g in CFLAGS otherwise, as far as I can see, there is nothing to generate CTF data from. Forcing an end-user to remember to additionally pass -g is not nice. Also, I think that we can always have -g in CTFFLAGS, because the stripping step takes care of the original DWARF data in any case. But I am not 100% sure about this. What do you think? Thanks! -- Andriy Gapon From owner-freebsd-toolchain@FreeBSD.ORG Wed Sep 10 18:45:29 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 F01C8286 for ; Wed, 10 Sep 2014 18:45:28 +0000 (UTC) Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) (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 91FC6C39 for ; Wed, 10 Sep 2014 18:45:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1410374721; bh=8XRgJXsDjD39jNM1PffhNvIoW16sSD6tB6ttviSdrG0=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:From:Subject; b=ZPaM1wwnXuEyZf+v3ZNGOnP9f3MsFbOxlenaDxN5zXFDkCL2t8S0RN6JtIySZnsEqzSw1HXQWELlOjMf6CFoT2YpfSNXRHK0MJECLt8EuOIuNz5vwEYFNhnaX+5+d9bE0/U67lHQfpuXIJ841ehct7SVImzcyVFuJmeN3o2tIxN89uhQImrf70d1M1WWOCJ/07K6+PM/x8oMRDYYw2Mc7MZyZBBmzS7IbFsI/c3wNFeYnaMHy1xydsbUHWe0Mq4NvB5XVrgtds6CTIgl9FEUc1ZecJBzIzA2/xfoSNimSoUFj1tM3AoEX+F74EQgGbIucTJMk6d9etiQPL7gwYpdTA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=cuGMXOgnF/pKZCsKztXapRZGt/UpasbbDNZm0FrUeietJ7OWdgMbU4efT3i7yyi5HfxR6WNu6Wia94fhgvDjO1a+tc0HJDlGaxZfUbedscMuwWGv6n/ckNH5DPXq8US63b+kYMZXwDTfc7h24zlxPmESDqH2QPaDKeqIwItI5Kv6RNpFYRHVDU7cPFFMOvSBbwyIXl+4T3c+ce8SS2X8/BE79rx14a4z1qxJiSEx/hB1NKYf51pshrPlAZjCcdywCUURGcVgdqhA3PX7V1h8hsslWfURmlghXo/5oEVod4/AaDJY8czkCQSqDctG4qnqunhwGGQ0+if2MpxMH23L9g==; Received: from [98.139.215.141] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 10 Sep 2014 18:45:21 -0000 Received: from [68.142.230.64] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 10 Sep 2014 18:45:21 -0000 Received: from [127.0.0.1] by smtp221.mail.bf1.yahoo.com with NNFMP; 10 Sep 2014 18:45:21 -0000 X-Yahoo-Newman-Id: 424371.14573.bm@smtp221.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: RMAmT0MVM1l..R3RtV28yHpgevXpP_shWb5rV8TMBOtyEBs _7Pyjp4kV3vC6vwt5642frWj31._6aEjexih4OPKMPNfawA3u0eb0VtZ9x7s jv1lnCGl7SY6a0DTMagSVvT7L.1eL3FuHBECzOm9KR0ULwULpsAJSj7KEu_s 9FBInzrwRK4awQ_Akcc8MZ7V3EfGVKxxfoRXV45Cm7ao3k180kbJqVskRWOg 152VXiA1.AHkkRfPA4eR4OsNRbUVlzwHtGLrGo_etE.Ly_296hiYydErznLi 3yPocUBd0X.8Z1VHPq3gUQcM55a0X8UfwvsCd.spBwc7ICFOkAjRAwaQyIqx OjPbyTt8spzPujqs7iMMZOi.GvPoY037GQk9lmoAV.tAFsQ0PJxc8C70O_R_ 6pr78AyAIVAk3jZlkEJOXI0ZDgb9tPMtyE5wLCpLNcLXLxyZjxAzuqZOJXQA M794jb2scVBGAZivCODm04QqCN62lmL6Ym4FXmzqB_f5vlnmjAR1jzl.cmxS 0muYT7lXeBS9MV1Vj2BvvFNDRjEHfPzcZgQBIYTME6I3rxsTtns7.bhMhXrJ Mo2gb1QMAUbchqKdpD_8i3j6L3mRInFHxT9kBC6Y4X7XijT.iAaGu1c1T1UN PwJXeMGIcF1EZ_WnO X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: WITH_CTF vs -g From: Pedro Giffuni In-Reply-To: <54108909.7050908@FreeBSD.org> Date: Wed, 10 Sep 2014 13:45:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <58B30723-19D6-40FA-97F7-206401C5D2A2@freebsd.org> References: <54108909.7050908@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-toolchain@FreeBSD.org, freebsd-dtrace@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, 10 Sep 2014 18:45:29 -0000 Hi Andriy; Il giorno 10/set/2014, alle ore 12:23, Andriy Gapon ha = scritto: >=20 > In my opinion WITH_CTF should imply -g in CFLAGS otherwise, as far as = I can see, > there is nothing to generate CTF data from. Forcing an end-user to = remember to > additionally pass -g is not nice. >=20 My understanding is that CTF is meant to be a debugging format = independent of DWARF, so it should be especially useful for the cases where there is no = debugging information. Just like Illumos, we haven=92t really made much (or any) use of CTF = outside the kernel but now that is an option: http://dtrace.org/blogs/rm/2013/11/14/userland-ctf-in-dtrace/=20 > Also, I think that we can always have -g in CTFFLAGS, because the = stripping step > takes care of the original DWARF data in any case. But I am not 100% = sure about > this. >=20 > What do you think? BTW, it would be nice to see what we can take from the CTF/DDB GSoC [1]. = I understand the BSD-licensed CTF library has advanced greatly but still needs more = work. Pedro. =1B[1] = http://lists.freebsd.org/pipermail/soc-status/2014-August/000870.html From owner-freebsd-toolchain@FreeBSD.ORG Wed Sep 10 19:31:29 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 A985B8BF; Wed, 10 Sep 2014 19:31:29 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 62B3C1B8; Wed, 10 Sep 2014 19:31:28 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8AJVKfu040365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2014 12:31:21 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8AJVKC2040364; Wed, 10 Sep 2014 12:31:20 -0700 (PDT) (envelope-from jmg) Date: Wed, 10 Sep 2014 12:31:20 -0700 From: John-Mark Gurney To: Pedro Giffuni Subject: Re: WITH_CTF vs -g Message-ID: <20140910193120.GA82175@funkthat.com> References: <54108909.7050908@FreeBSD.org> <58B30723-19D6-40FA-97F7-206401C5D2A2@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58B30723-19D6-40FA-97F7-206401C5D2A2@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 10 Sep 2014 12:31:21 -0700 (PDT) Cc: freebsd-toolchain@freebsd.org, freebsd-dtrace@freebsd.org, Andriy Gapon 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, 10 Sep 2014 19:31:29 -0000 Pedro Giffuni wrote this message on Wed, Sep 10, 2014 at 13:45 -0500: > Hi Andriy; > > Il giorno 10/set/2014, alle ore 12:23, Andriy Gapon ha scritto: > > > > > In my opinion WITH_CTF should imply -g in CFLAGS otherwise, as far as I can see, > > there is nothing to generate CTF data from. Forcing an end-user to remember to > > additionally pass -g is not nice. > > > > My understanding is that CTF is meant to be a debugging format independent of DWARF, > so it should be especially useful for the cases where there is no debugging information. Except that the CTF data is generated from the DWARF data... Hence why you need to compile w/ -g... ctfconvert uses the DWARF data to make the CTF data... > Just like Illumos, we haven?t really made much (or any) use of CTF outside the kernel > but now that is an option: > > http://dtrace.org/blogs/rm/2013/11/14/userland-ctf-in-dtrace/ > > > > Also, I think that we can always have -g in CTFFLAGS, because the stripping step > > takes care of the original DWARF data in any case. But I am not 100% sure about > > this. > > > > > What do you think? > > > BTW, it would be nice to see what we can take from the CTF/DDB GSoC [1]. I understand > the BSD-licensed CTF library has advanced greatly but still needs more work. Yeh, I need to look at this more too as there are somethings I would like to do w/ CTF that I can't because the library we have doesn't export all the data.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-toolchain@FreeBSD.ORG Thu Sep 11 15:07:33 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 2618CD0D; Thu, 11 Sep 2014 15:07:33 +0000 (UTC) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC6A59AC; Thu, 11 Sep 2014 15:07:32 +0000 (UTC) Received: from [96.232.17.88] (port=62402 helo=[10.189.221.171]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1XS5y6-0007oL-V1; Thu, 11 Sep 2014 11:07:31 -0400 From: "George Neville-Neil" To: "John-Mark Gurney" Subject: Re: WITH_CTF vs -g Date: Thu, 11 Sep 2014 11:07:16 -0400 Message-ID: <4227AECE-CD12-4C1E-B610-8BE81E6DBF0D@neville-neil.com> In-Reply-To: <20140910193120.GA82175@funkthat.com> References: <54108909.7050908@FreeBSD.org> <58B30723-19D6-40FA-97F7-206401C5D2A2@freebsd.org> <20140910193120.GA82175@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.8r4469) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com Cc: Pedro Giffuni , Andriy Gapon , freebsd-dtrace@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, 11 Sep 2014 15:07:33 -0000 On 10 Sep 2014, at 15:31, John-Mark Gurney wrote: > Pedro Giffuni wrote this message on Wed, Sep 10, 2014 at 13:45 -0500: >> Hi Andriy; >> >> Il giorno 10/set/2014, alle ore 12:23, Andriy Gapon >> ha scritto: >> >>> >>> In my opinion WITH_CTF should imply -g in CFLAGS otherwise, as far >>> as I can see, >>> there is nothing to generate CTF data from. Forcing an end-user to >>> remember to >>> additionally pass -g is not nice. >>> >> >> My understanding is that CTF is meant to be a debugging format >> independent of DWARF, >> so it should be especially useful for the cases where there is no >> debugging information. > > Except that the CTF data is generated from the DWARF data... Hence > why you need to compile w/ -g... ctfconvert uses the DWARF data to > make the CTF data... > >> Just like Illumos, we haven?t really made much (or any) use of CTF >> outside the kernel >> but now that is an option: >> >> http://dtrace.org/blogs/rm/2013/11/14/userland-ctf-in-dtrace/ >> >> >>> Also, I think that we can always have -g in CTFFLAGS, because the >>> stripping step >>> takes care of the original DWARF data in any case. But I am not >>> 100% sure about >>> this. >>> >> >>> What do you think? >> >> >> BTW, it would be nice to see what we can take from the CTF/DDB GSoC >> [1]. I understand >> the BSD-licensed CTF library has advanced greatly but still needs >> more work. > > Yeh, I need to look at this more too as there are somethings I would > like to do w/ CTF that I can't because the library we have doesn't > export all the data.. > And on the main topic, yes, one should imply the other. Go for it. Best, George From owner-freebsd-toolchain@FreeBSD.ORG Fri Sep 12 00:04:12 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 D134FAB for ; Fri, 12 Sep 2014 00:04:12 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 96FC4986 for ; Fri, 12 Sep 2014 00:04:12 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id s8C046xY083882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Sep 2014 17:04:06 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id s8C046ZF083881 for freebsd-toolchain@freebsd.org; Thu, 11 Sep 2014 17:04:06 -0700 (PDT) (envelope-from sgk) Date: Thu, 11 Sep 2014 17:04:06 -0700 From: Steve Kargl To: freebsd-toolchain@freebsd.org Subject: status of clang on sparc64? Message-ID: <20140912000406.GA83874@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) 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, 12 Sep 2014 00:04:12 -0000 What's the current status for running clang on sparc64? In particular, flame.freebsd.org is running 10.1-PRERELEASE compiled with gcc 4.2.1. Any chance that clanf can be made available on flame? -- Steve From owner-freebsd-toolchain@FreeBSD.ORG Fri Sep 12 15:01:49 2014 Return-Path: Delivered-To: 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 5B8D4619 for ; Fri, 12 Sep 2014 15:01:49 +0000 (UTC) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8416C15 for ; Fri, 12 Sep 2014 15:01:45 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id s18so1135665lam.14 for ; Fri, 12 Sep 2014 08:01:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=zhxIVw/6BD34/A1bihXs3ZFnbLptajNRNajE4CtETQo=; b=TcHX51TEOUdbkyrqPwyp1PEgDJhIL7cW1tYrt1JVIcw6044BRIsuVTunQ7XjdQrXZ9 r7lTTKMDU3keQxaqICu16j1qKNyTUwcCrr1NXa+x91ZWFrnRGsS8kIAmzFGwd6p/5uBp A/OwQjopm7mIyLAXkYYAkFJ00w/aaGxNF7fe3AwhgDy3yKlD1xdNrApZkNsqCK9b0R5O z1TlD+3/ch8ZJ0GnU7/E152uZ07L3b2Y5ttSTp7ehNfJqBOf9dXlF0vwxMphULF0lVZz vLK70/Us5RIl7BIQZ7K27CTHaMASfUNtLnLIq2muQNxQZH7muviCWRXRMvjvA1XRqmDc YOjQ== X-Gm-Message-State: ALoCoQmAIJHgTeOLJfeS/cfnBGWIPSYliPA8yptG51jUcqnxi5m2ek5bSgqkUfngWRAFyDHRi3XB X-Received: by 10.112.72.10 with SMTP id z10mr4190627lbu.87.1410534097947; Fri, 12 Sep 2014 08:01:37 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id j10sm1420000lbb.34.2014.09.12.08.01.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 08:01:37 -0700 (PDT) Message-ID: <54130AD0.8090103@freebsd.org> Date: Fri, 12 Sep 2014 19:01:36 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: toolchain@freebsd.org Subject: clang makes segfaulting code with -march=core2 on i386 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit 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, 12 Sep 2014 15:01:49 -0000 Hi. Please look at this thread. At the end the bug trigger found, since removing -march=core2 fix the thing. tijl@ suspects that clang produce 64bit instruction on i386 in that case. https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095466.html -- http://ache.vniz.net/ From owner-freebsd-toolchain@FreeBSD.ORG Fri Sep 12 17:20:53 2014 Return-Path: Delivered-To: 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 7650E606; Fri, 12 Sep 2014 17:20:53 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3234ADA8; Fri, 12 Sep 2014 17:20:52 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::5caf:c211:678:38f] (unknown [IPv6:2001:7b8:3a7:0:5caf:c211:678:38f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9300CB803; Fri, 12 Sep 2014 19:20:43 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_1629C272-01B4-42E6-B3C1-BD473DA8B037"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: clang makes segfaulting code with -march=core2 on i386 From: Dimitry Andric In-Reply-To: <54130AD0.8090103@freebsd.org> Date: Fri, 12 Sep 2014 19:20:31 +0200 Message-Id: References: <54130AD0.8090103@freebsd.org> To: Andrey Chernov X-Mailer: Apple Mail (2.1878.6) Cc: 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, 12 Sep 2014 17:20:53 -0000 --Apple-Mail=_1629C272-01B4-42E6-B3C1-BD473DA8B037 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Sep 2014, at 17:01, Andrey Chernov wrote: >=20 > Please look at this thread. At the end the bug trigger found, since > removing -march=3Dcore2 fix the thing. tijl@ suspects that clang = produce > 64bit instruction on i386 in that case. >=20 > = https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095466.ht= ml I just built lang/gcc successfully on 11.0-CURRENT and i386, using -march=3Dcore2, but saw no crashes at all. Is this limited specifically to stable/10? Do you also have a coredump of the crashed process? -Dimitry --Apple-Mail=_1629C272-01B4-42E6-B3C1-BD473DA8B037 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) iEYEARECAAYFAlQTK2QACgkQsF6jCi4glqOpIwCfSGuD+I4OQFHNAXMeUe72QgQ8 uhYAoOE5LbJ6YEOCy7XCwOHwipet3kzn =0oOg -----END PGP SIGNATURE----- --Apple-Mail=_1629C272-01B4-42E6-B3C1-BD473DA8B037-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Sep 12 18:40:51 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BC9371B for ; Fri, 12 Sep 2014 18:40:51 +0000 (UTC) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2D308BD for ; Fri, 12 Sep 2014 18:40:50 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id w7so1423837lbi.3 for ; Fri, 12 Sep 2014 11:40:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=1RVFiCNprlT30ACd2TDswrChklj+0DM/ttCQoDVTRBo=; b=L9qp9UtduvQCGKDNhLnNUgANO+udLhw+h9KlF9IWyIkxrewhbVTraHgb7jdCH4K134 Eiz7unZD9o9Z6IkkZOs4QTQDVt/MizQB0Yh/Vsl3tykmGQDf3aHgX9+KjMyLSTF8cGzz LQxXvJWqdFCo2qf9M5R9NmwmSl6mEEn4149H5oxBC8A8YxfgSshFvj4YEw3PdHl56bEL ervT+viecpGQXTkW/vlyVd7dsOFOZtXhOYoLbInK9l6N0N1ltVSW8/5E1CxWMnt9Qskn HfeJCC40fEUNUnYoOeO2CwSPWIBtXdWsds2XNraM419Txwrwt/SW5jhIwQqU2TSxtwXL jP3Q== X-Gm-Message-State: ALoCoQnX4+zQhpqnjXmLWJhrrNv5lAeq9LS0IS/tqSn7KBWDuEOeI/w4UTT1wGTNm8TpbMeh4wxO X-Received: by 10.152.22.200 with SMTP id g8mr10991381laf.1.1410547242774; Fri, 12 Sep 2014 11:40:42 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id n7sm1496295lag.47.2014.09.12.11.40.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 11:40:41 -0700 (PDT) Message-ID: <54133E1E.9030105@freebsd.org> Date: Fri, 12 Sep 2014 22:40:30 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang makes segfaulting code with -march=core2 on i386 References: <54130AD0.8090103@freebsd.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="40jNqBdE2JKbNOhIGpS39NI54HQlnEOrX" Cc: 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, 12 Sep 2014 18:40:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --40jNqBdE2JKbNOhIGpS39NI54HQlnEOrX Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 12.09.2014 21:20, Dimitry Andric wrote: > On 12 Sep 2014, at 17:01, Andrey Chernov wrote: >> >> Please look at this thread. At the end the bug trigger found, since >> removing -march=3Dcore2 fix the thing. tijl@ suspects that clang produ= ce >> 64bit instruction on i386 in that case. >> >> https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/09546= 6.html >=20 > I just built lang/gcc successfully on 11.0-CURRENT and i386, using > -march=3Dcore2, but saw no crashes at all. Is this limited specificall= y > to stable/10? Do you also have a coredump of the crashed process? >=20 > -Dimitry >=20 For all cases check in 'make config' that BOOTSTRAP is off, because it no= t fail when gcc bootstraps itself. To see correct error place set env MAKE_JOBS_UNSAFE=3Dyes because gcc try= to build some things in parallel and segfault can come in the middle of = other unrelated compilation. Not only lang/gcc segfaulting, but also lang/gcc48 and lang/gcc49 (last o= ne fails in stdc++ too but for different (first) file). xgcc does not dump core by default. I use -dH switch to force core dump r= unning the faulting command manually. Core was generated by `cc1plus'. Program terminated with signal 6, Aborted. (gdb) bt #0 0x28f4c307 in kill () from /lib/libc.so.7 #1 0x28f4c297 in raise () from /lib/libc.so.7 #2 0x28f4a8d6 in abort () from /lib/libc.so.7 #3 0x0892f138 in real_abort () #4 0x0892e7ac in diagnostic_action_after_output () #5 0x0892e4ca in diagnostic_report_diagnostic () #6 0x0892f106 in internal_error () #7 0x0853b17e in crash_signal () #8 0xbfbff004 in ?? () #9 0x0000000b in ?? () #10 0x00000001 in ?? () #11 0xbfbfab40 in ?? () #12 0x08d208d8 in ?? () #13 0x0853b140 in alloc_for_identifier_to_locale () #14 0x081f2a8c in gt_pch_nx_lang_tree_node () #15 0x081f1bd6 in gt_pch_nx_lang_tree_node () #16 0x081f26c1 in gt_pch_nx_lang_tree_node () #17 0x081f22ab in gt_pch_nx_lang_tree_node () #18 0x081f2260 in gt_pch_nx_lang_tree_node () #19 0x081f1e62 in gt_pch_nx_lang_tree_node () #20 0x081f271b in gt_pch_nx_lang_tree_node () #21 0x081f231d in gt_pch_nx_lang_tree_node () #22 0x081f4304 in gt_pch_nx_lang_type () #23 0x081f270c in gt_pch_nx_lang_tree_node () #24 0x081f1ba9 in gt_pch_nx_lang_tree_node () #25 0x081f226f in gt_pch_nx_lang_tree_node () #26 0x081f1ba9 in gt_pch_nx_lang_tree_node () #27 0x081f2a8c in gt_pch_nx_lang_tree_node () #28 0x081f42f5 in gt_pch_nx_lang_type () #29 0x081f270c in gt_pch_nx_lang_tree_node () #30 0x081f26fd in gt_pch_nx_lang_tree_node () #31 0x081f26ee in gt_pch_nx_lang_tree_node () #32 0x081f26d0 in gt_pch_nx_lang_tree_node () #33 0x081f26df in gt_pch_nx_lang_tree_node () #34 0x081f1ba9 in gt_pch_nx_lang_tree_node () #35 0x081f26c1 in gt_pch_nx_lang_tree_node () #36 0x081f2260 in gt_pch_nx_lang_tree_node () #37 0x081f2a8c in gt_pch_nx_lang_tree_node () #38 0x081f271b in gt_pch_nx_lang_tree_node () #39 0x081f1ff9 in gt_pch_nx_lang_tree_node () [rest stripped...] As you see, last meaningful info say something about "locale". If system = locale assumed here, I use ru_RU.KOI8-R. I try to check this thing with L= ANG=3DC later. I don't have -current & i386 combination, but I can try -current & x64 la= ter (with different -march). Instruction set may depends on CPU, I have "Core2 Duo E8400" which should= match -march=3Dcore2 in theory. For lang/gcc the bug starts on second stdc++ file compiling, related log = from the entering stdc++ directory: gmake[5]: Entering directory `/usr/ports/lang/gcc/work/build/i386-portbld= -freebsd10.1/libstdc++-v3' Making all in include gmake[6]: Entering directory `/usr/ports/lang/gcc/work/build/i386-portbld= -freebsd10.1/libstdc++-v3/include' mkdir -p ./i386-portbld-freebsd10.1/bits/stdc++.h.gch /usr/ports/lang/gcc/work/build/./gcc/xgcc -shared-libgcc -B/usr/ports/lan= g/gcc/work/build/./gcc -nostdinc++ -L/usr/ports/lang/gcc/work/build/i386-= portbld-freebsd10.1/libstdc++-v3/src -L/usr/ports/lang/gcc/work/build/i38= 6-portbld-freebsd10.1/libstdc++-v3/src/.libs -B/usr/local/i386-portbld-fr= eebsd10.1/bin/ -B/usr/local/i386-portbld-freebsd10.1/lib/ -isystem /usr/l= ocal/i386-portbld-freebsd10.1/include -isystem /usr/local/i386-portbld-fr= eebsd10.1/sys-include -x c++-header -nostdinc++ -g -O2 -pipe -march=3D= core2 -DLIBICONV_PLUG -fno-strict-aliasing -DLIBICONV_PLUG -I/usr/ports/= lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3/include/i386-po= rtbld-freebsd10.1 -I/usr/ports/lang/gcc/work/build/i386-portbld-freebsd10= =2E1/libstdc++-v3/include -I/usr/ports/lang/gcc/work/gcc-4.8.3/libstdc++-= v3/libsupc++ -O2 -g -std=3Dgnu++0x /usr/ports/lang/gcc/work/gcc-4.8.3/lib= stdc++-v3/include/precompiled/stdc++.h \ -o i386-portbld-freebsd10.1/bits/stdc++.h.gch/O2ggnu++0x.gch mkdir -p ./i386-portbld-freebsd10.1/bits/stdc++.h.gch /usr/ports/lang/gcc/work/build/./gcc/xgcc -shared-libgcc -B/usr/ports/lan= g/gcc/work/build/./gcc -nostdinc++ -L/usr/ports/lang/gcc/work/build/i386-= portbld-freebsd10.1/libstdc++-v3/src -L/usr/ports/lang/gcc/work/build/i38= 6-portbld-freebsd10.1/libstdc++-v3/src/.libs -B/usr/local/i386-portbld-fr= eebsd10.1/bin/ -B/usr/local/i386-portbld-freebsd10.1/lib/ -isystem /usr/l= ocal/i386-portbld-freebsd10.1/include -isystem /usr/local/i386-portbld-fr= eebsd10.1/sys-include -x c++-header -nostdinc++ -g -O2 -pipe -march=3D= core2 -DLIBICONV_PLUG -fno-strict-aliasing -DLIBICONV_PLUG -I/usr/ports/= lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3/include/i386-po= rtbld-freebsd10.1 -I/usr/ports/lang/gcc/work/build/i386-portbld-freebsd10= =2E1/libstdc++-v3/include -I/usr/ports/lang/gcc/work/gcc-4.8.3/libstdc++-= v3/libsupc++ -O2 -g /usr/ports/lang/gcc/work/gcc-4.8.3/libstdc++-v3/inclu= de/precompiled/stdc++.h -o i386-portbld-freebsd10.1/bits/stdc++.h.gch/O2g= =2Egch In file included from /usr/ports/lang/gcc/work/gcc-4.8.3/libstdc++-v3/inc= lude/precompiled/stdc++.h:94:0: /usr/ports/lang/gcc/work/build/i386-portbld-freebsd10.1/libstdc++-v3/incl= ude/valarray:1233:1: internal compiler error: Segmentation fault } // namespace ^ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gmake[6]: *** [i386-portbld-freebsd10.1/bits/stdc++.h.gch/O2g.gch] Error = 1 --=20 http://ache.vniz.net/ --40jNqBdE2JKbNOhIGpS39NI54HQlnEOrX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUEz4pAAoJEKUckv0MjfbK+gcH/jNpPVPZEuHJHZLlu6EdFcEI LAzsRN5r8R/1+AKyn1rtlOQn92n1mZCKFEN1XTGx/rM80daqnzFYNRpYWbbHoO/p VFMXrlXOmqGnZ08AzIqI7zBkbhZ+eAS8YZ6MQQZ3v9ad6oYJnigs0Gsj447+oDIM kR3skmenBSxBLCoRrRqz8nZ6j3AT3O62G8VoBbMd5N2d9b4kFF64fPGSAnIB20nv zycSFvsZo1W0FYftEMN/9vsvf40yDx+DixmZUWdbgvurNmvohyi/464CUJd62Tg1 /7ar5Ny18SqQ/SmywCPyY2GUceI5AeXDHyjq++hjjUC1kwvEnwr/Op8k3r7wHLM= =CMkN -----END PGP SIGNATURE----- --40jNqBdE2JKbNOhIGpS39NI54HQlnEOrX-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Sep 12 19:01:53 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DC11F for ; Fri, 12 Sep 2014 19:01:53 +0000 (UTC) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E354EB34 for ; Fri, 12 Sep 2014 19:01:52 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id ty20so1542206lab.9 for ; Fri, 12 Sep 2014 12:01:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=5/mgLNXUFMAe0/DdXBzCMLcK0GnY4/Xo21FPnrJA2No=; b=kxBQEIEcGPnuinek9qPgl6OZqJMVViwP+coQDu+0jJQ7YUr9IC7ds4v+4jztfti0CO a7/awagKtxzlyxQmuOtPFu9Uv74UCBZFw/CTzElUOjIvtunNirX6YNyyeC0xgPw5hZ/O JS7R4IGi8U3PVORykUkvgpSY4EZ8flMgLTLRMv6j/xm5vN/g3bQROAi0oTYI0u5OkJcL d+Kp8diSZt5hRbHiNrOujBFNFLyHLaJC2RxJydxA74rBgsI0+w6b77/ZesqRqzUSW7MY xcqwo5sU2Ri2T41WzUzrUi+fIcdo4KJNYmQCQ6meRwbwkNimej4WWfvvgZlKdlXKK8op ualw== X-Gm-Message-State: ALoCoQk5vYa3EHozdwQ9y/m9TaCPtHsfSJ1G6TMw23eGjChyajttND99AmAdBOQZviYgkY+Ph6vp X-Received: by 10.112.163.170 with SMTP id yj10mr7471629lbb.88.1410548510071; Fri, 12 Sep 2014 12:01:50 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id w4sm1518586laj.26.2014.09.12.12.01.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 12:01:49 -0700 (PDT) Message-ID: <5413431C.3070408@freebsd.org> Date: Fri, 12 Sep 2014 23:01:48 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang makes segfaulting code with -march=core2 on i386 References: <54130AD0.8090103@freebsd.org> <54133E1E.9030105@freebsd.org> In-Reply-To: <54133E1E.9030105@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="e1l2NclPa5qGCRDJ2S0Ikrea9lnKlVb2e" Cc: 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, 12 Sep 2014 19:01:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --e1l2NclPa5qGCRDJ2S0Ikrea9lnKlVb2e Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 12.09.2014 22:40, Andrey Chernov wrote: > As you see, last meaningful info say something about "locale". If syste= m locale assumed here, I use ru_RU.KOI8-R. I try to check this thing with= LANG=3DC later. Does not help. The same fault with LANG=3DC too. --=20 http://ache.vniz.net/ --e1l2NclPa5qGCRDJ2S0Ikrea9lnKlVb2e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUE0McAAoJEKUckv0MjfbKE1IIAKfi+Im7wH4Np3olkSBx17uE Xp4YSEwjSYkqqJhVE/yo+q8fosOHFWj3W2X1KRxVoiRujdaxwkrOs25rW++n+kfP 2oOCGBfclB8cOqYTJ9ErzoEWDdsl4LbdS+RQ7tw8gmJpSdpwgajYwvPKnOtFvnoD F3Auvs4Lmqwav38wGkGgTWGPY4ZRR2WGcODBo8MHDwSPYi5ZO/miMz0kJjbdAzaQ gwqj5HMGJK/ZNX2L6rE3cKssh4QzbGWk8vyryzWqT7oLxypg+tIGYn8m3OfO+hQl e+xozwLKXecHTHQAd5despCA+zpBUCrBL7E7IE3vfcUB7QQduTb3z4C+2ZTp2n4= =LpHL -----END PGP SIGNATURE----- --e1l2NclPa5qGCRDJ2S0Ikrea9lnKlVb2e-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Sep 12 19:11:03 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 856061EF for ; Fri, 12 Sep 2014 19:11:03 +0000 (UTC) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05C2EC33 for ; Fri, 12 Sep 2014 19:11:02 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id pv20so1555788lab.22 for ; Fri, 12 Sep 2014 12:10:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=A6qYU4GeSUZAQTBPL0kJ0t0GExpc6g5amNG4wXVciWU=; b=bY2Lm8VXGgQFPGdghNZsjRGUz1aSwhMUPwnJ/pPZniqFqR6BynFmCKSF42JGSXnIul rUgObsXlxHXRgHJxouCnW6ZTNZuAlDuPCQ2ds2Fw7LB7TiiNZRE55B2GK2Mnw75U3Tst R6OuujX6hZrhlOl1lI7CFIGNXAngmhFMbv9VaG4oX17ao6cHNMzFVMjTxE7HnC/KCvGQ RxqYyl7mC3J2sAGFLCG+YEn20Lx54RdLmhEnek5xRtIQEcSmZaBVKcftqHuYp+thW9vD nD6RfJqDI4IFbRgtpqlRImqK4Yw1mUknAGA6C0adrXqRwjUeuUA3xcoL7tQu6s7luqi/ 7DiQ== X-Gm-Message-State: ALoCoQnRz+o/Ckvy9ZLKbm+roFMGLyiMINuOPSNuqqp8YguFNj+IcYBbLQTCdEooLEeRmg0H+lyk X-Received: by 10.152.26.133 with SMTP id l5mr11462626lag.4.1410549055477; Fri, 12 Sep 2014 12:10:55 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id m5sm1519815laa.37.2014.09.12.12.10.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 12:10:54 -0700 (PDT) Message-ID: <5413453E.9070800@freebsd.org> Date: Fri, 12 Sep 2014 23:10:54 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang makes segfaulting code with -march=core2 on i386 References: <54130AD0.8090103@freebsd.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OoOGPlqK97fOriqQdh8n7WWtkqXwnlqvA" Cc: 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, 12 Sep 2014 19:11:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OoOGPlqK97fOriqQdh8n7WWtkqXwnlqvA Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 12.09.2014 21:20, Dimitry Andric wrote: > Do you also have a coredump of the crashed process? Core file bzipped: http://rghost.ru/57982669 --=20 http://ache.vniz.net/ --OoOGPlqK97fOriqQdh8n7WWtkqXwnlqvA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUE0U+AAoJEKUckv0MjfbKX/kH/0Mx8R172CAvcu2YGT7VfoCN i0v9BX30lWmmP0yav6UeZrYcqqSeqVRnttIUGfxXnYZU+2wrYYLko6NJ9PlETvHy AC7mbgI3zLF4vPbAj3jP6oTvhXklm9wAD+uOmCH4ZCBlDUCzewPbN8LLT83UKsyj TZRcBQSNnvWDr4ZzYiwDSRvxqa9L/TypoYdyY7cYKIAp4NYqKng1Hz9udIOEHoD+ 9LtYPFWUEl9kz1/jyo/L2fkCWe7TNekP0uwcf9wsrLkWeSqcUmO1sRD+n3TYowDy fDpCwXz+Glw6up/HWYBgTgqF5WpCSMOh6KbhBjaDXkkT+e5sF8KovyH7iGzD4pw= =ZDN2 -----END PGP SIGNATURE----- --OoOGPlqK97fOriqQdh8n7WWtkqXwnlqvA-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Sep 12 20:51:22 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD812D58 for ; Fri, 12 Sep 2014 20:51:22 +0000 (UTC) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F204824 for ; Fri, 12 Sep 2014 20:51:21 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id w7so1607032lbi.32 for ; Fri, 12 Sep 2014 13:51:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=OekJ0OLiWldGldHh1swKwKEfmn6XaGQu9mTy4gFsZmo=; b=R6M8V2CZYr5HpRKfG7SmaF9QnlrHMuRcmrJ1Z3Rf15a/Q1QjdNaKk/50ybh6Zm14Lu 6W09wyu7R8rE7COHVfNp65kfU3pwobSn6vzY5aEKmhJD+HP+jX863toNndiWHi/O4NNW Ci2EWNsxP6JAKixDYtcOE5AZbk2gxZmNR9vaU2plFoa56ZHx+B11CkWz9xT0BZCGkvIX mez5gUfnXxIuVXCCmCo/fQf4Ip3xokSen6XGUfV85T+9OZTD/C4E+s8Faq5xRjAp722V pGqJLnk7haYpE/0qg4K75fdZqefBN3Wc/A+KxuhIFJP9GO8bliRO+pOKNZA6vyAvkFOf 16UQ== X-Gm-Message-State: ALoCoQnbzZU9q2KwrWAgAq7SRR4zyrdHHZK2OU3GD0uJg8eXMxmuWgkul0unLZ8blOZv0GylV6i5 X-Received: by 10.112.54.169 with SMTP id k9mr11327037lbp.32.1410554670437; Fri, 12 Sep 2014 13:44:30 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id x5sm1586009lad.30.2014.09.12.13.44.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 13:44:29 -0700 (PDT) Message-ID: <54135B24.5040905@freebsd.org> Date: Sat, 13 Sep 2014 00:44:20 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang makes segfaulting code with -march=core2 on i386 References: <54130AD0.8090103@freebsd.org> <54133E1E.9030105@freebsd.org> In-Reply-To: <54133E1E.9030105@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BAi4K9lX248altNKGLjLg2AhES1J7jsuB" Cc: 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, 12 Sep 2014 20:51:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BAi4K9lX248altNKGLjLg2AhES1J7jsuB Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 12.09.2014 22:40, Andrey Chernov wrote: > I don't have -current & i386 combination, but I can try -current & x64 = later (with different -march). It works on -current, amd64, -march=3Dcore2. So it either -stable or i386-specific clang bug. --=20 http://ache.vniz.net/ --BAi4K9lX248altNKGLjLg2AhES1J7jsuB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUE1ssAAoJEKUckv0MjfbKHtEH/0q/uz2rw79Xwjr5ORXjQ6A/ 2iHrhuU1oQBAqgIsU9zX4/oN6GbWr0+WdOW8zrkdrZVqvdacJYEnQVADlPFa+ABK fOaauNcZHhP7Y9wqZUA4pQbhhwZRvQxjvQfUeVBn9hDEjXyzXkgIgAIWsN93RbE8 UwgnB1AXUQYHsJPG6+8Hfq4dR4aOPw1cZaFsUp8BfQ/Z+DqGXNn4+nPOsAK9aP76 nrbzFYB83Qmz0yn0MzJvnDpruR0xYqyyACnilkI+w6ubTS+KADoY82n8Ywcu7lTE siQRLlM2OcsUPkR8wevzomUrO6Af3u0dLyoEWf1kcOSTiKLztUs014RCeyNyF9w= =0EtD -----END PGP SIGNATURE----- --BAi4K9lX248altNKGLjLg2AhES1J7jsuB-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Sep 12 20:52:31 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE538E6B for ; Fri, 12 Sep 2014 20:52:31 +0000 (UTC) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EAAF837 for ; Fri, 12 Sep 2014 20:52:31 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id b8so1660797lan.39 for ; Fri, 12 Sep 2014 13:52:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=rjMHTCz+szQZBMj2a6ezOd+PdelS4wsQBlLBGs4QVZk=; b=CuzRqcSdTlNIyLl7DG+wkYshbAmUx5CSTU7huc9RzveqsLlXol1eZpQ4WHPOhmC9mz xxlWIJ4rI3bo0cDO+dGeS5e3cbtjmvLHpG10C8xV9XBKs2oIux4aCjS+rCSqm2pasxh5 ZdlyaEACVlJY7i+ffrMjyQvsbohPkBhsPEQaXhuh9NQMFxejdw2cFCzZBnhts7SuOH1c vZxldcVF8ktXl4t1uf6RCKK8/kcvqHC0gcwuGY9t1dbK8zE9nAjFnioN9wZlf04A2HGj vFFzfWJfKodpjWSJF/8UyGM6HbF86zn2btFrEuqt4yBD8WfQ34QHJHyAeB28YeSbGx0O dFhg== X-Gm-Message-State: ALoCoQm3LN8DzK5ohlWng0ukQ4y3Ev7V14R87xA6n8n3zEl7iflaCLxwLteZulagymtwh1ihEUb/ X-Received: by 10.153.4.39 with SMTP id cb7mr11574934lad.19.1410555148861; Fri, 12 Sep 2014 13:52:28 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id zc10sm1675505lbb.40.2014.09.12.13.52.27 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 13:52:28 -0700 (PDT) Message-ID: <54135D0B.7060701@freebsd.org> Date: Sat, 13 Sep 2014 00:52:27 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang makes segfaulting code with -march=core2 on i386 References: <54130AD0.8090103@freebsd.org> <54133E1E.9030105@freebsd.org> <54135B24.5040905@freebsd.org> In-Reply-To: <54135B24.5040905@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AArRqmorP2kuRJ3EGvarkjRlEMHsl0vEH" Cc: 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, 12 Sep 2014 20:52:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AArRqmorP2kuRJ3EGvarkjRlEMHsl0vEH Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 13.09.2014 0:44, Andrey Chernov wrote: > On 12.09.2014 22:40, Andrey Chernov wrote: >> I don't have -current & i386 combination, but I can try -current & x64= later (with different -march). >=20 > It works on -current, amd64, -march=3Dcore2. So it either -stable or > i386-specific clang bug. >=20 I forget to say that real CPU on -current tested is not the same as for failing i386: QuadCore Intel Core i7-3820 --=20 http://ache.vniz.net/ --AArRqmorP2kuRJ3EGvarkjRlEMHsl0vEH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUE10LAAoJEKUckv0MjfbK/xoH/2AnjfsqF8tw9lS1wyMZyLDL +3lu2jxBYt2Ft6DumEEh37XBhMor7ayYDq4x/TrQ/UMhIQqukdYERJ7sTU6iJ6tE njzEHPXtrD1Sum/IPoLIBcvwvbwMXvelh4ujGii40Q2BiW8i4tmL0okfB8YhThBl 0h1vUv719cds3htlzoILbFImRPQF1Xp6CQljx40FEy/WpHb0zn+PQDom0gQDJkMc /hPqaL/h2SSkXSLqvX5K9tW/bTP1wo//JNDPyaUYiILdod2l97IBMsF2e9jEQ1Is 1i88nVzZO++mxPMwVPcLyt8Xjk+p0quD41xQPlCZEpuh1BebROFfvO/vP5uAJQo= =bVbf -----END PGP SIGNATURE----- --AArRqmorP2kuRJ3EGvarkjRlEMHsl0vEH-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 13 08:29:40 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 49F912E5 for ; Sat, 13 Sep 2014 08:29:40 +0000 (UTC) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 08EA1C9B for ; Sat, 13 Sep 2014 08:29:39 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id EA05D1D95D14; Sat, 13 Sep 2014 10:23:22 +0200 (CEST) Date: Sat, 13 Sep 2014 10:23:22 +0200 From: Roman Divacky To: Steve Kargl Subject: Re: status of clang on sparc64? Message-ID: <20140913082322.GA76218@vlakno.cz> References: <20140912000406.GA83874@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140912000406.GA83874@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Sat, 13 Sep 2014 08:29:40 -0000 On Thu, Sep 11, 2014 at 05:04:06PM -0700, Steve Kargl wrote: > What's the current status for running clang on sparc64? Last time we played with this (february?) it was able to compile a seemingly working world. So I guess it's not that terribly broken. We didnt test that much stuff though. > In particular, flame.freebsd.org is running 10.1-PRERELEASE > compiled with gcc 4.2.1. Any chance that clanf can be > made available on flame? I think your best bet is to compile it on flame yourself or crosscompile world for sparc64 and use it on flame. Roman From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 13 16:45:40 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 624EC1FC; Sat, 13 Sep 2014 16:45:40 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D6F99D28; Sat, 13 Sep 2014 16:45:39 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b12a:a821:10d9:98f3] (unknown [IPv6:2001:7b8:3a7:0:b12a:a821:10d9:98f3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 64D88B803; Sat, 13 Sep 2014 18:45:35 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_FC22A853-BF0E-4EA7-BF1F-26A338126E0C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: clang makes segfaulting code with -march=core2 on i386 From: Dimitry Andric In-Reply-To: <54135D0B.7060701@freebsd.org> Date: Sat, 13 Sep 2014 18:45:26 +0200 Message-Id: <6FDF432B-8245-4BC7-952B-DFFEEA106D6F@FreeBSD.org> References: <54130AD0.8090103@freebsd.org> <54133E1E.9030105@freebsd.org> <54135B24.5040905@freebsd.org> <54135D0B.7060701@freebsd.org> To: Andrey Chernov X-Mailer: Apple Mail (2.1878.6) Cc: 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, 13 Sep 2014 16:45:40 -0000 --Apple-Mail=_FC22A853-BF0E-4EA7-BF1F-26A338126E0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=koi8-r On 12 Sep 2014, at 22:52, Andrey Chernov wrote: > On 13.09.2014 0:44, Andrey Chernov wrote: >> On 12.09.2014 22:40, Andrey Chernov wrote: >>> I don't have -current & i386 combination, but I can try -current & = x64 later (with different -march). >>=20 >> It works on -current, amd64, -march=3Dcore2. So it either -stable or >> i386-specific clang bug. >>=20 >=20 > I forget to say that real CPU on -current tested is not the same as = for > failing i386: QuadCore Intel Core i7-3820 After some massaging of gcc's source to disable its built-in segfault handlers, I get this backtrace: Program received signal SIGSEGV, Segmentation fault. find_parameter_packs_r (tp=3D0x2c3212fc, walk_subtrees=3D0xbfbfda60, = data=3D0xbfbfdb58) at .././../gcc-4.8.3/gcc/cp/pt.c:3063 3063 if (TYPE_P (t) (gdb) bt #0 find_parameter_packs_r (tp=3D0x2c3212fc, walk_subtrees=3D0xbfbfda60, = data=3D0xbfbfdb58) at .././../gcc-4.8.3/gcc/cp/pt.c:3063 #1 0x086a111c in walk_tree_1 (tp=3D, func=3D, data=3D, pset=3D0x295e00a0, lh=3D) = at .././../gcc-4.8.3/gcc/tree.c:10700 #2 0x086a15f6 in walk_tree_1 (tp=3D, func=3D, data=3D, pset=3D0x295e00a0, lh=3D) = at .././../gcc-4.8.3/gcc/tree.c:10954 #3 0x086a1555 in walk_tree_1 (tp=3D, func=3D, data=3D, pset=3D, lh=3D) at .././../gcc-4.8.3/gcc/tree.c:10747 #4 0x081ed0ef in cp_walk_subtrees (tp=3D0xbfbfdb68, = walk_subtrees_p=3D0x29401674, func=3D, data=3D, pset=3D) at .././../gcc-4.8.3/gcc/cp/tree.c:3522 #5 0x086a118c in walk_tree_1 (tp=3D, func=3D, data=3D, pset=3D, lh=3D) at .././../gcc-4.8.3/gcc/tree.c:10723 #6 0x0813b6fc in check_for_bare_parameter_packs (t=3D0x2c388514) at = .././../gcc-4.8.3/gcc/cp/pt.c:3357 #7 0x081c4707 in check_return_expr (retval=3D0x2c388514, = no_warning=3D) at .././../gcc-4.8.3/gcc/cp/typeck.c:8156 #8 0x081da7b9 in finish_return_stmt (expr=3D0x2c388514) at = .././../gcc-4.8.3/gcc/cp/semantics.c:793 #9 0x0819a799 in cp_parser_jump_statement (parser=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:10150 #10 cp_parser_statement (parser=3D0x298ea1c0, in_statement_expr=3D0x0, = in_compound=3D, if_p=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:8877 #11 0x081990c8 in cp_parser_statement_seq_opt (parser=3D0x298ea1c0, = in_statement_expr=3D0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:9241 #12 0x08198f5f in cp_parser_compound_statement (parser=3D, in_statement_expr=3D, in_try=3D, = function_body=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:9195 #13 0x0819dd96 in cp_parser_implicitly_scoped_statement = (parser=3D, if_p=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:10237 #14 0x0819a8e4 in cp_parser_selection_statement (parser=3D0x298ea1c0, = if_p=3D0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:9347 #15 cp_parser_statement (parser=3D0x298ea1c0, in_statement_expr=3D0x0, = in_compound=3D, if_p=3D0x0) at = .././../gcc-4.8.3/gcc/cp/parser.c:8864 #16 0x0819ddbb in cp_parser_implicitly_scoped_statement = (parser=3D, if_p=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:10244 #17 0x0819a8e4 in cp_parser_selection_statement (parser=3D0x298ea1c0, = if_p=3D0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:9347 #18 cp_parser_statement (parser=3D0x298ea1c0, in_statement_expr=3D0x0, = in_compound=3D, if_p=3D0x0) at = .././../gcc-4.8.3/gcc/cp/parser.c:8864 #19 0x081990c8 in cp_parser_statement_seq_opt (parser=3D0x298ea1c0, = in_statement_expr=3D0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:9241 #20 0x0819dbfe in cp_parser_already_scoped_statement (parser=3D0x298ea1c0)= at .././../gcc-4.8.3/gcc/cp/parser.c:10273 #21 0x0819a045 in cp_parser_iteration_statement (parser=3D) at .././../gcc-4.8.3/gcc/cp/parser.c:9938 #22 cp_parser_statement (parser=3D0x298ea1c0, in_statement_expr=3D0x0, = in_compound=3D, if_p=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:8870 #23 0x081990c8 in cp_parser_statement_seq_opt (parser=3D0x298ea1c0, = in_statement_expr=3D0x0) at .././../gcc-4.8.3/gcc/cp/parser.c:9241 #24 0x08198f5f in cp_parser_compound_statement (parser=3D, in_statement_expr=3D, in_try=3D, = function_body=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:9195 #25 0x08198e33 in cp_parser_function_body (parser=3D, = parser=3D, in_function_try_block=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:17816 #26 cp_parser_ctor_initializer_opt_and_function_body (parser=3D0x298ea1c0,= in_function_try_block=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:17852 #27 0x08198a14 in cp_parser_function_definition_after_declarator = (parser=3D0x298ea1c0, inline_p=3Dfalse) at = .././../gcc-4.8.3/gcc/cp/parser.c:21831 #28 0x08183dcb in = cp_parser_function_definition_from_specifiers_and_declarator = (parser=3D, decl_specifiers=3D, = attributes=3D, declarator=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:21752 #29 cp_parser_init_declarator (parser=3D0x298ea1c0, = decl_specifiers=3D, checks=3D, = function_definition_allowed_p=3D, member_p=3D, declares_class_or_enum=3D, = function_definition_p=3D, maybe_range_for_decl=3D) at .././../gcc-4.8.3/gcc/cp/parser.c:15905 #30 0x081abc32 in cp_parser_single_declaration (parser=3D0x298ea1c0, = checks=3D0x0, member_p=3D, = explicit_specialization_p=3Dfalse, friend_p=3D) at = .././../gcc-4.8.3/gcc/cp/parser.c:22127 #31 0x081ab137 in cp_parser_template_declaration_after_export = (parser=3D0x298ea1c0, member_p=3Dfalse) at = .././../gcc-4.8.3/gcc/cp/parser.c:21941 #32 0x0817d57e in cp_parser_template_declaration (parser=3D0x298ea1c0, = member_p=3Dfalse) at .././../gcc-4.8.3/gcc/cp/parser.c:12226 #33 cp_parser_declaration (parser=3D0x298ea1c0) at = .././../gcc-4.8.3/gcc/cp/parser.c:10404 #34 0x0817b387 in cp_parser_declaration_seq_opt (parser=3D0x298ea1c0) at = .././../gcc-4.8.3/gcc/cp/parser.c:10334 #35 0x0817e3a7 in cp_parser_namespace_body (parser=3D0x298ea1c0) at = .././../gcc-4.8.3/gcc/cp/parser.c:15136 #36 cp_parser_namespace_definition (parser=3D0x298ea1c0) at = .././../gcc-4.8.3/gcc/cp/parser.c:15117 #37 0x0817d4f8 in cp_parser_declaration (parser=3D0x298ea1c0) at = .././../gcc-4.8.3/gcc/cp/parser.c:10432 #38 0x0817b387 in cp_parser_declaration_seq_opt (parser=3D0x298ea1c0) at = .././../gcc-4.8.3/gcc/cp/parser.c:10334 #39 0x0817a4b2 in cp_parser_translation_unit (parser=3D) = at .././../gcc-4.8.3/gcc/cp/parser.c:3813 #40 c_parse_file () at .././../gcc-4.8.3/gcc/cp/parser.c:28334 #41 0x0824a304 in c_common_parse_file () at = .././../gcc-4.8.3/gcc/c-family/c-opts.c:1052 #42 0x0853aca8 in compile_file () at .././../gcc-4.8.3/gcc/toplev.c:547 #43 0x0853aac3 in do_compile () at .././../gcc-4.8.3/gcc/toplev.c:1870 #44 toplev_main (argc=3D43, argv=3D0xbfbfe1ec) at = .././../gcc-4.8.3/gcc/toplev.c:1946 #45 0x0810e6aa in _start1 () #46 0x0810e568 in _start () (gdb) list 3058 struct find_parameter_pack_data* ppd =3D=20 3059 (struct find_parameter_pack_data*)data; 3060 bool parameter_pack_p =3D false; 3061=09 3062 /* Handle type aliases/typedefs. */ 3063 if (TYPE_P (t) 3064 && TYPE_NAME (t) 3065 && TREE_CODE (TYPE_NAME (t)) =3D=3D TYPE_DECL 3066 && TYPE_DECL_ALIAS_P (TYPE_NAME (t))) 3067 { (gdb) print t $1 =3D (tree) 0x8 (gdb) print tp $2 =3D (tree *) 0x2c3212fc (gdb) print *tp $3 =3D (tree) 0x8 I think it's most likely this is some type of undefined behavior in gcc, which leads to randomly corrupted tree values. Of course, it could also be a clang bug, but I don't see any "64-bit" instructions in there at all. This needs to be investigated further, but it's very hard to understand what is going on the guts of gcc's parser. Let alone to reduce this to some sort of reproducible test case. -Dimitry --Apple-Mail=_FC22A853-BF0E-4EA7-BF1F-26A338126E0C 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) iEYEARECAAYFAlQUdKoACgkQsF6jCi4glqN1ZACgoVkPGvB9I3F5vgg8fUqNKhBF pS0Ani61mdp+gvmiEt7dcq6F9onNEcWh =fbTu -----END PGP SIGNATURE----- --Apple-Mail=_FC22A853-BF0E-4EA7-BF1F-26A338126E0C-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 13 16:51:43 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 0F9474E8 for ; Sat, 13 Sep 2014 16:51:43 +0000 (UTC) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask.apl.washington.edu", Issuer "troutmask.apl.washington.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C8502E04 for ; Sat, 13 Sep 2014 16:51:42 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.9/8.14.9) with ESMTP id s8DGpZpg001593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Sep 2014 09:51:35 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.9/8.14.9/Submit) id s8DGpZ2e001592; Sat, 13 Sep 2014 09:51:35 -0700 (PDT) (envelope-from sgk) Date: Sat, 13 Sep 2014 09:51:35 -0700 From: Steve Kargl To: Roman Divacky Subject: Re: status of clang on sparc64? Message-ID: <20140913165135.GA1572@troutmask.apl.washington.edu> References: <20140912000406.GA83874@troutmask.apl.washington.edu> <20140913082322.GA76218@vlakno.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140913082322.GA76218@vlakno.cz> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Sat, 13 Sep 2014 16:51:43 -0000 On Sat, Sep 13, 2014 at 10:23:22AM +0200, Roman Divacky wrote: > On Thu, Sep 11, 2014 at 05:04:06PM -0700, Steve Kargl wrote: > > What's the current status for running clang on sparc64? > > Last time we played with this (february?) it was able to compile > a seemingly working world. So I guess it's not that terribly broken. > > We didnt test that much stuff though. > > > In particular, flame.freebsd.org is running 10.1-PRERELEASE > > compiled with gcc 4.2.1. Any chance that clanf can be > > made available on flame? > > I think your best bet is to compile it on flame yourself or crosscompile > world for sparc64 and use it on flame. > Was your testing with the in-tree llvm/clang or upstream? Should I try to compile lang/clang35 or lang/clang-devel? My main (and perhaps only) interest is to test the ld128 math libraries functions that I've been writing. -- Steve From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 13 16:53:41 2014 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97339581 for ; Sat, 13 Sep 2014 16:53:41 +0000 (UTC) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 56264E2D for ; Sat, 13 Sep 2014 16:53:40 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 972F91D95716; Sat, 13 Sep 2014 18:53:32 +0200 (CEST) Date: Sat, 13 Sep 2014 18:53:32 +0200 From: Roman Divacky To: Steve Kargl Subject: Re: status of clang on sparc64? Message-ID: <20140913165332.GA98677@vlakno.cz> References: <20140912000406.GA83874@troutmask.apl.washington.edu> <20140913082322.GA76218@vlakno.cz> <20140913165135.GA1572@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140913165135.GA1572@troutmask.apl.washington.edu> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Sat, 13 Sep 2014 16:53:41 -0000 On Sat, Sep 13, 2014 at 09:51:35AM -0700, Steve Kargl wrote: > On Sat, Sep 13, 2014 at 10:23:22AM +0200, Roman Divacky wrote: > > On Thu, Sep 11, 2014 at 05:04:06PM -0700, Steve Kargl wrote: > > > What's the current status for running clang on sparc64? > > > > Last time we played with this (february?) it was able to compile > > a seemingly working world. So I guess it's not that terribly broken. > > > > We didnt test that much stuff though. > > > > > In particular, flame.freebsd.org is running 10.1-PRERELEASE > > > compiled with gcc 4.2.1. Any chance that clanf can be > > > made available on flame? > > > > I think your best bet is to compile it on flame yourself or crosscompile > > world for sparc64 and use it on flame. > > > > Was your testing with the in-tree llvm/clang or upstream? > Should I try to compile lang/clang35 or lang/clang-devel? > > My main (and perhaps only) interest is to test the ld128 > math libraries functions that I've been writing. In-tree clang is ok. We have backported all the relevant patches. Roman From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 13 18:01:03 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75071B1A for ; Sat, 13 Sep 2014 18:01:03 +0000 (UTC) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E735A669 for ; Sat, 13 Sep 2014 18:01:02 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id l4so2523887lbv.22 for ; Sat, 13 Sep 2014 11:01:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=hxPA66QXN17RUmPgd8KisxOlfOdeuu5Ph60kniTIxNA=; b=ZdNb8eD4/MxCGiZX1gy0kX56m1BJnzE1G4GU5DsFaUu61n5zIVuLniP5HzEhk7UjV/ 0ZcOZTqsJm+agszSyM2GKWATeVsgvz58JhXEQMJ5iqTGc85DhJxS507e9ksnHGUFL7CI egBhUjVHN8oUcBjUuDz2bz8GajkenD5cnV/PDAuDbOXeX5e55eSEhbnO8KU71v/7Ezub lgI6+paa9kqO1sp6pNwVLQuXAxhs2b79zH06pAoBR4beZD6qt5cISmOR1OvLVld6Ly+u yMQmF5py69IdZexGJMydDtardBdLlsQpaYA67uJG+bhjeM0cZSWIZZNbP1SHKE0PkFpe n+kA== X-Gm-Message-State: ALoCoQkXadfaL05Oxqj+8KEJ4Myfu6FqvCNhughVJriW9uyV6YRz/wxGjLaDU4XA9aULCVN9BR9B X-Received: by 10.152.9.200 with SMTP id c8mr17684768lab.76.1410631260075; Sat, 13 Sep 2014 11:01:00 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id zt1sm2534324lbc.31.2014.09.13.11.00.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Sep 2014 11:00:59 -0700 (PDT) Message-ID: <5414865A.6030101@freebsd.org> Date: Sat, 13 Sep 2014 22:00:58 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang makes segfaulting code with -march=core2 on i386 References: <54130AD0.8090103@freebsd.org> <54133E1E.9030105@freebsd.org> <54135B24.5040905@freebsd.org> <54135D0B.7060701@freebsd.org> <6FDF432B-8245-4BC7-952B-DFFEEA106D6F@FreeBSD.org> In-Reply-To: <6FDF432B-8245-4BC7-952B-DFFEEA106D6F@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n7FhQD5bMaQ4uuo5HlHcbDp2tc4Xu1rTK" Cc: 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, 13 Sep 2014 18:01:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --n7FhQD5bMaQ4uuo5HlHcbDp2tc4Xu1rTK Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 13.09.2014 20:45, Dimitry Andric wrote: > After some massaging of gcc's source to disable its built-in segfault > handlers, I get this backtrace: Do you get this with my core or finally able to reproduce it by yourself?= > I think it's most likely this is some type of undefined behavior in gcc= , > which leads to randomly corrupted tree values. Of course, it could als= o > be a clang bug, but I don't see any "64-bit" instructions in there at > all. >=20 > This needs to be investigated further, but it's very hard to understand= > what is going on the guts of gcc's parser. Let alone to reduce this to= > some sort of reproducible test case. By first glance I see a lots of things. It is known that in edge cases gcc preserves more "unused" values than clang. It can be the possible case. I'll try to lower -O level preserving -march=3Dcore2 and see. --=20 http://ache.vniz.net/ --n7FhQD5bMaQ4uuo5HlHcbDp2tc4Xu1rTK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUFIZaAAoJEKUckv0MjfbKvDcH/jJIOeC+TalKXt2DFGkKvW3x T9dMEGXISSdt4y5z9/EdKCDtHY5YPu0QOjCaSHLRRfOYiW2cpKoUdw7rjzRyq4Sm q+Ys97X16ttCUaaeh0EpT1oKEyh7OSvv/MA77zAPO/ep3fER6pM7BZmhj5IxZ8N7 x8Zco6birUT7GoXuiRPIExXJnz6ceUou2kF6bEiuTMiV3dU/c18v6TK2O1WMz5hm ZdDY6DoWbNcQi5y13ESs/iTFcxyRut/A0WwllbLfyVXcXi6mmYBPclKgzj9ILHp0 4KegthiD7FWYZ88SPohltLdY57CyY9T0eiPoTsxNGGb4f3BUWGD79ccaWm52neg= =xzzE -----END PGP SIGNATURE----- --n7FhQD5bMaQ4uuo5HlHcbDp2tc4Xu1rTK-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 13 18:30:46 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05B0F816; Sat, 13 Sep 2014 18:30:46 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "tensor.andric.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 678369FB; Sat, 13 Sep 2014 18:30:45 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::b12a:a821:10d9:98f3] (unknown [IPv6:2001:7b8:3a7:0:b12a:a821:10d9:98f3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1045BB803; Sat, 13 Sep 2014 20:30:38 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_FD0B8BBC-223F-4B45-8F17-6B995FBDE8C9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: clang makes segfaulting code with -march=core2 on i386 From: Dimitry Andric In-Reply-To: <5414865A.6030101@freebsd.org> Date: Sat, 13 Sep 2014 20:30:12 +0200 Message-Id: References: <54130AD0.8090103@freebsd.org> <54133E1E.9030105@freebsd.org> <54135B24.5040905@freebsd.org> <54135D0B.7060701@freebsd.org> <6FDF432B-8245-4BC7-952B-DFFEEA106D6F@FreeBSD.org> <5414865A.6030101@freebsd.org> To: Andrey Chernov X-Mailer: Apple Mail (2.1878.6) Cc: 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, 13 Sep 2014 18:30:46 -0000 --Apple-Mail=_FD0B8BBC-223F-4B45-8F17-6B995FBDE8C9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=koi8-r On 13 Sep 2014, at 20:00, Andrey Chernov wrote: > On 13.09.2014 20:45, Dimitry Andric wrote: >> After some massaging of gcc's source to disable its built-in segfault >> handlers, I get this backtrace: > > Do you get this with my core or finally able to reproduce it by yourself? I was able to reproduce it, on stable/10. I could not reproduce it on head, but that is how it sometimes goes with this kind of issue. :) >> I think it's most likely this is some type of undefined behavior in gcc, >> which leads to randomly corrupted tree values. Of course, it could also >> be a clang bug, but I don't see any "64-bit" instructions in there at >> all. >> >> This needs to be investigated further, but it's very hard to understand >> what is going on the guts of gcc's parser. Let alone to reduce this to >> some sort of reproducible test case. > > By first glance I see a lots of things. It is known that > in edge cases gcc preserves more "unused" values than clang. It can be > the possible case. I'll try to lower -O level preserving -march=core2 > and see. It seems to work for me with -O1 -march=core2, and while valgrind does complain a little, the warnings are all benign. I'll see if I can "mix and match" a few -O2 and -O1 compiled objects, to zero in on where the problematic area(s) are. -Dimitry --Apple-Mail=_FD0B8BBC-223F-4B45-8F17-6B995FBDE8C9 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) iEYEARECAAYFAlQUjUgACgkQsF6jCi4glqMLcQCePX11qOw/Gh+jUTUzCw4iV0DK URYAoJKWrTC0w3eXhnxzLsJgvdg7s9os =IAJV -----END PGP SIGNATURE----- --Apple-Mail=_FD0B8BBC-223F-4B45-8F17-6B995FBDE8C9-- From owner-freebsd-toolchain@FreeBSD.ORG Sat Sep 13 18:58:52 2014 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E22EB5A9 for ; Sat, 13 Sep 2014 18:58:51 +0000 (UTC) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F416C64 for ; Sat, 13 Sep 2014 18:58:50 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id w7so2555505lbi.17 for ; Sat, 13 Sep 2014 11:58:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=f2Znljj+7WYbJE0fBBmOvP6YBrNh4dC4XYsJPRucqO4=; b=ae9JYCQC2pq+bQIVQxK5LegDuYOH/MR8I/wgMGuKvSQt4olG9f+K6+6OQEiX+eR2rg mZnHG65uXedFJikGQ+GBJVpV32sy+U8MHt6SvLqJLayqYBh8aGom/V0S5V43de46CdGD E4P3/2FOJFMsDV40jYuyxWxc1rmR7t+g8HDvTAIQMvmiJh/V0qTsrrH7WVh4K7+d9eZA bDkDA4eQwZ9inXqGyYhXQZZgGQIwWddiyDEJMmY1291iOs/Gc2yHTRcj/yLT9rvYqbQR 4GYLmQ6sXyoAqGgL2SQIMyia94V0fmRUzuxKZpNSj9piQYjDnPxGTfXDWzH4R6LMZYLm aNiQ== X-Gm-Message-State: ALoCoQlHNmE4/Pr6dg/PJo713XMi6dTuY2tK2VV5ZtlRPbPWKM80jEcfj8bmrF1WapQ4UOK2dlJy X-Received: by 10.152.5.40 with SMTP id p8mr17999619lap.32.1410634375654; Sat, 13 Sep 2014 11:52:55 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id k8sm2442842laf.5.2014.09.13.11.52.54 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Sep 2014 11:52:54 -0700 (PDT) Message-ID: <54149286.80608@freebsd.org> Date: Sat, 13 Sep 2014 22:52:54 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: clang makes segfaulting code with -march=core2 on i386 References: <54130AD0.8090103@freebsd.org> <54133E1E.9030105@freebsd.org> <54135B24.5040905@freebsd.org> <54135D0B.7060701@freebsd.org> <6FDF432B-8245-4BC7-952B-DFFEEA106D6F@FreeBSD.org> <5414865A.6030101@freebsd.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9TuO7hLcmsFCUr6gT8Q63VCkDg5G6qB7f" Cc: 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, 13 Sep 2014 18:58:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9TuO7hLcmsFCUr6gT8Q63VCkDg5G6qB7f Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 13.09.2014 22:30, Dimitry Andric wrote: >> By first glance I see a lots of things. It is known th= at >> in edge cases gcc preserves more "unused" values than clang. It can be= >> the possible case. I'll try to lower -O level preserving -march=3Dcore= 2 >> and see. >=20 > It seems to work for me with -O1 -march=3Dcore2, and while valgrind doe= s > complain a little, the warnings are all benign. >=20 > I'll see if I can "mix and match" a few -O2 and -O1 compiled objects, t= o > zero in on where the problematic area(s) are. I can confirm that it works with -march=3Dcore2 and without -O at all or with -O1. So it looks very match like overoptimization in clang. --=20 http://ache.vniz.net/ --9TuO7hLcmsFCUr6gT8Q63VCkDg5G6qB7f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUFJKGAAoJEKUckv0MjfbKGCQH/3DIJ+bOv8boGbr0xe4wh4nB 11cgEAKolrNH6qJBzkiASFnScHgN+wMHItwiSYCZ5l24Birw9ev0K/UKdGFmCgiW OOTcEzFed1dIC7R5oCxN5d3NgiN1jQNRPXL4GFa1TPB+e5fV4E9FhvBha/p1shWe 9q1JCWyRhhRj2gvC5SwmnZHxiiPngc/Y4Nihpag6IfnLbwLb8OgqA/jTmuIZQNgN vtphxlMSM3igAix91BU4cfoCWyxzYq7IFJjCa5uWFET4R86epdXX+mPtd5D3fP6t FCld0k2VbOheH/7srIjoU841huZ+ybQWBWLeH0/FmjF4jjoTswmGJ1MRAk9epyI= =JJaf -----END PGP SIGNATURE----- --9TuO7hLcmsFCUr6gT8Q63VCkDg5G6qB7f--