stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: ABI test results with gcc 3.4.3/Red Hat EL 4.4/12D
Date Mon, 21 Apr 2008 20:52:19 GMT

>Martin Sebor wrote:
>Here's a list of all failing tests with 4.2.0 and 4.2.1, with
>backward and forward binary compatibility runs included in the
>second and third columns. Cells with n/a indicate that the test
>wasn't available in 4.2.0. Cells with A### indicate the number
>of failing assertions.
>The failures in 21.string.replace,, and
>22.locale.messages are possible sources of concern. The COMP
>failure in 26.valarray.cassign is a known problem that I plan
>to fix by deleting the test from 4.2.1.

I hate to be Captain Obvious here, but...

I thought that we had to maintain both forward and backward binary
compatibility for 4.2.1 and that binary compatibility included
functional compatibility. If that is what we are expecting doesn't that
mean that the failures below are breaking?

>gcc 3.4.3/RHEL 4.4/12D     SRC:   4.2.0   4.2.0   4.2.1   4.2.1
>                           LIB:   4.2.0   4.2.1   4.2.0   4.2.1
>             n/a     n/a    ABRT       0
>21.string.stdcxx-231                n/a     n/a    ABRT       0
>22.locale.codecvt.stdcxx-435        n/a     n/a    ABRT       0
>22.locale.messages                    0       0     HUP       0
>22.locale.num.put.stdcxx-2          n/a     n/a    ABRT       0
>27.basic.ios.copyfmt.stdcxx-766     n/a     n/a    ABRT       0
>27.filebuf.members.stdcxx-308       n/a     n/a    ABRT       0
>27.ostream.unformatted.stdcxx-626   n/a     n/a    ABRT       0
>27.stringbuf.overflow.stdcxx-795    n/a     n/a    ABRT       0

If the user compiles an app with 4.2.1 and then rolls back to the 4.2.0
library they should expect everything to work, right? That would suck if
their aborted or hung on them like the above test are doing.


View raw message