From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19737 invoked by alias); 20 Oct 2014 18:58:37 -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 19681 invoked by uid 89); 20 Oct 2014 18:58:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qc0-f177.google.com Received: from mail-qc0-f177.google.com (HELO mail-qc0-f177.google.com) (209.85.216.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 20 Oct 2014 18:58:35 +0000 Received: by mail-qc0-f177.google.com with SMTP id c9so4090029qcz.8 for ; Mon, 20 Oct 2014 11:58:32 -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=axiXgt7E3tl6TTtASQAqscbT5yFU0hta3VwhnAd7imc=; b=ifz3T8HwBHI5QWqJJgaH/JdfY6TzcFJpn9CxqlEM0ZGeNIrXUR9hqIy1unNcbiRbwo Og7Ua2kCKAhzqoXByOQLspYiTdd9NT3cZOcTjC5Y7fiHgxrYQSI6NFurbD9R6jGUG1xs 1xZ3Ke1Da9XogNp6jn2A+KWUbO5fCcn5zQgjR7ZVAzYhsrZBx6cTjCIyCH9L/QgPFPNI vSytshxQ0ByB9uRQkWvUIaSuAFRxgUrBuf8UwftZqWIxNep/Uu+nKjxqWV8dMxRNNOnz XDtFPwD8lmjLO3U0JUMiHXYMQLMqyI7tmVdiNe4p0E7yENtngovu8GJgBr8po9TsyE1V zxVA== X-Gm-Message-State: ALoCoQkRiD5cUaVWMeukDRtbXMXGscbLhf+kcYEwRk3mOesyXB0VGmfc4dtCeare5UUx/cUJe/9p MIME-Version: 1.0 X-Received: by 10.140.109.53 with SMTP id k50mr36906726qgf.83.1413831512415; Mon, 20 Oct 2014 11:58:32 -0700 (PDT) Received: by 10.229.26.135 with HTTP; Mon, 20 Oct 2014 11:58:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 18:59:00 -0000 Message-ID: Subject: Re: [Google/gcc-4_9][PATCH][target/x86_64] PR 63538 From: Sriraman Tallam To: Xinliang David Li Cc: GCC Patches , Jan Hubicka , Cary Coutant , Paul Pluzhnikov Content-Type: multipart/mixed; boundary=001a113a6bf6123f8d0505df4d5c X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg01957.txt.bz2 --001a113a6bf6123f8d0505df4d5c Content-Type: text/plain; charset=UTF-8 Content-length: 1696 On Mon, Oct 20, 2014 at 10:59 AM, Xinliang David Li wrote: > Perhaps explicitly allowing STRING_CST to go through the large data > check, instead of removing the var-decl check? Do you see other > opcodes that need to be handled too? I do not see any other opcodes explicitly but the code in ix86_in_large_data_p seemingly handles all opcodes other than FUNCTION_DECL through: if (TREE_CODE (exp) == VAR_DECL && DECL_SECTION_NAME (exp)) { } else { } However, I have modified the patch to explicitly check for STRING_CST and I cannot think of any other case where the constant goes into rodata but is not accessed via a VAR_DECL. Also note that TREE_STATIC (decl) is true for STRING_CST. Thanks Sri > > David > > 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. >> >> 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 --001a113a6bf6123f8d0505df4d5c Content-Type: text/plain; charset=US-ASCII; name="pr63538.txt" Content-Disposition: attachment; filename="pr63538.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i1i6ruvi0 Content-length: 1623 SW5kZXg6IGNvbmZpZy9pMzg2L2kzODYuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBjb25maWcvaTM4Ni9pMzg2LmMJKHJldmlzaW9uIDIxNjI4NykK KysrIGNvbmZpZy9pMzg2L2kzODYuYwkod29ya2luZyBjb3B5KQpAQCAtNDEz MzEsNyArNDEzMzEsNyBAQCBpeDg2X2VuY29kZV9zZWN0aW9uX2luZm8gKHRy ZWUgZGVjbCwgcnR4IHJ0bCwgaW50CiB7CiAgIGRlZmF1bHRfZW5jb2RlX3Nl Y3Rpb25faW5mbyAoZGVjbCwgcnRsLCBmaXJzdCk7CiAKLSAgaWYgKFRSRUVf Q09ERSAoZGVjbCkgPT0gVkFSX0RFQ0wKKyAgaWYgKChUUkVFX0NPREUgKGRl Y2wpID09IFZBUl9ERUNMIHx8IFRSRUVfQ09ERSAoZGVjbCkgPT0gU1RSSU5H X0NTVCkKICAgICAgICYmIChUUkVFX1NUQVRJQyAoZGVjbCkgfHwgREVDTF9F WFRFUk5BTCAoZGVjbCkpCiAgICAgICAmJiBpeDg2X2luX2xhcmdlX2RhdGFf cCAoZGVjbCkpCiAgICAgU1lNQk9MX1JFRl9GTEFHUyAoWEVYUCAocnRsLCAw KSkgfD0gU1lNQk9MX0ZMQUdfRkFSX0FERFI7CkluZGV4OiB0ZXN0c3VpdGUv Z2NjLmRnL3ByNjM1MzguYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0 ZXN0c3VpdGUvZ2NjLmRnL3ByNjM1MzguYwkocmV2aXNpb24gMCkKKysrIHRl c3RzdWl0ZS9nY2MuZGcvcHI2MzUzOC5jCShyZXZpc2lvbiAwKQpAQCAtMCww ICsxLDE0IEBACisvKiBQUjYzNTM4IGlzIGFib3V0IG5vdCB1c2luZyA2NC1i aXQgYWRkcmVzc2VzIGZvciAubHJvZGF0YSBhY2Nlc3NlcyB3aGVuIGl0Cisg ICBpbnZvbHZlcyBTVFJJTkdfQ1NUcy4gICovCisvKiB7IGRnLWRvIGNvbXBp bGUgeyB0YXJnZXQgeDg2XzY0LSotKiB9IH0gKi8KKy8qIHsgZGctb3B0aW9u cyAiLU8yIC1tY21vZGVsPW1lZGl1bSAtbWxhcmdlLWRhdGEtdGhyZXNob2xk PTAiIHsgdGFyZ2V0IHg4Nl82NC0qLSogfSB9ICovCisKKyNpbmNsdWRlIDxz dGRpby5oPgorCitjb25zdCBjaGFyICpzdHIgPSAiSGVsbG8gV29ybGQiOwor CitpbnQgbWFpbigpIHsKKyBwcmludGYoInN0ciA9ICVwICVzXG4iLHN0ciwg c3RyKTsKKyByZXR1cm4gMDsKK30KKy8qIHsgZGctZmluYWwgeyBzY2FuLWFz c2VtYmxlci1ub3QgIm1vdmwiIH0gfSAqLwo= --001a113a6bf6123f8d0505df4d5c--