[Bug target/63538] New: [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses

[Bug target/63538] New: [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses

[tmsriram at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538

            Bug ID: 63538
           Summary: [X86_64] With -mcmodel=medium .lrodata accesses do not
                    use 64-bit addresses
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tmsriram at google dot com
                CC: davidxl at google dot com

foo.cc
======

#include <stdio.h>

const char *str = "Hello World";

int main() {
 printf("str = %p %s\n",str, str);
 return 0;
}


$ g++ --save-temps foo.cc -mcmodel=medium -mlarge-data-threshold=0 -O2

Linked with gold linker.

Look at foo.s:
===========

       .section        .lrodata,"a",@progbits
.LC0:
       .string "str = %p %s\n"

.....

main:
    ...
    movl       $.LC0, %edi

This is the problem, it treats .LC0 as a 32-bit address when it should a 64-bit
address since it is placed in .lrodata

Now this bug will not manifest until .lrodata exceeds the 2GB limit.  That can
be done by linking with -Wl,-Ttext=0x7ffff000  which moves the start address of
.text to be very close to 2GB and enough to throw .lrodata out of the limit.

Program segfaults.

[Bug target/63538] [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-03
                 CC|                            |ubizjak at gmail dot com
     Ever confirmed|0                           |1

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Can you please try following patch:

--cut here--
Index: config/i386/i386.c
===================================================================
--- config/i386/i386.c    (revision 217050)
+++ config/i386/i386.c    (working copy)
@@ -5099,8 +5099,7 @@ ATTRIBUTE_UNUSED static section *
 x86_64_elf_select_section (tree decl, int reloc,
                unsigned HOST_WIDE_INT align)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-      && ix86_in_large_data_p (decl))
+  if (ix86_in_large_data_p (decl))
     {
       const char *sname = NULL;
       unsigned int flags = SECTION_WRITE;
@@ -5186,8 +5185,7 @@ x86_64_elf_section_type_flags (tree decl, const ch
 static void ATTRIBUTE_UNUSED
 x86_64_elf_unique_section (tree decl, int reloc)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-      && ix86_in_large_data_p (decl))
+  if (ix86_in_large_data_p (decl))
     {
       const char *prefix = NULL;
       /* We only need to use .gnu.linkonce if we don't have COMDAT groups.  */
@@ -44230,9 +44228,7 @@ ix86_encode_section_info (tree decl, rtx rtl, int
 {
   default_encode_section_info (decl, rtl, first);

-  if (TREE_CODE (decl) == VAR_DECL
-      && (TREE_STATIC (decl) || DECL_EXTERNAL (decl))
-      && ix86_in_large_data_p (decl))
+  if (ix86_in_large_data_p (decl))
     SYMBOL_REF_FLAGS (XEXP (rtl, 0)) |= SYMBOL_FLAG_FAR_ADDR;
 }

--cut here--

The most important change is in the last part: leave ix86_in_large_data_p to
decide if the declaration goes to large section, as is the case in other
places.

Patch fixes the testcase and survives bootstrap+regtest for x86_64-linux-gnu,
but the testsuite that involves -mcmodel=medium is virtually nonexistent.

Confirmed.
>From gcc-bugs-return-465672-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Nov 03 21:25:32 2014
Return-Path: <gcc-bugs-return-465672-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7643 invoked by alias); 3 Nov 2014 21:25:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7593 invoked by uid 48); 3 Nov 2014 21:25:29 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63714] AIX (5.3.7, xlC v11) fails to bootstrap for gcc 4.9.2, 4.8.3 and 4.7.4
Date: Mon, 03 Nov 2014 21:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63714-4-H4CJW8gwwq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63714-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63714-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00144.txt.bz2
Content-length: 384

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc714

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
https://gcc.gnu.org/wiki/FAQ#Configuration_fails_with_.27.27configure:_error:_cannot_compute_suffix_of_object_files:_cannot_compile.27.27._What_is_the_problem.3F

(and for selecting the shell: https://gcc.gnu.org/install/prerequisites.html )

Please read the docs...

[Bug target/63538] [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov  5 21:00:07 2014
New Revision: 217156

URL: https://gcc.gnu.org/viewcvs?rev=217156&root=gcc&view=rev
Log:
    PR target/63538
    * config/i386/i386.c (in_large_data_p): Reject automatic variables.
    (ix86_encode_section_info): Do not check for non-automatic varibles
    when setting SYMBOL_FLAG_FAR_ADDR flag.
    (x86_64_elf_select_section): Do not check ix86_cmodel here.
    (x86_64_elf_unique_section): Ditto.
    (x86_elf_aligned_common): Emit tab before .largecomm.

testsuite/ChangeLog:

    PR target/63538
    * gcc.target/i386/pr63538.c: New test.


Added:
    trunk/gcc/testsuite/gcc.target/i386/pr63538.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/63538] [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses

[uros at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538

--- Comment #3 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov  5 22:23:05 2014
New Revision: 217160

URL: https://gcc.gnu.org/viewcvs?rev=217160&root=gcc&view=rev
Log:
    PR target/63538
    * config/i386/i386.c (in_large_data_p): Reject automatic variables.
    (ix86_encode_section_info): Do not check for non-automatic varibles
    when setting SYMBOL_FLAG_FAR_ADDR flag.
    (x86_64_elf_select_section): Do not check ix86_cmodel here.
    (x86_64_elf_unique_section): Ditto.
    (x86_elf_aligned_common): Emit tab before .largecomm.

testsuite/ChangeLog:

    PR target/63538
    * gcc.target/i386/pr63538.c: New test.


Added:
    branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr63538.c
Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/i386/i386.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/63538] [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses

[ubizjak at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.9.3

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
Fixed for 4.9.3+.
>From gcc-bugs-return-465841-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 05 22:29:15 2014
Return-Path: <gcc-bugs-return-465841-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21771 invoked by alias); 5 Nov 2014 22:29:15 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21739 invoked by uid 48); 5 Nov 2014 22:29:11 -0000
From: "thomas at famillebernardgouriou dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63198] decltype in template function declaration yields spurious error
Date: Wed, 05 Nov 2014 22:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thomas at famillebernardgouriou dot fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-63198-4-aeSYCJXNnq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63198-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63198-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00313.txt.bz2
Content-length: 718

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc198

Thomas Bernard <thomas at famillebernardgouriou dot fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thomas@famillebernardgourio
                   |                            |u.fr

--- Comment #3 from Thomas Bernard <thomas at famillebernardgouriou dot fr> ---
I tried investigating this and it seems that decltype( v1 = v2 )::t1 should be
handled as a dependent type, but isn't. I modified the test case like this

template <typename T>
void f1(typename decltype(v1 = v2)::t1);

and the problem seems to be solved.