This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>
- Cc: Matthew Wahab <matthew dot wahab at arm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Mon, 2 Feb 2015 16:33:48 +0000
- Subject: Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.
- Authentication-results: sourceware.org; auth=none
- References: <54CF9C84 dot 4020706 at arm dot com> <54CFA31F dot 9020601 at oracle dot com>
On 2 February 2015 at 16:17, Paolo Carlini <email@example.com> wrote:
> On 02/02/2015 04:49 PM, Matthew Wahab wrote:
>> With target arm-none-eabi, the libstdc++ tests
>> 28_regex/traits/char/isctype.cc and 28_regex/traits/wchar/isctype.cc fail at
>> VERIFY(!t.isctype('\n', t.lookup_classname(range(blank))));
>> This is because libstdc++ puts '\n' in the 'space' character class, rather
>> than 'blank' when building on newlib. This problem was known when suport for
>> the blank character class was added to libstdc++ (see
>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01902.html) so this failure
>> is not unexpected.
>> Changes to newlib that would have allowed the problem to be fixed were
>> made (https://sourceware.org/ml/newlib/2009/msg00342.html) but then reverted
>> This patch modifies the test to add a special case for the behaviour with
>> Tested by running check-target-libstdc++-v3 -
>> libstdc++-dg/conformance.exp, with the modified tests, for arm-none-eabi and
>> aarch64-none-linux-gnu. No new failures and the modified tests now pass on
>> Ok for trunk?
This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 so please
note that in the ChangeLog.
> I guess the patch is Ok for trunk, but please also add in the comment a link
> to this message of yours, that is
> PS: please remember to always CC libstdc++-v3 patches to
Yes, not everyone subscribes to gcc-patches so please always send
libstdc++ patches to the libstdc++ list, as documented at
https://gcc.gnu.org/lists.html and in the libstdc++ manual.