From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25088 invoked by alias); 4 Aug 2008 11:06:09 -0000 Received: (qmail 25037 invoked by uid 22791); 4 Aug 2008 11:06:08 -0000 X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.159) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Aug 2008 11:05:14 +0000 Received: by fg-out-1718.google.com with SMTP id e21so989271fga.28 for ; Mon, 04 Aug 2008 04:05:11 -0700 (PDT) Received: by 10.86.95.20 with SMTP id s20mr10287792fgb.49.1217847910628; Mon, 04 Aug 2008 04:05:10 -0700 (PDT) Received: from scientist-2.lan ( [213.140.22.65]) by mx.google.com with ESMTPS id l12sm3448951fgb.6.2008.08.04.04.05.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 Aug 2008 04:05:09 -0700 (PDT) Message-ID: <4896E265.4020800@gnu.org> Date: Mon, 04 Aug 2008 11:06:00 -0000 From: Paolo Bonzini User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Jay CC: Andrew Pinski , gcc@gcc.gnu.org Subject: Re: configuring in-tree gmp/mpfr with "none"? References: <4891C3E7.4050401@gnu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg00038.txt.bz2 Jay wrote: >> Because at some point, no released version worked on intel macs. > > Long since passed and can be removed? I don't think so, http://gmp.darwinports.com/ shows that it is still a problem with 4.2.2. Besides, GMP's authors say that it is often a stress test for compilers, so using more C and less assembly can be a good thing (GCC's usage of GMP does not include manipulating really really huge numbers). > gmp/configure is where the blame really lies, but if gcc configured gmp "normally", > this wouldn't occur. Or, is cpu=none not so abnormal? Just that I hadn't seen it? It's a GMP-only thing. Given that this is a problem because of Python's apparently broken handling of signals, we cannot do anything about it. Complain with the Python maintainers that they should reset the signals they ignore, before exec-ing another program. Paolo