Bug#1067644: gcc-12: BD-Uninstallable on m68k due to gnat-11 vs gnat-12

[Thorsten Glaser]

Source: gcc-12
Version: 12.3.0-15

gcc-12 is BD-Uninstallable on m68k due to missing gnat-11
but gnat-12 is present and could probably be used, at least
in a “gnat-11 | gnat-12” alternative dependency maybe?

Bug#1066891: gcc-13: ICE compiling OpenSSH: in change_address_1

[Thorsten Glaser]

On Sat, 16 Mar 2024, Matthias Klose wrote:

> you can work-around that by omitting -fzero-call-used-regs=used

Thanks! That will help with the transition.

Will you hand this over to upstream for an eventual fix?

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#1050429: GCC 13 stopped supporting a documented option (was Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL')

[Thorsten Glaser]

Matthias Klose dixit:

> you can work around it

Unfortunately not. (The musl packagers might be able to.)

>, this is not an RC issue. Please stop playing
> bug ping pong.

If GCC stops supporting an option it used to support,
and where the GCC documentation say it’s supported,
it in my opinion very much is an RC bug.

Unfortunately, eller is down so I can’t check whether
this also occurs in gcc-snapshot on mips64el (in which
case it’d likely be an upstream bug).

bye,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec

Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'

[Thorsten Glaser]

Control: severity -1 serious
thanks

Matthias Klose dixit:

> musl is not part of the standard toolchain, not even on mips64el.
> Please build your package with the default toolchain

This isn’t (just) an issue with a package build.

This bug manifests as follows:

As a user, I install musl-tools in order to be able to run
musl-gcc on some code I’m developing locally so it builds
against musl libc.

musl-gcc calls gcc with several options, including -EL.

gcc-12 has that option, gcc-13 doesn’t. gcc-13 documents,
however, to have this option:

│ 3.19.28 MIPS Options
│ 
│
│ ‘-EB’
│  Generate big-endian code.
│
│ ‘-EL’
│  Generate little-endian code.  This is the default for ‘mips*el-*-*’
│  configurations.
[…]

So this is clearly a bug in gcc-13 and a regression against gcc-12.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'

[Thorsten Glaser]

reassign 1050429 gcc-13 13.2.0-2
notfound 1050429 12.3.0-8
affects 1050429 musl-tools
thanks

Dixi quod…

>The -EL is not even musl-specific?!
>
>(sid_mips64el-dchroot)tg@eller:~$ cat 
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
[…]

Worse, doing mips64el-linux-gnuabi64-gcc{,-12} -dumpspecs and
diffing the result, there’s no change regarding -EL either.

This looks like a genuine GCC bug? I’m reassigning.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'

[Thorsten Glaser]

Dixi quod…

>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -EL
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -specs 
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
>mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL'
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -EL
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -specs 
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
>(sid_mips64el-dchroot)tg@eller:~$ _
>
>… but a regression (?) in GCC 13 versus GCC 12.

The -EL is not even musl-specific?!

(sid_mips64el-dchroot)tg@eller:~$ cat 
"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
%rename cpp_options old_cpp_options

*cpp_options:
-nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s 
%(old_cpp_options)

*cc1:
%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem 
include%s

*link_libgcc:
-L/usr/lib/mips64el-linux-musl -L .%s

*libgcc:
libgcc.a%s %:if-exists(libgcc_eh.a%s)

*startfile:
%{!shared: /usr/lib/mips64el-linux-musl/Scrt1.o} 
/usr/lib/mips64el-linux-musl/crti.o crtbeginS.o%s

*endfile:
crtendS.o%s /usr/lib/mips64el-linux-musl/crtn.o

*link:
-dynamic-linker /lib/ld-musl-mips64el.so.1 -nostdlib %{shared:-shared} 
%{static:-static} %{rdynamic:-export-dynamic}

*esp_link:


*esp_options:


*esp_cpp_options:


(sid_mips64el-dchroot)tg@eller:~$ _

There’s no -EL in that file‽ So apparently GCC 13 is breaking of itself?

bye,
//mirabilos
-- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'

[Thorsten Glaser]

Dixi quod…

>According to upstream documentation, -EL is supposed to be supported
>by the compiler driver:

OK so it’s not the compiler *driver*…

(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -EL
(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -specs 
"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL'
(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -EL
(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -specs 
"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
(sid_mips64el-dchroot)tg@eller:~$ _

… but a regression (?) in GCC 13 versus GCC 12.

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Re: Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'

[Thorsten Glaser]

Hm.

According to upstream documentation, -EL is supposed to be supported
by the compiler driver:

https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#1050589: gcc-13: [x32] -fbuiltin-strchr miscompiles

[Thorsten Glaser]

Dixi quod…

>Package: gcc-13
>Version: 13.2.0-1

This is a regression against gcc-12 (= 12.3.0-8); if I install that
and export CC='diet -Os gcc-12' it works.

>./mksh -c 'x=q; x=${ echo a; typeset e=2; return 3; echo x$e;}; echo .$x.'

In case this is relevant: that codepath uses setjmp/longjmp quite a bit,
and builds for glibc, musl or klibc don’t trigger this, so it’s probably
a combination of several things. Using dietlibc/amd64 is also fine, and
dietlibc-wise, they are good as identical: differ only in start.S and
syscall numbers, and a few sections in header files.

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#1050589: gcc-13: [x32] -fbuiltin-strchr miscompiles

[Thorsten Glaser]

Package: gcc-13
Version: 13.2.0-1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

I've got miscompiles of mksh with gcc-13 on x32 with dietlibc.

I could reproduce this in a chroot by doing…

export CC='diet -Os gcc'
export CFLAGS='-g -Wformat -Werror=format-security -Wall -Wextra'
export CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2 -DMKSH_BUILDMEAT'
sh Build.sh -r -j
./mksh -c 'x=q; x=${ echo a; typeset e=2; return 3; echo x$e;}; echo .$x.'

… in an mksh source tree. (Output is “..” but “.a.” was expected.)

Adding -fno-builtin-strchr to CFLAGS makes the problem go away.

This is as far as I could reduce this; more would involve diving
into the gcc internals.


-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: x32 (x86_64)

Kernel: Linux 5.10.0-23-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages gcc-13 depends on:
ii  binutils   2.41-4
ii  cpp-13 13.2.0-1
ii  gcc-13-base13.2.0-1
ii  libc6  2.37-7
ii  libcc1-0   13.2.0-1
ii  libgcc-13-dev  13.2.0-1
ii  libgcc-s1  13.2.0-1
ii  libgmp10   2:6.3.0+dfsg-2
ii  libisl23   0.26-3
ii  libmpc31.3.1-1
ii  libmpfr6   4.2.0-1
ii  libstdc++6 13.2.0-1
ii  libzstd1   1.5.5+dfsg2-1
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages gcc-13 recommends:
ii  libc6-dev  2.37-7

Versions of packages gcc-13 suggests:
pn  gcc-13-doc   
pn  gcc-13-locales   
pn  gcc-13-multilib  

-- no debconf information

Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'

[Thorsten Glaser]

Package: musl-tools
Version: 1.2.3-1
Severity: serious
Justification: unusable on release architectures
X-Debbugs-Cc: t...@mirbsd.de, debian-gcc@lists.debian.org
Control: affects -1 src:mksh

Unsure if it’s musl or gcc-13_13.2.0-2 but building a simple
test program fails on both mips64el and mipsel:

$ musl-gcc […] -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -static  conftest.c
mipsel-linux-gnu-gcc: error: unrecognized command-line option '-EL'

If doing 'gcc -v' (normal gcc, not musl-gcc wrapper) the -EL shows up in:

COLLECT_GCC_OPTIONS='-g' '-O2' '-ffile-prefix-map=/<>=.' 
'-fstack-protector-strong' '-Wformat=1' '-Werror=format-security' '-Wall' 
'-Wextra' '-I' '.' '-I' '../..' '-Wdate-time' '-D' '_FORTIFY_SOURCE=2' '-D' 
'MKSH_EARLY_LOCALE_TRACKING' '-D' 'KSH_VERSIONNAME_VENDOR_EXT=" +Debian"' '-D' 
'MKSH_BUILDMEAT' '-D' 'MKSH_BUILDSH=1' '-D' '_GNU_SOURCE' '-D' 
'SETUID_CAN_FAIL_WITH_EAGAIN=1' '-v' '-march=mips32r2' '-mfpxx' '-mllsc' 
'-mno-lxc1-sxc1' '-mno-madd4' '-mips32r2' '-EL' '-mabi=32' '-dumpdir' 'a-'

musl-gcc uses mipsel-linux-gnu-gcc (or mips64el-linux-gnuabi64-gcc)
instead of gcc, but it’s still Debian 13.2.0-2 according to --version.

Bug#980770: libgcc-s2: file overwrite conflict with libgcc2

[Thorsten Glaser]

You probably didn’t get this as debbugs fails on d-ports-only
binary packages:

-- Forwarded message --
From: Thorsten Glaser 
Message-ID: 
To: sub...@bugs.debian.org
Date: Thu, 21 Jan 2021 21:27:37 + (UTC)
Subject: libgcc-s2: file overwrite conflict with libgcc2

Package: libgcc-s2
Version: 10.2.1-6

On upgrading an older (1 year or so) sid installation, I get this:

Preparing to unpack .../libgcc-s2_10.2.1-6_m68k.deb ...
Unpacking libgcc-s2:m68k (10.2.1-6) ...
dpkg: error processing archive 
/var/cache/apt/archives/libgcc-s2_10.2.1-6_m68k.deb (--unpack):
 trying to overwrite '/lib/m68k-linux-gnu/libgcc_s.so.2', which is also in 
package libgcc2:m68k 1:9.2.1-25
Errors were encountered while processing:
 /var/cache/apt/archives/libgcc-s2_10.2.1-6_m68k.deb

Bug#943393: closed by Matthias Klose (Bug#943393: fixed in gcc-9-cross 14)

[Thorsten Glaser]

On Sun, 27 Oct 2019, Debian Bug Tracking System wrote:

> #943393: gcc-9-cross: FTBFS: libatomic.so.1, needed by ./libgnat-9.so, not 
> found
> 
> It has been closed by Matthias Klose .

>   * Link libgnatvsn against libatomic.
>   

Doesn’t seem to help as gcc-9-cross-ports (11) with
gcc-9-source (9.2.1-15) still FTBFS the build in both
arch:all and arch:any variants:

/usr/hppa-linux-gnu/bin/ld: cannot find -latomic
 
collect2: error: ld returned 1 exit status  
 
libtool: install: error: relink `libgnatvsn.la' with the above command before 
installing it  

(Or the hppa libatomic.so is just missing.)

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#943487: libgcc-9-dev-sparc64-cross: (arch:all package) needs binNMU to make arch:any packages installable

[Thorsten Glaser]

Package: libgcc-9-dev-sparc64-cross
Version: 9.2.1-8cross1
Severity: important
Tags: ftbfs
Justification: keeps src:binutils in BD-Uninstallable

Dependency installability problem for [154]binutils on x32: 
 

 
binutils build-depends on:  
 
- [155]g++-sparc64-linux-gnu:x32
 
[156]g++-sparc64-linux-gnu depends on:  
 
- [157]g++-9-sparc64-linux-gnu:x32 (>= 9.2.1-1~)
 
[158]g++-9-sparc64-linux-gnu depends on:
 
- [159]gcc-9-sparc64-linux-gnu:x32 (= 9.2.1-12cross1)   
 
[160]gcc-9-sparc64-linux-gnu depends on missing:
 
- [161]libgcc-9-dev-sparc64-cross:x32 (>= 9.2.1-12cross1)   
 

This is because gcc-9-sparc64-linux-gnu is arch:any but
libgcc-9-dev-sparc64-cross is arch:all and thus not rebuilt
against the newer gcc-9-source package.

So either the arch:all packages need a binNMU or the entire
package a sourceful new upload.



-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages libgcc-9-dev-sparc64-cross depends on:
ii  gcc-9-cross-base-ports9.2.1-8cross1
ii  libasan5-sparc64-cross9.2.1-8cross1
ii  libatomic1-sparc64-cross  9.2.1-8cross1
ii  libgcc1-sparc64-cross 1:9.2.1-8cross1
ii  libgomp1-sparc64-cross9.2.1-8cross1
ii  libitm1-sparc64-cross 9.2.1-8cross1
ii  libubsan1-sparc64-cross   9.2.1-8cross1

Versions of packages libgcc-9-dev-sparc64-cross recommends:
pn  libc6-dev-sparc64-cross  

libgcc-9-dev-sparc64-cross suggests no packages.

-- no debconf information

Bug#943393: gcc-9-cross: FTBFS: libatomic.so.1, needed by ./libgnat-9.so, not found

[Thorsten Glaser]

Source: gcc-9-cross
Version: 12

With gcc-9-source (= 9.2.1-12), it still fails:

[…]
/usr/arm-linux-gnueabi/bin/ld: warning: libatomic.so.1, needed by 
./libgnat-9.so, not found (try using -rpath or 
-rpath-link)
 
/usr/arm-linux-gnueabi/bin/ld: ./libgnat-9.so: undefined reference to 
`__atomic_load_8@LIBATOMIC_1.0'
collect2: error: ld returned 1 exit status  
 
make[8]: *** [gcc-interface/Makefile:665: gnatlib-shared-default] Error 1   
 
make[8]: Leaving directory '/<>/gcc/build/gcc/ada' 
 
make[7]: *** [gcc-interface/Makefile:715: gnatlib-shared-dual] Error 2  
 
make[7]: Leaving directory '/<>/gcc/build/gcc/ada' 
 
make[6]: *** [gcc-interface/Makefile:810: gnatlib-shared] Error 2   
 
make[6]: Leaving directory '/<>/gcc/build/gcc/ada' 
 
make[5]: *** [Makefile:105: gnatlib-shared] Error 2 
 
make[5]: Leaving directory 
'/<>/gcc/build/arm-linux-gnueabi/libada'   
  
make[4]: *** [Makefile:17020: all-target-libada] Error 2
 
make[4]: *** Waiting for unfinished jobs
 
[…]

https://buildd.debian.org/status/fetch.php?pkg=gcc-9-cross&arch=x32&ver=12&stamp=1571881141&raw=0

Interestingly enough, this now seems to be an ARM problem, as
gcc-9-cross-ports (= 10) with the same gcc-9-source version has
built just fine.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#942059: gcc-9-cross: uses “long” as “time_t” leading to failure on most new 32-bit architectures

[Thorsten Glaser]

Control: reassign -1 src:gcc-9-cross
Control: found -1 12


On Thu, 10 Oct 2019, Matthias Klose wrote:

> Control: severity -1 important
> Control: reassign -1 src:gcc-9-cross-ports

No, this is wrong. It may fail in src:gcc-9-cross-ports (= 10)
as well (which it does according to
https://buildd.debian.org/status/package.php?p=gcc-9-cross-ports
anyway) but this report is about src:gcc-9-cross (= 12) which is
a blocker for building src:binutils:

https://buildd.debian.org/status/package.php?p=gcc-9-cross has
the build failure and…
   [51]Buildd exposure stats [52]x32  [53]↓ 12 [54]Build-Attempted 34d 9h 49m 
[55]x32-do-02 out-of-date
   misc [56]old | [57]all (1)
… and https://buildd.debian.org/status/package.php?p=binutils has:
   [133]Buildd exposure stats [134]x32 2.33.1-1 BD-Uninstallable 4h 34m 
out-of-date devel [135]old | no log

Dependency installability problem for [144]binutils on x32:

binutils build-depends on:
- [145]g++-x86-64-linux-gnu:x32
[146]g++-x86-64-linux-gnu depends on:
- [147]g++-9-x86-64-linux-gnu:x32 (>= 9.2.1-1~)
[148]g++-9-x86-64-linux-gnu depends on:
- [149]gcc-9-x86-64-linux-gnu:x32 (= 9.2.1-1cross1)
[150]gcc-9-x86-64-linux-gnu depends on missing:
- [151]libisl19:x32 (>= 0.15)

So this is about the cross compiler _from_ x32 _to_ amd64 (apparently)
which is src:gcc-9-cross, not src:gcc-9-cross-ports.

Please fix this in an upload RSN due to the binutils issue.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**

Bug#942059: gcc-9-cross: uses “long” as “time_t” leading to failure on most new 32-bit architectures

[Thorsten Glaser]

Source: gcc-9-cross
Version: 12
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)


x86_64-linux-gnux32-g++-9 -fno-PIE -c -g -I-I../../src/gcc/gm2 -Igm2 
-I../../src/gcc/gm2/gm2-gcc -Igm2/gm2-gcc   -g -O2 -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual-DHAVE_CONFIG_H -I. -Igm2 -I../../src/gcc -I../../src/gcc/gm2 
-I../../src/gcc/../include -I../../src/gcc/../libcpp/include  
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/bid 
-I../libdecnumber -I../../src/gcc/../libbacktrace   -I. -Igm2 -I../../src/gcc 
-I../../src/gcc/gm2 -I../../src/gcc/../include 
-I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber 
-I../../src/gcc/../libdecnumber/bid -I../libdecnumber 
-I../../src/gcc/../libbacktrace  ../../src/gcc/gm2/gm2-lang.c -o gm2/gm2-lang.o
../../src/gcc/gm2/m2.flex: In function 'void handleDate()':
../../src/gcc/gm2/m2.flex:354:24: error: cannot convert 'long int*' to 
'time_t*' {aka 'long long int*'}
  354 |   time_t  clock = time((long *)0);
  |^
  ||
  |long int*
In file included from ../../src/gcc/system.h:337,
 from ../../src/gcc/gm2/gm2-gcc/gcc-consolidation.h:23,
 from ../../src/gcc/gm2/m2.flex:22:
/usr/include/time.h:75:29: note:   initializing argument 1 of 'time_t 
time(time_t*)'
   75 | extern time_t time (time_t *__timer) __THROW;
  | ^~~
make[5]: *** [../../src/gcc/gm2/Make-lang.in:1124: 
gm2/gm2-compiler-boot/m2flex.o] Error 1

Bug#934837: gcc-doc-base: GCC 9 is now the default

[Thorsten Glaser]

Package: gcc-doc-base
Version: 8.3.0-1
Severity: important

Please bump gcc-doc-base to follow GCC 9, as gcc-defaults
has just done. Thanks!

-- System Information:
Debian Release: bullseye/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), 
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

-- no debconf information

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

[Thorsten Glaser]

Dear porters, could you please…

Matthias Klose dixit:

>Control: tags -1 + moreinfo
>
>please add the preprocessed source.

… because I’ve just seen this fail in the buildd QA.

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

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

[Thorsten Glaser]

Package: g++-8
Version: 8.3.0-7

https://buildd.debian.org/status/fetch.php?pkg=musescore-snapshot&arch=riscv64&ver=3.1%2Bdfsg1-1&stamp=1559616036&raw=0

Excerpt:

[…]
make[4]: Entering directory '/<>/obj-riscv64-linux-gnu'
[ 86%] Building CXX object 
mtest/zerberus/inputControls/CMakeFiles/tst_sfzinputcontrols.dir/tst_sfzinputcontrols.cpp.o
cd /<>/obj-riscv64-linux-gnu/mtest/zerberus/inputControls && 
/usr/bin/c++  -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_HELP_LIB 
-DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_PRINTSUPPORT_LIB 
-DQT_QML_LIB -DQT_QUICKWIDGETS_LIB -DQT_QUICK_LIB -DQT_SQL_LIB -DQT_SVG_LIB 
-DQT_TESTCASE_BUILDDIR=\"/<>/obj-riscv64-linux-gnu\" 
-DQT_TESTLIB_LIB -DQT_WIDGETS_LIB -DQT_XMLPATTERNS_LIB -DQT_XML_LIB 
-I/<>/obj-riscv64-linux-gnu/mtest/zerberus/inputControls 
-I/<>/mtest/zerberus/inputControls 
-I/<>/obj-riscv64-linux-gnu/mtest/zerberus/inputControls/tst_sfzinputcontrols_autogen/include
 -I/<>/obj-riscv64-linux-gnu -I/<> 
-I/usr/include/freetype2 -isystem /usr/include/riscv64-linux-gnu/qt5 -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/riscv64-linux-gnu/qt5/mkspecs/linux-g++ -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtGui -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtTest -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtQml -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtQuick -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtQuickWidgets -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtXml -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtXmlPatterns -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtSvg -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtSql -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtPrintSupport -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtConcurrent -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtOpenGL -isystem 
/usr/include/riscv64-linux-gnu/qt5/QtHelp  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security  -Wdate-time -D_FORTIFY_SOURCE=2  -DQT_NO_DEBUG 
-DNDEBUG -DMSCORE_NO_UPDATE_CHECKER -std=gnu++11 -fPIC-include all.h -D 
QT_GUI_LIB -D TESTROOT=\"/<>\" -g -Wall -Wextra -fPIC -std=gnu++11 
-o CMakeFiles/tst_sfzinputcontrols.dir/tst_sfzinputcontrols.cpp.o -c 
/<>/mtest/zerberus/inputControls/tst_sfzinputcontrols.cpp
c++: internal compiler error: Illegal instruction signal terminated program 
collect2
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** 
[mtest/zerberus/global/CMakeFiles/tst_sfzglobal.dir/build.make:126: 
mtest/zerberus/global/tst_sfzglobal] Error 4
[…]

Bug#904018: gcc-8: FTBFS on x32: hangs in the testsuite

[Thorsten Glaser]

found 904018 8.3.0-2
thanks

https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=x32&ver=8.3.0-2&stamp=1551277939&raw=0

I’ve again uploaded a “nocheck” build, to let the game continue,
but this ought to be eventually fixed.

Thanks,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Bug#918923: gcc-8: why build an hppa64 cross-compiler on x32?

[Thorsten Glaser]

Source: gcc-8
Version: 8.2.0-14
Severity: wishlist

Should it not be enough to provide it on hppa and _one_
not-ports architecture (either i386 or amd64)?

Bug#904018: gcc-8: FTBFS on x32: hangs in the testsuite (zombie child)

[Thorsten Glaser]

Dixi quod…

> but, at that point, 06-check-stamp was already written.
>
> Then, it hangs again.

Incidentally, killing it starts my cowbuilder hook which opens
up a shell in that chroot; at that point, build-arch was fully
done, which allowed a manual call to binary-arch to succeed (I
am going to upload it, as it’s better than the old gcc-8 binary
we have in d-ports right now, and the C/C++/etc. parts seem to
be good).

You might wish to see this:

Listing installed files not included in any package:
find debian/tmp ! -type d
debian/tmp/libx32
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/ieee_features.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/omp_lib_kinds.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/openacc_kinds.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/openacc_lib.h
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/openacc.f90
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/openacc.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/ieee_exceptions.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/omp_lib.f90
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/omp_lib.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/omp_lib.h
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/64/finclude/ieee_arithmetic.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/ieee_features.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/omp_lib_kinds.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/openacc_kinds.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/openacc_lib.h
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/openacc.f90
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/openacc.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/ieee_exceptions.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/omp_lib.f90
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/omp_lib.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/omp_lib.h
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/32/finclude/ieee_arithmetic.mod
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/include/ssp/unistd.h
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/include/ssp/ssp.h
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/include/ssp/string.h
debian/tmp/usr/lib/gcc/x86_64-linux-gnux32/8/include/ssp/stdio.h
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/opt.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/alloc.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/table.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/debug.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/atree.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/tree_in.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/csets.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/stand.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/snames.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/widechar.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/sinfo.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/fname.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/scans.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/xutil.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/sinput.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/uname.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/stringt.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/casing.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/uintp.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/sem_aux.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/gnatvsn.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/repinfo.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/lib.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/tree_io.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/elists.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/types.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/hostparm.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/namet.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/output.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/aspects.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/einfo.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/nlists.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/urealp.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/rident.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/ada/adalib/gnatvsn/krunch.ali
debian/tmp/usr/lib/x86_64-linux-gnux32/libgnatvsn.so
debian/tmp/usr/lib/x86_64-linux-gnux32/libstdc++.so.6.0.25-gdb.py
debian/tmp/usr/lib/x86_64-linux-gnux32/libssp.so.0
debian/tmp/usr/lib/x86_64-li

Bug#904018: gcc-8: FTBFS on x32: hangs in the testsuite (zombie child)

[Thorsten Glaser]

On Wed, 18 Jul 2018, Thorsten Glaser wrote:

> A system state inspection at the fail point shows an idle system
> and a hang here:
>
> tglase@tglase:~ $ ps axwww -O ppid | fgrep 18365
> 17623 18365 Z pts/600:00:00 [sh] 
> 18365 18342 S pts/600:00:00 expect -- /usr/share/dejagnu/runtest.exp 
> --tool libphobos --srcdir ../../../../src/libphobos/testsuite 
> --target_board=unix{,-fstack-protector}
> 20458 18365 S pts/600:10:16 
> /tmp/buildd/gcc-8-8.1.0/build/x86_64-linux-gnux32/libphobos/testsuite/../libdruntime/unittest_static
>  core.demangle
> 20462 18365 Z pts/600:00:00 [cat] 

At that time, killing the expect process (20458 is not
sufficient) lets the build continue for a while (partial
log attached), but then just hangs.

The hang is during “/usr/bin/make -j 8 -f debian/rules2 build-arch”,
but, at that point, 06-check-stamp was already written.

Then, it hangs again.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-develFAIL: libphobos.unittests/druntime/static/core.demangle
/bin/bash: line 4: 18365 CPU time limit exceeded (core dumped) $runtest --tool 
$tool --srcdir $srcdir --target_board=unix\{,-fstack-protector\}
make[6]: *** [Makefile:284: check-DEJAGNU] Error 1
make[6]: Leaving directory 
'/tmp/buildd/gcc-8-8.1.0/build/x86_64-linux-gnux32/libphobos/testsuite'
make[5]: *** [Makefile:328: check-am] Error 2
make[5]: Target 'check' not remade because of errors.
make[5]: Leaving directory 
'/tmp/buildd/gcc-8-8.1.0/build/x86_64-linux-gnux32/libphobos/testsuite'
make[5]: Entering directory 
'/tmp/buildd/gcc-8-8.1.0/build/x86_64-linux-gnux32/libphobos'
/usr/bin/make "AR_FLAGS=rc" "CC_FOR_BUILD=x86_64-linux-gnux32-gcc-8" 
"CC_FOR_TARGET=/tmp/buildd/gcc-8-8.1.0/build/./gcc/xgcc 
-B/tmp/buildd/gcc-8-8.1.0/build/./gcc/" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2 
-D_GNU_SOURCE" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" 
"GDC_FOR_TARGET=/tmp/buildd/gcc-8-8.1.0/build/./gcc/gdc 
-B/tmp/buildd/gcc-8-8.1.0/build/./gcc/" 
"GDC=/tmp/buildd/gcc-8-8.1.0/build/./gcc/gdc 
-B/tmp/buildd/gcc-8-8.1.0/build/./gcc/ -B/usr/x86_64-linux-gnux32/bin/ 
-B/usr/x86_64-linux-gnux32/lib/ -isystem /usr/x86_64-linux-gnux32/include 
-isystem /usr/x86_64-linux-gnux32/sys-include -isystem 
/tmp/buildd/gcc-8-8.1.0/build/sys-include   " "INSTALL=/usr/bin/install -c" 
"INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" 
"INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-Wl,-z,relro" "LIBCFLAGS=-g -O2" 
"LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=/usr/bin/make" "MAKEINFO=makeinfo 
--split-size=500 --split-size=500  " "PICFLAG=" "PICFLAG_FOR_TARGET=" 
"SHELL=/bin/bash" "RUNTESTFLAGS=--target_board=unix\{,-fstack-protector\}" 
"exec_prefix=/usr" "infodir=/usr/share/info" "libdir=/usr/lib" 
"includedir=/usr/include" "prefix=/usr" "tooldir=/usr/x86_64-linux-gnux32" 
"gdc_include_dir=/usr/lib/gcc/x86_64-linux-gnux32/8/include/d" 
"AR=x86_64-linux-gnux32-ar" "AS=/tmp/buildd/gcc-8-8.1.0/build/./gcc/as" 
"LD=/tmp/buildd/gcc-8-8.1.0/build/./gcc/collect-ld" 
"RANLIB=x86_64-linux-gnux32-ranlib" "NM=/tmp/buildd/gcc-8-8.1.0/build/./gcc/nm" 
"NM_FOR_BUILD=" "NM_FOR_TARGET=x86_64-linux-gnux32-nm" "DESTDIR=" "WERROR=" 
DO=all multi-do # /usr/bin/make
make[6]: Entering directory 
'/tmp/buildd/gcc-8-8.1.0/build/x86_64-linux-gnux32/libphobos'
if [ -z "64 32" ]; then \
  true; \
else \
  rootpre=`${PWDCMD-pwd}`/; export rootpre; \
  srcrootpre=`cd ../../../src/libphobos; ${PWDCMD-pwd}`/; export srcrootpre; \
  lib=`echo "${rootpre}" | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
  compiler="/tmp/buildd/gcc-8-8.1.0/build/./gcc/xgcc 
-B/tmp/buildd/gcc-8-8.1.0/build/./gcc/ -B/usr/x86_64-linux-gnux32/bin/ 
-B/usr/x86_64-linux-gnux32/lib/ -isystem /usr/x86_64-linux-gnux32/include 
-isystem /usr/x86_64-linux-gnux32/sys-include -isystem 
/tmp/buildd/gcc-8-8.1.0/build/sys-include   "; \
  for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
  true; \
else \
  if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; /usr/bin/make "AR_FLAGS=rc" 
"CC_FOR_BUILD=x86_64-linux-gnux32-gcc-8" 
"CC_FOR_TARGET=/tmp/buildd/gcc-8-8.1.0/buil

Bug#854061: [Debian-ports-devel] Bug#854061: Lack of hardening=+pie gives unwanted, unsilenceable noisy compiler output

[Thorsten Glaser]

James Clarke dixit:

>As far as I can tell, no progress has been made on this issue since the
>few discussions on debian-devel[0]. The current state is not desirable,

I agree. I think everyone agreed that GCC should handle hardening
and dpkg should not pass the -specs= stuff any longer.

>and in fact is causing at least one crucial package, cmake, to FTBFS

Indeed. I porter-uploaded it for x32 by downgrading dpkg first
which made the build succeed.

bye,
//mirabilos
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”

Bug#846214: gcc-6: wrong code generation in protobuf-c testsuite, adding printf works around

[Thorsten Glaser]

On Thu, 1 Dec 2016, Matthias Klose wrote:

> cool, thanks! bonus questions:
> 
>  - does the test pass with -O1, if yes can you identify
>the -O2 -fno-* flag?
>  - do the above with -O0

I’ll have to try, but I’m a bit out of time for the next
two to three days.

>  - do you get warnings when you run the test with
>the address and undefined sanitizers?

How do I do that?

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#846214: gcc-6: wrong code generation in protobuf-c testsuite, adding printf works around

[Thorsten Glaser]

On Thu, 1 Dec 2016, Thorsten Glaser wrote:

> OK. I’ve got it cut down, both regular and preprocessed
> versions are attached.

Attaching the .s output of the stripped-down version, both
unmodified and with the printf command changed. The diff
between them is not trivial, though.

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

x1.s.gz
Description: application/gzip


x2.s.gz
Description: application/gzip

Bug#846214: gcc-6: wrong code generation in protobuf-c testsuite, adding printf works around

[Thorsten Glaser]

tags 846214 - moreinfo
thanks

On Thu, 1 Dec 2016, Matthias Klose wrote:

>  - please could you reduce the test case to just run the failing test?

I’ll try…

>  - please add the preprocessed source

Attached from the following command:

gcc -DHAVE_CONFIG_H -I.  -include ./config.h -I./protobuf-c -I. -I. -Wdate-time 
-D_FORTIFY_SOURCE=2   -g -O2 -fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -E -o /tmp/x1.i t/generated-code2/test-generated-code2.c

The diff to the working version boils down to:

(pbuild15677)root@tglase:/tmp/buildd/protobuf-c-1.2.1 # diff -u /tmp/x?.i
--- /tmp/x1.i   2016-12-01 21:21:12.804468216 +
+++ /tmp/x2.i   2016-12-01 21:21:46.620862123 +
@@ -6429,7 +6429,7 @@
   if (memcmp (a.data, b.data, a.len) == 0) {
 return 1;
   } else {
-printf("E: memcmp unequal\n");
+printf("E: memcmp len=%zd unequal\n", a.len);
 return 0;
   }
 }

So, nothing changed in the preprocessed output.

>  - does this work with GCC 7?

I fail to see how this is relevant for a bugreport against GCC 6,
but… as it’s in experimental, I can try (7-20161125-1, as today’s
upload is still not built).

Compile commands are:

gcc-7 -DHAVE_CONFIG_H -I.  -include ./config.h -I./protobuf-c -I. -I. 
-Wdate-time -D_FORTIFY_SOURCE=2   -g -O2 
-fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -c -o t/generated-code2/test-generated-code2.o 
t/generated-code2/test-generated-code2.c
gcc-7 -g -O2 -fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -specs=/usr/share/dpkg/pie-link.specs -Wl,-z -Wl,relro 
-o t/generated-code2/.libs/test-generated-code2 
t/generated-code2/test-generated-code2.o t/test-full.pb-c.o 
t/test-optimized.pb-c.o  protobuf-c/.libs/libprotobuf-c.so

Yes, this fails just the same.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

x1.i.gz
Description: application/gzip

Bug#846214: gcc-6: wrong code generation in protobuf-c testsuite, adding printf works around

[Thorsten Glaser]

Package: gcc-6
Version: 6.2.1-5
Severity: important

The protobuf-c testsuite fails. More specifically, the attached
test-generated-code2.c file fails with the following output:

-begin output of unmodified code-
(pbuild3910)root@tglase:/tmp/buildd/protobuf-c-1.2.1 # make 
t/generated-code2/test-generated-code2
gcc -DHAVE_CONFIG_H -I.  -include ./config.h -I./protobuf-c -I. -I. -Wdate-time 
-D_FORTIFY_SOURCE=2   -g -O2 -fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -c -o t/generated-code2/test-generated-code2.o 
t/generated-code2/test-generated-code2.c
/bin/bash ./libtool  --tag=CC   --mode=link gcc   -g -O2 
-fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security  -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -o 
t/generated-code2/test-generated-code2 t/generated-code2/test-generated-code2.o 
t/test-full.pb-c.o t/test-optimized.pb-c.o protobuf-c/libprotobuf-c.la
libtool: link: gcc -g -O2 -fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -specs=/usr/share/dpkg/pie-link.specs -Wl,-z -Wl,relro 
-o t/generated-code2/.libs/test-generated-code2 
t/generated-code2/test-generated-code2.o t/test-full.pb-c.o 
t/test-optimized.pb-c.o  protobuf-c/.libs/libprotobuf-c.so
(pbuild3910)root@tglase:/tmp/buildd/protobuf-c-1.2.1 # 
t/generated-code2/test-generated-code2
Test: small enums...  done.
Test: big enums...  done.
Test: test field numbers...  done.
Test: test required int32...  done.
Test: test required sint32...  done.
Test: test required sfixed32...  done.
Test: test required int64...  done.
Test: test required sint64...  done.
Test: test required sfixed64...  done.
Test: test required uint32...  done.
Test: test required fixed32...  done.
Test: test required uint64...  done.
Test: test required fixed64...  done.
Test: test required float...  done.
Test: test required double...  done.
Test: test required bool...  done.
Test: test required TestEnumSmall...  done.
Test: test required TestEnum...  done.
Test: test required string...  done.
Test: test required bytes... test-generated-code2: 
t/generated-code2/test-generated-code2.c:418: test_required_bytes: Assertion 
`binary_data_equals (mess->test, bd_hello)' failed.
Aborted
-end output of unmodified code-

Adding a small patch…

--- t/generated-code2/test-generated-code2.c.orig0  2016-11-29 
10:16:32.138011287 +
+++ t/generated-code2/test-generated-code2.c.new1   2016-11-29 
10:17:41.554820423 +
@@ -98,7 +98,11 @@
 return 0;
   if (a.len == 0 && b.len == 0)
 return 1;
-  return memcmp (a.data, b.data, a.len) == 0;
+  if (memcmp (a.data, b.data, a.len) == 0) {
+return 1;
+  } else {
+return 0;
+  }
 }
 
 static protobuf_c_boolean

… does not change the output:

-begin output of modified (round 1) code-
(pbuild3910)root@tglase:/tmp/buildd/protobuf-c-1.2.1 # make 
t/generated-code2/test-generated-code2
gcc -DHAVE_CONFIG_H -I.  -include ./config.h -I./protobuf-c -I. -I. -Wdate-time 
-D_FORTIFY_SOURCE=2   -g -O2 -fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -c -o t/generated-code2/test-generated-code2.o 
t/generated-code2/test-generated-code2.c
/bin/bash ./libtool  --tag=CC   --mode=link gcc   -g -O2 
-fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security  -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -o 
t/generated-code2/test-generated-code2 t/generated-code2/test-generated-code2.o 
t/test-full.pb-c.o t/test-optimized.pb-c.o protobuf-c/libprotobuf-c.la
libtool: link: gcc -g -O2 -fdebug-prefix-map=/tmp/buildd/protobuf-c-1.2.1=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -specs=/usr/share/dpkg/pie-link.specs -Wl,-z -Wl,relro 
-o t/generated-code2/.libs/test-generated-code2 
t/generated-code2/test-generated-code2.o t/test-full.pb-c.o 
t/test-optimized.pb-c.o  protobuf-c/.libs/libprotobuf-c.so
(pbuild3910)root@tglase:/tmp/buildd/protobuf-c-1.2.1 # 
t/generated-code2/test-generated-code2
Test: small enums...  done.
Test: big enums...  done.
Test: test field numbers...  done.
Test: test required int32...  done.
Test: test required sint32...  done.
Test: test required sfixed32...  done.
Test: test required int64...  done.
Test: test required sint64...  done.
Test: test required sfixed64...  done.
Test: test required uint32...  done.
Test: test required fixed32...  done.
Test: test required uint64...  done.
Test: test required fixed64...  done.
Test: test required float...  done.
Test: test required double...  done.
Test: test required bool...  done.
Test: test r

Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Thorsten Glaser]

Guillem Jover dixit:

>> Yes, but they *do* break anything that
>> - acts on the CFLAGS (and LDFLAGS) variables
>> - uses klcc or other compiler wrappers that don't understand -specs
>> - uses clang or pcc or whatever other compilers
>
>The default dpkg build flags have always been tied to the specific
>language compiler version currently marked as the default (for C that
>would currently be gcc-6).

Sure, but we do have other compilers and compiler wrappers in the
archive, and packages are using them.

>As long as gcc enables PIE on a subset, there will be need to inject
>some form of specs on either subset of those arches, either on
>hardening=+pie or on hardening=-pie, pick yout poison. :(

[…]
>> Either are *much* better than the current way.
>
>Well you and me both, I'm just adapting the dpkg-buildflags to the
>current gcc situation. :/

This sounds to me like we should reassign this to GCC (and remove
all the… well, “offending”, no offence intended, code from dpkg).

>Having a subset of architectures is a pain for maintainers as they

True, so GCC should just enable it on all architectures where it
at all works.

>Well I think we should be enabling all hardening flags directly in
>gcc, but now that we have the specs files I guess it would not be
>too bad to enable them just in dpkg, but I agree either would be
>preferable. :/

OK, thank you.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Re: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Thorsten Glaser]

clone 845193 -1
reassign -1 dpkg
retitle -1 dpkg: please do not add -specs= flags only on some architectures
thanks

Guillem Jover dixit:

>> I cannot build openssl1.0 any longer. Downgrading all binary
>> packages from src:dpkg to 1.18.10 makes the build succeed.

Interestingly enough, src:openssl (1.1) works, so…

>So, I think I'll reassign this to openssl1.0, if no other feedback

… this is probably legit. But I would *still* like to raise
another point.

>Those specs files should make it possible to build stuff with PIE

Yes, but they *do* break anything that
- acts on the CFLAGS (and LDFLAGS) variables
- uses klcc or other compiler wrappers that don't understand -specs
- uses clang or pcc or whatever other compilers

Worse, they break *differently* on whether…

>Precisely to make the behavior consistent on all architectures, dpkg
>enables PIE (conditionally if no other flags marks it as to be
>disabled) on all architectures were gcc has not enabled this by
>default.

… that. And that is just plain wrong. Either dpkg should inject
-specs= stuff on all architectures or on none. Differing like this
just invites hidden and hard to track down bugs.

Please get an agreement with the GCC maintainer on how to proceed
from here.

Personally, I’d still prefer for GCC to behave as on other systems,
i.e. not to enable PIE by default, and to have it done completely
within dpkg, but I can *also* live with it being done exclusively
in GCC.

Either are *much* better than the current way.

>if no other feedback is provided showing that this is a problem in
>dpkg itself, such as PIE not working at all there, and a request to
>disable it for x32 in dpkg as non-functional.

This can be done just as well on the GCC side.

>Also BTW the gcc maintainer asked that porters
>interested could request PIE to be enabled by default in gcc.

What difference does it make on whether GCC or dpkg enables PIE?

The two last quote sections make it clear that any architecture
that currently has PIE enabled in dpkg should have it enabled in
GCC in the first place. (Did dpkg enable that on porters’ requests?
It does not look like that to me. This smells like overstepping
boundaries.)


tl;dr: I don’t care as much _which_ of GCC xor dpkg does it,
as long as only one does it. FFS, just enable it on all of them
unless known to absolutely not work; that’d still be better than
the current mess.

Thanks,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)

Bug#835148: Bug#837420: Bug#835148: please do not make GCC incompatible, we have dpkg-buildflags for this! (was Re: Bug#837420: Processed: PIE FTBFS are now RC)

[Thorsten Glaser]

Bálint Réczey dixit:

>AFAIK the linux package is the only problematic package were the
>maintainer refused to disable PIE from packaging scripts.

So, how are you supposed to do that now, instead of filtering
-fPIE from CFLAGS and -pie from LDFLAGS?

Christian/zumbi: do you take care of dietlibc, or should I?

Thanks,
//mirabilos
-- 
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.

Bug#835148: please do not make GCC incompatible, we have dpkg-buildflags for this! (was Re: Bug#837420: Processed: PIE FTBFS are now RC)

[Thorsten Glaser]

Adrian Bunk dixit:

>gcc-6 6.2.0-7 uploaded to unstable on Tue 18 Oct 2016 defaults to PIE,
>see #835148 for details.

Oh, thanks.

This is *so* *totally* the wrong approach, especially as we
have dpkg-buildflags, which was introduced *precisely* for
this purpose, and to make Debian’s GCC not incompatible even
more with the rest of the world.

Matthias, please do revert this.

Thanks,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#833505: Please update gcc-doc to stretch’s compiler now, kthx!

[Thorsten Glaser]

severity 794778 important
forcemerge 833505 794778
thanks

Hi,

can we *please* have the gcc-doc source package track gcc-defaults
more closely, especially considering that the gcc-X.Y-doc packages
are already there and it’s only updating the metapackage left…

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#833505: gcc-doc: please update to gcc-6-doc

[Thorsten Glaser]

Package: gcc-doc
Version: 5:4.9.2-1
Severity: important

Hi,

please update gcc-doc so it points to the documentation
for the version of GCC that’s to be released as the
default compiler for stretch.

Thanks!

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages gcc-doc depends on:
ii  gcc-4.9-doc  4.9.3-1

gcc-doc recommends no packages.

gcc-doc suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: package gcc-doc is not installed

Bug#780000: closed by Eduard Bloch (Bug#777753: fixed in apt-cacher-ng 0.8.1-1)

[Thorsten Glaser]

reopen 78
thanks

Debian Bug Tracking System dixit:

>Their explanation is attached below along with your original report.
>If this explanation is unsatisfactory and you have not received a
>better one in a separate message then please contact Eduard Bloch 
> by
>replying to this email.

This is nonsense, a bug in gcc cannot be closed by an apt-cacher-ng
upload as they are unrelated.

bye,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/pine.bsm.4.64l.1504102234140.2...@herc.mirbsd.org

Bug#780000: gcc-4.9: LTO makes the build unreproducible

[Thorsten Glaser]

Package: gcc-4.9
Version: 4.9.2-10
Severity: minor

With the attached file, or really any program (e.g. src:pax):

1$ gcc -O2 -g -fPIE -fstack-protector-strong -flto=jobserver -c bottles.c 
2$ gcc -O2 -g -fPIE -fstack-protector-strong -flto=jobserver -o x1 bottles.o
3$ gcc -O2 -g -fPIE -fstack-protector-strong -flto=jobserver -o x2 bottles.o
4$ md5sum x1 x2
9d58f432cfe6437fd83a807578400efe  x1
a57d1253be60b9a520c140e9c55e5b47  x2

Removing “-flto=jobserver” from line #1 (!) makes it succeed.
If LTO information is included in the object file, even not
using LTO during link (line #2 and #3) creates diverging output.

While I like the reproducible builds effort in Debian, I kinda
don’t want to eliminate LTO for it… though src:mksh hasn’t been
using LTO for a while, as it regularily breaks in newer versions
of GCC…

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages gcc-4.9 depends on:
ii  binutils2.25-5
ii  cpp-4.9 4.9.2-10
ii  gcc-4.9-base4.9.2-10
ii  libc6   2.19-15
ii  libcloog-isl4   0.18.2-1+b2
ii  libgcc-4.9-dev  4.9.2-10
ii  libgmp102:6.0.0+dfsg-6
ii  libisl100.12.2-2
ii  libmpc3 1.0.3-1
ii  libmpfr43.1.2-3
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages gcc-4.9 recommends:
ii  libc6-dev  2.19-15

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

-- no debconf information
/* $MirOS: contrib/hosted/tg/hellow/bottles.c,v 1.1 2011/04/02 19:49:44 tg Exp $ */

#include 

int
main(void)
{
	int b;

	for (b = 99; b >= 0; b--) {
		switch (b) {
		case 0:
			printf("No more bottles of beer on the wall, no more bottles of beer.\n");
			printf("Go to the store and buy some more, 99 bottles of beer on the wall.\n");
			break;
		case 1:
			printf("1 bottle of beer on the wall, 1 bottle of beer.\n");
			printf("Take one down and pass it around, no more bottles of beer on the wall.\n\n");
			break;
		default:
			printf("%d bottles of beer on the wall, %d bottles of beer.\n", b, b);
			printf("Take one down and pass it around, %d %s of beer on the wall.\n\n",
			b - 1, ((b - 1) > 1) ? "bottles" : "bottle");
			break;
		}
	}

	return (0);
}

Re: [m68k] preparing for GCC 4.9

[Thorsten Glaser]

(excluding d-release for what they hatingly call “debian-ports spam”)

Matthias Klose dixit:

>I would like to see some partial test rebuilds (like buildd or minimal chroot

Haven’t tried yet, but Helmut Grohne does automated rebootstrapping of
some ports using what he can get his hands on, and he said m68k was the
best-(cross)bootstrappable port, and was using gcc-4.9 for it, so there
are probably at least no ICEs.

If Helmut can publish the *.deb files that fall out of such a (cross)
rebootstrap, we could try debootstrapping (natively, in ARAnyM) from
them, then boot (a VM) into them, to check basic usage.

This sounds pretty few work.

Other than that… we’ve built src:gcc-4.9 now, which means that at least
the C/C-- part survives the three-stage bootstrap AFAICT.

>packages) for other architectures. Any possibility to setup such a test rebuild
>for some architectures by the porters? Afaics the results for the GCC testsuite
>look okish for every architecture.

… that runs it. I have no idea how to set up such a test rebuild
setup, but we have somewhat clonable VMs (and a VM base image that
“just” needs to be dist-upgraded to latest sid before using it),
so “anybody” can do that for m68k (provided they install the aranym
package from sid, as it contains FPU emulation bugfixes required by
Python 3.5 at least).

Also, I’d be interested in a way to run GCC’s testsuite against an
installed compiler, i.e. without taking the five days needed for the
bootstrap (plus adding dejagnu and removing disabling the testsuite
from the package rules) again.

bye,
//mirabilos
-- 
 Ich gebs zu, jupp ist cool
-- theftf zu Natureshadow beim Fixen von Debian


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/pine.bsm.4.64l.1405081543370.28...@herc.mirbsd.org

Re: gcc-4.9 uploaded to experimental

[Thorsten Glaser]

Yunqiang Su dixit:

>On Fri, Jan 10, 2014 at 7:23 PM, Matthias Klose  wrote:
>> gcc-4.9 is uploaded to experimental, asking the porters to watch for build
>> failures and corresponding patches. See

>The build log on mips64el can be found from:
>  http://mips64el.debian.net/attempted/gcc-4.9-mips64el.log.xz

m68k took a little longer, the full build log (cowbuilder, up-to-date
sid chroot, “nocheck”) is here:
http://www.freewrt.org/~tg/sink/gcc-4.9_4.9-20140109-1_m68k.build.xz

Tackling eglibc from experimental next… (we don’t have any buildds
for experimental, but I’ve got machines I can’t quickly make into
buildds, so cowbuilder it is).


Debian Ports Archive Maintainer dixit:

>Maintainer: Thorsten Glaser 
>Uploader: Thorsten Glaser (no PGP/MIME please, use Inline OpenPGP instead) 
>
>Host: leda.debian.net
>Accepted: gcc-4.9_4.9-20140109-1_m68k.changes
>Files:
>gcc-4.9-base_4.9-20140109-1_m68k.deb
>libgcc2_4.9-20140109-1_m68k.deb
>libgcc2-dbg_4.9-20140109-1_m68k.deb
>libgcc-4.9-dev_4.9-20140109-1_m68k.deb
>libgomp1_4.9-20140109-1_m68k.deb
>libgomp1-dbg_4.9-20140109-1_m68k.deb
>libatomic1_4.9-20140109-1_m68k.deb
>libatomic1-dbg_4.9-20140109-1_m68k.deb
>cpp-4.9_4.9-20140109-1_m68k.deb
>fixincludes_4.9-20140109-1_m68k.deb
>gobjc++-4.9_4.9-20140109-1_m68k.deb
>gobjc-4.9_4.9-20140109-1_m68k.deb
>libobjc4_4.9-20140109-1_m68k.deb
>libobjc4-dbg_4.9-20140109-1_m68k.deb
>libobjc-4.9-dev_4.9-20140109-1_m68k.deb
>gcj-4.9-jre-headless_4.9-20140109-1_m68k.deb
>libgcj15_4.9-20140109-1_m68k.deb
>libgcj15-awt_4.9-20140109-1_m68k.deb
>gcj-4.9-jre_4.9-20140109-1_m68k.deb
>gcj-4.9-jdk_4.9-20140109-1_m68k.deb
>libgcj15-dev_4.9-20140109-1_m68k.deb
>libgcj15-dbg_4.9-20140109-1_m68k.deb
>gcj-4.9_4.9-20140109-1_m68k.deb
>g++-4.9_4.9-20140109-1_m68k.deb
>libstdc++6_4.9-20140109-1_m68k.deb
>libstdc++-4.9-dev_4.9-20140109-1_m68k.deb
>libstdc++-4.9-pic_4.9-20140109-1_m68k.deb
>libstdc++6-4.9-dbg_4.9-20140109-1_m68k.deb
>libgfortran3_4.9-20140109-1_m68k.deb
>libgfortran3-dbg_4.9-20140109-1_m68k.deb
>libgfortran-4.9-dev_4.9-20140109-1_m68k.deb
>gfortran-4.9_4.9-20140109-1_m68k.deb
>gcc-4.9-plugin-dev_4.9-20140109-1_m68k.deb
>gcc-4.9_4.9-20140109-1_m68k.deb


bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (268 (291) bugs: 0 RC, 188 (204) I&N, 80 (87) M&W, 0 F&P)
‣ src:dash (89 (106) bugs: 2 RC, 43 (49) I&N, 44 (55) M&W, 0 F&P)
‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P, 1 gift)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1401131515310.25...@herc.mirbsd.org

Bug#730475: gcc-doc: Unable to find node referenced by `gcc-4.7' in `(dir)Top'.

[Thorsten Glaser]

Package: gcc-doc
Version: 5:4.8.0-1
Severity: normal

Hi,

after upgrading gcc-doc (with gcc-4.8-doc installed) and autoremoving
gcc-4.7-doc, “info gcc” no longer works:

「Unable to find node referenced by `gcc-4.7' in `(dir)Top'.」

I think you missed one place where the outdated gcc-4.7-doc is
referenced.

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

Kernel: Linux 3.11-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh

Versions of packages gcc-doc depends on:
ii  gcc-4.8-doc  4.8.2-1

gcc-doc recommends no packages.

gcc-doc suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20131125125124.28873.11556.report...@tglase-nb.lan.tarent.de

Bug#711558: PR52306 (was Re: Bug#711558: gcc-4.8: [m68k] patch set 2)

[Thorsten Glaser]

Matthias Klose dixit:

>I think, setting the flag for the option to 0 as the default, and
>applying this for m68k only would be the second best option, provided

Right…

>that you cannot find out how to implement Mikael's suggestion.

… but I think I know, generally, how to do that.
(Have been dealing with GCC’s ever-changing options subsystem
since 2.x times, in various BSDs mostly.)

Just ENOTIME right now. I’ll get back to you all.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1309011810210.27...@herc.mirbsd.org

Bug#711558: PR52306 (was Re: Bug#711558: gcc-4.8: [m68k] patch set 2)

[Thorsten Glaser]

Matthias Klose dixit:

>yes, I do reject this.

I see. Would you please…

>> “for the time being”? If so, would you accept a patch
>> that just disables -fauto-inc-dec on m68k *always*,
>> even in the cases where it doesn’t ICE? (one-liner)

answer whether this would be considerable? (Untested,
but should have the desired effect, right Mikael?)

--- a/src/gcc/common.opt
+++ b/src/gcc/common.opt
@@ -858,7 +858,7 @@ Common Report Var(flag_asynchronous_unwi
 Generate unwind tables that are exact at each instruction boundary
 
 fauto-inc-dec
-Common Report Var(flag_auto_inc_dec) Init(1)
+Common Report Var(flag_auto_inc_dec) Init(0)
 Generate auto-inc/dec instructions
 
 ; -fcheck-bounds causes gcc to generate array bounds checks.

Or maybe this one (although it’s got the malus that it can’t
be re-enabled for testing):

--- a/src/gcc/config/m68k/m68k.c
+++ b/src/gcc/config/m68k/m68k.c
@@ -663,6 +663,8 @@ m68k_override_options_after_change (void
   flag_schedule_insns_after_reload = 0;
   flag_modulo_sched = 0;
 }
+  /* PR52306 */
+  flag_auto_inc_dec = 0;
 }
 
 /* Generate a macro of the form __mPREFIX_cpu_NAME, where PREFIX is the

>not many thanks for trying to sneak in this into the
>Debian package.

I’m just forwarding what we use in production. This is
really necessary right now to work around bugs with the
GNU Chagrin Collection.

Apparently just always disabling optimisation is the
way, not just when it is problematic…

bye,
//mirabilos
-- 
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant.  Therefore you cannot use ' in a preproces-
sing file in c99 mode.  -- Ragge
No faith left in ISO C99, undefined behaviour, etc.


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.130817430.2...@herc.mirbsd.org

Bug#711558: gcc-4.8: [m68k] patch set 2

[Thorsten Glaser]

Hi!

Despite mentioning PR52306 in the changelog (as I did)
you seem to have rejected pr52306-retry-hack.diff which
is a bit unfortunate as we really need a workaround for
that ICE to build some things in the archive, e.g. Qt4,
Qt5 and anything using it, mcabber, etc.

Do you outright reject this patch even if it’s just
“for the time being”? If so, would you accept a patch
that just disables -fauto-inc-dec on m68k *always*,
even in the cases where it doesn’t ICE? (one-liner)

Please apply the attached patch for now, to fix this
documentation issue (and another one):

Index: debian/changelog
===
--- debian/changelog(revision 6947)
+++ debian/changelog(working copy)
@@ -17,7 +17,6 @@
 - m68k-revert-pr45144: Needed for Ada.
 - pr52714: Revert optimisation that breaks CC0 arch.
   * Fix PR49847 (Mikael Pettersson). Closes: #711558.
-  * Use -fno-auto-inc-dec for PR52306 (Mikael Pettersson).
 
  -- Matthias Klose   Wed, 21 Aug 2013 12:32:54 +0200
 
Index: debian/control.m4
===
--- debian/control.m4   (revision 6947)
+++ debian/control.m4   (working copy)
@@ -83,8 +83,8 @@
 ', `dnl
 Homepage: http://gcc.gnu.org/
 ')dnl SRCNAME
-XS-Vcs-Browser: http://svn.debian.org/viewsvn/gcccvs/branches/sid/gcc`'PV/
-XS-Vcs-Svn: svn://svn.debian.org/svn/gcccvs/branches/sid/gcc`'PV
+XS-Vcs-Browser: http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc`'PV/
+XS-Vcs-Svn: svn://anonscm.debian.org/svn/gcccvs/branches/sid/gcc`'PV
 
 ifelse(regexp(SRCNAME, `gcc-snapshot'),0,`dnl
 Package: gcc-snapshot`'TS



Thanks,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1308221927530.2...@herc.mirbsd.org

Bug#711558: gcc-4.8: [m68k] patch set 2

[Thorsten Glaser]

Matthias Klose dixit:

>Which of these are applied upstream, and if not, why?

libffi-m68k.diff is applied.

m68k-revert-pr45144.diff is not applied upstream yet,
maybe Mikael knows why?

pr49847.diff is not applied yet even though it seems
to be clear – I’ve prodded them again a month ago
and have not received any response yet; maybe just
nobody feels responsible?

pr52306-retry-hack.diff is not intended to ever be
applied upstream as-is (and depends on another Debian
patch) but only a stopgap allowing us to proceed to
compile things until the problem is fixed for real
(although we now at least seem to know where it is).

pr52714.diff is not applied yet because Mikael didn’t
submit it as he didn’t understand why the 4.6 version
of the code (which we revert to the 4.5 version) has
the problem, even though it definitely is an issue.

There’s also m68k-ada.diff in gcc in Debian already,
which will probably applied when it’s ready enough
and working with 4.8 (I think both Mikael upstream
and the GNAT people in Debian do most of the Ada
related work on 4.6), maybe in combination with the
pr49847.diff one?

bye,
//mirabilos

PS: Native compilation still running, looking good so far.
-- 
21:27⎜[Natureshadow] BÄH! Wer hatn das Bier neben den Notebooklüfter
 ⎜gestellt ... Das ist ja warm!
21:27⎜>Natureshadow< lol 21:27⎜>Natureshadow< du?
21:27⎜[Natureshadow] vermutlich ...   -- Kev^WNatureshadow allein zu Haus


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1308212303060.16...@herc.mirbsd.org

Bug#711558: gcc-4.8: [m68k] patch set 2

[Thorsten Glaser]

tags 711558 + patch
thanks

Hi,

this should do the trick, already tested the bugfix with
a cross-compiler.

Building src:gcc-4.8 on wheezy needs the -d dpkg-buildpackage
option though because the libcloog-isl-dev version is not
lowered down to 0.17 in wheezy (it does build and work with
-d though). Just in case you want to fix that, too.

bye,
//mirabilos
-- 
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh").  [aus dasr]diff -u gcc-4.8-4.8.1/debian/changelog gcc-4.8-4.8.1/debian/changelog
--- gcc-4.8-4.8.1/debian/changelog
+++ gcc-4.8-4.8.1/debian/changelog
@@ -1,3 +1,21 @@
+gcc-4.8 (4.8.1-9+m68k.2) unreleased; urgency=low
+
+  * Use -fno-auto-inc-dec for pr52306 (from Mikael Pettersson)
+
+ -- Thorsten Glaser   Sat, 17 Aug 2013 21:08:30 +0200
+
+gcc-4.8 (4.8.1-9+m68k.1) unreleased; urgency=high
+
+  * Merge several old m68k-specific patches from gcc-4.6 package:
+- libffi-m68k: rebased against gcc-4.8 and libffi 3.0.13-4
+- m68k-revert-pr45144: needed for Ada
+- pr52306-retry-hack: workaround for ICE in cselib_record_set
+- pr52714: revert optimisation that breaks CC0 arch
+  * Apply patch from Mikael Pettersson to fix PR49847.
+  * (Closes: #711558)
+
+ -- Thorsten Glaser   Sat, 17 Aug 2013 18:12:36 +
+
 gcc-4.8 (4.8.1-9) unstable; urgency=low
 
   * Update to SVN 20130815 (r201764) from the gcc-4_8-branch.
diff -u gcc-4.8-4.8.1/debian/rules.patch gcc-4.8-4.8.1/debian/rules.patch
--- gcc-4.8-4.8.1/debian/rules.patch
+++ gcc-4.8-4.8.1/debian/rules.patch
@@ -80,6 +80,8 @@
kfreebsd-unwind \
libgcc-no-limits-h \
kfreebsd-boehm-gc \
+   pr49847 \
+   libffi-m68k \
 
 #  $(if $(filter yes, $(DEB_CROSS)),,gcc-print-file-name) \
 #  libstdc++-nothumb-check \
@@ -193,6 +195,8 @@
 
 ifeq ($(DEB_TARGET_ARCH),m68k)
   debian_patches += m68k-ada
+  debian_patches += m68k-revert-pr45144
+  debian_patches += pr52714
 endif
 
 ifeq ($(DEB_TARGET_ARCH),powerpcspe)
@@ -245,6 +249,9 @@
 debian_patches += gcc-ice-hack gcc-ice-apport
 #FIXME
 #debian_patches += gold-and-ld
+ifeq ($(DEB_TARGET_ARCH),m68k)
+  debian_patches += pr52306-retry-hack
+endif
 
 debian_patches += libjava-fixed-symlinks
 debian_patches += libstdc++-arm-wno-abi
only in patch2:
unchanged:
--- gcc-4.8-4.8.1.orig/debian/patches/libffi-m68k.diff
+++ gcc-4.8-4.8.1/debian/patches/libffi-m68k.diff
@@ -0,0 +1,141 @@
+# DP: Apply #660525 fix to in-tree libffi
+
+--- a/src/libffi/src/m68k/sysv.S
 b/src/libffi/src/m68k/sysv.S
+@@ -2,9 +2,10 @@
+   
+sysv.S - Copyright (c) 2012 Alan Hourihane
+   Copyright (c) 1998, 2012 Andreas Schwab
+-  Copyright (c) 2008 Red Hat, Inc. 
+-   
+-   m68k Foreign Function Interface 
++  Copyright (c) 2008 Red Hat, Inc.
++      Copyright (c) 2012 Thorsten Glaser
++
++   m68k Foreign Function Interface
+ 
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+@@ -168,8 +169,28 @@ retstruct1:
+ 
+ retstruct2:
+   btst#7,%d2
+-  jbeqnoretval
++  jbeqretsint8
+   move.w  %d0,(%a1)
++  jbraepilogue
++
++retsint8:
++  btst#8,%d2
++  jbeqretsint16
++  | NOTE: On the mc68000, extb is not supported. 8->16, then 16->32.
++#if !defined(__mc68020__) && !defined(__mc68030__) && !defined(__mc68040__) 
&& !defined(__mc68060__) && !defined(__mcoldfire__)
++  ext.w   %d0
++  ext.l   %d0
++#else
++  extb.l  %d0
++#endif
++  move.l  %d0,(%a1)
++  jbraepilogue
++
++retsint16:
++  btst#9,%d2
++  jbeqnoretval
++  ext.l   %d0
++  move.l  %d0,(%a1)
+ 
+ noretval:
+ epilogue:
+@@ -201,8 +222,10 @@ CALLFUNC(ffi_closure_SYSV):
+   lsr.l   #1,%d0
+   jne 1f
+   jcc .Lcls_epilogue
++  | CIF_FLAGS_INT
+   move.l  -12(%fp),%d0
+ .Lcls_epilogue:
++  | no CIF_FLAGS_*
+   unlk%fp
+   rts
+ 1:
+@@ -210,6 +233,7 @@ CALLFUNC(ffi_closure_SYSV):
+   lsr.l   #2,%d0
+   jne 1f
+   jcs .Lcls_ret_float
++  | CIF_FLAGS_DINT
+   move.l  (%a0)+,%d0
+   move.l  (%a0),%d1
+   jra .Lcls_epilogue
+@@ -224,6 +248,7 @@ CALLFUNC(ffi_closure_SYSV):
+   lsr.l   #2,%d0
+   jne 1f
+   jcs .Lcls_ret_ldouble
++  | CIF_FLAGS_DOUBLE
+ #if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.d (%a0),%fp0
+ #else
+@@ -242,17 +267,37 @@ CALLFUNC(ffi_closure_SYSV):
+   jra .Lcls_epilogue
+ 1:
+   lsr.l   #2,%d0
+-  jne .Lcls_ret_struct2
++  jne 1f
+   jcs .Lcls_ret_struct1
++  | CIF_FLAGS_POINTER
+   move.l  (%a0),%a0
+   move.l  %a0,%d0
+   

Bug#711558: gcc-4.8: [m68k] hold applying this for now, we need more

[Thorsten Glaser]

tags 711558 - patch
thanks

It turns out we need to port more of the gcc-4.6 patches to
gcc-4.8 since we otherwise still hit some of the ICEs and
other bugs.

I’ll supply an updated debdiff soon (takes five days or so
to compile GCC, though).

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1308171718140.28...@herc.mirbsd.org

Bug#711558: Why not uploaded with 4.8.1-8 or 4.8.1-9 ?

[Thorsten Glaser]

ping?

//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1308151903290.28...@herc.mirbsd.org

Bug#717734: gcc-4.8: busy-spin building with LTO

[Thorsten Glaser]

Package: gcc-4.8
Version: 4.8.1-8
Severity: important

https://bugzilla.redhat.com/show_bug.cgi?id=922974
is now entering Debian, much to my joy (not).

Building mksh with “sh mksh/Build.sh -r -g -c lto”
(the “-c lto” is the trigger) lets the “link” not
succeed but instead busy-spin.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.10-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh

Versions of packages gcc-4.8 depends on:
ii  binutils2.23.52.20130722-1
ii  cpp-4.8 4.8.1-8
ii  gcc-4.8-base4.8.1-8
ii  libc6   2.17-7
ii  libcloog-isl4   0.18.0-2
ii  libgcc-4.8-dev  4.8.1-8
ii  libgmp102:5.1.2+dfsg-2
ii  libisl100.11.2-1
ii  libmpc3 1.0.1-1
ii  libmpfr43.1.1-1
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages gcc-4.8 recommends:
ii  libc6-dev  2.17-7

Versions of packages gcc-4.8 suggests:
ii  binutils [binutils-gold]  2.23.52.20130722-1
pn  gcc-4.8-doc   
pn  gcc-4.8-locales   
pn  gcc-4.8-multilib  
pn  libasan0-dbg  
pn  libatomic1-dbg
pn  libbacktrace1-dbg 
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  libmudflap0-4.8-dev   
pn  libmudflap0-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130724120930.20211.27566.report...@tglase.lan.tarent.de

Bug#711558: Fix for gcc-4.8: FTBFS on m68k: ICE compiling libjava/interpret.cc

[Thorsten Glaser]

tags 711558 + patch
thanks

Hi,

please apply this one, the failure in interpret.cc is gone,
and we apparently had a patch for this in 4.6 already.

gcc-4.8 (4.8.1-7+m68k.1) unreleased; urgency=low

  * Apply patch from Mikael Pettersson to fix PR49847. (Closes: #711558)

 -- Thorsten Glaser   Fri, 19 Jul 2013 13:10:43 +0200


diff -u gcc-4.8-4.8.1/debian/rules.patch gcc-4.8-4.8.1/debian/rules.patch
--- gcc-4.8-4.8.1/debian/rules.patch
+++ gcc-4.8-4.8.1/debian/rules.patch
@@ -81,6 +81,7 @@
kfreebsd-unwind \
libgcc-no-limits-h \
kfreebsd-boehm-gc \
+   pr49847 \
 
 #  $(if $(filter yes, $(DEB_CROSS)),,gcc-print-file-name) \
 #  libstdc++-nothumb-check \
only in patch2:
unchanged:
--- gcc-4.8-4.8.1.orig/debian/patches/pr49847.diff
+++ gcc-4.8-4.8.1/debian/patches/pr49847.diff
@@ -0,0 +1,28 @@
+gcc/
+
+2012-02-26  Mikael Pettersson  
+
+   PR rtl-optimization/49847
+   * cse.c (fold_rtx) : If prev_insn_cc0 is zero
+   don't call equiv_constant on it.
+
+--- a/src/gcc/cse.c
 b/src/gcc/cse.c
+@@ -3194,9 +3194,14 @@ fold_rtx (rtx x, rtx insn)
+ 
+ #ifdef HAVE_cc0
+ case CC0:
+-  folded_arg = prev_insn_cc0;
+-  mode_arg = prev_insn_cc0_mode;
+-  const_arg = equiv_constant (folded_arg);
++  if (!prev_insn_cc0)
++const_arg = 0;
++  else
++{
++  folded_arg = prev_insn_cc0;
++  mode_arg = prev_insn_cc0_mode;
++  const_arg = equiv_constant (folded_arg);
++}
+   break;
+ #endif
+ 

Thanks,
//mirabilos
-- 
17:08⎜«Vutral» früher gabs keine packenden smartphones und so
17:08⎜«Vutral» heute gibts frauen die sind facebooksüchtig
17:10⎜«Vutral» aber auch traurig; früher warst du als nerd voll am arsch
17:10⎜«Vutral» heute bist du als nerd der einzige der wirklich damit klarkommt


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1307232325300.26...@herc.mirbsd.org

Bug#707766: gcc-4.8: FTBFS on m68k: needs patch unfuzzing

[Thorsten Glaser]

Source: gcc-4.8
Version: 4.8.0-6
Severity: important
Tags: patch

Hi,

src:gcc-4.8 FTBFS on m68k because it fails to apply patches:

[…]
Applying patch gcc-d-lang.diff
patching file src/gcc/d/lang-specs.h
patching file src/gcc/d/lang.opt

Applying patch m68k-ada.diff
patching file src/gcc/ada/gcc-interface/Makefile.in
Hunk #1 FAILED at 1871.
1 out of 1 hunk FAILED -- rejects in file src/gcc/ada/gcc-interface/Makefile.in
patching 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 m68k-ada.diff does not apply (enforce with -f)
make: *** [stamps/02-patch-stamp] Error 1


I’ve noticed the same on i386 when running the following command:
debian/rules GCC_TARGET=m68k patch

(I expect the same patches to be applied for a cross-compiler to
Linux/m68k like for a native compiler on Linux/m68k.)

I’ve refreshed the patch in question and attached the result, but
I noticed that many patches apply only with offset or even quite
some fuzz (and, huh, quilt is colourful now!). I suggest that you
unfuzz all patches and then test, for every Debian architecture,
that they apply (like above), before the next upload.

Thanks!

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"--- gcc-4.8-4.8.0/debian/patches/m68k-ada.diff
+++ gcc-4.8-4.8.0/debian/patches/m68k-ada.diff
@@ -11,14 +11,13 @@
 	Add Gnat_Malloc -> __gnat_malloc export.
 	* s-memory.ads: Remove Alloc -> __gnat_malloc export.
 
-Index: gcc-4.6-4.6.3/src/gcc/ada/gcc-interface/Makefile.in
-===
 gcc-4.6-4.6.3.orig/src/gcc/ada/gcc-interface/Makefile.in	2012-03-04 16:06:01.0 +
-+++ gcc-4.6-4.6.3/src/gcc/ada/gcc-interface/Makefile.in	2012-03-04 16:06:49.0 +
-@@ -1871,6 +1871,34 @@
+--- a/src/gcc/ada/gcc-interface/Makefile.in
 b/src/gcc/ada/gcc-interface/Makefile.in
+@@ -1919,6 +1919,35 @@ ifeq ($(strip $(filter-out arm%-linux,$(
LIBRARY_VERSION := $(LIB_VERSION)
  endif
  
++# m68k Linux
 +ifeq ($(strip $(filter-out m68k% linux%,$(arch) $(osys))),)
 +  LIBGNAT_TARGET_PAIRS = \
 +  a-intnam.ads

Bug#660525: libffi_3.0.12~rc1-1

[Thorsten Glaser]

Dixi quod…

>libffi_3.0.12~rc1.orig.tar.gz/utar://libffi-3.0.12-rc1/testsuite/libffi.call/a.out

The RC built fine on m68k with only a small delta
in the symbols file by the way, thanks!

bye,
//mirabilos
-- 
 cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht noch 3 Jahre warten können?  bis dahin gibts google nicht
mehr  ja, könnte man meinen. wahrscheinlich ist der angekündigte welt-
untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum
müssen die die doodles vorher noch raushauen

libffi_3.0.12~rc1-1_m68k.build.gz
Description: Binary data

Bug#698380: gcc-4.6: [m68k] miscompiles pari

[Thorsten Glaser]

To be precise:

http://gcc.gnu.org/viewcvs/trunk/gcc/regrename.c?r1=195288&r2=195287&view=patch&pathrev=195288

That’s all we need ;-)

Thanks,
//mirabilos
-- 
„nein: BerliOS und Sourceforge sind Plattformen für Projekte, github ist
eine Plattform für Einzelkämpfer“
-- dieses Zitat ist ein Beweis dafür, daß auch ein blindes Huhn
   mal ein Korn findet, bzw. – in diesem Fall – Recht haben kann


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1301271826230.4...@herc.mirbsd.org

Bug#698380: [Bug target/56087] [m68k] gcc miscompiles pari (multiplication)

[Thorsten Glaser]

tags 698380 + patch fixed-upstream
thanks

mikpe at it dot uu.se dixit:

>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087

>Mikael Pettersson  changed:

>--- Comment #2 from Mikael Pettersson  2013-01-23 
>21:15:40 UTC ---
>(In reply to comment #0)

>This sounds a lot like PR52573, a patch was proposed in July 2012 and finally
>approved and committed a few days ago in r195288, see
>.

Thanks Mikael! @GCC developers, in this case sorry for the noise,
but you do have a better overview of possible causes.

Doko, could you please apply the aforementioned patch in your
next upload of gcc-4.6 to unstable?

Thanks in advance,
//mirabilos
-- 
 cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht noch 3 Jahre warten können?  bis dahin gibts google nicht
mehr  ja, könnte man meinen. wahrscheinlich ist der angekündigte welt-
untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum
müssen die die doodles vorher noch raushauen


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1301232209180.14...@herc.mirbsd.org

Bug#660525: libffi fixes for testsuite failures (bugs) on m68k and for bugs in testsuite

[Thorsten Glaser]

Anthony Green dixit:

>Thanks - I'll look at this later today.

Thanks for merging – looking good… see attached manual-build and
test log, with reproducer script.

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh+ cat ../libffi-13e2d7b92557a9511a0414df82bf2df3edc55cba
#!/bin/mksh
if [[ -z $1 ]]; then
mksh "$0" foo 2>&1 | tee "$0".log
exit
fi
set -x
cat "$0"
# sysinfo
uname -a
lsb_release -a
/lib/m68k-linux-gnu/libc.so.6
# build, mostly from the Debian package
eval $(dpkg-buildflags --export=sh)
export CC=cc CXX=c++ CCASFLAGS="$CFLAGS -Wa,--gdwarf2" LDFLAGS="-Wl,-z,defs 
$LDFLAGS"
$CC -v
mksh configure && make && make check
+ uname -a
Linux ara4.mirbsd.org 3.2.0-4-atari #1 Debian 3.2.35-2 m68k GNU/Linux
+ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 7.0 (wheezy)
Release:unstable
Codename:   sid
+ /lib/m68k-linux-gnu/libc.so.6
GNU C Library (Debian EGLIBC 2.13-38+m68k.1) stable release version 2.13, by 
Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.7.
Compiled on a Linux 3.2.35 system on 2012-12-31.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
Support for some architectures added on, not maintained in glibc core.
BIND-8.2.3-T5B
libc ABIs: UNIQUE
For bug reporting instructions, please see:
.
+ dpkg-buildflags --export=sh
+ eval export CFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 
-Wformat -Werror=format-security" export CPPFLAGS="-D_FORTIFY_SOURCE=2" export 
CXXFLAGS="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security" export FFLAGS="-g -O2" export LDFLAGS="-Wl,-z,relro"
+ export CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security export CPPFLAGS=-D_FORTIFY_SOURCE=2 export CXXFLAGS=-g 
-O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security export FFLAGS=-g -O2 export LDFLAGS=-Wl,-z,relro
+ export CC=cc CXX=c++ CCASFLAGS=-g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wa,--gdwarf2 
LDFLAGS=-Wl,-z,defs -Wl,-z,relro
+ cc -v
Using built-in specs.
COLLECT_GCC=cc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper
Target: m68k-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+m68k.3' 
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.6 --enable-shared --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object 
--disable-libssp --enable-plugin --enable-objc-gc --disable-werror 
--disable-multilib --enable-checking=release --build=m68k-linux-gnu 
--host=m68k-linux-gnu --target=m68k-linux-gnu
Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-14+m68k.3) 
+ mksh configure
checking build system type... m68k-unknown-linux-gnu
checking host system type... m68k-unknown-linux-gnu
checking target system type... m68k-unknown-linux-gnu
continue configure in default builddir "./m68k-unknown-linux-gnu"
exec /bin/sh ../configure "--srcdir=.." 
"--enable-builddir=m68k-unknown-linux-gnu" "linux gnu"
checking build system type... m68k-unknown-linux-gnu
checking host system type... m68k-unknown-linux-gnu
checking target system type... m68k-unknown-linux-gnu
checking for gsed... sed
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for gcc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of cc... gcc3
checking dependency style of cc... gcc3
checking whether cc understands -c and -o together... yes
checking how to prin

Bug#694112: Updated m68k patch bundle

[Thorsten Glaser]

Hi,

here’s the updated bundle (in case the unfreeze should happen).

New: backport of three trunk changes that speed up running
genattrtab from 4-6 *hours* to roughly THREE MINUTES (on my m68k
VM, which has about 188 BogoMIPS). This is applied generally,
as the GCC developers consider it safe.

Also: one more Ada fix, so shared libraries can actually be built.
(I kept all other Ada related changes in the gnat-4.6 package but
believe a generic two-way sync would be useful. I also looked at
gcj-4.6 but that can be replaced by just re-uploading gcc-4.6 with
a changed source package name in debian/control as it contains no
further changes.)

The patch is gzip’d due to a bug in debbugs that otherwise could
damage it. (And yes, despite all, I imported a couple of gcc-4.6
and gnat-4.6 debian/ trees into git and diffed things there…)

bye,
//mirabilos
-- 
I want one of these. They cost 720 € though… good they don’t have the HD hole,
which indicates 3½″ floppies with double capacity… still. A tad too much, atm.
‣ http://www.floppytable.com/floppytable-images-1.html

deb694112.diff.gz
Description: Binary data

Bug#660525: [PATCH] Fix libffi on m68k-linux-gnu, completely

[Thorsten Glaser]

Dixi quod…

>Hello Debian libffi maintainer, you will receive patches in a separate
>message against unstable (3.0.10) and experimental (3.0.11) as well as
>gcc-4.7 (uses something close to 3.0.10 but not quite).

OK, attached are:

• Patch against libffi from unstable
  ‣ symbols file change:
--- debian/libffi5.symbols.m68k (libffi5_3.0.10-3+m68k.4_m68k)
+++ dpkg-gensymbolsKl0ncP   2012-12-02 22:08:22.0 +
@@ -14,6 +14,7 @@
  ffi_prep_args@Base 3.0.4
  ffi_prep_cif@Base 3.0.4
  ffi_prep_cif_machdep@Base 3.0.4
+ ffi_prep_cif_var@Base 3.0.10-3+m68k.4
  ffi_prep_closure@Base 3.0.4
  ffi_prep_closure_loc@Base 3.0.4
  ffi_prep_java_raw_closure@Base 3.0.4

• Patch against libffi from experimental
  (with the caveat that I believe some testcases to be broken;
  the patch adds no new failures)

• Drop-in replacement for debian/patches/libffi-m68k.diff
  in gcc-4.7_4.7.2-12

I’m keeping the gcc-4.6 patch separate, as I’m currently
juggling a larger m68k related patchset, which I’ll post
occasionally to #694112 to be applied after the unfreeze.

>Andreas, I think you can commit the GCC side of the patch as well, so
>I’ll keep debian-68k on Cc for the followup message with them.

See above ;)

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh--- a/src/libffi/src/m68k/ffi.c
+++ b/src/libffi/src/m68k/ffi.c
@@ -107,6 +107,8 @@ ffi_prep_args (void *stack, extended_cif
 #define CIF_FLAGS_POINTER  32
 #define CIF_FLAGS_STRUCT1  64
 #define CIF_FLAGS_STRUCT2  128
+#define CIF_FLAGS_SINT8256
+#define CIF_FLAGS_SINT16   512
 
 /* Perform machine dependent cif processing */
 ffi_status
@@ -120,6 +122,13 @@ ffi_prep_cif_machdep (ffi_cif *cif)
   break;
 
 case FFI_TYPE_STRUCT:
+  if (cif->rtype->elements[0]->type == FFI_TYPE_STRUCT &&
+  cif->rtype->elements[1])
+{
+  cif->flags = 0;
+  break;
+}
+
   switch (cif->rtype->size)
{
case 1:
@@ -163,6 +172,14 @@ ffi_prep_cif_machdep (ffi_cif *cif)
   cif->flags = CIF_FLAGS_DINT;
   break;
 
+case FFI_TYPE_SINT16:
+  cif->flags = CIF_FLAGS_SINT16;
+  break;
+
+case FFI_TYPE_SINT8:
+  cif->flags = CIF_FLAGS_SINT8;
+  break;
+
 default:
   cif->flags = CIF_FLAGS_INT;
   break;
@@ -261,7 +278,8 @@ ffi_prep_closure_loc (ffi_closure* closu
  void *user_data,
  void *codeloc)
 {
-  FFI_ASSERT (cif->abi == FFI_SYSV);
+  if (cif->abi != FFI_SYSV)
+return FFI_BAD_ABI;
 
   *(unsigned short *)closure->tramp = 0x207c;
   *(void **)(closure->tramp + 2) = codeloc;
--- a/src/libffi/src/m68k/ffitarget.h
+++ b/src/libffi/src/m68k/ffitarget.h
@@ -34,8 +34,8 @@ typedef signed longffi_sarg;
 typedef enum ffi_abi {
   FFI_FIRST_ABI = 0,
   FFI_SYSV,
-  FFI_DEFAULT_ABI = FFI_SYSV,
-  FFI_LAST_ABI = FFI_DEFAULT_ABI + 1
+  FFI_LAST_ABI,
+  FFI_DEFAULT_ABI = FFI_SYSV
 } ffi_abi;
 #endif
 
--- a/src/libffi/src/m68k/sysv.S
+++ b/src/libffi/src/m68k/sysv.S
@@ -2,6 +2,7 @@

sysv.S - Copyright (c) 1998, 2012 Andreas Schwab
    Copyright (c) 2008 Red Hat, Inc. 
+   Copyright (c) 2012 Thorsten Glaser

m68k Foreign Function Interface 
 
@@ -153,8 +154,22 @@ retstruct1:
 
 retstruct2:
btst#7,%d2
-   jbeqnoretval
+   jbeqretsint8
move.w  %d0,(%a1)
+   jbraepilogue
+
+retsint8:
+   btst#8,%d2
+   jbeqretsint16
+   extb.l  %d0
+   move.l  %d0,(%a1)
+   jbraepilogue
+
+retsint16:
+   btst#9,%d2
+   jbeqnoretval
+   ext.l   %d0
+   move.l  %d0,(%a1)
 
 noretval:
 epilogue:
@@ -186,8 +201,10 @@ ffi_closure_SYSV:
lsr.l   #1,%d0
jne 1f
jcc .Lcls_epilogue
+   | CIF_FLAGS_INT
move.l  -12(%fp),%d0
 .Lcls_epilogue:
+   | no CIF_FLAGS_*
unlk%fp
rts
 1:
@@ -195,6 +212,7 @@ ffi_closure_SYSV:
lsr.l   #2,%d0
jne 1f
jcs .Lcls_ret_float
+   | CIF_FLAGS_DINT
move.l  (%a0)+,%d0
move.l  (%a0),%d1
jra .Lcls_epilogue
@@ -209,6 +227,7 @@ ffi_closure_SYSV:
lsr.l   #2,%d0
jne 1f
jcs .Lcls_ret_ldouble
+   | CIF_FLAGS_DOUBLE
 #if defined(__MC68881__) || defined(__HAVE_68881__)
fmove.d (%a0),%fp0
 #else
@@ -227,17 +246,31 @@ ffi_closure_SYSV:
jra .Lcls_epilogue
 1:
lsr.l   #2,%d0
-   jne .Lcls_ret_struct2
+   jne 1f
jcs .Lcls_ret_struct1
+   | CIF_FLAGS_POINTER
move.l  (%a0),%a0
move.l  %a0,%d0
  

Bug#660525: [PATCH] Fix libffi on m68k-linux-gnu, completely

[Thorsten Glaser]

Note: Doko and Andreas, you’re mentioned further below.


Andreas Schwab dixit:

>Alan Hourihane  writes:
>
>> Fixed the test, as it was broken.
>
>No, it isn't.

Hi you two, I’ve seen you fixed all failures than the (above discussed)
return_sc. I took care of that one today. (If I get my hands on the
person responsible for the lsr.l codepath, when the other routine uses
something so much easier to spot, thus being so temptingly easy, making
me not look harder… this cost me quite some time today!)

Hello libffi developers upstream, please do apply the attached patch
against git master, and then mark m68k-linux-gnu as working/tested
platform. I’m getting a full testsuite pass for both 3.0.10 with the
m68k code updated, and no new failures for 3.0.11 with the patch applied
although I believe some 3.0.11 checks to be broken:

The cls_uchar.c test has:

static void cls_ret_uchar_fn(ffi_cif* cif __UNUSED__, void* resp,
void** args, void* userdata __UNUSED__) {
*(ffi_arg*)resp = *(unsigned char *)args[0];

The cls_uchar_va.c test has (T expanded):

static void cls_ret_T_fn(ffi_cif* cif __UNUSED__, void* resp,
void** args, void* userdata __UNUSED__) {
*(unsigned char *)resp = *(unsigned char *)args[0];

Now, on big endian platforms, the result is quite different:

Assuming we call them with args[0]=0x7F, then:
Before: *(unsigned long *)resp = { 0x??, 0x??, 0x??, 0x?? }
After1: *(unsigned long *)resp = { 0x00, 0x00, 0x00, 0x7F }
After2: *(unsigned long *)resp = { 0x7F, 0x??, 0x??, 0x?? }

The failing tests are contributed by ARM, who are using
Little Endian, or so I’m told, so it’s no surprise they
didn’t notice. What’s the correct method to access *resp
in a closure, casting to the “real” return type or to an
ffi_arg pointer (the latter is used by all other/older
tests, i.e. all those predating arm64 support).

The failing tests (both before and after my patch) are:
libffi.call/cls_uchar_va.c cls_ushort_va.c va_1.c
The following exemplary patch makes one of them pass:
--- cls_uchar_va.c  2012-12-02 21:34:19.0 +
+++ cls_uchar_va2.c 2012-12-02 22:26:37.0 +
@@ -12,9 +12,9 @@
 static void cls_ret_T_fn(ffi_cif* cif __UNUSED__, void* resp, void** args,
 void* userdata __UNUSED__)
  {
-   *(T *)resp = *(T *)args[0];
+   *(ffi_arg *)resp = *(T *)args[0];
 
-   printf("%d: %d %d\n", *(T *)resp, *(T *)args[0], *(T *)args[1]);
+   printf("%d: %d %d\n", (int)(*(ffi_arg *)resp), *(T *)args[0], *(T 
*)args[1]);
  }
 
 typedef T (*cls_ret_T)(T, ...);


And, WTF: Why is there a .pc directory in the git repository?


Hello Debian libffi maintainer, you will receive patches in a separate
message against unstable (3.0.10) and experimental (3.0.11) as well as
gcc-4.7 (uses something close to 3.0.10 but not quite).

Andreas, I think you can commit the GCC side of the patch as well, so
I’ll keep debian-68k on Cc for the followup message with them.

bye,
//mirabilos
-- 
Darwinism never[…]applied to wizardkind. There's a more than fair amount of[…]
stupidity in its gene-pool[…]never eradicated[…]magic evens the odds that way.
It's[…]harder to die for us than[…]muggles[…]wonder if, as technology[…]better
[…]same will[…]happen there too. Dursleys' continued existence indicates so.From 9dd3345b2ef98b1fc18a1381cfe46b0381d71777 Mon Sep 17 00:00:00 2001
From: Thorsten Glaser 
Date: Sun, 2 Dec 2012 20:11:37 +
Subject: [PATCH] Fix 8-bit and 16-bit signed calls on m68k

Note: return_sc only tests 8-bit calls; I wrote myself a small
return_ss testcase which is the same except using signed short

TODO: src/m68k/sysv.S uses two different styles, one uses a
bit test command and simple jumps, the other rather convoluted
right-shifts through carry by two and three-way jumps. This
should be unified and documented better; also, the label naming
differs greatly between the call and the closure function.

Signed-off-by: Thorsten Glaser 
---
 src/m68k/ffi.c  |   10 ++
 src/m68k/sysv.S |   39 ---
 2 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/src/m68k/ffi.c b/src/m68k/ffi.c
index 37a0784..0dee938 100644
--- a/src/m68k/ffi.c
+++ b/src/m68k/ffi.c
@@ -123,6 +123,8 @@ ffi_prep_args (void *stack, extended_cif *ecif)
 #define CIF_FLAGS_POINTER  32
 #define CIF_FLAGS_STRUCT1  64
 #define CIF_FLAGS_STRUCT2  128
+#define CIF_FLAGS_SINT8256
+#define CIF_FLAGS_SINT16   512
 
 /* Perform machine dependent cif processing */
 ffi_status
@@ -200,6 +202,14 @@ ffi_prep_cif_machdep (ffi_cif *cif)
   cif->flags = CIF_FLAGS_DINT;
   break;
 
+case FFI_TYPE_SINT16:
+  cif->flags = CIF_FLAGS_SINT16;
+  break;
+
+case FFI_TYPE_SINT8:
+  cif->flags = CIF_FLAGS_SINT8;
+  break;
+
 default:
   cif->flags = CIF_FLAGS_INT;
   break;
diff --git a/src/m68k/sysv.S b/src/m68k/sysv.S
index f6f4ef9..4

Bug#693632: gcc-snapshot: depends on libc6-dev-x32 which is not in Debian

[Thorsten Glaser]

Package: gcc-snapshot
Version: 20121116-1
Severity: serious
Justification: uninstallable

tg@zigo:~ $ sudo apt-get --purge dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Starting
Starting 2
Investigating (0) gcc-snapshot [ amd64 ] < 20121106-1 -> 20121116-1 > ( devel )
Broken gcc-snapshot:amd64 Depends on libc6-dev-x32 [ amd64 ] < none > ( none ) 
(>= 2.11)
 Try to Re-Instate (1) gcc-snapshot:amd64
Done
Done
The following packages have been kept back:
  gcc-snapshot
The following packages will be upgraded:
[…]


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1211181958060.24...@herc.mirbsd.org

Re: RFH: compile-time assertions now broken in GCC

[Thorsten Glaser]

Matthias Klose dixit:

>I'll propose 4.7.2-4 for testing, so please update.

OK thanks for the heads-up, will do after I get over
the worst of this cold I caught.

>However I couldn't find the upstream GCC issue.

Didn’t report one yet, had too much dayjob-related
stuff to do this week. Will do.

bye,
//mirabilos
-- 
 Oh, ich hab mim Bauch Mittelklick gemacht, als ich nach dem
Kaffee gegriffen habe…
 Cool, ich hab ne neue eMail-Signatur
 Sag doch sowas nich, wenn ich den Kaffee in der Hand habe!
Gib mir nen Lappen! Schnell! Das kommt aber nicht mit in die Signatur!


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1210121402400.17...@herc.mirbsd.org

Re: RFH: compile-time assertions now broken in GCC

[Thorsten Glaser]

Matthias Klose dixit:

>how does gcc-snapshot behave?

It also introduces this failure.

>If you think it's a regression, please could you forward it upstream?

OK. In the meantime, I’ve prepared workarounds upstream (and
made the code a bit less depending on -fwrapv), but I need to
know whether I should upload mksh to sid now with the hotfix
applied to Ubuntu, i.e. whether you plan to have the affected
gcc versions migrate.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1210041655180.13...@herc.mirbsd.org

RFH: compile-time assertions now broken in GCC

[Thorsten Glaser]

Hi,

https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1058035
was just the beginning, as gcc-snapshot in Debian had it (I
wrote that in the bugreport already), but, now, gcc-4.{6,7}
in sid also have it.

I’ve just tracked it down for gcc-4.6 to have been introdu‐
ced between 4.6.3-9 and 4.6.3-10; gcc-4.7 as currently sits
in wheezy (4.7.1-7) doesn’t have the problem, 4.7.2-2 does.

tg@zigo:~/b $ cat t.c
#include 
typedef int32_t mksh_ari_t;
char ari_sign_32_bit_and_wrap[(

(mksh_ari_t)(mksh_ari_t)1 << 15) << 15) - 1) * 2 + 1) >
(mksh_ari_t)(mksh_ari_t)1 << 15) << 15) - 1) * 2 + 2)

) ? 1 : -1];

int main(void) { return (sizeof(ari_sign_32_bit_and_wrap)); }
tg@zigo:~/b $ gcc-4.6 -O -Wextra t.c
t.c:6:62: warning: integer overflow in expression [-Woverflow]
t.c:3:6: error: variably modified ‘ari_sign_32_bit_and_wrap’ at file scope

My question now is, how am I supposed to deal with that? Will
the affected gcc versions transition into wheezy? In that case
I’ll need to apply the hotfix I made for Ubuntu into Debian as
well, so I’d like an answer.

More generally, why does GCC suddenly break such compile-time
check constructs? (mksh guarantees to scripts it runs that all
arithmetic operations are 32-bit and that both signed and un‐
signed operations wrap around, so it *must* know whether the
system does that correctly. And its build script is cross-com‐
pile agnostic, so it doesn’t do run-time checks.)

Thanks in advance,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1210031354150.16...@herc.mirbsd.org

Bug#688330: gcc-4.7-base: WTF are you doing to the binary packages?

[Thorsten Glaser]

Philipp Kern dixit:

>I think you could work on your politeness and adjust the tone of your
>mails.

Right. I know that formulating is not one of my better skills.

>I don't think Matthias had an malicious intent here, to hurt you and
>induce suffering.

Yes, of course not.

>I think it was merely a
>human mistake of believing that a simple changelog mistake can be
>fixed after a quite long gcc build.

Well, this is not the first time I noticed it, and M-A only made it
visible. I cannot help but wonder what else things are done to the
packages that were not built from source. Of course, people uploading,
for example, binaries for multiple architectures at once are even more
suspicious (especially when the source FTBFS on all buildds then and it
doesn’t get fixed for weeks)…

I’m sorry Matthias for singling you out, but this was just an instance
where I noticed it as repeated issue with gcc-* packages. And, one has
to admit, wondering about the what-else is not _that_ far a mental jump.

(Especially after getting told off by the backports ftpmasters for
daring to upload a package built on a Xen or KVM, don’t remember,
guest. I’m now always taking care to build my packages for Debian
on bare metal and in as clean and minimal an environment as possible.)

bye,
//mirabilos
-- 
 Dann mach ich git annex copy --to shore und fertig ist das
 das ist ja viel cooler als ownCloud ...
 sag ich doch
 ja wieso stimmt das denn immer was du sagst ...


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1209211938230.28...@herc.mirbsd.org

Bug#688330: gcc-4.7-base: WTF are you doing to the binary packages?

[Thorsten Glaser]

Package: gcc-4.7-base
Version: 4.7.2-1
Severity: serious

I don’t quite can believe this. What the hey are you doing with
your binary packages you officially upload to Debian, to get THIS?

Fetched 187 MB in 49s (3766 kB/s)
Reading changelogs...
Extracting templates from packages: 100%
(Reading database ... 79415 files and directories currently installed.)
Preparing to replace gcc-4.7-base:amd64 4.7.1-9 (using 
.../gcc-4.7-base_4.7.2-1_amd64.deb) ...
De-configuring gcc-4.7-base:i386 ...
Unpacking replacement gcc-4.7-base:amd64 ...
Preparing to replace gcc-4.7-base:i386 4.7.1-9 (using 
.../gcc-4.7-base_4.7.2-1_i386.deb) ...
Unpacking replacement gcc-4.7-base:i386 ...
dpkg: error processing 
/var/cache/pbuilder/aptcache/gcc-4.7-base_4.7.2-1_i386.deb (--unpack):
 trying to overwrite shared '/usr/share/doc/gcc-4.7-base/changelog.Debian.gz', 
which is different from other instances of package gcc-4.7-base:i386
Errors were encountered while processing:
 /var/cache/pbuilder/aptcache/gcc-4.7-base_4.7.2-1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Oh, and indeed:

--- /tmp/clog-amd64 2012-09-21 17:28:40.002638617 +
+++ /tmp/clog-i386  2012-09-21 17:28:49.766650387 +
@@ -3,7 +3,6 @@
   * GCC 4.7.2 release.
   * Issues addressed after the release candidate:
 - PR c++/53661 (wrong warning), LTO backport from trunk, documentation fix.
-  * Update NEWS files.
 
  -- Matthias Klose   Thu, 20 Sep 2012 12:19:07 +0200
 

Really, why do you upload binary packages that are *obviously* not
built from the source package you upload?


Note to anyone whose Multi-Arch is suffering from this, and who run
into this issue, a quick hack/würgaround:

tg@zigo:~ $ sudo rm /usr/share/doc/gcc-4.7-base/changelog.Debian.gz
tg@zigo:~ $ sudo apt-get --purge -f install

bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (250 (270) bugs: 1 (2) RC, 175 (189) I&N, 74 (79) M&W, 0 F&P)
‣ src:dash (78 (90) bugs: 4 RC, 32 (36) I&N, 42 (50) M&W, 0 F&P)
‣ src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1209211728580.28...@herc.mirbsd.org

Bug#676569: gcc-4.7: -nostdlib broken, multiarch library path always added

[Thorsten Glaser]

Matthias Klose dixit:

>-nostdlib doesn't say anything about discarding the -L flags. Did this change
>with 4.7?

Hm, actually, it doesn’t.

What’s the option to do so, then? I have always been under the
impression that -nostdlib would include this behaviour.

bye,
//mirabilos
-- 
 ncal.c: In function 'parsemonth': warning: comparison between pointer
and integer  •  ↑ hab da „in function parselmouth“ gelesen
 ICH AUCH! •  Ich hab gerade gedacht "Häh? Wie,
hab da parselmouth gelesen ... steht da doch auch :o?"  -- too much fanfic…



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1206131350390.7...@herc.mirbsd.org

Bug#676569: gcc-4.7: -nostdlib broken, multiarch library path always added

[Thorsten Glaser]

Package: gcc-4.7
Version: 4.7.0-12
Severity: serious
Justification: breaks unrelated software

The following scenario is broken: I would expect the link to fail.
This is a carefully nailed-down testcase to figure out that the
fault is with gcc not binutils.

tg@zigo:~ $ echo 'int login_tty(int); void _exit(int); void _start() { 
_exit(login_tty(0)); }' >test.c
tg@zigo:~ $ rm -f test.out; gcc -nostdlib -lutil -o test.out test.c; ls -l 
test.out
-rwxr-xr-x 1 tg tg 3712 Jun  7 20:09 test.out

Reason behind this is that GNU autoconf generated configure scripts
(and other things like that) use such tests to check whether to add
libraries providing certain functionality to the build. Now if klibc
or dietlibc are used, you don't want to have libraries linked against
eglibc added to the build, as that will eventually fail. Figured this
out while trying to see whether jupp can be built with those libcs.

tg@zigo:~ $ gcc -nostdlib -lutil -o test.out test.c -v 2>&1 | tail -1
 /usr/lib/gcc/x86_64-linux-gnu/4.7/collect2 --sysroot=/ --build-id 
--no-add-needed --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker 
/lib64/ld-linux-x86-64.so.2 -o test.out -L/usr/lib/gcc/x86_64-linux-gnu/4.7 
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. -lutil /tmp/ccjpTrCm.o
tg@zigo:~ $ $(gcc -nostdlib -lutil -o test.out test.c -v -save-temps 2>&1 | 
tail -1) -t
/usr/bin/ld.bfd.real: mode elf_x86_64
-lutil (/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libutil.so)
test.o

Here ^ we see "nicely" how gcc is the culprit adding -L directives,
and that ld uses them at library resolution time.

tg@zigo:~ $ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.0-12' 
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs 
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.7 --enable-shared --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object 
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.0 (Debian 4.7.0-12)


-- System Information:
Debian Release: wheezy/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable'), (500, 'testing'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
m68k

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh

Versions of packages gcc-4.7 depends on:
ii  binutils  2.22-6.1
ii  cpp-4.7   4.7.0-12
ii  gcc-4.7-base  4.7.0-12
ii  libc6 2.13-33
ii  libgcc1   1:4.7.0-12
ii  libgmp10  2:5.0.5+dfsg-2
ii  libgomp1  4.7.0-12
ii  libitm1   4.7.0-12
ii  libmpc2   0.9-4
ii  libmpfr4  3.1.0-5
ii  libquadmath0  4.7.0-12
ii  zlib1g1:1.2.7.dfsg-11

Versions of packages gcc-4.7 recommends:
ii  libc6-dev  2.13-33

Versions of packages gcc-4.7 suggests:
pn  binutils-gold
pn  gcc-4.7-doc  
pn  gcc-4.7-locales  
pn  gcc-4.7-multilib 
pn  libgcc1-dbg  
pn  libgomp1-dbg 
pn  libitm1-dbg  
pn  libmudflap0-4.7-dev  
pn  libmudflap0-dbg  
pn  libquadmath0-dbg 

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120607201454.32745.51782.report...@zigo.mirbsd.org

Re: GCC 4.7 is now the default for x86 architectures

[Thorsten Glaser]

Matthias Klose dixit:

>GCC 4.7 is now the default for x86 architectures for all frontends except the D
>frontends, including KFreeBSD and the Hurd.

How are the plans for other architectures?

The m68k status (which obviously can’t influence the release decisions)
is as follows: gcc-4.7 builds, last time I looked gcj-4.7 didn’t but it
is currently building again (so let’s see whether it does this time);
gcc-4.6 and gnat-4.6 are getting development and bugfixes (I’ve queued
up some patches, but am not entirely ready with all of them, plus some
for binutils and gdb), and I’ve asked for help re. the gcj-4.4/gcj-4.6
recent problems. But nothing has tested gcj-4.7, and I fear of new and
old bugs… so I’d rather not switch default compiler to it anytime soon.

As for gcc-4.7 in general: a friend (authoring an ObjC framework _and_
runtime) told me that it dropped support for an old method of doing
things while not fulfilling the promise to get the new method of doing
it (don’t exactly remember what it was, /msg js on freenode for details)
fixed, with the effect that gobjc-4.7 is virtually useless/broken.

This is hearsay, but ask him for details, and check them against
reality.

bye,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1205071730550.28...@herc.mirbsd.org

Bug#670923: gcc-4.7-base: Multi-Arch breakage: differing content in shared files

[Thorsten Glaser]

Package: gcc-4.7-base
Version: 4.7.0-5
Severity: serious

Hi,

trying to upgrade my system breaks the package database, to a
point I have to uninstall all :i386 packages from the amd64
system… using dpkg, as apt goes on a strike.

tg@zigo:~ $ sudo apt-get --purge dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Starting
Starting 2
Done
Done
The following packages have been kept back:
  aranym
The following packages will be upgraded:
  cpp-4.6-m68k-linux-gnu cvs debootstrap diffutils dpkg dpkg-dev dselect 
gcc-4.6-m68k-linux-gnu
  gcc-4.6-m68k-linux-gnu-base gcc-4.7-base gcc-4.7-base:i386 gdb gdbserver 
ghostscript iceweasel iptables
  isc-dhcp-client isc-dhcp-common ksh lib32gcc1 lib32gomp1 lib32quadmath0 
lib32stdc++6 libc-bin libc-dev-bin
  libc6 libc6:i386 libc6-dev libc6-dev-i386 libc6-dev-m68k-cross libc6-i386 
libc6-m68k-cross libcairo2
  libconfig-inifiles-perl libdpkg-perl libgcc1 libgcc1:i386 libgcc2-m68k-cross 
libglib2.0-0 libgomp1
  libgomp1-m68k-cross libgs9 libgs9-common libmozjs10d libnet-ssleay-perl 
libnewt-dev libnewt0.52 libnss3-1d
  libpython2.7 libquadmath0 libslang2 libslang2-dev libssl-dev libssl1.0.0 
libstdc++6 libstdc++6-m68k-cross
  libtiff4 libusb-1.0-0 libx11-6 libx11-data libx11-xcb1 libxen-4.1 
libxenstore3.0 libxml2 libxml2-utils libxt6
  libxtst6 libxv1 libyaml-perl linux-libc-dev locales lsb-base lsb-release 
multiarch-support openssl
  python-decorator python2.7 python2.7-dev python2.7-minimal tex-common 
texlive-base texlive-common
  texlive-doc-base texlive-extra-utils texlive-font-utils 
texlive-fonts-recommended texlive-latex-base
  texlive-latex-extra texlive-latex-recommended texlive-pictures whiptail 
xulrunner-10.0
92 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 83.2 MB/172 MB of archives.
After this operation, 1836 kB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://ftp.fr.debian.org/debian/ sid/main gcc-4.7-base i386 4.7.0-5 [140 
kB]
Get:2 http://ftp.fr.debian.org/debian/ sid/main libgcc1 i386 1:4.7.0-5 [53.3 kB]
Get:3 http://ftp.fr.debian.org/debian/ sid/main libc6 i386 2.13-31 [3920 kB]
Get:4 http://ftp.fr.debian.org/debian/ sid/main libc6-dev-i386 amd64 2.13-31 
[1574 kB]
Get:5 https://www.freewrt.org/~tg/debs68k/ cross/main libc6-dev-m68k-cross all 
2.13-30 [1939 kB]
Get:6 http://ftp.fr.debian.org/debian/ sid/main libc6-i386 amd64 2.13-31 [4024 
kB]
Get:7 http://ftp.fr.debian.org/debian/ sid/main lib32stdc++6 amd64 4.7.0-5 [347 
kB]
Get:8 http://ftp.fr.debian.org/debian/ sid/main lib32quadmath0 amd64 4.7.0-5 
[198 kB]
Get:9 http://ftp.fr.debian.org/debian/ sid/main lib32gomp1 amd64 4.7.0-5 [30.0 
kB]
Get:10 http://ftp.fr.debian.org/debian/ sid/main lib32gcc1 amd64 1:4.7.0-5 
[53.1 kB]
Get:11 https://www.freewrt.org/~tg/debs68k/ cross/main libc6-m68k-cross all 
2.13-30 [1005 kB]
Get:12 http://ftp.fr.debian.org/debian/ sid/main libslang2-dev amd64 2.2.4-9 
[627 kB]
Get:13 http://ftp.fr.debian.org/debian/ sid/main libnewt-dev amd64 0.52.14-9 
[94.3 kB]
Get:14 http://ftp.fr.debian.org/debian/ sid/main libnewt0.52 amd64 0.52.14-9 
[73.6 kB]
Get:15 http://ftp.fr.debian.org/debian/ sid/main libx11-data all 2:1.4.99.901-2 
[186 kB]
Get:16 http://ftp.fr.debian.org/debian/ sid/main libx11-6 amd64 2:1.4.99.901-2 
[898 kB]
Get:17 http://ftp.fr.debian.org/debian/ sid/main libnss3-1d amd64 3.13.4-1 
[1309 kB]
Get:18 http://ftp.fr.debian.org/debian/ sid/main libusb-1.0-0 amd64 2:1.0.9-1 
[39.3 kB]
Get:19 http://ftp.fr.debian.org/debian/ sid/main libx11-xcb1 amd64 
2:1.4.99.901-2 [137 kB]
Get:20 http://ftp.fr.debian.org/debian/ sid/main libxv1 amd64 2:1.0.7-1 [21.6 
kB]
Get:21 http://ftp.fr.debian.org/debian/ sid/main iptables amd64 1.4.13-1.1 [402 
kB]
Get:22 http://ftp.fr.debian.org/debian/ sid/main isc-dhcp-client amd64 
4.2.2.dfsg.1-5 [795 kB]
Get:23 http://ftp.fr.debian.org/debian/ sid/main isc-dhcp-common amd64 
4.2.2.dfsg.1-5 [855 kB]
Get:24 http://ftp.fr.debian.org/debian/ sid/main whiptail amd64 0.52.14-9 [33.5 
kB]
Get:25 http://ftp.fr.debian.org/debian/ sid/main locales all 2.13-31 [5710 kB]
Get:26 http://ftp.fr.debian.org/debian/ sid/main cvs amd64 2:1.12.13+real-9 
[2755 kB]
Get:27 http://ftp.fr.debian.org/debian/ sid/main dselect amd64 1.16.3 [1079 kB]
Get:28 http://ftp.fr.debian.org/debian/ sid/main gdbserver amd64 7.4.1-1 [135 
kB]
Get:29 http://ftp.fr.debian.org/debian/ sid/main gdb amd64 7.4.1-1 [2436 kB]
Get:30 http://ftp.fr.debian.org/debian/ sid/main ghostscript amd64 9.05~dfsg-5 
[82.2 kB]
Get:31 http://ftp.fr.debian.org/debian/ sid/main libgs9 amd64 9.05~dfsg-5 [2316 
kB]
Get:32 http://ftp.fr.debian.org/debian/ sid/main libgs9-common all 9.05~dfsg-5 
[2187 kB]
Get:33 http://ftp.fr.debian.org/debian/ sid/main xulrunner-10.0 amd64 
10.0.4esr-2 [12.0 MB]
Get:34 http://ftp.fr.debian.org/debian/ sid/main libmozjs10d amd64 10.0.4esr-2 
[1497 kB]
Get:35 http://ftp.fr.debian.org/debian/ sid/main iceweasel amd64 10.0.4esr-2

Bug#670084: gcc-*: please allow cross-building for arbitrary GNU triplets

[Thorsten Glaser]

Source: gcc-4.6
Severity: wishlist

Hi,

while https://wiki.debian.org/BuildingCrossCompilers is an
invaluable help to people dabbling in such black art, but
wishing to do it “the proper Debian way”, it lacks a certain
functionality.

For example, if I want to build a cross-compiler to Debian/m68k,
I can use this for binutils:
|TARGET=$(dpkg-architecture -am68k -qDEB_HOST_GNU_TYPE 2>/dev/null)
(or just TARGET=m68k-linux-gnu of course)

But I need to use this for gcc-4.6:
|GCC_TARGET=m68k

Currently, reading the Debian gcc packaging, there seems to be no
way to create a cross-compiler the Debian way to something that is
not a Debian or Debian-Ports architecture.

I could probably register mint-m68k¹²³ with the dpkg developers, but
it would be more generically useful to just be able to tell it the
GNU triplet m68k-atari-mint and let GCC work with that (besides, the
package names are based on the triplets anyway).

① http://web.archive.org/web/20080517034704/http://debian-mint.nocrew.org/
② http://ftp.nocrew.org/pub/debian-mint/
③ Although I need the cross compiler to be able to compile a bootloader
  for the Atari to boot Linux on it (and as such must run on the native
  OS and be cross-built), not for continuing the Debian GNU/MiNT port.

bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (244 (263) bugs: 0 RC, 172 (186) I&N, 72 (77) M&W, 0 F&P)
‣ src:dash (75 (87) bugs: 3 RC, 31 (35) I&N, 41 (49) M&W, 0 F&P)
‣ src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P)
http://qa.debian.org/data/bts/graphs/d/dash.png is pretty red, innit?



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1204221933510.27...@herc.mirbsd.org

Bug#660525: [PATCH v2] libffi on m68k failures

[Thorsten Glaser]

Hi,

updated patch (from a commit to GCC’s libffi) attached.

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burrdiff -Nru libffi-3.0.11~rc1/debian/changelog libffi-3.0.11~rc1/debian/changelog
--- libffi-3.0.11~rc1/debian/changelog  2011-10-12 19:46:01.0 +
+++ libffi-3.0.11~rc1/debian/changelog  2012-03-04 15:40:31.0 +
@@ -1,3 +1,9 @@
+libffi (3.0.11~rc1-5+m68k.2) local; urgency=low
+
+  * Fix m68k floats (Andreas Schwab) and err_bad_abi (Alan Hourihane).
+
+ -- Thorsten Glaser   Sun, 04 Mar 2012 15:40:20 +
+
 libffi (3.0.11~rc1-5) experimental; urgency=low
 
   * Fix powerpc and ppc64 builds (Kyle Moffett).
diff -Nru libffi-3.0.11~rc1/debian/patches/m68k-fix.diff 
libffi-3.0.11~rc1/debian/patches/m68k-fix.diff
--- libffi-3.0.11~rc1/debian/patches/m68k-fix.diff  1970-01-01 
00:00:00.0 +
+++ libffi-3.0.11~rc1/debian/patches/m68k-fix.diff  2012-03-04 
15:40:16.0 +
@@ -0,0 +1,81 @@
+Index: libffi-3.0.11~rc1/src/m68k/ffi.c
+===
+--- libffi-3.0.11~rc1.orig/src/m68k/ffi.c  2011-07-28 19:45:45.0 
+
 libffi-3.0.11~rc1/src/m68k/ffi.c   2012-03-04 15:39:01.0 +
+@@ -261,7 +261,8 @@
+ void *user_data,
+ void *codeloc)
+ {
+-  FFI_ASSERT (cif->abi == FFI_SYSV);
++  if (cif->abi != FFI_SYSV)
++return FFI_BAD_ABI;
+ 
+   *(unsigned short *)closure->tramp = 0x207c;
+   *(void **)(closure->tramp + 2) = codeloc;
+Index: libffi-3.0.11~rc1/src/m68k/sysv.S
+===
+--- libffi-3.0.11~rc1.orig/src/m68k/sysv.S 2011-07-28 19:45:45.0 
+
 libffi-3.0.11~rc1/src/m68k/sysv.S  2012-03-04 15:39:55.0 +
+@@ -87,7 +87,7 @@
+ 
+   | If the return value pointer is NULL, assume no return value.
+   | NOTE: On the mc68000, tst on an address register is not supported.
+-#if defined(__mc68000__) && !defined(__mcoldfire__)
++#if !defined(__mc68020__) && !defined(__mc68030__) && !defined(__mc68040__) 
&& !defined(__mc68060__) && !defined(__mcoldfire__)
+   cmp.w   #0, %a1
+ #else
+   tst.l   %a1
+@@ -109,7 +109,7 @@
+ retfloat:
+   btst#2,%d2
+   jbeqretdouble
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.s %fp0,(%a1)
+ #else
+   move.l  %d0,(%a1)
+@@ -119,7 +119,7 @@
+ retdouble:
+   btst#3,%d2
+   jbeqretlongdouble
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.d %fp0,(%a1)
+ #else
+   move.l  %d0,(%a1)+
+@@ -130,7 +130,7 @@
+ retlongdouble:
+   btst#4,%d2
+   jbeqretpointer
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.x %fp0,(%a1)
+ #else
+   move.l  %d0,(%a1)+
+@@ -199,7 +199,7 @@
+   move.l  (%a0),%d1
+   jra .Lcls_epilogue
+ .Lcls_ret_float:
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.s (%a0),%fp0
+ #else
+   move.l  (%a0),%d0
+@@ -209,7 +209,7 @@
+   lsr.l   #2,%d0
+   jne 1f
+   jcs .Lcls_ret_ldouble
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.d (%a0),%fp0
+ #else
+   move.l  (%a0)+,%d0
+@@ -217,7 +217,7 @@
+ #endif
+   jra .Lcls_epilogue
+ .Lcls_ret_ldouble:
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.x (%a0),%fp0
+ #else
+   move.l  (%a0)+,%d0
diff -Nru libffi-3.0.11~rc1/debian/patches/series 
libffi-3.0.11~rc1/debian/patches/series
--- libffi-3.0.11~rc1/debian/patches/series 2011-10-07 10:06:54.0 
+
+++ libffi-3.0.11~rc1/debian/patches/series 2012-03-04 15:38:40.0 
+
@@ -3,3 +3,4 @@
 sparc-v8-fix.diff
 kfreebsd-config.diff
 powerpc-softfloat.diff
+m68k-fix.diff

[PATCH] backport PR47612 fix; unbreak DEB_BUILD_OPTIONS=nostrap

[Thorsten Glaser]

Hi,

please apply. This fixes what I believe an oversight that
broke DEB_BUILD_OPTIONS=nostrap, and backports an m68k fix
(actually, fix for all cc0 architectures) already in trunk
and probably soon in the 4.6 branch (while it does not fix
my Perl problem, it can apparently be hit in real life, as
the FreeMiNT people found).

Thanks,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burrdiff -u gcc-4.6-4.6.2/debian/rules2 gcc-4.6-4.6.2/debian/rules2
--- gcc-4.6-4.6.2/debian/rules2
+++ gcc-4.6-4.6.2/debian/rules2
@@ -522,7 +522,6 @@
 endif
   endif
 endif
-  bootstrap_target = bootstrap-lean
 
 DEJAGNU_TIMEOUT=300
 # Increase the timeout for one testrun on slow architectures
diff -u gcc-4.6-4.6.2/debian/rules.patch gcc-4.6-4.6.2/debian/rules.patch
--- gcc-4.6-4.6.2/debian/rules.patch
+++ gcc-4.6-4.6.2/debian/rules.patch
@@ -88,6 +88,7 @@
$(if $(with_linaro_branch),,pr49030) \
$(if $(with_linaro_branch),,pr50193) \
pr50114 \
+   pr47612 \
libffi-m68k \
 
 #  $(if $(filter yes, $(DEB_CROSS)),,gcc-print-file-name) \
diff -u gcc-4.6-4.6.2/debian/changelog gcc-4.6-4.6.2/debian/changelog
--- gcc-4.6-4.6.2/debian/changelog
+++ gcc-4.6-4.6.2/debian/changelog
@@ -1,3 +1,10 @@
+gcc-4.6 (4.6.2-16+m68k.1) unreleased; urgency=low
+
+  * Add patch from PR47612.
+  * Unbreak DEB_BUILD_OPTIONS=nostrap
+
+ -- Thorsten Glaser   Mon, 27 Feb 2012 19:55:10 +
+
 gcc-4.6 (4.6.2-16) unstable; urgency=medium
 
   * Update to SVN 20120223 (r184520) from the gcc-4_6-branch (4.6.3 release
only in patch2:
unchanged:
--- gcc-4.6-4.6.2.orig/debian/patches/pr47612.diff
+++ gcc-4.6-4.6.2/debian/patches/pr47612.diff
@@ -0,0 +1,29 @@
+# DP: Attachment 23909 to fix PR rtl-optimization/47612
+
+--- a/src/gcc/df-problems.c(revision 172094)
 b/src/gcc/df-problems.c(working copy)
+@@ -4001,7 +4001,10 @@ can_move_insns_across (rtx from, rtx to,
+ if (bitmap_intersect_p (merge_set, test_use)
+ || bitmap_intersect_p (merge_use, test_set))
+   break;
+-max_to = insn;
++#ifdef HAVE_cc0
++if (!sets_cc0_p (insn))
++#endif
++  max_to = insn;
+   }
+   next = NEXT_INSN (insn);
+   if (insn == to)
+@@ -4038,7 +4041,11 @@ can_move_insns_across (rtx from, rtx to,
+ {
+   if (NONDEBUG_INSN_P (insn))
+   {
+-if (!bitmap_intersect_p (test_set, local_merge_live))
++if (!bitmap_intersect_p (test_set, local_merge_live)
++#ifdef HAVE_cc0
++&& !sets_cc0_p (insn)
++#endif
++)
+   {
+ max_to = insn;
+ break;

Bug#658050: FTBFS: miniperl Out of memory during list extend at make_patchnum.pl line 126.

[Thorsten Glaser]

forwarded 658050 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52383
thanks

I’ve taken the time to track this down a little and forwarded
it upstream.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1202252250310.4...@herc.mirbsd.org

Bug#660525: libffi on m68k failures

[Thorsten Glaser]

Matthias Klose dixit:

> Please provide the patch for the version in experimental.

Sure. @porters: Similar to the sid version, we’re left with:

FAIL: libffi.call/nested_struct2.c -O0 -W -Wall execution test
FAIL: libffi.call/nested_struct2.c -O2 execution test
FAIL: libffi.call/return_sc.c -O2 execution test
FAIL: libffi.call/nested_struct2.c -O3 execution test
FAIL: libffi.call/return_sc.c -O3 execution test
FAIL: libffi.call/nested_struct2.c -Os execution test
FAIL: libffi.call/return_sc.c -Os execution test
FAIL: libffi.call/nested_struct2.c -O2 -fomit-frame-pointer execution test
FAIL: libffi.call/return_sc.c -O2 -fomit-frame-pointer execution test

And then, there’s…

dh_makeshlibs -plibffi6 --add-udeb=libffi6-udeb
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: debian/libffi6/DEBIAN/symbols doesn't match 
completely debian/libffi6.symbols.m68k
--- debian/libffi6.symbols.m68k (libffi6_3.0.11~rc1-5+m68k.1_m68k)
+++ dpkg-gensymbols0plREZ   2012-02-24 19:28:19.0 +
@@ -13,6 +13,7 @@
  ffi_prep_args@Base 3.0.4
  ffi_prep_cif@Base 3.0.4
  ffi_prep_cif_machdep@Base 3.0.4
+ ffi_prep_cif_var@Base 3.0.11~rc1-5+m68k.1
  ffi_prep_closure@Base 3.0.4
  ffi_prep_closure_loc@Base 3.0.4
  ffi_prep_java_raw_closure@Base 3.0.4

I’ve only built that for testing, not uploaded anything yet.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.rdiff -Nru libffi-3.0.11~rc1/debian/changelog libffi-3.0.11~rc1/debian/changelog
--- libffi-3.0.11~rc1/debian/changelog  2011-10-12 19:46:01.0 +
+++ libffi-3.0.11~rc1/debian/changelog  2012-02-24 18:29:49.0 +
@@ -1,3 +1,9 @@
+libffi (3.0.11~rc1-5+m68k.1) local; urgency=low
+
+  * Fix m68k floats (Andreas Schwab) and err_bad_abi (Alan Hourihane).
+
+ -- Thorsten Glaser   Fri, 24 Feb 2012 18:28:42 +
+
 libffi (3.0.11~rc1-5) experimental; urgency=low
 
   * Fix powerpc and ppc64 builds (Kyle Moffett).
diff -Nru libffi-3.0.11~rc1/debian/patches/m68k-fix.diff 
libffi-3.0.11~rc1/debian/patches/m68k-fix.diff
--- libffi-3.0.11~rc1/debian/patches/m68k-fix.diff  1970-01-01 
00:00:00.0 +
+++ libffi-3.0.11~rc1/debian/patches/m68k-fix.diff  2012-02-24 
18:28:08.0 +
@@ -0,0 +1,72 @@
+Index: libffi-3.0.11~rc1/src/m68k/ffi.c
+===
+--- libffi-3.0.11~rc1.orig/src/m68k/ffi.c  2011-07-28 19:45:45.0 
+
 libffi-3.0.11~rc1/src/m68k/ffi.c   2012-02-24 18:27:55.0 +
+@@ -261,7 +261,8 @@
+ void *user_data,
+ void *codeloc)
+ {
+-  FFI_ASSERT (cif->abi == FFI_SYSV);
++  if (cif->abi != FFI_SYSV)
++return FFI_BAD_ABI;
+ 
+   *(unsigned short *)closure->tramp = 0x207c;
+   *(void **)(closure->tramp + 2) = codeloc;
+Index: libffi-3.0.11~rc1/src/m68k/sysv.S
+===
+--- libffi-3.0.11~rc1.orig/src/m68k/sysv.S 2011-07-28 19:45:45.0 
+
 libffi-3.0.11~rc1/src/m68k/sysv.S  2012-02-24 18:27:03.0 +
+@@ -109,7 +109,7 @@
+ retfloat:
+   btst#2,%d2
+   jbeqretdouble
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.s %fp0,(%a1)
+ #else
+   move.l  %d0,(%a1)
+@@ -119,7 +119,7 @@
+ retdouble:
+   btst#3,%d2
+   jbeqretlongdouble
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.d %fp0,(%a1)
+ #else
+   move.l  %d0,(%a1)+
+@@ -130,7 +130,7 @@
+ retlongdouble:
+   btst#4,%d2
+   jbeqretpointer
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.x %fp0,(%a1)
+ #else
+   move.l  %d0,(%a1)+
+@@ -199,7 +199,7 @@
+   move.l  (%a0),%d1
+   jra .Lcls_epilogue
+ .Lcls_ret_float:
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.s (%a0),%fp0
+ #else
+   move.l  (%a0),%d0
+@@ -209,7 +209,7 @@
+   lsr.l   #2,%d0
+   jne 1f
+   jcs .Lcls_ret_ldouble
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.d (%a0),%fp0
+ #else
+   move.l  (%a0)+,%d0
+@@ -217,7 +217,7 @@
+ #endif
+   jra .Lcls_epilogue
+ .Lcls_ret_ldouble:
+-#if defined(__MC68881__)
++#if defined(__MC68881__) || defined(__HAVE_68881__)
+   fmove.x (%a0),%fp0
+ #else
+   move.l  (%a0)+,%d0
diff -Nru libffi-3.0.11~rc1/debian/patches/series 
libffi-3.0.11~rc1/debian/patches/series
--- libffi-3.0.11~rc1/debian/patches/series 2011-10-07 10:06:54.0 
+
+++ libffi-3.0.11~rc1/debian/patches/series 2012-02-2

Bug#660525: libffi on m68k failures

[Thorsten Glaser]

Source: libffi
Version: 3.0.10-3
Tags: patch

Hi,

please add this collection of patches to your next upload,
as it fixes some problems on m68k.

Thanks,
//mirabilos
-- 
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh").  [aus dasr]diff -u libffi-3.0.10/debian/changelog libffi-3.0.10/debian/changelog
--- libffi-3.0.10/debian/changelog
+++ libffi-3.0.10/debian/changelog
@@ -1,3 +1,15 @@
+libffi (3.0.10-3+m68k.2) unreleased; urgency=low
+
+  * Apply patch from Alan Hourihane to fix err_bad_abi testcase on m68k.
+
+ -- Thorsten Glaser   Mon, 16 Jan 2012 17:23:35 +
+
+libffi (3.0.10-3+m68k.1) unreleased; urgency=low
+
+  * Apply patch from Andreas Schwab to fix floats on m68k.
+
+ -- Thorsten Glaser   Sat, 14 Jan 2012 17:45:01 +
+
 libffi (3.0.10-3) unstable; urgency=low
 
   * Fix powerpc and ppc64 builds (Kyle Moffett).
only in patch2:
unchanged:
--- libffi-3.0.10.orig/src/m68k/sysv.S
+++ libffi-3.0.10/src/m68k/sysv.S
@@ -109,7 +109,7 @@
 retfloat:
btst#2,%d2
jbeqretdouble
-#if defined(__MC68881__)
+#if defined(__MC68881__) || defined(__HAVE_68881__)
fmove.s %fp0,(%a1)
 #else
move.l  %d0,(%a1)
@@ -119,7 +119,7 @@
 retdouble:
btst#3,%d2
jbeqretlongdouble
-#if defined(__MC68881__)
+#if defined(__MC68881__) || defined(__HAVE_68881__)
fmove.d %fp0,(%a1)
 #else
move.l  %d0,(%a1)+
@@ -130,7 +130,7 @@
 retlongdouble:
btst#4,%d2
jbeqretpointer
-#if defined(__MC68881__)
+#if defined(__MC68881__) || defined(__HAVE_68881__)
fmove.x %fp0,(%a1)
 #else
move.l  %d0,(%a1)+
@@ -199,7 +199,7 @@
move.l  (%a0),%d1
jra .Lcls_epilogue
 .Lcls_ret_float:
-#if defined(__MC68881__)
+#if defined(__MC68881__) || defined(__HAVE_68881__)
fmove.s (%a0),%fp0
 #else
move.l  (%a0),%d0
@@ -209,7 +209,7 @@
lsr.l   #2,%d0
jne 1f
jcs .Lcls_ret_ldouble
-#if defined(__MC68881__)
+#if defined(__MC68881__) || defined(__HAVE_68881__)
fmove.d (%a0),%fp0
 #else
move.l  (%a0)+,%d0
@@ -217,7 +217,7 @@
 #endif
jra .Lcls_epilogue
 .Lcls_ret_ldouble:
-#if defined(__MC68881__)
+#if defined(__MC68881__) || defined(__HAVE_68881__)
fmove.x (%a0),%fp0
 #else
move.l  (%a0)+,%d0
only in patch2:
unchanged:
--- libffi-3.0.10.orig/src/m68k/ffi.c
+++ libffi-3.0.10/src/m68k/ffi.c
@@ -261,7 +261,8 @@
  void *user_data,
  void *codeloc)
 {
-  FFI_ASSERT (cif->abi == FFI_SYSV);
+  if (cif->abi != FFI_SYSV)
+return FFI_BAD_ABI;
 
   *(unsigned short *)closure->tramp = 0x207c;
   *(void **)(closure->tramp + 2) = codeloc;

Bug#658050: FTBFS: miniperl Out of memory during list extend at make_patchnum.pl line 126.

[Thorsten Glaser]

Hi,

just found http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47612
by almost-accident (in the MiNT patch for gcc). It does not
seem to have been applied to the 4.6 branch yet; the MiNT
patch is against 4.6 and contains this.

I will test the patch from that PR in a local build and see
whether it fixes this problem. This mail is for the archives
and as a reminder to myself ;-)

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
-- me, wondering why it’s not Jerry Potter………



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1202182309210.5...@herc.mirbsd.org

Bug#633754: gcj-4.6: FTBFS on m68k with segfault

[Thorsten Glaser]

Comment #11 on the forwarded bug:

Andreas Schwab 2012-01-23 13:05:35 UTC 
After r183426 this is now dormant on the 4.6 branch again.

On the other hand, it happens on 4.7/trunk now. But it’s
been brought to upstream’s attention, and with the next
regular 4.6 branch pull we should get this workable in
Debian’s gcj-4.6 package, finally.

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1201271849310.25...@herc.mirbsd.org

Bug#651607: gcc-4.4: cross-compiler build broken, cannot find its headers

[Thorsten Glaser]

Hi,

nevermind (close if you want), gcc-4.6 builds a cross-compiler
just fine, and since m68k was switched there anyway (looking
good so far) I’m building that now instead.

gn8,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1112152308580@herc.mirbsd.org

Bug#633479: status? gcc-4.6: ICE on armel+armhf

[Thorsten Glaser]

Hi,

what’s the status on this? I’m considering an NMU if this
does not get fixed some time soon.

(Thanks Héctor for validating the backport.)

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.302210060.12...@herc.mirbsd.org

Bug#650145: dpkg-shlibdeps warning about gcc-added library (LTO)

[Thorsten Glaser]

Source: gcc-4.6
Severity: minor

(@Bernhard: /dpkg-shlibdeps: warning: dependency on.*could be 
avoided.*uselessly linked/)

I’ve just spotted this in the build logs:

dpkg-shlibdeps: warning: dependency on libgcc_s.so.1 could be avoided if 
"debian/mksh/bin/mksh" were not uselessly linked against it (they use none of 
its symbols).

This could, by the way, be used in the new checker. Anyway,
thing is, mksh doesn’t use libgcc_s or request any function
from it specifically; the dependency is added by gcc itself
and this should be fixed there.

The link command used is:

gcc -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Wformat-security -Werror=format-security -Wall -Wextra
-fno-strict-aliasing -fstack-protector-all -fwrapv -flto=jobserver
-std=gnu99 -fPIE -pie -Wl,-z,relro -Wl,-z,now -fuse-linker-plugin
-o mksh  lalloc.o edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o
lex.o main.o misc.o shf.o syn.o tree.o var.o strlcpy.o printf.o

Looking at “gcc -dumpspecs”, I see this though:

*libgcc:
%{static|static-libgcc:-lgcc 
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared-libgcc:-lgcc --as-needed -lgcc_s 
--no-as-needed}%{shared-libgcc:-lgcc_s%{!shared: -lgcc

No explicit -shared-libgcc here (from me, at least.) This would have
been the logic place to fix this.

Running this (in a sid/i386 chroot) on a Hello World programme I get
the same result. Adding -v shows the possible culprit to be:
-plugin-opt=-pass-through=-lgcc_s
Actually, -Wl,-v is more legible and shows:
/usr/bin/ld -plugin /usr/lib/gcc/i486-linux-gnu/4.6/liblto_plugin.so 
-plugin-opt=/usr/lib/gcc/i486-linux-gnu/4.6/lto-wrapper 
-plugin-opt=-fresolution=/tmp/ccflfrHu.res -plugin-opt=-pass-through=-lgcc 
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc 
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id 
--no-add-needed --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker 
/lib/ld-linux.so.2 -pie -o t 
/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/Scrt1.o 
/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/crti.o 
/usr/lib/gcc/i486-linux-gnu/4.6/crtbeginS.o -L/usr/lib/gcc/i486-linux-gnu/4.6 
-L/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu 
-L/usr/lib/gcc/i486-linux-gnu/4.6/../../../../lib -L/lib/i386-linux-gnu 
-L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib 
-L/usr/lib/gcc/i486-linux-gnu/4.6/../../.. -z relro -z now t.o -v -lgcc 
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed 
/usr/lib/gcc/i486-linux-gnu/4.6/crtendS.o 
/usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/crtn.o

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.262337350.28...@herc.mirbsd.org

Bug#647553: apparently fixed

[Thorsten Glaser]

fixed 647553 4.6.2-3
close 647553
thanks

[…]
gcc -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Wformat-security -Werror=format-security -Wall -Wextra -fno-strict-aliasing 
-fstack-protector-all -fwrapv -flto=jobserver -std=gnu99 -fPIE -pie 
-Wl,-z,relro -Wl,-z,now -fuse-linker-plugin -o mksh  lalloc.o edit.o eval.o 
exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o syn.o tree.o 
var.o strlcpy.o printf.o  || for _f in ${tcfn}*; do test x"${_f}" = x"mksh.1" 
|| rm -f "${_f}"; done
edit.o (symbol from plugin): warning: memset used with constant zero length 
parameter; this could be due to transposed parameters
size mksh
   textdata bss dec hex filename
 2914973768   20984  316249   4d359 mksh
[…]
(sid)tg@sperger:~/mksh-40.2$ ./test.sh -v
[…]
Total failed: 0
Total passed: 410
(sid)tg@sperger:~/mksh-40.2$ gcc -v
[…]
gcc version 4.6.2 (Debian 4.6.2-3)

bye,
//mirabilos
-- 
08:05⎜ mika: Does grml have an tool to read Apple
 ⎜System Log (asl) files? :)
08:08⎜ yeah. /bin/rm. ;)   08:09⎜ hexdump -C
08:31⎜ ft, mrud: *g*



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.091929330.9...@herc.mirbsd.org

Bug#647553: gcc-4.6: fails LTO with PIE: sparc_get_pc_thunk referenced in .text, defined in discarded section

[Thorsten Glaser]

Package: gcc-4.6
Version: 4.6.1-13
Severity: important

Currently, compiling mksh with hardening enabled breaks on sparc (debian)
and sparc64 (debian-ports) with identical problems. I tracked this down to
the use of PIE in the final link (not object file generation) in combina-
tion with LTO using the linker plugin.

It boils down to this:

gcc -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Wformat-security -Werror=format-security -Wall -Wextra -fno-strict-aliasing 
-fstack-protector-all -fwrapv -flto=jobserver -std=gnu99 -fPIE -pie 
-Wl,-z,relro -Wl,-z,now -fuse-linker-plugin -o mksh  lalloc.o edit.o eval.o 
exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o syn.o tree.o 
var.o strlcpy.o printf.o  || for _f in ${tcfn}*; do test x"${_f}" = x"mksh.1" 
|| rm -f "${_f}"; done
edit.o (symbol from plugin): warning: memset used with constant zero length 
parameter; this could be due to transposed parameters
`__sparc_get_pc_thunk.l7' referenced in section `.text' of 
/tmp/ccx38SGj.ltrans21.ltrans.o: defined in discarded section 
`.text.__sparc_get_pc_thunk.l7.2528[__sparc_get_pc_thunk.l7.2528]' of 
/tmp/ccx38SGj.ltrans21.ltrans.o
`__sparc_get_pc_thunk.l7' referenced in section `.text' of 
/tmp/ccx38SGj.ltrans26.ltrans.o: defined in discarded section 
`.text.__sparc_get_pc_thunk.l7.2625[__sparc_get_pc_thunk.l7.2625]' of 
/tmp/ccx38SGj.ltrans26.ltrans.o
collect2: ld returned 1 exit status

Omitting either (a) -fPIE (twice) and -pie (once), or (b) -flto=jobserver
and -fuse-linker-plugin (both once), lets the link succeed with the binary
result being usable. (To fully test it, run './test.sh -v' afterwards.)

I’ve included detailed reproduction instructions using a Debian porterbox;
also note the warning about memset in edit.o that disappears when not using
LTO (I’ve been unable to find such use in the source code, so I assume it
must be compiler-emitted), but that’s not a cause of the breakage (as I’ve
seen it happen on platforms where mksh builds fine, too):


tg@sperger:~$ dget 
http://ftp.de.debian.org/debian/pool/main/m/mksh/mksh_40.2-3.dsc
dget: retrieving 
http://ftp.de.debian.org/debian/pool/main/m/mksh/mksh_40.2-3.dsc
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  1926  100  19260 0  11862  0 --:--:-- --:--:-- --:--:-- 15165
dget: retrieving 
http://ftp.de.debian.org/debian/pool/main/m/mksh/mksh_40.2.orig.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  319k  100  319k0 0  1156k  0 --:--:-- --:--:-- --:--:-- 1258k
dget: retrieving 
http://ftp.de.debian.org/debian/pool/main/m/mksh/mksh_40.2-3.diff.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 95334  100 953340 0   541k  0 --:--:-- --:--:-- --:--:--  629k
dscverify: can't find any Debian keyrings
tg@sperger:~$ dpkg-source -x mksh_40.2-3.dsc
gpgv: keyblock resource `/home/tg/.gnupg/trustedkeys.gpg': file open error
gpgv: Signature made Tue Oct 25 23:33:18 2011 UTC using RSA key ID E99007E0
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./mksh_40.2-3.dsc
dpkg-source: info: extracting mksh in mksh-40.2
dpkg-source: info: unpacking mksh_40.2.orig.tar.gz
dpkg-source: info: applying mksh_40.2-3.diff.gz
dpkg-source: info: upstream files that have been modified:
 mksh-40.2/Build.sh
 mksh-40.2/check.t
 mksh-40.2/dot.mkshrc
 mksh-40.2/edit.c
 mksh-40.2/eval.c
 mksh-40.2/exec.c
 mksh-40.2/expr.c
 mksh-40.2/funcs.c
 mksh-40.2/histrap.c
 mksh-40.2/jobs.c
 mksh-40.2/lalloc.c
 mksh-40.2/lex.c
 mksh-40.2/main.c
 mksh-40.2/misc.c
 mksh-40.2/mksh.1
 mksh-40.2/sh.h
 mksh-40.2/shf.c
 mksh-40.2/syn.c
 mksh-40.2/tree.c
 mksh-40.2/var.c
tg@sperger:~$ dchroot sid
Executing shell in chroot: /org/chroot/sid
(sid)tg@sperger:~$ cd mksh-40.2
(sid)tg@sperger:~/mksh-40.2$ HAVE_CAN_WALL=0 USE_PRINTF_BUILTIN=1 CC='gcc' 
CFLAGS='-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Wformat-security -Werror=format-security -Wall -Wextra' 
CPPFLAGS='-D_FORTIFY_SOURCE=2 -DMKSH_BINSHREDUCED' LDFLAGS='-fPIE -pie 
-Wl,-z,relro -Wl,-z,now' LIBS='' dash Build.sh -r -c lto

[…]

gcc -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Wformat-security -Werror=format-security -Wall -Wextra -fno-strict-aliasing 
-fstack-protector-all -fwrapv -flto=jobserver -std=gnu99 -I. 
-D_FORTIFY_SOURCE=2 -DMKSH_BINSHREDUCED -D_GNU_SOURCE 
-DSETUID_CAN_FAIL_WITH_EAGAIN -DHAVE_ATTRIBUTE_BOUNDED=0 
-DHAVE_ATTRIBUTE_FORMAT=1 -DHAVE_ATTRIBUTE_NONNULL=1 
-DHAVE_ATTRIBUTE_NORETURN=1 -DHAVE_ATTRIBUTE_UNUSED=1 -DHAVE_ATTRIBUTE_USED=1 
-DHAVE_SYS_BSDTYPES_H=0 -DHAVE_SYS_FILE_H=1 -DHAVE_SYS_MKDEV_H=0 
-DHAVE_SYS_MMAN_H=1 -DHA

Bug#633479: failed armel build of mksh 40.2-3

[Thorsten Glaser]

Hi,

probably the same problem, on armel instead:

Debian buildds dixit:

> * Source package: mksh
> * Version: 40.2-3
> * Architecture: armel
> * State: failed
> * Suite: sid
> * Builder: antheil.debian.org
> * Build log: 
> https://buildd.debian.org/fetch.cgi?pkg=mksh&arch=armel&ver=40.2-3&stamp=1319588488&file=log

gcc -g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Wformat-security -Werror=format-security -Wall -Wextra -fno-strict-aliasing 
-fstack-protector-all -fwrapv -flto=jobserver -std=gnu99 -I. -I'../..' 
-D_FORTIFY_SOURCE=2 -DMKSH_BINSHREDUCED -D_GNU_SOURCE 
-DSETUID_CAN_FAIL_WITH_EAGAIN -DHAVE_ATTRIBUTE_BOUNDED=0 
-DHAVE_ATTRIBUTE_FORMAT=1 -DHAVE_ATTRIBUTE_NONNULL=1 
-DHAVE_ATTRIBUTE_NORETURN=1 -DHAVE_ATTRIBUTE_UNUSED=1 -DHAVE_ATTRIBUTE_USED=1 
-DHAVE_SYS_BSDTYPES_H=0 -DHAVE_SYS_FILE_H=1 -DHAVE_SYS_MKDEV_H=0 
-DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SELECT_H=1 
-DHAVE_SYS_SYSMACROS_H=1 -DHAVE_BSTRING_H=0 -DHAVE_GRP_H=1 -DHAVE_LIBGEN_H=1 
-DHAVE_LIBUTIL_H=0 -DHAVE_PATHS_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_ULIMIT_H=1 -DHAVE_VALUES_H=1 -D_FILE_OFFSET_BITS=64 
-DHAVE_CAN_INTTYPES=1 -DHAVE_CAN_UCBINTS=1 -DHAVE_CAN_INT8TYPE=1 
-DHAVE_CAN_UCBINT8=1 -DHAVE_RLIM_T=1 -DHAVE_SIG_T=1 -DHAVE_SYS_SIGNAME=0 
-DHAVE_SYS_SIGLIST=1 -DHAVE_STRSIGNAL=0 -DHAVE_GETRUSAGE=1 -DHAVE_KILLPG=1 
-DHAVE_MKNOD=0 -DHAVE_MKSTEMP=1 -DHAVE_NICE=1 -DHAVE_REVOKE=0 
-DHAVE_SETLOCALE_CTYPE=1 -DHAVE_LANGINFO_CODESET=1 -DHAVE_SELECT=1 
-DHAVE_SETRESUGID=1 -DHAVE_SETGROUPS=1 -DHAVE_STRCASESTR=1 -DHAVE_STRLCPY=0 
-DHAVE_FLOCK_DECL=0 -DHAVE_REVOKE_DECL=1 -DHAVE_SYS_SIGLIST_DECL=1 
-DHAVE_PERSISTENT_HISTORY=1 -DMKSH_PRINTF_BUILTIN -c ../../exec.c
../../histrap.c: In function 'writehistfile':
../../histrap.c:1037:1: internal compiler error: in get_arm_condition_code, at 
config/arm/arm.c:17152
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccYmtFk6.out file, please attach this to 
your bugreport.

(Obviously I don’t have ready access to that file.)

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1110260659470.2...@herc.mirbsd.org

Bug#640035: FTBFS: maybe Multiarch related regression? fails to find its includes

[Thorsten Glaser]

tags 640035 + patch
thanks

Dixi quod…

>Related to #638603 even the latest version of gcj-4.4 also FTBFS.

The patch works. Uploading to d-p.org “unreleased” now.
Please include it in the next upload.

bye,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1109041409590.1...@herc.mirbsd.org

libffi symbols update

[Thorsten Glaser]

--- debian/libffi5.symbols.m68k (libffi5_3.0.10~rc10-3_m68k)
+++ dpkg-gensymbols3DQGiB   2011-09-03 21:23:05.0 +
@@ -14,6 +14,7 @@
  ffi_prep_args@Base 3.0.4
  ffi_prep_cif@Base 3.0.4
  ffi_prep_cif_machdep@Base 3.0.4
+ ffi_prep_cif_var@Base 3.0.10~rc10-3
  ffi_prep_closure@Base 3.0.4
  ffi_prep_closure_loc@Base 3.0.4
  ffi_prep_java_raw_closure@Base 3.0.4

Uploading current package now (with testsuite results, fifty-some
failed, in case someone wants to have a look at it).

bye,
//mirabilos
-- 
08:05⎜ mika: Does grml have an tool to read Apple
 ⎜System Log (asl) files? :)
08:08⎜ yeah. /bin/rm. ;)   08:09⎜ hexdump -C
08:31⎜ ft, mrud: *g*


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1109032125180.1...@herc.mirbsd.org

Bug#638603: FTBFS: maybe Multiarch related regression? fails to find its includes

[Thorsten Glaser]

Hi,

the patch I sent (4.4.6-10+m68k.1) indeed works for gcc-4.4 at least.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1109031247540.1...@herc.mirbsd.org

Bug#640035: possible patches

[Thorsten Glaser]

tags 638603 + patch
tags 635918 + patch
thanks

The attached patch for gcc-4.4 lets it compile past the stage
where it aborted previously. Both attached patches compile
cleanly on amd64; whether m68k will succeed is pretty certain
but can only be told in 1/2 (gcc) or three to four (gcj) days.

(The gcc build has just started stage3, and I’m starting a
gcj build on another machine right now.)

The gcj-4.4 patch is the same as the gcc-4.4 patch, just
rebased for gcj. It fixes #635918 as well.
A fix for gcc-4.6 (#639303) might be similar in nature.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Huntdiff -u gcc-4.4-4.4.6/debian/rules2 gcc-4.4-4.4.6/debian/rules2
--- gcc-4.4-4.4.6/debian/rules2
+++ gcc-4.4-4.4.6/debian/rules2
@@ -365,6 +365,10 @@
   CONFARGS += --with-multilib-list=m4,m4-nofpu --with-cpu=sh4
 endif
 
+ifneq (,$(findstring m68k-linux,$(DEB_TARGET_GNU_TYPE)))
+  CONFARGS += --disable-multilib
+endif
+
 ifeq ($(DEB_TARGET_ARCH_OS),linux)
   ifneq (,$(findstring $(DEB_TARGET_ARCH), alpha powerpc ppc64 s390 s390x 
sparc sparc64))
 ifeq ($(DEB_TARGET_ARCH),alpha)
diff -u gcc-4.4-4.4.6/debian/rules.patch gcc-4.4-4.4.6/debian/rules.patch
--- gcc-4.4-4.4.6/debian/rules.patch
+++ gcc-4.4-4.4.6/debian/rules.patch
@@ -251,6 +251,7 @@
   debian_patches += pr46179
   debian_patches += pr39531
   debian_patches += pr41064
+  debian_patches += pr47908
 endif
 
 ifeq ($(DEB_TARGET_ARCH),powerpcspe)
diff -u gcc-4.4-4.4.6/debian/changelog gcc-4.4-4.4.6/debian/changelog
--- gcc-4.4-4.4.6/debian/changelog
+++ gcc-4.4-4.4.6/debian/changelog
@@ -1,3 +1,10 @@
+gcc-4.4 (4.4.6-10+m68k.1) unreleased; urgency=low
+
+  * [m68k] Disable multilib, it FTBFS. (Closes: #638603)
+  * debian/patches/pr47908.diff: Fix ICE on m68k. (Closes: #635918)
+
+ -- Thorsten Glaser   Thu, 01 Sep 2011 20:31:52 +
+
 gcc-4.4 (4.4.6-10) unstable; urgency=low
 
   * Fix non-biarch multiarch builds.
only in patch2:
unchanged:
--- gcc-4.4-4.4.6.orig/debian/patches/pr47908.diff
+++ gcc-4.4-4.4.6/debian/patches/pr47908.diff
@@ -0,0 +1,51 @@
+# DP: Fix PR target/47908 with Attachment #24863 from Mikael Pettersson
+# DP: A fix is already included with gcc-4.6 MAIN.
+
+Index: gcc-4.4-4.4.6/src/gcc/config/m68k/m68k-protos.h
+===
+--- gcc-4.4-4.4.6.orig/src/gcc/config/m68k/m68k-protos.h   2011-09-01 
19:57:54.0 +
 gcc-4.4-4.4.6/src/gcc/config/m68k/m68k-protos.h2011-09-01 
20:22:07.0 +
+@@ -96,6 +96,7 @@
+ extern bool m68k_use_return_insn (void);
+ extern void m68k_expand_epilogue (bool);
+ extern void override_options (void);
++extern void optimization_options (int, int);
+ extern const char *m68k_cpp_cpu_ident (const char *);
+ extern const char *m68k_cpp_cpu_family (const char *);
+ extern void init_68881_table (void);
+Index: gcc-4.4-4.4.6/src/gcc/config/m68k/m68k.c
+===
+--- gcc-4.4-4.4.6.orig/src/gcc/config/m68k/m68k.c  2011-09-01 
19:57:54.0 +
 gcc-4.4-4.4.6/src/gcc/config/m68k/m68k.c   2011-09-01 20:22:07.0 
+
+@@ -729,6 +729,17 @@
+ }
+ }
+ 
++void
++optimization_options (int level ATTRIBUTE_UNUSED, int size ATTRIBUTE_UNUSED)
++{
++  if (m68k_sched_cpu == CPU_UNKNOWN)
++{
++  flag_schedule_insns = 0;
++  flag_schedule_insns_after_reload = 0;
++  flag_modulo_sched = 0;
++}
++}
++
+ /* Generate a macro of the form __mPREFIX_cpu_NAME, where PREFIX is the
+given argument and NAME is the argument passed to -mcpu.  Return NULL
+if -mcpu was not passed.  */
+Index: gcc-4.4-4.4.6/src/gcc/config/m68k/m68k.h
+===
+--- gcc-4.4-4.4.6.orig/src/gcc/config/m68k/m68k.h  2011-09-01 
19:57:54.0 +
 gcc-4.4-4.4.6/src/gcc/config/m68k/m68k.h   2011-09-01 20:22:07.0 
+
+@@ -274,6 +274,9 @@
+ 
+ #define OVERRIDE_OPTIONS   override_options()
+ 
++#define OPTIMIZATION_OPTIONS(LEVEL,SIZE) \
++  optimization_options ((LEVEL), (SIZE))
++
+ /* These are meant to be redefined in the host dependent files */
+ #define SUBTARGET_OVERRIDE_OPTIONS
+ 
diff -u gcj-4.4-4.4.6/debian/rules2 gcj-4.4-4.4.6/debian/rules2
--- gcj-4.4-4.4.6/debian/rules2
+++ gcj-4.4-4.4.6/debian/rules2
@@ -365,6 +365,10 @@
   CONFARGS += --with-multilib-list=m4,m4-nofpu --with-cpu=sh4
 endif
 
+ifneq (,$(findstring m68k-linux,$(DEB_TARGET_GNU_TYPE)))
+  CONFARGS += --disable-multilib
+endif
+
 ifeq ($(DEB_TARGET_ARCH_OS),linux)
   ifneq (,$(findstring $(DEB_TARGET_ARCH), alpha powerpc ppc64 s390 s390x 
sparc sparc64))
 ifeq ($(DEB_TARGET_ARCH),alpha)
diff -u gcj-4.4-4.4.6/debian/rules.patch gcj-4.4-4.4.6/debian/rules.patch
--- gcj

Bug#636291: gnat on kfreebsd

[Thorsten Glaser]

Ludovic Brenta dixit:

>I've already uploaded (yesterday evening) with my proposed patch but if
>your patch is better, I'll be happy to upload with yours.

Yes, I noticed because of the upload (keeping an eye on d-d-changes
at the moment). I don’t know whether my patch is better, with Ada
it’s really a do-as-I-encounter-it approach for me (but with years
of doing that, occasionally)… it was enough for the bootstrap to
succeed, at least.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1108091637230.3...@herc.mirbsd.org

Bug#636291: gnat on kfreebsd

[Thorsten Glaser]

Hi,

when I looked at this at Debconf 11, I copied two functions from the
Linux or FreeBSD (don’t remember, used the one that looked more fitting)
file over. The exact diff I sent to Christoph Egger, don’t have it with
me any more.

Christoph, can you send the patch here for difference? It differs from
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00139.html

Ludovic, I have copyright assignment to the FSF (also for GCC) standing,
so this shouldn’t be a problem.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.00.1108090924490.32...@tglase.bonn.tarent.de

Bug#635919: gcc-4.6: please add fix for PR/47908

[Thorsten Glaser]

Source: gcc-4.6

Hi,

please add the fix for PR/47908 from:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02514.html

The fix is scheduled for upstream inclusion, only waiting for
the FSF to process the copyright assignment papers, so it should
be fine.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1107291531360.27...@herc.mirbsd.org

Bug#635918: gcc-4.4: please add fix for PR/47908

[Thorsten Glaser]

Source: gcc-4.4

Hi,

please add the fix for PR/47908 from:
http://gcc.gnu.org/bugzilla/attachment.cgi?id=24863&action=diff

The fix is scheduled for upstream inclusion, only waiting for
the FSF to process the copyright assignment papers, so it should
be fine.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999



-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1107291527001.27...@herc.mirbsd.org

Bug#633754: gcj-4.6: FTBFS on m68k with segfault

[Thorsten Glaser]

Richard dixit:

>what is "prev_insn"?

(gdb) print prev_insn
No symbol "prev_insn" in current context.

Maybe this?

(gdb) print previous_insn
$4 = {rtx (rtx)} 0x801182c4 
(gdb) print prev_real_insn
$6 = {rtx (rtx)} 0x801184b4 
(gdb) print prev_active_insn
$7 = {rtx (rtx)} 0x801185ac 
(gdb) print prev_cc0_setter
$8 = {rtx (rtx)} 0x801187e8 


//mirabilos
-- 
08:05⎜ mika: Does grml have an tool to read Apple
 ⎜System Log (asl) files? :)
08:08⎜ yeah. /bin/rm. ;)   08:09⎜ hexdump -C
08:31⎜ ft, mrud: *g*



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1107151724180.8...@herc.mirbsd.org

Bug#633754: gcj-4.6: FTBFS on m68k with segfault

[Thorsten Glaser]

Richard dixit:

>equiv_constant is called with NULL pointer, I would think this is
>illegal and the problem happened one level up :

Probably.

(gdb) frame 1
#1  0x804b0542 in fold_rtx (x=0xc83cb5f4, insn=0xc83cc1c0) at 
../../src/gcc/cse.c:3274
3274const_arg = equiv_constant (folded_arg);
(gdb) list
3269
3270#ifdef HAVE_cc0
3271  case CC0:
3272folded_arg = prev_insn_cc0;
3273mode_arg = prev_insn_cc0_mode;
3274const_arg = equiv_constant (folded_arg);
3275break;
3276#endif
3277
3278  default:
(gdb) print folded_arg
$1 = (rtx) 0x0
(gdb) print prev_insn_cc0
$2 = (rtx) 0x0
(gdb) print prev_insn_cc0_mode
$3 = VOIDmode

Ideas?
//mirabilos
-- 
08:05⎜ mika: Does grml have an tool to read Apple
 ⎜System Log (asl) files? :)
08:08⎜ yeah. /bin/rm. ;)   08:09⎜ hexdump -C
08:31⎜ ft, mrud: *g*



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1107141846490.17...@herc.mirbsd.org

Bug#633754: gcj-4.6: FTBFS on m68k with segfault

[Thorsten Glaser]

Adam D. Barratt dixit:

> This isn't RC. It's not a regression, and m68k isn't a release architecture in
> any case.

Sure. I just selected FTBFS severity in reportbug,
but don’t disagree with that.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1107131422090.19...@herc.mirbsd.org

Bug#633754: gcj-4.6: FTBFS on m68k with segfault

[Thorsten Glaser]

Source: gcj-4.6
Version: 4.6.1-2
Severity: serious
Justification: fails to build from source

Building (bootstrapping) gcj-4.6 fails after 3/4 days at:

/bin/bash ./libtool --tag=GCJ   --mode=compile 
/tmp/buildd/gcj-4.6-4.6.1/build/./gcc/gcj 
-B/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/ 
-B/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/ 
-B/tmp/buildd/gcj-4.6-4.6.1/build/./gcc/ -B/usr/m68k-linux-gnu/bin/ 
-B/usr/m68k-linux-gnu/lib/ -isystem /usr/m68k-linux-gnu/include -isystem 
/usr/m68k-linux-gnu/sys-include  -m68040 -fclasspath= 
-fbootclasspath=../../../../src/libjava/classpath/lib --encoding=UTF-8 
-Wno-deprecated -fbootstrap-classes -g -O2  -m68040  -c -o java/util.lo 
-fsource-filename=/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/classpath/lib/classes
 -MT java/util.lo -MD -MP -MF java/util.deps @java/util.list
libtool: compile:  /tmp/buildd/gcj-4.6-4.6.1/build/./gcc/gcj 
-B/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/ 
-B/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/ 
-B/tmp/buildd/gcj-4.6-4.6.1/build/./gcc/ -B/usr/m68k-linux-gnu/bin/ 
-B/usr/m68k-linux-gnu/lib/ -isystem /usr/m68k-linux-gnu/include -isystem 
/usr/m68k-linux-gnu/sys-include -m68040 -fclasspath= 
-fbootclasspath=../../../../src/libjava/classpath/lib --encoding=UTF-8 
-Wno-deprecated -fbootstrap-classes -g -O2 -m68040 -c 
-fsource-filename=/tmp/buildd/gcj-4.6-4.6.1/build/m68k-linux-gnu/m68040/libjava/classpath/lib/classes
 -MT java/util.lo -MD -MP -MF java/util.deps @java/util.list  -fPIC -o 
java/.libs/util.o
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Random.java: In class 
'java.util.Random':
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Random.java: In 
method 'java.util.Random.nextGaussian()':
In file included from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/external/jsr166/java/util/Queue.java:0:0,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/PropertyResourceBundle.java:169,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/PropertyPermissionCollection.java:164,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/PropertyPermission.java:269,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Properties.java:820,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/PriorityQueue.java:335,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/PriorityQueue.java:176,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Observer.java:0,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Observable.java:181,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/NoSuchElementException.java:87,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/external/jsr166/java/util/NavigableSet.java:0,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/external/jsr166/java/util/NavigableMap.java:0,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/MissingResourceException.java:103,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/MissingFormatWidthException.java:86,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/MissingFormatArgumentException.java:88,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Map.java:0,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Map.java:0,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Locale.java:1028,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/ListResourceBundle.java:130,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/ListIterator.java:0,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/List.java:0,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/LinkedList.java:1257,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/LinkedList.java:1017,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/LinkedList.java:120,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/LinkedList.java:1107,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/LinkedHashSet.java:157,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/LinkedHashMap.java:442,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/LinkedHashMap.java:220,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/LinkedHashMap.java:497,
 from 
/tmp/buildd/gcj-4.6-4.6.1/src/libjava/classpath/java/util/Iterator.java

Bug#633359: gcc-defaults: some dissonance

[Thorsten Glaser]

Source: gcc-defaults
Version: 1.106

Three things I noticed in 1.105 which were not yet fixed
in 1.106 – the second one must be addressed in another
upload before I can build this on m68k; the third one is
an FTBFS fix I could work around (but since we require
an upload due to the second issue anyway, it can be fixed
correctly); the first one is cleanup.


1) There is a directory gcc-defaults-1.106/debian/gcj
   with junk content from before the gcj subpackage
   removal in the source package.

2) [important] The with_multiarch_lib flag is not set
   on Debian sid, which leads to the following:
ln -s libgcj.so.$(LIBGCJ_SONAME) \
debian/libgcj-bc/usr/lib/libgcj_bc.so.1
   However, libgcj.so.$(LIBGCJ_SONAME) is already in
   the multiarch directories:

root@ara5:/var/cache/apt/archives # ar p libgcj10_4.4.6-6_m68k.deb 
./data.tar.gz | tar tzvf - | fgrep libgcj.so.
-rw-r--r-- root/root  38346776 2011-06-27 15:57 
./usr/lib/m68k-linux-gnu/libgcj.so.10.0.0

   This makes gcj unusable (e.g. src:libidn FTBFS). I’ve
   fixed it by editing debian/rules and removing “sid”
   from line 240 (236 in 1.105), but that may have impli‐
   cations for with_multilib=yes targets (multilib_archs),
   so I don’t know whether this was the correct fix.

3) The package currently doesn’t build on m68k because
   of its broken build-depends; it shouldn’t assume
   gcc-4.6/gcj-4.6 exist on !gcc46_archs / !gcj46_archs

   My fix was to use alternate build dependencies and
   spell out what to use where:

Build-Depends: m4, debhelper (>= 5), dpkg-dev (>= 1.16.0~ubuntu4)
 , gcj-4.6-base (>= 4.6.0~) [amd64 armel armhf hppa i386 ia64 lpia mips mipsel 
powerpc ppc64 s390 sh4 sparc sparc64 kfreebsd-amd64 kfreebsd-i386 hurd-i386]
 | gcj-4.4-base (>= 4.4.5~) [!arm !amd64 !armel !armhf !hppa !i386 !ia64 !lpia 
!mips !mipsel !powerpc !ppc64 !s390 !sh4 !sparc !sparc64 !kfreebsd-amd64 
!kfreebsd-i386 !hurd-i386]
 , gcc-4.6-base (>= 4.6.0~) [amd64 armel armhf hppa i386 ia64 lpia mips mipsel 
powerpc ppc64 s390 sh4 sparc sparc64 kfreebsd-amd64 kfreebsd-i386 hurd-i386]
 | gcc-4.4-base (>= 4.4.5~) [!amd64 !armel !armhf !hppa !i386 !ia64 !lpia !mips 
!mipsel !powerpc !ppc64 !s390 !sh4 !sparc !sparc64 !kfreebsd-amd64 
!kfreebsd-i386 !hurd-i386]
 , lsb-release

   Algorithmically:
   - gcc-4.6-base becomes:
 gcc-4.6-base [gcc46_archs] | gcc-4.4-base [!gcc46_archs]
   - gcj-4.6-base [!arm] becomes:
 gcj-4.6-base [gcj46_archs] | gcj-4.4-base [!arm !gcj46_archs]

   I could probably just have used the ‘-d’ option to ignore missing
   build dependencies, but I use cowbuilder, and felt that fixing
   the Build-Depends was the correct way to go, hence this submission.


bye,
//mirabilos
-- 
[00:02]  gecko: benutzt du emacs ?
[00:03]  nö  [00:03]  nur n normalen mac
[00:04]  argl   [00:04]  ne den editor
-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1107091621070.22...@herc.mirbsd.org

Bug#632380: gcc-4.6: please add m68k support

[Thorsten Glaser]

Thorsten Glaser dixit:

>So this is at least not
>worse than the current state, and please include it in the next
>upload.

Well, it built, and I uploaded it to debian-ports.org unreleased,
so please, everyone who can, test it.

+   158 Jul  4 Debian Ports Archive Maintai  (2174)   
gcc-4.6_4.6.1-1+m68k.1_m68k.changes ACCEPTED

It will probably take me 2 days before I can do so myself.

bye,
//mirabilos
-- 
Support mksh as /bin/sh and RoQA dash NOW!
‣ src:bash (256 (275) bugs: 0 RC, 177 (192) I&N, 79 (83) M&W, 0 F&P)
‣ src:dash (81 (89) bugs: 3 RC, 43 (46) I&N, 35 (40) M&W, 0 F&P)
‣ src:mksh (2 bugs: 0 RC, 0 I&N, 2 M&W, 0 F&P)



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1107040759560.20...@herc.mirbsd.org

Bug#632380: gcc-4.6: please add m68k support

[Thorsten Glaser]

Source: gcc-4.6
Version: 4.6.1-1
Severity: wishlist
Tags: patch

Hi,

as promised I’ve ported what was still in src:gcc-4.4 regarding
m68k support and related fixes to gcc-4.6. The package with this
patch applied builds on amd64 both natively¹ and as a crosscompiler,
the m68k native build will take a few days as usual. The multiarch
selection² has been fixed upstream³, and all but one of the pr*.diff
are also merged already.

I’ve done some rudimentary testing: cross-built mksh (statically
and dynamically linked) and ran its own testsuite on an m68k sy-
stem, which passed with 0 errors each. So this is at least not
worse than the current state, and please include it in the next
upload.

bye,
//mirabilos

① Package build aborted though due to running out of disc space
  in the testsuite… but then, none of the changes should touch
  the amd64 native build parts.

② Although I wonder why we build the multilib stuff at all, you
  told me to not disable it, but I can’t find the 68040/68060
  optimised target libraries in the .deb packages… so they just
  take up compile time at the moment.

③ Turns out my old m68k-multilib patch was indeed correct, and
  the cpu32 and fidoa targets were incorrectly marked as having
  an MMU in gcc-4.4 (they fixed that instead so the selection
  was fine again).
-- 
08:05⎜ mika: Does grml have an tool to read Apple
 ⎜System Log (asl) files? :)
08:08⎜ yeah. /bin/rm. ;)   08:09⎜ hexdump -C
08:31⎜ ft, mrud: *g*Changes to generated files (d/r control) omitted.

--- gcc-4.6-4.6.1/debian/rules.patch
+++ gcc-4.6-4.6.1/debian/rules.patch
@@ -64,7 +64,6 @@
alpha-no-ev4-directive \
boehm-gc-getnprocs \
note-gnu-stack \
-   m68k-allow-gnu99 \
libgomp-omp_h-multilib \
sparc-force-cpu \
pr24619 \
@@ -76,6 +75,7 @@
$(if $(with_linaro_branch),,gcc-dw2-loc-tracking) \
mudflap-varargs \
pr45078 \
+   pr43804 \
 
 #  libstdc++-nothumb-check \
 # TODO: update
--- gcc-4.6-4.6.1/debian/rules.defs
+++ gcc-4.6-4.6.1/debian/rules.defs
@@ -1176,7 +1176,7 @@
 
 # GNU locales
 force_gnu_locales := yes
-locale_no_cpus := m68k
+locale_no_cpus :=
 locale_no_systems := knetbsd-gnu
 ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(locale_no_systems)))
   force_gnu_locales := disabled for system $(DEB_TARGET_GNU_SYSTEM)
--- gcc-4.6-4.6.1/debian/changelog
+++ gcc-4.6-4.6.1/debian/changelog
@@ -1,3 +1,15 @@
+gcc-4.6 (4.6.1-1+m68k.1) unreleased; urgency=low
+
+  [ Thorsten Glaser ]
+  * Apply changes from src:gcc-4.4 for m68k support:
+- debian/rules.defs: Remove m68k from locale_no_cpus.
+- debian/patches/gcc-multiarch.diff: Add m68k multiarch_mappings.
+- debian/patches/m68k-allow-gnu99.diff: Drop, we have eglibc now.
+- debian/patches/pr43804.diff: Fix backported from SVN.
+- debian/rules.patch: Add pr43804 and drop m68k-allow-gnu99.
+
+ -- Thorsten Glaser   Fri, 01 Jul 2011 18:39:11 +
+
 gcc-4.6 (4.6.1-1) unstable; urgency=low
 
   * GCC 4.6.1 release.
--- gcc-4.6-4.6.1/debian/patches/gcc-multiarch.diff
+++ gcc-4.6-4.6.1/debian/patches/gcc-multiarch.diff
@@ -7,6 +7,9 @@
 # DP:  /usr/lib/-linux-gnu
 # DP: to the system paths.
 
+2011-07-01  Thorsten Glaser 
+   * Add m68k multiarch_mappings
+
 2011-03-08  Steve Langasek 
* Canonicalize x86 to i386 everywhere, not i486/i686
 
@@ -262,7 +265,7 @@
 this architecture. */
 --- a/src/gcc/multiarch.h
 +++ b/src/gcc/multiarch.h
-@@ -0,0 +1,95 @@
+@@ -0,0 +1,101 @@
 +/* Header for multiarch handling (include directories, libraries path).
 +   Copyright (C) 2009 Free Software Foundation, Inc.
 +   Contributed by Arthur Loiret 
@@ -336,6 +339,12 @@
 +  { "m4",  "sh4-linux-gnu" },
 +  { "m4-nofpu",  "sh4_nofpu-linux-gnu" },
 +# endif
++# if defined(__m68k_linux_gnu__)
++  { "m68040", "m68040-linux-gnu" },
++  { "m68060", "m68060-linux-gnu" },
++  { "mcpu32", "m68360-linux-gnu" },
++  { "mfidoa", "fido-linux-gnu" },
++# endif
 +#endif /* ENABLE_MULTIARCH */
 +  { 0, 0 }
 +};
reverted:
--- gcc-4.6-4.6.1/debian/patches/m68k-allow-gnu99.diff
+++ gcc-4.6-4.6.1.orig/debian/patches/m68k-allow-gnu99.diff
@@ -1,30 +0,0 @@
-# DP: patch to allow gnu99 mode on m68k
-
-On m68k, gnu99 mode doesn't work correctly out of the box due to our
-woefully outdated glibc (we're currently stuck at 2.5-1). This is
-because the inline schematics changed between glibc 2.5 and 2.7, and
-gcc 4.2 to 4.3.  This patch configures the built in spec file to pass
--fgnu89-inline, and thus allowing proper compilation and linking with
-the older glibc on m68k. This patch should not be merged upstream, and
-it should be removed once a newer glibc is available for our
-architecture.
-

- gcc/config/m68k/linux.h |6 ++
- 1 files changed, 6 insertions(+), 0 deletions(-)
-
 a/src/gcc/config/m68k/linux.h
-+++ b/src/gcc/config/m68k/linux.h

Bug#629244: gcc-4.1: miscompiles with -fwrapv

[Thorsten Glaser]

Source: gcc-4.1
Version: 4.1.1ds2-21

Just for reference: the standard compiler on Debian etch (i386)
miscompiles the attached test programme with -fwrapv -O2 and
-fwrapv -Os, but not with -fwrapv -O1 or without -fwrapv.

If there's a workaround I can apply to the source (texpand was
the function changed) please tell me./* Copyright (c) Thorsten Glaser. Part of mksh, under the MirOS Licence. */

#include 
#include 
#include 
#include 
#include 
#include 

#define BIT(i)  (1 << (i))  /* define bit in flag */
#define DEFINED BIT(1)  /* is defined in block */
#define FINUSE  BIT(9)  /* function being executed */

#define INIT_TBLS   8   /* initial table size (power of 2) */
#define PERTURB_SHIFT   5   /* see Python 2.5.4 Objects/dictobject.c */

#ifndef SIZE_MAX
#ifdef SIZE_T_MAX
#define SIZE_MAXSIZE_T_MAX
#else
#define SIZE_MAX((size_t)-1)
#endif
#endif
#define notoktoadd(val, cnst)   ((val) > (SIZE_MAX - (cnst)))
#define checkoktoadd(val, cnst) do {\
if (notoktoadd((val), (cnst)))  \
errx(1,"overflow"); \
} while (/* CONSTCOND */ 0)

struct lalloc {
struct lalloc *next;
};
typedef struct lalloc Area;
typedef int32_t mksh_ari_t;
typedef uint32_t mksh_uari_t;
struct op;
typedef int Tflag;

struct table {
Area *areap;/* area to allocate entries */
struct tbl **tbls;  /* hashed table items */
uint32_t size;  /* table size (always 2^n) */
uint32_t nfree; /* free table entries */
};

struct tbl {/* table item */
Area *areap;/* area to allocate from */
union {
char *s;/* string */
mksh_ari_t i;   /* integer */
mksh_uari_t u;  /* unsigned integer */
int (*f)(const char **); /* int function */
struct op *t;   /* "function" tree */
} val;  /* value */
union {
struct tbl *array;  /* array values */
const char *fpath;  /* temporary path to undef function */
} u;
union {
int field;  /* field with for -L/-R/-Z */
int errno_; /* CEXEC/CTALIAS */
} u2;
int type;   /* command type (see below), base (if INTEGER),
 * or offset from val.s of value (if EXPORT) */
Tflag flag; /* flags */
union {
uint32_t hval;  /* hash(name) */
uint32_t index; /* index for an array */
} ua;
char name[4];   /* name -- variable length */
};


static void texpand(struct table *, size_t);

static void
texpand(struct table *tp, size_t nsize)
{
size_t i, j, osize = tp->size, perturb;
struct tbl *tblp, **pp;
struct tbl **ntblp, **otblp = tp->tbls;

i = 1;
i <<= 30;
if (nsize > i)
errx(1, "hash table size limit reached");

ntblp = malloc(nsize * sizeof(struct tbl *));
memset(ntblp, 0, nsize * sizeof(struct tbl *));
tp->size = nsize;
if (nsize == i) {
/* cannot be grown any more, use a fixed value */
tp->nfree = i - 65536;
} else /* (nsize < 2^30) */ {
/* table can get 80% full */
tp->nfree = (nsize * 4) / 5;
}
tp->tbls = ntblp;
if (otblp == NULL)
return;

/* from here on nsize := mask */
nsize--;
for (i = 0; i < osize; i++)
if ((tblp = otblp[i]) != NULL) {
if ((tblp->flag & DEFINED)) {
/* search for free hash table slot */
j = (perturb = tblp->ua.hval) & nsize;
goto find_first_empty_slot;
 find_next_empty_slot:
j = (j << 2) + j + perturb + 1;
perturb >>= PERTURB_SHIFT;
 find_first_empty_slot:
pp = &ntblp[j & nsize];
if (*pp != NULL)
goto find_next_empty_slot;
/* found an empty hash table slot */
*pp = tblp;
tp->nfree--;
} else if (!(tblp->flag & FINUSE)) {
free(tblp);
}
}
free(otblp);
}

void
ktinit(struct table *tp, Area *ap, size_t tsize)
{
tp->areap = ap;
tp->tbls = NULL;
tp->size = tp->n

Re: GCC-4.5 as the default for (at least some) architectures

[Thorsten Glaser]

Matthias Klose dixit:

> At this point, pretty well after the GCC 4.6.0 release, I would like to avoid
> switching more architectures to 4.5, but rather get rid of GCC 4.5 to reduce
> maintenance efforts on the debian-gcc side, even before the multiarch changes

Porters side, too. I’m okay with keeping gcc-4.4 for a while (kernel?)
and switching to gcc-4.6 directly for m68k. I know I’ll probably have
to invest some work into the latter, but considering the kernel problem
is almost solved, chances are good. (I do want to bring out a new base
emulator image first, though, but then…)

bye,
//mirabilos
-- 
13:47⎜ if i were omnipotent, i would divide by zero
all day long ;)
(thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1104261853560.28...@herc.mirbsd.org

[Bug target/43804] [4.5/4.6/4.7 regression] ICE in reload_cse_simplify_operands (fwd)

[Thorsten Glaser]

Hi,

pr43804.diff (in src:gcc-4.4 in Debian) has been committed as-is
upstream and needs to be applied to at least gcc-4.5 and gcc-4.6

bye,
//mirabilos
-- 
13:47⎜ if i were omnipotent, i would divide by zero
all day long ;)
(thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)

-- Forwarded message --
From: schwab at gcc dot gnu.org 
Message-ID: 
X-Spam-Status: No, hits=0.00 required=0.90
To: t...@mirbsd.org
Date: Sun, 24 Apr 2011 20:05:21 +
Subject: [Bug target/43804] [4.5/4.6/4.7 regression] ICE in
reload_cse_simplify_operands

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43804

--- Comment #22 from Andreas Schwab  2011-04-24 
20:04:26 UTC ---
Author: schwab
Date: Sun Apr 24 20:04:24 2011
New Revision: 172920

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172920
Log:
Author: Richard Sandiford 

PR target/43804
* gcc/config/m68k/constraints.md (T): Allow PIC operands that satisfy
LEGITIMATE_PIC_OPERAND_P.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/constraints.md

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.


--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1104242123090.8...@herc.mirbsd.org

Re: [m68k] Re: GCC-4.5 as the default for (at least some) architectures

[Thorsten Glaser]

Michael Tomkins dixit:

> make[2]: Entering directory `/usr/src/mpc-0.9/tests'

We build with cowbuilder from Debian source packages, never
there manually.

>On 03/03/2011, at 6:35 AM, Thorsten Glaser wrote:

>> dependencies, we �just� got gcc-4.4 in a pretty good shape,
>> plus it�s used by the kernel, whereas gcc-4.5 is another

I’d like to run with the attached patch a little while longer.
Actual m68k porters can help by getting their buildds up and
running again (I didn’t manage to get one setup).

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999diff -u gcc-4.4-4.4.6/debian/changelog gcc-4.4-4.4.6/debian/changelog
--- gcc-4.4-4.4.6/debian/changelog
+++ gcc-4.4-4.4.6/debian/changelog
@@ -1,3 +1,9 @@
+gcc-4.4 (4.4.6-2+m68k.1) unreleased; urgency=low
+
+  * Re-enable common pkgs and libs on m68k for lack of gcc-4.[56].
+
+ -- Thorsten Glaser   Sat, 23 Apr 2011 17:45:23 +
+
 gcc-4.4 (4.4.6-2) unstable; urgency=low
 
   * debian/rules (clean): Revert the previous change, breaks the clean target.
diff -u gcc-4.4-4.4.6/debian/rules.defs gcc-4.4-4.4.6/debian/rules.defs
--- gcc-4.4-4.4.6/debian/rules.defs
+++ gcc-4.4-4.4.6/debian/rules.defs
@@ -299,9 +299,11 @@
 # XXX: should with_common_libs be "yes" only if this is the default compiler
 # version on the targeted arch?
 ifeq (,$(filter $(distrelease),lenny etch squeeze dapper hardy jaunty karmic 
lucid))
+ifeq (,$(filter $(DEB_TARGET_ARCH),m68k))
   with_common_pkgs := no
   with_common_libs := no
 endif
+endif
 #ifneq (,$(filter $(distrelease),squeeze sid))
 #  ifneq (,$(filter $(DEB_TARGET_ARCH),amd64 i386))
 #with_common_pkgs := no