RE: Testsuite warnings about wchar_t

> On Fri, Feb 27, 2004 at 01:39:57PM +1100, Billinghurst, David (CALCRTS) wrote:
>> I have just enabled testing of the -o32 ABI on my irix6.5 testsuite runs
>> See http://gcc.gnu.org/ml/gcc-testresults/2004-02/msg01329.html
>> for an example.
>> 
>> Most of the libstdc++ testsuite failures are due to the absence of 
>> wchar support in the -o32 ABI.  Is there a way to disable of XFAIL 
>> these tests for only one of the three ABI under test?
>
> If wchar isn't supported, then configure should be turning it off.  If it
> isn't, then there will be a zero-length objdir/testsuite/testsuite_wchar_t
> file indicating that the wchar tests should be run.  You'll need to look in
> config.log for why they are remaining enabled.  In the meantime, configure
> with --disable-c-mbchar to force them off.

Thanks.  I see that:
 - libstdc++-v3/testsuite/testsuite_wchar_t exists
 - libstdc++-v3/mabi=64/testsuite/testsuite_wchar_t exists
 - libstdc++-v3/mabi=32/testsuite/testsuite_wchar_t doesn't exist
which is correct, but the tests are still run for mabi=32.

I have logged this as Bug 14353 and see what I can do to fix it. (Oh joy).

Patch for libstdc++/14353 libstdc++ wchar tests run for -mabi=32

The following patch fixes libstdc++/14353 by using the testsuite_files in the 
correct multilib directory.

Tested on mips-sgi-irix6.5 for 3.4 branch with 
	RUNTESTFLAGS='--target_board \"unix{-mabi=32,,-mabi=64}\"'

2004-03-01  David Billinghurst <David.Billinghurst <at> riotinto.com>

	* testsuite/lib/libstdc++.exp: Use testsuite_files from
	correct multilib blddir when running testsuite

 Index: testsuite/lib/libstdc++.exp
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/testsuite/lib/libstdc++.exp,v
retrieving revision 1.15
diff -u -r1.15 libstdc++.exp
--- testsuite/lib/libstdc++.exp 12 Jan 2004 20:47:44 -0000      1.15
+++ testsuite/lib/libstdc++.exp 1 Mar 2004 03:36:50 -0000
 <at>  <at>  -246,9 +246,14  <at>  <at> 
 proc v3-list-tests { filename } {
     global srcdir
     global outdir
+    global blddir

-    set tests_file "${outdir}/${filename}"
+    set tests_file "${blddir}/testsuite/${filename}"
     set sfiles ""
+
+    verbose -log "In v3-list-tests"
+    verbose -log "blddir = ${blddir}"

Re: Patch for libstdc++/14353 libstdc++ wchar tests run for -mabi=32

On Mon, Mar 01, 2004 at 02:46:58PM +1100, Billinghurst, David (CALCRTS) wrote:
> The following patch fixes libstdc++/14353 by using the testsuite_files in the 
> correct multilib directory.
> 
> Tested on mips-sgi-irix6.5 for 3.4 branch with 
> 	RUNTESTFLAGS='--target_board \"unix{-mabi=32,,-mabi=64}\"'
> 
> 2004-03-01  David Billinghurst <David.Billinghurst <at> riotinto.com>
> 
> 	* testsuite/lib/libstdc++.exp: Use testsuite_files from
> 	correct multilib blddir when running testsuite

Works for now.  (I think there's another way to do this that will let us
remove code, but that's for the future.)  Don't forget to put a period on
the end of the ChangeLog sentence.

--

-- 
America may be unique in being a country which has leapt
from barbarism to decadence without touching civilization.
  - John O'Hara

[Patch] Fix a minor instance of Martin's ordering issue

Hi,

forgot about the exponent sign.

Tested x86-linux, will commit soon together with the last one.

Paolo.

//////////////

2004-03-01  Paolo Carlini  <pcarlini <at> suse.de>

	* include/bits/locale_facets.tcc (num_get<>::_M_extract_float):
	Also when parsing exponent sign, first look for thousands_sep
	and decimal_point; tweak a bit.
	* testsuite/22_locale/num_get/get/char/15.cc: New.
	* testsuite/22_locale/num_get/get/wchar_t/15.cc: New.

diff -urN libstdc++-v3-curr/include/bits/locale_facets.tcc libstdc++-v3/include/bits/locale_facets.tcc
--- libstdc++-v3-curr/include/bits/locale_facets.tcc	2004-02-29 23:53:29.000000000 +0100
+++ libstdc++-v3/include/bits/locale_facets.tcc	2004-03-01 09:43:18.000000000 +0100
 <at>  <at>  -221,7 +221,6  <at>  <at> 
       if (__lc->_M_use_grouping)
 	__found_grouping.reserve(32);
       int __sep_pos = 0;
-      bool __e;
       const char_type* __lit_zero = __lit + _S_izero;
       const char_type* __q;
       while (__beg != __end)

Re: [RFC/Patch] libstdc++/14320 aka class type streamoff doesn't work :(

On Fri, Feb 27, 2004 at 07:57:18PM +0100, Gabriel Dos Reis wrote:

> One of the testcase says that operator*= is not defined.  Another
> wanted to insert or extract. It occurs to me that thr right course of
> action is to provide those instead of removing the class.

One issue that can't be fixed by providing the necessary operators is:

    #include <ios>

    struct A
    {
        static const std::streamoff n = 4;
    };

I used to be able to use std::streamoff like this, e.g. to hold the
number of putback characters suported in my stream class, or the
buffer size. [*]

Unless std::streamoff is an integral type (in the builtin sense) then
in-class initialisation of static consts won't work.  Should it?

It seems to me that the above code is legal, and not unreasonable, but
will fail on GCC 3.4 [**]

jon

[*]
I realise an unsigned type would work for this, but I need to compare
the value with the result of pointer arithmetic, and since streamoff

RE: [RFC/Patch] libstdc++/14320 aka class type streamoff doesn't work :(

Paolo Carlini wrote:
> Thus the below: it seems to me that the best we can do for streamoff is
> essentially returning to what we had in 3_3. This implies giving away
> some type safety (i.e., some QoI) and also that the issue with LFS is
> still there, but otherwise seems OK. On glibc platforms we get an XPASS,
> since int64t is actually a typedef for long long.

This patch seems reasonable to me given the current release plan for
3.4.

A minor nitpick:

 <at>  <at>  -204,7 +111,7  <at>  <at> 
       // conversion. In this implementation this constructor stores
       // the integer as the offset and default constructs the state.
       /// Construct position from integer.
-      fpos(__streamoff_base_type __off)
+      fpos(int __off)
       : _M_off(__off), _M_state() { }

       // The standard requires that fpos objects can be constructed
 <at>  <at>  -214,9 +121,12  <at>  <at> 
       // constructor stores the streamoff as the offset and default
       // constructs the state.
       /// Construct position from offset.
-      fpos(const streamoff& __off)
+      fpos(streamoff __off)
       : _M_off(__off), _M_state() { }

If streamoff is an integral type, it should be sufficient to have only

Re: [libstdc++ 1/2] Add testsuite comments, shuffle a bit of code.

Hi Phil,

while you are working on the collate tests and, more generally
the testsuite... I wonder which is your take on this (serious,
IMHO) issue:

    http://gcc.gnu.org/ml/libstdc++/2004-02/msg00100.html

???

Thanks,
Paolo.

Re: [Patch] Fix the narrow/widen problem in money_get::do_get

Paolo Carlini wrote:

> Martin Sebor wrote:
> 
>> More importantly, do you know of any locales where there
>> are two or more characters that ctype narrows to the same digit?
> 
> 
> See:
> 
>    http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#303
> 

I assume you are referring to this:

     "... in the Unicode representation of the Devanagari script
     (used in many of the Indic languages) the digit 0 is 0x0966,
     and the digit 1 is 0x0967. Calling narrow would translate
     those into '0' and '1'.

Yes, that's the example I was trying to recall. Thanks for pointing
it out.

I don't think the example is terribly relevant anymore, though,
or that the text above is entirely correct. I'm not aware of any
requirement that says that any wide character with value greater
than 0xff must be successfully narrowed to anything at all (other
than the default). Even if narrow() did do that (it might or it
may not), I am not convinced that there would be anything wrong
with it. It might be helpful to do a survey of scanf() behavior

Re: Patch for libstdc++/14353 libstdc++ wchar tests run for -mabi=32

David, thanks for fixing this.

I'd like to add some docs to libstdc++ to explain how to test multilibs,
based on your experiences. Can you (or Kaveh?) help me with this? I have
no experience testing multilibs.

>2004-03-01  David Billinghurst <David.Billinghurst <at> riotinto.com>
>
>	* testsuite/lib/libstdc++.exp: Use testsuite_files from
>	correct multilib blddir when running testsuite

2004-03-01  Benjamin Kosnik  <bkoz <at> redhat.com>

	* docs/html/test.html: Add multilib RUNTESTFLAGS example.

Index: docs/html/test.html
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/docs/html/test.html,v
retrieving revision 1.8
diff -c -p -r1.8 test.html
*** docs/html/test.html	22 Dec 2003 20:09:21 -0000	1.8
--- docs/html/test.html	1 Mar 2004 17:25:32 -0000
*************** or
*** 477,487 ****
  make check-target-libstdc++-v3 RUNTESTFLAGS="-v -v"
  </pre>

  There are two ways to run on a simulator: set up DEJAGNU to point to a

[v3] autoconf 2.59 fixups

tested x86/linux

...this allows the current top-of-release-tree autoconf to work with libstdc++. 

Automake, however, still has problems, see below. If somebody will be so
kind as to tell me how to fixup this bit, I'll do that too.

%automake --version
automake (GNU automake) 1.8.2

%automake
Makefile.am:63: user variable `MULTISRCTOP' defined here...
/mnt/hd/bld/H-x86-autotools/share/automake-1.8/am/multilib.am: ... overrides Automake variable
`MULTISRCTOP' defined here
Makefile.am:64: user variable `MULTIBUILDTOP' defined here...
/mnt/hd/bld/H-x86-autotools/share/automake-1.8/am/multilib.am: ... overrides Automake variable
`MULTIBUILDTOP' defined here
Makefile.am:65: user variable `MULTIDIRS' defined here...
/mnt/hd/bld/H-x86-autotools/share/automake-1.8/am/multilib.am: ... overrides Automake variable
`MULTIDIRS' defined here
Makefile.am:66: user variable `MULTISUBDIR' defined here...
/mnt/hd/bld/H-x86-autotools/share/automake-1.8/am/multilib.am: ... overrides Automake variable
`MULTISUBDIR' defined here
Makefile.am:67: user variable `MULTIDO' defined here...
/mnt/hd/bld/H-x86-autotools/share/automake-1.8/am/multilib.am: ... overrides Automake variable
`MULTIDO' defined here
Makefile.am:68: user variable `MULTICLEAN' defined here...
/mnt/hd/bld/H-x86-autotools/share/automake-1.8/am/multilib.am: ... overrides Automake variable
`MULTICLEAN' defined here