[PATCH] config: delete unused CYG_AC_PATH_LIBERTY macro

[Mike Frysinger]

Nothing uses this, so delete it to avoid confusion.

config/ChangeLog:

* acinclude.m4 (CYG_AC_PATH_LIBERTY): Delete.
---
 config/acinclude.m4 | 22 --
 1 file changed, 22 deletions(-)

diff --git a/config/acinclude.m4 b/config/acinclude.m4
index 0abccafa0353..f18f0d6e8c77 100644
--- a/config/acinclude.m4
+++ b/config/acinclude.m4
@@ -238,28 +238,6 @@ fi
 AC_SUBST(BFDLIB)
 ])
 
-dnl 
-dnl Find the libiberty library. This defines many commonly used C
-dnl functions that exists in various states based on the underlying OS.
-AC_DEFUN([CYG_AC_PATH_LIBERTY], [
-AC_MSG_CHECKING(for the liberty library in the build tree)
-dirlist=".. ../../ ../../../ ../../../../ ../../../../../ ../../../../../../ 
../../../../../../.. ../../../../../../../.. ../../../../../../../../.. 
../../../../../../../../../.."
-AC_CACHE_VAL(ac_cv_c_liberty,[
-for i in $dirlist; do
-if test -f "$i/libiberty/Makefile" ; then
-   ac_cv_c_liberty=`(cd $i/libiberty; ${PWDCMD-pwd})`
-fi
-done
-])
-if test x"${ac_cv_c_liberty}" != x; then
-LIBERTY="-L${ac_cv_c_liberty}"
-AC_MSG_RESULT(${ac_cv_c_liberty})
-else
-AC_MSG_RESULT(none)
-fi
-AC_SUBST(LIBERTY)
-])
-
 dnl 
 dnl Find the opcodes library. This is used to do dissasemblies.
 AC_DEFUN([CYG_AC_PATH_OPCODES], [
-- 
2.43.0

[PATCH/committed] sim: add distclean dep for gnulib

[Mike Frysinger]

ChangeLog:

* Makefile.def: Add distclean-sim dependency on distclean-gnulib.
* Makefile.in: Regenerate.
---
 Makefile.def | 1 +
 Makefile.in  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Makefile.def b/Makefile.def
index 870150183b9a..15c068e4ac40 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -612,6 +612,7 @@ dependencies = { module=check-libctf; on=all-ld; };
 // gdb and gdbserver.
 dependencies = { module=distclean-gnulib; on=distclean-gdb; };
 dependencies = { module=distclean-gnulib; on=distclean-gdbserver; };
+dependencies = { module=distclean-gnulib; on=distclean-sim; };
 
 // Warning, these are not well tested.
 dependencies = { module=all-bison; on=all-intl; };
diff --git a/Makefile.in b/Makefile.in
index e0e3c4c8fe80..1dda62a03032 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -66891,6 +66891,7 @@ check-stageautoprofile-libctf: 
maybe-all-stageautoprofile-ld
 check-stageautofeedback-libctf: maybe-all-stageautofeedback-ld
 distclean-gnulib: maybe-distclean-gdb
 distclean-gnulib: maybe-distclean-gdbserver
+distclean-gnulib: maybe-distclean-sim
 all-bison: maybe-all-build-texinfo
 all-flex: maybe-all-build-bison
 all-flex: maybe-all-m4
-- 
2.42.0

[PATCH] sim: leverage gnulib

[Mike Frysinger via Gcc-patches]

We use getline, so leverage gnulib to provide fallback implementation.

ChangeLog:

* configure.ac: Add gnulib to configdirs for sim.
* configure: Regenerate.
---
 configure| 3 +++
 configure.ac | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/configure b/configure
index 3715d169dbfe..1224fc4039ec 100755
--- a/configure
+++ b/configure
@@ -9520,6 +9520,9 @@ case " ${configdirs} " in
   *\ gdbserver\ *)
 configdirs="${configdirs} gnulib gdbsupport"
 ;;
+  *\ sim\ *)
+configdirs="${configdirs} gnulib"
+;;
 esac
 
 # Strip out unwanted targets.
diff --git a/configure.ac b/configure.ac
index 626e2106cba7..66d637d70dc5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2849,6 +2849,9 @@ case " ${configdirs} " in
   *\ gdbserver\ *)
 configdirs="${configdirs} gnulib gdbsupport"
 ;;
+  *\ sim\ *)
+configdirs="${configdirs} gnulib"
+;;
 esac
 
 # Strip out unwanted targets.
-- 
2.31.1

Re: [PATCH] config: delete unused sim macros

[Mike Frysinger via Gcc-patches]

On 13 May 2021 09:24, Jeff Law wrote:
> On 5/11/2021 10:28 PM, Mike Frysinger via Gcc-patches wrote:
> > Nothing in gcc or binutils or gdb or anything anywhere uses these.
> >
> > config/
> >
> > * acinclude.m4 (CYG_AC_PATH_SIM, CYG_AC_PATH_DEVO): Delete.
> 
> "DEVO", yea, that's old.  I had a slight concern CYG might refer to 
> Cygwin rather than Cygnus, but the comments reference old Cygnus 
> projects (Foundry).  However, just to be sure, I checked the 
> newlib-cygwin repo which has no references other than a clone of the 
> code you're removing.
> 
> OK for the trunk.

thanks.  did you happen to see this one too ?
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569894.html
-mike

[PATCH] config: delete unused sim macros

[Mike Frysinger via Gcc-patches]

Nothing in gcc or binutils or gdb or anything anywhere uses these.

config/

* acinclude.m4 (CYG_AC_PATH_SIM, CYG_AC_PATH_DEVO): Delete.
---
 config/acinclude.m4 | 102 
 1 file changed, 102 deletions(-)

diff --git a/config/acinclude.m4 b/config/acinclude.m4
index 8242b2c7a8ac..0abccafa0353 100644
--- a/config/acinclude.m4
+++ b/config/acinclude.m4
@@ -373,88 +373,6 @@ fi
 AC_SUBST(INTLLIB)
 ])
 
-dnl 
-dnl Find the simulator library.
-AC_DEFUN([CYG_AC_PATH_SIM], [
-dirlist=".. ../../ ../../../ ../../../../ ../../../../../ ../../../../../../ 
../../../../../../.. ../../../../../../../.. ../../../../../../../../.. 
../../../../../../../../../.. ../../../../../../../../../.."
-case "$target_cpu" in
-powerpc)   target_dir=ppc ;;
-sparc*)target_dir=erc32 ;;
-mips*) target_dir=mips ;;
-*) target_dir=$target_cpu ;;
-esac
-dnl First look for the header file
-AC_MSG_CHECKING(for the simulator header file)
-AC_CACHE_VAL(ac_cv_c_simh,[
-for i in $dirlist; do
-if test -f "${srcdir}/$i/include/remote-sim.h" ; then
-   ac_cv_c_simh=`(cd ${srcdir}/$i/include; ${PWDCMD-pwd})`
-   break
-fi
-done
-])
-if test x"${ac_cv_c_simh}" != x; then
-SIMHDIR="-I${ac_cv_c_simh}"
-AC_MSG_RESULT(${ac_cv_c_simh})
-else
-AC_MSG_RESULT(none)
-fi
-AC_SUBST(SIMHDIR)
-
-dnl See whether it's a devo or Foundry branch simulator
-AC_MSG_CHECKING(Whether this is a devo simulator )
-AC_CACHE_VAL(ac_cv_c_simdevo,[
-CPPFLAGS="$CPPFLAGS $SIMHDIR"
-AC_EGREP_HEADER([SIM_DESC sim_open.*struct _bfd], remote-sim.h,
-ac_cv_c_simdevo=yes,
-ac_cv_c_simdevo=no)
-])
-if test x"$ac_cv_c_simdevo" = x"yes" ; then
-AC_DEFINE(HAVE_DEVO_SIM)
-fi
-AC_MSG_RESULT(${ac_cv_c_simdevo})
-AC_SUBST(HAVE_DEVO_SIM)
-
-dnl Next look for the library
-AC_MSG_CHECKING(for the simulator library)
-AC_CACHE_VAL(ac_cv_c_simlib,[
-for i in $dirlist; do
-if test -f "$i/sim/$target_dir/Makefile" ; then
-   ac_cv_c_simlib=`(cd $i/sim/$target_dir; ${PWDCMD-pwd})`
-fi
-done
-])
-if test x"${ac_cv_c_simlib}" != x; then
-SIMLIB="-L${ac_cv_c_simlib}"
-else
-AC_MSG_RESULT(none)
-dnl FIXME: this is kinda bogus, cause umtimately the TM will build
-dnl all the libraries for several architectures. But for now, this
-dnl will work till then.
-dnl AC_MSG_CHECKING(for the simulator installed with the compiler 
libraries)
-dnl Transform the name of the compiler to it's cross variant, unless
-dnl CXX is set. This is also what CXX gets set to in the generated
-dnl Makefile.
-CROSS_GCC=`echo gcc | sed -e "s/^/$target/"`
-
-dnl Get G++'s full path to libgcc.a
-changequote(,)
-gccpath=`${CROSS_GCC} --print-libgcc | sed -e 
's:[a-z0-9A-Z\.\-]*/libgcc.a::' -e 's:lib/gcc-lib/::'`lib
-changequote([,])
-if test -f $gccpath/libsim.a -o -f $gccpath/libsim.so ; then
-ac_cv_c_simlib="$gccpath/"
-SIMLIB="-L${ac_cv_c_simlib}"
-   AC_MSG_RESULT(${ac_cv_c_simlib})
-else
-AM_CONDITIONAL(PSIM, test x$psim = xno)
-   SIMLIB=""
-   AC_MSG_RESULT(none)
-dnl ac_cv_c_simlib=none
-fi
-fi
-AC_SUBST(SIMLIB)
-])
-
 dnl 
 dnl Find the libiberty library.
 AC_DEFUN([CYG_AC_PATH_LIBIBERTY], [
@@ -476,26 +394,6 @@ fi
 AC_SUBST(LIBIBERTY)
 ])
 
-dnl 
-AC_DEFUN([CYG_AC_PATH_DEVO], [
-AC_MSG_CHECKING(for devo headers in the source tree)
-dirlist=".. ../../ ../../../ ../../../../ ../../../../../ ../../../../../../ 
../../../../../../.. ../../../../../../../.. ../../../../../../../../.. 
../../../../../../../../../.."
-AC_CACHE_VAL(ac_cv_c_devoh,[
-for i in $dirlist; do
-if test -f "${srcdir}/$i/include/remote-sim.h" ; then
-   ac_cv_c_devoh=`(cd ${srcdir}/$i/include; ${PWDCMD-pwd})`
-fi
-done
-])
-if test x"${ac_cv_c_devoh}" != x; then
-DEVOHDIR="-I${ac_cv_c_devoh}"
-AC_MSG_RESULT(${ac_cv_c_devoh})
-else
-AC_MSG_RESULT(none)
-fi
-AC_SUBST(DEVOHDIR)
-])
-
 dnl 
 dnl Find all the ILU headers and libraries
 AC_DEFUN([CYG_AC_PATH_ILU], [
-- 
2.31.1

[PATCH] sim: depend on gnulib

[Mike Frysinger via Gcc-patches]

We're going to start using gnulib in the sim, so make sure it exists.

ChangeLog:

* Makefile.def: Add configure-sim dependency on all-gnulib.
* Makefile.in: Regenerated.
---
 Makefile.def | 1 +
 Makefile.in  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Makefile.def b/Makefile.def
index df8ccfb24c3d..2029ff3a72af 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -541,6 +541,7 @@ dependencies = { module=install-strip-sid; 
on=install-strip-tcl; };
 dependencies = { module=install-sid; on=install-tk; };
 dependencies = { module=install-strip-sid; on=install-strip-tk; };
 
+dependencies = { module=configure-sim; on=all-gnulib; };
 dependencies = { module=configure-sim; on=configure-intl; };
 dependencies = { module=all-sim; on=all-intl; };
 dependencies = { module=all-sim; on=all-libiberty; };
diff --git a/Makefile.in b/Makefile.in
index 047be0255e26..1a08f3bd376a 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -61521,6 +61521,7 @@ install-sid: maybe-install-tcl
 install-strip-sid: maybe-install-strip-tcl
 install-sid: maybe-install-tk
 install-strip-sid: maybe-install-strip-tk
+configure-sim: maybe-all-gnulib
 all-sim: maybe-all-readline
 all-fastjar: maybe-all-build-texinfo
 all-libctf: all-libiberty
-- 
2.31.1

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

[Mike Frysinger via Gcc-patches]

On 26 Apr 2021 19:32, Joseph Myers wrote:
> On Mon, 26 Apr 2021, Nick Clifton via Gcc-patches wrote:
> >   Given that gcc, gdb and now binutils are all now requiring C99 as a
> >   minimum version of C, are there any objections to updating
> >   configure.ac to reflect this ?
> 
> This isn't an objection, since upgrading auto* for the toolchain can be 
> complicated, but note that AC_PROG_CC_C99 is obsolete in Autoconf 2.70 and 
> instead AC_PROG_CC enables C11 mode if supported.  (So moving to the 
> latest Autoconf and Automake releases would supersede this change.)

considering how long it took before we adopted 2.69, seems unlikely we can
upgrade to 2.70.  plus, i think there was a flurry of regression fixes for
2.70, and ideally we'd get a 2.71 ?

as long as we have 2.69, we should move to AC_PROG_CC_C99 in all projects.
-mike

[PATCH] sim: drop dep on configure-gdb

[Mike Frysinger via Gcc-patches]

I'm not entirely sure why this is here since the sim doesn't use
anything from the gdb/ dir directly, and the commit that added it
included a bunch more changes and doesn't seem to call out this
dep specifically.

ChangeLog:

* Makefile.def: Remove all-sim dependency on configure-gdb.
* Makefile.in: Regenerated.
---
 Makefile.def | 1 -
 Makefile.in  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/Makefile.def b/Makefile.def
index 3e38f61193ff..df8ccfb24c3d 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -547,7 +547,6 @@ dependencies = { module=all-sim; on=all-libiberty; };
 dependencies = { module=all-sim; on=all-bfd; };
 dependencies = { module=all-sim; on=all-opcodes; };
 dependencies = { module=all-sim; on=all-readline; };
-dependencies = { module=all-sim; on=configure-gdb; };
 
 // Other host modules.
 dependencies = { module=all-fastjar; on=all-zlib; };
diff --git a/Makefile.in b/Makefile.in
index 03785200dc71..047be0255e26 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -61522,7 +61522,6 @@ install-strip-sid: maybe-install-strip-tcl
 install-sid: maybe-install-tk
 install-strip-sid: maybe-install-strip-tk
 all-sim: maybe-all-readline
-all-sim: maybe-configure-gdb
 all-fastjar: maybe-all-build-texinfo
 all-libctf: all-libiberty
 all-stage1-libctf: all-stage1-libiberty
-- 
2.30.0

Re: V3 [PATCH 3/5] Support the PGO build for binutils+gdb

[Mike Frysinger via Gcc-patches]

On 19 Dec 2020 10:10, H.J. Lu via Gdb-patches wrote:
> --- a/Makefile.in
> +++ b/Makefile.in
>
> +PGO_BUILD_TRAINING_FLAGS_TO_PASS = \
> + PGO_BUILD_TRAINING=yes \
> + CFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CFLAGS)" \
> + CXXFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CXXFLAGS)"
> +
> +# Ignore "make check" errors in PGO training runs.
> +PGO_BUILD_TRAINING_MFLAGS = -i

these lines are in Makefile.in but not Makefile.tpl.  so regenerating
the file causes them to be removed.  can you take a look please ?

$ autogen --version
autogen (GNU AutoGen) 5.18.16
$ autogen Makefile.def
$ git diff
diff --git a/Makefile.in b/Makefile.in
index 0a64fc10e5b0..63565ad525b9 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -437,13 +437,9 @@ PGO_BUILD_TRAINING_CFLAGS:= \
 PGO_BUILD_TRAINING_CXXFLAGS:= \
$(filter-out -specs=%,$(PGO_BUILD_TRAINING_CXXFLAGS))
 PGO_BUILD_TRAINING_FLAGS_TO_PASS = \
-   PGO_BUILD_TRAINING=yes \
CFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CFLAGS)" \
CXXFLAGS_FOR_TARGET="$(PGO_BUILD_TRAINING_CXXFLAGS)"
 
-# Ignore "make check" errors in PGO training runs.
-PGO_BUILD_TRAINING_MFLAGS = -i
-
 # Additional PGO and LTO compiler options to use profiling data for the
 # PGO build.
 PGO_BUILD_USE_FLAGS_TO_PASS = \
@@ -1054,7 +1050,6 @@ all:
$(PGO_BUILD_GEN_FLAGS_TO_PASS) all-host all-target \
 @if pgo-build
&& $(MAKE) $(RECURSE_FLAGS_TO_PASS) \
-   $(PGO_BUILD_TRAINING_MFLAGS) \
$(PGO_BUILD_TRAINING_FLAGS_TO_PASS) \
$(PGO_BUILD_TRAINING) \
&& $(MAKE) $(RECURSE_FLAGS_TO_PASS) clean \
-mike

Re: [PATCH] libiberty: autogenerate aclocal.m4

[Mike Frysinger via Gcc-patches]

On 16 Feb 2021 11:54, Jeff Law wrote:
> On 2/13/21 7:32 PM, Mike Frysinger via Gcc-patches wrote:
> > Move custom macros to acinclude.m4 so we can autogenerate aclocal.m4
> > with aclocal.  This matches every other project in the tree.
> >
> > libiberty/ChangeLog:
> >
> > * Makefile.in (ACLOCAL, ACLOCAL_AMFLAGS, $(srcdir)/aclocal.m4): Define.
> > (configure_deps): Rename to ...
> > (aclocal_deps): ... this.  Replace aclocal.m4 with acinclude.m4.
> > ($(srcdir)/configure): Replace $(configure_deps) with
> > $(srcdir)/aclocal.m4.
> > * aclocal.m4: Move libiberty macros to acinclude.m4, then regenerate.
> > * acinclude.m4: New file.
> > * configure: Regenerate.
> OK for the trunk.
> 
> Do you have commit privs or do you need someone to commit for you?

thanks, i've pushed it now
-mike

[PATCH] gitignore: ignore generated dejagnu test files treewide

[Mike Frysinger via Gcc-patches]

These files are never commited, and are generated by most testsuites,
so ignore them.

ChangeLog:

* .gitignore: Ignore generated dejagnu test files.
---
 .gitignore | 5 +
 1 file changed, 5 insertions(+)

diff --git a/.gitignore b/.gitignore
index 382e2def731e..2d316e0bf881 100644
--- a/.gitignore
+++ b/.gitignore
@@ -66,3 +66,8 @@ stamp-*
 /mpc*
 /gmp*
 /isl*
+
+site.bak
+site.exp
+*.log
+*.sum
-- 
2.30.0

[PATCH] libiberty: autogenerate aclocal.m4

[Mike Frysinger via Gcc-patches]

Move custom macros to acinclude.m4 so we can autogenerate aclocal.m4
with aclocal.  This matches every other project in the tree.

libiberty/ChangeLog:

* Makefile.in (ACLOCAL, ACLOCAL_AMFLAGS, $(srcdir)/aclocal.m4): Define.
(configure_deps): Rename to ...
(aclocal_deps): ... this.  Replace aclocal.m4 with acinclude.m4.
($(srcdir)/configure): Replace $(configure_deps) with
$(srcdir)/aclocal.m4.
* aclocal.m4: Move libiberty macros to acinclude.m4, then regenerate.
* acinclude.m4: New file.
* configure: Regenerate.
---
 libiberty/Makefile.in  |  12 ++-
 libiberty/acinclude.m4 | 185 ++
 libiberty/aclocal.m4   | 198 +
 libiberty/configure|   3 -
 4 files changed, 215 insertions(+), 183 deletions(-)
 create mode 100644 libiberty/acinclude.m4

diff --git a/libiberty/Makefile.in b/libiberty/Makefile.in
index 788590957e17..4f1213b983b6 100644
--- a/libiberty/Makefile.in
+++ b/libiberty/Makefile.in
@@ -481,18 +481,24 @@ config.status: $(srcdir)/configure
$(SHELL) ./config.status --recheck
 
 AUTOCONF = autoconf
-configure_deps = $(srcdir)/aclocal.m4 \
+ACLOCAL = aclocal
+ACLOCAL_AMFLAGS = -I ../config -I ..
+aclocal_deps = \
$(srcdir)/../config/acx.m4 \
$(srcdir)/../config/cet.m4 \
$(srcdir)/../config/enable.m4 \
$(srcdir)/../config/no-executables.m4 \
$(srcdir)/../config/override.m4 \
$(srcdir)/../config/picflag.m4 \
-   $(srcdir)/../config/warnings.m4
+   $(srcdir)/../config/warnings.m4 \
+   $(srcdir)/acinclude.m4
 
-$(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(configure_deps)
+$(srcdir)/configure: @MAINT@ $(srcdir)/configure.ac $(srcdir)/aclocal.m4
cd $(srcdir) && $(AUTOCONF)
 
+$(srcdir)/aclocal.m4: @MAINT@ $(aclocal_deps)
+   cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)
+
 # Depending on config.h makes sure that config.status has been re-run
 # if needed.  This prevents problems with parallel builds, in case
 # subdirectories need to run config.status also.
diff --git a/libiberty/acinclude.m4 b/libiberty/acinclude.m4
new file mode 100644
index ..6db0e5085171
--- /dev/null
+++ b/libiberty/acinclude.m4
@@ -0,0 +1,185 @@
+dnl Copyright (C) 2000-2021 Free Software Foundation, Inc.
+dnl
+dnl GCC is free software; you can redistribute it and/or modify
+dnl it under the terms of the GNU General Public License as published by
+dnl the Free Software Foundation; either version 3, or (at your option)
+dnl any later version.
+dnl
+dnl GCC is distributed in the hope that it will be useful,
+dnl but WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+dnl GNU General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU General Public License
+dnl along with GCC; see the file COPYING3.  If not see
+dnl .
+
+dnl See whether strncmp reads past the end of its string parameters.
+dnl On some versions of SunOS4 at least, strncmp reads a word at a time
+dnl but erroneously reads past the end of strings.  This can cause
+dnl a SEGV in some cases.
+AC_DEFUN([libiberty_AC_FUNC_STRNCMP],
+[AC_REQUIRE([AC_FUNC_MMAP])
+AC_CACHE_CHECK([for working strncmp], ac_cv_func_strncmp_works,
+[AC_TRY_RUN([
+/* Test by Jim Wilson and Kaveh Ghazi.
+   Check whether strncmp reads past the end of its string parameters. */
+#include 
+
+#ifdef HAVE_FCNTL_H
+#include 
+#endif
+
+#ifdef HAVE_SYS_MMAN_H
+#include 
+#endif
+
+#ifndef MAP_ANON
+#ifdef MAP_ANONYMOUS
+#define MAP_ANON MAP_ANONYMOUS
+#else
+#define MAP_ANON MAP_FILE
+#endif
+#endif
+
+#ifndef MAP_FILE
+#define MAP_FILE 0
+#endif
+#ifndef O_RDONLY
+#define O_RDONLY 0
+#endif
+
+#define MAP_LEN 0x1
+
+main ()
+{
+#if defined(HAVE_MMAP) || defined(HAVE_MMAP_ANYWHERE)
+  char *p;
+  int dev_zero;
+
+  dev_zero = open ("/dev/zero", O_RDONLY);
+  if (dev_zero < 0)
+exit (1);
+
+  p = (char *) mmap (0, MAP_LEN, PROT_READ|PROT_WRITE,
+MAP_ANON|MAP_PRIVATE, dev_zero, 0);
+  if (p == (char *)-1)
+p = (char *) mmap (0, MAP_LEN, PROT_READ|PROT_WRITE,
+  MAP_ANON|MAP_PRIVATE, -1, 0);
+  if (p == (char *)-1)
+exit (2);
+  else
+{
+  char *string = "__si_type_info";
+  char *q = (char *) p + MAP_LEN - strlen (string) - 2;
+  char *r = (char *) p + 0xe;
+
+  strcpy (q, string);
+  strcpy (r, string);
+  strncmp (r, q, 14);
+}
+#endif /* HAVE_MMAP || HAVE_MMAP_ANYWHERE */
+  exit (0);
+}
+], ac_cv_func_strncmp_works=yes, ac_cv_func_strncmp_works=no,
+  ac_cv_func_strncmp_works=yes)
+rm -f core core.* *.core])
+if test $ac_cv_func_strncmp_works = no ; then
+  AC_LIBOBJ([strncmp])
+fi
+])
+
+dnl See if errno must be declared even when  is included.
+AC_DEFUN([libiberty_AC_DECLARE_ERRNO],
+[AC_CACHE_CHECK(whether errno must be declared, libiberty_cv

Re: [PATCH] mklog: automatically fill in generated entries

[Mike Frysinger via Gcc-patches]

On 08 Feb 2021 22:44, Joseph Myers wrote:
> On Sun, 7 Feb 2021, Mike Frysinger via Gcc-patches wrote:
> > +# NB: Makefile.in isn't listed as it's not always generated.
> > +generated_files = {'aclocal.m4', 'config.h.in', 'configure'}
> 
> libiberty/aclocal.m4 isn't a generated file either.

that is ... weird.  maybe it's a vintage thing.  any reason it needs
to stay this way ?  looks like it'd be trivial to switch it over to
acinclude.m4.
-mike

[PATCH] mklog: automatically fill in generated entries

[Mike Frysinger via Gcc-patches]

contrib/ChangeLog:

* mklog.py (generated_files): New set.
(generate_changelog): Add entries based on generated_files.
---
 contrib/mklog.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/contrib/mklog.py b/contrib/mklog.py
index a70536a6849a..6509886741d7 100755
--- a/contrib/mklog.py
+++ b/contrib/mklog.py
@@ -55,6 +55,9 @@ bugzilla_url = 
'https://gcc.gnu.org/bugzilla/rest.cgi/bug?id=%s&;' \
 
 function_extensions = {'.c', '.cpp', '.C', '.cc', '.h', '.inc', '.def', '.md'}
 
+# NB: Makefile.in isn't listed as it's not always generated.
+generated_files = {'aclocal.m4', 'config.h.in', 'configure'}
+
 help_message = """\
 Generate ChangeLog template for PATCH.
 PATCH must be generated using diff(1)'s -up or -cp options
@@ -192,6 +195,8 @@ def generate_changelog(data, no_functions=False, 
fill_pr_titles=False):
 if new_path.startswith(changelog):
 new_path = new_path[len(changelog):].lstrip('/')
 out += '\t* %s: ...here.\n' % (new_path)
+elif os.path.basename(file.path) in generated_files:
+out += '\t* %s: Regenerate.\n' % (relative_path)
 else:
 if not no_functions:
 for hunk in file:
-- 
2.30.0

[PATCH] config: import pkg.m4 from pkg-config

[Mike Frysinger]

We use this in the sim tree currently.  Rather than require people to
have pkg-config installed, include it in the config/ dir.

2012-12-23  Mike Frysinger  

* pkg.m4: New file from pkg-config-0.29.2.
---
 config/pkg.m4 | 275 ++
 1 file changed, 275 insertions(+)
 create mode 100644 config/pkg.m4

diff --git a/config/pkg.m4 b/config/pkg.m4
new file mode 100644
index ..13a889017866
--- /dev/null
+++ b/config/pkg.m4
@@ -0,0 +1,275 @@
+# pkg.m4 - Macros to locate and utilise pkg-config.   -*- Autoconf -*-
+# serial 12 (pkg-config-0.29.2)
+
+dnl Copyright ?? 2004 Scott James Remnant .
+dnl Copyright ?? 2012-2015 Dan Nicholson 
+dnl
+dnl This program is free software; you can redistribute it and/or modify
+dnl it under the terms of the GNU General Public License as published by
+dnl the Free Software Foundation; either version 2 of the License, or
+dnl (at your option) any later version.
+dnl
+dnl This program is distributed in the hope that it will be useful, but
+dnl WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+dnl General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU General Public License
+dnl along with this program; if not, write to the Free Software
+dnl Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+dnl 02111-1307, USA.
+dnl
+dnl As a special exception to the GNU General Public License, if you
+dnl distribute this file as part of a program that contains a
+dnl configuration script generated by Autoconf, you may include it under
+dnl the same distribution terms that you use for the rest of that
+dnl program.
+
+dnl PKG_PREREQ(MIN-VERSION)
+dnl ---
+dnl Since: 0.29
+dnl
+dnl Verify that the version of the pkg-config macros are at least
+dnl MIN-VERSION. Unlike PKG_PROG_PKG_CONFIG, which checks the user's
+dnl installed version of pkg-config, this checks the developer's version
+dnl of pkg.m4 when generating configure.
+dnl
+dnl To ensure that this macro is defined, also add:
+dnl m4_ifndef([PKG_PREREQ],
+dnl [m4_fatal([must install pkg-config 0.29 or later before running 
autoconf/autogen])])
+dnl
+dnl See the "Since" comment for each macro you use to see what version
+dnl of the macros you require.
+m4_defun([PKG_PREREQ],
+[m4_define([PKG_MACROS_VERSION], [0.29.2])
+m4_if(m4_version_compare(PKG_MACROS_VERSION, [$1]), -1,
+[m4_fatal([pkg.m4 version $1 or higher is required but 
]PKG_MACROS_VERSION[ found])])
+])dnl PKG_PREREQ
+
+dnl PKG_PROG_PKG_CONFIG([MIN-VERSION])
+dnl --
+dnl Since: 0.16
+dnl
+dnl Search for the pkg-config tool and set the PKG_CONFIG variable to
+dnl first found in the path. Checks that the version of pkg-config found
+dnl is at least MIN-VERSION. If MIN-VERSION is not specified, 0.9.0 is
+dnl used since that's the first version where most current features of
+dnl pkg-config existed.
+AC_DEFUN([PKG_PROG_PKG_CONFIG],
+[m4_pattern_forbid([^_?PKG_[A-Z_]+$])
+m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$])
+m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$])
+AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])
+AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search path])
+AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in search 
path])
+
+if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then
+   AC_PATH_TOOL([PKG_CONFIG], [pkg-config])
+fi
+if test -n "$PKG_CONFIG"; then
+   _pkg_min_version=m4_default([$1], [0.9.0])
+   AC_MSG_CHECKING([pkg-config is at least version $_pkg_min_version])
+   if $PKG_CONFIG --atleast-pkgconfig-version $_pkg_min_version; then
+   AC_MSG_RESULT([yes])
+   else
+   AC_MSG_RESULT([no])
+   PKG_CONFIG=""
+   fi
+fi[]dnl
+])dnl PKG_PROG_PKG_CONFIG
+
+dnl PKG_CHECK_EXISTS(MODULES, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
+dnl ---
+dnl Since: 0.18
+dnl
+dnl Check to see whether a particular set of modules exists. Similar to
+dnl PKG_CHECK_MODULES(), but does not set variables or print errors.
+dnl
+dnl Please remember that m4 expands AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+dnl only at the first occurence in configure.ac, so if the first place
+dnl it's called might be skipped (such as if it is within an "if", you
+dnl have to call PKG_CHECK_EXISTS manually
+AC_DEFUN([PKG_CHECK_EXISTS],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
+if test -n "$PKG_CONFIG" && \
+AC_RUN_LOG([$PKG_CONFIG --exists --print-errors "$1"]); then
+  m4_default([$2], [:])
+m4_ifvaln([$3], [else
+  $3])dnl
+fi])
+
+dnl _PKG_CONFIG([VARIABLE], [COMMAND], [MODULES])
+dnl 

[PATCH] libiberty.h: punt duplicate strverscmp prototype

[Mike Frysinger]

SVN r216772 accidentally copied & pasted this prototype when adding
other ones nearby.

2020-02-13  Mike Frysinger  

* libiberty.h (strverscmp): Delete duplicate prototype.
---
 include/ChangeLog   | 4 
 include/libiberty.h | 5 -
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/include/ChangeLog b/include/ChangeLog
index 3f9382d9ad4c..5094f6ce742f 100644
--- a/include/ChangeLog
+++ b/include/ChangeLog
@@ -1,3 +1,7 @@
+2020-02-13  Mike Frysinger  
+
+   * libiberty.h (strverscmp): Delete duplicate prototype.
+
 2020-02-05  Andrew Burgess  
 
* hashtab.h (htab_remove_elt): Make a parameter const.
diff --git a/include/libiberty.h b/include/libiberty.h
index 141cb886a850..08ede9889213 100644
--- a/include/libiberty.h
+++ b/include/libiberty.h
@@ -706,11 +706,6 @@ extern unsigned long long int strtoull (const char *nptr,
 char **endptr, int base);
 #endif
 
-#if defined(HAVE_DECL_STRVERSCMP) && !HAVE_DECL_STRVERSCMP
-/* Compare version strings.  */
-extern int strverscmp (const char *, const char *);
-#endif
-
 /* Set the title of a process */
 extern void setproctitle (const char *name, ...);
 
-- 
2.23.0

[PATCH] gcc: ada: delete old $(P) reference

[Mike Frysinger]

From: Mike Frysinger 

The P variable was deleted back in Nov 2015 (svn rev 231062),
but its expansion was missed.  Delete those now too.

2017-07-18  Mike Frysinger  

* gcc-interface/Makefile.in ($(P)): Delete
---
 gcc/ada/gcc-interface/Makefile.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/ada/gcc-interface/Makefile.in 
b/gcc/ada/gcc-interface/Makefile.in
index 1c172037d927..b485c18ec21e 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -2643,10 +2643,10 @@ gnatlink-re: ../stamp-tools gnatmake-re
 #  stamp target in the parent directory whenever gnat1 is rebuilt
 
 # Likewise for the tools
-../../gnatmake$(exeext): $(P) b_gnatm.o $(GNATMAKE_OBJS)
+../../gnatmake$(exeext): b_gnatm.o $(GNATMAKE_OBJS)
+$(GCC_LINK) $(ALL_CFLAGS) -o $@ b_gnatm.o $(GNATMAKE_OBJS) 
$(TOOLS_LIBS) $(TOOLS1_LIBS)
 
-../../gnatlink$(exeext): $(P) b_gnatl.o $(GNATLINK_OBJS)
+../../gnatlink$(exeext): b_gnatl.o $(GNATLINK_OBJS)
+$(GCC_LINK) $(ALL_CFLAGS) -o $@ b_gnatl.o $(GNATLINK_OBJS) 
$(TOOLS_LIBS) $(TOOLS1_LIBS)
 
 ../stamp-gnatlib-$(RTSDIR):
-- 
2.12.0

Re: [PATCH PING] boehm-gc: check for execinfo.h directly

[Mike Frysinger]

On 21 Jun 2016 21:10, Jeff Law wrote:
> On 06/21/2016 06:59 PM, Mike Frysinger wrote:
> > On 21 Jun 2016 15:46, Jeff Law wrote:
> >
> >> If accepted into upstream Boehm-GC, then this is obviously acceptable in
> >> GCC's copy.
> >
> > so changes can be pushed directly if it's already in upstream ?
> > my original goal is already fixed in upstream, but it's not in
> > gcc's copy ...
> 
> Yes.  Ideally we'd just resync at some point in the near future, but if 
> you want to cherry-pick a fix from upstream so it gets fixed sooner, 
> that's fine.

great, then i'll cherry pick the fix as it was merged upstream,
and pursue the updated version via upstream's github.
-mike
From cc481b795b819595d2d1a5d671448c9894d1f05c Mon Sep 17 00:00:00 2001
From: Mike Frysinger 
Date: Wed, 22 Jun 2016 10:04:18 -0400
Subject: [PATCH] boehm-gc: pull in upstream fix for uClibc

2007-12-18  Hans Boehm  (really Radek Polak)

	* include/gc.h: Don't define GC_HAVE_BUILTIN_BACKTRACE for uclibc.
---
 boehm-gc/ChangeLog| 4 
 boehm-gc/include/gc.h | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/boehm-gc/ChangeLog b/boehm-gc/ChangeLog
index 6896c67b757a..208b18efd4ea 100644
--- a/boehm-gc/ChangeLog
+++ b/boehm-gc/ChangeLog
@@ -1,3 +1,7 @@
+2016-06-22  Mike Frysinger  
+
+	* include/gc.h: Don't define GC_HAVE_BUILTIN_BACKTRACE for uclibc.
+
 2016-03-29  Samuel Thibault  
 
 	* configure.host: Set gc_use_mmap on *-kfreebsd-gnu* and *-gnu*.
diff --git a/boehm-gc/include/gc.h b/boehm-gc/include/gc.h
index 6b38f2d0e6ca..fca98ffb61d5 100644
--- a/boehm-gc/include/gc.h
+++ b/boehm-gc/include/gc.h
@@ -503,7 +503,7 @@ GC_API GC_PTR GC_malloc_atomic_ignore_off_page GC_PROTO((size_t lb));
 #if defined(__linux__) || defined(__GLIBC__)
 # include 
 # if (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 1 || __GLIBC__ > 2) \
- && !defined(__ia64__)
+ && !defined(__ia64__) && !defined(__UCLIBC__)
 #   ifndef GC_HAVE_BUILTIN_BACKTRACE
 # define GC_HAVE_BUILTIN_BACKTRACE
 #   endif
-- 
2.8.2



signature.asc
Description: Digital signature

Re: [PATCH PING] boehm-gc: check for execinfo.h directly

[Mike Frysinger]

On 21 Jun 2016 15:46, Jeff Law wrote:
> On 06/13/2016 11:40 AM, Mike Frysinger wrote:
> > The current header depends on glibc version checks to determine whether
> > execinfo.h exists which breaks uClibc.  Instead, add an explicit configure
> > check for it.
> >
> > 2015-08-29  Mike Frysinger  
> >
> > * configure.ac: Call AC_CHECK_HEADERS([execinfo.h]).
> > * configure: Regenerated.
> > * include/gc.h [HAVE_EXECINFO_H]: Define GC_HAVE_BUILTIN_BACKTRACE.
> > * include/gc_config.h.in: Regenerated.
> 
> Shouldn't this be going to the upstream Boehm-GC project?  You should be 
> able to find information here on how to get the patch into the official 
> Boehm-GC project:

thanks ... didn't realize this was an embedded upstream project.
i've sent my patch there now:
https://github.com/ivmai/bdwgc/pull/123

> If accepted into upstream Boehm-GC, then this is obviously acceptable in 
> GCC's copy.

so changes can be pushed directly if it's already in upstream ?
my original goal is already fixed in upstream, but it's not in
gcc's copy ...
-mike


signature.asc
Description: Digital signature

[PATCH PING] boehm-gc: check for execinfo.h directly

[Mike Frysinger]

The current header depends on glibc version checks to determine whether
execinfo.h exists which breaks uClibc.  Instead, add an explicit configure
check for it.

2015-08-29  Mike Frysinger  

* configure.ac: Call AC_CHECK_HEADERS([execinfo.h]).
* configure: Regenerated.
* include/gc.h [HAVE_EXECINFO_H]: Define GC_HAVE_BUILTIN_BACKTRACE.
* include/gc_config.h.in: Regenerated.
---
 boehm-gc/configure  | 105 +++-
 boehm-gc/configure.ac   |   3 ++
 boehm-gc/include/gc.h   |   2 +-
 boehm-gc/include/gc_config.h.in |   3 ++
 4 files changed, 110 insertions(+), 3 deletions(-)

diff --git a/boehm-gc/configure b/boehm-gc/configure
index a8e11dab41b3..7d2b1f7401f7 100755
--- a/boehm-gc/configure
+++ b/boehm-gc/configure
@@ -1945,6 +1945,93 @@ $as_echo "$ac_res" >&6; }
   eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset 
as_lineno;}
 
 } # ac_fn_c_check_member
+
+# ac_fn_c_check_header_mongrel LINENO HEADER VAR INCLUDES
+# ---
+# Tests whether HEADER exists, giving a warning if it cannot be compiled using
+# the include files in INCLUDES and setting the cache variable VAR
+# accordingly.
+ac_fn_c_check_header_mongrel ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  if { as_var=$3; eval "test \"\${$as_var+set}\" = set"; }; then :
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if { as_var=$3; eval "test \"\${$as_var+set}\" = set"; }; then :
+  $as_echo_n "(cached) " >&6
+fi
+eval ac_res=\$$3
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+else
+  # Is the header compilable?
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking $2 usability" >&5
+$as_echo_n "checking $2 usability... " >&6; }
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+#include <$2>
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  ac_header_compiler=yes
+else
+  ac_header_compiler=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_header_compiler" >&5
+$as_echo "$ac_header_compiler" >&6; }
+
+# Is the header present?
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking $2 presence" >&5
+$as_echo_n "checking $2 presence... " >&6; }
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include <$2>
+_ACEOF
+if ac_fn_c_try_cpp "$LINENO"; then :
+  ac_header_preproc=yes
+else
+  ac_header_preproc=no
+fi
+rm -f conftest.err conftest.$ac_ext
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_header_preproc" >&5
+$as_echo "$ac_header_preproc" >&6; }
+
+# So?  What about this header?
+case $ac_header_compiler:$ac_header_preproc:$ac_c_preproc_warn_flag in #((
+  yes:no: )
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: accepted by the 
compiler, rejected by the preprocessor!" >&5
+$as_echo "$as_me: WARNING: $2: accepted by the compiler, rejected by the 
preprocessor!" >&2;}
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: proceeding with the 
compiler's result" >&5
+$as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
+;;
+  no:yes:* )
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: present but cannot 
be compiled" >&5
+$as_echo "$as_me: WARNING: $2: present but cannot be compiled" >&2;}
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: check for 
missing prerequisite headers?" >&5
+$as_echo "$as_me: WARNING: $2: check for missing prerequisite headers?" 
>&2;}
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: see the Autoconf 
documentation" >&5
+$as_echo "$as_me: WARNING: $2: see the Autoconf documentation" >&2;}
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: section 
\"Present But Cannot Be Compiled\"" >&5
+$as_echo "$as_me: WARNING: $2: section \"Present But Cannot Be Compiled\"" 
>&2;}
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: proceeding with the 
compiler's result" >&5
+$as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
+;;
+esac
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2.

[PATCH] gcc: invoke: delete -mno-fma4 docs

[Mike Frysinger]

We don't document the -mno-xxx variants for other flags here, and the
paragraph here specifically says "Each has a corresponding -mno- option
to disable use of these instructions".  Drop the -mno-fma4 line.

2016-01-31  Mike Frysinger  

* doc/invoke.texi: Delete -mno-fma4.
---
 gcc/doc/invoke.texi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ba0b4b2..fd05deb 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -23458,9 +23458,6 @@ preferred alignment to 
@option{-mpreferred-stack-boundary=2}.
 @itemx -mfma4
 @opindex mfma4
 @need 200
-@itemx -mno-fma4
-@opindex mno-fma4
-@need 200
 @itemx -mprefetchwt1
 @opindex mprefetchwt1
 @need 200
-- 
2.6.2

Re: [PATCH] longlong: fix sh -Wundef builds

[Mike Frysinger]

On 08 Jan 2016 06:54, Oleg Endo wrote:
> On Jan 8, 2016, at 4:39 AM, Mike Frysinger  wrote:
> > This file fails when building for SuperH as it assumes __SHMEDIA__ is
> > always defined.  Update the code to check if it's defined.
> 
> This is OK for trunk.  Thanks for spotting it.

i had checked only the first case previously (as i don't have sh5
systems), but there's a logic error in the second i fixed before
committing.  this is what i merged:
--- include/longlong.h  (revision 232142)
+++ include/longlong.h  (working copy)
@@ -1086,7 +1086,7 @@ extern UDItype __umulsidi3 (USItype, USI
   } while (0)
 #endif
 
-#if defined(__sh__) && !__SHMEDIA__ && W_TYPE_SIZE == 32
+#if defined(__sh__) && (!defined (__SHMEDIA__) || !__SHMEDIA__) && W_TYPE_SIZE 
== 32
 #ifndef __sh1__
 #define umul_ppmm(w1, w0, u, v) \
   __asm__ (\
@@ -1159,7 +1159,7 @@ extern UDItype __umulsidi3 (USItype, USI
 
 #endif /* __sh__ */
 
-#if defined (__SH5__) && __SHMEDIA__ && W_TYPE_SIZE == 32
+#if defined (__SH5__) && defined (__SHMEDIA__) && __SHMEDIA__ && W_TYPE_SIZE 
== 32
 #define __umulsidi3(u,v) ((UDItype)(USItype)u*(USItype)v)
 #define count_leading_zeros(count, x) \
   do   \
-mike


signature.asc
Description: Digital signature

Re: [PATCH] libiberty: {count,dup,write}argv: constify argv input slightly

[Mike Frysinger]

On 05 Jan 2016 07:32, Ian Lance Taylor wrote:
> On Sat, Jan 2, 2016 at 10:39 PM, Mike Frysinger  wrote:
> > Would be more useful if we could use "const char * const *", but there's
> > a long standing bug where gcc warns about incompatible pointers when you
> > try to pass in "char **".
> 
> That's not a bug.  It's how C works.  http://c-faq.com/ansi/constmismatch.html

i'm referring to the bugs filed/discussing the issue in the gcc tracker.
i'm aware of the (crap) standards.

> > We can at least constify the array itself as
> > gcc will not warn in that case.
> >
> > include/:
> > 2016-01-03  Mike Frysinger  
> >
> > * libiberty.h (dupargv): Change arg to char * const *.
> > (writeargv, countargv): Likewise.
> >
> > libiberty/:
> > 2016-01-03  Mike Frysinger  
> >
> > * argv.c (dupargv): Change arg to char * const *.  Update comment.
> > (writeargv, countargv): Likewise.
> > * functions.texi (dupargv, writeargv, countargv): Likewise.
> 
> This is OK if it bootstraps.  Thanks.

i've been testing this in gdb because gcc doesn't actually use dupargv or
countargv.  it does use writeargv in all of three places.

that said, it does bootstrap
-mike


signature.asc
Description: Digital signature

[PATCH] libiberty: {count,dup,write}argv: constify argv input slightly

[Mike Frysinger]

Would be more useful if we could use "const char * const *", but there's
a long standing bug where gcc warns about incompatible pointers when you
try to pass in "char **".  We can at least constify the array itself as
gcc will not warn in that case.

include/:
2016-01-03  Mike Frysinger  

* libiberty.h (dupargv): Change arg to char * const *.
(writeargv, countargv): Likewise.

libiberty/:
2016-01-03  Mike Frysinger  

* argv.c (dupargv): Change arg to char * const *.  Update comment.
(writeargv, countargv): Likewise.
* functions.texi (dupargv, writeargv, countargv): Likewise.
---
 include/libiberty.h  |  6 +++---
 libiberty/argv.c | 12 ++--
 libiberty/functions.texi |  6 +++---
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/include/libiberty.h b/include/libiberty.h
index 8e096a0..a9c885f 100644
--- a/include/libiberty.h
+++ b/include/libiberty.h
@@ -80,7 +80,7 @@ extern void freeargv (char **);
 /* Duplicate an argument vector. Allocates memory using malloc.  Use
freeargv to free the vector.  */
 
-extern char **dupargv (char **) ATTRIBUTE_MALLOC;
+extern char **dupargv (char * const *) ATTRIBUTE_MALLOC;
 
 /* Expand "@file" arguments in argv.  */
 
@@ -88,11 +88,11 @@ extern void expandargv (int *, char ***);
 
 /* Write argv to an @-file, inserting necessary quoting.  */
 
-extern int writeargv (char **, FILE *);
+extern int writeargv (char * const *, FILE *);
 
 /* Return the number of elements in argv.  */
 
-extern int countargv (char**);
+extern int countargv (char * const *);
 
 /* Return the last component of a path name.  Note that we can't use a
prototype here because the parameter is declared inconsistently
diff --git a/libiberty/argv.c b/libiberty/argv.c
index 5c3dd70..994dd35 100644
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -49,7 +49,7 @@ Boston, MA 02110-1301, USA.  */
 
 /*
 
-@deftypefn Extension char** dupargv (char **@var{vector})
+@deftypefn Extension char** dupargv (char * const *@var{vector})
 
 Duplicate an argument vector.  Simply scans through @var{vector},
 duplicating each argument until the terminating @code{NULL} is found.
@@ -62,7 +62,7 @@ argument vector.
 */
 
 char **
-dupargv (char **argv)
+dupargv (char * const *argv)
 {
   int argc;
   char **copy;
@@ -279,7 +279,7 @@ char **buildargv (const char *input)
 
 /*
 
-@deftypefn Extension int writeargv (const char **@var{argv}, FILE *@var{file})
+@deftypefn Extension int writeargv (char * const *@var{argv}, FILE *@var{file})
 
 Write each member of ARGV, handling all necessary quoting, to the file
 named by FILE, separated by whitespace.  Return 0 on success, non-zero
@@ -290,7 +290,7 @@ if an error occurred while writing to FILE.
 */
 
 int
-writeargv (char **argv, FILE *f)
+writeargv (char * const *argv, FILE *f)
 {
   int status = 0;
 
@@ -463,7 +463,7 @@ expandargv (int *argcp, char ***argvp)
 
 /*
 
-@deftypefn Extension int countargv (char **@var{argv})
+@deftypefn Extension int countargv (char * const *@var{argv})
 
 Return the number of elements in @var{argv}.
 Returns zero if @var{argv} is NULL.
@@ -473,7 +473,7 @@ Returns zero if @var{argv} is NULL.
 */
 
 int
-countargv (char **argv)
+countargv (char * const *argv)
 {
   int argc;
 
diff --git a/libiberty/functions.texi b/libiberty/functions.texi
index b5f4e80..24dcc37 100644
--- a/libiberty/functions.texi
+++ b/libiberty/functions.texi
@@ -176,7 +176,7 @@ Concatenate zero or more of strings and return the result 
in freshly
 @end deftypefn
 
 @c argv.c:470
-@deftypefn Extension int countargv (char **@var{argv})
+@deftypefn Extension int countargv (char * const *@var{argv})
 
 Return the number of elements in @var{argv}.
 Returns zero if @var{argv} is NULL.
@@ -213,7 +213,7 @@ make it easy to compose the values of multiple blocks.
 @end deftypefn
 
 @c argv.c:52
-@deftypefn Extension char** dupargv (char **@var{vector})
+@deftypefn Extension char** dupargv (char * const *@var{vector})
 
 Duplicate an argument vector.  Simply scans through @var{vector},
 duplicating each argument until the terminating @code{NULL} is found.
@@ -1915,7 +1915,7 @@ does the return value.  The third argument is unused in 
@libib{}.
 @end deftypefn
 
 @c argv.c:286
-@deftypefn Extension int writeargv (const char **@var{argv}, FILE *@var{file})
+@deftypefn Extension int writeargv (char * const *@var{argv}, FILE *@var{file})
 
 Write each member of ARGV, handling all necessary quoting, to the file
 named by FILE, separated by whitespace.  Return 0 on success, non-zero
-- 
2.6.2

[PATCH] libiberty: dupargv: rewrite to use xstrdup

[Mike Frysinger]

This func is basically open coding the xstrdup function, so gut it
and use it directly.

2016-01-03  Mike Frysinger  

* argv.c (dupargv): Replace strlen/xmalloc/strcpy with xstrdup.
---
 libiberty/argv.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/libiberty/argv.c b/libiberty/argv.c
index f2727e8..5c3dd70 100644
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -76,11 +76,7 @@ dupargv (char **argv)
 
   /* the strings */
   for (argc = 0; argv[argc] != NULL; argc++)
-{
-  int len = strlen (argv[argc]);
-  copy[argc] = (char *) xmalloc (len + 1);
-  strcpy (copy[argc], argv[argc]);
-}
+copy[argc] = xstrdup (argv[argc]);
   copy[argc] = NULL;
   return copy;
 }
-- 
2.6.2

[PATCH] cfns: fix mismatch in gnu_inline attributes

[Mike Frysinger]

Since the 3.0.3 release of gperf (made in May 2007), the generated func
has had the gnu_inline attribute applied to it.  The gcc source however
has not been updated to include that which has lead to a mismatch.

In practice, this hasn't been an issue for two reasons:
(1) Before gcc-5, the default standard was (gnu) C89, and gcc does not
warn or throw an error in this mode.
(2) Starting with gcc-4.8, the compiler driver used to build gcc was
changed to C++, and g++ does not warn or throw an error in this mode.

This error does show up though when using gcc-5 to build gcc-4.7 or
older as then the default is (gnu) C11 and the C compiler driver is
used.  That failure looks like:
In file included from .../gcc-4.7.4/gcc/cp/except.c:990:0:
cfns.gperf: At top level:
cfns.gperf:101:1: error: 'gnu_inline' attribute present on 'libc_name_p'
cfns.gperf:26:14: error: but not here

Whether the compiler should always emit this error regardless of the
active standard or compiler driver is debatable (I think it should be
consistent -- either always do it or never do it).

2015-08-06  Mike Frysinger  

* cfns.gperf [__GNUC__, __GNUC_STDC_INLINE__]: Apply the
__gnu_inline__ attribute.
* cfns.h: Regenerated.
---
 gcc/cp/cfns.gperf | 3 +++
 gcc/cp/cfns.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/gcc/cp/cfns.gperf b/gcc/cp/cfns.gperf
index 68acd3d..953262f 100644
--- a/gcc/cp/cfns.gperf
+++ b/gcc/cp/cfns.gperf
@@ -22,6 +22,9 @@ __inline
 static unsigned int hash (const char *, unsigned int);
 #ifdef __GNUC__
 __inline
+#ifdef __GNUC_STDC_INLINE__
+__attribute__ ((__gnu_inline__))
+#endif
 #endif
 const char * libc_name_p (const char *, unsigned int);
 %}
diff --git a/gcc/cp/cfns.h b/gcc/cp/cfns.h
index 1c6665d..6d00c0e 100644
--- a/gcc/cp/cfns.h
+++ b/gcc/cp/cfns.h
@@ -53,6 +53,9 @@ __inline
 static unsigned int hash (const char *, unsigned int);
 #ifdef __GNUC__
 __inline
+#ifdef __GNUC_STDC_INLINE__
+__attribute__ ((__gnu_inline__))
+#endif
 #endif
 const char * libc_name_p (const char *, unsigned int);
 /* maximum key range = 391, duplicates = 0 */
-- 
2.6.2

[PATCH] gcc: configure: fix test == bashisms

[Mike Frysinger]

---
 gcc/ChangeLog| 5 +
 gcc/configure| 4 ++--
 gcc/configure.ac | 4 ++--
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ea15ada..e3a0432 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2015-11-10  Mike Frysinger  
+
+   * configure.ac: Use = with test and not ==.
+   * configure: Regenerated.
+
 2015-11-11  David Edelsohn  
 
* config/rs6000/aix.h (TARGET_OS_AIX_CPP_BUILTINS): Add cpu and
diff --git a/gcc/configure b/gcc/configure
index 0cd85fb..4b4e724 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -28329,7 +28329,7 @@ else
   enable_default_ssp=no
 fi
 
-if test x$enable_default_ssp == xyes ; then
+if test x$enable_default_ssp = xyes ; then
 
 $as_echo "#define ENABLE_DEFAULT_SSP 1" >>confdefs.h
 
@@ -29181,7 +29181,7 @@ else
   enable_default_pie=no
 fi
 
-if test x$enable_default_pie == xyes ; then
+if test x$enable_default_pie = xyes ; then
 
 $as_echo "#define ENABLE_DEFAULT_PIE 1" >>confdefs.h
 
diff --git a/gcc/configure.ac b/gcc/configure.ac
index ed2e665b..42d8f13 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5463,7 +5463,7 @@ else
   enable_default_ssp=no
 fi],
 enable_default_ssp=no)
-if test x$enable_default_ssp == xyes ; then
+if test x$enable_default_ssp = xyes ; then
   AC_DEFINE(ENABLE_DEFAULT_SSP, 1,
   [Define if your target supports default stack protector and it is 
enabled.])
 fi
@@ -6028,7 +6028,7 @@ AC_ARG_ENABLE(default-pie,
   [enable Position Independent Executable as default])],
 enable_default_pie=$enableval,
 enable_default_pie=no)
-if test x$enable_default_pie == xyes ; then
+if test x$enable_default_pie = xyes ; then
   AC_DEFINE(ENABLE_DEFAULT_PIE, 1,
   [Define if your target supports default PIE and it is enabled.])
 fi
-- 
2.6.2

Re: [PATCH] libjava: fix locale handling when sorting JNI methods

[Mike Frysinger]

On 26 Oct 2015 12:10, Tom Tromey wrote:
> Mike> URL: https://bugs.gentoo.org/563710
> Mike> Reported-by: Miroslav Šulc 
> 
> Mike> 2015-10-22  Mike Frysinger  
> 
> Mike> * scripts/check_jni_methods.sh.in: Run sort with LC_ALL=C, and
> Mike> combine `sort|uniq` into `sort -u`.
> Mike> ---
> Mike>  libjava/classpath/scripts/check_jni_methods.sh.in | 4 ++--
> 
> Just FYI - Classpath changes should also go upstream.

i sent it to Andrew & cc-ed their patches list independently now
-mike


signature.asc
Description: Digital signature

[PATCH] libjava: fix locale handling when sorting JNI methods

[Mike Frysinger]

When building under LANG=cs_CZ.UTF-8, the JNI method check fails:

/bin/bash ../../scripts/check_jni_methods.sh
Found a problem with the JNI methods declared and implemented.
(<) missing in implementation, (>) missing in header files
> Java_gnu_java_awt_peer_gtk_GtkClipboard_advertiseContent
> Java_gnu_java_awt_peer_gtk_GtkClipboard_initNativeState
... lots more ...

While the sed commands are run under LC_ALL=C, the two sort commands are
not, and they end up producing unexpected output (for the test).  Once we
run both under LC_ALL=C, the check passes.  While we're here, we can also
combine latter the `sort|uniq` into `sort -u` to match the earlier code.

URL: https://bugs.gentoo.org/563710
Reported-by: Miroslav Šulc 

2015-10-22  Mike Frysinger  

* scripts/check_jni_methods.sh.in: Run sort with LC_ALL=C, and
combine `sort|uniq` into `sort -u`.
---
 libjava/classpath/scripts/check_jni_methods.sh.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libjava/classpath/scripts/check_jni_methods.sh.in 
b/libjava/classpath/scripts/check_jni_methods.sh.in
index facf34b..18834f2 100644
--- a/libjava/classpath/scripts/check_jni_methods.sh.in
+++ b/libjava/classpath/scripts/check_jni_methods.sh.in
@@ -14,7 +14,7 @@ grep -h '^JNIEXPORT .* Java_' @abs_top_srcdir@/include/*.h | \
 LC_ALL=C sed -e 's,.*JNICALL \(Java_[a-z_A-Z0-9]*\).*$,\1,' > $TMPFILE
 grep -h '^JNIEXPORT .* Java_' @abs_top_builddir@/include/*.h | \
 LC_ALL=C sed -e 's,.*JNICALL \(Java_[a-z_A-Z0-9]*\).*$,\1,' >> $TMPFILE
-sort -u $TMPFILE > $TMPFILE4
+LC_ALL=C sort -u $TMPFILE > $TMPFILE4
 mv $TMPFILE4 $TMPFILE
 
 # Find all methods in the JNI C source files.
@@ -31,7 +31,7 @@ find @abs_top_srcdir@/native/jni -name \*.cpp | \
cut -f4 -d\  | \
 LC_ALL=C sed -e 's,^\JNIEXPORT .* JNICALL 
\(Java_[a-z_A-Z0-9]*\).*$,\1,' >> $TMPFILE2
 mv $TMPFILE2 $TMPFILE3
-sort $TMPFILE3 | uniq > $TMPFILE2
+LC_ALL=C sort $TMPFILE3 > $TMPFILE2
 rm $TMPFILE3
 
 # Write temporary ignore file.
-- 
2.5.2

[PATCH] gcc: doc: add missing space in asan-stack desc

[Mike Frysinger]

Committed as obvious.
---
 gcc/ChangeLog   | 4 
 gcc/doc/invoke.texi | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fdc0209..2e7230b 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2015-08-31  Mike Frysinger  
+
+   * doc/invoke.texi (asan-stack): Add space before option.
+
 2015-08-31  Marc Glisse  
 
* tree.h (zerop): New function.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c0ec0fd..101335e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10949,7 +10949,7 @@ To disable global objects protection use 
@option{--param asan-globals=0}.
 
 @item asan-stack
 Enable buffer overflow detection for stack objects.  This kind of
-protection is enabled by default when using@option{-fsanitize=address}.
+protection is enabled by default when using @option{-fsanitize=address}.
 To disable stack protection use @option{--param asan-stack=0} option.
 
 @item asan-instrument-reads
-- 
2.5.0

[PATCH] boehm-gc: check for execinfo.h directly

[Mike Frysinger]

The current header depends on glibc version checks to determine whether
execinfo.h exists which breaks uClibc.  Instead, add an explicit configure
check for it.

2015-08-29  Mike Frysinger  

* configure.ac: Call AC_CHECK_HEADERS([execinfo.h]).
* configure: Regenerated.
* include/gc.h [HAVE_EXECINFO_H]: Define GC_HAVE_BUILTIN_BACKTRACE.
* include/gc_config.h.in: Regenerated.
---
 boehm-gc/configure  | 105 +++-
 boehm-gc/configure.ac   |   3 ++
 boehm-gc/include/gc.h   |   2 +-
 boehm-gc/include/gc_config.h.in |   3 ++
 4 files changed, 110 insertions(+), 3 deletions(-)

diff --git a/boehm-gc/configure b/boehm-gc/configure
index a8e11da..7d2b1f7 100755
--- a/boehm-gc/configure
+++ b/boehm-gc/configure
@@ -1945,6 +1945,93 @@ $as_echo "$ac_res" >&6; }
   eval $as_lineno_stack; test "x$as_lineno_stack" = x && { as_lineno=; unset 
as_lineno;}
 
 } # ac_fn_c_check_member
+
+# ac_fn_c_check_header_mongrel LINENO HEADER VAR INCLUDES
+# ---
+# Tests whether HEADER exists, giving a warning if it cannot be compiled using
+# the include files in INCLUDES and setting the cache variable VAR
+# accordingly.
+ac_fn_c_check_header_mongrel ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  if { as_var=$3; eval "test \"\${$as_var+set}\" = set"; }; then :
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2... " >&6; }
+if { as_var=$3; eval "test \"\${$as_var+set}\" = set"; }; then :
+  $as_echo_n "(cached) " >&6
+fi
+eval ac_res=\$$3
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_res" >&5
+$as_echo "$ac_res" >&6; }
+else
+  # Is the header compilable?
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking $2 usability" >&5
+$as_echo_n "checking $2 usability... " >&6; }
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+$4
+#include <$2>
+_ACEOF
+if ac_fn_c_try_compile "$LINENO"; then :
+  ac_header_compiler=yes
+else
+  ac_header_compiler=no
+fi
+rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_header_compiler" >&5
+$as_echo "$ac_header_compiler" >&6; }
+
+# Is the header present?
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking $2 presence" >&5
+$as_echo_n "checking $2 presence... " >&6; }
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include <$2>
+_ACEOF
+if ac_fn_c_try_cpp "$LINENO"; then :
+  ac_header_preproc=yes
+else
+  ac_header_preproc=no
+fi
+rm -f conftest.err conftest.$ac_ext
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_header_preproc" >&5
+$as_echo "$ac_header_preproc" >&6; }
+
+# So?  What about this header?
+case $ac_header_compiler:$ac_header_preproc:$ac_c_preproc_warn_flag in #((
+  yes:no: )
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: accepted by the 
compiler, rejected by the preprocessor!" >&5
+$as_echo "$as_me: WARNING: $2: accepted by the compiler, rejected by the 
preprocessor!" >&2;}
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: proceeding with the 
compiler's result" >&5
+$as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
+;;
+  no:yes:* )
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: present but cannot 
be compiled" >&5
+$as_echo "$as_me: WARNING: $2: present but cannot be compiled" >&2;}
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: check for 
missing prerequisite headers?" >&5
+$as_echo "$as_me: WARNING: $2: check for missing prerequisite headers?" 
>&2;}
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: see the Autoconf 
documentation" >&5
+$as_echo "$as_me: WARNING: $2: see the Autoconf documentation" >&2;}
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: section 
\"Present But Cannot Be Compiled\"" >&5
+$as_echo "$as_me: WARNING: $2: section \"Present But Cannot Be Compiled\"" 
>&2;}
+{ $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: $2: proceeding with the 
compiler's result" >&5
+$as_echo "$as_me: WARNING: $2: proceeding with the compiler's result" >&2;}
+;;
+esac
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking for $2" >&5
+$as_echo_n "checking for $2.

[PATCH] cfns: fix mismatch in gnu_inline attributes

[Mike Frysinger]

Since the 3.0.3 release of gperf (made in May 2007), the generated func
has had the gnu_inline attribute applied to it.  The gcc source however
has not been updated to include that which has lead to a mismatch.

In practice, this hasn't been an issue for two reasons:
(1) Before gcc-5, the default standard was (gnu) C89, and gcc does not
warn or throw an error in this mode.
(2) Starting with gcc-4.8, the compiler driver used to build gcc was
changed to C++, and g++ does not warn or throw an error in this mode.

This error does show up though when using gcc-5 to build gcc-4.7 or
older as then the default is (gnu) C11 and the C compiler driver is
used.  That failure looks like:
In file included from .../gcc-4.7.4/gcc/cp/except.c:990:0:
cfns.gperf: At top level:
cfns.gperf:101:1: error: 'gnu_inline' attribute present on 'libc_name_p'
cfns.gperf:26:14: error: but not here

Whether the compiler should always emit this error regardless of the
active standard or compiler driver is debatable (I think it should be
consistent -- either always do it or never do it).

2015-08-06  Mike Frysinger  

* cfns.gperf [__GNUC__, __GNUC_STDC_INLINE__]: Apply the
__gnu_inline__ attribute.
* cfns.h: Regenerated.
---
 gcc/cp/cfns.gperf | 3 +++
 gcc/cp/cfns.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/gcc/cp/cfns.gperf b/gcc/cp/cfns.gperf
index 68acd3d..953262f 100644
--- a/gcc/cp/cfns.gperf
+++ b/gcc/cp/cfns.gperf
@@ -22,6 +22,9 @@ __inline
 static unsigned int hash (const char *, unsigned int);
 #ifdef __GNUC__
 __inline
+#ifdef __GNUC_STDC_INLINE__
+__attribute__ ((__gnu_inline__))
+#endif
 #endif
 const char * libc_name_p (const char *, unsigned int);
 %}
diff --git a/gcc/cp/cfns.h b/gcc/cp/cfns.h
index 1c6665d..6d00c0e 100644
--- a/gcc/cp/cfns.h
+++ b/gcc/cp/cfns.h
@@ -53,6 +53,9 @@ __inline
 static unsigned int hash (const char *, unsigned int);
 #ifdef __GNUC__
 __inline
+#ifdef __GNUC_STDC_INLINE__
+__attribute__ ((__gnu_inline__))
+#endif
 #endif
 const char * libc_name_p (const char *, unsigned int);
 /* maximum key range = 391, duplicates = 0 */
-- 
2.4.4

Re: [PATCH] gcc: fix building w/isl-0.15

[Mike Frysinger]

On 21 Jul 2015 12:33, Jeff Law wrote:
> On 07/14/2015 08:45 AM, Mike Frysinger wrote:
> > ---
> >   gcc/config.in   |  6 ++
> >   gcc/configure   | 31 +++
> >   gcc/configure.ac| 14 ++
> >   gcc/graphite-dependences.c  | 14 +++---
> >   gcc/graphite-optimize-isl.c |  8 ++--
> >   gcc/graphite-poly.h |  5 +
> >   6 files changed, 69 insertions(+), 9 deletions(-)
>
> Thanks.  I needed Bernhard's follow-up to get a successful build with 
> isl-0.15 installed.
> 
> For testing I verified there were no regressions using bootstrapped 
> compilers built with isl-0.13 vs isl-0.15.  I also verified that GCC 
> would bootstrap with the patch installed, but no ISL installed.

thanks for the extensive testing :).  i largely only validated gcc-5.2 with
with 0.13 and 0.15 and even then was smoke tests (rebuilding itself and other
packages).
-mike


signature.asc
Description: Digital signature

[PATCH] gcc: fix building w/isl-0.15

[Mike Frysinger]

---
 gcc/config.in   |  6 ++
 gcc/configure   | 31 +++
 gcc/configure.ac| 14 ++
 gcc/graphite-dependences.c  | 14 +++---
 gcc/graphite-optimize-isl.c |  8 ++--
 gcc/graphite-poly.h |  5 +
 6 files changed, 69 insertions(+), 9 deletions(-)

diff --git a/gcc/config.in b/gcc/config.in
index b031a62..23e1757 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -1326,6 +1326,12 @@
 #endif
 
 
+/* Define if isl_options_set_schedule_serialize_sccs exists. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS
+#endif
+
+
 /* Define if isl_schedule_constraints_compute_schedule exists. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE
diff --git a/gcc/configure b/gcc/configure
index 9561e5c..6e81298 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -28456,6 +28456,8 @@ fi
 
 # Check whether isl_schedule_constraints_compute_schedule is available;
 # it's new in ISL-0.13.
+# Check whether isl_options_set_schedule_serialize_sccs is available;
+# it's new in ISL-0.15.
 if test "x${ISLLIBS}" != "x" ; then
   saved_CXXFLAGS="$CXXFLAGS"
   CXXFLAGS="$CXXFLAGS $ISLINC"
@@ -28485,6 +28487,29 @@ rm -f core conftest.err conftest.$ac_objext \
   { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$ac_has_isl_schedule_constraints_compute_schedule" >&5
 $as_echo "$ac_has_isl_schedule_constraints_compute_schedule" >&6; }
 
+  { $as_echo "$as_me:${as_lineno-$LINENO}: checking Checking for 
isl_options_set_schedule_serialize_sccs" >&5
+$as_echo_n "checking Checking for isl_options_set_schedule_serialize_sccs... " 
>&6; }
+  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+#include 
+int
+main ()
+{
+isl_options_set_schedule_serialize_sccs (NULL, 0);
+  ;
+  return 0;
+}
+_ACEOF
+if ac_fn_cxx_try_link "$LINENO"; then :
+  ac_has_isl_options_set_schedule_serialize_sccs=yes
+else
+  ac_has_isl_options_set_schedule_serialize_sccs=no
+fi
+rm -f core conftest.err conftest.$ac_objext \
+conftest$ac_exeext conftest.$ac_ext
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$ac_has_isl_options_set_schedule_serialize_sccs" >&5
+$as_echo "$ac_has_isl_options_set_schedule_serialize_sccs" >&6; }
+
   LIBS="$saved_LIBS"
   CXXFLAGS="$saved_CXXFLAGS"
 
@@ -28493,6 +28518,12 @@ $as_echo 
"$ac_has_isl_schedule_constraints_compute_schedule" >&6; }
 $as_echo "#define HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE 1" >>confdefs.h
 
   fi
+
+  if test x"$ac_has_isl_options_set_schedule_serialize_sccs" = x"yes"; then
+
+$as_echo "#define HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS 1" >>confdefs.h
+
+  fi
 fi
 
 # Check for plugin support
diff --git a/gcc/configure.ac b/gcc/configure.ac
index cb14639..7fb964a 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5725,6 +5725,8 @@ fi
 
 # Check whether isl_schedule_constraints_compute_schedule is available;
 # it's new in ISL-0.13.
+# Check whether isl_options_set_schedule_serialize_sccs is available;
+# it's new in ISL-0.15.
 if test "x${ISLLIBS}" != "x" ; then
   saved_CXXFLAGS="$CXXFLAGS"
   CXXFLAGS="$CXXFLAGS $ISLINC"
@@ -5738,6 +5740,13 @@ if test "x${ISLLIBS}" != "x" ; then
   [ac_has_isl_schedule_constraints_compute_schedule=no])
   AC_MSG_RESULT($ac_has_isl_schedule_constraints_compute_schedule)
 
+  AC_MSG_CHECKING([Checking for isl_options_set_schedule_serialize_sccs])
+  AC_TRY_LINK([#include ],
+  [isl_options_set_schedule_serialize_sccs (NULL, 0);],
+  [ac_has_isl_options_set_schedule_serialize_sccs=yes],
+  [ac_has_isl_options_set_schedule_serialize_sccs=no])
+  AC_MSG_RESULT($ac_has_isl_options_set_schedule_serialize_sccs)
+
   LIBS="$saved_LIBS"
   CXXFLAGS="$saved_CXXFLAGS"
 
@@ -5745,6 +5754,11 @@ if test "x${ISLLIBS}" != "x" ; then
  AC_DEFINE(HAVE_ISL_SCHED_CONSTRAINTS_COMPUTE_SCHEDULE, 1,
[Define if isl_schedule_constraints_compute_schedule exists.])
   fi
+
+  if test x"$ac_has_isl_options_set_schedule_serialize_sccs" = x"yes"; then
+ AC_DEFINE(HAVE_ISL_OPTIONS_SET_SCHEDULE_SERIALIZE_SCCS, 1,
+   [Define if isl_options_set_schedule_serialize_sccs exists.])
+  fi
 fi
 
 GCC_ENABLE_PLUGINS
diff --git a/gcc/graphite-dependences.c b/gcc/graphite-dependences.c
index 50fe73e..9a0986d 100644
--- a/gcc/graphite-dependences.c
+++ b/gcc/graphite-dependences.c
@@ -205,7 +205,7 @@ scop_get_transformed_schedule (scop_p scop, vec 
pbbs)
 /* Helper function used on each MAP of a isl_union_map.  Computes the
maximal output dimension.  */
 
-static int
+static isl_stat
 max_number_of_out_dimensions (__isl_take isl_map *map, void *user)
 {
   int global_max = *((int *) user);
@@ -217,7 +217,7 @@ max_number_of_out_dimensions (__isl_take isl_map *map, void 
*user)
 
   isl_map_free (map);
   isl_space_free (space);
-  return 0;
+  return isl_stat_ok;
 }
 
 /* Extends the output dimension of MAP to MAX dimensions.  */
@@ -241,12 +241,12 @

Re: [PATCH] nios2-linux: add missing cpp specs

[Mike Frysinger]

On 30 May 2015 09:38, Sandra Loosemore wrote:
> On 05/29/2015 09:28 PM, Mike Frysinger wrote:
> > On 29 May 2015 12:32, Sandra Loosemore wrote:
> >> On 05/29/2015 11:36 AM, Mike Frysinger wrote:
> >>> On 29 May 2015 08:44, Sandra Loosemore wrote:
> >>>> On 05/27/2015 10:00 AM, Mike Frysinger wrote:
> >>>>> Define CPP_SPEC for nios2 linux targets so that -posix & -pthread work
> >>>>> like on all other linux targets.
> >>>>>
> >>>>> 2015-05-27  Mike Frysinger  
> >>>>>
> >>>>> * config/nios2/linux.h (CPP_SPEC): Define.
> >>>>
> >>>> I see that -posix is not documented at all in invoke.texi and -pthread
> >>>> is documented only for RS6000 and Solaris (which is not Linux).  What,
> >>>> exactly, are these options supposed to do on "all other linux targets"?
> >>>> If these options are supposed to be generic to all Linux targets,
> >>>> can't they be handled in some common way instead of duplicating the
> >>>> CPP_SPEC code in all the individual back ends?
> >>>
> >>> please see my other threads/patches
> >>
> >> (Sorry, I am a few days behind in mailing list traffic, was just trying
> >> to respond to the review request that was CC'ed to me directly.)
> >>
> >> Do you mean this one?
> >>
> >> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02708.html
> >
> > yes
> >
> >> That addresses my concern about not duplicating this in every back end,
> >> but I still don't see any documentation and don't really understand what
> >> these flags are supposed to do or why I might need to add them to my
> >> command line.  Taking off my nios2 maintainer hat and putting on the
> >> docs maintainer one instead, I think proper documentation for these
> >> options is a requirement here
> >
> > i'm not familiar with the history.  i'm merely cleaning up some of the mess.
> > both defines are respected by glibc and make a difference to compilation.
> 
> I see that the glibc manual does document the preprocessor macros, but 
> it doesn't look like glibc either uses or documents the use of special 
> GCC command-line options, so I am still confused about why we need these 
> options.  However, if using these command-line options on targets where 
> they previously have existed is common practice, I have no real 
> objection to adding them to nios2 as well.
> 
> But, please note that the GCC coding conventions
> 
> https://gcc.gnu.org/codingconventions.html#Documentation
> 
> explicitly requires documentation for all command-line options.
> 
> So, if you are cleaning up the mess to generalize the implementation of 
> these options so that they are no longer confined to a few specific 
> targets, you must also move the documentation for these options out of 
> the back-end-specific part of the manual and make sure it accurately 
> reflects the current purpose and usage of these options.

it's not that i disagree with anything you're saying wrt documentation -- the 
situation is pretty bad.  it's that i think it's not directly impacted by my
changes.  my cleanups also do not really move them out of the back end ...
they still only work for gnu/linux type targets.  so while we should see about 
fixing the docs, i don't think my patch should depend on that considering (1) 
it's an obvious (imo) improvement and (2) the docs have always been broken.
-mike


signature.asc
Description: Digital signature

[PATCH] netbsd: respect -symbolic

[Mike Frysinger]

The current netbsd elf spec doesn't respect -symbolic which prevents
passing -Bsymbolic down to the linker.  This causes problems when you
try to link the runtime linker as it creates an ELF with incorrect
sections in it leading it to crash at startup.

2015-05-30  Benigno B. Junior  

* config/netbsd-elf.h (NETBSD_LINK_SPEC_ELF): Turn -symbolic into
-Bsymbolic.
---
 gcc/config/netbsd-elf.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/config/netbsd-elf.h b/gcc/config/netbsd-elf.h
index ea09429..a679bbd 100644
--- a/gcc/config/netbsd-elf.h
+++ b/gcc/config/netbsd-elf.h
@@ -70,6 +70,7 @@ along with GCC; see the file COPYING3.  If not see
 #define NETBSD_LINK_SPEC_ELF \
   "%{assert*} %{R*} %{rpath*} \
%{shared:-shared} \
+   %{symbolic:-Bsymbolic} \
%{!shared: \
  -dc -dp \
  %{!nostdlib: \
-- 
2.4.1

Re: [PATCH] nios2-linux: add missing cpp specs

[Mike Frysinger]

On 29 May 2015 12:32, Sandra Loosemore wrote:
> On 05/29/2015 11:36 AM, Mike Frysinger wrote:
> > On 29 May 2015 08:44, Sandra Loosemore wrote:
> >> On 05/27/2015 10:00 AM, Mike Frysinger wrote:
> >>> Define CPP_SPEC for nios2 linux targets so that -posix & -pthread work
> >>> like on all other linux targets.
> >>>
> >>> 2015-05-27  Mike Frysinger  
> >>>
> >>>   * config/nios2/linux.h (CPP_SPEC): Define.
> >>
> >> I see that -posix is not documented at all in invoke.texi and -pthread
> >> is documented only for RS6000 and Solaris (which is not Linux).  What,
> >> exactly, are these options supposed to do on "all other linux targets"?
> >>If these options are supposed to be generic to all Linux targets,
> >> can't they be handled in some common way instead of duplicating the
> >> CPP_SPEC code in all the individual back ends?
> >
> > please see my other threads/patches
> 
> (Sorry, I am a few days behind in mailing list traffic, was just trying 
> to respond to the review request that was CC'ed to me directly.)
> 
> Do you mean this one?
> 
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02708.html

yes

> That addresses my concern about not duplicating this in every back end, 
> but I still don't see any documentation and don't really understand what 
> these flags are supposed to do or why I might need to add them to my 
> command line.  Taking off my nios2 maintainer hat and putting on the 
> docs maintainer one instead, I think proper documentation for these 
> options is a requirement here

i'm not familiar with the history.  i'm merely cleaning up some of the mess.
both defines are respected by glibc and make a difference to compilation.
-mike


signature.asc
Description: Digital signature

Re: [PATCH] nios2-linux: add missing cpp specs

[Mike Frysinger]

On 29 May 2015 08:44, Sandra Loosemore wrote:
> On 05/27/2015 10:00 AM, Mike Frysinger wrote:
> > Define CPP_SPEC for nios2 linux targets so that -posix & -pthread work
> > like on all other linux targets.
> >
> > 2015-05-27  Mike Frysinger  
> >
> > * config/nios2/linux.h (CPP_SPEC): Define.
> 
> I see that -posix is not documented at all in invoke.texi and -pthread 
> is documented only for RS6000 and Solaris (which is not Linux).  What, 
> exactly, are these options supposed to do on "all other linux targets"? 
>   If these options are supposed to be generic to all Linux targets, 
> can't they be handled in some common way instead of duplicating the 
> CPP_SPEC code in all the individual back ends?

please see my other threads/patches
-mike


signature.asc
Description: Digital signature

[PATCH] unify -posix/-pthread cpp handling for gnu-user targets

[Mike Frysinger]

Many Linux targets duplicate the cpp spec macros for turning -posix/-thread
into the right defines.  Some Linux targets forget to do this entirely and
can be hard to notice.  Add common definitions to the gnu headers (since
these are really in relation to the C library) and drop the duplications in
the target headers.

I've tested a few targets (aarch64, cris, x86_64) to make sure -dumpspecs
still includes the right content.

Some targets still define -posix/-pthread in SUBTARGET_CPP_SPEC and in
CPP_SUBTARGET_SPEC, but I can't seem to find any reference to either of
those defines.  Are they dead/confused code and I should just delete it ?

2015-05-28  Mike Frysinger  

* config/aarch64/aarch64-linux.h (CPP_SPEC): Delete.
* config/alpha/linux.h (CPP_SPEC): Delete.
* config/arm/linux-gas.h (SUBTARGET_CPP_SPEC): Change to
GNU_USER_CPP_SPEC.
* config/cris/linux.h (CRIS_CPP_SUBTARGET_SPEC): Remove -pthread.
* config/gnu-user.h (GNU_USER_CPP_SPEC, CPP_SPEC): Define.
* config/gnu.h (GNU_USER_CPP_SPEC): Define.
(CPP_SPEC): Change to GNU_USER_CPP_SPEC.
* config/i386/gnu-user-common.h (CPP_SPEC): Delete.
* config/ia64/linux.h (CPP_SPEC): Delete.
* config/m32r/linux.h (SUBTARGET_CPP_SPEC): Change to
GNU_USER_CPP_SPEC.
* config/m68k/linux.h (CPP_SPEC): Delete.
* config/microblaze/linux.h (CPP_SPEC): Delete.
* config/mips/gnu-user.h (SUBTARGET_CPP_SPEC): Change to
GNU_USER_CPP_SPEC.
* config/mn10300/linux.h (SUBTARGET_CPP_SPEC): Change to
GNU_USER_CPP_SPEC.
* config/nios2/linux.h (CPP_SPEC): Delete.
* config/pa/pa-linux.h (CPP_SPEC): Delete.
* config/s390/linux.h (CPP_SPEC): Delete.
* config/sh/linux.h (SUBTARGET_CPP_SPEC): Change to
GNU_USER_CPP_SPEC.
* config/sparc/linux.h (SUBTARGET_CPP_SPEC): Change to
GNU_USER_CPP_SPEC.
* config/sparc/linux64.h (SUBTARGET_CPP_SPEC): Change to
GNU_USER_CPP_SPEC.
* config/tilegx/linux.h (CPP_SPEC): Delete.
* config/tilepro/linux.h (CPP_SPEC): Delete.
* config/vax/linux.h (CPP_SPEC): Delete.
* config/xtensa/linux.h (SUBTARGET_CPP_SPEC): Change to
GNU_USER_CPP_SPEC.
---
 gcc/config/aarch64/aarch64-linux.h | 2 --
 gcc/config/alpha/linux.h   | 3 ---
 gcc/config/arm/linux-gas.h | 2 +-
 gcc/config/cris/linux.h| 6 ++
 gcc/config/gnu-user.h  | 5 +
 gcc/config/gnu.h   | 3 ++-
 gcc/config/i386/gnu-user-common.h  | 3 ---
 gcc/config/ia64/linux.h| 2 --
 gcc/config/m32r/linux.h| 5 ++---
 gcc/config/m68k/linux.h| 3 ---
 gcc/config/microblaze/linux.h  | 3 ---
 gcc/config/mips/gnu-user.h | 2 +-
 gcc/config/mn10300/linux.h | 6 +++---
 gcc/config/nios2/linux.h   | 3 ---
 gcc/config/pa/pa-linux.h   | 3 ---
 gcc/config/s390/linux.h| 2 --
 gcc/config/sh/linux.h  | 5 ++---
 gcc/config/sparc/linux.h   | 3 +--
 gcc/config/sparc/linux64.h | 5 +
 gcc/config/tilegx/linux.h  | 3 ---
 gcc/config/tilepro/linux.h | 3 ---
 gcc/config/vax/linux.h | 3 ---
 gcc/config/xtensa/linux.h  | 2 +-
 23 files changed, 21 insertions(+), 56 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-linux.h 
b/gcc/config/aarch64/aarch64-linux.h
index 1600a32..7d356dd 100644
--- a/gcc/config/aarch64/aarch64-linux.h
+++ b/gcc/config/aarch64/aarch64-linux.h
@@ -32,8 +32,6 @@
 #undef  CC1_SPEC
 #define CC1_SPEC GNU_USER_TARGET_CC1_SPEC ASAN_CC1_SPEC
 
-#define CPP_SPEC "%{pthread:-D_REENTRANT}"
-
 #define LINUX_TARGET_LINK_SPEC  "%{h*} \
%{static:-Bstatic}  \
%{shared:-shared}   \
diff --git a/gcc/config/alpha/linux.h b/gcc/config/alpha/linux.h
index 475ea06..e609f38 100644
--- a/gcc/config/alpha/linux.h
+++ b/gcc/config/alpha/linux.h
@@ -39,9 +39,6 @@ along with GCC; see the file COPYING3.  If not see
%{shared:-lc} \
%{!shared: %{profile:-lc_p}%{!profile:-lc}}"
 
-#undef CPP_SPEC
-#define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
-
 /* Show that we need a GP when profiling.  */
 #undef TARGET_PROFILING_NEEDS_GP
 #define TARGET_PROFILING_NEEDS_GP 1
diff --git a/gcc/config/arm/linux-gas.h b/gcc/config/arm/linux-gas.h
index d3a3196..6ce62c7 100644
--- a/gcc/config/arm/linux-gas.h
+++ b/gcc/config/arm/linux-gas.h
@@ -31,7 +31,7 @@
 #define DEFAULT_SIGNED_CHAR 0
 
 #undef  SUBTARGET_CPP_SPEC
-#define SUBTARGET_CPP_SPEC  "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
+#define SUBTARGET_CPP_SPEC GNU_USER_CPP_SPEC
 
 #undef  SIZE_TYPE
 #define SIZE_TYPE "unsigned int"
diff --git a/gcc/config/cris/linux.h b/gcc/config/cris/linux.h
index 262aac5..043a1ac 100644
--- a/gcc/config/cris/linux.h
+++ b/gcc/config/cris/linux.h
@@ -54,12 

Re: [PATCH] hppa-linux: add missing cpp specs

[Mike Frysinger]

On 27 May 2015 14:20, John David Anglin wrote:
> On 2015-05-27 1:50 PM, Mike Frysinger wrote:
> > since i'm not looped into gcc development normally, which branches are those
> > currently ?  naively reading gcc.gnu.org homepage makes me think none since
> > they're labled "regression fixes" and afaict, none of these are regressions.
> > they've been broken for as long as the ports have existed :/.
>
> The branches are 4.8, 4.9, 5 and trunk as noted on http://gcc.gnu.org.  
> For target fixes, that don't
> affect primary or secondary targets, nobody cares about the regression 
> criteria.

gotcha.  i've committed them then to trunk/4.8/4.9/5.  hopefully didn't break 
anything ;).

> This is probably one of the causes of poor thread behavior of many 
> applications running on
> parisc hardware.  I want to see the patch in Debian and you probably 
> want it for Gentoo.

i've already merged the patches in Gentoo for 4.6+ ;)
-mike


signature.asc
Description: Digital signature

Re: [PATCH] hppa-linux: add missing cpp specs

[Mike Frysinger]

On 27 May 2015 13:05, John David Anglin wrote:
> On 2015-05-27 11:59 AM, Mike Frysinger wrote:
> > Define CPP_SPEC for parisc linux targets so that -posix & -pthread work
> > like on all other linux targets.
> >
> > 2015-05-27  Mike Frysinger
> >
> > * config/pa/pa-linux.h (CPP_SPEC): Define.
>
> Okay.  I think this should be applied to all active branches. ChangeLog 
> entry should mention
> _REENTRANT.

since i'm not looped into gcc development normally, which branches are those 
currently ?  naively reading gcc.gnu.org homepage makes me think none since 
they're labled "regression fixes" and afaict, none of these are regressions.
they've been broken for as long as the ports have existed :/.
-mike


signature.asc
Description: Digital signature

Re: [PATCH] microblaze-linux: add missing cpp specs

[Mike Frysinger]

On 27 May 2015 18:03, Andreas Schwab wrote:
> Mike Frysinger  writes:
> 
> > diff --git a/gcc/config/microblaze/linux.h b/gcc/config/microblaze/linux.h
> > index a7faa7d..655a70f 100644
> > --- a/gcc/config/microblaze/linux.h
> > +++ b/gcc/config/microblaze/linux.h
> > @@ -22,6 +22,9 @@
> >  #undef TARGET_SUPPORTS_PIC
> >  #define TARGET_SUPPORTS_PIC 1
> >  
> > +#undef CPP_SPEC
> > +#define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
> 
> Should this be defined by a shared header?

i was going to poke that next, but i don't think fixing the few fringe arches 
should be predicated on cleaning up a mess that has been here for over a decade.
-mike


signature.asc
Description: Digital signature

[PATCH] nios2-linux: add missing cpp specs

[Mike Frysinger]

Define CPP_SPEC for nios2 linux targets so that -posix & -pthread work
like on all other linux targets.

2015-05-27  Mike Frysinger  

* config/nios2/linux.h (CPP_SPEC): Define.
---
 gcc/config/nios2/linux.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/nios2/linux.h b/gcc/config/nios2/linux.h
index 41cad94..f43f655 100644
--- a/gcc/config/nios2/linux.h
+++ b/gcc/config/nios2/linux.h
@@ -26,6 +26,9 @@
 }   \
   while (0)
 
+#undef CPP_SPEC
+#define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
+
 #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-nios2.so.1"
 
 #undef LINK_SPEC
-- 
2.4.1

[PATCH] microblaze-linux: add missing cpp specs

[Mike Frysinger]

Define CPP_SPEC for microblaze linux targets so that -posix & -pthread
work like on all other linux targets.

2015-05-27  Mike Frysinger  

* config/microblaze/linux.h (CPP_SPEC): Define.
---
 gcc/config/microblaze/linux.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/microblaze/linux.h b/gcc/config/microblaze/linux.h
index a7faa7d..655a70f 100644
--- a/gcc/config/microblaze/linux.h
+++ b/gcc/config/microblaze/linux.h
@@ -22,6 +22,9 @@
 #undef TARGET_SUPPORTS_PIC
 #define TARGET_SUPPORTS_PIC 1
 
+#undef CPP_SPEC
+#define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
+
 #undef TLS_NEEDS_GOT
 #define TLS_NEEDS_GOT 1
 
-- 
2.4.1

[PATCH] hppa-linux: add missing cpp specs

[Mike Frysinger]

Define CPP_SPEC for parisc linux targets so that -posix & -pthread work
like on all other linux targets.

2015-05-27  Mike Frysinger  

* config/pa/pa-linux.h (CPP_SPEC): Define.
---
 gcc/config/pa/pa-linux.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/pa/pa-linux.h b/gcc/config/pa/pa-linux.h
index 396d321..f8da185 100644
--- a/gcc/config/pa/pa-linux.h
+++ b/gcc/config/pa/pa-linux.h
@@ -28,7 +28,7 @@ along with GCC; see the file COPYING3.  If not see
   while (0)
 
 #undef CPP_SPEC
-#define CPP_SPEC "%{posix:-D_POSIX_SOURCE}"
+#define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}"
 
 #undef ASM_SPEC
 #define ASM_SPEC \
-- 
2.4.1

[PATCH] use gold/configure.tgt to calc supported targets

[Mike Frysinger]

Rather than maintain two lists, re-use gold's target file to determine
whether the current target is supported.

2015-04-20  Mike Frysinger  

* configure.ac: Replace $target checks with gold/configure.tgt.
* configure: Regenerate.
---
 configure| 20 ++--
 configure.ac | 20 ++--
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/configure b/configure
index 2549945..2d91a22 100755
--- a/configure
+++ b/configure
@@ -2968,16 +2968,16 @@ case "${ENABLE_GOLD}" in
 
 if test "$is_elf" = "yes"; then
   # Check for target supported by gold.
-  case "${target}" in
-i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | tilegx*-*-* | mips*-*-*)
- configdirs="$configdirs gold"
- if test x${ENABLE_GOLD} = xdefault; then
-   default_ld=gold
- fi
- ENABLE_GOLD=yes
-  ;;
-  esac
+  if (srcdir=${srcdir}/gold; \
+  targ=${target}; \
+  . ${srcdir}/configure.tgt; \
+  test "$targ_obj" != "UNKNOWN"); then
+configdirs="$configdirs gold"
+if test x${ENABLE_GOLD} = xdefault; then
+  default_ld=gold
+fi
+ENABLE_GOLD=yes
+  fi
 fi
 ;;
   no)
diff --git a/configure.ac b/configure.ac
index 0fe176b..a350fb4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -349,16 +349,16 @@ case "${ENABLE_GOLD}" in
 
 if test "$is_elf" = "yes"; then
   # Check for target supported by gold.
-  case "${target}" in
-i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-* \
-| aarch64*-*-* | tilegx*-*-* | mips*-*-*)
- configdirs="$configdirs gold"
- if test x${ENABLE_GOLD} = xdefault; then
-   default_ld=gold
- fi
- ENABLE_GOLD=yes
-  ;;
-  esac
+  if (srcdir=${srcdir}/gold; \
+  targ=${target}; \
+  . ${srcdir}/configure.tgt; \
+  test "$targ_obj" != "UNKNOWN"); then
+configdirs="$configdirs gold"
+if test x${ENABLE_GOLD} = xdefault; then
+  default_ld=gold
+fi
+ENABLE_GOLD=yes
+  fi
 fi
 ;;
   no)
-- 
2.3.5

Re: PATCH: Update --with-system-zlib

[Mike Frysinger]

On 01 Apr 2015 19:05, Bernhard Reutner-Fischer wrote:
> On April 1, 2015 6:54:31 PM GMT+02:00, Mike Frysinger wrote:
> >On 01 Apr 2015 05:04, H.J. Lu wrote:
> >> --- a/config/zlib.m4
> >> +++ b/config/zlib.m4
> >> @@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
> >>zlibinc="-I\$(srcdir)/../zlib"
> >>AC_ARG_WITH(system-zlib,
> >>[AS_HELP_STRING([--with-system-zlib], [use installed libz])],
> >> -  zlibdir=
> >> -  zlibinc=
> >> +  if test x$with_system_zlib = xyes ; then
> >> +zlibdir=
> >> +zlibinc=
> >> +  fi
> >>)
> >
> >this is inside the 3rd arg, so normally you check $withval.  this code
> >will 
> >still work as the generated shell does:
> >if test "${with_system_zlib+set}" = set; then :
> 
> Why doesn't this expand to test -n "${with_system_zlib+set}"
> nowadays, BTW? Would be faster to parse and supposedly sums up quite a bit, 
> fwiw.

question for the autoconf list ?

although note that this is autoconf-2.64 as that is what the tree has locked 
itself to currently.
-mike


signature.asc
Description: Digital signature

Re: PATCH: Update --with-system-zlib

[Mike Frysinger]

On 01 Apr 2015 05:04, H.J. Lu wrote:
> --- a/config/zlib.m4
> +++ b/config/zlib.m4
> @@ -9,8 +9,10 @@ AC_DEFUN([AM_ZLIB],
>zlibinc="-I\$(srcdir)/../zlib"
>AC_ARG_WITH(system-zlib,
>[AS_HELP_STRING([--with-system-zlib], [use installed libz])],
> -  zlibdir=
> -  zlibinc=
> +  if test x$with_system_zlib = xyes ; then
> +zlibdir=
> +zlibinc=
> +  fi
>)

this is inside the 3rd arg, so normally you check $withval.  this code will 
still work as the generated shell does:
if test "${with_system_zlib+set}" = set; then :
  withval=$with_system_zlib; [3rd arg content]
fi

>  bfd/ChangeLog  | 4 
>  bfd/configure  | 6 --
>  binutils/ChangeLog | 4 
>  binutils/configure | 6 --
>  gas/ChangeLog  | 4 
>  gas/configure  | 6 --
>  gdb/ChangeLog  | 4 
>  gdb/configure  | 6 --

you need to regenerate the sim tree too
-mike


signature.asc
Description: Digital signature

Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4

[Mike Frysinger]

On 18 Feb 2015 14:24, H.J. Lu wrote:
> On Wed, Feb 18, 2015 at 2:21 PM, Mike Frysinger wrote:
> > i think we already have the reports: multiple people don't think it should 
> > be
> > (1) x86-specific or (2) required.  don't get me wrong -- i think having 
> > support
> > like this is great.  that doesn't mean we should be forcing it.
> 
> Please file a bug report with a testcase.

this is getting kafka-esque.  you yourself stated:
  On Linux/x86, zlib is required for assembler.  At least, you should issue an 
  error when --without-libz is used in binutils for Linux/x86 target.
that should not be the case.  making someone open a bug report so you can close 
it with "fixed" and a patch is wasting time.  just fix it now.

all that said, if we look at your actual commit (89e7505fcde4bd83948f559f429a0):
gas/config/tc-i386.c:
  +#ifdef TE_LINUX
  +/* Default to compress debug sections for Linux.  */
  +int flag_compress_debug = 1;
  +#endif

and we look at where that flag is used:
gas/as.c:
  ...
case OPTION_COMPRESS_DEBUG:
  #ifdef HAVE_ZLIB_H
  flag_compress_debug = 1;
  #else
  as_warn (_("cannot compress debug sections (zlib not installed)"));
  #endif /* HAVE_ZLIB_H */
  break;

case OPTION_NOCOMPRESS_DEBUG:
  flag_compress_debug = 0;
  break;
  ...

gas/write.c:
  void
  write_object_file (void)
  {
  ...
if (flag_compress_debug)
  bfd_map_over_sections (stdoutput, compress_debug, (char *) 0);
  ...
  static void
  compress_debug (bfd *abfd, asection *sec, void *xxx ATTRIBUTE_UNUSED)
  {
  ...
strm = compress_init ();
if (strm == NULL)
  return;

it turns out the current code does *not* require zlib.  as long as that does 
not 
change (either issuing a warning or throwing an error), i see no reason why we 
need or should make zlib a requirement in binutils, regardless of target.
-mike


signature.asc
Description: Digital signature

Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4

[Mike Frysinger]

On 18 Feb 2015 13:54, H.J. Lu wrote:
> On Wed, Feb 18, 2015 at 1:40 PM, Mark Wielaard wrote:
> > On Wed, 2015-02-18 at 12:53 -0800, H.J. Lu wrote:
> >> On Wed, Feb 18, 2015 at 12:32 PM, Mark Wielaard wrote:
> >> > That doesn't seem like a smart default. And why is is Linux/x86 only?
> >> > Shouldn't that be something that is done explicitly by a distro
> >> > configuring binutils after making sure it actually is beneficial
> >> > (debuginfo is often compressed in a different way, on the package/file
> >> > level or with dwz). And after making sure all tools actually work with
> >> > it? There are various tools that don't handle the .zdebug format like
> >> > valgrind. And at least elfutils has trouble with it for ET_REL files,
> >> > like kernel modules, because relocations don't actually apply anymore to
> >> > the section data as is (but only after the decompression).
> >>
> >> Now it becomes a monthly topic:
> >>
> >> https://sourceware.org/ml/binutils/2015-01/msg00089.html
> >
> > Thanks, I hadn't seen that before. Alan Modra makes some good points in
> > that thread why it is not a good change:
> > https://sourceware.org/ml/binutils/2015-01/msg00135.html
> > Do people agree with that? And/Or can the change be reverted for now
> > till there is agreement it is a desirable default?
> 
> It may not be a good idea for all targets.  If you find an issue
> on Linux/x86, please file a bug binutils report.

i think we already have the reports: multiple people don't think it should be 
(1) x86-specific or (2) required.  don't get me wrong -- i think having support 
like this is great.  that doesn't mean we should be forcing it.
-mike


signature.asc
Description: Digital signature

Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4

[Mike Frysinger]

On 18 Feb 2015 08:58, H.J. Lu wrote:
> On Wed, Feb 18, 2015 at 8:54 AM, Mike Frysinger wrote:
> > On 18 Feb 2015 04:56, H.J. Lu wrote:
> >> On Wed, Feb 18, 2015 at 4:08 AM, Joel Brobecker wrote:
> >> > On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote:
> >> >> This patch enhances config/zlib.m4 to introduce an extra option
> >> >> --with-libz-prefix which allows us to provide the location of
> >> >> the zlib library we want to use during the build.
> >> >>
> >> >> config/ChangeLog:
> >> >>
> >> >> * zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support.
> >> >>
> >> >> I didn't see any file in the GCC project that uses this macro,
> >> >> so for the GCC repository, the change to zlib.m4 is it. But
> >> >> I am also attaching to this email a copy of the patch that
> >> >> will be applied to the binutils-gdb.git repository, with all
> >> >> configury using this macro being re-generated - mostly for info,
> >> >> also as a heads-up to both binutils and GDB.
> >> >>
> >> >> This was tested by regenerating all autoconf/automake files in
> >> >> the binutils-gdb project, and rebuilding GDB, using the following
> >> >> combinations:
> >> >>
> >> >>   --with-zlib (system zlib used)
> >> >>   --with-libz-prefix=/zlib/prefix (specific zlib linked in)
> >> >>   --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in)
> >> >>
> >> >>   --without-zlib (zlib support turned off)
> >> >>   --without-zlib --with-zlib-prefix (zlib support turned off)
> >> >>
> >> >>   --with-zlib (no system zlib available, configure fails with expected 
> >> >> error)
> >> >>   --with-zlib --with-libz-prefix=/invalid/zlib/prefix
> >> >>   (no system zlib, configure fails with same error)
> >> >>
> >> >> OK to commit?
> >>
> >> Why do you want to turn off zlib? On Linux/x86,  zlib is required
> >> for assembler.  At least, you should issue an error when --without-libz
> >> is used in binutils for Linux/x86 target.
> >
> > err, when did that happen ?  why would zlib be possibly required for an
> > assembler ?
> 
> commit 89e7505fcde4bd83948f559f429a0e1eb4262f05
> Author: H.J. Lu 
> Date:   Sun Dec 14 06:41:03 2014 -0800
> 
> Compress debug sections for Linux/x86 by default
> 
>   * config/tc-i386.c (flag_compress_debug): Default to compress
>   debug sections for Linux.

i don't see how that justifies making it a hard requirement
-mike


signature.asc
Description: Digital signature

Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4

[Mike Frysinger]

On 18 Feb 2015 04:56, H.J. Lu wrote:
> On Wed, Feb 18, 2015 at 4:08 AM, Joel Brobecker  wrote:
> > On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote:
> >> This patch enhances config/zlib.m4 to introduce an extra option
> >> --with-libz-prefix which allows us to provide the location of
> >> the zlib library we want to use during the build.
> >>
> >> config/ChangeLog:
> >>
> >> * zlib.m4 (AM_ZLIB): Add --with-libz-prefix option support.
> >>
> >> I didn't see any file in the GCC project that uses this macro,
> >> so for the GCC repository, the change to zlib.m4 is it. But
> >> I am also attaching to this email a copy of the patch that
> >> will be applied to the binutils-gdb.git repository, with all
> >> configury using this macro being re-generated - mostly for info,
> >> also as a heads-up to both binutils and GDB.
> >>
> >> This was tested by regenerating all autoconf/automake files in
> >> the binutils-gdb project, and rebuilding GDB, using the following
> >> combinations:
> >>
> >>   --with-zlib (system zlib used)
> >>   --with-libz-prefix=/zlib/prefix (specific zlib linked in)
> >>   --with-zlib --with-libz-prefix=/zlib/prefix (specific zlib linked in)
> >>
> >>   --without-zlib (zlib support turned off)
> >>   --without-zlib --with-zlib-prefix (zlib support turned off)
> >>
> >>   --with-zlib (no system zlib available, configure fails with expected 
> >> error)
> >>   --with-zlib --with-libz-prefix=/invalid/zlib/prefix
> >>   (no system zlib, configure fails with same error)
> >>
> >> OK to commit?
> 
> Why do you want to turn off zlib? On Linux/x86,  zlib is required
> for assembler.  At least, you should issue an error when --without-libz
> is used in binutils for Linux/x86 target.

err, when did that happen ?  why would zlib be possibly required for an 
assembler ?
-mike


signature.asc
Description: Digital signature

[PATCH] libiberty: fix --enable-install-libiberty flag [PR 56780]

[Mike Frysinger]

Commit 199570 fixed the --disable-install-libiberty behavior, but it also
added a bug where the enable path never works because the initial clear
of target_header_dir wasn't deleted.  So we end up initializing properly
at the top only to reset it at the end all the time.

2014-01-06  Mike Frysinger  

PR other/56780
* configure.ac: Delete target_header_dir assignment.
* configure: Regenerated.
---
 libiberty/configure| 1 -
 libiberty/configure.ac | 1 -
 2 files changed, 2 deletions(-)

diff --git a/libiberty/configure b/libiberty/configure
index 8ea54da..7bde9b3 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -5510,7 +5510,6 @@ fi
 
 setobjs=
 CHECK=
-target_header_dir=
 if test -n "${with_target_subdir}"; then
 
   # We are being configured as a target library.  AC_REPLACE_FUNCS
diff --git a/libiberty/configure.ac b/libiberty/configure.ac
index 4ad88a9..d6180bc 100644
--- a/libiberty/configure.ac
+++ b/libiberty/configure.ac
@@ -411,7 +411,6 @@ fi
 
 setobjs=
 CHECK=
-target_header_dir=
 if test -n "${with_target_subdir}"; then
 
   # We are being configured as a target library.  AC_REPLACE_FUNCS
-- 
1.8.4.3

[patch] libbacktrace: add support for --disable-werror

[Mike Frysinger]

In the same vein as the other dirs, add a --disable-werror option to the
libbacktrace dir to disable the explicit -Werror usage.

2014-01-03  Mike Frysinger  

* configure.ac: Add --enable-werror.
(WARN_FLAGS): Use it.
* configure: Regenerate.

--- a/libbacktrace/configure.ac
+++ a/libbacktrace/configure.ac
@@ -132,8 +132,13 @@ ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwri
  -Wmissing-format-attribute -Wcast-qual],
  [WARN_FLAGS])
 
+AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
+  [turns on -Werror @<:@default=yes@:>@])])
+
 if test -n "${with_target_subdir}"; then
-  WARN_FLAGS="$WARN_FLAGS -Werror"
+  if test "x$enable_werror" != "xno"; then
+WARN_FLAGS="$WARN_FLAGS -Werror"
+  fi
 fi
 
 AC_SUBST(WARN_FLAGS)
--- a/libbacktrace/configure
+++ a/libbacktrace/configure
@@ -730,6 +730,7 @@ enable_fast_install
 with_gnu_ld
 enable_libtool_lock
 enable_multilib
+enable_werror
 with_system_libunwind
 '
   ac_precious_vars='build_alias
@@ -1370,6 +1371,7 @@ Optional Features:
   optimize for fast installation [default=yes]
   --disable-libtool-lock  avoid locking (might break parallel builds)
   --enable-multilib   build many library versions (default)
+  --enable-werror turns on -Werror [default=yes]
 
 Optional Packages:
   --with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
@@ -11614,8 +11616,16 @@ fi
 CFLAGS="$save_CFLAGS"
 
 
+# Check whether --enable-werror was given.
+if test "${enable_werror+set}" = set; then :
+  enableval=$enable_werror;
+fi
+
+
 if test -n "${with_target_subdir}"; then
-  WARN_FLAGS="$WARN_FLAGS -Werror"
+  if test "x$enable_werror" != "xno"; then
+WARN_FLAGS="$WARN_FLAGS -Werror"
+  fi
 fi
 
 


signature.asc
Description: This is a digitally signed message part.

Re: [libiberty] xmalloc cannot return NULL

[Mike Frysinger]

On Monday 14 October 2013 13:59:16 Marc Glisse wrote:
> libiberty provides a function xmalloc that never returns NULL. However,
> there are some hints that it might be ok if someone wants to supply their
> own xmalloc that can return NULL (though that would break a lot of things,
> including in libiberty itself).
> 
> I would like to remove that freedom, and the point of this email (I hope
> it doesn't bounce from too many of these addresses) is to ask all
> libiberty users if that would cause problems for them. I already heard
> from gcc and gdb that they are happy forbidding a null return value from
> xmalloc.
> 
> Why do I want to do that? I just added an attribute "returns_nonnull" to
> gcc and would like to mark relevant functions, to let the compiler
> optimize based on this property.
> 
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00817.html

makes sense to me.  as you point out, we write code based on the assumption 
that NULL is never returned (although, perhaps phrased more accurately, that 
the pointer returned is always valid).
-mike


signature.asc
Description: This is a digitally signed message part.

Re: -static-libstdc++ breaks building gdb

[Mike Frysinger]

On Tuesday 03 September 2013 17:39:10 Mike Stump wrote:
> host compiler.  When I building gdb trunk, I get a failure to build because
> configure tests g++ to see if these work, but gdb links with gcc and 4.5.1
> errors out with the flag.  You can't set LDFLAGS, because that is given to
> gcc, without testing the flag with gcc.  So, either:

it's a bug in gcc code.  random subdirs (like binutils) shouldn't be working 
around it:
http://gcc.gnu.org/PR56750
-mike


signature.asc
Description: This is a digitally signed message part.

[PATCH v2] gcc: arm: linux-eabi: fix handling of armv4 bx fixups when linking

[Mike Frysinger]

The bpabi.h header already sets up defines to automatically use the
--fix-v4bx flag with the assembler & linker as needed, and creates a
default assembly & linker spec which uses those.  Unfortunately, the
linux-eabi.h header clobbers the LINK_SPEC define and doesn't include
the v4bx define when setting up its own.  So while the assembler spec
is retained and works fine to generate the right relocs, building for
armv4 targets doesn't invoke the linker correctly so all the relocs
get processed as if we had an armv4t target.

You can see this with -dumpspecs when configuring gcc for an armv4
target and using --with-arch=armv4:
$ armv4l-unknown-linux-gnueabi-gcc -dumpspecs |& grep -B 1 fix-v4bx
*subtarget_extra_asm_spec:
 
%{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx}
 ...

With this fix in place, we also get the link spec:
$ armv4l-unknown-linux-gnueabi-gcc -dumpspecs |& grep -B 1 fix-v4bx
*link:
...  
%{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx}
 ...

And all my hello world tests / glibc builds automatically turn the
bx insn into the 'mov pc, lr' insn and all is right in the world.

Signed-off-by: Mike Frysinger 

2013-04-27  Mike Frysinger  

* config/arm/bpabi.h (EABI_LINK_SPEC): Define.
(BPABI_LINK_SPEC): Use new EABI_LINK_SPEC.
* config/arm/linux-eabi.h (LINK_SPEC): Replace BE8_LINK_SPEC
with EABI_LINK_SPEC.
---
v2
- create a dedicated link spec as suggested by Richard

 gcc/config/arm/bpabi.h  | 6 +-
 gcc/config/arm/linux-eabi.h | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/gcc/config/arm/bpabi.h b/gcc/config/arm/bpabi.h
index 8e6683b..ff89633 100644
--- a/gcc/config/arm/bpabi.h
+++ b/gcc/config/arm/bpabi.h
@@ -91,11 +91,15 @@
 #define SUBTARGET_EXTRA_LINK_SPEC ""
 #endif
 
+/* Split out the EABI common values so other targets can use it.  */
+#define EABI_LINK_SPEC \
+  TARGET_FIX_V4BX_SPEC BE8_LINK_SPEC
+
 /* The generic link spec in elf.h does not support shared libraries.  */
 #define BPABI_LINK_SPEC \
   "%{mbig-endian:-EB} %{mlittle-endian:-EL} "  \
   "%{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} "   \
-  "-X" SUBTARGET_EXTRA_LINK_SPEC TARGET_FIX_V4BX_SPEC BE8_LINK_SPEC
+  "-X" SUBTARGET_EXTRA_LINK_SPEC EABI_LINK_SPEC
 
 #undef  LINK_SPEC
 #define LINK_SPEC BPABI_LINK_SPEC
diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 4a425c8..23671a7 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -80,7 +80,7 @@
 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
use the GNU/Linux version, not the generic BPABI version.  */
 #undef  LINK_SPEC
-#define LINK_SPEC BE8_LINK_SPEC
\
+#define LINK_SPEC EABI_LINK_SPEC   \
   LINUX_OR_ANDROID_LD (LINUX_TARGET_LINK_SPEC, \
   LINUX_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC)
 
-- 
1.8.2.1

[PATCH] gcc: arm: linux-eabi: fix handling of armv4 bx fixups when linking

[Mike Frysinger]

The bpabi.h header already sets up defines to automatically use the
--fix-v4bx flag with the assembler & linker as needed, and creates a
default assembly & linker spec which uses those.  Unfortunately, the
linux-eabi.h header clobbers the LINK_SPEC define and doesn't include
the v4bx define when setting up its own.  So while the assembler spec
is retained and works fine to generate the right relocs, building for
armv4 targets doesn't invoke the linker correctly so all the relocs
get processed as if we had an armv4t target.

You can see this with -dumpspecs when configuring gcc for an armv4
target and using --with-arch=armv4:
$ armv4l-unknown-linux-gnueabi-gcc -dumpspecs |& grep -B 1 fix-v4bx
*subtarget_extra_asm_spec:
 
%{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx}
 ...

With this fix in place, we also get the link spec:
$ armv4l-unknown-linux-gnueabi-gcc -dumpspecs |& grep -B 1 fix-v4bx
*link:
...  
%{mcpu=arm8|mcpu=arm810|mcpu=strongarm*|march=armv4|mcpu=fa526|mcpu=fa626:--fix-v4bx}
 ...

And all my hello world tests / glibc builds automatically turn the
bx insn into the 'mov pc, lr' insn and all is right in the world.

Signed-off-by: Mike Frysinger 

2013-04-19  Mike Frysinger  

* config/arm/linux-eabi.h (LINK_SPEC): Add TARGET_FIX_V4BX_SPEC.
---
Note: This issue seems to exist since the code was first introduced.
  At least, I've tested gcc-4.5.x and gcc-4.8.x and they both fail,
  and the code looks the same in gcc-4.[467].x.  That means it's
  not technically a regression, so I guess policy dictates that it
  can't be merged into older branches?

 gcc/config/arm/linux-eabi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 4a425c8..8b7ebb2 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -80,7 +80,7 @@
 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
use the GNU/Linux version, not the generic BPABI version.  */
 #undef  LINK_SPEC
-#define LINK_SPEC BE8_LINK_SPEC
\
+#define LINK_SPEC TARGET_FIX_V4BX_SPEC BE8_LINK_SPEC   \
   LINUX_OR_ANDROID_LD (LINUX_TARGET_LINK_SPEC, \
   LINUX_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC)
 
-- 
1.8.2.1

Re: [PATCH 1/2] [pr53679] libgo: add a --enable-werror configure flag

[Mike Frysinger]

On Wednesday 06 March 2013 10:49:23 Diego Novillo wrote:
> On Tue, Mar 5, 2013 at 12:31 AM, Ian Lance Taylor  wrote:
> > On Mon, Mar 4, 2013 at 4:11 PM, Mike Frysinger  wrote:
> > > On Saturday 26 January 2013 21:40:44 Ian Lance Taylor wrote:
> > >> On Fri, Jan 25, 2013 at 7:20 PM, Mike Frysinger wrote:
> > >> > On Friday 25 January 2013 19:13:55 Ian Lance Taylor wrote:
> > >> >> On Tue, Jan 15, 2013 at 9:45 AM, Mike Frysinger wrote:
> > >> >> > On Tuesday 15 January 2013 09:56:06 Ian Lance Taylor wrote:
> > >> >> >> On Sun, Dec 23, 2012 at 3:30 PM, Mike Frysinger wrote:
> > >> >> >> > diff --git a/libgo/configure.ac b/libgo/configure.ac
> > >> >> >> > index 8cde50b..63d8cbc 100644
> > >> >> >> > --- a/libgo/configure.ac
> > >> >> >> > +++ b/libgo/configure.ac
> > >> >> >> > @@ -50,8 +50,11 @@ AC_PROG_AWK
> > >> >> >> > 
> > >> >> >> >  WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual'
> > >> >> >> >  AC_SUBST(WARN_FLAGS)
> > >> >> >> > 
> > >> >> >> > -dnl FIXME: This should be controlled by
> > >> >> >> > --enable-maintainer-mode.
> > >> >> >> > -WERROR="-Werror"
> > >> >> >> > +AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
> > >> >> >> > +  [turns on -Werror
> > >> >> >> > @<:@default=yes@:>@])]) +if test "x$enable_werror" != "xno";
> > >> >> >> > then
> > >> >> >> > +  WERROR="-Werror"
> > >> >> >> > +fi
> > >> >> >> > 
> > >> >> >> >  AC_SUBST(WERROR)
> > >> >> >> >  
> > >> >> >> >  glibgo_toolexecdir=no
> > >> >> >> 
> > >> >> >> Can you say something about when you needed this?  What errors
> > >> >> >> were
> > >> >> >> you seeing?
> > >> >> > 
> > >> >> > the referenced PR describes one:
> > >> >> > /build/src/gcc-4.7.1/libgo/runtime/print.c: In function 'gwrite':
> > >> >> > /build/src/gcc-4.7.1/libgo/runtime/print.c:20:3: error: ignoring
> > >> >> > return value of 'write', declared with attribute
> > >> >> > warn_unused_result
> > >> >> > [-Werror=unused-result] cc1: all warnings being treated as errors
> > >> >> > 
> > >> >> > this bites distros that enable security settings by default (such
> > >> >> > as
> > >> >> > fortify and ssp).  but ignoring even that, i don't believe
> > >> >> > releases
> > >> >> > should build all the time with -Werror -- i'm fine with
> > >> >> > defaulting to
> > >> >> > on as long as there is a configure flag to turn it off which is
> > >> >> > what
> > >> >> > this does like is already handled in much of the sourceware tree.
> > >> >> > -Werror is great for development, but sucks when deployed on
> > >> >> > actual
> > >> >> > systems.  the assumptions made at time of checkin rarely stay
> > >> >> > constant forever (in this case, a changing lib C can easily break
> > >> >> > it). -mike
> > >> >> 
> > >> >> Thanks for the explanation.
> > >> >> 
> > >> >> Committed to mainline.
> > >> > 
> > >> > thanks!  mind if i commit it to gcc-4.6 and gcc-4.7 too ?
> > >> 
> > >> I certainly don't mind.  You should probably get agreement from the
> > >> release managers although this seems safe enough.
> > > 
> > > can you approve merges to the google branches ?  that's really where i
> > > want
> > > this :).
> > 
> > No, I don't work on those branches.  Sorry.
> 
> I committed this patch to google/gcc-4_7 rev 196494.  Feel free to
> commit to google/gcc-4_6 if you need to.

nope, we just need it in 4.7, thanks!
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] [pr53679] libgo: add a --enable-werror configure flag

[Mike Frysinger]

On Saturday 26 January 2013 21:40:44 Ian Lance Taylor wrote:
> On Fri, Jan 25, 2013 at 7:20 PM, Mike Frysinger wrote:
> > On Friday 25 January 2013 19:13:55 Ian Lance Taylor wrote:
> >> On Tue, Jan 15, 2013 at 9:45 AM, Mike Frysinger wrote:
> >> > On Tuesday 15 January 2013 09:56:06 Ian Lance Taylor wrote:
> >> >> On Sun, Dec 23, 2012 at 3:30 PM, Mike Frysinger wrote:
> >> >> > diff --git a/libgo/configure.ac b/libgo/configure.ac
> >> >> > index 8cde50b..63d8cbc 100644
> >> >> > --- a/libgo/configure.ac
> >> >> > +++ b/libgo/configure.ac
> >> >> > @@ -50,8 +50,11 @@ AC_PROG_AWK
> >> >> > 
> >> >> >  WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual'
> >> >> >  AC_SUBST(WARN_FLAGS)
> >> >> > 
> >> >> > -dnl FIXME: This should be controlled by --enable-maintainer-mode.
> >> >> > -WERROR="-Werror"
> >> >> > +AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
> >> >> > +  [turns on -Werror
> >> >> > @<:@default=yes@:>@])]) +if test "x$enable_werror" != "xno"; then
> >> >> > +  WERROR="-Werror"
> >> >> > +fi
> >> >> > 
> >> >> >  AC_SUBST(WERROR)
> >> >> >  
> >> >> >  glibgo_toolexecdir=no
> >> >> 
> >> >> Can you say something about when you needed this?  What errors were
> >> >> you seeing?
> >> > 
> >> > the referenced PR describes one:
> >> > /build/src/gcc-4.7.1/libgo/runtime/print.c: In function 'gwrite':
> >> > /build/src/gcc-4.7.1/libgo/runtime/print.c:20:3: error: ignoring
> >> > return value of 'write', declared with attribute warn_unused_result
> >> > [-Werror=unused-result] cc1: all warnings being treated as errors
> >> > 
> >> > this bites distros that enable security settings by default (such as
> >> > fortify and ssp).  but ignoring even that, i don't believe releases
> >> > should build all the time with -Werror -- i'm fine with defaulting to
> >> > on as long as there is a configure flag to turn it off which is what
> >> > this does like is already handled in much of the sourceware tree. 
> >> > -Werror is great for development, but sucks when deployed on actual
> >> > systems.  the assumptions made at time of checkin rarely stay
> >> > constant forever (in this case, a changing lib C can easily break
> >> > it). -mike
> >> 
> >> Thanks for the explanation.
> >> 
> >> Committed to mainline.
> > 
> > thanks!  mind if i commit it to gcc-4.6 and gcc-4.7 too ?
> 
> I certainly don't mind.  You should probably get agreement from the
> release managers although this seems safe enough.

can you approve merges to the google branches ?  that's really where i want 
this :).
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] [pr53679] libgo: add a --enable-werror configure flag

[Mike Frysinger]

On Friday 25 January 2013 19:13:55 Ian Lance Taylor wrote:
> On Tue, Jan 15, 2013 at 9:45 AM, Mike Frysinger wrote:
> > On Tuesday 15 January 2013 09:56:06 Ian Lance Taylor wrote:
> >> On Sun, Dec 23, 2012 at 3:30 PM, Mike Frysinger wrote:
> >> > diff --git a/libgo/configure.ac b/libgo/configure.ac
> >> > index 8cde50b..63d8cbc 100644
> >> > --- a/libgo/configure.ac
> >> > +++ b/libgo/configure.ac
> >> > @@ -50,8 +50,11 @@ AC_PROG_AWK
> >> > 
> >> >  WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual'
> >> >  AC_SUBST(WARN_FLAGS)
> >> > 
> >> > -dnl FIXME: This should be controlled by --enable-maintainer-mode.
> >> > -WERROR="-Werror"
> >> > +AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
> >> > +  [turns on -Werror
> >> > @<:@default=yes@:>@])]) +if test "x$enable_werror" != "xno"; then
> >> > +  WERROR="-Werror"
> >> > +fi
> >> > 
> >> >  AC_SUBST(WERROR)
> >> >  
> >> >  glibgo_toolexecdir=no
> >> 
> >> Can you say something about when you needed this?  What errors were you
> >> seeing?
> > 
> > the referenced PR describes one:
> > /build/src/gcc-4.7.1/libgo/runtime/print.c: In function 'gwrite':
> > /build/src/gcc-4.7.1/libgo/runtime/print.c:20:3: error: ignoring return
> > value of 'write', declared with attribute warn_unused_result
> > [-Werror=unused-result] cc1: all warnings being treated as errors
> > 
> > this bites distros that enable security settings by default (such as
> > fortify and ssp).  but ignoring even that, i don't believe releases
> > should build all the time with -Werror -- i'm fine with defaulting to on
> > as long as there is a configure flag to turn it off which is what this
> > does like is already handled in much of the sourceware tree.  -Werror is
> > great for development, but sucks when deployed on actual systems.  the
> > assumptions made at time of checkin rarely stay constant forever (in
> > this case, a changing lib C can easily break it). -mike
> 
> Thanks for the explanation.
> 
> Committed to mainline.

thanks!  mind if i commit it to gcc-4.6 and gcc-4.7 too ?
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/2] [pr53679] libgo: add a --enable-werror configure flag

[Mike Frysinger]

On Tuesday 15 January 2013 09:56:06 Ian Lance Taylor wrote:
> On Sun, Dec 23, 2012 at 3:30 PM, Mike Frysinger  wrote:
> > diff --git a/libgo/configure.ac b/libgo/configure.ac
> > index 8cde50b..63d8cbc 100644
> > --- a/libgo/configure.ac
> > +++ b/libgo/configure.ac
> > @@ -50,8 +50,11 @@ AC_PROG_AWK
> > 
> >  WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual'
> >  AC_SUBST(WARN_FLAGS)
> > 
> > -dnl FIXME: This should be controlled by --enable-maintainer-mode.
> > -WERROR="-Werror"
> > +AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
> > +  [turns on -Werror
> > @<:@default=yes@:>@])]) +if test "x$enable_werror" != "xno"; then
> > +  WERROR="-Werror"
> > +fi
> > 
> >  AC_SUBST(WERROR)
> >  
> >  glibgo_toolexecdir=no
> 
> Can you say something about when you needed this?  What errors were you
> seeing?

the referenced PR describes one:
/build/src/gcc-4.7.1/libgo/runtime/print.c: In function 'gwrite':
/build/src/gcc-4.7.1/libgo/runtime/print.c:20:3: error: ignoring return value
of 'write', declared with attribute warn_unused_result [-Werror=unused-result]
cc1: all warnings being treated as errors

this bites distros that enable security settings by default (such as fortify 
and ssp).  but ignoring even that, i don't believe releases should build all 
the time with -Werror -- i'm fine with defaulting to on as long as there is a 
configure flag to turn it off which is what this does like is already handled 
in 
much of the sourceware tree.  -Werror is great for development, but sucks when 
deployed on actual systems.  the assumptions made at time of checkin rarely 
stay constant forever (in this case, a changing lib C can easily break it).
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [RFC PATCH, i386]: Use %r15 for REAL_PIC_OFFSET_TABLE_REGNUM on x86_64

[Mike Frysinger]

On Tuesday 25 December 2012 14:12:09 Uros Bizjak wrote:
> On Tue, Dec 25, 2012 at 6:54 AM, Mike Frysinger  wrote:
> > On Monday 24 December 2012 17:26:47 Leif Ekblad wrote:
> >> In the case of cpuid, the code is hardly performance sensitive, and
> >> probably runs only at startup. An alternative solution for the broken
> >> code here is to move the result from rbx to another register, and to
> >> save/restore rbx. Currently, this is the only place in libgcc and
> >> newlib affected by this problem.
> > 
> > it's not a question of performance.  i can't remember how many various
> > projects i've had to tweak the inline asm code to work with __PIC__
> > (either because it's going into shared library code or it's being built
> > as a PIE). Andi's point is now we have to redo all of that work a 2nd
> > time and handle two different cases depending on gcc version ?  it'd be
> > a _lot_ better if gcc were intelligent and end users didn't have to code
> > crap like stuffing %ebx somewhere temporarily.
> 
> Please note that we are not talking about 32bit code, where this would
> make a difference, but for 64bit targets with -mcmodel=medium and
> -mcmodel=large exclusively. The default x64_64 -mcmodel=small doesn't
> use PIC register, other code models are rarely used, so I sincerely
> doubt that any %rbx workarounds were needed in the past for x86_64.

i'm aware.  the comment still applies.  you're breaking asm code that used to 
work because the gcc inline asm code isn't intelligent enough (currently) to 
transparently handle the PIC register for the user.
-mike


signature.asc
Description: This is a digitally signed message part.

[PATCH] fixincludes: handle symlinks with multiple slashes

[Mike Frysinger]

If you have a symlink in /usr/include like so:
/usr/include/oracle/10.2.0.3/client -> 
//usr/lib64/oracle/10.2.0.3/client/include

The fixincludes script gets confused and tries to write to /usr/include.
This is because the logic to walk the path names strips just one slash.
Tweak the sed statement to consume all duplicate slashes instead.

Before this change (and the aforementioned symlink):

$ rm -rf output
$ ./fixinc.sh $PWD/output 2>/dev/null
Fixing headers into 
/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/build-x86_64-pc-linux-gnu/fixincludes/output
 for x86_64-pc-linux-gnu target
Forbidden identifiers:
Finding directories and links to directories
 Searching /usr/include/.
 Searching /usr/include/./quicktime
 Searching /usr/include/./schily/scg
 Searching /usr/include/./libpq
 Searching /usr/include/./libunrar
 Searching /usr/include/./cryptopp
 Searching /usr/include/./oracle/10.2.0.3/client
 Searching /usr/include/./postgresql
 Searching /usr/include/./scsilib
Making symbolic directory links
Fixing directory /usr/include into 
/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/build-x86_64-pc-linux-gnu/fixincludes/output
Fixing directory /usr/include/oracle/10.2.0.3/client into /usr/include
Cleaning up unneeded directories:
fixincludes is done

Notice that second "Fixing directory" is wrong -- it shouldn't be in /usr.

After this fix, that second line correctly reads:
Fixing directory /usr/include/oracle/10.2.0.3/client into 
/var/tmp/portage/sys-devel/gcc-4.5.4/work/build/build-x86_64-pc-linux-gnu/fixincludes/output/root/usr/lib64/oracle/10.2.0.3/client/include

Signed-off-by: Mike Frysinger 

2012-12-25  Mike Frysinger  

* fixinc.in (dirname): Change sed from 's|[^/]*/||' to
's|[^/]*//*||'.
---
 fixincludes/fixinc.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index f7b8d8f..202fff3 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -344,7 +344,7 @@ if $LINKS; then
 mkdir $component >/dev/null 2>&1
 cd $component
 dirmade=$dirmade/$component
-dirname=`echo $dirname | sed -e 's|[^/]*/||'`
+dirname=`echo $dirname | sed -e 's|[^/]*//*||'`
   done
 fi
 
-- 
1.8.0

Re: [RFC PATCH, i386]: Use %r15 for REAL_PIC_OFFSET_TABLE_REGNUM on x86_64

[Mike Frysinger]

On Monday 24 December 2012 17:26:47 Leif Ekblad wrote:
> In the case of cpuid, the code is hardly performance sensitive, and
> probably runs only at startup. An alternative solution for the broken code
> here is to move the result from rbx to another register, and to
> save/restore rbx. Currently, this is the only place in libgcc and newlib
> affected by this problem.

it's not a question of performance.  i can't remember how many various 
projects i've had to tweak the inline asm code to work with __PIC__ (either 
because it's going into shared library code or it's being built as a PIE).  
Andi's point is now we have to redo all of that work a 2nd time and handle two 
different cases depending on gcc version ?  it'd be a _lot_ better if gcc were 
intelligent and end users didn't have to code crap like stuffing %ebx somewhere 
temporarily.
-mike


signature.asc
Description: This is a digitally signed message part.

[PATCH] config: import pkg.m4 from pkg-config

[Mike Frysinger]

We use this in the sim tree currently.  Rather than require people to
have pkg-config installed, include it in the config/ dir.

Signed-off-by: Mike Frysinger 

2012-12-23  Mike Frysinger  

* pkg.m4: New file from pkg-config-0.27.
---
 config/pkg.m4 | 199 ++
 1 file changed, 199 insertions(+)
 create mode 100644 config/pkg.m4

diff --git a/config/pkg.m4 b/config/pkg.m4
new file mode 100644
index 000..f26f84c
--- /dev/null
+++ b/config/pkg.m4
@@ -0,0 +1,199 @@
+# pkg.m4 - Macros to locate and utilise pkg-config.-*- Autoconf -*-
+# serial 1 (pkg-config-0.24)
+# 
+# Copyright © 2004 Scott James Remnant .
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+#
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
+
+# PKG_PROG_PKG_CONFIG([MIN-VERSION])
+# --
+AC_DEFUN([PKG_PROG_PKG_CONFIG],
+[m4_pattern_forbid([^_?PKG_[A-Z_]+$])
+m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$])
+m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$])
+AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])
+AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search path])
+AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in search 
path])
+
+if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then
+   AC_PATH_TOOL([PKG_CONFIG], [pkg-config])
+fi
+if test -n "$PKG_CONFIG"; then
+   _pkg_min_version=m4_default([$1], [0.9.0])
+   AC_MSG_CHECKING([pkg-config is at least version $_pkg_min_version])
+   if $PKG_CONFIG --atleast-pkgconfig-version $_pkg_min_version; then
+   AC_MSG_RESULT([yes])
+   else
+   AC_MSG_RESULT([no])
+   PKG_CONFIG=""
+   fi
+fi[]dnl
+])# PKG_PROG_PKG_CONFIG
+
+# PKG_CHECK_EXISTS(MODULES, [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
+#
+# Check to see whether a particular set of modules exists.  Similar
+# to PKG_CHECK_MODULES(), but does not set variables or print errors.
+#
+# Please remember that m4 expands AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+# only at the first occurence in configure.ac, so if the first place
+# it's called might be skipped (such as if it is within an "if", you
+# have to call PKG_CHECK_EXISTS manually
+# --
+AC_DEFUN([PKG_CHECK_EXISTS],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
+if test -n "$PKG_CONFIG" && \
+AC_RUN_LOG([$PKG_CONFIG --exists --print-errors "$1"]); then
+  m4_default([$2], [:])
+m4_ifvaln([$3], [else
+  $3])dnl
+fi])
+
+# _PKG_CONFIG([VARIABLE], [COMMAND], [MODULES])
+# -
+m4_define([_PKG_CONFIG],
+[if test -n "$$1"; then
+pkg_cv_[]$1="$$1"
+ elif test -n "$PKG_CONFIG"; then
+PKG_CHECK_EXISTS([$3],
+ [pkg_cv_[]$1=`$PKG_CONFIG --[]$2 "$3" 2>/dev/null`
+ test "x$?" != "x0" && pkg_failed=yes ],
+[pkg_failed=yes])
+ else
+pkg_failed=untried
+fi[]dnl
+])# _PKG_CONFIG
+
+# _PKG_SHORT_ERRORS_SUPPORTED
+# -
+AC_DEFUN([_PKG_SHORT_ERRORS_SUPPORTED],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+if $PKG_CONFIG --atleast-pkgconfig-version 0.20; then
+_pkg_short_errors_supported=yes
+else
+_pkg_short_errors_supported=no
+fi[]dnl
+])# _PKG_SHORT_ERRORS_SUPPORTED
+
+
+# PKG_CHECK_MODULES(VARIABLE-PREFIX, MODULES, [ACTION-IF-FOUND],
+# [ACTION-IF-NOT-FOUND])
+#
+#
+# Note that if there is a possibility the first call to
+# PKG_CHECK_MODULES might not happen, you should be sure to include an
+# explicit call to PKG_PROG_PKG_CONFIG in your configure.ac
+#
+#
+# --
+AC_DEFUN([PKG_CHECK_MODULES],
+[AC_REQUIRE([PKG_PROG_PKG_CONFIG])dnl
+AC_ARG_VAR([$1][_CFLAGS], [C compiler flags for $1, overriding pkg-config])dnl
+AC_ARG_VAR([$1][_LIBS]

[PATCH 1/2] [pr53679] libgo: add a --enable-werror configure flag

[Mike Frysinger]

URL: http://gcc.gnu.org/PR53679
Signed-off-by: Mike Frysinger 
---
 libgo/configure| 15 ---
 libgo/configure.ac |  7 +--
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/libgo/configure b/libgo/configure
index 04fa89d..49cc4a9 100755
--- a/libgo/configure
+++ b/libgo/configure
@@ -809,6 +809,7 @@ enable_static
 with_pic
 enable_fast_install
 enable_libtool_lock
+enable_werror
 enable_version_specific_runtime_libs
 with_libffi
 with_system_libunwind
@@ -1449,6 +1450,7 @@ Optional Features:
   --enable-fast-install[=PKGS]
   optimize for fast installation [default=yes]
   --disable-libtool-lock  avoid locking (might break parallel builds)
+  --enable-werror turns on -Werror [default=yes]
   --enable-version-specific-runtime-libs
   Specify that runtime libraries should be installed
   in a compiler-specific directory
@@ -11102,7 +11104,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11105 "configure"
+#line 11107 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11208,7 +11210,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11211 "configure"
+#line 11213 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -13386,7 +13388,14 @@ done
 WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual'
 
 
-WERROR="-Werror"
+# Check whether --enable-werror was given.
+if test "${enable_werror+set}" = set; then :
+  enableval=$enable_werror;
+fi
+
+if test "x$enable_werror" != "xno"; then
+  WERROR="-Werror"
+fi
 
 
 glibgo_toolexecdir=no
diff --git a/libgo/configure.ac b/libgo/configure.ac
index 8cde50b..63d8cbc 100644
--- a/libgo/configure.ac
+++ b/libgo/configure.ac
@@ -50,8 +50,11 @@ AC_PROG_AWK
 WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual'
 AC_SUBST(WARN_FLAGS)
 
-dnl FIXME: This should be controlled by --enable-maintainer-mode.
-WERROR="-Werror"
+AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
+  [turns on -Werror @<:@default=yes@:>@])])
+if test "x$enable_werror" != "xno"; then
+  WERROR="-Werror"
+fi
 AC_SUBST(WERROR)
 
 glibgo_toolexecdir=no
-- 
1.8.0

[PATCH 2/2] [pr32193] libgomp: add a --enable-werror configure flag

[Mike Frysinger]

URL: http://gcc.gnu.org/PR32193
Signed-off-by: Mike Frysinger 

2012-12-23  Mike Frysinger  

PR libgomp/32193
* configure.ac: Call AC_ARG_ENABLE(werror).
(XCFLAGS): Add -Werror when enable_werror is not no.
* configure: Regenerated.
---
 libgomp/configure| 16 +---
 libgomp/configure.ac |  7 ++-
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/libgomp/configure b/libgomp/configure
index 238b1af..3add57f 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -760,6 +760,7 @@ enable_version_specific_runtime_libs
 enable_generated_files_in_srcdir
 enable_multilib
 enable_dependency_tracking
+enable_werror
 enable_shared
 enable_static
 with_pic
@@ -1410,6 +1411,7 @@ Optional Features:
   --enable-multilib   build many library versions (default)
   --disable-dependency-tracking  speeds up one-time build
   --enable-dependency-tracking   do not reject slow dependency extractors
+  --enable-werror turns on -Werror [default=yes]
   --enable-shared[=PKGS]  build shared libraries [default=yes]
   --enable-static[=PKGS]  build static libraries [default=yes]
   --enable-fast-install[=PKGS]
@@ -4280,9 +4282,17 @@ fi
 # in both places for now and restore CFLAGS at the end of config.
 save_CFLAGS="$CFLAGS"
 
+# Check whether --enable-werror was given.
+if test "${enable_werror+set}" = set; then :
+  enableval=$enable_werror;
+fi
+
 # Add -Wall -Werror if we are using GCC.
 if test "x$GCC" = "xyes"; then
-  XCFLAGS="$XCFLAGS -Wall -Werror"
+  XCFLAGS="$XCFLAGS -Wall"
+  if test "x$enable_werror" != "xno"; then
+XCFLAGS="$XCFLAGS -Werror"
+  fi
 fi
 
 # Find other programs we need.
@@ -11088,7 +11098,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11091 "configure"
+#line 11101 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11194,7 +11204,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11197 "configure"
+#line 11207 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index d87ed29..3b9cd4b 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -113,9 +113,14 @@ AC_SUBST(CFLAGS)
 # in both places for now and restore CFLAGS at the end of config.
 save_CFLAGS="$CFLAGS"
 
+AC_ARG_ENABLE(werror, [AS_HELP_STRING([--enable-werror],
+  [turns on -Werror @<:@default=yes@:>@])])
 # Add -Wall -Werror if we are using GCC.
 if test "x$GCC" = "xyes"; then
-  XCFLAGS="$XCFLAGS -Wall -Werror"
+  XCFLAGS="$XCFLAGS -Wall"
+  if test "x$enable_werror" != "xno"; then
+XCFLAGS="$XCFLAGS -Werror"
+  fi
 fi
 
 # Find other programs we need.
-- 
1.8.0

Re: PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes

[Mike Frysinger]

On Saturday 25 August 2012 18:31:32 H.J. Lu wrote:
> On Sat, Aug 25, 2012 at 3:27 PM, Mike Frysinger  wrote:
> > On Saturday 25 August 2012 11:58:08 H.J. Lu wrote:
> >> On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu  wrote:
> >> > Hi,
> >> > 
> >> > Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes:
> >> > 
> >> > as: error while loading shared libraries:
> >> > /builddir/build/BUILD/binutils/./opcodes/.libs/libopcodes-2.23.51.0.2-
> >> > 0.1 .fc17.so: file too short
> >> > make[4]: *** [gold-threads.o] Error 2
> >> > 
> >> > when compiling gold using binutils linked with the same versions of
> >> > libbfd and libopcodes. As far as I can tell, one can run the newly
> >> > built binutils without setting them since libtool already sets up
> >> > proper DT_RPATH.
> >> 
> >> The change was introduced by
> >> 
> >> http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01452.html
> >> 
> >> Paolo, do you remember the reason for this?
> >> 
> >> I tested this patch and works fine with --enable-shared for binutils.
> >> I tested both separate build directory and in-source build.  OK
> >> to install?
> > 
> > does this also fix:
> > http://sourceware.org/bugzilla/show_bug.cgi?id=4970
> 
> Yes, it should.  That is the same bug I ran into.  Please
> give my patch a try.

yep, seems to fix the use case i described (cross-compiler with shared libs 
enabled and running the same version of binutils with shared libs on the host)
-mike


signature.asc
Description: This is a digitally signed message part.

Re: PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes

[Mike Frysinger]

On Saturday 25 August 2012 11:58:08 H.J. Lu wrote:
> On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu  wrote:
> > Hi,
> > 
> > Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes:
> > 
> > as: error while loading shared libraries:
> > /builddir/build/BUILD/binutils/./opcodes/.libs/libopcodes-2.23.51.0.2-0.1
> > .fc17.so: file too short
> > make[4]: *** [gold-threads.o] Error 2
> > 
> > when compiling gold using binutils linked with the same versions of
> > libbfd and libopcodes. As far as I can tell, one can run the newly built
> > binutils without setting them since libtool already sets up proper
> > DT_RPATH.
> 
> The change was introduced by
> 
> http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01452.html
> 
> Paolo, do you remember the reason for this?
> 
> I tested this patch and works fine with --enable-shared for binutils.
> I tested both separate build directory and in-source build.  OK
> to install?

does this also fix:
http://sourceware.org/bugzilla/show_bug.cgi?id=4970
-mike


signature.asc
Description: This is a digitally signed message part.

Re: PATCH: Add x32 support to config.guess

[Mike Frysinger]

On Saturday 18 August 2012 14:01:57 H.J. Lu wrote:
> On Sat, Aug 18, 2012 at 10:40 AM, Mike Frysinger wrote:
> > On Saturday 18 August 2012 13:32:59 Mike Stump wrote:
> >> On Aug 18, 2012, at 6:52 AM, "H.J. Lu"  wrote:
> >> > In case of x32, the only difference between x32 and x86-64 is
> >> > the default output of CC.  What do you recommend how to
> >> > detect x32?
> >> 
> >> So, is there a cpp symbol that is defined for code-gen?  If so,
> >> something like
> >> 
> >>   If [ $(gcc -x c /dev/null -dM -E | grep x32) = x32 ]; then fi
> >> 
> >> Would do it.
> > 
> > how is executing `gcc` any better than $CC_FOR_BUILD ?
> > 
> > your code suggestion here is pretty much what H.J. Lu is already doing.
> 
> There are 12 existing set_cc_for_build usages in config.guess.
> I don't think it is reasonable to require x32 not to use it without
> providing an alternative.  If you want to remove set_cc_for_build,
> one extra usage doesn't make it much harder to do.

(in case it wasn't clear, i'm in favor of H.J. Lu's patch)
-mike


signature.asc
Description: This is a digitally signed message part.

Re: PATCH: Add x32 support to config.guess

[Mike Frysinger]

On Saturday 18 August 2012 13:32:59 Mike Stump wrote:
> On Aug 18, 2012, at 6:52 AM, "H.J. Lu"  wrote:
> > In case of x32, the only difference between x32 and x86-64 is
> > the default output of CC.  What do you recommend how to
> > detect x32?
> 
> So, is there a cpp symbol that is defined for code-gen?  If so, something
> like
> 
>   If [ $(gcc -x c /dev/null -dM -E | grep x32) = x32 ]; then fi
> 
> Would do it.

how is executing `gcc` any better than $CC_FOR_BUILD ?

your code suggestion here is pretty much what H.J. Lu is already doing.
-mike


signature.asc
Description: This is a digitally signed message part.

libiberty/md5: fix strict alias warnings

[Mike Frysinger]

Current libiberty md5 code triggers these warnings with gcc-4.7.1 for me:

libiberty/md5.c: In function ‘md5_finish_ctx’:
libiberty/md5.c:117:3: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]
libiberty/md5.c:118:3: warning: dereferencing type-punned pointer will break 
strict-aliasing rules [-Wstrict-aliasing]

The change below fixes things for me.  The optimized output (-O2) is the same
before/after my change on x86_64-linux.  I imagine it'll be the same for most
targets.  It seems simpler than using a union on the md5_ctx buffer since these
are the only two locations in the code where this occurs.

2012-07-27  Mike Frysinger  

* md5.c (md5_finish_ctx): Declare swap_bytes.  Assign SWAP() output
to swap_bytes, and then call memcpy to move it to ctx->buffer.

--- a/libiberty/md5.c
+++ b/libiberty/md5.c
@@ -102,7 +102,7 @@
 md5_finish_ctx (struct md5_ctx *ctx, void *resbuf)
 {
   /* Take yet unprocessed bytes into account.  */
-  md5_uint32 bytes = ctx->buflen;
+  md5_uint32 swap_bytes, bytes = ctx->buflen;
   size_t pad;
 
   /* Now count remaining bytes.  */
@@ -113,10 +113,13 @@
   pad = bytes >= 56 ? 64 + 56 - bytes : 56 - bytes;
   memcpy (&ctx->buffer[bytes], fillbuf, pad);
 
-  /* Put the 64-bit file length in *bits* at the end of the buffer.  */
-  *(md5_uint32 *) &ctx->buffer[bytes + pad] = SWAP (ctx->total[0] << 3);
-  *(md5_uint32 *) &ctx->buffer[bytes + pad + 4] = SWAP ((ctx->total[1] << 3) |
-   (ctx->total[0] >> 29));
+  /* Put the 64-bit file length in *bits* at the end of the buffer.
+ Use memcpy to avoid aliasing problems.  On most systems, this
+ will be optimized away to the same code.  */
+  swap_bytes = SWAP (ctx->total[0] << 3);
+  memcpy (&ctx->buffer[bytes + pad], &swap_bytes, sizeof (swap_bytes));
+  swap_bytes = SWAP ((ctx->total[1] << 3) | (ctx->total[0] >> 29));
+  memcpy (&ctx->buffer[bytes + pad + 4], &swap_bytes, sizeof (swap_bytes));
 
   /* Process last bytes.  */
   md5_process_block (ctx->buffer, bytes + pad + 8, ctx);


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Wednesday 23 May 2012 17:11:53 Michael Hope wrote:
> On 24 May 2012 02:16, Mike Frysinger wrote:
> > On Wednesday 23 May 2012 04:17:51 Richard Guenther wrote:
> >> On Wed, 23 May 2012, Andreas Jaeger wrote:
> >> > On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote:
> >> > > [...]
> >> > > This is a behaviour change.  It would need RM approval for a release
> >> > > branch.
> >> > > 
> >> > > R.
> >> > 
> >> > There was agreement by all pushing for the change to use it. So, let's
> >> > ask the release managers about their opinion,
> >> 
> >> I'm ok with the change - but of course only to carry one less patch
> >> in our local tree.  What do others think?  It would definitely (anyway)
> >> need documenting in changes.html (for both 4.7.1 and 4.8).
> > 
> > i've done this for Gentoo and 4.5.0+, so if all the distros are going to
> > be doing this in 4.7.x anyways, makes sense to me to do it in the
> > official branch.
> 
> Agreed.  Google have done it for their 4.6, Fedora have done it for
> 4.7 (?), and we've done it for Linaro GCC 4.6 and 4.7.
> 
> My concern is that a point release of GCC would stop working against
> the latest release of GLIBC.
> 
> I'm happy to prepare a backport to GCC 4.6, GCC 4.7, and GLIBC 2.15 so
> the next set of point releases will all work with each other.  This
> would match what the distros are doing.

http://sources.gentoo.org/gentoo/src/patchsets/gcc/4.6.3/gentoo/33_all_armhf.patch
http://sources.gentoo.org/gentoo/src/patchsets/gcc/4.7.0/gentoo/33_all_armhf.patch
http://sources.gentoo.org/gentoo/src/patchsets/glibc/2.15/6226_all_arm-glibc-2.15-hardfp.patch
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v2] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Wednesday 23 May 2012 04:17:51 Richard Guenther wrote:
> On Wed, 23 May 2012, Andreas Jaeger wrote:
> > On Wednesday, May 23, 2012 09:56:31 Richard Earnshaw wrote:
> > > [...]
> > > This is a behaviour change.  It would need RM approval for a release
> > > branch.
> > > 
> > > R.
> > 
> > There was agreement by all pushing for the change to use it. So, let's
> > ask the release managers about their opinion,
> 
> I'm ok with the change - but of course only to carry one less patch
> in our local tree.  What do others think?  It would definitely (anyway)
> need documenting in changes.html (for both 4.7.1 and 4.8).

i've done this for Gentoo and 4.5.0+, so if all the distros are going to be 
doing this in 4.7.x anyways, makes sense to me to do it in the official branch.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: Phone call (was Re: Armhf dynamic linker path)

[Mike Frysinger]

On Thursday 12 April 2012 13:53:13 Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 01:49:16PM -0400, Mike Frysinger wrote:
> > > ia64 installs in /lib, because it isn't a multilibbed architecture.
> > 
> > because distros choose not to support it.  in first gen chips, there was
> > hardware support for running x86.  so if we were to be strict, there
> > should have been /libia64/ (or whatever) while the current x86 32bit
> > code would stay in /lib/.  but no distro was interested in supporting
> > that (probably due to the 32bit x86 layers being balls-ass slow), so it
> > never happened.
> 
> We even carried patches (not applied) for lib64 ia64 support in our
> binutils/glibc/gcc for a while, but the final decision after these were
> written was that it is going to stay in /lib.

true, it would have been /lib64/ since the hardware doesn't the 64bit 
extensions for x86.  but i think the point still stands that using /lib/ for 
the new hardfloat ABI is OK rather than needing to go the /libhf/ multilib 
route.

and, if it turns out that we were being too optimistic and we do actually want 
soft/hard float multilib, i don't think this will be a blocker.  as mentioned, 
the s390x guys have been bad and it hasn't been a blocker for s390/s390x 
multilib with them :).
-mike


signature.asc
Description: This is a digitally signed message part.

Re: Phone call (was Re: Armhf dynamic linker path)

[Mike Frysinger]

On Thursday 12 April 2012 03:47:29 Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote:
> > On 12 April 2012 09:05, Jakub Jelinek  wrote:
> > > On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> > >> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
> > > The directory should be /libhf/ or /libhfp/ for that for consistency
> > > with all the other architectures.  Note e.g. x86_64 dynamic linker
> > > is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2.
> > 
> > For some value of consistency. x86_64, mips64, powerpc64 and sparc64
> > install to /lib64. But on ia64 it is /lib/ld-linux-ia64.so.2 and on
> 
> ia64 installs in /lib, because it isn't a multilibbed architecture.

because distros choose not to support it.  in first gen chips, there was 
hardware support for running x86.  so if we were to be strict, there should 
have been /libia64/ (or whatever) while the current x86 32bit code would stay 
in /lib/.  but no distro was interested in supporting that (probably due to 
the 32bit x86 layers being balls-ass slow), so it never happened.

> > s390x it is /lib/ld64.so.1 [1].
> 
> Ok, I forgot about this, I've tried to convince s390x folks to move it
> to /lib64/ld64.so.1 many years ago, but that just didn't happen, so
> /lib/ld64.so.1 is just a symlink to /lib64/ld64.so.1.
> Upstream glibc binaries use /lib64/ld64.so.1 as their dynamic linker,
> while all other packages use /lib/ld64.so.1 as that is hardcoded in gcc.

i always thought this was weird.  glad to know i'm not the only one :).
-mike


signature.asc
Description: This is a digitally signed message part.

Re: Phone call (was Re: Armhf dynamic linker path)

[Mike Frysinger]

On Thursday 12 April 2012 02:05:23 Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> > All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>
> The directory should be /libhf/ or /libhfp/ for that for consistency
> with all the other architectures.

i think the idea was that no one is looking to do multilib here.  so we won't 
have softfloat in /lib/ and hardfloat in /libhf/.  we're just changing the ldso 
to reflect a change in the ABI.

you could also make this argument for EABI and OABI -- the EABI ldso should 
not be in /lib/.  but since we've got OABI and EABI both in /lib/ and people 
are happy with that, as well as the hardfloat ldso in /lib/, there's no need 
for a sep /libhf/.

> I'm fine with arm and hf (resp. hfp) being mentioned in the name of
> the dynamic linker, but IMNSHO having there gnu and eabi strings
> is an overkill - why mention gnu there, when all the other
> architectures which also have GNU libc dynamic linkers don't?  That
> part is implicit.  And, EABI is implied by so.3, softfp dynamic linker
> for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old
> ABI is /lib/ld-linux.so.2.

i have no opinion either way here.  uClibc has already opted to name things 
with "-uClibc-" in them, so we're clear of collisions there.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Tuesday 10 April 2012 12:46:49 Michael Edwards wrote:
> That way I can grandfather in binaries with ABI-ignorant
> hard-coded library paths, and still handle ISA variants.  The
> "extranoise" might be "neon", or "ssse3"

aren't ISA variants handled already by glibc ?  that's what the hwcaps stuff 
does -- you can put optimized versions in ISA-specific subdirs of the normal 
lib paths.  glibc will look for those first before falling back to the common 
libs.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Tuesday 10 April 2012 01:17:36 Adam Conrad wrote:
> On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote:
> > On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
> > > I realize that most people can't see past their own use case to
> > > understand why a unique location for linkers is helpful, useful, and
> > > important for some other people's use cases, but you either didn't
> > > read or chose to ignore why using multilib paths just plain doesn't
> > > scale past a single base architecture, and why that's a problem for
> > > people who aren't you.
> > 
> > and as already stated, the proposed paths here, free of multiarch
> > subpaths, satisfy the requirements that you've put forth
> 
> Like I said, then, you didn't actually read or understand why proposing
> multilib paths doesn't work.  You realize conceptually, I hope, that
> there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once
> you cross the base CPU architecture boundary, right?

i don't see this as a problem

> Sure, I said that /libhf/ld-linux.so.3 would *accidentally* work for
> us right now, due to sheer luck, and you're running with that as saying
> that we clearly have no problem here worth solving.

my point was: it works today and has no clashes.  that satisfies the "omg we 
have to ship something $now" and satisfies the requirement that only the Debian 
people are putting forth (and has already been violated by many targets): the 
ldso must be unique across all arches/multilibs.

> When the next architecture clashes with linkers on another (hint: it almost
> certainly will), do we get to argue about this all over again in six months,
> instead of codifying a new and saner practice now?

i don't buy that it'll happen that soon (since ldso's don't get generated 
quickly), but that is certainly plenty of time for the Debian project to 
attempt to convince everyone else that multiarch isn't a waste of time.  and 
does so without holding up moving forward with a unified arm hardfloat abi.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Tuesday 10 April 2012 00:16:34 Jeff Law wrote:
> On 04/09/2012 05:14 PM, Mike Frysinger wrote:
> > tbh, i thought the ldso discussion was more "we've been talking about
> > this for a long time, so let's just go with XXX" and then people moved
> > on to the next topic (which was defining exactly what "hard float abi"
> > meant wrt compiler flags).  further, it seemed like we had distro
> > representation there, but not mainline gcc people.
> 
> Actually Mike, there was at least one mainline GCC person there.  Me.

my mistake.  i don't think we've met before, and that was a fairly busy time 
for me, so i probably missed things.  we should get a beer ;).

> Of course I was thrown into a discussion I knew nothing about

admittedly, that was the first time i've been in a linaro-related meeting 
before, and i hadn't been following linaro at all before (as the job i left 
before wasn't working on arm at all)

> goal of having a standardized path to discover ld.so which worked across
> distros seems like goodness to me.  Honestly, I don't see what all the
> resistance is about.

i think we have suggestions that would work for everyone ... but maybe this 
thread has gotten too big so we need to regroup with a summary
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Thursday 05 April 2012 12:25:09 Konstantinos Margaritis wrote:
> On Thu, 5 Apr 2012 11:55:14 -0400 Mike Frysinger wrote:
> > note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or
> > /libhf/ld-linux.so.[34].  /lib// is really the only one i
> > don't think doesn't belong.
> 
> and I'm just saying that I dislike /libhf, I also think that just raising
> the version is a wrong solution.

i can see why bumping ver # is undesirable, but i don't think it's that big of 
a deal.  the ldso is a bit of a magic beast, so i don't think applying the 
same SONAME versioning rules is terribly important.  especially since ARM has 
already moved from ld-linux.so.2 for OABI to ld-linux.so.3 for EABI.  you 
could even argue that enshrining hardfloat is actually an ABI version bump, so 
ld-linux.so.4 is appropriate.  and really, once you bump the SONAME, injecting 
substrings like "hf" are no different.

> > don't really know what you're talking about here.  other distros have no
> > problem with handling multilib.
> 
> multilib for softfloat/hardfloat on arm? I don't think so, even for other
> arches -it was already demonstrated that you cannot e.g. have powerpc
> e500v2 and e600 installed concurrently,

i'm not familiar with ppc's embedded variants, so i can't speak to these 
examples

> and anyway that's not the topic of
> the discussion here. Apart from multiarch there is no other solution to do
> that *for* arm, at least at the moment, because the two ABIs use exactly
> the same paths on a non-multiarch system.

i'm not sure why you think that.  if people actually want to do multilib with 
these, then there's nothing stopping people from doing that, once the ldso's 
are in a unique path.

> And I get back to the proposed
> solution /libhf -which is the multilib path you're referring to- and I'm
> saying that the topic here is for the linker path alone. In the
> hypothetical scenario that everyone agreed on /libhf for the linker path,
> but not for libraries -which would stay in /lib- , then we'd have a /libhf
> top directory with just one file, the linker. Or a symlink from /lib to
> /libhf or /lib/ to /libhf in Debian's case, but that defeats the
> purposes of having a new /libhf directory, doesn't it?

what Debian chooses to do with multiarch is up to Debian ... i don't think it 
should have any bearing here.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
> I realize that most people can't see past their own use case to understand
> why a unique location for linkers is helpful, useful, and important for
> some other people's use cases, but you either didn't read or chose to
> ignore why using multilib paths just plain doesn't scale past a single
> base architecture, and why that's a problem for people who aren't you.

and as already stated, the proposed paths here, free of multiarch subpaths, 
satisfy the requirements that you've put forth
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Monday 09 April 2012 16:48:06 Adam Conrad wrote:
> On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote:
> > On 4 April 2012 18:54, Jakub Jelinek wrote:
> > > If the agreement is that arm 32-bit softfp really needs to be
> > > installable alongside 32-bit hardfp (and alongside aarch64), then IMHO
> > > it should do it like all other multilib ports (x86_64/i?86/x32,
> > > s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says,
> > > e.g. use
> > > /lib/ld-linux.so.3 and */lib dirs for softfp,
> > > /libhf/ld-linux.so.3 and */libhf dirs for hardfp and
> > > /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
> > > arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
> > > MULTILIB_OSDIRNAMES, etc., have it configured in glibc
> > 
> > OK.  This gives a different path for the hard float loader and lets
> > the Debian guys add on top of that.  I'll ping them and see what they
> > think.
> 
> The problem here that everyone !Debian isn't taking into account is that
> multilib paths don't solve our use-case.  Multilib paths only solve the
> case of multiple ABIs on the same base processor family.  As soon as you
> combine x86, arm, power, etc, you end up with overlaps

and the problem there is that you're assuming anyone !Debian sees this as a 
problem.  so, once again, do not use the armhf standardization work to 
backdoor multiarch.  if you want to talk about multiarch, then start a new 
thread to do that.

> Ultimately, however, I want this solved.  We thought we had this solved at
> Plumbers last fall.  To hear now that we "didn't involve everyone" is
> disheartening, given that we ("we" being Debian and Ubuntu) were well
> outnumbered in that room by people from RedHat, Fedora, ChromeOS, and
> Gentoo.

tbh, i thought the ldso discussion was more "we've been talking about this for 
a long time, so let's just go with XXX" and then people moved on to the next 
topic (which was defining exactly what "hard float abi" meant wrt compiler 
flags).  further, it seemed like we had distro representation there, but not 
mainline gcc people.

> So, pretty please, can we (A) address the concerns here without people
> putting up the "Unique paths are Debian trying to force multi-arch on us"
> straw man, and (B) agree to *something*, before I ship something that
> conforms to a standard agreed upon more than half a year ago that is now
> a cause for contention?  Pretty please?  With sugar on top?  Kthx.

again, saying "/lib//" isn't multiarch is bunk.  but it sounds 
like you're fine with /libhf/, so there isn't anything left to thrash about 
there.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Thursday 05 April 2012 12:15:41 Steve McIntyre wrote:
> On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote:
> >On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
> >> Loic suggested a -IMHO- better solution: to change the dynamic linker
> >> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular
> >> case).
> >
> >the implication in supporting both hardfloat and softfloat simultaneously
> >is that you'd could have them both installed.  thus putting them both in
> >/lib/ doesn't make much sense if you're still going to need /libhf/ to
> >hold everything else.
> 
> Except you wouldn't - the Debian/Ubuntu plan with multi-arch is to put
> them all in cleanly-separated paths corresponding to the triplets.

/lib/ and /libhf/ is just as "clean" as /lib/ and /lib64/ (and now /libx32/).  
i see no difference here with a gcc configured for these multilib paths.

> I'm concerned that the potential proliferation of /lib* directories
> here could become very messy over time. I'm surprised that people seem
> to be happy to invent another namespace on a much more ad-hoc and
> arbitrary basis than the (mostly) well-understood triplets that we
> already have defined in the toolchains.

the triplet situation isn't as clean as you imply here.  there are already 
examples of not being able to tell the ABI based purely on that.  mips64-
linux-gnu could be n32 or n64.  x86_64-linux-gnu could be x86_64 or x32.

the Debian multiarch project might have made up new triplets to account for 
this, but those don't translate exactly into the same triplet that are used 
for e.g. configure --host.

> Multi-arch is an attempt to make things cleaner for those of us that
> care about having lots of different platforms supported in
> parallel. Seen against that background, I was hoping that using the
> multi-arch path for the armhf linker would make sense.

if you think that's a useful goal, then sure.  but not everyone thinks the 
multiarch proposal is really all that useful.  however, that (much larger) 
discussion is really out of scope here.

> For people that don't care about multi-arch for themselves, a simple
> symbolic link is all that's needed.

i think it's safe to say that the wider community has yet to be convinced, so 
extending existing support via the existing standards makes more sense.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Thursday 05 April 2012 11:24:15 Konstantinos Margaritis wrote:
> On Thu, 5 Apr 2012 11:08:56 -0400 Mike Frysinger wrote:
> > i don't think that's true.  on an x86_64 system, the 64bit libs are in
> > /lib64/.  some distros tried to (pointlessly imo) resist and force 64bits
> > into /lib/ when the native ABI was x86_64 (Gentoo included), but those
> > are legacy imo, and afaik, they didn't break the ldso paths.
> > 
> > so in a setup that only has hardfloat binaries, you'd have all the libs
> > in /libhf/, not just the ldso.
> 
> That's exactly my concern. If /libhf is chosen for the dymamic linker path,
> but it's not adopted by everyone else for libraries and other files, then
> at best you'd have a symlink, at worst a dir with only one file inside.

if gcc declares libhf as another multilib target, then everyone else will get 
it automatically

note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or 
/libhf/ld-linux.so.[34].  /lib// is really the only one i don't 
think doesn't belong.

> > the implication in supporting both hardfloat and softfloat simultaneously
> > is that you'd could have them both installed.  thus putting them both in
> > /lib/ doesn't make much sense if you're still going to need /libhf/ to
> > hold everything else.
> 
> That case has only any chance of realization in a multiarch environment
> such as Debian/Ubuntu.

don't really know what you're talking about here.  other distros have no 
problem with handling multilib.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Thursday 05 April 2012 10:38:07 Steve McIntyre wrote:
> On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
> >2012/4/4 Paulo César Pereira de Andrade
> >
> >>  I did two ports of Mandriva to armv7. One of my choice to use softfp,
> >> and another hardfp port to be compatible with other distros. But other
> >> than a previous armv5 port, there is not much else of Mandriva arm,
> >> so, it would be "good to have" to be able to run binaries for either
> >> without resorting to a chroot, and only testing purposes.
> >> 
> >>  Bumping major or calling it ld-linux-foo.so.3 is out of question?
> >
> >I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
> >questions here though: can the hard float loader have a different path
> >and, if so, what should it be?  We're still working on the first part.
> 
> We've previously discussed changing the name or the version number of
> the linker, but there was a worry that compatibility would be
> broken. Apparently the Meego folks have released a hard-float system
> using ld-linux.so.3 and were concerned about this.

i'm not sure how changing the leading dir components but leaving the base path 
the same would be any more or less work for meego to maintain backwards 
compatibility.  whatever random path is picked, they're going to be broken, as 
the ELF encodes the full path to the ldso.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
> On Wed, 4 Apr 2012 07:09:46 -0500 Dennis Gilmore wrote:
> > Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but
> > wouldn't object to /libhf  though today we have f17 about to go beta
> > and all of rawhide built using /lib
> 
>   One potential problem that is born from the /libhf suggestion is the
> danger of having a new top level directory (/libhf) with only one file,
> the dynamic linker. AFAIU it, no distro is currently willing to move away
> from its existing scheme (/lib)

i don't think that's true.  on an x86_64 system, the 64bit libs are in 
/lib64/.  some distros tried to (pointlessly imo) resist and force 64bits into 
/lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy 
imo, and afaik, they didn't break the ldso paths.

so in a setup that only has hardfloat binaries, you'd have all the libs in 
/libhf/, not just the ldso.

> Loic suggested a -IMHO- better solution: to change the dynamic linker
> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular
> case).

the implication in supporting both hardfloat and softfloat simultaneously is 
that you'd could have them both installed.  thus putting them both in /lib/ 
doesn't make much sense if you're still going to need /libhf/ to hold 
everything else.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: struct siginfo vs. siginfo_t (was: GNU C Library master sources branch, master, updated. glibc-2.15-229-g4efeffc)

[Mike Frysinger]

On Thursday 15 March 2012 11:57:00 Carlos O'Donell wrote:
> We should be rebuilding *all* of userspace when glibc changes. It
> would be nice if we setup an OpenEmbedded system to rebuild as much of
> x86-64 userspace as possible against a new glibc and check for
> regressions.

emerge -e world
-mike


signature.asc
Description: This is a digitally signed message part.

[PATCH] libmudflap: avoid legacy memory functions

[Mike Frysinger]

Mudflap checks a few legacy memory functions like bzero, and then passes
through the result to the C library's bzero.  However, these functions
are no longer required in the latest POSIX spec (and in previous ones,
they were marked as LEGACY), so some libraries will omit this which leads
to build failures in libmudflap.

Wrapping the legacy funcs on the frontend are fine, but that doesn't mean
that we need to implement things locally with those legacy funcs.  So use
the newer POSIX standard equivalents.

Signed-off-by: Mike Frysinger 

2011-12-15  Mike Frysinger  

* mf-hooks2.c (bzero wrapper): Change bzero call to memset.
(bcopy wrapper): Change bcopy call to memmove.
(bcmp wrapper): Change bcmp call to memcmp.
(index wrapper): Change index call to strchr.
(rindex wrapper): Change rindex call to strrchr.
---
 libmudflap/mf-hooks2.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/libmudflap/mf-hooks2.c b/libmudflap/mf-hooks2.c
index c030e69..f7c493e 100644
--- a/libmudflap/mf-hooks2.c
+++ b/libmudflap/mf-hooks2.c
@@ -424,7 +424,7 @@ WRAPPER2(void, bzero, void *s, size_t n)
 {
   TRACE ("%s\n", __PRETTY_FUNCTION__);
   MF_VALIDATE_EXTENT(s, n, __MF_CHECK_WRITE, "bzero region");
-  bzero (s, n);
+  memset (s, 0, n);
 }
 
 
@@ -434,7 +434,7 @@ WRAPPER2(void, bcopy, const void *src, void *dest, size_t n)
   TRACE ("%s\n", __PRETTY_FUNCTION__);
   MF_VALIDATE_EXTENT(src, n, __MF_CHECK_READ, "bcopy src");
   MF_VALIDATE_EXTENT(dest, n, __MF_CHECK_WRITE, "bcopy dest");
-  bcopy (src, dest, n);
+  memmove (dest, src, n);
 }
 
 
@@ -444,7 +444,7 @@ WRAPPER2(int, bcmp, const void *s1, const void *s2, size_t 
n)
   TRACE ("%s\n", __PRETTY_FUNCTION__);
   MF_VALIDATE_EXTENT(s1, n, __MF_CHECK_READ, "bcmp 1st arg");
   MF_VALIDATE_EXTENT(s2, n, __MF_CHECK_READ, "bcmp 2nd arg");
-  return bcmp (s1, s2, n);
+  return memcmp (s1, s2, n);
 }
 
 
@@ -453,7 +453,7 @@ WRAPPER2(char *, index, const char *s, int c)
   size_t n = strlen (s);
   TRACE ("%s\n", __PRETTY_FUNCTION__);
   MF_VALIDATE_EXTENT(s, CLAMPADD(n, 1), __MF_CHECK_READ, "index region");
-  return index (s, c);
+  return strchr (s, c);
 }
 
 
@@ -462,7 +462,7 @@ WRAPPER2(char *, rindex, const char *s, int c)
   size_t n = strlen (s);
   TRACE ("%s\n", __PRETTY_FUNCTION__);
   MF_VALIDATE_EXTENT(s, CLAMPADD(n, 1), __MF_CHECK_READ, "rindex region");
-  return rindex (s, c);
+  return strrchr (s, c);
 }
 
 /* XXX:  stpcpy, memccpy */
-- 
1.7.6.1

Re: [PATCH v2] _GCC_PICFLAG: use -fPIC for s390x targets

[Mike Frysinger]

On Thursday 08 December 2011 11:48:32 Rainer Orth wrote:
> Mike Frysinger  writes:
> > Building newer libiberty for s390x targets fails with relocation errors:
> > libiberty/pic/libiberty.a(hashtab.o): In function 'htab_create':
> > 
> > libiberty/hashtab.c:408:(.text+0x5e4): relocation truncated to fit:
> > R_390_GOT12 against symbol 'xcalloc' defined in .text section in
> > libiberty/pic/libiberty.a(xmalloc.o)
> > 
> > libiberty/pic/libiberty.a(hashtab.o): In function 'htab_try_create':
> > 
> > libiberty/hashtab.c:414:(.text+0x61c): relocation truncated to fit:
> > R_390_GOT12 against symbol 'calloc@@GLIBC_2.2' defined in .text
> > section in /lib/libc.so.6
> > 
> > collect2: ld returned 1 exit status
> > 
> > Building with larger GOT (-fPIC rather than -fpic) fixes this.
> 
> Unfortunately, you mostly ignored my review comments on the previous
> version.

not really.  what you ask is way beyond scope of s390x and is up to someone 
else to decide.  i'm not an s390 maintainer.
-mike


signature.asc
Description: This is a digitally signed message part.

[PATCH v2] _GCC_PICFLAG: use -fPIC for s390x targets

[Mike Frysinger]

Building newer libiberty for s390x targets fails with relocation errors:
libiberty/pic/libiberty.a(hashtab.o): In function 'htab_create':
libiberty/hashtab.c:408:(.text+0x5e4): relocation truncated to fit:
R_390_GOT12 against symbol 'xcalloc' defined in .text section in
libiberty/pic/libiberty.a(xmalloc.o)
libiberty/pic/libiberty.a(hashtab.o): In function 'htab_try_create':
libiberty/hashtab.c:414:(.text+0x61c): relocation truncated to fit:
R_390_GOT12 against symbol 'calloc@@GLIBC_2.2' defined in .text
section in /lib/libc.so.6
collect2: ld returned 1 exit status

Building with larger GOT (-fPIC rather than -fpic) fixes this.

CC: Aurelien Jarno 
CC: Martin Schwidefsky 
Signed-off-by: Mike Frysinger 

config/:
2011-12-06  Mike Frysinger  

* picflag.m4 (_GCC_PICFLAG): Set $1 to -fPIC for s390x*-*-*.

gcc/:
libada/:
libgcc/:
libiberty/:
2011-12-06  Mike Frysinger  

* configure: Regenerate.
---
v2
- fix typo when porting patch from older binutils

 config/picflag.m4 |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/config/picflag.m4 b/config/picflag.m4
index f6f1b44..b871d99 100644
--- a/config/picflag.m4
+++ b/config/picflag.m4
@@ -51,6 +51,9 @@ case "${$2}" in
 m68k-*-*)
$1=-fpic
;;
+s390x*-*-*)
+   $1=-fPIC
+   ;;
 s390*-*-*)
$1=-fpic
;;
-- 
1.7.6.1

[PATCH] _GCC_PICFLAG: use -fPIC for s390x targets

[Mike Frysinger]

Building newer libiberty for s390x targets fails with relocation errors:
libiberty/pic/libiberty.a(hashtab.o): In function 'htab_create':
libiberty/hashtab.c:408:(.text+0x5e4): relocation truncated to fit:
R_390_GOT12 against symbol 'xcalloc' defined in .text section in
libiberty/pic/libiberty.a(xmalloc.o)
libiberty/pic/libiberty.a(hashtab.o): In function 'htab_try_create':
libiberty/hashtab.c:414:(.text+0x61c): relocation truncated to fit:
R_390_GOT12 against symbol 'calloc@@GLIBC_2.2' defined in .text
section in /lib/libc.so.6
collect2: ld returned 1 exit status

Building with larger GOT (-fPIC rather than -fpic) fixes this.

CC: Aurelien Jarno 
CC: Martin Schwidefsky 
Signed-off-by: Mike Frysinger 

config/:
2011-12-06  Mike Frysinger  

* picflag.m4 (_GCC_PICFLAG): Set $1 to -fPIC for s390x*-*-*.

gcc/:
libada/:
libgcc/:
libiberty/:
2011-12-06  Mike Frysinger  

* configure: Regenerate.
---
 config/picflag.m4 |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/config/picflag.m4 b/config/picflag.m4
index f6f1b44..db2ce0f 100644
--- a/config/picflag.m4
+++ b/config/picflag.m4
@@ -51,6 +51,9 @@ case "${$2}" in
 m68k-*-*)
$1=-fpic
;;
+s390x*-*-*)
+   $1=-fpic
+   ;;
 s390*-*-*)
$1=-fpic
;;
-- 
1.7.6.1

[PATCH] start a gitignore

[Mike Frysinger]

I committed this to the sourceware repo a while ago before I was made
aware of the top level needing to be kept in sync with gcc.  So this
syncs that commit from sourceware CVS to gcc SVN.

---
 .gitignore |   40 
 ChangeLog  |4 
 2 files changed, 44 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..dc1bf3f
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,40 @@
+*.diff
+*.patch
+*.orig
+*.rej
+
+*~
+*.a
+*.flt
+*.gdb
+*.gmo
+*.info
+*.la
+*.lo
+*.o
+*.tmp
+
+.deps
+.libs
+
+autom4te.cache
+config.cache
+config.h
+config.intl
+config.log
+config.status
+libtool
+Makefile
+stamp-*
+POTFILES
+*-POTFILES
+*/po/Makefile.in
+
+.gdbinit
+.gdb_history
+core
+
+lost+found
+
+*.log
+*.sum
diff --git a/ChangeLog b/ChangeLog
index f97c1ab..22c8fc5 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2010-11-17  Mike Frysinger  
+
+   * .gitignore: New file.
+
 2010-11-05  Michael Eager  
 
* COPYING.LIBGLOSS: Correct typo in microblaze.
-- 
1.7.4.1

[PATCH] gitignore: ignore site.{bak,exp} treewide

[Mike Frysinger]

These files are never checked into cvs, and are generated by most
testsuites, so ignore them.

Signed-off-by: Mike Frysinger 

2011-03-28  Mike Frysinger  

* .gitignore: Ignore site.bak and site.exp.
---
 .gitignore |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/.gitignore b/.gitignore
index dc1bf3f..df5ae23 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,5 +36,7 @@ core
 
 lost+found
 
+site.bak
+site.exp
 *.log
 *.sum
-- 
1.7.4.1

Re: [PATCH] libdecnumber: start a gitignore

[Mike Frysinger]

2011/2/7 Mike Frysinger:
> Signed-off-by: Mike Frysinger 
> ---
>  libdecnumber/.gitignore |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>  create mode 100644 libdecnumber/.gitignore
>
> diff --git a/libdecnumber/.gitignore b/libdecnumber/.gitignore
> new file mode 100644
> index 000..7e47161
> --- /dev/null
> +++ b/libdecnumber/.gitignore
> @@ -0,0 +1 @@
> +/gstdint.h

i'll go ahead and commit then as no one complained ...
-mike

[PATCH] libdecnumber: start a gitignore

[Mike Frysinger]

Signed-off-by: Mike Frysinger 
---
 libdecnumber/.gitignore |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 libdecnumber/.gitignore

diff --git a/libdecnumber/.gitignore b/libdecnumber/.gitignore
new file mode 100644
index 000..7e47161
--- /dev/null
+++ b/libdecnumber/.gitignore
@@ -0,0 +1 @@
+/gstdint.h
-- 
1.7.4.1