Bug#948317: gcc-10: Please disable gm2 on ia64

2020-01-07 Thread James Clarke 
On 7 Jan 2020, at 08:57, John Paul Adrian Glaubitz 
 wrote:
> On 1/7/20 9:54 AM, Matthias Klose wrote:
>>> The gcc-10 build currently fails on ia64 when trying to build gm2 [1],
>>> thus I have disabled gm2 for a local test build.
>> 
>> how does it fail?
> 
> The assembler is complaining [1]:
> 
> mv -f $depbase.Tpo $depbase.Plo
> libtool: compile:  /<>/build/./gcc/xgcc 
> -B/<>/build/./gcc/ -B/usr/ia64-linux-gnu/bin/ 
> -B/usr/ia64-linux-gnu/lib/ -isystem /usr/ia64-linux-gnu/include -isystem 
> /usr/ia64-linux-gnu/sys-include -isystem /<>/build/sys-include 
> -fchecking=1 -DHAVE_CONFIG_H -I. -I../../../src/libquadmath -I 
> ../../../src/libquadmath/../include -g -O2 -MT math/clogq.lo -MD -MP -MF 
> math/.deps/clogq.Tpo -c ../../../src/libquadmath/math/clogq.c  -fPIC -DPIC -o 
> math/.libs/clogq.o
> /tmp/ccyNARpA.s: Assembler messages:
> /tmp/ccyNARpA.s:40: Error: Wrong number of input operands
> /tmp/ccyNARpA.s:47: Error: Wrong number of input operands
> /tmp/ccyNARpA.s:81: Error: Wrong number of input operands
> /tmp/ccyNARpA.s:100: Error: Wrong number of input operands
> /tmp/ccyNARpA.s:109: Error: Wrong number of input operands
> /tmp/ccyNARpA.s:116: Error: Wrong number of input operands

I haven't tried building it yet, but suspect it's this:

src/gcc/m2/gm2-gcc/m2block.c:719:  tree instr = m2decl_BuildStringConstant 
("nop", 3);
src/gcc/m2/gm2-gcc/m2block.c-720-  tree string
src/gcc/m2/gm2-gcc/m2block.c-721-  = resolve_asm_operand_names (instr, 
NULL_TREE, NULL_TREE, NULL_TREE);
src/gcc/m2/gm2-gcc/m2block.c-722-  tree note = build_stmt 
(pending_location, ASM_EXPR, string, NULL_TREE,
src/gcc/m2/gm2-gcc/m2block.c-723-  NULL_TREE, 
NULL_TREE, NULL_TREE);

ia64's nop, like s390, is "nop 0", but unlike s390 there is no alias for just
"nop", you need to give the full instruction. Can we not avoid this and use
build_empty_stmt instead of creating inline assembly?

James

Bug#922496: GCC 9: gnat ftbs on kfreebsd-*

2019-07-03 Thread James Clarke 
Control: tags -1 patch upstream
Control: forwarded -1 https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00309.html

On Sun, Feb 17, 2019 at 07:44:37AM +0100, Matthias Klose wrote:
> Package: src:gcc-9
> Version: 9-20190216-2
> Tags: important
> Severity: sid bullseye
>
> ftbfs, and we still have local, not forwarded patches for kfreebsd.
>
> s-tpopmo.adb:61:25: expected private type "System.Os_Interface.clockid_t"
> s-tpopmo.adb:61:25: found type universal integer
> s-tpopmo.adb:76:34: expected private type "System.Os_Interface.clockid_t"
> s-tpopmo.adb:76:34: found type universal integer
> ../gcc-interface/Makefile:299: recipe for target 'a-dispat.o' failed
> make[8]: *** [a-dispat.o] Error 1
> make[8]: Leaving directory '/<>/build/gcc/ada/rts'
> gcc-interface/Makefile:622: recipe for target 'gnatlib' failed
> make[7]: *** [gnatlib] Error 2
> make[7]: Leaving directory '/<>/build/gcc/ada'
> gcc-interface/Makefile:714: recipe for target 'gnatlib-shared-dual' failed
> make[6]: *** [gnatlib-shared-dual] Error 2
> make[6]: Leaving directory '/<>/build/gcc/ada'
> gcc-interface/Makefile:811: recipe for target 'gnatlib-shared' failed
> make[5]: *** [gnatlib-shared] Error 2
> make[5]: Leaving directory '/<>/build/gcc/ada'
> Makefile:104: recipe for target 'gnatlib-shared' failed
> make[4]: *** [gnatlib-shared] Error 2

Hi Matthias,
Please add the above patch I've sent upstream, which should fix this.

Thanks,
James

Bug#929311: gcc-9: please include fix for pr87338

2019-05-21 Thread James Clarke 
Control: tags -1 pending
(sort of; changelog won't close this bug)

On 21 May 2019, at 14:24, Jason Duerstock  wrote:
> 
> Package: gcc-9
> Version: 9-20190428-1
> Severity: normal
> User: debian-i...@lists.debian.org
> Usertags: ia64
> 
> Dear Maintainer,
> 
> Please include the fix for pr87338 that was previously included in
> gcc-8.  This patch is required for gcc-9 to build under ia64.
> 
> Thank you.

Already done in git[1] less than an hour ago :)

James

[1] 
https://salsa.debian.org/toolchain-team/gcc/commit/8477738a263fd225e71b3d629c29c1bc38faca35

Bug#927976: gcc-8: FTBFS on ia64 due to bootstrap comparison failure

2019-04-25 Thread James Clarke 
Source: gcc-8
Version: 8-20180308-1
Severity: important
Tags: upstream patch
Forwarded: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg01000.html
X-Debbugs-Cc: debian-i...@lists.debian.org

Hi,
A bug in a new GCC 8.1 feature was exposed by an updated binutils with
debug_view support, which causes gcc-8 to FTBFS on ia64 with a bootstrap
comparison failure. Please include the above patch to fix this (possibly
only enabled on ia64 if you want to be conservative, as it has not been
widely tested on other architectures).

Thanks,
James

Bug#897416: gcc: Decimal float support is not enabled on kfreebsd-amd64

2018-07-05 Thread James Clarke 
Control: notfound -1 8.1.0-9 7.3.0-24thanks gcc-7/7.3.0-24
Control: found -1 7.3.0-24
Control: tags -1 upstream fixed-upstream
Control: forwarded -1 https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00219.html

On Thu, Jul 05, 2018 at 12:54:37PM +0200, Svante Signell wrote:
> On Thu, 2018-07-05 at 12:37 +0200, Svante Signell wrote:
> > On Tue, 2018-07-03 at 05:42 +0200, Matthias Klose wrote:
> > > On 01.07.2018 00:02, Svante Signell wrote:
> > > > reopen 897416
> > > > found 897416 7.3.0-24, 8.1.0-9
> > > > tags 897416 patch
> > > > thanks
> > > >
> > > > Hi, the patch by Matthias was not enough to make gcc-7,8 to build
> > > > properly. Three configure files were needed to be recreated from
> > > > their
> > > > corresponding configure.ac. Additionally, this patch use x86_64*-
> > > > *-
> > > > gnu*
> > > > to also cover the future implementation of 64bit Hurd.
> > >
> > > this is not applied upstream. Please test the patch on trunk,
> > > forward
> > > it upstream and make sure it gets applied.
> >
> > It is already forwarded upstream (somewhat differently) by James
> > Clarke: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00218.html
>
> Additional info: gcc-7-7.3.2-24 and gcc-8-8.1.0-9 built fine on
> kfreebsd-amd64 with the patch in this bug report.

Hi all,
The patch I submitted upstream (v2) has been applied to trunk (r62452).
I have modified it for the GCC Debian packaging (adding the src/ prefix
to the paths) so it should Just Work; please could you use it for the
next upload?

Thanks,
James
>From 1c703f62283a33508fbd5d2a9b38dd7bfaeb3c83 Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Thu, 14 Jun 2018 15:04:47 +0100
Subject: [PATCH v2] Enable decimal float on x86_64 kFreeBSD and Hurd
To: gcc-patc...@gcc.gnu.org

config/
* dfp.m4 (enable_decimal_float): Enable for x86_64*-*-gnu* to
catch x86_64 kFreeBSD and Hurd.

gcc/
* configure: Regenerate.

libdecnumber/
* configure: Regenerate.

libgcc/
* configure: Regenerate.
---
 config/dfp.m4  | 2 +-
 gcc/configure  | 2 +-
 libdecnumber/configure | 2 +-
 libgcc/configure   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/config/dfp.m4 b/src/config/dfp.m4
index 5b29089cec5..a137ddebf8c 100644
--- a/src/config/dfp.m4
+++ b/src/config/dfp.m4
@@ -21,7 +21,7 @@ Valid choices are 'yes', 'bid', 'dpd', and 'no'.]) ;;
 [
   case $1 in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/src/gcc/configure b/src/gcc/configure
index 60d373982fd..35564942bbf 100755
--- a/src/gcc/configure
+++ b/src/gcc/configure
@@ -7458,7 +7458,7 @@ else
 
   case $target in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/src/libdecnumber/configure b/src/libdecnumber/configure
index 4cb732e80d4..b1588f4e884 100755
--- a/src/libdecnumber/configure
+++ b/src/libdecnumber/configure
@@ -4709,7 +4709,7 @@ else
 
   case $target in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
diff --git a/src/libgcc/configure b/src/libgcc/configure
index b2f3f870844..f395474beac 100644
--- a/src/libgcc/configure
+++ b/src/libgcc/configure
@@ -4647,7 +4647,7 @@ else
 
   case $host in
 powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | \
-i?86*-*-elfiamcu | i?86*-*-gnu* | \
+i?86*-*-elfiamcu | i?86*-*-gnu* | x86_64*-*-gnu* | \
 i?86*-*-mingw* | x86_64*-*-mingw* | \
 i?86*-*-cygwin* | x86_64*-*-cygwin*)
   enable_decimal_float=yes
-- 
2.17.0

Bug#897416: mpfr4: FTBFS on kfreebsd-amd64

2018-05-03 Thread James Clarke 
On 3 May 2018, at 09:21, Svante Signell <svante.sign...@gmail.com> wrote:
> On Wed, 2018-05-02 at 12:51 +0100, James Clarke wrote:
>> Control: reassign -1 gcc-7
>> Control: retitle -1 gcc: Decimal float support is not enabled on kfreebsd-
>> amd64
>> 
>> On 2 May 2018, at 10:38, Svante Signell <svante.sign...@gmail.com> wrote:
>>> 
>>> Source: mpfr4
>>> Version: 4.0.1-1
>>> Severity: important
>>> Tags: patch
>>> User: debian-...@lists.debian.org
>>> Usertags: kfreebsd
>>> 
>>> Hi,
>>> 
>>> mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the
>>> debian/libmpfr6.symbols
>>> file. Attached is a file with the symbols generated from the build:
>>> libmpfr6.symbols.kfreebsd-amd64.
>>> 
>>> Thanks!
>> 
>> You're right that the symbols file is currently wrong, but IMO gcc should 
>> have
>> decimal float support enabled for kfreebsd-amd64. It's enabled for
>> kfreebsd-i386 by virtue of the fact that i?86*-*-gnu* (for Hurd) matches
>> kfreebsd-i386's tuple, but there's no corresponding x86_64*-*-gnu* for a
>> future
>> 64-bit Hurd, and thus kfreebsd-amd64's tuple is not matched[0].
>> 
>> James
>> 
>> [0] https://github.com/gcc-mirror/gcc/blob/trunk/config/dfp.m4#L23-L26
> 
> Hi James,
> 
> I think it is unfortunate that you reassigned this bug to gcc-7. That will not
> solve the mpfr4 build on the buildds.
> 
> There are two ways to solve this problem:
> 1)
> - reassign this bug back to mpfr4, adding the libfr6.symbols.kfreebsd-amd64 in
> next version 4.0.1-2.

Well, if you wanted to do that, it should be by changing the (arch=...)
restriction lists in the main libfr6.symbols rather than forking a copy for
kfreebsd-amd64.

> - clone this bug to gcc-7, adding a patch to dfp.m4 so it can be integrated in
> next release of gcc-7: 7.3.0-18?

Personally I'd just get gcc patched and give back mpfr4.

> 2) (not preferred)
> - Build an NMUed version of mpfr4, 4.0.1-1.1, and install it at debian-ports. 

Indeed, unreleased uploads are best avoided when possible.

> For GNU/Hurd the entry in sources.list is
> deb http://ftp.ports.debian.org/debian-ports unreleased main
> 
> What about creating
> http://ftp.ports.debian.org/debian-ports/pool-kfreebsd-{amd64,i386} and 
> populate
> the mpfr4 packages there at pool-kfreebsd-amd64/m/. Additionally the buildds
> need to use these packages. Unfortunately I don't know how to do that.

We could, and may well eventually need an unreleased suite, but not now.
Getting the buildds to see the suite would be simple; wanna-build would need a
copy of the hurd code to tell it that unreleased exists, and our buildd setup
scripts would need tweaking to add it to apt's sources in the chroots.

> Then when gcc-7-7.3.0-18 is released, an updated version of mpfr4 is hopefully
> available (if not, what to do, how to get back to using the old version?)

In such a situation, the updated version of mpfr4 in unstable would be picked
by `apt upgrade` as unstable and unreleased get the same priority by default,
just like how you automatically get security updates from stretch/updates for
packages installed from the stretch archive on ftp-master.

James

Bug#897416: mpfr4: FTBFS on kfreebsd-amd64

2018-05-02 Thread James Clarke 
Control: reassign -1 gcc-7
Control: retitle -1 gcc: Decimal float support is not enabled on kfreebsd-amd64

On 2 May 2018, at 10:38, Svante Signell  wrote:
> 
> Source: mpfr4
> Version: 4.0.1-1
> Severity: important
> Tags: patch
> User: debian-...@lists.debian.org
> Usertags: kfreebsd
> 
> Hi,
> 
> mpfr4 FTBFS on kFreebsd-amd64 due to mismatches in the debian/libmpfr6.symbols
> file. Attached is a file with the symbols generated from the build:
> libmpfr6.symbols.kfreebsd-amd64.
> 
> Thanks!

You're right that the symbols file is currently wrong, but IMO gcc should have
decimal float support enabled for kfreebsd-amd64. It's enabled for
kfreebsd-i386 by virtue of the fact that i?86*-*-gnu* (for Hurd) matches
kfreebsd-i386's tuple, but there's no corresponding x86_64*-*-gnu* for a future
64-bit Hurd, and thus kfreebsd-amd64's tuple is not matched[0].

James

[0] https://github.com/gcc-mirror/gcc/blob/trunk/config/dfp.m4#L23-L26

Bug#884642: libgo11: Please backport upstream sparc64 fix

2017-12-17 Thread James Clarke 
Package: libgo11
Version: 7.2.0-17
Tags: upstream fixed-upstream patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi,
For a while, libgo11 on sparc64 has been broken, with executables
crashing with messages like:

> runtime: lfstackpush invalid packing: node=0xfff8000102424000 cnt=1 
> packed=283958541549569 -> node=0x102424000

whenever runtime_gc is called. This is because lfstack_64bit.go has
incorrect assumptions about the virtual address space, and so clobbers
the node address when packing. Please apply the attached debdiff, which
is a backport of the upstream fix (the change to gcc/go/gofrontend/MERGE
has been dropped as it's needless noise that is likely to just cause
conflicts). In my testing it completely fixes that error with no traces
of it in the build log.

Regards,
James
diff -u gcc-7-7.2.0/debian/rules.patch gcc-7-7.2.0/debian/rules.patch
--- gcc-7-7.2.0/debian/rules.patch
+++ gcc-7-7.2.0/debian/rules.patch
@@ -75,6 +75,7 @@
pr77631 \
pr67165 \
cuda-float128 \
+   libgo-sparc64 \
libgo-ia64 \
pr82880 \
libcc1-compiler-name \
only in patch2:
unchanged:
--- gcc-7-7.2.0.orig/debian/patches/libgo-sparc64.diff
+++ gcc-7-7.2.0/debian/patches/libgo-sparc64.diff
@@ -0,0 +1,99 @@
+From c536feb42f56afd6397697f9ee9e5d8d918bef1b Mon Sep 17 00:00:00 2001
+From: ian 
+Date: Wed, 31 May 2017 21:36:42 +
+Subject: [PATCH] libgo: support for sparc64 GNU/Linux
+
+Fix lfstack code to work with sparc64 GNU/Linux address map.
+
+Force alignment of epollevent.  To make this work reliably, pass
+GOARCH explicitly to mkrsysinfo.sh.
+
+Patch by Vladimir Mezentsev.
+
+Reviewed-on: https://go-review.googlesource.com/44494
+
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248765 
138bc75d-0d04-0410-961f-82ee72b054a4
+---
+[gcc/go/gofrontend/MERGE   |  2 +-]
+ libgo/Makefile.am |  2 +-
+ libgo/Makefile.in |  2 +-
+ libgo/go/runtime/lfstack_64bit.go | 12 
+ libgo/mkrsysinfo.sh   |  6 +-
+ 5 files changed, 20 insertions(+), 4 deletions(-)
+
+diff --git a/src/libgo/Makefile.am b/src/libgo/Makefile.am
+index 8bbd43771447..0f9881ffaa4e 100644
+--- a/src/libgo/Makefile.am
 b/src/libgo/Makefile.am
+@@ -531,7 +531,7 @@ s-version: Makefile
+ 
+ runtime_sysinfo.go: s-runtime_sysinfo; @true
+ s-runtime_sysinfo: $(srcdir)/mkrsysinfo.sh gen-sysinfo.go
+-  $(SHELL) $(srcdir)/mkrsysinfo.sh
++  GOARCH=$(GOARCH) GOOS=$(GOOS) $(SHELL) $(srcdir)/mkrsysinfo.sh
+   $(SHELL) $(srcdir)/mvifdiff.sh tmp-runtime_sysinfo.go runtime_sysinfo.go
+   $(STAMP) $@
+ 
+diff --git a/src/libgo/Makefile.in b/src/libgo/Makefile.in
+index cbdd37998369..2452f967252b 100644
+--- a/src/libgo/Makefile.in
 b/src/libgo/Makefile.in
+@@ -3081,7 +3081,7 @@ s-version: Makefile
+ 
+ runtime_sysinfo.go: s-runtime_sysinfo; @true
+ s-runtime_sysinfo: $(srcdir)/mkrsysinfo.sh gen-sysinfo.go
+-  $(SHELL) $(srcdir)/mkrsysinfo.sh
++  GOARCH=$(GOARCH) GOOS=$(GOOS) $(SHELL) $(srcdir)/mkrsysinfo.sh
+   $(SHELL) $(srcdir)/mvifdiff.sh tmp-runtime_sysinfo.go runtime_sysinfo.go
+   $(STAMP) $@
+ 
+diff --git a/src/libgo/go/runtime/lfstack_64bit.go 
b/src/libgo/go/runtime/lfstack_64bit.go
+index 213efb107068..b314a3ba2169 100644
+--- a/src/libgo/go/runtime/lfstack_64bit.go
 b/src/libgo/go/runtime/lfstack_64bit.go
+@@ -32,9 +32,18 @@ const (
+   // bottom, because node must be pointer-aligned, giving a total of 19 
bits
+   // of count.
+   cntBits = 64 - addrBits + 3
++
++  // On sparc64-linux, user addresses are 52-bit numbers sign extended to 
64.
++  // We shift the address left 12 to eliminate the sign extended part and 
make
++  // room in the bottom for the count.
++  sparcLinuxAddrBits = 52
++  sparcLinuxCntBits  = 64 - sparcLinuxAddrBits + 3
+ )
+ 
+ func lfstackPack(node *lfnode, cnt uintptr) uint64 {
++  if GOARCH == "sparc64" && GOOS == "linux" {
++  return 
uint64(uintptr(unsafe.Pointer(node)))<<(64-sparcLinuxAddrBits) | 
uint64(cnt&(1<> cntBits 
<< 3)))
+   }
++  if GOARCH == "sparc64" && GOOS == "linux" {
++  return (*lfnode)(unsafe.Pointer(uintptr(int64(val) >> 
sparcLinuxCntBits << 3)))
++  }
+   return (*lfnode)(unsafe.Pointer(uintptr(val >> cntBits << 3)))
+ }
+diff --git a/src/libgo/mkrsysinfo.sh b/src/libgo/mkrsysinfo.sh
+index a86e9143bf46..6ab80e625d93 100755
+--- a/src/libgo/mkrsysinfo.sh
 b/src/libgo/mkrsysinfo.sh
+@@ -83,7 +83,11 @@ if grep '^const _epoll_data_offset ' ${OUT} >/dev/null 
2>&1;

Bug#833829: libgcc-6-dev: Missing crtfastmath.o on kfreebsd-*

2017-05-15 Thread James Clarke 
On Tue, Sep 06, 2016 at 03:17:52PM +0200, Andreas Beckmann wrote:
> Control: retitle -1 libgcc-6-dev: Missing crtfastmath.o on kfreebsd-*
> Control: affects -1 + src:vlc
>
> On Tue, 9 Aug 2016 11:39:54 +0200 Matthias Klose  wrote:
> > > I'm unable to build a package because crtfastmath.o is missing from this
> > > package. Architecture is kfreebsd-i386. I don't see this bug on the
> > > kfreebsd-amd64
> > >
> > > ,
> > > | cc -Wall -DPIC   -O2 -pipe -fno-tree-dominator-opts -fno-tree-pre 
> > > -ffast-math -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g -D_FILE_OFFSET_BITS=64 
> > > -D_LARGEFILE_SOURCE -fPIC -pthreadluma.c   -o luma
> > > | /usr/bin/ld: cannot find crtfastmath.o: No such file or directory
> > > `
> >
> > https://buildd.debian.org/status/fetch.php?pkg=gcc-6=kfreebsd-i386=6.1.1-11=1470331624
> >
> > looks like this is never built, and the install step succeeds despite it
> > complains about not finding this file.
>
> Seems to be specific to gcc-6, the file is available in libgcc-4.9-dev,
> libgcc-5-dev, and gcc-snapshot (7.0.0).
>
> This bug is the cause for the FTBFS of vlc on both kfreebsd-amd64 and
> kfreebsd-i386:
>
> https://buildd.debian.org/status/fetch.php?pkg=vlc=kfreebsd-amd64=2.2.4-3%2Bb4=1472902929
> https://buildd.debian.org/status/fetch.php?pkg=vlc=kfreebsd-i386=2.2.4-3%2Bb4=1472905628

This seems to be caused by the fact that t-crtfm moved from
libgcc/config/i386 to just libgcc/config between GCC 5 and 6, but
kfreebsd-unwind.diff wasn't updated to reflect this (GCC 7's was though,
but there's another issue below). Patch included, though I haven't
actually tested it.

Matthias, I noticed a couple of other things when exploring this:

 1. GCC 5 and 6 both omit the tm_file="${tm_file} i386/elf-lib.h"
statement in the new kfreebsd branch for both x86_64 and i386, but
GCC 7 includes it.

 2. (Likely more important) GCC 7's kfreebsd-unwind.diff is missing the
change for x86_64[1], so I assume only i386 has unwind support.

Let me know if you want separate bugs for either of these.

Regards,
James

[1] 
https://sources.debian.net/src/gcc-7/7.1.0-5/debian/patches/kfreebsd-unwind.diff/

---
diff -u gcc-6-6.3.0/debian/patches/kfreebsd-unwind.diff 
gcc-6-6.3.0/debian/patches/kfreebsd-unwind.diff
--- gcc-6-6.3.0/debian/patches/kfreebsd-unwind.diff
+++ gcc-6-6.3.0/debian/patches/kfreebsd-unwind.diff
@@ -11,7 +11,7 @@
 -i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | i[34567]86-*-gnu* | 
i[34567]86-*-kopensolaris*-gnu)
 +i[34567]86-*-kfreebsd*-gnu)
 +  extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o 
crtfastmath.o"
-+  tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff 
t-dfprules"
++  tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff 
t-dfprules"
 +  md_unwind_header=i386/freebsd-unwind.h
 +  ;;
 +i[34567]86-*-knetbsd*-gnu | i[34567]86-*-gnu* | 
i[34567]86-*-kopensolaris*-gnu)
@@ -25,7 +25,7 @@
 -x86_64-*-kfreebsd*-gnu | x86_64-*-knetbsd*-gnu)
 +x86_64-*-kfreebsd*-gnu)
 +  extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o 
crtfastmath.o"
-+  tmake_file="${tmake_file} i386/t-crtpc i386/t-crtfm i386/t-crtstuff 
t-dfprules"
++  tmake_file="${tmake_file} i386/t-crtpc t-crtfm i386/t-crtstuff 
t-dfprules"
 +  md_unwind_header=i386/freebsd-unwind.h
 +  ;;
 +x86_64-*-knetbsd*-gnu)

Bug#823937: gcc -E has __DATE__/__TIME__ as Jan 1 1970 00:00:00

2017-05-12 Thread James Clarke 
On Tue, May 10, 2016 at 04:32:58PM +0100, James Clarke wrote:
> Package: gcc-5
> Version: 5.3.1-17
> Severity: normal
> Tags: upstream patch
> Control: clone -1 -2
> Control: reassign -2 gcc-6 6.1.1-1
>
> Hi,
> With the SOURCE_DATE_EPOCH patch from upstream, the __DATE__ and
> __TIME__ macros always give Jan 1 1970 00:00:00 when running the
> preprocessor on its own with gcc -E[1]. I believe this is because
> c_lex_with_flags is not called when just preprocessing (no C code needs
> to be lexed), so pfile->source_date_epoch stays initialised to 0, and
> subsequent __DATE__/__TIME__ expansions believe that the timestamp has
> been set to epoch 0. I have attached an alternative implementation of
> gcc-SOURCE_DATE_EPOCH.diff which fixes this, by initialising
> pfile->source_date_epoch inside libcpp when pfile is initially created.
>
> [1] https://paste.debian.net/683081/

Hi,
I notice 5.4.0-1 included a backport of r237001 to fix this, but the
upstream commit introduced a regression fixed in r237408 which *wasn't*
backported to this. Could you please bundle that into the next upload? I
guess it's not especially important now gcc-5 is out of testing, but it
would still be nice to have this fixed.

(The regression introduced is that SOURCE_DATE_EPOCH isn't used when
rnning just the preprocessor [previously it would always act as if it
was 0, but now it always uses the current time] so if you do:

echo __DATE__ | SOURCE_DATE_EPOCH=86400 gcc-5 -E -

you get the current date, not "Jan  2 1970").

Regards,
James

Bug#854090: gcc-6: Please enable PIE hardening flags by default on sparc*

2017-02-03 Thread James Clarke 
Package: gcc-6
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Please enable PIE by default on sparc and sparc64.

Regards,
James

Bug#854061: Lack of hardening=+pie gives unwanted, unsilenceable noisy compiler output

2017-02-03 Thread James Clarke 
Package: gcc-6, dpkg-dev
Severity: important
X-Debbugs-Cc: debian-ports-de...@lists.alioth.debian.org
Control: block 851720 by -1

As far as I can tell, no progress has been made on this issue since the
few discussions on debian-devel[0]. The current state is not desirable,
and in fact is causing at least one crucial package, cmake, to FTBFS
(see the block above). This needs to be resolved one way or another.

Regards,
James

[0] https://lists.debian.org/debian-devel/2017/01/msg00522.html

Bug#851698: Dangling symlinks in /usr/share/man

2017-01-17 Thread James Clarke 
Package: gcc
Version: 4:6.2.1-1
Severity: important

The following symlinks are currently dangling:

/usr/share/man/man1/gcc-ar.1.gz -> gcc-ar-6.1.gz
/usr/share/man/man1/gcc-nm.1.gz -> gcc-nm-6.1.gz
/usr/share/man/man1/gcc-ranlib.1.gz -> gcc-ranlib-6.1.gz
/usr/share/man/man1/x86_64-linux-gnu-gcc-ar.1.gz -> gcc-ar-6.1.gz
/usr/share/man/man1/x86_64-linux-gnu-gcc-nm.1.gz -> gcc-nm-6.1.gz
/usr/share/man/man1/x86_64-linux-gnu-gcc-ranlib.1.gz -> gcc-ranlib-6.1.gz

They should point to x86_64-linux-gnu-gcc-ar-6.1.gz, etc.

Regards,
James



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: x32

Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc depends on:
ii  cpp4:6.2.1-1
ii  gcc-6  6.3.0-2

Versions of packages gcc recommends:
ii  libc6-dev [libc-dev]  2.24-8

Versions of packages gcc suggests:
ii  autoconf  2.69-10
ii  automake  1:1.15-5
ii  bison 2:3.0.4.dfsg-1
ii  flex  2.6.1-1.3
pn  gcc-doc   
pn  gcc-multilib  
ii  gdb   7.12-4
ii  libtool   2.4.6-2
ii  make  4.1-9
ii  manpages-dev  4.09-2

-- no debconf information

Bug#850250: FTBFS on sparc with DEB_BUILD_OPTIONS=nolang=biarch

2017-01-05 Thread James Clarke 
Source: gcc-6
Version: 6.3.0-2
Tags: patch
User: debian-sp...@lists.debian.org
Usertag: sparc
X-Debbugs-Cc: helm...@debian.org, debian-sp...@lists.debian.org

Thanks to the recent changes to get gcc to target ultrasparc by default,
the biarch build is now successful. However, it still fails in exactly
the same way when biarch is disabled; I believe the following patch
should fix this. Is there a good reason why this wasn't done before,
other than an oversight?

Regards,
James

> --- debian/rules2.orig  2017-01-05 11:06:00.846518693 +
> +++ debian/rules2   2017-01-05 11:08:24.644346025 +
> @@ -543,9 +543,9 @@
>  endif
>
>  ifneq (,$(findstring sparc-linux,$(DEB_TARGET_GNU_TYPE)))
> +  CONFARGS += --with-cpu-32=ultrasparc
>ifeq ($(biarch64),yes)
>  CONFARGS += --enable-targets=all
> -CONFARGS += --with-cpu-32=ultrasparc
>endif
>  endif
>

Bug#849542: PIE specs ignored even with DEB_BUILD_MAINT_OPTIONS hardening

2016-12-28 Thread James Clarke 
Package: gcc-6
Version: 6.2.1-7
Severity: important

The check introduced to ignore dpkg's PIE specs when PIE is not enabled
by default is wrong, and ends up ignoring them even when hardening=+all
or hardening=+pie is present in DEB_BUILD_MAINT_OPTIONS.

The current check is:

>   if (ignore_pie_specs_when_not_enabled("DEB_BUILD_MAINT_OPTIONS", arg)
>  || ignore_pie_specs_when_not_enabled("DEB_BUILD_OPTIONS", arg))

but since only DEB_BUILD_MAINT_OPTIONS includes the hardening options,
the second call with DEB_BUILD_OPTIONS returns true and causes the file
to be ignored. I believe this should be && rather than ||.

I can reproduce this regression by building one of my packages
(src:polyml) on sparc64:

> $ grep hardening debian/rules
> export DEB_BUILD_MAINT_OPTIONS=hardening=+all
> $ dpkg-buildpackage -us -uc
> [...]
> g++: note: pie specs /usr/share/dpkg/pie-compile.specs ignored when pie is 
> not enabled

Regards,
James

Bug#840574: Please backport libgo fixes for sparc64

2016-10-20 Thread James Clarke 
Hi Matthias,
As promised yesterday on #debian-toolchain, here is a debdiff to fix the
libgo debug/elf testsuite failure by providing a uuencoded copy of
go-relocation-test-gcc620-sparc64.obj.

Regards,
James
diff -u gcc-6-6.2.0/debian/changelog gcc-6-6.2.0/debian/changelog
--- gcc-6-6.2.0/debian/changelog
+++ gcc-6-6.2.0/debian/changelog
@@ -1,3 +1,10 @@
+gcc-6 (6.2.0-9+sparc64) UNRELEASED; urgency=medium
+
+  * Include go-relocation-test-gcc620-sparc64.obj.uue to fix libgo's
+debug/elf TestDWARFRelocations test case.
+
+ -- James Clarke <jrt...@jrtc27.com>  Thu, 20 Oct 2016 20:32:51 +0100
+
 gcc-6 (6.2.0-9) unstable; urgency=medium
 
   * Regenerate the control file.
diff -u gcc-6-6.2.0/debian/patches/libgo-elf-relocations-sparc64.diff 
gcc-6-6.2.0/debian/patches/libgo-elf-relocations-sparc64.diff
--- gcc-6-6.2.0/debian/patches/libgo-elf-relocations-sparc64.diff
+++ gcc-6-6.2.0/debian/patches/libgo-elf-relocations-sparc64.diff
@@ -1,4 +1,7 @@
 # DP: Backport r241051 from trunk
+# DP: src/libgo/go/debug/elf/testdata/go-relocation-test-gcc620-sparc64.obj is
+# DP: encoded in debian/go-relocation-test-gcc620-sparc64.obj.uue and is
+# DP: decoded at patch time.
 
 debug/elf: add sparc64 relocations
 
@@ -104,4 +106,0 @@
-Index: b/src/libgo/go/debug/elf/testdata/go-relocation-test-gcc620-sparc64.obj
-===
-Cannot display: file marked as a binary type.
-svn:mime-type = application/octet-stream
diff -u gcc-6-6.2.0/debian/rules.patch gcc-6-6.2.0/debian/rules.patch
--- gcc-6-6.2.0/debian/rules.patch
+++ gcc-6-6.2.0/debian/rules.patch
@@ -392,6 +392,10 @@
  $(patchdir)/svn-updates.diff > src/LAST_UPDATED
 endif
 
+ifneq (,$(filter libgo-elf-relocations-sparc64, $(debian_patches)))
+   uudecode debian/go-relocation-test-gcc620-sparc64.obj.uue
+endif
+
: # only needed when we have changes, and currently fails with autogen 
5.18
: #cd $(srcdir)/fixincludes && ./genfixes
 
@@ -409,6 +413,11 @@
mv pxxx $@
 
 unpatch:
+ifneq (,$(filter libgo-elf-relocations-sparc64, $(debian_patches)))
+   # uudecoded in $(patch_stamp) rule
+   rm -f 
$(srcdir)/libgo/go/debug/elf/testdata/go-relocation-test-gcc620-sparc64.obj
+endif
+
QUILT_PATCHES=$(patchdir) \
  quilt --quiltrc /dev/null pop -a -R || test $$? = 2
rm -rf .pc
only in patch2:
unchanged:
--- gcc-6-6.2.0.orig/debian/go-relocation-test-gcc620-sparc64.obj.uue
+++ gcc-6-6.2.0/debian/go-relocation-test-gcc620-sparc64.obj.uue
@@ -0,0 +1,136 @@
+begin 644 src/libgo/go/debug/elf/testdata/go-relocation-test-gcc620-sparc64.obj
+M?T5,1@("`0`!`"L!
+M`!(``@!```!``!4`$IWCOU""$``8\G>HA\(GJ'\#D!!@`$``
+M```!`0```('/X`@!`+"!W;W)L9`-"``0`
+M"`$`#```+``"``+8
+M.`,(!P`#`0@``P('``,$!P`#`08``P(%``0$
+M!6EN=``#"`4``@`#@P```"``.$:0,(!P`%"`8(
+ME0,!!@`'E0@`V`3Q```"'@D`!/(```!B``D`
+M!/<```"/"`D`!/@```"/$`D`!/D```"/&`D`!/H```"/(`D`
+M!/L```"/*`D`!/P```"/,`D`!/T```"/.`D`!/X```"/
+M0`H`!`$`CT@*``0!`0```(]0"@`$`0(```"/6`H`
+M!`$$```"5F`*``0!!@```EQH"@`$`0@```!B<`H`!`$,
+M8G0*``0!#@```'!X"@`$`1(```!&@`H`!`$35((*
+M``0!%F*#"@`$`1@```)RB`H`!`$A>Y`*``0!*0``
+M`(V8"@`$`2H```"-H`H`!`$KC:@*``0!+(VP"@``
+M```$`2XMN`H`!`$O8L`*``0!,0```GC$``L`!)8(
+M`!@$GE8)``2=```"5@`)``2>```"7`@)``2B
+M8A``!@@```(E!@@```"A#)4```)R#0```(8```8(```"'@P```"5```"
+MB`T```"&$P`.``\`!`$[```"B`\`!`$\```"B`\`!`$]
+M```"B`8(G`<```*Q$``%J@```EP0``6K```"7!``!:P`
+M``)<$``&&@```&(,```"MP```O,1``<```+H$``&```O,2
+M``$$+`&<```#/Q,``00```!B`Y&``1,`
+M`00```,_`Y&(`0`&"(\``1$!)0X3"P,.`1('$!<```(6``,..@L[
+M"TD3```#)``+"SX+`PX```0D``L+/@L#"```!0\`"PL```8/``L+21,```7-?;F5R<@!?24]?<V%V95]E;F0`<VAO<G0@:6YT`'-I>F5?=`!S:7IE
+M='EP90!?;V9F<V5T`%])3U]W<FET95]P='(`7V9L86=S`%])3U]B=69?8F%S
+M90!?;6%R:V5R<P!?24]?<F5A9%]E;F0`<W1D97)R`%]L;V-K`F<@:6YT
+M`$=.52!#,3$@-BXR+C`@,C`Q-C`Y,30@+6UC<'4]=CD@+6<@+69S=&%C:RUP
+M<F]T96-T;W(M<W1R;VYG`%]C=7)?8V]L=6UN`%])3U\R7S%?<W1D97)R7P!?
+M24]?1DE,15]P;'5S`%]P;W,`87)G=@!?<V)U9@!?24]?1DE,10!U;G-I9VYE
+M9"!C:&%R`&%R9V,`<VEG;F5D(&-H87(`7TE/7S)?,5]S=&1I;E\`=6YS:6=N
+M960@:6YT`%])3U]M87)K97(`7W-H;W)T8G5F`%])3U]W<FET95]B87-E`%]U
+M;G5S960R`%])3U]R96%D7W!T<@

Bug#840574: Please backport libgo fixes for sparc64

2016-10-18 Thread James Clarke 
Control: tags -1 patch
(almost; explained below)

Hi Matthias,
On Tue, Oct 18, 2016 at 01:47:20PM +0200, Matthias Klose wrote:
> Control: tags -1 - patch
>
> James, based on your feedback, I tried to apply these revisions on the branch,
> had to update some of these, and got a failed build. I'm not intending to work
> on this, and would like to ask you to prepare a tested debdiff for a backport 
> or
> to get the backport upstream if you want to include the libgo port into the
> gcc-6 Debian packages.

Please find a debdiff attached; I have successfully built it on sparc64.

There is just *one* little detail which messes this up (and perhaps was
the cause of your failure?): libgo-elf-relocations-sparc64.diff
references a new binary file (for the test suite), but "svn diff"
doesn't include the actual data, nor does quilt seem to support
git-style binary diffs. Please either remove the hunks for
libgo/go/debug/elf/{file_test.go,testdata/go-relocation-test-gcc620-sparc64.obj}
or place a copy of the latter .obj in the source package and ensure it
gets copied to the same relative directory under src when
unpacking/patching.

Do let me know if I can do anything else to make this happen. I will
also see if I can get them backported upstream (though even with that
you'll still need to faff about with the .obj or drop the test...).

Thanks,
James

> On 16.10.2016 19:40, James Clarke wrote:
> > Control: tags -1 - help + patch
> >
> > Hi Matthias,
> > On Thu, Oct 13, 2016 at 01:50:43PM +0200, Matthias Klose wrote:
> >> Control: tags -1 + help
> >> Control: tags -1 - patch
> >>
> >> James, please could you name the revisions in the GCC subversion 
> >> repository?
> >> Afaics these are r241084, r241077, r241051.  Even better, could you test 
> >> and
> >> propose this backport upstream?
> >
> > To confirm, they are the following revisions:
> >
> > * r241171 (sparc64 relocations, e1fc2925 in go master, now also in
> >gofrontend/gccgo)
> > * r241084 (don't use pt_regs; unnecessary, and seemingly not defined by
> >the included headers on arm64)
> > * r241072 (make rawClone no_split_stack)
> > * r241051 (fix getrandom on sparc64 and clone on sparc*)
> > * r240457 (add getrandom for MIPS/SPARC)
> >
> > We've been using the latest gcc-6 package with these patches (other than
> > no_split_stack and pt_regs fixups) applied on top for sparc64 (uploaded
> > to unreleased) for the past few days, and the only packages which fail
> > to build seem to be because Debian currently has an out-of-date x/sys
> > package without sparc64 definitions. I haven't been aware of any
> > regressions.
> >
> > Ian: I imagine the getrandom and elf changes would be fine for gcc-6,
> > but what about the clone changes? I can understand if that's too
> > invasive, but backporting would be great.
> >
> > Regards,
> > James
> >
> >> On 12.10.2016 23:35, James Clarke wrote:
> >>> Source: gcc-6
> >>> Version: 6.2.0-6
> >>> User: debian-sp...@lists.debian.org
> >>> Usertags: sparc64
> >>> X-Debbugs-Cc: debian-sp...@lists.debian.org
> >>> Tags: patch fixed-upstream
> >>>
> >>> Hi,
> >>> Could you please backport the patches listed below so that we can have a
> >>> working gccgo? They fix the (minor) issue of using the wrong syscall
> >>> number for getrandom (if code uses it), add support for sparc64's
> >>> relocations, and also the following error when running go build:
> >>>
> >>> /usr/bin/sparc64-linux-gnu-gccgo-6: wait: no child processes
> >>> /usr/bin/sparc64-linux-gnu-gccgo-6: exit status 1
> >>>
> >>> The patches are:
> >>>
> >>> https://go.googlesource.com/go/+/e1fc292500aa70c265937aebad00ac010031cbaf
> >>> (not yet pulled into gofrontend's libgo)
> >>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a357a86a9f2772561454ce17ef13a89a51fc4a27
> >>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0509fa0eae193f8d99886e9b6a1feda4c6c16356
> >>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3457370357929d70f26873e914fae6ea6f1a8ffd
> >>>
> >>> With all but the last patch (a minor fixup after my patches), I have
> >>> been able to successfully build and run go programs on sparc64.
> >>>
> >>> Regards,
> >>> James
> >>>
> >>
>
diff -u gcc-6-6.2.0/debian/changelog gcc-6-6.2.0/debian/changelog
--- gcc-6-6.2.0/debian/changelog
+++ gcc-6-6.2.0/debian/changelog
@@ -1,3 +1,16

Bug#840574: Please backport libgo fixes for sparc64

2016-10-16 Thread James Clarke 
Control: tags -1 - help + patch

Hi Matthias,
On Thu, Oct 13, 2016 at 01:50:43PM +0200, Matthias Klose wrote:
> Control: tags -1 + help
> Control: tags -1 - patch
>
> James, please could you name the revisions in the GCC subversion repository?
> Afaics these are r241084, r241077, r241051.  Even better, could you test and
> propose this backport upstream?

To confirm, they are the following revisions:

* r241171 (sparc64 relocations, e1fc2925 in go master, now also in
   gofrontend/gccgo)
* r241084 (don't use pt_regs; unnecessary, and seemingly not defined by
   the included headers on arm64)
* r241072 (make rawClone no_split_stack)
* r241051 (fix getrandom on sparc64 and clone on sparc*)
* r240457 (add getrandom for MIPS/SPARC)

We've been using the latest gcc-6 package with these patches (other than
no_split_stack and pt_regs fixups) applied on top for sparc64 (uploaded
to unreleased) for the past few days, and the only packages which fail
to build seem to be because Debian currently has an out-of-date x/sys
package without sparc64 definitions. I haven't been aware of any
regressions.

Ian: I imagine the getrandom and elf changes would be fine for gcc-6,
but what about the clone changes? I can understand if that's too
invasive, but backporting would be great.

Regards,
James

> On 12.10.2016 23:35, James Clarke wrote:
> > Source: gcc-6
> > Version: 6.2.0-6
> > User: debian-sp...@lists.debian.org
> > Usertags: sparc64
> > X-Debbugs-Cc: debian-sp...@lists.debian.org
> > Tags: patch fixed-upstream
> >
> > Hi,
> > Could you please backport the patches listed below so that we can have a
> > working gccgo? They fix the (minor) issue of using the wrong syscall
> > number for getrandom (if code uses it), add support for sparc64's
> > relocations, and also the following error when running go build:
> >
> > /usr/bin/sparc64-linux-gnu-gccgo-6: wait: no child processes
> > /usr/bin/sparc64-linux-gnu-gccgo-6: exit status 1
> >
> > The patches are:
> >
> > https://go.googlesource.com/go/+/e1fc292500aa70c265937aebad00ac010031cbaf
> > (not yet pulled into gofrontend's libgo)
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a357a86a9f2772561454ce17ef13a89a51fc4a27
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0509fa0eae193f8d99886e9b6a1feda4c6c16356
> > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3457370357929d70f26873e914fae6ea6f1a8ffd
> >
> > With all but the last patch (a minor fixup after my patches), I have
> > been able to successfully build and run go programs on sparc64.
> >
> > Regards,
> > James
> >
>


signature.asc
Description: PGP signature

Bug#840574: Please backport libgo fixes for sparc64

2016-10-12 Thread James Clarke 
Source: gcc-6
Version: 6.2.0-6
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org
Tags: patch fixed-upstream

Hi,
Could you please backport the patches listed below so that we can have a
working gccgo? They fix the (minor) issue of using the wrong syscall
number for getrandom (if code uses it), add support for sparc64's
relocations, and also the following error when running go build:

/usr/bin/sparc64-linux-gnu-gccgo-6: wait: no child processes
/usr/bin/sparc64-linux-gnu-gccgo-6: exit status 1

The patches are:

https://go.googlesource.com/go/+/e1fc292500aa70c265937aebad00ac010031cbaf
(not yet pulled into gofrontend's libgo)
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a357a86a9f2772561454ce17ef13a89a51fc4a27
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0509fa0eae193f8d99886e9b6a1feda4c6c16356
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3457370357929d70f26873e914fae6ea6f1a8ffd

With all but the last patch (a minor fixup after my patches), I have
been able to successfully build and run go programs on sparc64.

Regards,
James


signature.asc
Description: PGP signature

Bug#823937: gcc -E has __DATE__/__TIME__ as Jan 1 1970 00:00:00

2016-05-10 Thread James Clarke 
Package: gcc-5
Version: 5.3.1-17
Severity: normal
Tags: upstream patch
Control: clone -1 -2
Control: reassign -2 gcc-6 6.1.1-1

Hi,
With the SOURCE_DATE_EPOCH patch from upstream, the __DATE__ and
__TIME__ macros always give Jan 1 1970 00:00:00 when running the
preprocessor on its own with gcc -E[1]. I believe this is because
c_lex_with_flags is not called when just preprocessing (no C code needs
to be lexed), so pfile->source_date_epoch stays initialised to 0, and
subsequent __DATE__/__TIME__ expansions believe that the timestamp has
been set to epoch 0. I have attached an alternative implementation of
gcc-SOURCE_DATE_EPOCH.diff which fixes this, by initialising
pfile->source_date_epoch inside libcpp when pfile is initially created.

[1] https://paste.debian.net/683081/

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-5 depends on:
ii  binutils  2.26-8
ii  cpp-5 5.3.1-17
ii  gcc-5-base5.3.1-17
ii  libc6 2.22-7
ii  libcc1-0  6.1.1-1
ii  libgcc-5-dev  5.3.1-17
ii  libgcc1   1:6.1.1-1
ii  libgmp10  2:6.1.0+dfsg-2
ii  libisl15  0.16.1-1
ii  libmpc3   1.0.3-1
ii  libmpfr4  3.1.4-1
ii  libstdc++66.1.1-1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages gcc-5 recommends:
ii  libc6-dev  2.22-7

Versions of packages gcc-5 suggests:
pn  gcc-5-doc 
pn  gcc-5-locales 
pn  gcc-5-multilib
pn  libasan2-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx0-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information
--- a/src/libcpp/init.c
+++ b/src/libcpp/init.c
@@ -36,6 +36,7 @@
 
 static void init_library (void);
 static void mark_named_operators (cpp_reader *, int);
+static void cpp_init_source_date_epoch (cpp_reader *);
 static void read_original_filename (cpp_reader *);
 static void read_original_directory (cpp_reader *);
 static void post_options (cpp_reader *);
@@ -264,6 +265,9 @@
 
   _cpp_init_hashtable (pfile, table);
 
+  /* Initialize the source_date_epoch value.  */
+  cpp_init_source_date_epoch (pfile);
+
   return pfile;
 }
 
@@ -530,6 +534,46 @@
 _cpp_define_builtin (pfile, "__OBJC__ 1");
 }
 
+/* Read SOURCE_DATE_EPOCH from environment to have a deterministic
+   timestamp to replace embedded current dates to get reproducible
+   results.  Returns -1 if SOURCE_DATE_EPOCH is not defined.  */
+static time_t
+get_source_date_epoch (cpp_reader *pfile)
+{
+  char *source_date_epoch;
+  long long epoch;
+  char *endptr;
+
+  source_date_epoch = getenv ("SOURCE_DATE_EPOCH");
+  if (!source_date_epoch)
+return (time_t) -1;
+
+  errno = 0;
+  epoch = strtoll (source_date_epoch, , 10);
+  if ((errno == ERANGE && (epoch == LLONG_MAX || epoch == LLONG_MIN))
+  || (errno != 0 && epoch == 0))
+cpp_error (pfile, CPP_DL_FATAL, "environment variable $SOURCE_DATE_EPOCH: "
+		 "strtoll: %s\n", xstrerror(errno));
+  if (endptr == source_date_epoch)
+cpp_error (pfile, CPP_DL_FATAL, "environment variable $SOURCE_DATE_EPOCH: "
+		 "no digits were found: %s\n", endptr);
+  if (*endptr != '\0')
+cpp_error (pfile, CPP_DL_FATAL, "environment variable $SOURCE_DATE_EPOCH: "
+		 "trailing garbage: %s\n", endptr);
+  if (epoch < 0)
+cpp_error (pfile, CPP_DL_FATAL, "environment variable $SOURCE_DATE_EPOCH: "
+		 "value must be nonnegative: %lld \n", epoch);
+
+  return (time_t) epoch;
+}
+
+/* Initialize the source_date_epoch value.  */
+static void
+cpp_init_source_date_epoch (cpp_reader *pfile)
+{
+  pfile->source_date_epoch = get_source_date_epoch (pfile);
+}
+
 /* Sanity-checks are dependent on command-line options, so it is
called as a subroutine of cpp_read_main_file ().  */
 #if ENABLE_CHECKING
--- a/src/libcpp/internal.h
+++ b/src/libcpp/internal.h
@@ -502,6 +502,10 @@
   const unsigned char *date;
   const unsigned char *time;
 
+  /* Externally set timestamp to replace current date and time useful for
+ reproducibility.  */
+  time_t source_date_epoch;
+
   /* EOF token, and a token forcing paste avoidance.  */
   cpp_token avoid_paste;
   cpp_token eof;
--- a/src/libcpp/macro.c
+++ b/src/libcpp/macro.c
@@ -350,13 +350,20 @@
 	  time_t tt;
 	  struct tm *tb = NULL;
 
-	  /* (time_t) -1 is a legitimate value for "number of seconds
-	 since the Epoch", so we have to do a little dance to
-	 distinguish that from a genuine error.  */
-	  errno = 0;
-	  tt = time(NULL);
-	  if (tt != (time_t)-1 || errno == 0)
-	tb = localtime ();
+	  /* Set a reproducible timestamp for __DATE__ and