[gcc-6] 257/401: - complete libiberty backport

Ximin Luo infinity0 at debian.org
Wed Apr 5 15:49:56 UTC 2017


This is an automated email from the git hooks/post-receive script.

infinity0 pushed a commit to branch pu/reproducible_builds
in repository gcc-6.

commit c466405acb3bbbc707bc61c63064fa4f011ae5ab
Author: doko <doko at 6ca36cf4-e1d1-0310-8c6f-e303bb2178ca>
Date:   Wed Nov 9 14:58:04 2016 +0000

     - complete libiberty backport
    
    
    git-svn-id: svn://anonscm.debian.org/gcccvs/branches/sid/gcc-6@9035 6ca36cf4-e1d1-0310-8c6f-e303bb2178ca
---
 debian/patches/libiberty-updates.diff | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/debian/patches/libiberty-updates.diff b/debian/patches/libiberty-updates.diff
index b59921d..cdc8906 100644
--- a/debian/patches/libiberty-updates.diff
+++ b/debian/patches/libiberty-updates.diff
@@ -1295,3 +1295,23 @@
 +    memset ((char *) output + copy_size, 0, alloc_size - copy_size);
    return (PTR) memcpy (output, input, copy_size);
  }
+--- a/src/include/libiberty.h
++++ b/src/include/libiberty.h
+@@ -397,6 +397,17 @@
+ /* Save files used for communication between processes.  */
+ #define PEX_SAVE_TEMPS		0x4
+ 
++/* Max number of alloca bytes per call before we must switch to malloc.
++
++   ?? Swiped from gnulib's regex_internal.h header.  Is this actually
++   the case?  This number seems arbitrary, though sane.
++
++   The OS usually guarantees only one guard page at the bottom of the stack,
++   and a page size can be as small as 4096 bytes.  So we cannot safely
++   allocate anything larger than 4096 bytes.  Also care for the possibility
++   of a few compiler-allocated temporary stack slots.  */
++#define MAX_ALLOCA_SIZE	4032
++
+ /* Prepare to execute one or more programs, with standard output of
+    each program fed to standard input of the next.
+    FLAGS	As above.

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/gcc-6.git



More information about the Reproducible-commits mailing list