[Bug go/65134] gccgo ignores the attribute "constructor" in a subdirectory

[Bug go/65134] gccgo ignores the attribute "constructor" in a subdirectory

[ian at airs dot com]

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

--- Comment #1 from Ian Lance Taylor <ian at airs dot com> ---
It's pretty ugly, but a workaround is to drop something like this into sub.go:

var AlwaysFalse bool
func init() {
    if AlwaysFalse {
        C.init()
    }
}

The idea is to force in something that refers to the function that the compiler
and linker aren't smart enough to discard.

[Bug go/65134] gccgo ignores the attribute "constructor" in a subdirectory

[e29253 at jp dot ibm.com]

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

--- Comment #2 from Tatsushi Inagaki <e29253 at jp dot ibm.com> ---
(In reply to Ian Lance Taylor from comment #1)
> It's pretty ugly, but a workaround is to drop something like this into
> sub.go:
> 
> var AlwaysFalse bool
> func init() {
> 	if AlwaysFalse {
> 		C.init()
> 	}
> }
> 
> The idea is to force in something that refers to the function that the
> compiler and linker aren't smart enough to discard.

Thank you very much for your suggestion. Don't we have to take special care at
declaration or assignment of AlwaysFalse, so that the compiler will not
eliminate the never-taken branch to C.init()?
>From gcc-bugs-return-478028-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Feb 21 03:13:54 2015
Return-Path: <gcc-bugs-return-478028-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11171 invoked by alias); 21 Feb 2015 03:13:54 -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 11144 invoked by uid 48); 21 Feb 2015 03:13:50 -0000
From: "howarth at bromo dot med.uc.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/65150] bootstrap failure at r220878 on x86_64 darwin
Date: Sat, 21 Feb 2015 03:40: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: howarth at bromo dot med.uc.edu
X-Bugzilla-Status: UNCONFIRMED
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-65150-4-RM8UMcExUs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65150-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65150-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-02/txt/msg02360.txt.bz2
Content-length: 653

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

--- Comment #2 from howarth at bromo dot med.uc.edu ---
Caused by...

r220875 | jakub | 2015-02-20 11:44:37 -0500 (Fri, 20 Feb 2015) | 8 lines

        PR target/63892
        * ipa-icf.c (sem_function::merge): If DECL_COMDAT_GROUP (alias->decl),
        don't try to create_thunk if stdarg_p.  If
        !sem_item::target_supports_symbol_aliases_p (), similarly, and try to
        redirect_callers if possible.
        (sem_item_optimizer::execute): Call unregister_hooks here...
        (ipa_icf_driver): ... instead of here.

Could this failure be due to the absence of alias support on darwin?

[Bug go/65134] gccgo ignores the attribute "constructor" in a subdirectory

[ian at airs dot com]

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

--- Comment #3 from Ian Lance Taylor <ian at airs dot com> ---
In principle, sure.  In practice, since it's an exported variable, the compiler
would have to see the entire program, which can't happen at present.  If it
ever can, then something else would have to be done.

[Bug go/65134] gccgo ignores the attribute "constructor" in a subdirectory

[e29253 at jp dot ibm.com]

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

--- Comment #4 from Tatsushi Inagaki <e29253 at jp dot ibm.com> ---
I see. Thanks a lot!

[Bug go/65134] gccgo ignores the attribute "constructor" in a subdirectory

[boger at us dot ibm.com]

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

--- Comment #5 from boger at us dot ibm.com ---
(In reply to Tatsushi Inagaki from comment #0)
> Created attachment 34813 [details]
> Example to reproduce the constructor problem
> 
> Gccgo ignores a C-function with the "constructor" attribute in a
> subdirectory. In the attached example, gc executes a C-function init() in
> sub.go before a Go function main(), but gccgo does not:
> 
> ~/example$ export GOPATH=$(pwd)
> ~/example$ /usr/local/go/bin/go version
> go version go1.4.2 linux/amd64
> ~/example$ /usr/local/go/bin/go run src/main/main.go
> Hello from constructor
> Hello from main
> 
> ~/example$ export LD_LIBRARY_PATH=/usr/local/gccgo/lib64:$LD_LIBRARY_PATH
> ~/example$ /usr/local/gccgo/bin/go version
> go version gccgo (GCC) 5.0.0 20150115 (experimental) linux/amd64
> ~/example$ /usr/local/gccgo/bin/go run src/main/main.go
> Hello from main
> 
> ~/example$
> 
> It seems this difference is due to that gccgo cannot detect a function with
> the constructor attribute in an archived objects created in a subdirectory.
> Is there any workaround to avoid this problem?

Just to clarify this -- are you saying the problem that the gccgo linker is
smart enough to determine that the function is not being used so it is
discarded, but with gc it is not?  So this is a difference in behavior but not
actually a bug?

[Bug go/65134] gccgo ignores the attribute "constructor" in a subdirectory

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor <ian at airs dot com> ---
No, I believe the problem is different.  The gccgo build process stores objects
in an archive, and relies on the system linker to pull in those objects. 
However, at least on ELF-based systems like GNU/Linux, the system linker does
not link an object from an archive merely because it has a constructor.  It
only links an object from an archive if there is some reference to it: if the
object defines a symbol that some other object, already included in the link,
refers to.  What I'm doing with the Go code is adding a reference, forcing the
object to be linked in from the archive.

Once the object is linked in, everything works.  So although we want the
reference, we don't want the reference to actually do anything.  That is why I
wrote the AlwaysFalse code: so that there is a function call, but the compiler
can't see that the function will never be called.

This is a standard problem with ELF linkers.  See, e.g.,
http://stackoverflow.com/questions/6589772/gcc-functions-with-constructor-attribute-are-not-being-linked
.  This issue is not really Go-specific, except for the fact that the go tool
build process when using gccgo uses archives.  Perhaps it should change to work
in some other way.