From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1029 invoked by alias); 24 Nov 2007 01:53:04 -0000 Received: (qmail 894 invoked by uid 22791); 24 Nov 2007 01:53:03 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 24 Nov 2007 01:52:59 +0000 Received: (qmail 25754 invoked from network); 24 Nov 2007 01:52:57 -0000 Received: from unknown (HELO ?192.168.0.2?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Nov 2007 01:52:57 -0000 Message-ID: <474783EB.7020103@codesourcery.com> Date: Sat, 24 Nov 2007 10:06:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: gcc-patches@gcc.gnu.org Subject: Re: RFA: Improve 128-bit long double configure test References: <20071115192757.GA7557@caradoc.them.org> In-Reply-To: <20071115192757.GA7557@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg01269.txt.bz2 Daniel Jacobowitz wrote: > MontaVista builds both cross compilers (Linux or Windows -> MVL > target) and native compilers (MVL host) on their Linux-based build > systems. We discovered that the two compilers disagreed on the > size of long double for PowerPC. Have I mentioned that I think > making ABI choices based on configure tests is a really lousy idea? I strongly agree. We've been getting into trouble by using autoconf to try to probe the target for a while, and these kinds of differences between cross- and native- compilers keep coming up. In general, automated probing of the *host* system was what autoconf was originally designed to do. Probing the *target* system isn't a very good idea, since, in general, we can't run programs on it, may not have headers and libraries for it, etc. In my opinion, configuration that affects the target should either be part of the config/ files (t-files, .h files, etc.) or handled explicitly via configuration options. In this specific case, I think it would be better just to use the --with-long-double-128 configuration switch and remove the automated probing altogether. Users that get binary compilers from a distributor won't be affected. Users that build from source will be able to figure this out, just as they do lots of other things. Also, would be to use AC_WARN to tell the user that we think they may have set the option wrong, but still not try to set the option automatically. However, I think that the decision here should be up to the Power maintainers; I'm not trying to set policy unilaterally. Assuming that we don't want to move away from probing here, I have a couple of questions about your patch. It looks like we've got target-probing code for __stack_chk_fail right aboe the code you changed that does the same kind of search for GLIBC headers. I'd expect that your change should be applied to that code too, or, better, that the code that finds GLIBC headers should be factored out. Also, why wouldn't your method (using CPP) going to work on all host/target combinations? If so, we should use it everywhere, rather than just in the ($host = $target) != $build case. Thanks, -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713