oss4 version 4.2-build2004-1ubuntu1 failed to build on armel

Bug #809761 reported by Ricardo Salveti on 2011-07-13
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linaro GCC
Fix Released
Medium
Richard Sandiford
gcc
Fix Released
Medium
oss4 (Debian)
Fix Released
Unknown
oss4 (Ubuntu)
Undecided
Unassigned

Bug Description

oss4 version 4.2-build2004-1ubuntu1 failed to build on armel
Link to failed build: https://launchpad.net/ubuntu/+source/oss4/4.2-build2004-1ubuntu1/+build/2573745

Direct link to the build log: https://launchpad.net/ubuntu/+source/oss4/4.2-build2004-1ubuntu1/+build/2573745/+files/buildlog_ubuntu-oneiric-armel.oss4_4.2-build2004-1ubuntu1_FAILEDTOBUILD.txt.gz

This log snippet might be of interest, since it triggered the matcher 'Purging chroot-autobuild'.
Excerpt 1847 lines into the build log:

cc -c -g -O2 -O -O -O -Wall -Werror -DOSS_LITTLE_ENDIAN -I../../include -I../../kernel/framework/include -I../../kernel/OS/Linux -I../../kernel/nonfree/include -I../.. ossplay_console.c -o ./ossplay_console.o
cc -c -g -O2 -O -O -O -Wall -Werror -DOSS_LITTLE_ENDIAN -I../../include -I../../kernel/framework/include -I../../kernel/OS/Linux -I../../kernel/nonfree/include -I../.. ossplay_decode.c -o ./ossplay_decode.o
ossplay_decode.c: In function 'decode_amplify':
ossplay_decode.c:1002:1: internal compiler error: in get_arm_condition_code, at config/arm/arm.c:17206
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
make[3]: *** [ossplay_decode.o] Error 1
make[3]: Leaving directory `/build/buildd/oss4-4.2-build2004/build-tree/oss-build/cmd/ossplay'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/build/buildd/oss4-4.2-build2004/build-tree/oss-build/cmd'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/build/buildd/oss4-4.2-build2004/build-tree/oss-build'
make: *** [stamp-build-oss4] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
******************************************************************************
Build finished at 20110616-1852
FAILED [dpkg-buildpackage died]
Purging chroot-autobuild/build/buildd/oss4-4.2-build2004

Related branches

Created attachment 24268
preprocessed source

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnueabi
Configured with: ../configure --target=arm-unknown-linux-gnueabi --prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi --with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root --disable-multilib --with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared --disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.7.0 20110517 (experimental) [trunk revision 173832] (GCC)
$ ./xgcc -B. -O1 ~/ice.i
/home/ryan/ice.i: In function 'bar':
/home/ryan/ice.i:33:1: internal compiler error: in get_arm_condition_code, at config/arm/arm.c:17180
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

In , Ibolton (ibolton) wrote :

I haven't been able to reproduce this. Please can you include the args that are being sent to cc1.

With rev173940

$ ./cc1 -fpreprocessed ice.i -quiet -O1
ice.i: In function 'bar':
ice.i:33:1: internal compiler error: in get_arm_condition_code, at config/arm/arm.c:17021
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

In , Ibolton (ibolton) wrote :

I was hoping the compiler command would tell me what -mcpu it was defaulting to.

Anyway, I have managed to reproduce it now, by compiling as follows:

  cc1 -fpreprocessed 49030.i -quiet -O1 -o 49030.s -mcpu=arm7tdmi -marm

Note that it all works with -mthumb and/or -mcpu=cortex-a9.

I have tried this with my old toolchain and it is broken as far back as r164700.

(In reply to comment #3)
> I was hoping the compiler command would tell me what -mcpu it was defaulting
> to.

I'm using an arm-unknown-linux-gnueabi configuration which defaults an arm10tdmi.

linux-eabi.h:#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm10tdmi

The same assert is seen in https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/689887 in Thumb-2 mode on trunk r174795.

Chung-Lin posted a patch at http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00790.html but there are bootstrap issues.

Adding -fno-if-conversion works around the problem.

In , Mikpe (mikpe) wrote :

It's caused by r161764:

Author: sandra
Date: Sat Jul 3 01:00:37 2010
New Revision: 161764

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161764
Log:
2010-07-02 Daniel Jacobowitz <email address hidden>
     Julian Brown <email address hidden>
     Sandra Loosemore <email address hidden>

 gcc/
 * config/arm/arm.c (arm_canonicalize_comparison): Canonicalize DImode
 comparisons. Adjust to take both operands.
 (arm_select_cc_mode): Handle DImode comparisons.
 (arm_gen_compare_reg): Generate a scratch register for DImode
 comparisons which require one. Use xor for Thumb equality checks.
 (arm_const_double_by_immediates): New.
 (arm_print_operand): Allow 'Q' and 'R' for constants.
 (get_arm_condition_code): Handle new CC_CZmode and CC_NCVmode.
        ...

In , Mikpe (mikpe) wrote :

Created attachment 24503
more reduced test case, ICEs at -O1 for armv5te and armv6

Using this slightly more reduced test case I've found that gcc transforms

(set (reg:CC_NCV ...) (compare:CC_NCV (reg:DI ...) (const_int 1 ...)))
(if_then_else (ge (reg:CC_NCV ...) ...) ...)

to

(set (reg:CC_NCV ...) (compare:CC_NCV (reg:DI ...) (const_int 0 ...)))
(if_then_else (gt (reg:CC_NCV ...) ...)

because ifcvt calls noce_get_condition which calls canonicalize_condition, and the latter has a general rule to transform (GE x const) to (GT x const-1).

So the careful code in e.g. cbranchdi4 to not generate unimplemented comparisons is neutralized by generic code.

Do DImode comparisons really have to be asymmetric? I.e., could CC_NCV be removed? I see that LT is apparently supported so why can't GT be too?

In , Mikpe (mikpe) wrote :

I have a preliminary patch which creates a clone of *arm_cmpdi_insn that does a reverse comparison, via a new CC mode for must-be-reversed comparisons, and corresponding updates to arm_select_cc_mode and get_arm_condition_code. It's the same transformation from eg (GT x y) to (LT y x) that cstoredi4 does, only later so it can handle problematic comparisons introduced by the middle-end.

This fixes the ICEs on the two test cases in this PR. I'll do a full bootstrap and regtest as soon as my test machine is done with its current bootstrap and regtest cycle.

I'll send the FSF Yet Another Ping about my employer's copyright disclaimer first thing tomorrow. They've had the papers since January or February...

Marcin Juszkiewicz (hrw) wrote :

16:44 hrw@malenstwo:ossplay$ cc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.6.real
COLLECT_LTO_WRAPPER=/usr/lib/arm-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-5ubuntu2' --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-multiarch --with-multiarch-defaults=arm-linux-gnueabi --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/arm-linux-gnueabi --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/arm-linux-gnueabi --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-5ubuntu2)
16:45 hrw@malenstwo:ossplay$ cc -c -O -DOGG_SUPPORT -Wall -DOSS_LITTLE_ENDIAN -I../../include -I../../kernel/framework/include -I../../kernel/OS/Linux -I../../kernel/nonfree/include -I../.. ossplay_decode.c -o ./ossplay_decode.o -save-temps
ossplay_decode.c: In function ‘decode_amplify’:
ossplay_decode.c:1002:1: internal compiler error: in get_arm_condition_code, at config/arm/arm.c:17488
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.

Changed in oss4 (Ubuntu):
status: New → Confirmed
Marcin Juszkiewicz (hrw) wrote :

Also fails with gcc-4.5 and gcc-snapshot

Michael Hope (michaelh1) wrote :

Thank you for the bug report. I've confirmed this with gcc-linaro-4.6-2011.08 on ARM:

michaelh@ursa1:~/linaro/bugs$ /tools/toolchains/arch/armv7l/gcc-linaro-4.6-2011.08-armv7l-natty-cbuild162-ursa1-cortexa9r1/bin/gcc -O2 -S ossplay_decode3.i
ossplay_decode.c: In function 'decode_amplify':
ossplay_decode.c:1002:1: internal compiler error: in get_arm_condition_code, at config/arm/arm.c:17488

It also fails at -O1 and -O3. The work-around is to compile with -O0 or -marm. The fault also exists in gcc-4.6.1 and trunk r178025. It does not exist in gcc-4.5.3. Could you please also report this in GCC bugzilla and attach it to this ticket?

I've set it to medium priority as it is a ftbfs, a work-around exists, and the fault exists upstream.

Changed in gcc-linaro:
status: New → Triaged
importance: Undecided → Medium
Michael Hope (michaelh1) on 2011-08-30
Changed in gcc-linaro:
assignee: nobody → Richard Sandiford (rsandifo)
Changed in gcc:
importance: Unknown → Medium
status: Unknown → Confirmed
Michael Hope (michaelh1) on 2011-09-07
Changed in gcc-linaro:
status: Triaged → In Progress

Author: rsandifo
Date: Wed Sep 7 13:48:03 2011
New Revision: 178636

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178636
Log:
gcc/
 PR target/49030
 * config/arm/arm-protos.h (maybe_get_arm_condition_code): Declare.
 * config/arm/arm.c (maybe_get_arm_condition_code): New function,
 reusing the old code from get_arm_condition_code. Return ARM_NV
 for invalid comparison codes.
 (get_arm_condition_code): Redefine in terms of
 maybe_get_arm_condition_code.
 * config/arm/predicates.md (arm_comparison_operator): Use
 maybe_get_arm_condition_code.

gcc/testsuite/
 PR target/49030
 * gcc.dg/torture/pr49030.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr49030.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm-protos.h
    trunk/gcc/config/arm/arm.c
    trunk/gcc/config/arm/predicates.md
    trunk/gcc/testsuite/ChangeLog

I am out of the office until September 19th. For emergencies please contact Fred Plante.

Michael Hope (michaelh1) on 2011-09-08
Changed in gcc-linaro:
milestone: none → 4.6-2011.09
In , Gjl (gjl) wrote :

Author: gjl
Date: Fri Sep 9 17:00:26 2011
New Revision: 178736

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178736
Log:
 PR target/49030
 * gcc.dg/torture/pr49030.c: Run only if target int32plus.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/torture/pr49030.c

Michael Hope (michaelh1) wrote :

Confirmed fixed.

Changed in gcc-linaro:
status: In Progress → Fix Committed
Michael Hope (michaelh1) wrote :

The fix was reverted due to LP: #850099

Changed in gcc-linaro:
status: Fix Committed → In Progress
milestone: 4.6-2011.09 → 4.6-2011.10
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package oss4 - 4.2-build2004-1ubuntu2

---------------
oss4 (4.2-build2004-1ubuntu2) oneiric; urgency=low

  * Build with -Wno-error=unused-but-set-variable. LP: #809761.
 -- Matthias Klose <email address hidden> Tue, 27 Sep 2011 11:57:01 +0200

Changed in oss4 (Ubuntu):
status: Confirmed → Fix Released
Matthias Klose (doko) wrote :

re-opening for oss4. the upload just fixed the build on the other architectures

Changed in oss4 (Ubuntu):
status: Fix Released → Confirmed
Michael Hope (michaelh1) on 2011-10-10
Changed in gcc-linaro:
status: In Progress → Fix Committed
Michael Hope (michaelh1) on 2011-10-13
Changed in gcc-linaro:
status: Fix Committed → Fix Released
Changed in oss4 (Debian):
status: Unknown → Confirmed
Changed in oss4 (Debian):
status: Confirmed → Fix Released

Fixed on trunk, and not marked as a regression.

Changed in gcc:
status: Confirmed → Fix Released
Jani Monoses (jani) wrote :

This seems to no longer FTBFS

Changed in oss4 (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.