Bug#770450: gcc-snapshot: ICE with -O2 -fsanitize=undefined
Package: gcc-snapshot
Version: 20141118-1
Severity: important
Tags: upstream
Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64016
$ gcc-snapshot -O2 -fsanitize=undefined -c gcc-ice.c
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions.
with:
void foo (void);
void tst (void)
{
int px, py, e;
for (py = 3; py = 136; py++)
for (px = 32; px = 160; px += 32)
for (e = py - 2; e = 0; e--)
foo ();
}
This was found when compiling GNU MPFR (tests/tget_f.c).
This is a regression. There is no such problem with 20141016-1.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gcc-snapshot depends on:
ii binutils 2.24.90.2014-2
ii libasound2 1.0.28-1
ii libatk1.0-0 2.14.0-1
ii libc62.19-13
ii libc6-dev2.19-13
ii libc6-dev-i386 2.19-13
ii libc6-dev-x322.19-13
ii libc6-i386 2.19-13
ii libc6-x322.19-13
ii libcairo21.14.0-2.1
ii libecj-java 3.10.1-1
ii libfontconfig1 2.11.0-6.2
ii libfreetype6 2.5.2-2
ii libgdk-pixbuf2.0-0 2.31.1-2+b1
ii libglib2.0-0 2.42.1-1
ii libgmp10 2:6.0.0+dfsg-6
ii libgtk2.0-0 2.24.25-1
ii libice6 2:1.0.9-1
ii libisl10 0.12.2-2
ii libmpc3 1.0.2-1
ii libmpfr4 3.1.2-1
ii libpango-1.0-0 1.36.8-3
ii libpangocairo-1.0-0 1.36.8-3
ii libpangoft2-1.0-01.36.8-3
ii libsm6 2:1.2.2-1
ii libxrandr2 2:1.4.2-1+b1
ii libxrender1 1:0.9.8-1+b1
ii libxtst6 2:1.2.2-1+b1
ii python 2.7.8-2
ii zlib1g 1:1.2.8.dfsg-2
gcc-snapshot recommends no packages.
Versions of packages gcc-snapshot suggests:
ii binutils [binutils-gold] 2.24.90.2014-2
-- 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: https://lists.debian.org/20141121112853.ga21...@ypig.lip.ens-lyon.fr
Processed: Re: gcc-snapshot: ICE with -O2 -fsanitize=undefined
Processing commands for cont...@bugs.debian.org: tags 770450 fixed-upstream Bug #770450 [gcc-snapshot] gcc-snapshot: ICE with -O2 -fsanitize=undefined Added tag(s) fixed-upstream. End of message, stopping processing here. Please contact me if you need assistance. -- 770450: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770450 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.141657216113178.transcr...@bugs.debian.org
Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
Helmut wrote: On Wed, Nov 19, 2014 at 04:41:49PM -0800, Don Armstrong wrote: Are people who are doing cross-building like this actually using the code which will be in jessie? I (perhaps naïvely) would expect them to be primarily using the code in unstable, and maybe at a late stage of bring-up rebuilding all of stable. Thanks for asking this. Let me give two answers to this question: 1) No. The continuous integration happened in sid and people bootstrapping new architectures tend to use sid plus patches. However the method of bootstrapping that was known working two weeks before the freeze no longer works. Whatever method is going to be used now, it requires changing packages. Since these changes tend to not fall under the freeze policy, they are practically not mergeable. So in this answer, jessie is to be understood as a time frame: Keep things working that worked before until we are allowed to fix things. 2) Yes. People repeatedly ask for cross toolchains on stable systems. This is the very reason why Wookey tried to package them for jessie. Ultimately, they ended being late, so people will try to build them on their own and for the popular targets (mostly armhf, armel) this actually worked. We've been using this for development of embedded systems where building on native hardware (or in an emulator) is ridiculously slow (or even impossible for some devices) compared to cross building from Debian on more powerful hardware. That worked great for all releases up to and including Squeeze. For Wheezy, the late introduction of multi-arch basically broke that and doing this on that release was effectively impossible. The change which was reverted here had made doing that on Jessie possible once again, and made it a relatively trivial matter to build your own cross-toolchain using the packaged gcc source (in the absence of those being able to actually be uploaded as pre-built binaries yet). I'd be kind of sad if that stopped being possible again for the final released version of Jessie, and we had to skip yet another release before being able to do this on Debian again. It may not be the best and final answer, but it has some advantages over the proposed alternative, like being able to work with existing m-a packages without needing to rebuild custom versions of everything, and actually working on Debian today. It's not clear to me what advantage was gained by removing it before the alternative to it is actually viable to use, or what problem it had that made doing that compelling. Unless someone can show me that, I'd definitely prefer to have this functionality restored again for Jessie. It's definitely desirable to have this on a stable system, since the lock-step requirement of m-a makes it rather more painful to keep this all working on an unstable system where packages are changing rapidly (and because stable deps are kind of an important thing too :) Cheers, Ron -- 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/20141121144342.go29...@hex.shelbyville.oz
Re: Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
Ron == Ron r...@debian.org writes: Ron I'd be kind of sad if that stopped being possible again for the Ron final released version of Jessie, and we had to skip yet Ron another release before being able to do this on Debian again. Ron It may not be the best and final answer, but it has some Ron advantages over the proposed alternative, like being able to Ron work with existing m-a packages without needing to rebuild Ron custom versions of everything, and actually working on Debian Ron today. I personally think that this use case--building on non-native hardware not for bootstrap but for things where that really just is the wrong answer is an important use case for our toolchains. I'm not saying it is an important use case for the debian archive. However for debian developers using debian and for our downstreams, this seems like it can be very valuable. In particular, I want to take the Debian archive or one of our downstreams, build a cross tool chain, and build additional packages against that archive that would work with the packages in that archive. As an example, I'd like to build some of the prerelease moonshot packages (http://www.project-moonshot.org/) for some arm boards and I don't want to build on those boards. I want the resulting packages to be usable by anyone without needing to install some magic cross toolchain libraries. I don't care which mechanism ]is used to produce this. I understand how to doo this with the method being removed in Jessie. I can't even understand if this is possible with the default method. -- 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/0149d2f01aec-4737b33c-b68b-4cd1-b29f-4d5624e1ef96-000...@email.amazonses.com
Results for 4.9.2 (Debian 4.9.2-2) testsuite on i586-pc-gnu
LAST_UPDATED: Mon Nov 17 22:17:25 UTC 2014 (revision 217678) Target: i586-gnu gcc version 4.9.2 (Debian 4.9.2-2) Native configuration is i586-pc-gnu === g++ tests === Running target unix FAIL: g++.dg/cdce3.C -std=gnu++98 execution test FAIL: g++.dg/cdce3.C -std=gnu++11 execution test FAIL: g++.dg/cdce3.C -std=gnu++1y execution test FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C -std=gnu++11 (test for errors, line 89) FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C -std=gnu++11 (test for errors, line 90) FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C -std=gnu++11 (test for errors, line 91) FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C -std=gnu++11 (test for errors, line 92) FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C -std=gnu++1y (test for errors, line 89) FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C -std=gnu++1y (test for errors, line 90) FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C -std=gnu++1y (test for errors, line 91) FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C -std=gnu++1y (test for errors, line 92) FAIL: g++.dg/cpp0x/gnu_fext-numeric-literals.C -std=gnu++1y (test for excess errors) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for warnings, line 371) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for warnings, line 373) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for warnings, line 375) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for warnings, line 418) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for warnings, line 421) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for warnings, line 436) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for warnings, line 440) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for errors, line 653) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for errors, line 654) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for errors, line 655) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for errors, line 668) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for errors, line 669) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for errors, line 674) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for errors, line 675) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for warnings, line 371) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for warnings, line 373) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for warnings, line 375) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for warnings, line 418) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for warnings, line 421) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for warnings, line 436) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for warnings, line 440) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for errors, line 653) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for errors, line 654) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for errors, line 655) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for errors, line 668) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for errors, line 669) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for errors, line 674) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for errors, line 675) FAIL: g++.dg/cpp0x/overloadn.C -std=gnu++1y (test for excess errors) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++11 (test for warnings, line 90) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++11 (test for warnings, line 93) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++11 (test for warnings, line 94) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++11 (test for warnings, line 95) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++11 (test for errors, line 102) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++11 (test for errors, line 103) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++11 candidate note (test for warnings, line 103) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++1y (test for warnings, line 90) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++1y (test for warnings, line 93) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++1y (test for warnings, line 94) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++1y (test for warnings, line 95) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++1y (test for errors, line 102) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++1y (test for errors, line 103) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++1y candidate note (test for warnings, line 103) FAIL: g++.dg/cpp0x/rv7n.C -std=gnu++1y (test for excess errors) FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C -std=gnu++11 (test for errors, line 89) FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C -std=gnu++11 (test for errors, line 90) FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C -std=gnu++11 (test for errors, line 91) FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C -std=gnu++11 (test for errors, line 92) FAIL: g++.dg/cpp0x/std_fext-numeric-literals.C -std=gnu++11 (test for
