This page summarizes regressions over the FSF toolchain discovered while testing the Linaro GCC branch in Ubuntu.

Last test results were compiled by Matthias Klose on Mon, 14 Jun 2010 11:40:42 +0200 as a result of his tests in the ~ubuntu-toolchain-r maverick PPA.

To install this toolchain add these sources.list entries:

    deb     http://ppa.launchpad.net/ubuntu-toolchain-r/ppa/ubuntu maverick main
    deb-src http://ppa.launchpad.net/ubuntu-toolchain-r/ppa/ubuntu maverick main

This is a toolchain built from current maverick gcc-4.4 packages + CodeSourcery 4.4.4 diff, which is what Linaro GCC currently carries (will progressively diverge from that).

Compatibility with Ubuntu patches and packaging

Description

Status

CS licensing patches

Patch reverting has been done by Yao.

missing HTML and PDF docs

Linaro diff removes autogenerated release files, misses some docs; solution 1: add build-deps to build these; solution 2: release proper Linaro GCC tarballs with the docs; solution 2 was chosen; need to check with doko what he wants here, probably solved by releasing tarballs like the FSF ones

CS changes to install html and pdf docs

proposing not to include these in the Linaro branch, (or needs reversion in the packages, we don't want to build these on every architecture. rename-info-files.diff would need an update to pass the fn* vars; fine if Linaro wants to address this). Need to identify patch and consider reversion; doko will provide further details

change of installation locations (libgcj.spec) breaks packaging

proposing to revert this in Linaro. Need to identify patch and consider reversion; check actual issue with doko. Small patch where installation location is changed in the CS branch

conflicts with cell-4_4-branch

update is prerequisite to use the Linaro GCC on powerpc
uweigand sent an updated cell-branch.diff to doko

gcc-cloog-dl patch (avoid direct dependency on cloog/ppl libs)

adjusted by doko

mips-fix-loongson2f-nop (requested by the Debian mips porters)

adjusted by doko

gcc-arm-thumb2-sched

All of 3 parts of this patch has been checked in linaro-gcc-4.4 tree by Yao.

arm-gcc-gcse

adjusted by doko, needs to be addressed/upstreamed by Linaro; lool to clarify with ams whether we intended to rewrite

libstdc++-arm-no-check (disable running the libstdc++ testsuite for Ubuntu buildd hardware)

adjusted by doko

patches already in Linaro GCC: sh4-scheduling, pr42748, pr42321

disabled by doko, in 4.5 and CS

gcc-multiarch-i686

adjusted by doko

CS HTML PDF: debian/patches/rename-info-files.diff This Ubuntu patch only covers .info files, and needs to be extended for HTML and PDF files CS defaults to turning on HTML and PDF outputs

14:27 <doko> Index: libjava/Makefile.in
14:27 <doko> ===================================================================
14:27 <doko> --- a/src/libjava/Makefile.in   (revision
14:27 <doko> +++ b/src/libjava/Makefile.in   (working
14:27 <doko> @@ -825,8 +825,14 @@
14:27 <doko>         $(am__append_2) $(am__append_3)
14:27 <doko>  toolexecmainlib_DATA = libgcj.spec
14:28 <doko>  dbexec_LTLIBRARIES = libjvm.la
14:28 <doko> -pkgconfigdir = $(libdir)/pkgconfig
14:28 <doko> -jardir = $(datadir)/java
14:28 <doko> +
14:28 <doko> +# Install the pkgconfig file in a target-specific directory, 
             since the
14:28 <doko> +# libraries it indicates
14:28 <doko> +pkgconfigdir = $(toolexeclibdir)/pkgconfig
14:28 <doko> +
14:28 <doko> +# We install the JAR in a target-specific directory so that 
             toolchains
14:28 <doko> +# build from different sources can be installed in the same 
             directory.
14:28 <doko> +jardir = $(prefix)/$(target_noncanonical)/share/java
14:28 <doko>  jar_DATA = libgcj-$(gcc_version).jar 
             libgcj-tools-$(gcc_version).jar \
14:28 <doko>         $(am__append_4)
14:28 <doko>  @[email protected]_HOME_DIR = $(prefix)

Color

Legend

lightgreen

Good way forward; perhaps some easy work remains

skyblue

Low risk workaround / Can address later

yellow

Solution identified, needs some work

lightpink

No data, needs investigation

GCC 4.4 Testsuite

Architectures

Description

Status

Bug

amd64, i386

+FAIL: g++.dg/eh/pr42859.C (test for excess errors)

ams: only unexpected warnings, harmless; ams to provide a separate Ubuntu packaging patch to update the testsuite for the Ubuntu toolchain defaults

#602168

amd64, i386

+FAIL: g++.dg/eh/ref1.C (test for excess errors)
+FAIL: g++.dg/eh/ref2.C (test for excess errors)

ams: only unexpected warnings caused by the Ubuntu defaults, harmless; ams to provide a separate Ubuntu packaging patch to update the testsuite for the Ubuntu toolchain defaults

#602168

i386

+FAIL: gcc.target/i386/pr9771-1.c (test for excess errors)
+UNRESOLVED: gcc.target/i386/pr9771-1.c compilation failed to produce executable

ams: CS #6246; testcase appears to be broken; michaelh backported patch from upstream into gcc-linaro
2010-05-24 Paul Brook <[email protected]>
* gcc.target/arm/frame-pointer-1.c: New test.
* gcc.target/i386/pr9771-1.c: Move code out of main to allow frame pointer elimination.

#602171

amd64

+XPASS: obj-c++.dg/bitfield-1.mm PR23610 (test for bogus messages, line 1)
+FAIL: obj-c++.dg/bitfield-1.mm (test for excess errors)
+XPASS: obj-c++.dg/bitfield-4.mm PR23610 (test for bogus messages, line 1)
+FAIL: obj-c++.dg/bitfield-4.mm (test for excess errors)
+XPASS: obj-c++.dg/layout-1.mm PR23610 (test for bogus messages, line 1)
+FAIL: obj-c++.dg/layout-1.mm (test for excess errors)

ams: Each pair of failures is due to a change in the way the line number is counted in the error message:
it's looking for:
<built-in>:1: warning: padding struct to align ......
but gets:
<built-in>:0: warning: padding struct to align ......
I'm not sure if this is an off-by-one error, or whether the line number has been lost somehow, or if the new version is correct or incorrect. Whatever, it isn't terribly serious. ams to provide a patch to update warnings' line numbers

#602174

armel

-FAIL: g++.dg/cpp0x/initlist13.C (test for excess errors)
-FAIL: g++.dg/cpp0x/initlist25.C (test for excess errors)
-FAIL: g++.dg/cpp0x/variadic-tuple.C (test for excess errors)

doko to update expected testsuite results for this new successful tests (only when the Linaro patch is applied)

-

armel

+FAIL: g++.dg/eh/pr42859.C (test for excess errors)
+FAIL: g++.dg/eh/ref1.C (test for excess errors)
+FAIL: g++.dg/eh/ref2.C (test for excess errors)

ams: presumably identical to i386; see above

#602168

armel

+FAIL: g++.dg/vect/pr36648.cc scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: g++.dg/vect/pr36648.cc scan-tree-dump-times vect "vectorizing stmts using SLP" 1

ams: might be CS #3365, ARM C++ ABI causes trouble for the vectorizer; problem might be fixed upstream in 4.5 (?) already
ams recommends adding expected failure for now; doko to add expected failure for now

#602186

armel

+FAIL: gcc.dg/autopar/reduc-1.c scan-tree-dump-times parloops "Detected reduction" 3
+FAIL: gcc.dg/autopar/reduc-1.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 3
+FAIL: gcc.dg/autopar/reduc-1char.c scan-tree-dump-times parloops "Detected reduction" 3
+FAIL: gcc.dg/autopar/reduc-1char.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 3
+FAIL: gcc.dg/autopar/reduc-1short.c scan-tree-dump-times parloops "Detected reduction" 3
+FAIL: gcc.dg/autopar/reduc-1short.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 3
+FAIL: gcc.dg/autopar/reduc-2.c scan-tree-dump-times parloops "Detected reduction" 3
+FAIL: gcc.dg/autopar/reduc-2.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 3
+FAIL: gcc.dg/autopar/reduc-2char.c scan-tree-dump-times parloops "Detected reduction" 2
+FAIL: gcc.dg/autopar/reduc-2char.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 2
+FAIL: gcc.dg/autopar/reduc-2short.c scan-tree-dump-times parloops "Detected reduction" 2
+FAIL: gcc.dg/autopar/reduc-2short.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 2
+FAIL: gcc.dg/autopar/reduc-6.c scan-tree-dump-times parloops "FAILED: it is not a part of reduction" 3

ams: probably CS #6663; cause unknown, failure expected; doko to add expected failure for now

#602190

armel

-FAIL: gcc.dg/sibcall-3.c execution test
-FAIL: gcc.dg/sibcall-4.c execution test

ams: the tests no longer fail; doko to add expected passes when Linaro patch is applied

-

armel

+FAIL: gcc.dg/Warray-bounds-3.c (test for excess errors)

ams: CS #5156; unexpected warning messages (unrelated to above). Not easy to fix, and depends on -funroll-loops. Should be an expected failure. doko to add expected failure for now

#602277

armel

+FAIL: gcc.dg/tree-ssa/predcom-3.c scan-tree-dump-times pcom "Unrolling 3 times." 1
+FAIL: gcc.dg/tree-ssa/predcom-4.c scan-tree-dump-times pcom "Unrolling 3 times." 1
+FAIL: gcc.dg/tree-ssa/predcom-5.c scan-tree-dump-times pcom "Unrolling 3 times." 1

ams: CS #5157; the testcases need to be fixed, but a gcc driver bug is in the way. doko to add as expected failures.

#602285

armel

+FAIL: gcc.dg/vect/vect-align-2.c scan-tree-dump-times vect "vectorized 1 loops" 1
+FAIL: gcc.dg/vect/vect-outer-4c.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 1
+FAIL: gcc.dg/vect/vect-outer-5.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED" 1
+FAIL: gcc.dg/vect/vect-outer-5.c scan-tree-dump-times vect "zero step in outer loop." 1
+FAIL: gcc.dg/vect/slp-3.c scan-tree-dump-times vect "vectorized 3 loops" 1
+FAIL: gcc.dg/vect/slp-3.c scan-tree-dump-times vect "vectorizing stmts using SLP" 3
+FAIL: gcc.dg/vect/no-vfa-pr29145.c scan-tree-dump-times vect "vectorized 0 loops" 2
+FAIL: gcc.dg/vect/no-vfa-pr29145.c scan-tree-dump-times vect "vectorized 1 loops" 1

jsm28: a lot of this kind of thing may be fixed upstream; not a correctness issue, and hard to backport according to uweigand; deferred to Linaro 4.5 branch

#602287

armel

+XPASS: gcc.dg/vect/no-scevccp-outer-8.c scan-tree-dump-times vect "OUTER LOOP VECTORIZED." 1
-FAIL: gcc.target/arm/mmx-1.c (test for excess errors)
-ERROR: gcc.target/arm/mmx-1.c: error executing dg-final: couldn't open "mmx-1.s": no such file or directory
-UNRESOLVED: gcc.target/arm/mmx-1.c: error executing dg-final: couldn't open "mmx-1.s": no such file or directory
-FAIL: gcc.target/arm/sibcall-1.c scan-assembler \\tb\\tfunc2(\\\\(PLT\\\\))?\\n

ams: fixed tests. Expected results need to be updated. doko to update testsuite for these progressions when the Linaro patch is applied.

-

armel

+FAIL: gcc.target/arm/vfp-ldmias.c scan-assembler fldmias
+FAIL: gcc.target/arm/vfp-stmias.c scan-assembler fstmias

ams: missed optimizations, not a correctness issue. doko to add expected failure for now

#602288

armel

+FAIL: gcc.target/arm/neon/vadds64.c scan-assembler vadd.i64[\\t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \\t][email protected][a-zA-Z0-9 ]+)?\\n
+FAIL: gcc.target/arm/neon/vaddu64.c scan-assembler vadd.i64[\\t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \\t][email protected][a-zA-Z0-9 ]+)?\\n
+FAIL: gcc.target/arm/neon/vands64.c scan-assembler vand[\\t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \\t][email protected][a-zA-Z0-9 ]+)?\\n
+FAIL: gcc.target/arm/neon/vandu64.c scan-assembler vand[\\t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \\t][email protected][a-zA-Z0-9 ]+)?\\n
+FAIL: gcc.target/arm/neon/veors64.c scan-assembler veor[\\t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \\t][email protected][a-zA-Z0-9 ]+)?\\n
+FAIL: gcc.target/arm/neon/veoru64.c scan-assembler veor[\\t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \\t][email protected][a-zA-Z0-9 ]+)?\\n
+FAIL: gcc.target/arm/neon/vorrs64.c scan-assembler vorr[\\t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \\t][email protected][a-zA-Z0-9 ]+)?\\n
+FAIL: gcc.target/arm/neon/vorru64.c scan-assembler vorr[\\t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \\t][email protected][a-zA-Z0-9 ]+)?\\n
+FAIL: gcc.target/arm/neon/vsubs64.c scan-assembler vsub.i64[\\t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \\t][email protected][a-zA-Z0-9 ]+)?\\n
+FAIL: gcc.target/arm/neon/vsubu64.c scan-assembler vsub.i64[\\t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \\t][email protected][a-zA-Z0-9 ]+)?\\n

jsm28: CS #8399; Thumb-2 specific but Ubuntu defaults to Thumb-2; being fixed upstream by Sandra. Sandra sent the fix: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02101.html http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02102.html
uweigand backported to 4.4; need to backport to 4.5.

#602289

armel

+FAIL: gfortran.dg/vect/vect-2.f90 -O scan-tree-dump-times vect "Alignment of access forced using peeling" 3
+FAIL: gfortran.dg/vect/vect-2.f90 -O scan-tree-dump-times vect "Vectorizing an unaligned access" 2
+FAIL: gfortran.dg/vect/vect-3.f90 -O scan-tree-dump-times vect "Alignment of access forced using peeling" 1
+FAIL: gfortran.dg/vect/vect-3.f90 -O scan-tree-dump-times vect "Vectorizing an unaligned access" 1
+FAIL: gfortran.dg/vect/vect-4.f90 -O scan-tree-dump-times vect "Alignment of access forced using peeling" 1
+FAIL: gfortran.dg/vect/vect-4.f90 -O scan-tree-dump-times vect "Vectorizing an unaligned access" 1
+FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect "Alignment of access forced using peeling" 1
+FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect "Vectorizing an unaligned access" 1

CS to reproduce; doesn't usually test fortran, so no prior CS data on this;
ams to reproduce

ams: I've looked at these briefly now; it seems that the vectorizer isn't working how the tests expect. I'm not sure how, or why, but it seems to be an optimization rather than a correctness issue. It could be related to one of the issues above. Whatever, it seems low-risk.

#602291

Color

Legend

lightgreen

Good way forward; perhaps some easy work remains

skyblue

Low risk workaround / Can address later

yellow

Solution identified, needs some work

lightpink

No data, needs investigation

WorkingGroups/ToolChain/UbuntuRegressions (last modified 2010-07-12 18:55:28)