[Bug target/65780] [5/6 Regression] Uninitialized common handling in executables

["hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to H.J. Lu from comment #9)
> > Created attachment 35327 [details]
> > A different patch
> > 
> > On x86, this issue only shows up with PIE. Here is a different
> > patch to treat common symbol defined locally only if the backend
> > passes true common_maybe_local.  For x86-64, it is true only if
> > HAVE_LD_PIE_COPYRELOC is 1.  For i386, it is always false.  If
> > we aren't building PIE, common_maybe_local is true or false
> > doesn't make a difference for x86 since the common symbol is
> > always referenced normally with copy reloc.  For PIE on x86-64,
> > common symbol is local only if HAVE_LD_PIE_COPYRELOC is 1.
> 
> +
> +  /* For common symbol, it is defined locally only if common_maybe_local
> +     is true.  */
> +  bool defined_locally = (!DECL_EXTERNAL (exp)
> +			  && (!DECL_COMMON (exp) || common_maybe_local));
> 
> I think better would be:
>   bool uninited_common = (DECL_COMMON (exp)
>                           && (DECL_INITIAL (exp) == NULL
>                               || (!in_lto_p && DECL_INITIAL (exp) ==
> error_mark_node)));
>   /* For common symbol, it is defined locally only if common_maybe_local
>      is true.  */
>   bool defined_locally = (!DECL_EXTERNAL (exp) && (!uninited_common ||
> common_maybe_local));
> ...
> and then use
>   /* Uninitialized COMMON variable may be unified with symbols
>      resolved from other modules.  */
>   if (uninited_common && !resolved_locally)
>     return false;

Can we find a tectase with initialized COMMON variable and compile
it as PIE?
>From gcc-bugs-return-483782-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 16 11:41:36 2015
Return-Path: <gcc-bugs-return-483782-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 37628 invoked by alias); 16 Apr 2015 11:41:36 -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 37588 invoked by uid 48); 16 Apr 2015 11:41:33 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
Date: Thu, 16 Apr 2015 11:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65780-4-QpeEqwMpS8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65780-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65780-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-04/txt/msg01334.txt.bz2
Content-length: 492

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #13)
> Check flag_pic isn't necessary.  For non-PIC, the same code sequence
> and relocation are used to access defined and undefined symbols, common
> or not.

What do you mean by is not necessary?  Without that, you'll return false from
targetm.binds_local_p for DECL_COMMON in the testcase say on i686-linux, or if
you have old linker.