From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32731 invoked by alias); 4 Nov 2014 18:58:38 -0000 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 Received: (qmail 32721 invoked by uid 89); 4 Nov 2014 18:58:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f181.google.com Received: from mail-lb0-f181.google.com (HELO mail-lb0-f181.google.com) (209.85.217.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 04 Nov 2014 18:58:36 +0000 Received: by mail-lb0-f181.google.com with SMTP id l4so5042335lbv.12 for ; Tue, 04 Nov 2014 10:58:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.131.33 with SMTP id oj1mr7602900lbb.97.1415127509409; Tue, 04 Nov 2014 10:58:29 -0800 (PST) Received: by 10.152.8.103 with HTTP; Tue, 4 Nov 2014 10:58:29 -0800 (PST) In-Reply-To: <5458C7F8.8080702@codesourcery.com> References: <5454CAB9.3040907@codesourcery.com> <5458016A.4080109@redhat.com> <5458C7F8.8080702@codesourcery.com> Date: Tue, 04 Nov 2014 18:58:00 -0000 Message-ID: Subject: Re: nvptx offloading patches [3/n], i386 bits RFD From: Uros Bizjak To: Bernd Schmidt Cc: Jeff Law , GCC Patches , Ilya Verbin , "H.J. Lu" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-11/txt/msg00223.txt.bz2 On Tue, Nov 4, 2014 at 1:35 PM, Bernd Schmidt wrote: >> Not sure how to deal with this any further out than the immediate term >> than using a hack like this. Though I'd prefer to avoid the #ifdef as it >> seems to me this shouldn't be baked in at build/configure time. > > > Yeah, I'm not expecting the i386 part to go in quite as-is. For reference > I'm including the offload-abi patch - Ilya is submitting this along with > other option changes. One possibility would be to print and recognize > strings such as lp64D128 or lp64D96 which would include information about > the size of long double. Somehow though I can't really bring myself to > believe that -mlong-double128 is a real use case with offloading so we might > just disallow the combination. > > CCing Uros in case he has an opinion. -mlong-double-128 was introduced for Android in: 2014-02-03 H.J. Lu * config/i386/i386.c (flag_opts): Add -mlong-double-128. (ix86_option_override_internal): Default long double to 64-bit for 32-bit Bionic and to 128-bit for 64-bit Bionic. [...] IMO, if it troubles offloading, anything else than the default -mlong-double-80 should be disallowed. Uros.