Re: [PATCH] PR rtl-optimization/32219: optimizer causees wrong code in pic/hidden/weak symbol checking

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Feb 16, 2015 at 5:25 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> Hello!
>
>> 2015-02-12  H.J. Lu  <hongjiu.lu@intel.com>
>>             Richard Henderson  <rth@redhat.com>
>>
>>         PR rtl/32219
>>         * cgraphunit.c (cgraph_node::finalize_function): Set definition
>>         before notice_global_symbol.
>>         (varpool_node::finalize_decl): Likewise.
>>         * varasm.c (default_binds_local_p_2): Rename from
>>         default_binds_local_p_1, add weak_dominate argument.  Use direct
>>         returns instead of assigning to local variable.  Unify varpool and
>>         cgraph paths via symtab_node.  Reject undef weak variables before
>>         testing visibility.  Reorder tests for simplicity.
>>         (default_binds_local_p): Use default_binds_local_p_2.
>>         (default_binds_local_p_1): Likewise.
>>         (decl_binds_to_current_def_p): Unify varpool and cgraph paths
>>         via symtab_node.
>>         (default_elf_asm_output_external): Emit visibility when specified.
>
> It looks like this patch broke alphaev68-linux-gnu [1]. There are many
> failures of the type:
>
> /tmp/cck7V7MR.o: In function
> `__static_initialization_and_destruction_0(int, int)':^M
> (.text+0x3ac): relocation truncated to fit: GPRELHIGH against symbol
> `std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >::~basic_string()@@GLIBCXX_3.4.21' defined in
> .text section in
> /space/uros/gcc-build/alphaev68-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so^M
> /space/homedirs/uros/local/bin/ld: /tmp/cck7V7MR.o: gp-relative
> relocation against dynamic symbol

It could be related to:

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

Before this bug fix, all common symbols don't bind locally,
which is one of PR 32219 bugs.  After this fix, common
symbols bind locally.  It may cause problems on targets with
small data sections and common symbols aren't in small
data section:

1. Since common symbols bind locally, backend may assume
they are in small data section and lead to link-time failure.
2. Backend assume common symbols are never in small
data section.  But a definition in small data section may
override a common symbol, which still binds lcoally, and
turn a reference to common symbol to reference to small
data section.  This also may lead to link-time failure.

Those targets can't assume common symbols are in
small data section since it may change at link-time.

The most conservative solution is to make common
symbol doesn't bind locally for targets which defines
TARGET_IN_SMALL_DATA_P.

-- 
H.J.