From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-381175-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 4453 invoked by alias); 20 Oct 2014 17:46:50 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 4301 invoked by uid 89); 20 Oct 2014 17:46:49 -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-f170.google.com
Received: from mail-qc0-f170.google.com (HELO mail-qc0-f170.google.com) (209.85.216.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 20 Oct 2014 17:46:47 +0000
Received: by mail-qc0-f170.google.com with SMTP id m20so4136885qcx.15        for <gcc-patches@gcc.gnu.org>; Mon, 20 Oct 2014 10:46:45 -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=NkbGYtdp2z6Lp9Lz58EycF0rxFae47Kir2xIg2D75w0=;        b=UtOl/F6RtR5Nn5JtdJwTmOJ2aeEGanlzPKrfEOj6kcTddbQcil2Zsne3NxkqlM81Ko         ohzQV8A52mvO+3IHdQHJI/h67EcVVeUy5C/fZ+RLaRZ3mr1+Dv5csvFZQjdSzBQSz1EO         PgsTFUfYlz86KqTZ1dsnWMv9k0pZg6biheHu0p/z6/ja1YmcK0pVq4LoKx9okjO5RzvX         Y/eVAq+5TIQ5s58QQYfqKQ1d/dzQtaIazUPUl0cfgeuRJSyzuJrMcJa89RTa0h2q2Q4F         YId9zegGrRRLsPuyMavN4Em05BPekrQrKrd7FSudVbY7guUM3qsOmAIejMAFWNY0G01r         LBEg==
X-Gm-Message-State: ALoCoQkVMKYpfZrg5KJeHXa5pVOTt60AypluvCqpxO9Bnd2Vu5SxGAH7k8LTskGW8qstpGtkkYl/
MIME-Version: 1.0
X-Received: by 10.224.64.71 with SMTP id d7mr37481513qai.16.1413827204957; Mon, 20 Oct 2014 10:46:44 -0700 (PDT)
Received: by 10.229.26.135 with HTTP; Mon, 20 Oct 2014 10:46:44 -0700 (PDT)
In-Reply-To: <CAAkRFZJH6UiUOLE+ca-5oRXWt0_Bdqv1m8uxRK=XbgiezMnVUg@mail.gmail.com>
References: <CAAs8HmzszJ+Pzm_pd0QjHNhbYsDhSrMGyq4zeC73pTD_Ws2_Yg@mail.gmail.com>	<CAAkRFZJH6UiUOLE+ca-5oRXWt0_Bdqv1m8uxRK=XbgiezMnVUg@mail.gmail.com>
Date: Mon, 20 Oct 2014 17:51:00 -0000
Message-ID: <CAAs8Hmx9c+Kzz7mgw7OYX18Soex2oXJ_prN+3HQEuXf6p9aJ6g@mail.gmail.com>
Subject: Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538
From: Sriraman Tallam <tmsriram@google.com>
To: Xinliang David Li <davidxl@google.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, Jan Hubicka <hubicka@ucw.cz>, 	Cary Coutant <ccoutant@google.com>, Paul Pluzhnikov <ppluzhnikov@google.com>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2014-10/txt/msg01950.txt.bz2

On Mon, Oct 20, 2014 at 10:42 AM, Xinliang David Li <davidxl@google.com> 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.

Thanks
Sri

>
> David
>
> On Mon, Oct 20, 2014 at 10:35 AM, Sriraman Tallam <tmsriram@google.com> 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