Bug#1072071: gcc-13: Please add libatomic for 32-bit SPARC for Ada

[John Paul Adrian Glaubitz]

Source: gcc-13
Version: 13.2.0-25
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hello,

I just tried to build a cross-compiler for 32-bit SPARC (Debian arch sparc)
with Ada enabled. The build failed with a linker failure which indicates
that linking against libatomic is required:

checking float.h presence... yes
checking for float.h... yes
checking fp.h usability... /usr/sparc-linux-gnu/bin/ld: libgnat-13.so: 
undefined reference to `__atomic_compare_exchange_8'
collect2: error: ld returned 1 exit status

Such a patch already exists for armel [1], so it should be easy to extend
it for 32-bit SPARC. 64-bit SPARC (Debian arch sparc64) is not affected,
linking against libatomic is therefore not required.

Thanks,
Adrian

> [1] 
> https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-13-debian/debian/patches/ada-armel-libatomic.diff

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1054272: gcc-13: Regression in SH backend results in binutils FTBFS

[John Paul Adrian Glaubitz]

Source: gcc-13
Version: 13.2.0-5
Severity: normal
Tags: upstream
User: debian-sup...@lists.debian.org
Usertags: sh4
X-Debbugs-Cc: debian-sup...@lists.debian.org

Hello!

There is currently a known regression in gcc-13 which causes binutils and
e2fsprogs to FTBFS on sh4 [1][2]:

libtool: compile:  sh4-linux-gnu-gcc (...) .deps/elf64-aarch64.Tpo -c 
elf64-aarch64.c -fPIC -DPIC -o .libs/elf64-aarch64.o
elfnn-aarch64.c: In function ‘elf64_aarch64_merge_gnu_properties’:
elfnn-aarch64.c:10408: warning: 
‘/<>/builddir-multi/bfd/.libs/elf64-aarch64.gcda’ profile count 
data file not found [-Wmissing-profile]
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Unhandled trap: 0x180
pc=0x3f9a38e0 sr=0x0001 pr=0x3f9a38d2 fpscr=0x00080004
spc=0x ssr=0x gbr=0x3f975aa0 vbr=0x
sgr=0x dbr=0x delayed_pc=0x3f9a38d2 fpul=0x0064
r0=0x0004 r1=0x3fb01170 r2=0x0005 r3=0x
r4=0x002e5a00 r5=0x002e5a00 r6=0x0006 r7=0x011c
r8=0x3fb01164 r9=0x0518 r10=0x3f9755e0 r11=0x09bc
r12=0x3fb00c58 r13=0x01766344 r14=0x01bed424 r15=0x407fb580
r16=0x r17=0x r18=0x r19=0x
r20=0x r21=0x r22=0x r23=0x

Testing on real hardware reveals the actual bug:

root@tirpitz:..lib/ext2fs> gcc-13 -I. -I../../lib -I../../../../lib -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 -ffile-prefix-map=$(pwd)=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -pthread  -DHAVE_CONFIG_H  -c 
../../../../lib/ext2fs/rw_bitmaps.c -o rw_bitmaps.o
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
during RTL pass: sh_treg_combine2
../../../../lib/ext2fs/rw_bitmaps.c: In function ‘read_bitmaps_range_start’:
../../../../lib/ext2fs/rw_bitmaps.c:447:1: internal compiler error: Illegal 
instruction
  447 | }
  | ^
0x29a738e0 __GI_abort
./stdlib/abort.c:107
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
root@tirpitz:..lib/ext2fs>

which has been been reported upstream [3]. The issue does not reproduce on 
gcc-12.

This bug report has been created to raise awareness within Debian.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=binutils=sh4=2.41-6=1697044502=0
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=e2fsprogs=sh4=1.47.0-2%2Bb1=1697478803=0
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111892

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1050893: gcc-13: Please disable Ada, D, Go and M2 as well as GDB support on loong64

[John Paul Adrian Glaubitz]

Source: gcc-13
Version: 13.2.0-2
Severity: normal
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loong64
X-Debbugs-Cc: debian-de...@lists.debian.org

Hello!

In order to ease the bootstrap of the new loong64 port, please reduce
the build dependencies and number of enabled languages.

- Please disable Ada, D, Go and M2 for loong64 in debian/rules.def.
- Please add "!loong64" for gdb in debian/control.m4

The attached patch implements these changes.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/gcc-13-13.2.0/debian/control.m4 
new/gcc-13-13.2.0/debian/control.m4
--- old/gcc-13-13.2.0/debian/control.m4 2023-07-11 17:40:07.0 +0200
+++ new/gcc-13-13.2.0/debian/control.m4 2023-08-30 20:17:54.515043971 +0200
@@ -81,7 +81,7 @@
   libzstd-dev, zlib1g-dev, SDT_BUILD_DEP USAGE_BUILD_DEP
   BINUTILS_BUILD_DEP,
   gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext,
-  gdb`'NT [!riscv64 !mipsel !mips64el], OFFLOAD_BUILD_DEP
+  gdb`'NT [!loong64 !riscv64 !mipsel !mips64el], OFFLOAD_BUILD_DEP
   texinfo (>= 4.3), LOCALES, sharutils,
   procps, FORTRAN_BUILD_DEP GNAT_BUILD_DEP GO_BUILD_DEP GDC_BUILD_DEP 
GM2_BUILD_DEP
   ISL_BUILD_DEP MPC_BUILD_DEP MPFR_BUILD_DEP GMP_BUILD_DEP PHOBOS_BUILD_DEP
diff -Nru old/gcc-13-13.2.0/debian/rules.defs 
new/gcc-13-13.2.0/debian/rules.defs
--- old/gcc-13-13.2.0/debian/rules.defs 2023-08-04 04:48:33.0 +0200
+++ new/gcc-13-13.2.0/debian/rules.defs 2023-08-30 20:11:21.780573351 +0200
@@ -850,6 +850,7 @@
 ada_no_cpus:= m32r sh3 sh3eb sh4eb
 ada_no_cpus+= arc
 ada_no_cpus+= ia64
+ada_no_cpus+= loong64
 ada_no_systems := 
 ada_no_cross   := no
 ada_no_snap:= no
@@ -1006,7 +1007,7 @@
   with_libcc1 :=
 endif
 
-go_no_cpus := arc avr hppa
+go_no_cpus := arc avr hppa loong64
 go_no_cpus += m68k # See PR 79281 / PR 83314
 go_no_systems := kfreebsd
 ifneq (,$(filter $(distrelease),precise))
@@ -1064,7 +1065,7 @@
 # D ---
 d_no_cross := yes
 d_no_snap :=
-d_no_cpus := alpha arc ia64 m68k sh4 s390 sparc64
+d_no_cpus := alpha arc loong64 ia64 m68k sh4 s390 sparc64
 d_no_systems := gnu kfreebsd-gnu
 
 ifneq ($(single_package),yes)
@@ -1261,7 +1262,7 @@
 with_m2 := yes
   endif
 endif
-m2_no_archs = powerpc ppc64 sh4 kfreebsd-amd64 kfreebsd-i386 hurd-amd64 
hurd-i386
+m2_no_archs = loong64 powerpc ppc64 sh4 kfreebsd-amd64 kfreebsd-i386 
hurd-amd64 hurd-i386
 ifneq (,$(filter $(DEB_TARGET_ARCH),$(m2_no_archs)))
 with_m2 := disabled for cpu $(DEB_TARGET_ARCH)
 endif

Bug#1036158: gcc-13: Please raise baseline for alpha to EV56

[John Paul Adrian Glaubitz]

Hi Michael!

On Tue, 2023-05-16 at 20:25 +1200, Michael Cree wrote:
> On Tue, May 16, 2023 at 09:38:56AM +0200, John Paul Adrian Glaubitz wrote:
> > After a long discussion on IRC and the mailing list, we have agreed to 
> > raise the
> > baseline for the alpha architecture to EV56 to improve the generated code 
> > and fix
> > a number of issues. The change is already being implemented in the glibc 
> > packages
> > which switches to EV56 [1] since hwcaps are no longer available with glibc 
> > 2.37 [2].
> > 
> > Could you raise the baseline for gcc on alpha to EV56?
> > 
> > I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".
> 
> Yes, please!
> 
> I suggest the following in debian/rules2:
> 
> ifneq (,$(findstring alpha,$(DEB_TARGET_ARCH)))
>   CONFARGS += --with-cpu=ev56 --with-tune=ev6
> endif
> 
> (the --with-tune only affects instruction scheduling and better tunes
> code for ev6 and more recent machines, but allows execution down to
> ev56.)  I have tested this in the past with a rebuild of most packages
> that are in the base essential chroot in the past and it works well.

Doesn't that come with a speed penalty for EV56 machines? I'm asking because 
EV56 is
currently the baseline for QEMU when emulating Alpha.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1036158: gcc-13: Please raise baseline for alpha to EV56

[John Paul Adrian Glaubitz]

Source: gcc-13
Version: 13.1.0-2
Severity: normal
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-al...@lists.debian.org

Hello!

After a long discussion on IRC and the mailing list, we have agreed to raise the
baseline for the alpha architecture to EV56 to improve the generated code and 
fix
a number of issues. The change is already being implemented in the glibc 
packages
which switches to EV56 [1] since hwcaps are no longer available with glibc 2.37 
[2].

Could you raise the baseline for gcc on alpha to EV56?

I assume, it should be "--with-cpu=ev56" or "--with-arch=ev56".

Thanks,
Adrian

> [1] 
> https://salsa.debian.org/glibc-team/glibc/-/commit/7af7b56d5f5fef7a4f3c011b36774e4556563d3d
> [2] 
> https://salsa.debian.org/glibc-team/glibc/-/commit/4d57b6af3efd1d6af277b2eb67fe9ee500e7ae68

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1028195: gcc-12: Please drop build dependency on gdc-12 on unsupported D targets

[John Paul Adrian Glaubitz]

Source: gcc-12
Version: 12.2.0-14
Severity: normal

Hello!

Similar to #1026201, gcc-12 is now BD-Uninstallable on a number of targets
since there is no gdc-12 compiler available for the bootstrap.

Thus, please disable D support for the affected architectures so that gcc-12
can build there again.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026201

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1027099: gccrs-13: Broken symlink /usr/bin/gccrs-13

[John Paul Adrian Glaubitz]

Source: gcc-13
Version: 13-20221226-1
Severity: normal
User: debian-i...@lists.debian.org
Usertags: ia64
X-Debbugs-Cc: debian-i...@lists.debian.org

Hello!

I just gave it a first try with the gccrs package on ia64 and it turns
out the gccrs-13 symlink in /usr/bin is broken as shown below. Manually
invoking ia64-linux-gnu-gccrs-13 works without any problems and I can
actually compile a working program.

glaubitz@electron:~$ dpkg -l gccrs-13
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
ii  gccrs-13   13-20221226-1 ia64 GNU Rust compiler
glaubitz@electron:~$ gccrs-13
-bash: gccrs-13: command not found
glaubitz@electron:~$ ls -l /usr/bin/gccrs-13
lrwxrwxrwx 1 root root 21 Dec 26 16:33 /usr/bin/gccrs-13 -> 
ia64-linux-gnu-grs-13
glaubitz@electron:~$ /usr/bin/ia64-linux-gnu-gccrs-13
ia64-linux-gnu-gccrs-13: fatal error: no input files
compilation terminated.
glaubitz@electron:~$

Proof that gccrs works on ia64:

glaubitz@electron:~$ cat rust42.rs
fn main() -> i32 {
return 42;
}
glaubitz@electron:~$ ia64-linux-gnu-gccrs-13 
-frust-incomplete-and-experimental-compiler-do-not-use rust42.rs -o rust42
glaubitz@electron:~$ ./rust42 
glaubitz@electron:~$ echo $?
42
glaubitz@electron:~$

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1026201: gcc-13: Please drop build dependency on gdc-12 on unsupported D targets

[John Paul Adrian Glaubitz]

Source: gcc-13
Version: 13-20221214-1
Severity: normal

Hello!

Both gcc-snapshot and gcc-13 have a build-dependency on gdc-12 which we
haven't enabled on most ports architectures.

Could this build dependency be dropped for the architectures that are
BD-Uninstallable for gcc-13 [1] and gcc-snapshot [2]? We don't really
need D language support in Debian Ports as the language has no standard
library support for most architectures.

Thanks,
Adrian

> [1] https://buildd.debian.org/status/package.php?p=gcc-13=experimental
> [2] https://buildd.debian.org/status/package.php?p=gcc-snapshot=sid

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1009026: gcc-12: Please re-enable JIT on m68k

[John Paul Adrian Glaubitz]

Source: gcc-12
Version: 12-20220319-1
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hello!

I have just successfully built gcc-12 with the JIT enabled, so it
seems that the underlying bug has been fixed upstream.

Can you please re-enable JIT for m68k for the next gcc-12 upload?

Thanks,
Adrian

--
  .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1006363: gcc-12: Patch alpha-ieee.diff no longer applies due to changed filename

[John Paul Adrian Glaubitz]

Source: gcc-12
Version: 12-20220222-1
Severity: normal
User: debian-al...@lists.debian.org
Usertags: alpha
X-Debbugs-Cc: debian-al...@lists.debian.org

Hello!

The patch alpha-ieee.diff no longer applies as the filename for 
gcc/config/alpha/alpha.c
changed to gcc/config/alpha/alpha.cc:

Applying patch alpha-ieee.diff
can't find file to patch at input line 11
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|# DP: #212912
|# DP: on alpha-linux, make -mieee default and add -mieee-disable switch
|# DP: to turn default off
|
|---
| gcc/config/alpha/alpha.c |4 
| 1 files changed, 4 insertions(+), 0 deletions(-)
|
|--- a/src/gcc/config/alpha/alpha.c
|+++ b/src/gcc/config/alpha/alpha.c
--
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
Patch alpha-ieee.diff does not apply (enforce with -f)

Changing "alpha.c" to "alpha.cc" in the patch fixes the problem.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1004659: gcc-11: Please include patch to default 32-bit mode to V8+ on sparc64

[John Paul Adrian Glaubitz]

Source: gcc-11
Version: 11.2.0-14
Severity: normal
Tags: patch
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi!

GCC upstream is defaulting to the V8+ baseline now for 32-bit mode on sparc64 
[1].

As this change is not going to be backported according to the responsible 
author [2],
I would like to ask this change to be backported in the gcc-11 package in 
Debian.

I'm attaching both the patch itself as well as a Debian patch which includes 
both
the patch and updates debian/rules.patch.

Could you include it for the next upload?

Thanks,
Adrian

> [1] 
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=23987912ddb4207de0714d81237f93f613557d1f
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104189

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/gcc-11-11.2.0/debian/patches/sparc64-v8plus-default.diff 
new/gcc-11-11.2.0/debian/patches/sparc64-v8plus-default.diff
--- old/gcc-11-11.2.0/debian/patches/sparc64-v8plus-default.diff
1970-01-01 01:00:00.0 +0100
+++ new/gcc-11-11.2.0/debian/patches/sparc64-v8plus-default.diff
2022-01-31 10:54:27.448637243 +0100
@@ -0,0 +1,28 @@
+From 23987912ddb4207de0714d81237f93f613557d1f Mon Sep 17 00:00:00 2001
+From: Eric Botcazou 
+Date: Mon, 31 Jan 2022 09:21:48 +0100
+Subject: [PATCH] Use V8+ default in 32-bit mode on SPARC64/Linux
+
+This is what has been done for ages on SPARC/Solaris and makes it possible
+to use 64-bit atomic instructions even in 32-bit mode.
+
+gcc/
+   PR target/104189
+   * config/sparc/linux64.h (TARGET_DEFAULT): Add MASK_V8PLUS.
+
+--- a/src/gcc/config/sparc/linux64.h
 b/src/gcc/config/sparc/linux64.h
+@@ -35,8 +35,8 @@ along with GCC; see the file COPYING3.  If not see
+ #if defined(TARGET_64BIT_DEFAULT) && TARGET_CPU_DEFAULT >= TARGET_CPU_v9
+ #undef TARGET_DEFAULT
+ #define TARGET_DEFAULT \
+-  (MASK_V9 + MASK_PTR64 + MASK_64BIT + MASK_STACK_BIAS + \
+-   MASK_APP_REGS + MASK_FPU + MASK_LONG_DOUBLE_128)
++  (MASK_V9 + MASK_64BIT + MASK_PTR64 + MASK_STACK_BIAS + \
++   MASK_V8PLUS + MASK_APP_REGS + MASK_FPU + MASK_LONG_DOUBLE_128)
+ #endif
+ 
+ /* This must be v9a not just v9 because by default we enable
+-- 
+2.31.1
+
diff -Nru old/gcc-11-11.2.0/debian/rules.patch 
new/gcc-11-11.2.0/debian/rules.patch
--- old/gcc-11-11.2.0/debian/rules.patch2022-01-17 13:42:16.0 
+0100
+++ new/gcc-11-11.2.0/debian/rules.patch2022-01-31 10:54:47.009328741 
+0100
@@ -50,6 +50,7 @@
gcc-auto-build \
libitm-no-fortify-source \
sparc64-biarch-long-double-128 \
+   sparc64-v8plus-default \
pr66368 \
pr67590 \
libffi-pax \
>From 23987912ddb4207de0714d81237f93f613557d1f Mon Sep 17 00:00:00 2001
From: Eric Botcazou 
Date: Mon, 31 Jan 2022 09:21:48 +0100
Subject: [PATCH] Use V8+ default in 32-bit mode on SPARC64/Linux

This is what has been done for ages on SPARC/Solaris and makes it possible
to use 64-bit atomic instructions even in 32-bit mode.

gcc/
PR target/104189
* config/sparc/linux64.h (TARGET_DEFAULT): Add MASK_V8PLUS.

--- a/src/gcc/config/sparc/linux64.h
+++ b/src/gcc/config/sparc/linux64.h
@@ -35,8 +35,8 @@ along with GCC; see the file COPYING3.  If not see
 #if defined(TARGET_64BIT_DEFAULT) && TARGET_CPU_DEFAULT >= TARGET_CPU_v9
 #undef TARGET_DEFAULT
 #define TARGET_DEFAULT \
-  (MASK_V9 + MASK_PTR64 + MASK_64BIT + MASK_STACK_BIAS + \
-   MASK_APP_REGS + MASK_FPU + MASK_LONG_DOUBLE_128)
+  (MASK_V9 + MASK_64BIT + MASK_PTR64 + MASK_STACK_BIAS + \
+   MASK_V8PLUS + MASK_APP_REGS + MASK_FPU + MASK_LONG_DOUBLE_128)
 #endif
 
 /* This must be v9a not just v9 because by default we enable
-- 
2.31.1

Bug#1003350: hsail-tools: Bogus endianness error message in debian/rules

[John Paul Adrian Glaubitz]

Source: hsail-tools
Severity: normal

Hi!

The logic in debian/rules for the endianness check seems inverted:

override_dh_auto_configure:
ifeq ($(DEB_HOST_ARCH_ENDIAN),big)
@echo "package can be built for big-endian only"
false
endif
dh_auto_configure

As a result, on s390x the package FTBFS with:

 package can be built for big-endian only
 false

which makes no sense.

Might be a better idea to whitelist all little-endian architectures
in debian/control instead since this will also avoid the package
from being picked up by the buildds.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=hsail-tools=s390x=0%7E20180830-1=1578612130=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995223: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#995223: fixed in libffi 3.4.2-3)

[John Paul Adrian Glaubitz]

Hi Matthias!

On 10/11/21 15:27, John Paul Adrian Glaubitz wrote:
> This did not fix the bug, unfortunately. libffi is still being built with
> "-mcpu=power8" on ppc64, see the full build log in [1].
> 
> We didn't need --enable-portable before, so this isn't the issue but I assume
> the problem is the new autoconf version which is not compatible with libffi 
> [2].

Julien has suggested on #debian-devel to build with --without-gcc-arch instead 
of
--enable-portable-binary and it indeed fixes the problem for me:

--- debian/rules.orig   2021-09-15 09:03:02.0 -0700
+++ debian/rules2021-10-28 05:10:01.357633494 -0700
@@ -53,6 +53,7 @@
--infodir=\$${prefix}/share/info \
--enable-pax_emutramp \
--disable-exec-static-tramp \
+   --without-gcc-arch \
CC="$(CC)" \
CXX="$(CXX)" \
CPPFLAGS="$(CPPFLAGS)" \

Could you update the debian/rules accordingly?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995223: closed by Debian FTP Masters (reply to Matthias Klose ) (Bug#995223: fixed in libffi 3.4.2-3)

[John Paul Adrian Glaubitz]

Control: reopen -1

Hello!

This did not fix the bug, unfortunately. libffi is still being built with
"-mcpu=power8" on ppc64, see the full build log in [1].

We didn't need --enable-portable before, so this isn't the issue but I assume
the problem is the new autoconf version which is not compatible with libffi [2].

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libffi=ppc64=3.4.2-3=1633957534=0
> [2] https://github.com/libffi/libffi/issues/662

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995916: std::stoi, std::stol, std::stoul, ... broken on sh4

[John Paul Adrian Glaubitz]

Hi Mattias!

On 10/8/21 11:21, John Paul Adrian Glaubitz wrote:
> I will try to build cmake with gcc-11 and see if that makes any difference.

Building with gcc-11 fixes the problem and cmake builds fine.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995916: std::stoi, std::stol, std::stoul, ... broken on sh4

[John Paul Adrian Glaubitz]

Hi Mattias!

On 10/8/21 09:54, Mattias Ellert wrote:
> The std::stoi, std::stol, std::stoul, ... functions should be available
> in two versions. One accepting a std::string and one accepting a
> std::wstring.
> 
> In g++ version 10.3.0-11 on sh4 only the std::wstring version is
> available, so when it tries to compile code that uses the std::string
> version it fails.
> 
> The problem is that for some reason the the file
> 
> /usr/include/sh4-linux-gnu/c++/10/bits/c++config.h
> 
> provided by libstdc++-10-dev_10.3.0-11_sh4.deb contains the line
> 
> /* #undef _GLIBCXX11_USE_C99_STDLIB */
> 
> The corresponding file for other architectures contains
> 
> #define _GLIBCXX11_USE_C99_STDLIB 1
> 
> This is a regression wrt earlier versions, since this used to work
> without problems.

Thanks so much for tracking this down. I have seen this issue before and
didn't understand what the problem was. At least I do now.

I will try to build cmake with gcc-11 and see if that makes any difference.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8

[John Paul Adrian Glaubitz]

Hello!

On 9/29/21 00:38, John Paul Adrian Glaubitz wrote:
> There is actually a baseline violation on i386 as "-march=amdfam10" is
> passed to the compiler, see the build log in [1], for example.

Comparing the build logs, it seems that this an issue with the newer version
of autoconf that was used to build version 3.4.2-2. Looking at the log for
3.4.2-2, a lot of autoconf warnings can be seen which are not present in the
log for 3.4.1-1.

> https://buildd.debian.org/status/fetch.php?pkg=libffi=powerpc=3.4.2-1=1626443428=0
> https://buildd.debian.org/status/fetch.php?pkg=libffi=powerpc=3.4.2-2=1632868252=0

So, upstream needs to fix compatibility issues with the newer autoconf version.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8

[John Paul Adrian Glaubitz]

Hi!

On 9/28/21 22:40, John Paul Adrian Glaubitz wrote:
> We should therefore pass "--enable-portable-binary" in debian/rules.

There is actually a baseline violation on i386 as "-march=amdfam10" is
passed to the compiler, see the build log in [1], for example.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libffi=i386=3.4.2-2=1632469242=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8

[John Paul Adrian Glaubitz]

Control: severity -1 serious

Hello!

It turns out that m4/ax_gcc_archflag.m4 contains code to detect the
baseline of the host system and sets the GCC architecture accordingly.

Thus, a libffi compiled on a POWER8 machine will not work on a POWER5
machine as the compiler is emitting POWER8 instructions in this case.

Since the m4 script contains such a host enviroment detection for aarch64
as well [1], this bug can potentially affect arm64 which is a release
architecture.

We should therefore pass "--enable-portable-binary" in debian/rules.

Adrian

> [1] https://github.com/libffi/libffi/blob/master/m4/ax_gcc_archflag.m4#L209

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#995223: libffi: SIGILL on powerpc and ppc64 systems since libffi8

[John Paul Adrian Glaubitz]

Source: libffi
Version: 3.3-6
Severity: important
User: debian-powe...@lists.debian.org
Usertags: powerpc ppc64
X-Debbugs-Cc: debian-powe...@lists.debian.org

Hi!

Multiple users on powerpc and ppc64 have reported SIGILL crashes
after upgrading to libffi8 (3.4.x):

# dmesg
...
[   16.257543] fail2ban-server[384]: illegal instruction (4) at
3fffb4283970 nip 3fffb4283970 lr 3fffb4282f90 code 1 in
libffi.so.8.1.0[3fffb427b000+c000]
...

Downgrading to libffi7 fixes the problem.

It has been reported that building and using the upstream version
does not reproduce this issue. But I have not yet independently
verified that. It might be that libffi performs a runtime detection
during build which causes the library to be built with a higher
baseline on the POWER8 buildds.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#978761: gcc-11: Please temporarily disable Ada on m68k

[John Paul Adrian Glaubitz]

Source: gcc-11
Version: 10.2.1-3
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hi!

The Ada bootstrap is currently broken on m68k which causes gcc-11 to FTBFS:

> +===GNAT BUG DETECTED==+
> | 11.0.0 20201228 (experimental) [master revision 
> 12ae2bc7084:08ca52bdc1f:97d3ddcfc9c67d26e3869a261a506ef70e7f092e] 
> (m68k-linux-gnu) |
> | Storage_Error stack overflow or erroneous memory access  |
> | No source file position information available|
> | Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
> | Use a subject line meaningful to you and us to track the bug.|
> | Include the entire contents of this bug box in the report.   |
> | Include the exact command that you entered.  |
> | Also include sources listed below.   |
> +==+
> 
> Please include these source files with error report
> Note that list may not be accurate in some cases,
> so please double check that the problem can still
> be reproduced with the set of files listed.
> Consider also -gnatd.n switch (see debug.adb).

I have reported the issue upstream [1] and also bisected the commit that 
introduced
the problem.

Could you disable Ada in gcc-11 on m68k until the issue has been fixed upstream?

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#977598: gcc-11: Please disable the Go compiler on ia64

[John Paul Adrian Glaubitz]

Source: gcc-11
Version: 10.2.1-1
Severity: normal
User: debian-i...@lists.debian.org
Usertags: ia64
X-Debbugs-Cc: debian-i...@lists.debian.org

Hello!

With gcc-11, the Go compiler is now used during the bootstrap process
which causes the build of gcc-11 and gcc-snapshot to fail on ia64 as
Go doesn't properly work there at the moment [1]:

go1: internal compiler error: Segmentation fault
0x4123848f crash_signal
../../src/gcc/toplev.c:327
0x42d57a9f std::__cxx11::basic_string, 
std::allocator >::substr(unsigned long, unsigned long) const

/<>/build/ia64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:907
0x40345cbf Gogo::special_name_pos(std::__cxx11::basic_string, std::allocator > const&)
../../src/gcc/go/gofrontend/names.cc:1136
0x4020ebff should_export
../../src/gcc/go/gofrontend/export.cc:464
0x40213d5f Export::export_globals(std::__cxx11::basic_string, std::allocator > const&, 
std::__cxx11::basic_string, std::allocator > 
const&, std::__cxx11::basic_string, 
std::allocator > const&, std::map, std::allocator >, Package*, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, Package*> > > const&, 
std::map, 
std::allocator >, Package*, std::less, std::allocator > >, 
std::allocator, std::allocator > const, Package*> > > const&, 
std::__cxx11::basic_string, std::allocator > 
const&, Import_init_set const&, Bindings const*, 
std::unordered_set, 
std::equal_to, std::allocator >*)
../../src/gcc/go/gofrontend/export.cc:573
0x4038569f Gogo::do_exports()

/<>/build/prev-ia64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:907
0x4033552f Gogo::do_exports()
../../src/gcc/go/gofrontend/gogo.cc:5190
0x4033552f go_parse_input_files(char const**, unsigned int, bool, bool)
../../src/gcc/go/gofrontend/go.cc:157
0x402cbc7f go_langhook_parse_file
../../src/gcc/go/go-lang.c:342
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

Could you therefore disable Go on ia64 for the time being in both gcc-11 and 
-snapshot?

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-11=ia64=11-20201208-1=1607996433=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#971547: gcc-10: gm2 should be disabled for cross-builds in debian/rules.defs

[John Paul Adrian Glaubitz]

> On Oct 2, 2020, at 1:30 PM, Matthias Klose  wrote:
> 
> On 10/2/20 1:26 PM, John Paul Adrian Glaubitz wrote:
>>>> On Oct 2, 2020, at 1:18 PM, Matthias Klose  wrote:
>>> both gcc-10-cross and gcc-10-cross-ports are building ok. Not sure what you 
>>> are
>>> trying to do here.
>> Cross-building a native compiler using “sbuild —host=$ARCH”. That failed 
>> when linking gm2.
> 
> ok, no reason to disable it. maybe have a complete bug report?

Well, I think “cross-building gcc-10” is not the same as “building a gcc-10 
cross-compiler”, but let’s not derail the discussion.

In any case, building a native compiler using the packaged cross-compilers 
didn’t work when I tried which is why I filed a bug.

I was also confused about the sequence

> m2_no_cross := yes
> m2_no_cross := no

which is certainly ambiguous to anyone reading the code.

Adrian

Bug#971547: gcc-10: gm2 should be disabled for cross-builds in debian/rules.defs

[John Paul Adrian Glaubitz]

> On Oct 2, 2020, at 1:18 PM, Matthias Klose  wrote:
> 
> both gcc-10-cross and gcc-10-cross-ports are building ok. Not sure what you 
> are
> trying to do here.

Cross-building a native compiler using “sbuild —host=$ARCH”. That failed when 
linking gm2.

Adrian

Bug#971551: gcc-10: Please enable gnat on m68k as it works now

[John Paul Adrian Glaubitz]

Source: gcc-10
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debian-...@lists.debian.org

Hi!

Since the gnat bootstrap on m68k was actually fixed almost over a year ago [1],
I gave it another try and, indeed, I was successfully able to build gcc natively
on m68k with gnat enabled.

I have uploaded a +gnat version of gcc-10 into Debian Ports with gnat enabled so
that the next official upload of the gcc-10 package in unstable can enable gnat
natively on m68k.

Can you apply the following patch to enable gnat on m68k?

--- debian/rules.defs.orig  2020-08-31 13:38:02.0 +0200
+++ debian/rules.defs   2020-10-01 19:30:59.457430044 +0200
@@ -841,10 +841,6 @@
 # Ada 
 ada_no_cpus:= m32r sh3 sh3eb sh4eb
 # no Debian builds ... some of these should exist
-# ... cross-build-native cross-builds a non-working compiler ...
-ifneq (,$(filter $(build_type), build-native))
-  ada_no_cpus += m68k # see https://bugs.debian.org/868365
-endif
 ada_no_systems := 
 ada_no_cross   := no
 ada_no_snap:= no

Not sure what the comment "# no Debian builds ... some of these should exist" 
refers
to, we might be able to remove that as well.

Adrian

> [1] 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9aa357c75358a51f038e50f7c8d9207b58c157e0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#971547: gcc-10: gm2 should be disabled for cross-builds in debian/rules.defs

[John Paul Adrian Glaubitz]

Source: gcc-10
Severity: normal

Hello!

I tried cross-building gcc-10 yesterday and it failed with a linker error when 
building
gm2. Looking at debian/rules.defs [1], m2 is first disabled, then enabled for 
cross
builds:

> # Modula-2 ---
> m2_no_cross := yes
> m2_no_cross := no

Since cross-builing failed for me with gm2 enabled, I assume it's best to 
remove the line
"m2_no_cross := no" from debian/rules.defs to unbreak cross-builds of 
src:gcc-10.

Thanks,
Adrian

> [1] https://sources.debian.org/src/gcc-10/10.2.0-13/debian/rules.defs/#L1247

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#969221: gcc-10: Please disable Go backend on sh4

[John Paul Adrian Glaubitz]

Source: gcc-10
Severity: normal
User: debian-sup...@lists.debian.org
Usertags: sh4
X-Debbugs-Cc: debian-sup...@lists.debian.org

Hi!

The Go backend currently causes gcc on sh4 failing to build from source.

Could you disable the backend for the time being in gcc-9, gcc-10 and
gcc-snapshot until the issue has been resolved?

It's most likely a bug in glibc and not gcc itself but prevents the Go
backend from being built.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#951496: libffi: libffi 3.3 breaks OpenJDK Zero on powerpc

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Hi!

On 2/17/20 2:08 PM, John Paul Adrian Glaubitz wrote:
> Once the issue has been fixed and this bug is closed, I will mark the package 
> for
> building again on powerpc.

Upstream has fixed the problem now [1], attaching the patch. I have
not actually tested yet whether the patch fixes the problem.

Adrian

> [1] 
> https://github.com/libffi/libffi/commit/4d6d2866ae43e55325e8ee96561221804602cd7a

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From 4d6d2866ae43e55325e8ee96561221804602cd7a Mon Sep 17 00:00:00 2001
From: Samuel Holland 
Date: Fri, 21 Feb 2020 21:06:15 -0600
Subject: [PATCH] Update powerpc sysv assembly for ffi_powerpc.h changes (#541)

Some of the flag bits were moved when adding powerpc64 vector support.

Fixes #536
---
 src/powerpc/sysv.S | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/src/powerpc/sysv.S b/src/powerpc/sysv.S
index 1474ce70..df977342 100644
--- a/src/powerpc/sysv.S
+++ b/src/powerpc/sysv.S
@@ -104,17 +104,16 @@ ENTRY(ffi_call_SYSV)
 	bctrl
 
 	/* Now, deal with the return value.  */
-	mtcrf	0x01,%r31 /* cr7  */
+	mtcrf	0x03,%r31 /* cr6-cr7  */
 	bt-	31,L(small_struct_return_value)
 	bt-	30,L(done_return_value)
 #ifndef __NO_FPRS__
 	bt-	29,L(fp_return_value)
 #endif
 	stw	%r3,0(%r30)
-	bf+	28,L(done_return_value)
+	bf+	27,L(done_return_value)
 	stw	%r4,4(%r30)
-	mtcrf	0x02,%r31 /* cr6  */
-	bf	27,L(done_return_value)
+	bf	26,L(done_return_value)
 	stw %r5,8(%r30)
 	stw	%r6,12(%r30)
 	/* Fall through...  */
@@ -145,10 +144,9 @@ L(done_return_value):
 #ifndef __NO_FPRS__
 L(fp_return_value):
 	.cfi_restore_state
-	bf	28,L(float_return_value)
+	bf	27,L(float_return_value)
 	stfd	%f1,0(%r30)
-	mtcrf   0x02,%r31 /* cr6  */
-	bf	27,L(done_return_value)
+	bf	26,L(done_return_value)
 	stfd	%f2,8(%r30)
 	b	L(done_return_value)
 L(float_return_value):

Bug#951496: libffi: libffi 3.3 breaks OpenJDK Zero on powerpc

[John Paul Adrian Glaubitz]

Source: libffi
Version: 3.3-3
Severity: important
Tags: upstream
User: debian-powe...@lists.debian.org
Usertags: powerpc

Hi!

Since libffi 3.3 breaks OpenJDK Zero on powerpc [1], I have reverted the 
breaking
changes in a manual upload (3.3-3+powerpc) in Debian Ports and have set the 
package
to "not-for-us" until the issue has been fixed upstream.

Once the issue has been fixed and this bug is closed, I will mark the package 
for
building again on powerpc.

Thanks,
Adrian

> [1] https://github.com/libffi/libffi/issues/536

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#947500: Missing -latomic on mipsel & armel only?

[John Paul Adrian Glaubitz]

On 1/23/20 2:02 PM, Matthias Klose wrote:
>> I have a package which fails to build on both Debian armel and mipsel
>> with this g++ package, and with the same error:
>> /usr/bin/ld: ./.libs/libfplll.so: undefined reference to
>> `__atomic_store_8'
>> /usr/bin/ld: ./.libs/libfplll.so: undefined reference to
>> `__atomic_load_8'
>>
>> which point to a missing -latomic somewhere. Since all other arches
>> compiled nicely, I think the package is correct and the compiler makes
>> something wrong in those cases, but I might err.
> 
> This is not a bug. You might want to link that unconditionally, however I'd
> prefer if this would be an upstream patch, only linking when needed.

It's actually bug [1] but it has been unresolved for years now.

Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[John Paul Adrian Glaubitz]

Hi Gaius!

On 1/8/20 12:59 PM, Gaius Mulley wrote:
> 
>>> Ah, this makes a lot of sense. Thanks for catching this. I guess, I'll
>>> file a bug report upstream then.
>>>
>>> Adrian
> 
> all fixed now,

Awesome, thanks.

@Matthias: Can you re-enable gm2 on ia64 once you update to gm2 version with
   the patch? Let's see first though whether gcc-10 builds fine with
   gm2 disabled.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[John Paul Adrian Glaubitz]

Hi!

On 1/7/20 12:10 PM, James Clarke wrote:
> 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?

Ah, this makes a lot of sense. Thanks for catching this. I guess, I'll
file a bug report upstream then.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[John Paul Adrian Glaubitz]

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

>> After disabling gm2, the build completes successfully, although I have
>> not run through the whole testsuite yet to confirm everything is okay.
>> But in any case, disabling gm2 on ia64 fixes the build error.
>>
>> Could you add ia64 to m2_no_archs in debian/rules.defs?
>>
>> Attaching a patch which achieves that.
> 
> I can do this.

OK. Thank you.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-10=ia64=10-20200104-1=1578159251=0

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[John Paul Adrian Glaubitz]

Source: gcc-10
Version: 10-20200104-1
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hi!

The gcc-10 build currently fails on ia64 when trying to build gm2 [1],
thus I have disabled gm2 for a local test build.

After disabling gm2, the build completes successfully, although I have
not run through the whole testsuite yet to confirm everything is okay.
But in any case, disabling gm2 on ia64 fixes the build error.

Could you add ia64 to m2_no_archs in debian/rules.defs?

Attaching a patch which achieves that.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/gcc-10-10-20200104/debian/rules.defs 
new/gcc-10-10-20200104/debian/rules.defs
--- old/gcc-10-10-20200104/debian/rules.defs2019-12-17 12:35:22.0 
+0100
+++ new/gcc-10-10-20200104/debian/rules.defs2020-01-07 09:07:55.823830321 
+0100
@@ -1240,7 +1240,7 @@
 with_m2 := yes
   endif
 endif
-m2_no_archs = powerpc ppc64 sh4 kfreebsd-amd64 kfreebsd-i386 hurd-i386
+m2_no_archs = ia64 powerpc ppc64 sh4 kfreebsd-amd64 kfreebsd-i386 hurd-i386
 ifneq (,$(filter $(DEB_TARGET_ARCH),$(m2_no_archs)))
 with_m2 := disabled for cpu $(DEB_TARGET_ARCH)
 endif

Bug#946792: Acknowledgement (gcc-9: Buffer overflow bug introduced by gcc-search-prefixed-as-ld.diff)

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Attaching debdiff which incorporates the changes :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru gcc-9-9.2.1/debian/changelog gcc-9-9.2.1/debian/changelog
--- gcc-9-9.2.1/debian/changelog	2019-11-30 09:17:04.0 +0100
+++ gcc-9-9.2.1/debian/changelog	2019-12-16 00:49:01.0 +0100
@@ -1,3 +1,9 @@
+gcc-9 (9.2.1-21+sh4) unstable; urgency=medium
+
+  * Fix patch gcc-search-prefixed-as-ld.diff.
+
+ -- John Paul Adrian Glaubitz   Mon, 16 Dec 2019 00:49:01 +0100
+
 gcc-9 (9.2.1-21) unstable; urgency=medium
 
   * Update to SVN 20191130 (r278870) from the gcc-9-branch.
diff -Nru gcc-9-9.2.1/debian/patches/gcc-search-prefixed-as-ld.diff gcc-9-9.2.1/debian/patches/gcc-search-prefixed-as-ld.diff
--- gcc-9-9.2.1/debian/patches/gcc-search-prefixed-as-ld.diff	2019-05-04 17:29:34.0 +0200
+++ gcc-9-9.2.1/debian/patches/gcc-search-prefixed-as-ld.diff	2019-12-16 00:48:45.0 +0100
@@ -6,7 +6,7 @@
  	{
  	  len = paths->max_len + extra_space + 1;
  	  len += MAX (MAX (suffix_len, multi_os_dir_len), multiarch_len);
-+	  len += multiarch_len + 2; /* triplet prefix for as, ld.  */
++	  len += strlen (DEFAULT_REAL_TARGET_MACHINE) + 2; /* triplet prefix for as, ld.  */
  	  path = XNEWVEC (char, len);
  	}
  

Bug#946792: Acknowledgement (gcc-9: Buffer overflow bug introduced by gcc-search-prefixed-as-ld.diff)

[John Paul Adrian Glaubitz]

Hi!

I can confirm that changing the patch gcc-search-prefixed-as-ld.diff as 
suggested
above and rebuilding the gcc-9 package fixes the problem for me:

root@tirpitz:~> gcc -m4 -m4-nofpu -pipe -x c /dev/null
/usr/bin/ld: /usr/lib/gcc/sh4-linux-gnu/9/../../../crt1.o: in function `L_main':
(.text+0x1c): undefined reference to `main'
collect2: error: ld returned 1 exit status
root@tirpitz:~>

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#946792: gcc-9: Buffer overflow bug introduced by gcc-search-prefixed-as-ld.diff

[John Paul Adrian Glaubitz]

Source: gcc-9
Severity: important

Hello!

Recently, we have observed strange crashes of gcc-9 while building src:linux
on sh4 [1].

Michael Karcher has debugged the problem and found that this is a buffer
overflow introduced by the patch gcc-search-prefixed-as-ld.diff.

The backtrace is:

Core was generated by `gcc -v -pipe -m4 -m4-nofpu hello.c'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x296993e6 in memcpy () from /lib/sh4-linux-gnu/libc.so.6
(gdb) bt
#0  0x296993e6 in memcpy () from /lib/sh4-linux-gnu/libc.so.6
#1  0x00405ade in file_at_path (path=0x29892fb0 
"/usr/lib/gcc/sh4-linux-gnu/9/../../../../sh4-linux-gnu/bin/sh4-linux-gnu/9/sh4-l",
 data=0x7b901400) at ../../src/gcc/gcc.c:2943
#2  0x00405b80 in file_at_path (path=0x29892fb0 
"/usr/lib/gcc/sh4-linux-gnu/9/../../../../sh4-linux-gnu/bin/sh4-linux-gnu/9/sh4-l",
 data=0x7b9014a0) at ../../src/gcc/gcc.c:2936
#3  0x00404d0e in for_each_path (paths=0x4e8520 , 
do_multi=, extra_space=2, callback=0x405a88 , callback_info=0x7b9014a0)
at ../../src/gcc/gcc.c:2724
#4  0x0040680c in find_a_file (pprefix=, name=0x29828240 "as", 
mode=1, do_multi=) at ../../src/gcc/gcc.c:2999
#5  0x00409e86 in execute () at ../../src/gcc/gcc.c:3200
#6  0x0040ff14 in driver::do_spec_on_infiles (this=0x7b9015f8) at 
../../src/gcc/gcc.c:8377
#7  0x00403b60 in driver::main (this=0x7b9015f8, argc=, 
argv=) at ../../src/gcc/gcc.c:7601
#8  0x00403dd4 in main (argc=6, argv=0x7b901694) at ../../src/gcc/gcc-main.c:47
(gdb)

See also [2].

The issue is fixed by replacing line 9 in [3] with:

+ len += strlen (DEFAULT_REAL_TARGET_MACHINE) + 2; /* triplet prefix 
for as, ld.  */

I assume it's just pure luck the issue doesn't show on other architectures.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=linux=sh4=5.3.15-1=1575738446=0
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92946
> [3] 
> https://sources.debian.org/src/gcc-9/9.2.1-21/debian/patches/gcc-search-prefixed-as-ld.diff/

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#929966: g++-8: ICE (SIGILL in collect2) building musescore-snapshot on riscv64

[John Paul Adrian Glaubitz]

On 6/5/19 7:49 PM, Thorsten Glaser wrote:
> Dear porters, could you please…

Why not do it yourself? You can just compile the source using qemu-user,
building with sbuild and --purge=successful.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: stop building cross compilers for powerpcspe

[John Paul Adrian Glaubitz]

> On Feb 8, 2019, at 3:58 PM, Matthias Klose  wrote:
> 
>> On 08.02.19 12:11, John Paul Adrian Glaubitz wrote:
>>> On 2/8/19 12:10 PM, Matthias Klose wrote:
>>> Upstream GCC has removed the powerpcspe support in GCC 9, and I'd like to 
>>> stop
>>> building the powerpcspe cross compilers for sid/buster.
>> 
>> Can we wait until gcc-9 is the default compiler?
> 
> no, gcc-8 will be the default compiler for buster.

Yes, I know. That’s why I’m not sure why that change would be necessary now.

Thanks,
Adrian

Re: stop building cross compilers for powerpcspe

[John Paul Adrian Glaubitz]

On 2/8/19 12:10 PM, Matthias Klose wrote:
> Upstream GCC has removed the powerpcspe support in GCC 9, and I'd like to stop
> building the powerpcspe cross compilers for sid/buster.

Can we wait until gcc-9 is the default compiler?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#916591: gcc-8: Please add patch to disable broken selective scheduling on ia64

[John Paul Adrian Glaubitz]

Source: gcc-8
Version: 8.2.0-12
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hello!

The optimization feature "selective scheduling" on ia64 is broken and
causes multiple packages failing to build from source when built with
-O3 [1].

Since gcc upstream is pondering to remove selective scheduling anyway
and it currently causes only trouble for us on ia64, I suggest to
disable it for ia64 which is what the attached patch and debdiff do.

Please use either the debdiff or the patch. I have tested the patch.

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/gcc-8-8.2.0/debian/patches/ia64-disable-selective-scheduling.diff 
new/gcc-8-8.2.0/debian/patches/ia64-disable-selective-scheduling.diff
--- old/gcc-8-8.2.0/debian/patches/ia64-disable-selective-scheduling.diff   
1970-01-01 01:00:00.0 +0100
+++ new/gcc-8-8.2.0/debian/patches/ia64-disable-selective-scheduling.diff   
2018-12-16 12:18:41.641049632 +0100
@@ -0,0 +1,16 @@
+--- a/src/gcc/config/ia64/ia64.c   2018-01-03 11:03:58.0 +0100
 b/src/gcc/config/ia64/ia64.c   2018-12-16 12:19:05.420184086 +0100
+@@ -6122,13 +6122,6 @@
+ static void
+ ia64_override_options_after_change (void)
+ {
+-  if (optimize >= 3
+-  && !global_options_set.x_flag_selective_scheduling
+-  && !global_options_set.x_flag_selective_scheduling2)
+-{
+-  flag_selective_scheduling2 = 1;
+-  flag_sel_sched_pipelining = 1;
+-}
+   if (mflag_sched_control_spec == 2)
+ {
+   /* Control speculation is on by default for the selective scheduler,
diff -Nru old/gcc-8-8.2.0/debian/rules.patch new/gcc-8-8.2.0/debian/rules.patch
--- old/gcc-8-8.2.0/debian/rules.patch  2018-12-16 12:19:39.0 +0100
+++ new/gcc-8-8.2.0/debian/rules.patch  2018-12-16 12:20:40.509053873 +0100
@@ -76,6 +76,7 @@
kfreebsd-decimal-float \
powerpcspe_remove_many \
pr87531-revert \
+   ia64-disable-selective-scheduling \
 
 # FIXME: see #915194
 #  gcc-search-prefixed-as-ld \
--- a/src/gcc/config/ia64/ia64.c2018-01-03 11:03:58.0 +0100
+++ b/src/gcc/config/ia64/ia64.c2018-12-16 12:19:05.420184086 +0100
@@ -6122,13 +6122,6 @@
 static void
 ia64_override_options_after_change (void)
 {
-  if (optimize >= 3
-  && !global_options_set.x_flag_selective_scheduling
-  && !global_options_set.x_flag_selective_scheduling2)
-{
-  flag_selective_scheduling2 = 1;
-  flag_sel_sched_pipelining = 1;
-}
   if (mflag_sched_control_spec == 2)
 {
   /* Control speculation is on by default for the selective scheduler,

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[John Paul Adrian Glaubitz]

Hello!

On 12/9/18 3:18 PM, Matthias Klose wrote:
> To me it looks sometimes that Debian is used for testing by upstream, and for
> that the mips architectures don't need to be release architectures.

A note on this: If you decide to move MIPS to Debian Ports, you will make the
port unusable to most users as Debian Ports has a rather rudimentary FTP archive
setup which has some annoying side effects.

There is no support for a testing release, there is no support for cruft and the
FTP maintainers will eventually remove any MIPS-only packages from the Debian
archive which don't build on other architectures which usually affects packages
like boot loaders meaning that it will no longer be easily possible to build the
debian-installer package and consequently build installation images. The 32-bit
PowerPC port lost quite a number of users because of this change. Not because 
the
port was not healthy but because people want to be able to install a stable 
release.

Debian unfortunately doesn't have really good support for Tier II 
architectures, it's
either release or something based on unstable that requires extra elbow grease 
from
both users and maintainers.

Please also keep in mind that removing MIPS from the list of release 
architectures
would mean one less open platform on which Debian is supported. Neither anything
based on ARM, x86 or IBM Z provides a true open platform due to the proprietary
nature of these architectures. There are some efforts in this regard on IBM 
POWER,
but the hardware is still rather expensive, unfortunately. I do hope that RISC-V
will catch up in the future though.

I also think that the broad architecture support is one of the selling points 
of Debian
and if we were to limit Debian's architecture support to just ARM, x86, POWER 
and IBM Z,
I fear that Debian would more and more be turned into a mere development 
project for Ubuntu
and other derivatives rather than being an operating system of its own.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#912649: gcc-8: Please disable gnat on powerpcspe temporarily

[John Paul Adrian Glaubitz]

   
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a 
../libdecnumber/libdecnumber.a   -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl  -lz -g
/usr/bin/ld: 
/usr/lib/gcc/powerpc-linux-gnuspe/8/../../../powerpc-linux-gnuspe/crt1.o: in 
function `_start':
(.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol 
`__libc_start_main@@GLIBC_2.0' defined in .plt section in 
../libiberty/libiberty.a(concat.o)
/usr/bin/ld: /usr/lib/gcc/powerpc-linux-gnuspe/8/libstdc++.a(eh_alloc.o): in 
function `_GLOBAL__sub_I_eh_alloc.cc':
(.text.startup._GLOBAL__sub_I_eh_alloc.cc+0x5c): relocation truncated to fit: 
R_PPC_PLTREL24 against symbol `malloc@@GLIBC_2.0' defined in .plt section in 
../libiberty/libiberty.a(concat.o)
/usr/bin/ld: ada/adadecode.o: in function `add_verbose(char const*, char*)':
/<>/build/gcc/../../src/gcc/ada/adadecode.c:73:(.text+0x48): 
relocation truncated to fit: R_PPC_REL24 against symbol `strcat@@GLIBC_2.0' 
defined in .plt section in ../libiberty/libiberty.a(concat.o)
/usr/bin/ld: 
/<>/build/gcc/../../src/gcc/ada/adadecode.c:74:(.text+0x54): 
relocation truncated to fit: R_PPC_REL24 against symbol `strcat@@GLIBC_2.0' 
defined in .plt section in ../libiberty/libiberty.a(concat.o)
/usr/bin/ld: ada/adadecode.o: in function `has_prefix(char const*, char 
const*)':
/<>/build/gcc/../../src/gcc/ada/adadecode.c:84:(.text+0xa0): 
relocation truncated to fit: R_PPC_REL24 against symbol `strlen@@GLIBC_2.0' 
defined in .plt section in ../libiberty/libiberty.a(concat.o)
/usr/bin/ld: 
/<>/build/gcc/../../src/gcc/ada/adadecode.c:84:(.text+0xb4): 
relocation truncated to fit: R_PPC_REL24 against symbol `strncmp@@GLIBC_2.0' 
defined in .plt section in ../libiberty/libiberty.a(concat.o)
/usr/bin/ld: ada/adadecode.o: in function `has_suffix(char const*, char 
const*)':
/<>/build/gcc/../../src/gcc/ada/adadecode.c:92:(.text+0x10c): 
relocation truncated to fit: R_PPC_REL24 against symbol `strlen@@GLIBC_2.0' 
defined in .plt section in ../libiberty/libiberty.a(concat.o)
/usr/bin/ld: 
/<>/build/gcc/../../src/gcc/ada/adadecode.c:93:(.text+0x11c): 
relocation truncated to fit: R_PPC_REL24 against symbol `strlen@@GLIBC_2.0' 
defined in .plt section in ../libiberty/libiberty.a(concat.o)
/usr/bin/ld: 
/<>/build/gcc/../../src/gcc/ada/adadecode.c:95:(.text+0x15c): 
relocation truncated to fit: R_PPC_REL24 against symbol `strncmp@@GLIBC_2.0' 
defined in .plt section in ../libiberty/libiberty.a(concat.o)
/usr/bin/ld: ada/adadecode.o: in function `__gnat_decode':
/<>/build/gcc/../../src/gcc/ada/adadecode.c:180:(.text+0x2b0): 
relocation truncated to fit: R_PPC_REL24 against symbol `strcpy@@GLIBC_2.0' 
defined in .plt section in ../libiberty/libiberty.a(concat.o)
/usr/bin/ld: 
/<>/build/gcc/../../src/gcc/ada/adadecode.c:184:(.text+0x2c8): 
additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[5]: *** [../../src/gcc/ada/gcc-interface/Make-lang.in:657: gnat1] Error 1

There is most likely a bug in the newer binutils version. As a workaround, gnat
can just be disabled and gcc-8 builds fine which I just did for a manual build.

Please disable gnat on powerpcspe for the time being until we have resolved
the linker issues.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-8=powerpcspe=8.2.0-9=1540969207=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj

[John Paul Adrian Glaubitz]

Hi Roger!

On 07/23/2018 10:42 AM, Roger Shimizu wrote:
> I talked to a few people about keeping armel in buster, during 1st and
> 2nd day in debcamp.
> Seems the blocker is just the buildd server hardware, and memory size it has.

According to my colleague Alex Graf at SUSE, you can definitely build
ARMv7 on arm64 using chroots. The only problem with chroots is that
"uname -a" shows "armv8" which some userspace applications are stumbling
over.

openSUSE/SLE builds armv7 packages in OBS/IBS using a fully emulated system
using KVM.

As for the hardware, you should watch out for hardware with ARM Cortex Cores.
Alternatively, X-Gene 1. ThunderX, ThunderX2 and Centriq are definitely not
supported.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: GCC and binutils updates for buster

[John Paul Adrian Glaubitz]

Hi Matthias!

On 07/16/2018 05:59 PM, Matthias Klose wrote:
> I understand that port maintainers want to have their port included as a 
> release
> architecture, however it becomes a burden if neither the upstream nor the 
> Debian
> port maintainers can keep up with the general upstream development. Maybe we
> need something in between the alternatives of being a release arch or not,
> having the benefit of packages in testing/stable, but not being supported in a
> release.

Care to elaborate what you are referring to? At least for powerpc, ppc64 and
sparc64, gcc seems well enough maintained that bugs get fixed in a reasonable
amount of time.

The powerpcspe is currently being reworked, the SH backend is still maintained
by at least one upstream developer. The only backend I am worried about is
the m68k backend since it still needs to be ported to CC1.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

[John Paul Adrian Glaubitz]

> On Jun 29, 2018, at 9:50 AM, Jonathan Wiltshire  wrote:
> 
>> On Fri, Jun 29, 2018 at 11:04:26PM +0900, Roger Shimizu wrote:
>> I see armel is already not a candidate for buster [0].
>> So it seems we can discuss armhf, but no armel at all.
>> I don't agree with this idea.
>> And I think we should treat armel and armhf equally.
> 
> Please review the mail which originated this thread [1] where you will see
> that both armel and armhf are affected by DSA's concern. If I understand
> correctly, virtualisation of architectures in general is a possible
> solution but there are problems in the case of these two.

I have just talked to a colleague at SUSE about this and apparently Alex Graf 
from SUSE’s QEMU/KVM team has fixed many bugs regarding ARM32 on ARM64 
virtualization. If I understand correctly, SUSE builds ARMv7 on ARM64 without 
problems.

I have reached out to Alex Graf and asked him for clarification on what 
possibilities we currently have.

Adrian

Re: Arch qualification for buster: call for DSA, Security, toolchain concernsj

[John Paul Adrian Glaubitz]

On 06/29/2018 10:41 AM, Luke Kenneth Casson Leighton wrote:
> On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König  
> wrote:
> 
>>> In short, the hardware (development boards) we're currently using to
>>> build armel and armhf packages aren't up to our standards, and we
>>> really, really want them to go away when stretch goes EOL (expected in
>>> 2020).  We urge arm porters to find a way to build armhf packages in
>>> VMs or chroots on server-class arm64 hardware.
> 
>  from what i gather the rule is that the packages have to be built
> native.  is that a correct understanding or has the policy changed?

Native in the sense that the CPU itself is not emulated which is the case
when building arm32 packages on arm64. We're also building i386 packages
on amd64 and we used to build powerpc packages on ppc64 (and we will continue
to do that once the move of powerpc to ports has been completed).

I think that building on arm64 after fixing the bug in question is the
way to move forward. I'm surprised the bug itself hasn't been fixed yet,
doesn't speak for ARM.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#888253: mpfr4: Please reduce optimization level on powerpcspe

[John Paul Adrian Glaubitz]

Source: mpfr4
Version: 3.1.6-1
Severity: important
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpcspe

Hello!

The mpfr4 build for the 4.x versions is currently choking on gcc ICEs [1]:

../../src/set_d64.c: In function 'mpfr_set_decimal64':
../../src/set_d64.c:429:1: error: unrecognizable insn:
 }
 ^
(insn 15 14 16 2 (set (reg:DF 155 [ _9 ])
(subreg:DF (reg/v:DD 214 [ d ]) 0)) "../../src/set_d64.c":130 -1
 (nil))
../../src/set_d64.c:429:1: internal compiler error: in extract_insn, at 
recog.c:2311
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccilswZc.out file, please attach this to 
your bugreport.

Since this prevents powerpcspe from the libmpfr6 transition, I suggest
reducing the optimization level on this architecture as a quick work-
around. I will file an upstream gcc bug and also check whether we still
need -O0 on m68k.

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=mpfr4=powerpcspe=4.0.0-5=1516751176=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/mpfr4-4.0.0/debian/rules new/mpfr4-4.0.0/debian/rules
--- old/mpfr4-4.0.0/debian/rules2018-01-07 08:50:32.0 +0100
+++ new/mpfr4-4.0.0/debian/rules2018-01-24 11:31:37.917782498 +0100
@@ -39,7 +39,7 @@
 CXXFLAGS := -g $(shell dpkg-buildflags --get CXXFLAGS)
 LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS) -Wl,-z,defs
 
-ifeq (m68k,$(DEB_HOST_ARCH))
+ifneq (,$(filter $(DEB_HOST_ARCH), m68k powerpcspe))
   CFLAGS += -O0
 else ifeq (sh4,$(DEB_HOST_ARCH))
   CFLAGS += -mieee

Bug#878338: gcc-defaults FTBFS with debhelper 10.9

[John Paul Adrian Glaubitz]

> dh_compress: unknown option or error during option parsing; aborting
> debian/rules:1354: recipe for target 'binary-native' failed
> make: *** [binary-native] Error 25

I'm running into this on ia64 now but I'm not sure whom to blame.

"Unknown option or error" doesn't make it seem that debhelper is
working as expected, is it? At least there should be a comprehensible
error message.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#883850: gcc-7-cross-ports: Please add support for ia64 to gcc-cross-ports

[John Paul Adrian Glaubitz]

On 01/02/2018 11:12 PM, John Paul Adrian Glaubitz wrote:

I couldn't find any obvious thing missing, so I'll let this as a homework
for anyone reading this bug report. Attaching my versions of rules,
packages.common and packages.invalid.


Ok, turns out replacing "Priority: extra" with "Priority: optional" in
all control.*.in files and then re-running debian/rules control fixes
the problem.

I will file a separate bug report.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#886103: gcc-8: Please disable gccgo on m68k

[John Paul Adrian Glaubitz]

Source: gcc-8
Version: 7.2.0-18
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hello!

Please disable gccgo in gcc-8 on m68k, the build currently fails [1]:

go1: internal compiler error: in set_from, at go/gofrontend/types.cc:2569
mmap: Permission denied
Please submit a full bug report,
with preprocessed source if appropriate.

This is because gccgo in general doesn't currently work properly
on qemu among other reasons.

However, please do not disable gccgo for gcc-7 as the package still
builds fine even with gccgo enabled. gccgo on m68k still needs some
work before it can be used and I want to keep it enabled as long as
it doesn't break the gcc-7 build so I can easily install gccgo-7
for debugging purposes.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-8=m68k=8-20171223-1=1514231538=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#885937: gcc-7: Please add patch to strip -z,defs from linker options for internal libunwind

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7.2.0-18
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hi!

As a follow-up for #885931 which enables gcc's internal libunwind
when cross-building gcc for ia64, we need this additional patch
by James Clarke which strips "-z,defs" from the linker options
for libunwind.

Without these options removed, linking against libunwind.so will
fail in later stages of rebootstrap. James Clarke will be able
to add more details if necessary.

Attaching a patch which adds the patch to debian/patches and
enables it in debian/rules.patch.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/gcc-7-7.2.0/debian/patches/t-libunwind-elf-Wl-z-defs.diff 
new/gcc-7-7.2.0/debian/patches/t-libunwind-elf-Wl-z-defs.diff
--- old/gcc-7-7.2.0/debian/patches/t-libunwind-elf-Wl-z-defs.diff   
1970-01-01 01:00:00.0 +0100
+++ new/gcc-7-7.2.0/debian/patches/t-libunwind-elf-Wl-z-defs.diff   
2017-12-31 15:51:00.191817965 +0100
@@ -0,0 +1,11 @@
+--- a/src/libgcc/config/t-libunwind-elf
 b/src/libgcc/config/t-libunwind-elf
+@@ -31,7 +31,7 @@
+ 
+ SHLIBUNWIND_LINK = $(CC) $(LIBGCC2_CFLAGS) -shared \
+   -nodefaultlibs -Wl,-h,$(SHLIBUNWIND_SONAME) \
+-  -Wl,-z,text -Wl,-z,defs -o $(SHLIB_DIR)/$(SHLIBUNWIND_SONAME).tmp \
++  -Wl,-z,text -o $(SHLIB_DIR)/$(SHLIBUNWIND_SONAME).tmp \
+   @multilib_flags@ $(SHLIB_OBJS) -lc && \
+   rm -f $(SHLIB_DIR)/$(SHLIB_SOLINK) && \
+   if [ -f $(SHLIB_DIR)/$(SHLIBUNWIND_SONAME) ]; then \
diff -Nru old/gcc-7-7.2.0/debian/rules.patch new/gcc-7-7.2.0/debian/rules.patch
--- old/gcc-7-7.2.0/debian/rules.patch  2017-12-27 15:47:52.0 +0100
+++ new/gcc-7-7.2.0/debian/rules.patch  2017-12-31 15:51:00.191817965 +0100
@@ -207,6 +207,7 @@
 debian_patches += \
sys-auxv-header \
libcilkrts-targets \
+   t-libunwind-elf-Wl-z-defs \
 
 ifeq ($(with_ibm_branch),yes)
   debian_patches += ibm-branch

Bug#885428: gcc-6: Please add support for building internal libunwind

[John Paul Adrian Glaubitz]

Hello!

On 12/27/2017 02:09 AM, John Paul Adrian Glaubitz wrote:
> With the patch applied, rebuilding src:gcc-6 provides a gcc-6-source
> package which can be used successully to build the package
> cross-toolchain-base-ports with the ia64 target enabled which in
> turn will allow us to enable ia64 in gcc-7-cross-ports (after
> this patch has been added to src:gcc-7 as well).

The patch isn't optimal as is as further test have shown. I will send
a second patch later, probably next week due to the New Year's
celebration.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#885931: gcc-7: Please modify gcc-7 to use internal libunwind for ia64 cross-builds

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7.2.0-18
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hi!

Like with gcc-6 in #885428, we need to patch src:gcc-7 to use the
internal libunwind library when cross-building for a ia64 target.

The attached patch makes the necessary modifications which have
been verified to work in rebootstrap. A second patch by James
Clarke is necessary to modify some linker flags for building
the internal libunwind. I will file a second bug report for that.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/gcc-7-7.2.0/debian/rules2 new/gcc-7-7.2.0/debian/rules2
--- old/gcc-7-7.2.0/debian/rules2   2017-12-27 15:47:52.0 +0100
+++ new/gcc-7-7.2.0/debian/rules2   2017-12-31 14:54:43.386904669 +0100
@@ -492,7 +492,9 @@
 endif
 
 ifneq (,$(findstring ia64-linux,$(DEB_TARGET_GNU_TYPE)))
-  CONFARGS += --with-system-libunwind
+  ifneq ($(with_unwind),yes)
+  CONFARGS += --with-system-libunwind
+  endif
 endif
 
 ifneq (,$(findstring sh4-linux,$(DEB_TARGET_GNU_TYPE)))
diff -Nru old/gcc-7-7.2.0/debian/rules.d/binary-libgcc.mk 
new/gcc-7-7.2.0/debian/rules.d/binary-libgcc.mk
--- old/gcc-7-7.2.0/debian/rules.d/binary-libgcc.mk 2017-12-27 
15:47:52.0 +0100
+++ new/gcc-7-7.2.0/debian/rules.d/binary-libgcc.mk 2017-12-31 
14:54:43.386904669 +0100
@@ -290,6 +290,11 @@
$(d_l)/$(libgcc_dir$(2))/.
)
 
+   $(if $(filter yes, $(with_unwind)),
+   mv $(d)/$(usr_lib$(2))/libunwind.* \
+   $(d_l)/$(libgcc_dir$(2))/.
+   )
+
debian/dh_doclink -p$(p_l) $(if $(3),$(3),$(p_lbase))
debian/dh_doclink -p$(p_d) $(if $(3),$(3),$(p_lbase))
debian/dh_rmemptydirs -p$(p_l)
diff -Nru old/gcc-7-7.2.0/debian/rules.defs new/gcc-7-7.2.0/debian/rules.defs
--- old/gcc-7-7.2.0/debian/rules.defs   2017-12-27 15:47:52.0 +0100
+++ new/gcc-7-7.2.0/debian/rules.defs   2017-12-31 14:54:43.386904669 +0100
@@ -1354,6 +1354,14 @@
 endif
   endif
 
+  # libunwind -
+  ifneq ($(DEB_STAGE),stage1)
+with_unwind := no
+ifeq ($(DEB_CROSS),yes)
+  with_unwind := yes
+endif
+  endif
+
   # Shared libgcc 
   ifneq ($(DEB_STAGE),stage1)
 with_shared_libgcc := yes

Bug#885428: gcc-6: Please add support for building internal libunwind

[John Paul Adrian Glaubitz]

Source: gcc-6
Version: 6.4.0-11
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hi!

In order to be able to build a cross-compiler for ia64, we need
to be able to build and use the internal libunwind of gcc as the
external libunwind is not available for cross-builds.

I have added a new flag "with_unwind" which is set in debian/
rules.defs for the case when a cross-compiler is built for the
ia64 target architecture. This "with_unwind" is used in debian/
rules2 to pass either --with-system-libunwind or --with-newlib/
--without-headers to the configure script, the latter are necessary
to set inhibit_libc without which building the internal libunwind
is not possible.

I also added the internal libunwind to debian/rules.sonames and
debian/rules.d/binary-libgcc.mk to install the static and shared
libunwind libraries into libgcc if libgcc built as a shared library.

Unfortunately, I couldn't figure out a clean way to avoid the
double check for ia64-linux == $(DEB_TARGET_GNU_TYPE), but this
is the only way to make sure I'm not breaking anything outside
ia64.

With the patch applied, rebuilding src:gcc-6 provides a gcc-6-source
package which can be used successully to build the package
cross-toolchain-base-ports with the ia64 target enabled which in
turn will allow us to enable ia64 in gcc-7-cross-ports (after
this patch has been added to src:gcc-7 as well).

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/gcc-6-6.4.0/debian/rules2 new/gcc-6-6.4.0/debian/rules2
--- old/gcc-6-6.4.0/debian/rules2   2017-12-27 01:32:47.0 +0100
+++ new/gcc-6-6.4.0/debian/rules2   2017-12-27 01:59:43.873507119 +0100
@@ -560,7 +560,12 @@
 endif
 
 ifneq (,$(findstring ia64-linux,$(DEB_TARGET_GNU_TYPE)))
-  CONFARGS += --with-system-libunwind
+  ifeq ($(with_unwind),yes)
+  CONFARGS += --with-newlib
+  CONFARGS += --without-headers
+  else
+  CONFARGS += --with-system-libunwind
+  endif
 endif
 
 ifneq (,$(findstring sh4-linux,$(DEB_TARGET_GNU_TYPE)))
diff -Nru old/gcc-6-6.4.0/debian/rules.d/binary-libgcc.mk 
new/gcc-6-6.4.0/debian/rules.d/binary-libgcc.mk
--- old/gcc-6-6.4.0/debian/rules.d/binary-libgcc.mk 2017-12-27 
01:32:47.0 +0100
+++ new/gcc-6-6.4.0/debian/rules.d/binary-libgcc.mk 2017-12-27 
01:10:46.587608383 +0100
@@ -265,6 +265,9 @@
$(if $(filter yes, $(with_qmath)),
$(call install_gcc_lib,libquadmath,$(QUADMATH_SONAME),$(1),$(2))
)
+   $(if $(filter yes, $(with_unwind)),
+   $(call install_gcc_lib,libunwind,$(UNWIND_SONAME),$(1),$(2))
+   )
 endef
 
 # do_gcc_devels(flavour)
diff -Nru old/gcc-6-6.4.0/debian/rules.defs new/gcc-6-6.4.0/debian/rules.defs
--- old/gcc-6-6.4.0/debian/rules.defs   2017-12-27 01:32:47.0 +0100
+++ new/gcc-6-6.4.0/debian/rules.defs   2017-12-27 00:51:30.727647629 +0100
@@ -1481,6 +1481,14 @@
 endif
   endif
 
+  # libunwind -
+  ifneq (,$(findstring ia64-linux,$(DEB_TARGET_GNU_TYPE)))
+with_unwind := no
+ifeq ($(DEB_CROSS)-$(with_shared_libgcc),yes-yes)
+  with_unwind := yes
+endif
+  endif
+
   # Shared libgcc 
   ifneq ($(DEB_STAGE),stage1)
 with_shared_libgcc := yes
diff -Nru old/gcc-6-6.4.0/debian/rules.sonames 
new/gcc-6-6.4.0/debian/rules.sonames
--- old/gcc-6-6.4.0/debian/rules.sonames2017-12-27 01:32:47.0 
+0100
+++ new/gcc-6-6.4.0/debian/rules.sonames2017-12-27 01:09:51.136178371 
+0100
@@ -38,6 +38,8 @@
echo TSAN_SONAME=$$v >> $$cache; \
v=`tail -1 $(srcdir)/libsanitizer/ubsan/libtool-version | cut -d: -f1`; 
\
echo UBSAN_SONAME=$$v >> $$cache; \
+   v=`tail -1 $(srcdir)/libunwind/unwind/libtool-version | cut -d: -f1`; \
+   echo UNWIND_SONAME=$$v >> $$cache; \
v=`awk -F= '/^libtool_VERSION/ {split($$2,v,":"); print v[1]}' \
$(srcdir)/libatomic/configure.ac`; \
 v=1; \
@@ -84,6 +86,7 @@
 LSAN_SONAME= $(call vafilt,$(SONAME_VARS),LSAN_SONAME)
 TSAN_SONAME= $(call vafilt,$(SONAME_VARS),TSAN_SONAME)
 UBSAN_SONAME   = $(call vafilt,$(SONAME_VARS),UBSAN_SONAME)
+UNWIND_SONAME  = $(call vafilt,$(SONAME_VARS),UNWIND_SONAME)
 VTV_SONAME = $(call vafilt,$(SONAME_VARS),VTV_SONAME)
 CILKRTS_SONAME = $(call vafilt,$(SONAME_VARS),CILKRTS_SONAME)
 QUADMATH_SONAME= $(call vafilt,$(SONAME_VARS),QUADMATH_SONAME)

Bug#883850: gcc-7-cross-ports: Please add support for ia64 to gcc-cross-ports

[John Paul Adrian Glaubitz]

Hi!

I just gave it a try and enabled ia64 as a cross-target and
it looks like we need a cross-glibc for ia64 first:

The following packages have unmet dependencies:
 sbuild-build-depends-gcc-7-cross-ports-dummy : Depends: libc6.1-dev-ia64-cross 
(>= 2.23) but it is not installable
Depends: 
linux-libc-dev-ia64-cross but it is not installable
E: Unable to correct problems, you have held broken packages.
apt-get failed.
E: Package installation failed

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#882174: gcc-7: Raising the armel port baseline to armv5te

[John Paul Adrian Glaubitz]

On 11/19/2017 10:16 PM, John Paul Adrian Glaubitz wrote:

On 11/19/2017 10:06 PM, Adrian Bunk wrote:

As announced in https://lists.debian.org/debian-arm/2017/11/msg00045.html
this patch raises the armel baseline for buster from armv4t to armv5te.


And I still disagree with this change and don't see any gain with it.


I have reconsidered my opinion on that after hearing Roger Shimizu's
opinion as well and I hereby withdraw my objection to this change.

Please go ahead.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#883794: gcc-7: Please enable gccgo on m68k

[John Paul Adrian Glaubitz]

On 12/08/2017 10:29 AM, Matthias Klose wrote:
>> So, please remove m68k from "go_no_cpus" in debian/rules.defs.
> 
> what about gcc-8?

I will start a test build now and let you know. Should be done
by the evening/tomorrow.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#883794: gcc-7: Please enable gccgo on m68k

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7.2.0-17
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

After gccgo-7 was disabled for m68k in #853906 as gcc-7 didn't build
successfully with the Go front enabled on that target, I'm happy to
report that I have successfully re-tested gcc-7 on m68k meaning the
build no longer fails :).

I haven't done thorough testing yet, but I the fact that gcc-7 builds
fine with Go enabled already means that the compiler works which is
enough for us to do further testing of Go on m68k in the future.

So, please remove m68k from "go_no_cpus" in debian/rules.defs.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#883433: gcc-7: Please include patch to implement __builtin_trap() on SH

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7.2.0-16
Severity: important
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh4

Hi!

Both src:linux and src:glibc currently FTBFS on sh4 with gcc-7 because
the compiler is missing the implementation of __builtin_trap(). Upstream
has suggested a patch in [1] which I have verified to work.

Since both src:linux and src:glibc are essential packages, I would like
to ask to have this patch merged into src:gcc-7 already even though
upstream has not merged the patch yet in its current form.

I have slightly modified the patch so it applies against src:gcc-7
and I actually tested the patch with Debian's gcc-7 package.

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Index: a/src/gcc/config/sh/sh-c.c
===
--- a/src/gcc/config/sh/sh-c.c  (revision 234258)
+++ b/src/gcc/config/sh/sh-c.c  (working copy)
@@ -147,4 +147,7 @@
 
   cpp_define_formatted (pfile, "__SH_ATOMIC_MODEL_%s__",
selected_atomic_model ().cdef_name);
+
+  if (TARGET_SH4_TRAPA_SLEEP_BUG)
+builtin_define ("__SH4_TRAPA_SLEEP_BUG__");
 }
Index: a/src/gcc/config/sh/sh-protos.h
===
--- a/src/gcc/config/sh/sh-protos.h (revision 234258)
+++ b/src/gcc/config/sh/sh-protos.h (working copy)
@@ -88,6 +88,46 @@
 #define TARGET_ATOMIC_SOFT_IMASK \
   (selected_atomic_model ().type == sh_atomic_model::soft_imask)
 
+/* __builtin_trapa handling options.  */
+struct sh_builtin_trap_handler
+{
+  enum enum_type
+  {
+none = 0,
+libcall,
+trapa,
+
+num_handlers
+  };
+
+  enum_type type;
+  int trapa_imm_val;
+};
+
+extern const sh_builtin_trap_handler& selected_builtin_trap_handler (void);
+
+#define TARGET_BUILTIN_TRAP_NONE \
+  (selected_builtin_trap_handler ().type == sh_builtin_trap_handler::none)
+
+#define TARGET_BUILTIN_TRAP_TRAPA \
+  (selected_builtin_trap_handler ().type == sh_builtin_trap_handler::trapa)
+
+#define TARGET_BUILTIN_TRAP_TRAPA_VAL_RTX \
+  GEN_INT (selected_builtin_trap_handler ().trapa_imm_val)
+
+#define TARGET_BUILTIN_TRAP_LIBCALL \
+  (selected_builtin_trap_handler ().type == sh_builtin_trap_handler::libcall)
+
+#ifdef SH4_TRAPA_SLEEP_BUG_DEFAULT
+#define TARGET_SH4_TRAPA_SLEEP_BUG \
+  (sh4_trapa_sleep_bug_option == -1 ? (SH4_TRAPA_SLEEP_BUG_DEFAULT != 0) \
+   : (sh4_trapa_sleep_bug_option != 0))
+#else
+#define TARGET_SH4_TRAPA_SLEEP_BUG \
+  ((sh4_trapa_sleep_bug_option == -1 && TARGET_SH4 && !TARGET_SH4A) \
+   || sh4_trapa_sleep_bug_option == 1)
+#endif
+
 #ifdef RTX_CODE
 extern rtx sh_fsca_sf2int (void);
 extern rtx sh_fsca_int2sf (void);
Index: a/src/gcc/config/sh/sh.c
===
--- a/src/gcc/config/sh/sh.c(revision 234258)
+++ b/src/gcc/config/sh/sh.c(working copy)
@@ -785,6 +785,102 @@
 #undef err_ret
 }
 
+/* Information on the currently selected __builtin_trap handler.  */
+static sh_builtin_trap_handler selected_builtin_trap_handler_;
+
+const sh_builtin_trap_handler&
+selected_builtin_trap_handler (void)
+{
+  return selected_builtin_trap_handler_;
+}
+
+static sh_builtin_trap_handler
+parse_validate_builtin_trap_option (const char* str)
+{
+  const char* names[sh_builtin_trap_handler::num_handlers];
+  names[sh_builtin_trap_handler::none] = "none";
+  names[sh_builtin_trap_handler::libcall] = "libcall";
+  names[sh_builtin_trap_handler::trapa] = "trapa";
+
+  sh_builtin_trap_handler ret;
+
+  #if defined (SH_BUILTIN_TRAP_DEFAULT_TRAPA)
+#if SH_BUILTIN_TRAP_DEFAULT_TRAPA < 0 || SH_BUILTIN_TRAP_DEFAULT_TRAPA > 
255
+  #error default builtin trap trapa handler value out of range
+#endif
+ret.type = sh_builtin_trap_handler::trapa;
+ret.trapa_imm_val = SH_BUILTIN_TRAP_DEFAULT_TRAPA;
+  #elif defined (SH_BUILTIN_TRAP_DEFAULT_LIBCALL)
+ret.type = sh_builtin_trap_handler::libcall;
+ret.trapa_imm_val = 0;
+  #else
+ret.type = sh_builtin_trap_handler::none;
+ret.trapa_imm_val = 0;
+  #endif
+
+  /* Handle empty string as 'none'.  */
+  if (str == NULL || *str == '\0')
+return ret;
+
+#define err_ret(...) do { error (__VA_ARGS__); return ret; } while (0)
+
+  std::vector tokens;
+  for (std::stringstream ss (str); ss.good (); )
+  {
+tokens.push_back (std::string ());
+std::getline (ss, tokens.back (), ',');
+  }
+
+  if (tokens.empty ())
+err_ret ("invalid builtin trap handler option");
+
+  /* The first token must be the handler name.  */
+  {
+for (size_t i = 0; i < sh_builtin_trap_handler::num_handlers; ++i)
+  if (tokens.front () =

Bug#882174: gcc-7: Raising the armel port baseline to armv5te

[John Paul Adrian Glaubitz]

On 11/19/2017 10:06 PM, Adrian Bunk wrote:
> As announced in https://lists.debian.org/debian-arm/2017/11/msg00045.html
> this patch raises the armel baseline for buster from armv4t to armv5te.

And I still disagree with this change and don't see any gain with it.

armel is a legacy architecture and people using it don't expect it to
break anymore. Why do you forcefully want to break things?

If people want something better than armel, they will just buy recent ARM
hardware and upgrade to armhf which provides much more hardware power
and capabilities (OpenJDK Hotspot, Rust and so on).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#871034: gcc-7: Please pass --program-prefix=$(cmd_prefix) for cross-build-native builds

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 6.3.0-18
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi!

Trying to cross-build a native compiler (build_type == cross-build-native)
fails with:

dh_movefiles -pcpp-7 usr/bin/powerpc-linux-gnuspe-cpp-7 
usr/lib/gcc/powerpc-linux-gnuspe/7/cc1
dh_movefiles: debian/tmp/usr/bin/powerpc-linux-gnuspe-cpp-7 not found (supposed 
to put it in cpp-7)
debian/rules.d/binary-cpp.mk:27: recipe for target 'stamps/08-binary-stamp-cpp' 
failed
make[1]: *** [stamps/08-binary-stamp-cpp] Error 1
make[1]: Leaving directory '/<>'
debian/rules:70: recipe for target 'binary-arch' failed
make: *** [binary-arch] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit 
status 2

This happens because --program-prefix is not being set.

This is fixed with:

--- debian/rules2~  2017-08-06 20:48:20.0 +0200
+++ debian/rules2   2017-08-06 20:50:04.069729038 +0200
@@ -186,7 +186,7 @@
 ifeq ($(versioned_packages),yes)
   CONFARGS += --program-suffix=-$(BASE_VERSION)
 endif
-ifeq ($(build_type),build-native)
+ifneq (,$(filter $(build_type),build-native cross-build-native))
   CONFARGS += --program-prefix=$(cmd_prefix)
 endif

Attaching a patch as well.

Adrian

--
  .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules2~  2017-08-06 20:48:20.0 +0200
+++ debian/rules2   2017-08-06 20:50:04.069729038 +0200
@@ -186,7 +186,7 @@
 ifeq ($(versioned_packages),yes)
   CONFARGS += --program-suffix=-$(BASE_VERSION)
 endif
-ifeq ($(build_type),build-native)
+ifneq (,$(filter $(build_type),build-native cross-build-native))
   CONFARGS += --program-prefix=$(cmd_prefix)
 endif
 

Bug#870375: gcc-7: Native gdc cross-builds fail

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7.1.0-11
Severity: normal
Tags: patch

Hi!

Trying to do a cross-native build for m68k with gdc enabled fails with:

g++-o d/impcvgen d/impcnvgen.dmdgen.o
/usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 4)
/usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 4)
/usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 4)
/usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 4)
/usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 4)
/usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 4)
/usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 4)
/usr/bin/ld: d/idgen.dmdgen.o: Relocations in generic ELF (EM: 4)
d/idgen.dmdgen.o: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status
../../src/gcc/d/Make-lang.in:254: recipe for target 'd/idgen' failed

I'm currently working around this issue by adding the following
changes to debian/rules.defs:

--- debian/rules.defs.orig  2017-08-01 15:35:52.999394076 +0200
+++ debian/rules.defs   2017-08-01 15:27:13.531269664 +0200
@@ -869,6 +869,9 @@
 ifeq ($(DEB_STAGE)-$(filter libphobos, $(with_rtlibs)),rtlibs-)
   with_d := disabled for rtlibs stage
 endif
+ifeq (,$(filter $(build_type), build-cross build-native))
+   with_d += no
+endif
 with_d := $(call envfilt, d, , , $(with_d))
 
 #with_d := not yet built for GCC 7

I'm attaching the patch just in case. I will also test whether this
affects other architectures for cross-native builds.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.defs.orig  2017-08-01 15:35:52.999394076 +0200
+++ debian/rules.defs   2017-08-01 15:27:13.531269664 +0200
@@ -869,6 +869,9 @@
 ifeq ($(DEB_STAGE)-$(filter libphobos, $(with_rtlibs)),rtlibs-)
   with_d := disabled for rtlibs stage
 endif
+ifeq (,$(filter $(build_type), build-cross build-native))
+   with_d += no
+endif
 with_d := $(call envfilt, d, , , $(with_d))
 
 #with_d := not yet built for GCC 7

Bug#869820: gcc-7-cross-ports: Please build gnat-7 cross-compiler for m68k

[John Paul Adrian Glaubitz]

Hi!

On 07/26/2017 08:32 PM, John Paul Adrian Glaubitz wrote:
> Now that #862927 has been resolved, please remember to build the gnat-7
> cross-compiler for m68k in the next upload.  It's then easier to cross-build
> a native compiler and continue working on the gnat-7 issue on m68k with
> the native compiler [1].

I just did a test build of the package with gnat-7 enabled for m68k. Builds
fine and I have a usable gnat-7 cross-compiler for m68k now.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#862927: gnat (GCC 7) fails to build on m68k

[John Paul Adrian Glaubitz]

Control: reopen -1

On 07/17/2017 10:55 AM, John Paul Adrian Glaubitz wrote:
> On Fri, Jul 14, 2017 at 06:00:04PM +0200, John Paul Adrian Glaubitz wrote:
>> I had a go at this and came up with the attached patch which
>> fixes the problem for me.  With the patch applied, I can build
>> a gnat cross-compiler for m68k.
> 
> The patch has already been merged upstream, both on trunk [1] and in
> the gcc-7-branch [2], so carrying the patch is not necessary when
> including the next slew of SVN updates.

The current version of gcc-7 in unstable is missing the patch from [1]:

s-maccod.ads:36:15: violation of No_Elaboration_Code_All at line 37
s-maccod.ads:36:15: unit "System" does not have No_Elaboration_Code_All
../gcc-interface/Makefile:299: recipe for target 's-maccod.o' failed

I'll reopen this.

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81446

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#869820: gcc-7-cross-ports: Please build gnat-7 cross-compiler for m68k

[John Paul Adrian Glaubitz]

Source: gcc-7-cross-ports
Version: 6.3.0-18cross1
Severity: normal

Hi!

Now that #862927 has been resolved, please remember to build the gnat-7
cross-compiler for m68k in the next upload.  It's then easier to cross-build
a native compiler and continue working on the gnat-7 issue on m68k with
the native compiler [1].

Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81495

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#862927: gnat (GCC 7) fails to build on m68k

[John Paul Adrian Glaubitz]

On Fri, Jul 14, 2017 at 06:00:04PM +0200, John Paul Adrian Glaubitz wrote:
> I had a go at this and came up with the attached patch which
> fixes the problem for me.  With the patch applied, I can build
> a gnat cross-compiler for m68k.

The patch has already been merged upstream, both on trunk [1] and in
the gcc-7-branch [2], so carrying the patch is not necessary when
including the next slew of SVN updates.

Adrian

> [1] https://gcc.gnu.org/viewcvs/gcc?view=revision=250224
> [2] https://gcc.gnu.org/viewcvs/gcc?view=revision=250225

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#868365: gcc-7: Please enable gnat-7 on m68k

[John Paul Adrian Glaubitz]

Hi!

On Sat, Jul 15, 2017 at 12:03:13AM +0200, John Paul Adrian Glaubitz wrote:
> After fixing gnat in gcc-7 with the small patch provided in
> #862927 [1], I have successfully bootstrapped gnat-7 for
> m68k and uploaded the packages to unstable so that gnat-7
> can be used as a build dependency for gcc-7.

While the patch allowed me to cross-build a native gnat-7, native
builds unfortunately currently fail with obscure linker errors [1]:

/usr/lib/gcc/m68k-linux-gnu/7/../../../m68k-linux-gnu/crt1.o: In function 
`_start':
(.text+0x1c): undefined reference to `main'
./xtreeprs.o: In function `_ada_xtreeprs':
xtreeprs.adb:(.text+0x4a6): undefined reference to `xtreeprs__TnamesBIP.1929'
xtreeprs.adb:(.text+0x4cc): undefined reference to `xtreeprs__TnamesBDI.1932'
xtreeprs.adb:(.text+0x168c): undefined reference to `xtreeprs__put_line__2.2465'
xtreeprs.adb:(.text+0x16b0): undefined reference to `xtreeprs__put_line__2.2465'
xtreeprs.adb:(.text+0x17d0): undefined reference to `xtreeprs__put_line__2.2465'
xtreeprs.adb:(.text+0x1802): undefined reference to `xtreeprs__put_line.2461'
xtreeprs.adb:(.text+0x23f4): undefined reference to `xtreeprs__put_line__2.2465'
xtreeprs.adb:(.text+0x26ae): undefined reference to `xtreeprs__put_line__2.2465'
xtreeprs.adb:(.text+0x28de): undefined reference to `xtreeprs__put_line__2.2465'
xtreeprs.adb:(.text+0x29a8): undefined reference to `xtreeprs__put_line.2461'
xtreeprs.adb:(.text+0x29d8): undefined reference to `xtreeprs__put_line.2461'
xtreeprs.adb:(.text+0x2a08): undefined reference to `xtreeprs__put_line.2461'
xtreeprs.adb:(.text+0x2a38): undefined reference to `xtreeprs__put_line.2461'
xtreeprs.adb:(.text+0x2cb2): undefined reference to `xtreeprs__put_line__2.2465'
xtreeprs.adb:(.text+0x2fca): undefined reference to `xtreeprs__put_line__2.2465'
xtreeprs.adb:(.text+0x309e): undefined reference to `xtreeprs__put_line.2461'
xtreeprs.adb:(.text+0x30ce): undefined reference to `xtreeprs__put_line.2461'
xtreeprs.adb:(.text+0x30ea): undefined reference to `xtreeprs___finalizer.1652'
xtreeprs.adb:(.text+0x314e): undefined reference to `xtreeprs__TnamesBDF.1940'
collect2: error: ld returned 1 exit status
gnatlink-7: error when calling /usr/bin/gcc-7
gnatmake: *** link failed.
/bin/bash: ./xtreeprs: No such file or directory
../../src/gcc/ada/Make-generated.in:28: recipe for target 'ada/treeprs.ads' 
failed
make[5]: *** [ada/treeprs.ads] Error 127
make[5]: *** Waiting for unfinished jobs
../../src/gcc/doc/cpp.texi: warning: document without nodes
../../src/gcc/doc/install.texi: warning: document without nodes
/usr/lib/gcc/m68k-linux-gnu/7/../../../m68k-linux-gnu/crt1.o: In function 
`_start':
(.text+0x1c): undefined reference to `main'
collect2: error: ld returned 1 exit status
gnatlink-7: error when calling /usr/bin/gcc-7
gnatmake: *** link failed.
/bin/bash: ./xsnamest: No such file or directory
../../src/gcc/ada/Make-generated.in:50: recipe for target 'ada/stamp-snames' 
failed
make[5]: *** [ada/stamp-snames] Error 127
/usr/lib/gcc/m68k-linux-gnu/7/../../../m68k-linux-gnu/crt1.o: In function 
`_start':
(.text+0x1c): undefined reference to `main'
collect2: error: ld returned 1 exit status
gnatlink-7: error when calling /usr/bin/gcc-7
gnatmake: *** link failed.
/bin/bash: ./xeinfo: No such file or directory
../../src/gcc/ada/Make-generated.in:35: recipe for target 'ada/einfo.h' failed
make[5]: *** [ada/einfo.h] Error 127
/usr/lib/gcc/m68k-linux-gnu/7/../../../m68k-linux-gnu/crt1.o: In function 
`_start':
(.text+0x1c): undefined reference to `main'
./csinfo.o: In function `_ada_csinfo':
csinfo.adb:(.text+0x3350): undefined reference to `csinfo__next_line.2855'
csinfo.adb:(.text+0x418a): undefined reference to `csinfo__next_line.2855'
csinfo.adb:(.text+0x443c): undefined reference to `csinfo__next_line.2855'
csinfo.adb:(.text+0x4b04): undefined reference to `csinfo__next_line.2855'
csinfo.adb:(.text+0x4dfa): undefined reference to `csinfo__next_line.2855'
./csinfo.o:csinfo.adb:(.text+0x54b6): more undefined references to 
`csinfo__next_line.2855' follow
./csinfo.o: In function `_ada_csinfo':
csinfo.adb:(.text+0x633a): undefined reference to `csinfo__vstringaIP.2881'
csinfo.adb:(.text+0x637e): undefined reference to `csinfo__vstringaDI.2884'
csinfo.adb:(.text+0x653e): undefined reference to `csinfo__sort.2907'
csinfo.adb:(.text+0x6550): undefined reference to `csinfo__next_line.2855'
csinfo.adb:(.text+0x6560): undefined reference to `csinfo__next_line.2855'
csinfo.adb:(.text+0x6570): undefined reference to `csinfo__next_line.2855'
csinfo.adb:(.text+0x65a0): undefined reference to `csinfo__next_line.2855'
csinfo.adb:(.text+0x69d8): undefined reference to `csinfo__next_line.2855'
./csinfo.o:csinfo.adb:(.text+0x7200): more undefined references to 
`csinfo__next_line.2855' follow
./csinfo.o: In function `_ada_csinfo':
csinfo.adb:(.text+0x7654): undefined reference to `csinfo__vstringaIP.2881'
csinfo.adb:(.text+0x7692): undefined reference to `csinfo__vstringaDI.2884

Bug#868365: gcc-7: Please enable gnat-7 on m68k

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7.1.0-9
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

After fixing gnat in gcc-7 with the small patch provided in
#862927 [1], I have successfully bootstrapped gnat-7 for
m68k and uploaded the packages to unstable so that gnat-7
can be used as a build dependency for gcc-7.

Thus, please enable gnat in gcc-7 on m68k by dropping "m68k"
from "ada_no_cpus" in debian/rules.defs after adding the
patch provided in #862927 [1] and adding "gnat-7 [m68k]"
to Build-Depends in debian/control.

Thanks,
Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862927

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#862927: gnat (GCC 7) fails to build on m68k

[John Paul Adrian Glaubitz]

Package: src:gcc-7-cross-ports
Followup-For: Bug #862927
User: debian-...@lists.debian.org
Usertags: m68k

Hello!

I had a go at this and came up with the attached patch which
fixes the problem for me.  With the patch applied, I can build
a gnat cross-compiler for m68k.

Cheers,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- a/src/gcc/ada/system-linux-m68k.ads.orig	2016-12-05 12:27:55.0 +0100
+++ b/src/gcc/ada/system-linux-m68k.ads	2017-07-14 16:07:32.442768480 +0200
@@ -40,6 +40,9 @@
--  this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
--  2005, this is Pure in any case (AI-362).
 
+   pragma No_Elaboration_Code_All;
+   --  Allow the use of that restriction in units that WITH this unit
+
type Name is (SYSTEM_NAME_GNAT);
System_Name : constant Name := SYSTEM_NAME_GNAT;
 
@@ -126,7 +129,7 @@
--  of the individual switch values.
 
Backend_Divide_Checks : constant Boolean := False;
-   Backend_Overflow_Checks   : constant Boolean := False;
+   Backend_Overflow_Checks   : constant Boolean := True;
Command_Line_Args : constant Boolean := True;
Configurable_Run_Time : constant Boolean := False;
Denorm: constant Boolean := True;

Bug#868186: gcc-7: powerpcspe missing for cross-builds in d/control and d/rules.conf

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 6.3.0-18
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpcspe

Hi!

Cross-building gcc-7 for powerpcspe is currently not possible because the
control file is missing the build dependencies for the cross-build [1].

Additionally, the Debian architecture mapping for the command prefix
(GNU triplet) is missing in debian/rules.conf [2].

Cheers,
Adrian

> [1] https://sources.debian.net/src/gcc-7/7.1.0-9/debian/control/#L23
> [2] http://sources.debian.net/src/gcc-7/7.1.0-9/debian/rules.conf/#L430

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#865059: gcc-7: Please temporarily build with --disable-libcilkrts on sparc64

[John Paul Adrian Glaubitz]

Control: clone -1
Control: reassign gcc-snapshot

On Mon, Jun 19, 2017 at 01:01:19AM +0200, John Paul Adrian Glaubitz wrote:
> It turned out that the offending test is cilkplus and until the kernel
> has been fixed, please make sure to build gcc-7 on sparc* with cilk
> disabled, e.g. by passing --disable-libcilkrts to configure:

Yep, just confirmed, building with libcilkrts disabled fixes our
problem.

The library should also be disabled for gcc-snapshot, cloning this bug.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#865059: gcc-7: Please temporarily build with --disable-libcilkrts on sparc64

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7.1.0-7
Severity: important
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

We're currently observing that the gcc-7 testsuite is crashing the kernel
on the buildds when building with many parallel jobs (>= 16).

It turned out that the offending test is cilkplus and until the kernel
has been fixed, please make sure to build gcc-7 on sparc* with cilk
disabled, e.g. by passing --disable-libcilkrts to configure:

ifneq (,$(findstring sparc64-linux,$(DEB_TARGET_GNU_TYPE)))
  CONFARGS += --with-cpu-32=ultrasparc --disable-libcilkrts
  ifeq ($(biarch32),yes)
CONFARGS += --enable-targets=all
  endif
endif

Not sure whether sparc64 should also be removed from rules.defs:cilkrts_archs
for now but I have done that now just to be safe.

We'll let you know once the issue has been fixed in the kernel and
libcilkrts can be enabled again.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#861945: gcc-6: Please backport fix for PR/60818 from the trunk

[John Paul Adrian Glaubitz]

Source: gcc-6
Version: 6.3.0-16
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpcspe

Hi!

The gcc trunk and thus gcc-7 contains a fix for the RTL optimizer that
affects powerpcspe [1]. Unfortunately, the patch for this PR (60818)
has not been backported to the gcc-6 trunk yet.

Would it be possible to include the patch to the gcc-6 package?

I'm attaching the patch taken from the trunk, already in the proper
format to be added to the gcc-6 package.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
# Fix PR rtl-optimization/60818, taken from the trunk.

gcc/

2017-04-04  Segher Boessenkool  <seg...@kernel.crashing.org>

PR rtl-optimization/60818
* simplify-rtx.c (simplify_binary_operation_1): Do not replace
a compare of comparisons with the thing compared if this results
in a different machine mode.

--- a/src/gcc/simplify-rtx.c2017/04/03 22:57:32 246665
+++ b/src/gcc/simplify-rtx.c2017/04/04 00:10:02 24
@@ -2306,10 +2306,10 @@
  return xop00;
 
if (REG_P (xop00) && REG_P (xop10)
-   && GET_MODE (xop00) == GET_MODE (xop10)
&& REGNO (xop00) == REGNO (xop10)
-   && GET_MODE_CLASS (GET_MODE (xop00)) == MODE_CC
-   && GET_MODE_CLASS (GET_MODE (xop10)) == MODE_CC)
+   && GET_MODE (xop00) == mode
+   && GET_MODE (xop10) == mode
+   && GET_MODE_CLASS (mode) == MODE_CC)
  return xop00;
}
   break;

Re: Lack of hardening=+pie gives unwanted, unsilenceable noisy compiler output

[John Paul Adrian Glaubitz]

Hi!

The latest upload [1] for gcc-6 now contains this change:

> * dpkg-buildflags stopped fiddling around with spec files; remove
>   the code removing and warning about dpkg's specs.

So, it seems this issue has been resolved now. Pending testing.

Adrian

> [1] https://packages.qa.debian.org/g/gcc-6/news/20170316T134920Z.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#856224: gcc-6: Please enable PIE on ppc64

[John Paul Adrian Glaubitz]

Source: gcc-6
Version: 6.3.0-8
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: ppc64

Hi!

Since PIE is currently disabled on ppc64, gcc-6 emits the following
warning during build:

  g++: note: pie specs /usr/share/dpkg/pie-compile.specs ignored when pie is 
not enabled

Unfortunately, this breaks the testsuites of packages like cmake for
which the warning is unexpected output when evaluating the test
suite.

For example:

  Expected stderr to match:

   expect-err> ^$

  Actual stderr:

   actual-err> c++: note: pie specs /usr/share/dpkg/pie-compile.specs ignored 
when pie is not enabled
   actual-err> c++: note: pie specs /usr/share/dpkg/pie-compile.specs ignored 
when pie is not enabled
   actual-err> c++: note: pie specs /usr/share/dpkg/pie-link.specs ignored when 
pie is not enabled

Since PIE is already enabled for ppc64el, I think we should also enable
it for ppc64 to mitigate this problem.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=cmake=ppc64=3.7.2-1=1488126538=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#855197: gcc-6: Please use --with-cpu on sparc without biarch

[John Paul Adrian Glaubitz]

On 02/15/2017 11:55 AM, John Paul Adrian Glaubitz wrote:
> This is because we're using --with-cpu-32=ultrasparc for all
> sparc configurations although we have to use --with-cpu=ultrasparc
> instead.

... when using nobiarch, I meant.

nobiarch = --with-cpu=ultrasparc
biarch = --with-cpu-32=ultrasparc

> However, after a quick discussion in #sparc, we have come to the conclusion
> to pin sparc to UltraSPARC for now and create a new GNU triplet for SPARCv7
> in the future.

I said "#sparc", I meant "#debian-bootstrap".

> The attached patch fixes the FTCBFS issue for sparc-nobiarch.

Actually verified:

biarch: https://people.debian.org/~glaubitz/bootstrap-sparc-biarch.log.gz
nobiarch: https://people.debian.org/~glaubitz/bootstrap-sparc-nobiarch.log.gz

I'm not fully awake yet. I need another coffee.

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#855197: gcc-6: Please use --with-cpu on sparc without biarch

[John Paul Adrian Glaubitz]

Source: gcc-6
Version: 6.3.0-6
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi!

The rebootstrap for sparc with nobiarch still fails [1].

This is because we're using --with-cpu-32=ultrasparc for all
sparc configurations although we have to use --with-cpu=ultrasparc
instead.

An alternative approach would be to apply the patch for PR libstdc++/64735
on sparc as well and use --with-cpu-32=ultrasparc on biarch configurations
as well. This means, we'd be defaulting to SPARCv7 on nobiarch confiurations
while UltraSPARC (SPARCv8+) would be use for biarch configurations. This
would allow the "sparc" port to be bootstrapped for old sun4m hardware.

However, after a quick discussion in #sparc, we have come to the conclusion
to pin sparc to UltraSPARC for now and create a new GNU triplet for SPARCv7
in the future.

The attached patch fixes the FTCBFS issue for sparc-nobiarch.

Thanks,
Adrian

> [1] 
> https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_sparc_gcc6_nobiarch/

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- gcc-6-6.3.0/debian/rules2.old   2017-02-15 11:51:16.0 +0100
+++ gcc-6-6.3.0/debian/rules2   2017-02-15 11:53:56.619034818 +0100
@@ -544,9 +544,11 @@
 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
+  else
+CONFARGS += --with-cpu=ultrasparc
   endif
 endif
 

Bug#853906: gcc-7: Please disable gccgo on m68k for gcc-7 (but not gcc-6)

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7-20161112-1
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

While we have almost fixed all issues with gccgo-6 on m68k, it seems
that getting gccgo-7 work on m68k requires a different approach as
the code question has been written in Go while it was written
in C for gcc-6.

I would therefore like to ask to disable gccgo in gcc-7 on m68k for
the time being until we have fully resolved the issues with gccgo-7
but please let gccgo-6 enabled for gcc-6.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#853794: gcc-defaults-ports: Missing packages for powerpcspe

[John Paul Adrian Glaubitz]

On 02/01/2017 01:44 PM, Matthias Klose wrote:
> you can't build that on ppc64el, the dependencies are not built there.

Good catch, thank you!

Attaching updated patch.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- gcc-defaults-ports-1.165/debian/rules   2017-01-21 19:07:52.0 +0100
+++ gcc-defaults-ports-1.165/debian/rules   2017-01-21 19:11:34.0 +0100
@@ -312,7 +312,7 @@
 
 go_archs = alpha amd64 arm64 armel armhf i386 ia64 m68k \
mips mips64 mips64el mipsel \
-   powerpc ppc64 ppc64el s390 s390x sparc sparc64 x32
+   powerpc powerpcspe ppc64 ppc64el s390 s390x sparc sparc64 x32
 
 go_multilib_archs = $(filter $(go_archs), $(filter-out armel armhf, $(multilib_archs)))
 
@@ -337,6 +337,7 @@
 HOST_ARCHS_mips64 = amd64 i386 x32
 HOST_ARCHS_mips64el = amd64 i386 x32
 HOST_ARCHS_powerpc = amd64 i386 x32 ppc64el
+HOST_ARCHS_powerpcspe = amd64 i386 x32
 HOST_ARCHS_ppc64 = amd64 i386 x32
 HOST_ARCHS_ppc64el = amd64 i386 x32 ppc64
 HOST_ARCHS_s390x = amd64 i386 x32
@@ -348,9 +349,8 @@
   CROSS_ARCHS  ?= s390x ppc64el arm64 armhf armel \
$(if $(filter $(vendor), Ubuntu),, mips mipsel mips64el)
 else
-  CROSS_ARCHS  ?= alpha hppa m68k mips64 powerpc ppc64 sh4 sparc64 \
+  CROSS_ARCHS  ?= alpha hppa m68k mips64 powerpc powerpcspe ppc64 sh4 sparc64 \
$(if $(filter $(vendor), Ubuntu), mips mipsel mips64el)
-  # powerpcspe, outdated, ftbfs
 endif
 with_cross  = yes

Bug#853794: gcc-defaults-ports: Missing packages for powerpcspe

[John Paul Adrian Glaubitz]

Source: gcc-defaults-ports
Version: 4:6.3.0-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi!

Although current versions of the gcc package have been building without
issues on powerpcspe, we're currently missing this architecture in
gcc-defaults-ports meaning that packages like gcc-powerpc-linux-gnuspe.

However, having these packages is important so powerpcspe can be
enabled in build-essential as cross-build-essential-powerpcspe so
that we're able to cross-build packages for powerpcspe.

I have looked into gcc-defaults-ports and figured that after applying
the changes from the attached patch, running debian/rules control, I
was able to rebuild gcc-defaults-ports with the default gcc packages
for powerpcspe enabled.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- gcc-defaults-ports-1.165/debian/rules   2017-01-21 19:07:52.0 
+0100
+++ gcc-defaults-ports-1.165/debian/rules   2017-01-21 19:11:34.0 
+0100
@@ -312,7 +312,7 @@
 
 go_archs = alpha amd64 arm64 armel armhf i386 ia64 m68k \
mips mips64 mips64el mipsel \
-   powerpc ppc64 ppc64el s390 s390x sparc sparc64 x32
+   powerpc powerpcspe ppc64 ppc64el s390 s390x sparc sparc64 x32
 
 go_multilib_archs = $(filter $(go_archs), $(filter-out armel armhf, 
$(multilib_archs)))
 
@@ -337,6 +337,7 @@
 HOST_ARCHS_mips64 = amd64 i386 x32
 HOST_ARCHS_mips64el = amd64 i386 x32
 HOST_ARCHS_powerpc = amd64 i386 x32 ppc64el
+HOST_ARCHS_powerpcspe = amd64 i386 x32 ppc64el
 HOST_ARCHS_ppc64 = amd64 i386 x32
 HOST_ARCHS_ppc64el = amd64 i386 x32 ppc64
 HOST_ARCHS_s390x = amd64 i386 x32
@@ -348,9 +349,8 @@
   CROSS_ARCHS  ?= s390x ppc64el arm64 armhf armel \
$(if $(filter $(vendor), Ubuntu),, mips mipsel mips64el)
 else
-  CROSS_ARCHS  ?= alpha hppa m68k mips64 powerpc ppc64 sh4 sparc64 \
+  CROSS_ARCHS  ?= alpha hppa m68k mips64 powerpc powerpcspe ppc64 sh4 sparc64 \
$(if $(filter $(vendor), Ubuntu), mips mipsel mips64el)
-  # powerpcspe, outdated, ftbfs
 endif
 with_cross  = yes

Bug#853223: gcc-6: Please update gccgo-m68k.diff with additional changes

[John Paul Adrian Glaubitz]

Source: gcc-6
Version: 6.3.0-5
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281

Hi!

While the first gccgo patch for m68k (gccgo-m68k.diff) already made the Go
compiler partially work, there is still an additional change required which
is enforcing alignment for the structs "Lock" and "Note" in libgo/runtime/
runtime.h:

--- a/src/libgo/runtime/runtime.h.orig  2016-02-12 23:10:09.0 +0100
+++ b/src/libgo/runtime/runtime.h   2017-01-30 18:30:14.188171787 +0100
@@ -154,14 +154,14 @@
// Futex-based impl treats it as uint32 key,
// while sema-based impl as M* waitm.
// Used to be a union, but unions break precise GC.
-   uintptr key;
+   uintptr key __attribute__((aligned(4)));
 };
 struct Note
 {
// Futex-based impl treats it as uint32 key,
// while sema-based impl as M* waitm.
// Used to be a union, but unions break precise GC.
-   uintptr key;
+   uintptr key __attribute__((aligned(4)));
 };
 struct String
 {

This is a change proposed by upstream [1] and verified by me to fix an issue 
with
goroutines causing crashes on m68k [2]. Since this part is implemented 
differently
in gcc-7, we need to pick a different fix there but I haven't received any 
proposal
from upstream for that yet.

Attaching the updated gccgo patch for m68k with the changes proposed by 
upstream.

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281#c4
> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- a/src/gcc/go/gofrontend/types.cc.orig   2016-02-03 07:54:41.0 
+0100
+++ b/src/gcc/go/gofrontend/types.cc2017-01-20 17:54:46.460409688 +0100
@@ -2175,11 +2175,25 @@
   is_common = true;
 }
 
+  // The current garbage collector requires that the GC symbol be
+  // aligned to at least a four byte boundary.  See the use of PRECISE
+  // and LOOP in libgo/runtime/mgc0.c.
+  int64_t align;
+  if (!sym_init->type()->backend_type_align(gogo, ))
+go_assert(saw_errors());
+  if (align < 4)
+align = 4;
+  else
+{
+  // Use default alignment.
+  align = 0;
+}
+
   // Since we are building the GC symbol in this package, we must create the
   // variable before converting the initializer to its backend representation
   // because the initializer may refer to the GC symbol for this type.
   this->gc_symbol_var_ =
-gogo->backend()->implicit_variable(sym_name, sym_btype, false, true, 
is_common, 0);
+gogo->backend()->implicit_variable(sym_name, sym_btype, false, true, 
is_common, align);
   if (phash != NULL)
 *phash = this->gc_symbol_var_;
 
--- a/src/libgo/runtime/go-unsafe-pointer.c.orig2015-10-29 
19:14:50.0 +0100
+++ b/src/libgo/runtime/go-unsafe-pointer.c 2017-01-20 17:57:12.227392567 
+0100
@@ -36,7 +36,8 @@
   sizeof REFLECTION - 1
 };
 
-const uintptr unsafe_Pointer_gc[] = {sizeof(void*), GC_APTR, 0, GC_END};
+const uintptr unsafe_Pointer_gc[] __attribute__((aligned(4))) =
+  {sizeof(void*), GC_APTR, 0, GC_END};
 
 const struct __go_type_descriptor unsafe_Pointer =
 {
--- a/src/libgo/runtime/parfor.c.orig   2015-10-31 01:59:47.0 +0100
+++ b/src/libgo/runtime/parfor.c2017-01-20 17:58:47.154729980 +0100
@@ -10,7 +10,7 @@
 struct ParForThread
 {
// the thread's iteration space [32lsb, 32msb)
-   uint64 pos;
+   uint64 pos __attribute__((aligned(8)));
// stats
uint64 nsteal;
uint64 nstealcnt;
--- a/src/libgo/runtime/runtime.h.orig  2016-02-12 23:10:09.0 +0100
+++ b/src/libgo/runtime/runtime.h   2017-01-21 00:58:07.386595035 +0100
@@ -431,7 +431,7 @@
// otherwise parfor may return while 
other threads are still working
ParForThread *thr;  // array of thread descriptors
// stats
-   uint64 nsteal;
+   uint64 nsteal  __attribute__((aligned(8))); // force alignment for m68k
uint64 nstealcnt;
uint64 nprocyield;
uint64 nosyield;
--- a/src/libgo/runtime/runtime.h.orig  2016-02-12 23:10:09.0 +0100
+++ b/src/libgo/runtime/runtime.h   2017-01-30 18:30:14.188171787 +0100
@@ -154,14 +154,14 @@
// Futex-based impl treats it as uint32 key,
// while sema-based impl as M* waitm.
// Used to be a union, but unions break precise GC.
-   uintptr key;
+   uintptr key __attribute__((aligned(4)));
 };
 struct Note
 {
// Futex-based impl treats it as uint32 key,
// while sema-based impl as M* waitm.
// Used to be a union, but unions break precise GC.
-   uintptr key;
+   uintptr key __attribute__((aligned(4)));
 };
 struct String
 {

Bug#852091: Acknowledgement (gcc-6: Binaries compiled with gccgo on m68k crash (unaligned access))

[John Paul Adrian Glaubitz]

Forgot to link the upstream patch set in the footnote, sorry:

> https://go-review.googlesource.com/#/c/35478/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#852091: gcc-6: Binaries compiled with gccgo on m68k crash (unaligned access)

[John Paul Adrian Glaubitz]

Source: gcc-6
Version: 6.3.0-3
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

The attached patch is a backport of the fix provided by upstream to fix
gccgo on m68k [1]. I have added this patch to gcc-6_6.3.0-3, rebuild the
package and verified gccgo now produces working binaries.

Of course, if upstream decides to backport this patch to gcc-6, it won't
be necessary to carry this patch in gcc-6. But in case that doesn't happen,
here's a patch verified to be working to be applied instantly.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- a/src/gcc/go/gofrontend/types.cc.orig   2016-02-03 07:54:41.0 
+0100
+++ b/src/gcc/go/gofrontend/types.cc2017-01-20 17:54:46.460409688 +0100
@@ -2175,11 +2175,25 @@
   is_common = true;
 }
 
+  // The current garbage collector requires that the GC symbol be
+  // aligned to at least a four byte boundary.  See the use of PRECISE
+  // and LOOP in libgo/runtime/mgc0.c.
+  int64_t align;
+  if (!sym_init->type()->backend_type_align(gogo, ))
+go_assert(saw_errors());
+  if (align < 4)
+align = 4;
+  else
+{
+  // Use default alignment.
+  align = 0;
+}
+
   // Since we are building the GC symbol in this package, we must create the
   // variable before converting the initializer to its backend representation
   // because the initializer may refer to the GC symbol for this type.
   this->gc_symbol_var_ =
-gogo->backend()->implicit_variable(sym_name, sym_btype, false, true, 
is_common, 0);
+gogo->backend()->implicit_variable(sym_name, sym_btype, false, true, 
is_common, align);
   if (phash != NULL)
 *phash = this->gc_symbol_var_;
 
--- a/src/libgo/runtime/go-unsafe-pointer.c.orig2015-10-29 
19:14:50.0 +0100
+++ b/src/libgo/runtime/go-unsafe-pointer.c 2017-01-20 17:57:12.227392567 
+0100
@@ -36,7 +36,8 @@
   sizeof REFLECTION - 1
 };
 
-const uintptr unsafe_Pointer_gc[] = {sizeof(void*), GC_APTR, 0, GC_END};
+const uintptr unsafe_Pointer_gc[] __attribute__((aligned(4))) =
+  {sizeof(void*), GC_APTR, 0, GC_END};
 
 const struct __go_type_descriptor unsafe_Pointer =
 {
--- a/src/libgo/runtime/parfor.c.orig   2015-10-31 01:59:47.0 +0100
+++ b/src/libgo/runtime/parfor.c2017-01-20 17:58:47.154729980 +0100
@@ -10,7 +10,7 @@
 struct ParForThread
 {
// the thread's iteration space [32lsb, 32msb)
-   uint64 pos;
+   uint64 pos __attribute__((aligned(8)));
// stats
uint64 nsteal;
uint64 nstealcnt;
--- a/src/libgo/runtime/runtime.h.orig  2016-02-12 23:10:09.0 +0100
+++ b/src/libgo/runtime/runtime.h   2017-01-21 00:58:07.386595035 +0100
@@ -431,7 +431,7 @@
// otherwise parfor may return while 
other threads are still working
ParForThread *thr;  // array of thread descriptors
// stats
-   uint64 nsteal;
+   uint64 nsteal  __attribute__((aligned(8))); // force alignment for m68k
uint64 nstealcnt;
uint64 nprocyield;
uint64 nosyield;

Bug#851869: gcc-6: Please support multiarch paths for sh3

[John Paul Adrian Glaubitz]

Source: gcc-6
Version: 6.3.0-3
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi!

In order to be able to support sh3 as an architecture in rebootstrap,
we need to modify the gcc-multiarch patch to support both "sh4"
and "sh3" for multiarch paths.

This is achieved by applying the attached patch.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/gcc-6-6.3.0/debian/patches/gcc-multiarch.diff 
new/gcc-6-6.3.0/debian/patches/gcc-multiarch.diff
--- old/gcc-6-6.3.0/debian/patches/gcc-multiarch.diff   2017-01-18 
20:37:40.0 +0100
+++ new/gcc-6-6.3.0/debian/patches/gcc-multiarch.diff   2017-01-17 
14:23:25.412976232 +0100
@@ -19,12 +19,17 @@
 ===
 --- a/src/gcc/config/sh/t-linux
 +++ b/src/gcc/config/sh/t-linux
-@@ -1,2 +1,5 @@
+@@ -1,2 +1,10 @@
  MULTILIB_DIRNAMES= 
  MULTILIB_MATCHES = 
 +
++ifneq (,$(findstring sh4,$(target)))
 +MULTILIB_OSDIRNAMES = .:sh4-linux-gnu sh4_nofpu-linux-gnu:sh4-linux-gnu
 +MULTIARCH_DIRNAME = $(call if_multiarch,sh4-linux-gnu)
++else
++MULTILIB_OSDIRNAMES = .:sh3-linux-gnu sh3_nofpu-linux-gnu:sh3-linux-gnu
++MULTIARCH_DIRNAME = $(call if_multiarch,sh3-linux-gnu)
++endif
 Index: b/src/gcc/config/sparc/t-linux64
 ===
 --- a/src/gcc/config/sparc/t-linux64

Bug#850749: gcc-6: Please enable gccgo on m68k

[John Paul Adrian Glaubitz]

On 01/09/2017 10:54 PM, Matthias Klose wrote:
> Do you have test results for a build?

I did not run the testsuite, if that's what you are asking and it
seems that there are some issues that need to be resolved first.

However, I would like to have gccgo enabled to be able to easily
install it and work on fixing the issues.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#850749: gcc-6: Please enable gccgo on m68k

[John Paul Adrian Glaubitz]

Source: gcc-6
Version: 6.3.0-2
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

I just successfully verified that enabling gccgo on m68k produces a
working gccgo package. I merely modified debian/rules.defs in the
current gcc-6 package to remove "m68k" from the "go_no_cpus" statement
and ran a regular build with sbuild on m68k.

I would like to play with gccgo on m68k, so it would be great if this
could be enabled in the next gcc-6 package upload. After gccgo has
been enabled here, it should also be enabled in gcc-7 and gcc-defaults
for m68k.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.defs.old   2017-01-09 22:07:01.0 +0100
+++ debian/rules.defs   2017-01-09 22:07:57.601561567 +0100
@@ -929,7 +929,7 @@
   with_libcc1 :=
 endif
 
-go_no_cpus := avr arm hppa m68k sh4
+go_no_cpus := avr arm hppa sh4
 ifeq (,$(filter $(distrelease),lenny etch squeeze dapper hardy jaunty karmic 
lucid maverick natty oneiric))
   go_no_cpus := $(filter-out arm, $(go_no_cpus))
 endif

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

On 12/22/2016 12:36 PM, John Paul Adrian Glaubitz wrote:
> Could you please remove the ada-m68k.diff patch from the gcc-7
> source package now. It's existence still breaks the build, it has
> been merged upstream now as already discussed.
> 
> Ada is currently is disabled on gcc-6 and gcc-7 anyway, so gcc-7
> should build fine with the patch removed unless there are other
> Ada-unrelated issues.

I just did that. gcc-7 built fine on m68k and I just uploaded it.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

Hi Matthias!

On 12/05/2016 12:42 PM, John Paul Adrian Glaubitz wrote:
>> gcc upstream just merged the patch after I had to modify it [1].
>>
>>
>>> [1] https://gcc.gnu.org/viewcvs/gcc?view=revision=243247
> 
> Ah, there is no gcc-7 branch yet. So we actually won't need this
> patch but just an updated gcc snapshot for the next upload :).
> 
> The patch can then be dropped from the Debian package.

Could you please remove the ada-m68k.diff patch from the gcc-7
source package now. It's existence still breaks the build, it has
been merged upstream now as already discussed.

Ada is currently is disabled on gcc-6 and gcc-7 anyway, so gcc-7
should build fine with the patch removed unless there are other
Ada-unrelated issues.

It would be good to see the gcc-7 builds on m68k go further than the
patch-apply stage, so I can investigate into remaining issues later.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

On 12/04/2016 06:33 PM, John Paul Adrian Glaubitz wrote:
> OK, attaching the updated patch which applies cleanly.

gcc upstream just merged the patch after I had to modify it [1].

Attaching the updated version.

Thanks,
Adrian

> [1] https://gcc.gnu.org/viewcvs/gcc?view=revision=243247

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>From a781b869f0307566f58d372f6b1b28dd260dcf17 Mon Sep 17 00:00:00 2001
From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Mon, 5 Dec 2016 12:17:09 +0100
Subject: [PATCH] 2011-10-12  Mikael Pettersson  <mi...@it.uu.se>

PR ada/48835
* gcc-interface/Makefile.in: Add support for m68k-linux.
* system-linux-m68k.ads: New file based on system-linux-ppc.ads
and system-vxworks-m68k.ads.

2016-12-05 John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>

* Update for gcc-7.
---
 gcc/ada/gcc-interface/Makefile.in |  29 +++
 gcc/ada/system-linux-m68k.ads | 155 ++
 2 files changed, 184 insertions(+)
 create mode 100644 gcc/ada/system-linux-m68k.ads

diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in
index ec8aa076cbb..98889c0f30f 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -2049,6 +2049,35 @@ ifeq ($(strip $(filter-out hppa% linux%,$(target_cpu) $(target_os))),)
   LIBRARY_VERSION := $(LIB_VERSION)
 endif
 
+# M68K Linux
+ifeq ($(strip $(filter-out m68k% linux%,$(target_cpu) $(target_os))),)
+  LIBGNAT_TARGET_PAIRS = \
+  a-intnam.adshttp://www.gnu.org/licenses/>.  --
+--  --
+-- GNAT was originally developed  by the GNAT team at  New York University. --
+-- Extensive contributions were provided by Ada Core Technologies Inc.  --
+--  --
+--
+
+package System is
+   pragma Pure;
+   --  Note that we take advantage of the implementation permission to make
+   --  this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
+   --  2005, this is Pure in any case (AI-362).
+
+   type Name is (SYSTEM_NAME_GNAT);
+   System_Name : constant Name := SYSTEM_NAME_GNAT;
+
+   --  System-Dependent Named Numbers
+
+   Min_Int   : constant := Long_Long_Integer'First;
+   Max_Int   : constant := Long_Long_Integer'Last;
+
+   Max_Binary_Modulus: constant := 2 ** Long_Long_Integer'Size;
+   Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1;
+
+   Max_Base_Digits   : constant := Long_Long_Float'Digits;
+   Max_Digits: constant := Long_Long_Float'Digits;
+
+   Max_Mantissa  : constant := 63;
+   Fine_Delta: constant := 2.0 ** (-Max_Mantissa);
+
+   Tick  : constant := 0.000_001;
+
+   --  Storage-related Declarations
+
+   type Address is private;
+   pragma Preelaborable_Initialization (Address);
+   Null_Address : constant Address;
+
+   Storage_Unit : constant := 8;
+   Word_Size: constant := 32;
+   Memory_Size  : constant := 2 ** 32;
+
+   --  Address comparison
+
+   function "<"  (Left, Right : Address) return Boolean;
+   function "<=" (Left, Right : Address) return Boolean;
+   function ">"  (Left, Right : Address) return Boolean;
+   function ">=" (Left, Right : Address) return Boolean;
+   function "="  (Left, Right : Address) return Boolean;
+
+   pragma Import (Intrinsic, "<");
+   pragma Import (Intrinsic, "<=");
+   pragma Import (Intrinsic, ">");
+   pragma Import (Intrinsic, ">=");
+   pragma Import (Intrinsic, "=");
+
+   --  Other System-Dependent Declarations
+
+   type Bit_Order is (High_Order_First, Low_Order_First);
+   Default_Bit_Order : constant Bit_Order := High_Order_First;
+   pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning
+
+   --  Priority-related Declarations (RM D.1)
+
+   --  Is the following actually true for GNU/Linux/m68k?
+   --
+   --  0 .. 98 corresponds to the system priority range 1 .. 99.
+   --
+   --  If the scheduling policy is SCHED_FIFO or SCHED_RR the runtime makes use
+   --  of the entire range provided by the system.
+   --
+   --  If the scheduling policy is SCHED_OTHER the only valid system priority
+   --  is 1 and other values are simply ignored.
+
+   Max_Priority   : constant Positive := 97;
+   Max_Interrupt_Priority : constant Positive := 98;
+
+   subtype Any_Priority   is Integer  range  0 .. 98;
+   subtype Priority   is Any_Priority rang

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

On 12/05/2016 12:32 PM, John Paul Adrian Glaubitz wrote:
> On 12/04/2016 06:33 PM, John Paul Adrian Glaubitz wrote:
>> OK, attaching the updated patch which applies cleanly.
> 
> gcc upstream just merged the patch after I had to modify it [1].
> 
> 
>> [1] https://gcc.gnu.org/viewcvs/gcc?view=revision=243247

Ah, there is no gcc-7 branch yet. So we actually won't need this
patch but just an updated gcc snapshot for the next upload :).

The patch can then be dropped from the Debian package.

Thanks,

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

On 12/04/2016 06:26 PM, Andreas Schwab wrote:
> On Dez 04 2016, John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> 
> wrote:
> 
>> So I assume we can strip the patch from the changes in s-memory.adb and
>> s-memory.ads?
> 
> Yes.

OK, attaching the updated patch which applies cleanly.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
gcc/ada/

2011-10-12  Mikael Pettersson  <mi...@it.uu.se>

	PR ada/48835
	* gcc-interface/Makefile.in: Add support for m68k-linux.
	* system-linux-m68k.ads: New file based on system-linux-ppc.ads
	and system-vxworks-m68k.ads.
	* s-memory.adb (Gnat_Malloc): New wrapper around Alloc, returning
	the memory address as a pointer not an integer.
	Add Gnat_Malloc -> __gnat_malloc export.
	* s-memory.ads: Remove Alloc -> __gnat_malloc export.

Index: b/src/gcc/ada/gcc-interface/Makefile.in
===
--- a/src/gcc/ada/gcc-interface/Makefile.in
+++ b/src/gcc/ada/gcc-interface/Makefile.in
@@ -2084,6 +2084,35 @@ ifeq ($(strip $(filter-out hppa% linux%,
   LIBRARY_VERSION := $(LIB_VERSION)
 endif
 
+# M68K Linux
+ifeq ($(strip $(filter-out m68k% linux%,$(arch) $(osys))),)
+  LIBGNAT_TARGET_PAIRS = \
+  a-intnam.adshttp://www.gnu.org/licenses/>.  --
+--  --
+-- GNAT was originally developed  by the GNAT team at  New York University. --
+-- Extensive contributions were provided by Ada Core Technologies Inc.  --
+--  --
+--
+
+package System is
+   pragma Pure;
+   --  Note that we take advantage of the implementation permission to make
+   --  this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
+   --  2005, this is Pure in any case (AI-362).
+
+   type Name is (SYSTEM_NAME_GNAT);
+   System_Name : constant Name := SYSTEM_NAME_GNAT;
+
+   --  System-Dependent Named Numbers
+
+   Min_Int   : constant := Long_Long_Integer'First;
+   Max_Int   : constant := Long_Long_Integer'Last;
+
+   Max_Binary_Modulus: constant := 2 ** Long_Long_Integer'Size;
+   Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1;
+
+   Max_Base_Digits   : constant := Long_Long_Float'Digits;
+   Max_Digits: constant := Long_Long_Float'Digits;
+
+   Max_Mantissa  : constant := 63;
+   Fine_Delta: constant := 2.0 ** (-Max_Mantissa);
+
+   Tick  : constant := 0.000_001;
+
+   --  Storage-related Declarations
+
+   type Address is private;
+   pragma Preelaborable_Initialization (Address);
+   Null_Address : constant Address;
+
+   Storage_Unit : constant := 8;
+   Word_Size: constant := 32;
+   Memory_Size  : constant := 2 ** 32;
+
+   --  Address comparison
+
+   function "<"  (Left, Right : Address) return Boolean;
+   function "<=" (Left, Right : Address) return Boolean;
+   function ">"  (Left, Right : Address) return Boolean;
+   function ">=" (Left, Right : Address) return Boolean;
+   function "="  (Left, Right : Address) return Boolean;
+
+   pragma Import (Intrinsic, "<");
+   pragma Import (Intrinsic, "<=");
+   pragma Import (Intrinsic, ">");
+   pragma Import (Intrinsic, ">=");
+   pragma Import (Intrinsic, "=");
+
+   --  Other System-Dependent Declarations
+
+   type Bit_Order is (High_Order_First, Low_Order_First);
+   Default_Bit_Order : constant Bit_Order := High_Order_First;
+   pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning
+
+   --  Priority-related Declarations (RM D.1)
+
+   --  Is the following actually true for GNU/Linux/m68k?
+   --
+   --  0 .. 98 corresponds to the system priority range 1 .. 99.
+   --
+   --  If the scheduling policy is SCHED_FIFO or SCHED_RR the runtime makes use
+   --  of the entire range provided by the system.
+   --
+   --  If the scheduling policy is SCHED_OTHER the only valid system priority
+   --  is 1 and other values are simply ignored.
+
+   Max_Priority   : constant Positive := 97;
+   Max_Interrupt_Priority : constant Positive := 98;
+
+   subtype Any_Priority   is Integer  range  0 .. 98;
+   subtype Priority   is Any_Priority range  0 .. 97;
+   subtype Interrupt_Priority is Any_Priority range 98 .. 98;
+
+   Default_Priority : constant Priority := 48;
+
+private
+
+   type Address is mod Memory_Size;
+   Null_Address : constant Address := 0;
+
+   --
+   -- System Implementation Parameters --
+   --

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

On 12/04/2016 04:43 PM, John Paul Adrian Glaubitz wrote:
> However, I'm by no means an Ada expert to be able to tell whether we still 
> need
> Ada.Unchecked_Conversion anymore. I have glimpsed over PR48835 and I'm not 
> sure
> whether this confirms this in any way.

Ah, I assume you were talking about comment #58 [1], sorry, I missed that.
It seems that the conversion issue no longer exists, am I correct?

So I assume we can strip the patch from the changes in s-memory.adb and
s-memory.ads? It seems from my elementary understanding of Ada, this
was just a work-around for the the m68k-typical register separation
(address and data) and they've now fixed the issue properly so the
workaround is no longer required.

If that's true, I assume we just need src/gcc/ada/s-memory.ads as well
as the changes to src/gcc/ada/gcc-interface/Makefile.in.

Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835#c58

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

On 12/04/2016 02:38 PM, Andreas Schwab wrote:
> On Dez 04 2016, John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> 
> wrote:
> 
>> @Andreas: Are you sure the patch is no longer necessary?
> 
> I didn't say that.

Ok, this was a misunderstanding then as you meant earlier that "this" is no
longer necessary. But I assume you were talking about the single hunk in line
47 that does no longer apply and not the whole patch, correct?

Removing this hunk below from the patch, makes it apply without issues:

--- a/src/gcc/ada/s-memory.adb
+++ b/src/gcc/ada/s-memory.adb
@@ -47,6 +47,7 @@ with Ada.Exceptions;
with System.Soft_Links;
with System.Parameters;
with System.CRTL;
+with Ada.Unchecked_Conversion;

package body System.Memory is


However, I'm by no means an Ada expert to be able to tell whether we still need
Ada.Unchecked_Conversion anymore. I have glimpsed over PR48835 and I'm not sure
whether this confirms this in any way.

I'm attaching the updated ada-m68k.diff in any case.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
gcc/ada/

2011-10-12  Mikael Pettersson  <mi...@it.uu.se>

	PR ada/48835
	* gcc-interface/Makefile.in: Add support for m68k-linux.
	* system-linux-m68k.ads: New file based on system-linux-ppc.ads
	and system-vxworks-m68k.ads.
	* s-memory.adb (Gnat_Malloc): New wrapper around Alloc, returning
	the memory address as a pointer not an integer.
	Add Gnat_Malloc -> __gnat_malloc export.
	* s-memory.ads: Remove Alloc -> __gnat_malloc export.

Index: b/src/gcc/ada/gcc-interface/Makefile.in
===
--- a/src/gcc/ada/gcc-interface/Makefile.in
+++ b/src/gcc/ada/gcc-interface/Makefile.in
@@ -2084,6 +2084,35 @@ ifeq ($(strip $(filter-out hppa% linux%,
   LIBRARY_VERSION := $(LIB_VERSION)
 endif
 
+# M68K Linux
+ifeq ($(strip $(filter-out m68k% linux%,$(arch) $(osys))),)
+  LIBGNAT_TARGET_PAIRS = \
+  a-intnam.adshttp://www.gnu.org/licenses/>.  --
+--  --
+-- GNAT was originally developed  by the GNAT team at  New York University. --
+-- Extensive contributions were provided by Ada Core Technologies Inc.  --
+--  --
+--
+
+package System is
+   pragma Pure;
+   --  Note that we take advantage of the implementation permission to make
+   --  this unit Pure instead of Preelaborable; see RM 13.7.1(15). In Ada
+   --  2005, this is Pure in any case (AI-362).
+
+   type Name is (SYSTEM_NAME_GNAT);
+   System_Name : constant Name := SYSTEM_NAME_GNAT;
+
+   --  System-Dependent Named Numbers
+
+   Min_Int   : constant := Long_Long_Integer'First;
+   Max_Int   : constant := Long_Long_Integer'Last;
+
+   Max_Binary_Modulus: constant := 2 ** Long_Long_Integer'Size;
+   Max_Nonbinary_Modulus : constant := 2 ** Integer'Size - 1;
+
+   Max_Base_Digits   : constant := Long_Long_Float'Digits;
+   Max_Digits: constant := Long_Long_Float'Digits;
+
+   Max_Mantissa  : constant := 63;
+   Fine_Delta: constant := 2.0 ** (-Max_Mantissa);
+
+   Tick  : constant := 0.000_001;
+
+   --  Storage-related Declarations
+
+   type Address is private;
+   pragma Preelaborable_Initialization (Address);
+   Null_Address : constant Address;
+
+   Storage_Unit : constant := 8;
+   Word_Size: constant := 32;
+   Memory_Size  : constant := 2 ** 32;
+
+   --  Address comparison
+
+   function "<"  (Left, Right : Address) return Boolean;
+   function "<=" (Left, Right : Address) return Boolean;
+   function ">"  (Left, Right : Address) return Boolean;
+   function ">=" (Left, Right : Address) return Boolean;
+   function "="  (Left, Right : Address) return Boolean;
+
+   pragma Import (Intrinsic, "<");
+   pragma Import (Intrinsic, "<=");
+   pragma Import (Intrinsic, ">");
+   pragma Import (Intrinsic, ">=");
+   pragma Import (Intrinsic, "=");
+
+   --  Other System-Dependent Declarations
+
+   type Bit_Order is (High_Order_First, Low_Order_First);
+   Default_Bit_Order : constant Bit_Order := High_Order_First;
+   pragma Warnings (Off, Default_Bit_Order); -- kill constant condition warning
+
+   --  Priority-related Declarations (RM D.1)
+
+   --  Is the following actually true for GNU/Linux/m68k?
+   --
+   --  0 .. 98 corresponds to the system priority range 1 .. 99.
+   --
+   --  If the scheduling policy is SCHED_FIFO or SCHED_RR the runtime makes use
+   --  of the entire range pr

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

On 12/04/2016 01:11 PM, John Paul Adrian Glaubitz wrote:
> Dropping ada-m68k.diff fixes this particular issue for me. 
> m68k-revert-pr45144.patch
> is currently not applied because we have disabled Ada on m68k by adding it to
> ada_no_cpus in debian/rules.defs because of #814221 [1].

Hmm, so I just had a look at the current gcc-7 sources as well as gcc git and it
seems this particular patch which adds support for m68k-linux is not in, I see
support for VXWorks only:

glaubitz@ikarus:~/m68k/gcc-7-7-20161201/gcc-20161201/gcc/ada$ ls -l *m68k*
-rw-r--r-- 1 glaubitz glaubitz 3533 Dec  9  2014 s-vxwork-m68k.ads
-rw-r--r-- 1 glaubitz glaubitz 7829 Apr 26  2016 system-vxworks-m68k.ads
glaubitz@ikarus:~/m68k/gcc-7-7-20161201/gcc-20161201/gcc/ada$

@Andreas: Are you sure the patch is no longer necessary?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

Hi Matthias!

On 12/03/2016 11:56 PM, Matthias Klose wrote:
> Adrian, I would appreciate if you could look at a package first before calling
> for actions, and then ask a complete question. We also have the
> m68k-revert-pr45144 patch in the build which apparently needs some decision.

Dropping ada-m68k.diff fixes this particular issue for me. 
m68k-revert-pr45144.patch
is currently not applied because we have disabled Ada on m68k by adding it to
ada_no_cpus in debian/rules.defs because of #814221 [1].

I think it makes sense to discuss m68k-revert-pr45144.patch in #814221 and treat
this particular patch as a separate issue.

Adrian

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814221

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

On 12/03/2016 10:02 PM, Andreas Schwab wrote:
>> patching file src/gcc/ada/s-memory.adb
>> Hunk #1 FAILED at 47.
>> Hunk #2 succeeded at 113 (offset 13 lines).
>> 1 out of 2 hunks FAILED -- rejects in file src/gcc/ada/s-memory.adb
>> patching file src/gcc/ada/s-memory.ads
> 
> According to PR48835, this is no longer necessary.

Ah, thanks for letting us know. I was already suspecting that, but I didn't
have the time yet to verify it.

@Matthias:

Do you agree that we can drop this particular patch then?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#846872: gcc-7: FTBFS on m68k - fails to apply ada-m68k.diff patch

[John Paul Adrian Glaubitz]

Source: gcc-7
Version: 7-20161201-1
Severity: normal
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

gcc-7 currently fails to build from source because one of the patches
shipped in the source package don't apply properly [1]:

Applying patch ada-m68k.diff
patching file src/gcc/ada/gcc-interface/Makefile.in
Hunk #1 succeeded at 2058 (offset -26 lines).
patching file src/gcc/ada/s-memory.adb
Hunk #1 FAILED at 47.
Hunk #2 succeeded at 113 (offset 13 lines).
1 out of 2 hunks FAILED -- rejects in file src/gcc/ada/s-memory.adb
patching file src/gcc/ada/s-memory.ads
patching file src/gcc/ada/system-linux-m68k.ads
Patch ada-m68k.diff does not apply (enforce with -f)
debian/rules.patch:311: recipe for target 'stamps/02-patch-stamp' failed
make: *** [stamps/02-patch-stamp] Error 1
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=gcc-7=m68k=7-20161201-1=1480796787

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#845461: gcc-6: Please build with --with-cpu=ultrasparc on sparc

[John Paul Adrian Glaubitz]

> On Nov 27, 2016, at 2:14 PM, Matthias Klose  wrote:
> 
> The patches to configure --with-cpu-32= and --with-cpu-64= are availabe in GCC
> 6, so we should use them and ensure that the defaults for the sparc/64 and
> sparc64, and sparc and sparc64/32 targets match.  Just forcing ultrasparc for
> all multilib variants seems to be questionable.

Right. I completely forgot about the approach to just with 
--with-cpu32=ultrasparc. Definitely makes sense. But it might break again if 
the default target for gcc for 64-bit is moved to anything newer than 
ultrasparc.

> Btw, is there any business with the Debian sparc port, or is this just some
> exercise?

I want to have this small patch in to help Helmut Grohne with his rebootstrap 
project. We are currently not planning to bring "sparc" back into Debian. 
However, there are many end users who stilm prefer a 32-bit userland over a 
64-bit userland, including David Miller (the main person behind the Linux port 
for SPARC), and keeping "sparc" bootstrappable in "rebootstrap" means that a) 
Helmut has more targets for testing (and finding bugs) and b) those who wish to 
use a 32-bit userland will always be able to bootstrap it themselves. I 
actually expect that thanks to Helmut's rebootstrap project, we might have a 
tool in Debian in the future which allows us to cross-bootstrap Debian for any 
architecture/toolchain/libc combination supported by the toolchain.

Given how small and self-containing this minor change to the debian/rules2 file 
is, I think it's definitely a very good idea to apply it given the previously 
mentioned motivations.

Thanks,
Adrian

Bug#845461: gcc-6: Please build with --with-cpu=ultrasparc on sparc

[John Paul Adrian Glaubitz]

> On Nov 24, 2016, at 7:07 PM, Jose E. Marchesi  
> wrote:
> 
> Ah, I thought you said that GCC 6 was not building anymore with
> --mcpu=ultrasparc due to some bug.  You mean that the debian package is
> no longer using that option.

Yes, but only the Debian package on 32-bit SPARC ("sparc"), 64-bit SPARC 
("sparc64") is fine.

I just want to convince our gcc maintainer in Debian to configure 32-bit SPARC 
on Debian for all configurations with --with-cpu=ultrasparc (i.e. for both 
biarch enabled and disabled).

Just always passing that configure should work on 32-bit SPARC, correct?

Adrian