stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: ABI test results with gcc 3.4.3/Red Hat EL 4.4/12D
Date Mon, 21 Apr 2008 21:34:02 GMT
Travis Vitek wrote:
>  
> 
>> 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, 22.locale.numpunct.mt, 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?

No. (You did give a quite a scare for a minute there! These are
all regression tests, so they abort on the old, buggy behavior.
Changing behavior in a patch release is okay if the original
behavior is undefined or buggy (as always, there are going to
be exceptions).

The only one we might want to look into is 22.locale.messages,
but even that one, I suspect, is okay (most likely the result
of STDCXX-607).

Martin

> 
>> 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
>> 21.string.io.stdcxx-250             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.
> 
> Travis


Mime
View raw message