Paolo Carlini | 1 Oct 15:00 2003
Picon

[Patch] Fix libstdc++/12439

Hi,

seems quite straightforward to me.

Tested x86-linux, if nobody objects will commit later today.

Paolo.

///////////
2003-10-01  Paolo Carlini  <pcarlini <at> unitus.it>

	PR libstdc++/12439
	* include/bits/locale_facets.tcc (time_put::put): Deal
	with the three issues pointed out by the PR.
	* testsuite/22_locale/time_put/put/char/12439_1.cc: New.
	* testsuite/22_locale/time_put/put/char/12439_3.cc: New.
	* testsuite/22_locale/time_put/put/wchar_t/12439_1.cc: New.
	* testsuite/22_locale/time_put/put/wchar_t/12439_2.cc: New.
	* testsuite/22_locale/time_put/put/wchar_t/12439_3.cc: New.
diff -urN libstdc++-v3-orig/include/bits/locale_facets.tcc libstdc++-v3/include/bits/locale_facets.tcc
--- libstdc++-v3-orig/include/bits/locale_facets.tcc	2003-09-30 13:38:47.000000000 +0200
+++ libstdc++-v3/include/bits/locale_facets.tcc	2003-10-01 14:20:52.000000000 +0200
 <at>  <at>  -2000,21 +2000,20  <at>  <at> 
   template<typename _CharT, typename _OutIter>
     _OutIter
     time_put<_CharT, _OutIter>::
-    put(iter_type __s, ios_base& __io, char_type, const tm* __tm, 
(Continue reading)

Benjamin Kosnik | 1 Oct 16:06 2003
Picon

Re: [Patch] Fix libstdc++/12439


looks good!

Martin Beaudoin | 1 Oct 16:20 2003
Picon

hash_map with unsigned long long keys

Hello,

I need to use a hash_map with unsigned long long keys.

Currently, this type of key is not supported by libstdc++.

I would like to propose the following addition to the file
gcc/libstdc++-v3/include/ext/hash_fun.h:

---------------------------------------------------------------------------------

template<> struct hash<long long> {
   size_t operator()(long long __x) const { return __x; }
};
template<> struct hash<const long long> {
   size_t operator()(const long long __x) const { return __x; }
};

template<> struct hash<unsigned long long> {
   size_t operator()(unsigned long long __x) const { return __x; }
};
template<> struct hash<const unsigned long long> {
   size_t operator()(const unsigned long long __x) const { return __x; }
};

----------------------------------------------------------------------------------

This simple addition on my local development system gave me the expected 
  functionnality currently missing with g++ hash_maps.

(Continue reading)

Paolo Carlini | 1 Oct 16:26 2003
Picon

Re: hash_map with unsigned long long keys

Martin Beaudoin wrote:

> Hello,
>
> I need to use a hash_map with unsigned long long keys.
>
> Currently, this type of key is not supported by libstdc++.
>
> I would like to propose the following addition to the file
> gcc/libstdc++-v3/include/ext/hash_fun.h: 

Hi. There is already a PR about this: libstdc++/12338. I have already
analyzed it a bit and I'm not sure that the fixes you propose (which
indeed come immediately to mind) are completely correct: it looks like
somewhere else there is the hidden assumption that long is the largest type.
I have to investigate the issue a little bit more: in case your solution
turns out to be ok, you will properly acknowledged, of course.

Paolo.

Nathan Myers | 1 Oct 18:20 2003

Re: [Patch] Fix libstdc++/12439

Hi Paolo,

Sorry, I see problems with this patch.  Comments interspersed.

On Wed, Oct 01, 2003 at 03:00:08PM +0200, Paolo Carlini wrote:
> Tested x86-linux, if nobody objects will commit later today.
> 
> ///////////

> 2003-10-01  Paolo Carlini  <pcarlini <at> unitus.it>
> 
> 	PR libstdc++/12439
> 	* include/bits/locale_facets.tcc (time_put::put): Deal
> 	with the three issues pointed out by the PR.
> 	* testsuite/22_locale/time_put/put/char/12439_1.cc: New.
> 	* testsuite/22_locale/time_put/put/char/12439_3.cc: New.
> 	* testsuite/22_locale/time_put/put/wchar_t/12439_1.cc: New.
> 	* testsuite/22_locale/time_put/put/wchar_t/12439_2.cc: New.
> 	* testsuite/22_locale/time_put/put/wchar_t/12439_3.cc: New.
> diff -urN libstdc++-v3-orig/include/bits/locale_facets.tcc libstdc++-v3/include/bits/locale_facets.tcc
> --- libstdc++-v3-orig/include/bits/locale_facets.tcc	2003-09-30 13:38:47.000000000 +0200
> +++ libstdc++-v3/include/bits/locale_facets.tcc	2003-10-01 14:20:52.000000000 +0200
>  <at>  <at>  -2000,21 +2000,20  <at>  <at> 
>    template<typename _CharT, typename _OutIter>
>      _OutIter
>      time_put<_CharT, _OutIter>::
> -    put(iter_type __s, ios_base& __io, char_type, const tm* __tm, 
> +    put(iter_type __s, ios_base& __io, char_type __fill, const tm* __tm, 
>  	const _CharT* __beg, const _CharT* __end) const
>      {
(Continue reading)

Paolo Carlini | 1 Oct 18:35 2003
Picon

Re: [Patch] Fix libstdc++/12439

Nathan Myers wrote:

>> 	  else
>>-	    {
>>-	      *__s = __c;
>>-	      ++__s;
>>-	    }
>>+	    *__s++ = *__tmp;
>> 	}
>>       return __s;
>>     }
>>    
>>
>
>This last delta is suboptimal.  Post-increment is quite expensive on 
>many iterator types.  Code that takes general iterator types should
>always use pre-increment.  Any use of post-increment where we don't 
>know the iterator type should be considered a performance bug.
>  
>
Hi. Ok for this. I'd rather prefer not answering in public the other part...

Paolo.

Martin Sebor | 1 Oct 18:52 2003

Re: [Patch] Fix libstdc++/12439

Nathan Myers wrote:

...
>>   template<typename _CharT, typename _OutIter>
>>     _OutIter
>>     time_put<_CharT, _OutIter>::
>>-    put(iter_type __s, ios_base& __io, char_type, const tm* __tm, 
>>+    put(iter_type __s, ios_base& __io, char_type __fill, const tm* __tm, 
>> 	const _CharT* __beg, const _CharT* __end) const
>>     {
>>       locale __loc = __io.getloc();
>>       ctype<_CharT> const& __ctype = use_facet<ctype<_CharT> >(__loc);
>>       while (__beg != __end)
>> 	{
>>-	  char __c = __ctype.narrow(*__beg, 0);
>>+	  const _CharT* __tmp = __beg;
>> 	  ++__beg;
>>-	  if (__c == '%')
>>+	  if (__ctype.narrow(*__tmp, 0) == '%' && __beg != __end)
>> 	    {
>> 	      char __format;
>> 	      char __mod = 0;
>>-	      size_t __len = 1; 
>>-	      __c = __ctype.narrow(*__beg, 0);
>>+	      const char __c = __ctype.narrow(*__beg, 0);
>> 	      ++__beg;
>> 	      if (__c == 'E' || __c == 'O')
>> 		{
> 
> 
(Continue reading)

Rainer Orth | 1 Oct 21:18 2003
Picon
Picon

3.4 PATCH: Properly check for lrand48 in libstdc++-v3

Looking into mips-sgi-irix6.5o32 testsuite failures compared to the basic
mips-sgi-irix6.5 configuration, I noticed several of the following:

FAIL: g++.dg/init/array4.C (test for excess errors)
Excess errors:
In file included from /var/tmp/gcc-obj/gcc-3.4-20030807/6.5o32-cc-gas/mips-sgi-irix6.5o32/libstdc++-v3/include/algorithm:69,
                 from /var/tmp/gcc-obj/gcc-3.4-20030807/6.5o32-cc-gas/mips-sgi-irix6.5o32/libstdc++-v3/include/string:56,
                 from
/.vol/gcc/src/gcc-dist/gcc/testsuite/g++.dg/init/array4.C:8:
/var/tmp/gcc-obj/gcc-3.4-20030807/6.5o32-cc-gas/mips-sgi-irix6.5o32/libstdc++-v3/include/bits/stl_algo.h:1616:
error: there are no arguments to `lrand48' that depend on a template parameter, so a declaration of
`lrand48' must be
available
/var/tmp/gcc-obj/gcc-3.4-20030807/6.5o32-cc-gas/mips-sgi-irix6.5o32/libstdc++-v3/include/bits/stl_algo.h:1616:
error: (if you use `-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)

While in the end I found that this happens because the IRIX 6 configuration
predefines __EXTENSIONS__ and _SGI_SOURCE even with -ansi to make the
lrand48 declaration visible, the following patch still seems useful: 

* While configure checks for drand48, the result is used to decide if
  lrand48 is present.  This is plain wrong.

* It was only tested if drand48 exists at link time, but a declaration test
  is also needed.

* Even though this new declaration test may succeed, the testsuite may
  still produce the failures above, since there g++ -ansi is run, which may
  hide declarations present without -ansi.  This part is not fixed by this
  patch.
(Continue reading)

Benjamin Kosnik | 1 Oct 22:02 2003
Picon

Re: 3.4 PATCH: Properly check for lrand48 in libstdc++-v3


>Fri Aug  8 00:00:31 2003  Rainer Orth  <ro <at> TechFak.Uni-Bielefeld.DE>
>
>	* linkage.m4 (GLIBCXX_CHECK_STDLIB_DECL_AND_LINKAGE_0): Define.
>	(GLIBCXX_CHECK_STDLIB_SUPPORT): Use it to test for lrand48
>	instead of drand48.
>	* acconfig.h (HAVE_DRAND48): Renamed to HAVE_LRAND48.
>	* crossconfig.m4 (*-freebsd*): Define HAVE_LRAND48 instead of
>	HAVE_DRAND48.
>	* config.h.in, configure: Regenerate.
>	* include/bits/stl_algo.h: Use _GLIBCXX_HAVE_LRAND48 to guard
>	lrand48 use.

Looks good, thanks!

-benjamin

Paolo Carlini | 1 Oct 23:44 2003
Picon

Re: __alignof__(T) not compile time constant?

Gabriel Dos Reis wrote:

>The root of the disease is the same as for the PR that talks about
>alignment in std::basic_string. 
>
>I promised Paolo that I'll raise the issue.  Now seems to be the time.
>
[snip]

Thanks Gaby.

If I understand your interesting explanations the front end should be
fixed to have a true "C++" __alignof__. Unfortunately, I don't think
this is going to happen "tomorrow", right?

Can you imagine a temporary fix for libstdc++/8670? Perhaps that
suggested at the time by Martin?

Thanks,
Paolo.


Gmane