https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
Bug ID: 65780 Summary: [5 Regression] Uninitialized common handling in executables Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org int optopt; int main () { optopt = 4; return 0; } fails to link with GCC 5 on powerpc64{,le}-linux: gcc -O2 -o a a.c /usr/bin/ld: /tmp/cckV8RvX.o: In function `main': a.c:(.text.startup+0x6): unresolvable R_PPC64_TOC16_HA against `optopt@@GLIBC_2.3' /usr/bin/ld: a.c:(.text.startup+0xe): unresolvable R_PPC64_TOC16_LO against `optopt@@GLIBC_2.3' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status The problem seems to be that targetm.binds_local_p now returns true for !shlib DECL_COMMON with NULL (or error_mark_node) DECL_INITIAL. Looking at the difference between 4.9 and 5, there is: if (defined_locally && weak_dominate && !shlib) resolved_locally = true; and finally (similar to 4.9) /* Uninitialized COMMON variable may be unified with symbols resolved from other modules. */ if (DECL_COMMON (exp) && !resolved_locally && (DECL_INITIAL (exp) == NULL || (!in_lto_p && DECL_INITIAL (exp) == error_mark_node))) return false; Looking at what x86_64-linux linker does in this case, assuming that an unitialized common binds locally in the executable if it is defined there works fine, but clearly not on ppc*. Either it is a linker bug there, or we for powerpc* (some other targets too) should treat the uninitialized DECL_COMMON defined_locally && weak_dominate && !shlib differently - not set resolved_locally in that case? Can people try other targets? The testcase relies on optopt being an integer variable defined in libc shared library, if that is not the case, create a shared library with that symbol and link it to the binary.