Bug#876825: gcc: not-actually-infinite loop targeting armel

2017-09-28 Thread Edmund Grimley Evans
Yes, it's not an infinite loop; it just takes an inordinate amount of time. The code that triggers this seems to be a long sequence of assignments initialising elements of a multi-dimensional array. There are some big variations in the build times on some other architectures, too. For example on

Bug#876825: gcc: infinite loop targeting armel

2017-09-27 Thread Edmund Grimley Evans
The problem still seems to occurs with: - version 6.4.0-3cross1 of gcc-6-arm-linux-gnueabi (on amd64) - version 7.2.0-7 of gcc-7 (on armel) It's perhaps not really an infinite loop but just an unreasonably long time. Perhaps someone should try running it over the weekend...

Bug#876825: gcc: infinite loop targeting armel

2017-09-26 Thread Edmund Grimley Evans
Package: gcc-6-arm-linux-gnueabi Version: 6.3.0-18cross1 This is not specific to cross-compiling and not even to gcc-6. We noticed the infinite loop when the buildd tries to build rnahybrid: https://buildd.debian.org/status/logs.php?pkg=rnahybrid=armel It seems to be easy to reproduce with the

Bug#807830: arm: -fstack-protector-strong adds dependency on ld-linux-aarch64.so.1 on arm64

2015-12-21 Thread Edmund Grimley Evans
I'd say this is a bug in dpkg-shlibdeps in dpkg-dev. Referring to the example above, on arm64 "test" does depend on ld-linux-aarch64.so.1 because, although "__stack_chk_guard" is defined in "test", there's also a relocation referring to the one in /lib/ld-linux-aarch64.so.1: $ nm test | grep

Bug#788812: g++-4.9: internal compiler error: in expand_fix, at optabs.c:5365

2015-06-15 Thread Edmund Grimley Evans
Package: g++-4.9 Version: 4.9.2-21 $ g++ -O3 -c source.i cpxfiddle.cc: In function 'void functie(Type, Type, const commandlineinput) [with Type = float]': cpxfiddle.cc:625:65: internal compiler error: in expand_fix, at optabs.c:5365 Please submit a full bug report, with preprocessed source if

Bug#785756: libffi: bug on arm64 when passing small struct on stack

2015-05-19 Thread Edmund Grimley Evans
Source: libffi Version: 3.1-2 Tags: patch The latest python-cffi (0.9.2-2) seems to have exposed a bug in libffi on arm64: https://buildd.debian.org/status/package.php?p=python-cffisuite=sid It seems to involve the case of small structs, that could be passed in registers, being passed on the

Bug#764195: gcc-4.9: problems with precompiled headers on arm64

2014-11-05 Thread Edmund Grimley Evans
please recheck with 4.9.2 and trunk (gcc-snapshot). In the past I had mixed results with precompiled headers on AArch64. I was able to reproduce the problem with aegisub and with qtbase-opensource-src. Replacing 4.9.1-16 with 4.9.2-1 or 20141017-1 made no difference. It seems strange to me

Bug#764195: gcc-4.9: problems with precompiled headers on arm64

2014-10-06 Thread Edmund Grimley Evans
Package: gcc-4.9 Version: 4.9.1-16 There are a couple of Debian packages that failed to build on arm64 apparently because of problems with precompiled headers: qtbase-opensource-src See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762702 aegisub See

Bug#755061: GCC 4.9 produces a bad binary on arm64

2014-07-17 Thread Edmund Grimley-Evans
Package: gcc-4.9 Version: 4.9.0-11 When I try to build gnupg2 2.0.25-1 on arm64 using gcc-4.9 some of the tests fail. The object file involved is: agent/gpg_agent-gpg-agent.o A particular test that fails is: ( cd tests/openpgp/ make check TESTS=genkey1024.test ) Other, non-Debian, binaries