From owner-freebsd-current@FreeBSD.ORG Fri Feb 22 15:50:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A26D4252 for ; Fri, 22 Feb 2013 15:50:01 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 69CBE8A8 for ; Fri, 22 Feb 2013 15:50:01 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:509e:5349:4e7a:bf0a]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id D049C4AC59; Fri, 22 Feb 2013 19:49:59 +0400 (MSK) Date: Fri, 22 Feb 2013 19:49:54 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <15917508.20130222194954@serebryakov.spb.ru> To: Dimitry Andric Subject: Re: r245741 (clang as cc) can not build binaries for GEODE processor In-Reply-To: <51277EFE.4000703@andric.com> References: <108875110.20130222104603@serebryakov.spb.ru> <51277EFE.4000703@andric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:50:01 -0000 Hello, Dimitry. You wrote 22 =D1=84=D0=B5=D0=B2=D1=80=D0=B0=D0=BB=D1=8F 2013 =D0=B3., 18:21= :50: DA> The default for FreeBSD on 32-bit x86 is i486, so maybe the problems are DA> caused by the -march=3Dgeode setting. If you disable that, do the DA> problems disappear? Problem is, that code compiled with "-march=3Dgeode" works. Code built without any "-march" at all (without CPUTYPE in configs) doesn't. It looks like clang or use "build system" CPU as default "-march" or issue some >=3D i686 commands without it. Or both :) DA> In any case, can you attempt to figure out which exact instructions it DA> dies on? If gdb does not work, like you said above, maybe you can use DA> objdump to disassemble the executable in question, and find the address DA> of the failing instruction. I'm trying to do this with very last sources both as build system and target sources. --=20 // Black Lion AKA Lev Serebryakov