On 10 September 2012 07:34, Mark Kettenis wrote:
>> Date: Sun, 9 Sep 2012 21:07:39 +0100
>> From: Jonathan Wakely <jwakely....@gmail.com>
>>
>> On 4 September 2012 20:26, Mark Kettenis wrote:
>> > Fixes a few testcases.  Mostly based on the existing
>> > NetBSD/FreeBSD/Darwin code.
>> >
>> > 2012-09-04  Mark Kettenis  <kette...@openbsd.org>
>> >
>> >         * configure.host (*-*-openbsd*) Set cpu_include_dir.
>> >         * config/os/bsd/openbsd/ctype_base.h: New file.
>> >         * config/os/bsd/openbsd/ctype_configure_char.cc: New file.
>> >         * config/os/bsd/openbsd/ctype_inline.h: New file.
>> >         * config/os/bsd/openbsd/os_defines.h: New file.
>>
>> This patch is OK, thanks.  Do you want me to commit it for you?
>
> Yes please.

It occurs to me now that the patch changes the size of
ctype_base::mask, from the generic unsigned to char. I assume the
OpenBSD system compiler uses char? How long has that change been
present in the OpenBSD source tree?

I'm not sure whether or not it's better to change the size of that
type in GCC 4.8, which would break compatibility with previous
versions of the FSF sources but provide compatibility with the OpenBSD
system compiler.  My guess would be that most people on OpenBSD are
using the system compiler not upstream FSF sources.

>> It shouoldn't stop the patch going in, but I assume that this test
>> fails on OpenBSD even with your patch applied?
>>
>> #include <locale>
>> #include <assert.h>
>>
>> class gnu_ctype: public std::ctype<wchar_t> { };
>>
>> int main()
>> {
>>   gnu_ctype gctype;
>>
>>   assert(gctype.is(std::ctype_base::xdigit, L'a'));
>> }
>
> Interestingly enough, it doesn't fail without my diff.  But it does
> fail for OpenBSD's system compiler (GCC 4.2.1 with a lot of local
> modifications).  As far as I can determine this is the result of
> ctype_base::mask being an 8-bit integer type which doesn't go well
> with the generic ctype_members.cc implementation.  Probably need to
> have an OpenBSD-specific implementation just like newlib.  Looking
> into that now.

See http://gcc.gnu.org/PR51772 (the original description gets the
cause wrong, see comment 3 for the real problem)

Reply via email to