Hi Clement,
>> This alone makes the patch inacceptable in its present form: breaking
>> the libstdc++ ABI is a non-starter. However, I suspect this can be
>> avoided somehow.
> Thanks for having tried and I agree the patch isn't ready at all. I've just
> wanted to see how behave on other systems and it seems that it might
> not work as is.
even if it did, this is certainly not stage3 material. However,
submitting the patch early gives us enough time to work out the issues
in time for GCC 12.
> However, is the C++ ABI not standard ? I don't have this test failing on
> AIX, AFAIK. Strange.
Not really: the ABI tests rely on symbol versioning, which is only
available on Solaris and GNU ELF targets.
>> +FAIL: 22_locale/classification/isblank.cc execution test
>>
>> /vol/gcc/src/hg/master/solaris/libstdc++-v3/testsuite/22_locale/classification/isblank.cc:38:
>> void test02(): Assertion 'std::isblank(L' ', std::locale::classic())'
>> failed.
>>
>> It turns out that this is caused by ieee_1003.1-2008/ctype_members.cc
>> using __bitmapsize = 11 in a couple of places, unlike the generic
>> version which uses 15 to accomodate variations in <ctype.h> character
>> classifications.
> 11 is the correct value on AIX and maybe also in Dragnofly/FreeBSD,
> based on the value of Dragonfly model. However, big endian vs little
> endian needs to be handled. I haven't fix that part on the current
> patch I guess. (when bitmapsize = 15, there is no difference, endianness
> doesn't matter). However, it might be simpler to set bitmapsize = 15
> for everyone, instead of having some defines for that. Maybe.
I guess so, because this matches what the generic version does:
obviously there are targets that need it depending in their <ctype.h>
constants, and Solaris may be just one of them.
OTOH, I wondered if it wouldn't be better to start from the GNU code
which is certainly known to work, rather than the DragonflyBSD one which
may well have bitrotten since most of the BSDs moved to LLVM. Then
again, it may not: Gerald tests on FreeBSD regularly. Perhaps a 3-way
merge of gnu and *bsd -> ieee_1003.1-2008 is in order?
>> However, there are many more which I haven't even started to
>> investigate. I suspect there's one (or a few) reasons immediately
>> obvious to someone familiar with the code.
> Thanks for the list. I'll check if there is some common with AIX. But
> wait until I push the new patch to start studying them.
> It'll have the correct #ifdef based on configure and I'll try it on Linux.
> Thus, it should be far better.
That has been my plan: you're obviously way more familiar with this code
than I am.
Thanks for doing all this work.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
