[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