]> git.ipfire.org Git - thirdparty/gcc.git/commit
Fix libiberty link failures in LTO mode for MinGW
authorEric Botcazou <ebotcazou@adacore.com>
Tue, 4 May 2021 10:40:42 +0000 (12:40 +0200)
committerEric Botcazou <ebotcazou@adacore.com>
Tue, 4 May 2021 10:53:21 +0000 (12:53 +0200)
commitf418bc3cd173bc4e679469928d4d96ffcc05fc7e
tree9883221a26c13694cf41f221dddf3f4ac2fc9acc
parent1b0f570009825ce53a3967ea9a92b1961b7c122b
Fix libiberty link failures in LTO mode for MinGW

The test for the presence of variables (really symbols) does not work
when you add -Ox -flto to CFLAGS:

  for v in $vars; do
    AC_MSG_CHECKING([for $v])
    AC_CACHE_VAL(libiberty_cv_var_$v,
      [AC_LINK_IFELSE([AC_LANG_PROGRAM([[int *p;]],[[extern int $v [];
                                         p = $v;]])],
                      [eval "libiberty_cv_var_$v=yes"],
                      [eval "libiberty_cv_var_$v=no"])])
    if eval "test \"`echo '$libiberty_cv_var_'$v`\" = yes"; then
      AC_MSG_RESULT(yes)
      AC_DEFINE_UNQUOTED($n)
    else
      AC_MSG_RESULT(no)
    fi
  done

because the assignment to 'p' is optimized away by LTO.  This is visible
on MinGW platforms in the form of a link failure for sys_siglist.

There is another link failures for stpcpy: the symbol is both referenced
by libiberty's pex-win32.c and provided by libiberty's stpcpy.c, so it
needs to have a linkage to be resolved in LTO mode.

libiberty/
* configure.ac: Make test for variables more robust.
* configure: Regenerate.
gcc/
* builtins.c (builtin_with_linkage_p): Return true for stp[n]cpy.
* symtab.c (symtab_node::output_to_lto_symbol_table_p): Tidy up.
gcc/builtins.c
gcc/symtab.c
libiberty/configure
libiberty/configure.ac