From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28737 invoked by alias); 27 Apr 2010 12:58:07 -0000 Received: (qmail 28723 invoked by uid 22791); 27 Apr 2010 12:58:05 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from 30.mail-out.ovh.net (HELO 30.mail-out.ovh.net) (213.186.62.213) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Tue, 27 Apr 2010 12:57:52 +0000 Received: (qmail 7802 invoked by uid 503); 27 Apr 2010 12:55:23 -0000 Received: from b7.ovh.net (HELO mail637.ha.ovh.net) (213.186.33.57) by 30.mail-out.ovh.net with SMTP; 27 Apr 2010 12:55:23 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 27 Apr 2010 12:58:20 -0000 Received: from unknown (HELO ?192.168.1.50?) (piments%piments.com@95.176.17.55) by ns0.ovh.net with SMTP; 27 Apr 2010 12:58:18 -0000 Message-ID: <4BD6DF79.2050705@piments.com> Date: Tue, 27 Apr 2010 12:58:00 -0000 From: ng@piments.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100131 Shredder/3.0.1 MIME-Version: 1.0 To: Martin Guy CC: crossgcc@sourceware.org Subject: Re: -mfloat-abi=softfp References: <4BCB51C6.90504@piments.com> <4BCBB03F.2000100@piments.com> <4BD6B8E5.2020807@piments.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 16098679820029502063 X-Ovh-Remote: 95.176.17.55 () X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-IsSubscribed: yes Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00155.txt.bz2 On 04/27/10 13:07, Martin Guy wrote: > On 4/27/10, ng@piments.com wrote: >> So now I've put >> LIBC_GLIBC_EXTRA_CFLAGS= -mfpu=maverick -mfloat-abi=softfp -mcpu=ep9312 >> >> It's throwing ICE in glibc.: >> >> [ALL ] ibm420.c:1: warning: switch -mcpu=ep9312 conflicts with -march= >> switch >> [ALL ] ../iconv/skeleton.c: In function 'gconv': >> [ERROR] ../iconv/skeleton.c:801: internal compiler error: Segmentation >> fault >> [ALL ] Please submit a full bug report, >> [ALL ] with preprocessed source if appropriate. > > ICE is a bug in the GCC that you are using to build the cross-compiler > - the "core compiler" - in this case, the output of your stage1 > compilation. "Segmentation fault" is pretty severe :( > To investigate further where it is segfaulting you can run the one > specific command under gdb. I the core compiler is built using the > system glibc, so it shouldn't be a bug in the glibc patches. For what > it's worth, I've used the native gcc-4.3-crunch to build glibc again. > natively). > > Another strategy you could use is to build gcc-4.2, which runs faster, > uses less memory to compile things and produces smaller and faster > code than gcc-4.3 (yes, really!) > >> warning: switch -mcpu=ep9312 conflicts with -march= switch >> I have left -mcpu -mtune empty in menuconfig giving just -march=armv4t > > -march=ep9312 should be what you need, but I doubt that will fix the ICE. > > M > Thanks Martin, Uptil now I was using -march=armv4t , setting it ep9312 fails on 4.2.4 [ALL ] /back/ts/ct-ng/targets/src/gcc-4.2.4/gcc/crtstuff.c:1: warning: target CPU does not support interworking [ALL ] Assembler messages: [ALL ] Error: unknown architecture `ep9312' [ALL ] [ALL ] Error: unrecognized option -march=ep9312 man gcc (4.3.4) says: `-march=NAME' This specifies the name of the target ARM architecture. GCC uses this name to determine what kind of instructions it can emit when generating assembly code. This option can be used in conjunction with or instead of the `-mcpu=' option. Permissible names are: `armv2', `armv2a', `armv3', `armv3m', `armv4', `armv4t', `armv5', `armv5t', `armv5te', `armv6', `armv6j', `armv6t2', `armv6z', `armv6zk', `armv7', `armv7-a', `armv7-r', `armv7-m', `iwmmxt', `ep9312'. :? I did not try this config with 4.3.4. Could this relate to the -march= switch message I was getting before. Is some other stage deciding this is invalid and replacing it with a null string? Now trying your suggestion of 4.2.4 thx -- For unsubscribe information see http://sourceware.org/lists.html#faq