[Bug target/61599] New: [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.

[Bug target/61599] New: [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.

[tmsriram at google dot com]

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

            Bug ID: 61599
           Summary: [x86_64] With -mcmodel=medium, extern global arrays
                    without size are not treated conservatively.
           Product: gcc
           Version: 4.10.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, ppluzhnikov at google dot com

foo.cc
======

char c[1*1024*1024*1024];

extern int bar();
int main()
{
  return bar() + c[225];
}

bar.cc
======
extern char c[];

int bar()
{
  return c[225];
}


$ g++ -mcmodel=medium foo.cc bar.cc -fdata-sections
BFD linker warns:
bar.cc:(.text+0x7): relocation truncated to fit: R_X86_64_PC32 against symbol
`c' defined in .lbss.c section in foo.o

Reason is the compiler does not treat 'c' conservatively as being in .lbss when
it does not know its size. Worse, adding -mlarge-data-threshold=0 still does
not solve the problem.

Changing the declaration "extern char c[]" to "extern char c[1*1024*1024*1024]"
solves the problem.

[Bug target/61599] [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.

[tmsriram at gcc dot gnu.org]

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

--- Comment #1 from tmsriram at gcc dot gnu.org <tmsriram at gcc dot gnu.org> ---
Author: tmsriram
Date: Wed Jul  9 00:50:25 2014
New Revision: 212380

URL: https://gcc.gnu.org/viewcvs?rev=212380&root=gcc&view=rev
Log:
2014-07-08  Sriraman Tallam  <tmsriram@google.com>

    PR target/61599
    * config/i386/i386.c (ix86_in_large_data_p): Check for size less
    than zero.

    PR target/61599
    * gcc.target/i386/pr61599-1.c: New test.
    * gcc.target/i386/pr61599-2.c: New test.




Added:
    trunk/gcc/testsuite/gcc.target/i386/pr61599-1.c
    trunk/gcc/testsuite/gcc.target/i386/pr61599-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/61599] [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.

[tmsriram at google dot com]

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

Sriraman Tallam <tmsriram at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Sriraman Tallam <tmsriram at google dot com> ---
Resolved with a simple fix.

[Bug target/61599] [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.

[ubizjak at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2015-01-30
                 CC|                            |hjl.tools at gmail dot com
         Resolution|FIXED                       |---
     Ever confirmed|0                           |1

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
Adding -fpic, I got:

/ssd/uros/gcc-build/gcc/xgcc -B/ssd/uros/gcc-build/gcc/
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.target/i386/pr61599-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -mcmodel=medium
-fdata-sections
/home/uros/gcc-svn/trunk/gcc/testsuite/gcc.target/i386/pr61599-2.c -lm -fpic -o
./pr61599-1.exe
/tmp/ccfpoxHY.o: In function `bar':
pr61599-2.c:(.text+0xe): relocation truncated to fit: R_X86_64_PC32 against
symbol `a' defined in LARGE_COMMON section in /tmp/ccKTKST2.o
collect2: error: ld returned 1 exit status
compiler exited with status 1

Reopened, it looks that some sections are not handled correctly.
>From gcc-bugs-return-475571-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jan 30 20:07:05 2015
Return-Path: <gcc-bugs-return-475571-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5029 invoked by alias); 30 Jan 2015 20:07:04 -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 4890 invoked by uid 48); 30 Jan 2015 20:06:59 -0000
From: "bjmnbraun at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63472] transaction_atomic within while loop causes ICE
Date: Fri, 30 Jan 2015 20:07: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bjmnbraun at gmail dot com
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:
Message-ID: <bug-63472-4-64mOIJCtiT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63472-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63472-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: 2015-01/txt/msg03565.txt.bz2
Content-length: 533

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

--- Comment #7 from Benjamin Braun <bjmnbraun at gmail dot com> ---
A workaround for the code at the top of this thread is to wrap the transaction
in the loop with a function and instead call that function from the loop.

This workaround also works for the case given in duplicate filing
https://gcc.gnu.org/bugzilla/show_bug.cgi?idd879, however the wrapper
function has to be marked __attribute__((noinline)) otherwise the function gets
inlined and then the workaround fails.