From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21348 invoked by alias); 20 Oct 2014 18:59:44 -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 21339 invoked by uid 89); 20 Oct 2014 18:59:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qc0-f181.google.com Received: from mail-qc0-f181.google.com (HELO mail-qc0-f181.google.com) (209.85.216.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 20 Oct 2014 18:59:43 +0000 Received: by mail-qc0-f181.google.com with SMTP id r5so4167163qcx.26 for ; Mon, 20 Oct 2014 11:59:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SCwioF4zxunI5WEvGRHIs+r2h/lGPfRcSGP08Pyi760=; b=PAnxVMz3RKmEFHQbN9fefsp9lroE7RmRlmNESZwPDnbZKyy1CV8gVohRArEEpXvxzT SfUSyE4M6J3/FsBzR1zBQW06boNk7sErhMtq78x/YpVx8MiWuNUPgOTTHbthrN+O5s+m SbJXL4BTxJHu5UF9qO7Kix3cgOS6WE0o56QsqEDLzAwEU8K3XxKh188VXdHgD6YhB+AL Rl2+YKx7s6R3ZsKBKUjsD0sA44wKnl8Pc3QtZKA8rPEff3uF/YdGj+sp8rKAmFDDm3uB 5zuNIOODem+97t4vGtYqRHh/65Y1NGVj/XGF+zUNqMOT82+ZTatum59yBE2/UBjg6LA1 wqEQ== X-Gm-Message-State: ALoCoQlrNbxi3OPV/bJQsJJYsYtCle1I7yqfprJLgt3dtfi2oP7b734jRu7/439UNU/xwTNF/2ql MIME-Version: 1.0 X-Received: by 10.140.88.177 with SMTP id t46mr28164894qgd.36.1413831580901; Mon, 20 Oct 2014 11:59:40 -0700 (PDT) Received: by 10.229.26.135 with HTTP; Mon, 20 Oct 2014 11:59:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 19:09:00 -0000 Message-ID: Subject: Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538 From: Sriraman Tallam To: Andrew Pinski Cc: Xinliang David Li , GCC Patches , Jan Hubicka , Cary Coutant , Paul Pluzhnikov Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg01958.txt.bz2 On Mon, Oct 20, 2014 at 10:51 AM, Andrew Pinski wrote: > On Mon, Oct 20, 2014 at 10:46 AM, Sriraman Tallam wrote: >> On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li wrote: >>> Why removing the tree_code check? >> >> The actual problem happens because STRING_CSTs (end up in .lrodata) >> are not set a far address as they dont match the VAR_DECL check here. >> Futher, "ix86_in_large_data_p" call has the TREE_CODE check to do the >> right thing so this seems unnecessary & buggy here. > > I think he is asking because TREE_STATIC (decl) || DECL_EXTERNAL > (decl) might be an issue for STRING_CSTs. TREE_STATIC is true for STRING_CSTs and DECL_EXTERNAL false, that looks ok. Thanks Sri > > Thanks, > Andrew > > >> >> Thanks >> Sri >> >>> >>> David >>> >>> On Mon, Oct 20, 2014 at 10:35 AM, Sriraman Tallam wrote: >>>> Hi, >>>> >>>> This patch is under review for trunk GCC : >>>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01638.html. >>>> >>>> In the mean time, is this ok for google/gcc-4_9 branch? Without >>>> this, -mcmodel=medium is unusable if .lrodata goes beyond the 2G >>>> boundary. >>>> >>>> Thanks >>>> Sri