problem in installing apache standard library on HPUX 11.23PA
Hi all, When i install Apache standard library to /opt/iexpress/stdcxx location it is giving problem. gmake install PREFIX=/opt/iexpress/stdcxx --- mkdir -p /opt/iexpress/stdcxx gmake -Clib install gmake[1]: Entering directory `/home/jaipal/Stdcxx/stdcxx-4.2.1/build/lib' mkdir -p /opt/iexpress/stdcxx/lib cp libstd.sl.4.2.1 /opt/iexpress/stdcxx/lib if [ libstd.sl != libstd.sl.4.2.1 ]; then \ rm /opt/iexpress/stdcxx/lib/libstd.sl; \ ln -s libstd.sl.4.2.1 /opt/iexpress/stdcxx/lib/libstd.sl; \ fi mkdir -p /opt/iexpress/stdcxx/etc cp rwstderr.cat /opt/iexpress/stdcxx/etc gmake[1]: Leaving directory `/home/jaipal/Stdcxx/stdcxx-4.2.1/build/lib' gmake -Cbin install gmake[1]: Entering directory `/home/jaipal/Stdcxx/stdcxx-4.2.1/build/bin' ./localedef -w -c -f /home/jaipal/Stdcxx/stdcxx-4.2.1/etc/nls/charmaps/GB18030 -i /home/jaipal/Stdcxx/stdcxx-4.2.1/etc/nls/src/zh_CN /home/jaipal/Stdcxx/stdcxx-4.2.1/build/nls/zh_CN.GB18030 /bin/sh: 948 Memory fault(coredump) gmake[1]: *** [zh_CN.GB18030] Error 139 gmake[1]: Leaving directory `/home/jaipal/Stdcxx/stdcxx-4.2.1/build/bin' gmake: *** [install] Error 2 -- Can you help me regarding this issue Thanks in Advance, Jaipal P.
Re: Patch for MinGW
Farid Zaripov wrote:
I've been working on building stdcxx on MinGW.
Below is patch for review. An option is hardcode
_RWSTD_CRITICAL_SECTION=_CRITICAL_SECTION and
_RWSTD_INTERLOCKED_T=long for MinGW
(_RWSTD_CRITICAL_SECTION=_RTL_CRITICAL_SECTION and
_RWSTD_INTERLOCKED_T=volatile long for MSVC respectively) and don't
recover ATOMIC_OPS.cpp config test.
Suggestions?
Hmm. So the differences are:
MinGW _CRITICAL_SECTION InterlockedXxx (long*)
Windows _RTL_CRITICAL_SECTION InterlockedXxx (volatile long*)
I would be inclined to hardcode the name of the critical section
type. I'm less sure about the InterlockedXxx argument. I wouldn't
be surprised if MinGW followed in Windows footsteps at some point
in the future. Have you tried to find out from the maintainers of
the project?
Travis, any comments on this?
Martin
ChangeLog:
* etc/config/src/ATOMIC_OPS.cpp: Restored config test file, deleted in
rev. 614212.
Determine type of parameter for InterlockedXXX() function on 32-bit
Windows only.
Determine type of parameter for EnterCriticalSection() and so on
functions.
* include/rw/_mutex.h: Replaced _RTL_CRITICAL_SECTION to
_RWSTD_CRITICAL_SECTION, determined at configure step.
[!_MSC_VER] Added declarations of Win32 API InterlockedXXX()
functions.
[!_MSC_VER] Added inline _InterlockedXXX() functions for consistency
with MSVC's intinsics.
Use __try/__except on MSVC (and ICC/Windows) only.
Index: etc/config/src/ATOMIC_OPS.cpp
===
--- etc/config/src/ATOMIC_OPS.cpp (revision 665767)
+++ etc/config/src/ATOMIC_OPS.cpp (working copy)
@@ -22,7 +22,7 @@
*
**/
-#if defined (_WIN32) && !defined (_WIN64)
+#ifdef _WIN32
#include
#include
@@ -30,36 +30,45 @@
extern "C" {
-typedef int __stdcall pfiipv_t (int*);
-typedef int __stdcall pfiip_t (volatile int*);
typedef long __stdcall pfllp_t (long*);
typedef long __stdcall pfllpv_t (volatile long*);
+struct _CRITICAL_SECTION;
+struct _RTL_CRITICAL_SECTION;
+
+typedef void __stdcall pfvcsp_t (_CRITICAL_SECTION*);
+typedef void __stdcall pfvrcsp_t (_RTL_CRITICAL_SECTION*);
+
} // extern "C"
-const char* foo (pfiip_t) { return "int"; }
-const char* foo (pfiipv_t) { return "volatile int"; }
-
const char* foo (pfllp_t) { return "long"; }
const char* foo (pfllpv_t) { return "volatile long"; }
+const char* bar (pfvcsp_t) { return "_CRITICAL_SECTION"; }
+const char* bar (pfvrcsp_t) { return "_RTL_CRITICAL_SECTION"; }
+
int main ()
{
+# ifndef _WIN64
// determine the argument type of InterlockedIncrement()
// (the type changes from long* to volatile long* depending
-// on the version/patch of MSVC)
-
+// on the version/patch of PlatformSDK headers)
printf ("#define _RWSTD_INTERLOCKED_T %s\n", foo
(InterlockedIncrement));
+# endif // _WIN64
+// determine the argument type of EnterCriticalSection()
+// (the type changes from struct _CRITICAL_SECTION to
+// struct _RTL_CRITICAL_SECTION depending on the version/patch of
+// PlatformSDK headers)
+printf ("#define _RWSTD_CRITICAL_SECTION %s\n", bar
(EnterCriticalSection));
+
return 0;
}
#else // not 32-bit Windows
-#include
-
int main ()
{
return 0;
Index: include/rw/_mutex.h
===
--- include/rw/_mutex.h (revision 665767)
+++ include/rw/_mutex.h (working copy)
@@ -125,7 +125,7 @@
# ifdef _RWSTD_NO_FWD_DECLARATIONS
#include
-#define _RWSTD_MUTEX_T _RTL_CRITICAL_SECTION
+#define _RWSTD_MUTEX_T _RWSTD_CRITICAL_SECTION
# else // if defined (_RWSTD_NO_FWD_DECLARATIONS)
@@ -135,20 +135,33 @@
extern "C" {
// but rather declare these globals here
-struct _RTL_CRITICAL_SECTION;
+struct _RWSTD_CRITICAL_SECTION;
__declspec (dllimport) void __stdcall
-InitializeCriticalSection (_RTL_CRITICAL_SECTION*);
+InitializeCriticalSection (_RWSTD_CRITICAL_SECTION*);
__declspec (dllimport) void __stdcall
-EnterCriticalSection (_RTL_CRITICAL_SECTION*);
+EnterCriticalSection (_RWSTD_CRITICAL_SECTION*);
__declspec (dllimport) void __stdcall
-LeaveCriticalSection (_RTL_CRITICAL_SECTION*);
+LeaveCriticalSection (_RWSTD_CRITICAL_SECTION*);
__declspec (dllimport) void __stdcall
-DeleteCriticalSection (_RTL_CRITICAL_SECTION*);
+DeleteCriticalSection (_RWSTD_CRITICAL_SECTION*);
+#if defined (_RWSTD_INTERLOCKED_T) && !defined (_MSC_VER)
+
+__declspec (dllimport) long __stdcall
+InterlockedIncrement (_RWSTD_INTERLOCKED_T*);
+
+__declspec (dllimport) long __stdcall
+InterlockedDecrement (_RWSTD_INTERLOCKED_T*);
+
+__declspec (dllimport) long __stdcall
+InterlockedExchange (_RWSTD_INTERLOCKED_T*, long);
+
+#endif // _RWSTD_INTERLOCKED_T && !_MSC_VER
+
} // extern "C"
_RWSTD_NAMESP
Re: question about aligned_storage
Travis Vitek wrote: Martin Sebor wrote: While looking at the hoops we jump through to implement aligned_storage I recalled the gcc __attribute__ (aligned (N)). Is there any to use it to simplify the implementation for gcc? We already do. You're a step (or a few) ahead of me, as usual... :) Have a look at the definition of the macro _RWSTD_TT_ALIGNED_POD(). You mean the one in rw/_gcc-config.h on the 103 character long line? (You almost got away with it ;-) I might be able to eliminate __rw_aligned_storage_impl<> if I wanted to do a partial specialization of __rw_aligned_storage<> on the _Align non-type template parameter and I could also eliminate __rw_default_alignment<>, but that is about as much as I think I could reduce it. I'm probably missing something but is aligned_storage only specified for alignment of powers of 2? (It looks to me as though those are the only alignments we support.) Martin See http://tinyurl.com/5kmvdy for reference. Martin
Re: HP aCC 3.63 compilation error in 21.string.append.stdcxx-438.cpp
Travis Vitek wrote: Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: The test fails to compile with HP aCC 3.63. The error messages point to the patch for the issue: http://svn.apache.org/viewvc?view=rev&revision=629550 Actually, I think it was me that caused the problem, in the following change: http://svn.apache.org/viewvc?view=rev&revision=669747 The fix was for STDCXX-170 and friends, but break on every compiler when the Iterator::operator*() returns a temporary (which is legal). That's what I thought was your objection to Farid's patch. Yes, it was. Unfortunately I forgot about this issue part way through making my patch. Am I to understand that the code somehow detects whether operator*() returns a rvalue or lvalue and the branch with the cast is only supposed to be entered for lvalues? Sort of. The code checks that the _InputIter is a pointer. Oh. I missed this. I actually haven't reviewed your patch yet so I've been mostly looking at Farid's change from March. Let me reiterate what I mentioned in my comments on a similar but unrelated change: http://www.nabble.com/forum/Permalink.jtp?root=13349768 I would just as soon delete rw/_typetraits from 4.2.x. If it is, then we know it is safe to use the pointer to check for overlap. I see. But because we're using runtime dispatch instead of compile-time one the code gets instantiated even for other types besides pointers... and hence the aCC error (possibly also due to a compiler bug). (I'm still uncomfortable with the cast and would like to understand why it's safe). It seems that the cast itself is legal because expr.static.cast says I was just trying to understand what in the function guaranteed that the code wouldn't be executed for non-pointer types. I got thrown by the compiler error mentioning a user-defined iterator type that clearly returned an rvalue. An expression e can be explicitly converted to a type T using static_cast of the form static_cast(e) if the declaration "T t(e);" is well-formed, for some invented temporary variable t. The declaration const_reference t(*__first); is legal if *__first is convertible to value_type, which is required, so everything seems okay here, right? Right. But the same isn't okay for __last because it's not dereferenceable. We'd need to compute the difference between the two pointers and use it instead. The problem with the original testcase was that the cast can end up giving us a pointer to a temporary if *__first doesn't return a reference, which can result in invalid results. The testcase I provided showed this. Right. My fix eliminated the cast (which caused breakage), but verifies that __first is actually a raw pointer type before trying to get a reference out of it. So I think that we may be able to combine the two patches to come up with a usable fix. I think we need to do the dispatch at compile time rather than at runtime (despite the horrible __is_bidirectional_iterator kludge). That way we'll avoid the cast and problems like the one we've just run into with aCC. > If we avoid doing the cast until we know that __first is a pointer, then we can be sure that the cast is giving us reliable results. If __first is not a pointer, then all bets are off and we have to fall back to making a copy. Sure. It looks like I'd need to do a special case when the iterator type is pointer. I don't see any way to legally check for no overlap without that, so the only option I can see then is to always make the copy and fix it with an overload selection trick (which would only be appropriate for 4.3.x). I think it should be fine to optimize just the common case (const_pointer) and leave the rest unoptimized (i.e., make a copy). Or can you think of another common use that should be optimized as well? I think all cv-qualified pointer types could be optimized in this way. Yes. I was thinking of "common" non-pointer types such as reverse_iterators (I'm not sure how common they are). Travis Looking at the patch I don't see how the reinterpret_cast to const_reference can possibly be correct, and I'm not sure we satisfactorily resolved the same question the first time it was raised back in March: http://markmail.org/message/eijfmt3wxhg25bvs Farid? Thanks Martin
RE: question about aligned_storage
Martin Sebor wrote: > >While looking at the hoops we jump through to implement aligned_storage >I recalled the gcc __attribute__ (aligned (N)). Is there any to use it >to simplify the implementation for gcc? We already do. Have a look at the definition of the macro _RWSTD_TT_ALIGNED_POD(). I might be able to eliminate __rw_aligned_storage_impl<> if I wanted to do a partial specialization of __rw_aligned_storage<> on the _Align non-type template parameter and I could also eliminate __rw_default_alignment<>, but that is about as much as I think I could reduce it. > >See http://tinyurl.com/5kmvdy for reference. > >Martin > >
RE: HP aCC 3.63 compilation error in 21.string.append.stdcxx-438.cpp
Martin Sebor wrote: > >Travis Vitek wrote: >> >>> Martin Sebor wrote: >>> >>> The test fails to compile with HP aCC 3.63. The error messages >>> point to the patch for the issue: >>> >>> http://svn.apache.org/viewvc?view=rev&revision=629550 >> >> Actually, I think it was me that caused the problem, in the following >> change: >> >> http://svn.apache.org/viewvc?view=rev&revision=669747 >> >> The fix was for STDCXX-170 and friends, but break on every >> compiler when the Iterator::operator*() returns a temporary >> (which is legal). > >That's what I thought was your objection to Farid's patch. Yes, it was. Unfortunately I forgot about this issue part way through making my patch. >Am I >to understand that the code somehow detects whether operator*() >returns a rvalue or lvalue and the branch with the cast is only >supposed to be entered for lvalues? Sort of. The code checks that the _InputIter is a pointer. If it is, then we know it is safe to use the pointer to check for overlap. >(I'm still uncomfortable >with the cast and would like to understand why it's safe). It seems that the cast itself is legal because expr.static.cast says An expression e can be explicitly converted to a type T using static_cast of the form static_cast(e) if the declaration "T t(e);" is well-formed, for some invented temporary variable t. The declaration const_reference t(*__first); is legal if *__first is convertible to value_type, which is required, so everything seems okay here, right? The problem with the original testcase was that the cast can end up giving us a pointer to a temporary if *__first doesn't return a reference, which can result in invalid results. The testcase I provided showed this. My fix eliminated the cast (which caused breakage), but verifies that __first is actually a raw pointer type before trying to get a reference out of it. So I think that we may be able to combine the two patches to come up with a usable fix. If we avoid doing the cast until we know that __first is a pointer, then we can be sure that the cast is giving us reliable results. If __first is not a pointer, then all bets are off and we have to fall back to making a copy. > >> >> It looks like I'd need to do a special case when the iterator type is >> pointer. I don't see any way to legally check for no overlap without >> that, so the only option I can see then is to always make >the copy and >> fix it with an overload selection trick (which would only be >appropriate >> for 4.3.x). > >I think it should be fine to optimize just the common case >(const_pointer) and leave the rest unoptimized (i.e., make >a copy). Or can you think of another common use that should >be optimized as well? I think all cv-qualified pointer types could be optimized in this way. > >> >> Travis >> >>> Looking at the patch I don't see how the reinterpret_cast to >>> const_reference can possibly be correct, and I'm not sure we >>> satisfactorily resolved the same question the first time it >>> was raised back in March: >>> >>> http://markmail.org/message/eijfmt3wxhg25bvs >>> >>> Farid? >>> >>> Thanks >>> Martin >>> > >
RE: Some internal aliases for __rw_integral_constant?
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Tuesday, June 24, 2008 5:11 PM
> To: dev@stdcxx.apache.org
> Subject: Re: Some internal aliases for __rw_integral_constant?
>
> Eric Lemings wrote:
> >
> > Propose adding the following defs (or something similar) to
> > primarily for our own convenience:
> >
> > template
> > class __rw_bool_const: public __rw_integral_constant _Bool> {};
>
> I was going to suggest the same thing this morning when I noticed
> how pervasive __rw_integral_constant seems to be in
> traits definitions (I count 41 occurrences) and thinking that it
> would make them less verbose. (With a different spelling of _Bool
> to avoid potential clashes with the C99 name.)
Good point.
>
> I didn't because the only beneficiaries of the change would be us
> (a fairly small notational convenience) and I wasn't sure the cost
> in terms of the added complexity and compilation time was worth it.
> I contemplated suggesting a macro for the same purpose instead but
> decided against it on the assumption that it probably wouldn't be
> very popular ;-) But now that the cat's out of the bag and you're
> asking about alternatives let me throw it out there:
>
> #define _RWSTD_BOOL_CONST(B) _RW::__rw_integral_constant
>
> Usage:
>
> _RW::__rw_bool_const
>vs
> _RWSTD_BOOL_CONST (false)
>
Looks good to me. I'll just add _RWSTD_BOOL_CONST for now.
Brad.
question about aligned_storage
While looking at the hoops we jump through to implement aligned_storage I recalled the gcc __attribute__ (aligned (N)). Is there any to use it to simplify the implementation for gcc? See http://tinyurl.com/5kmvdy for reference. Martin
Re: svn commit: r671294 - in /stdcxx/branches/4.3.x/include: rw/_meta_arr.h rw/_meta_cat.h rw/_meta_comp.h rw/_meta_cv.h rw/_meta_other.h rw/_meta_prop.h rw/_meta_ptr.h rw/_meta_ref.h rw/_meta_rel.h r
[EMAIL PROTECTED] wrote:
Author: vitek
Date: Tue Jun 24 11:55:30 2008
New Revision: 671294
URL: http://svn.apache.org/viewvc?rev=671294&view=rev
Log:
2008-06-24 Travis Vitek <[EMAIL PROTECTED]>
STDCXX-916
* include/type_traits: Remove doxygen comments, leaving C++
comments where appropriate.
[...]
Modified: stdcxx/branches/4.3.x/include/rw/_meta_arr.h
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/include/rw/_meta_arr.h?rev=671294&r1=671293&r2=671294&view=diff
==
--- stdcxx/branches/4.3.x/include/rw/_meta_arr.h (original)
+++ stdcxx/branches/4.3.x/include/rw/_meta_arr.h Tue Jun 24 11:55:30 2008
@@ -34,32 +34,18 @@
_RWSTD_NAMESPACE (__rw) {
-/**
- * TransformationTrait strips one dimension from an array type, leaving
- * other types as-is. The primary template is for non-array types.
- */
Many of these seem like useful comments. Are you sure you meant
to delete them?
template
struct __rw_remove_extent
{
typedef _TypeT type;
};
[...]
-/**
- * This template prevents the partial specialization below from
- * being instantiated on types for which it would fail or give
- * invalid results. i.e. it avoids creating references to void or
- * arrays with unknown length and for returning bad results for
- * references to functions.
- *
- * All void, array and reference types are not functions.
- */
This one especially, for example, but others below as well.
template ::value
|| __rw_is_array<_TypeT>::value
|| __rw_is_lvalue_reference<_TypeT>::value
@@ -266,13 +219,6 @@
enum { _C_value = 0 };
};
Martin
Re: Some internal aliases for __rw_integral_constant?
Eric Lemings wrote:
Propose adding the following defs (or something similar) to
primarily for our own convenience:
template
class __rw_bool_const: public __rw_integral_constant {};
I was going to suggest the same thing this morning when I noticed
how pervasive __rw_integral_constant seems to be in
traits definitions (I count 41 occurrences) and thinking that it
would make them less verbose. (With a different spelling of _Bool
to avoid potential clashes with the C99 name.)
I didn't because the only beneficiaries of the change would be us
(a fairly small notational convenience) and I wasn't sure the cost
in terms of the added complexity and compilation time was worth it.
I contemplated suggesting a macro for the same purpose instead but
decided against it on the assumption that it probably wouldn't be
very popular ;-) But now that the cat's out of the bag and you're
asking about alternatives let me throw it out there:
#define _RWSTD_BOOL_CONST(B) _RW::__rw_integral_constant
Usage:
_RW::__rw_bool_const
vs
_RWSTD_BOOL_CONST (false)
template
class __rw_int_const: public __rw_integral_constant {};
template <_RWSTD_SIZE_T _Size>
class __rw_size_const: public __rw_integral_constant<_RWSTD_SIZE_T,
_Size> {};
The name __rw_integral_constant is a bit too long for the amount of
usage that I'm anticipating.
AFAICS, there are just 9 occurrences of the size_t specializations
but none of the int one.
Martin
Or am I being premature?
Thoughts? Alternatives?
Brad.
Re: HP aCC 3.63 compilation error in 21.string.append.stdcxx-438.cpp
Travis Vitek wrote: Martin Sebor wrote: The test fails to compile with HP aCC 3.63. The error messages point to the patch for the issue: http://svn.apache.org/viewvc?view=rev&revision=629550 Actually, I think it was me that caused the problem, in the following change: http://svn.apache.org/viewvc?view=rev&revision=669747 The fix was for STDCXX-170 and friends, but break on every compiler when the Iterator::operator*() returns a temporary (which is legal). That's what I thought was your objection to Farid's patch. Am I to understand that the code somehow detects whether operator*() returns a rvalue or lvalue and the branch with the cast is only supposed to be entered for lvalues? (I'm still uncomfortable with the cast and would like to understand why it's safe). It looks like I'd need to do a special case when the iterator type is pointer. I don't see any way to legally check for no overlap without that, so the only option I can see then is to always make the copy and fix it with an overload selection trick (which would only be appropriate for 4.3.x). I think it should be fine to optimize just the common case (const_pointer) and leave the rest unoptimized (i.e., make a copy). Or can you think of another common use that should be optimized as well? Travis Looking at the patch I don't see how the reinterpret_cast to const_reference can possibly be correct, and I'm not sure we satisfactorily resolved the same question the first time it was raised back in March: http://markmail.org/message/eijfmt3wxhg25bvs Farid? Thanks Martin
Some internal aliases for __rw_integral_constant?
Propose adding the following defs (or something similar) to
primarily for our own convenience:
template
class __rw_bool_const: public __rw_integral_constant {};
template
class __rw_int_const: public __rw_integral_constant {};
template <_RWSTD_SIZE_T _Size>
class __rw_size_const: public __rw_integral_constant<_RWSTD_SIZE_T,
_Size> {};
The name __rw_integral_constant is a bit too long for the amount of
usage that I'm anticipating. Or am I being premature?
Thoughts? Alternatives?
Brad.
RE: svn commit: r662845 - in /stdcxx/branches/4.2.x: examples/include/ examples/tutorial/ tests/iostream/ tests/localization/ tests/regress/ tests/utilities/
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 2:24 PM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r662845 - in /stdcxx/branches/4.2.x: > examples/include/ examples/tutorial/ tests/iostream/ > tests/localization/ tests/regress/ tests/utilities/ > > [EMAIL PROTECTED] wrote: > > Author: elemings > > Date: Tue Jun 3 10:24:08 2008 > > New Revision: 662845 > > > > URL: http://svn.apache.org/viewvc?rev=662845&view=rev > > Log: > > 2008-06-03 Eric Lemings <[EMAIL PROTECTED]> > > > > STDCXX-550 > [...] > > * tests/utilities/20.operators.cpp (RandomNumberGenerator): > > Change parameter type of RNG from hard-coded `int' to template > > parameter `T'. > > (test_random_access_iterators): Instantiate RNG using difference > > type of iterator rather than value type as specified by > > `random_shuffle' requirements. > [...] > > I suspect this change is causing the test to fail to compile > with HP aCC 3.63 (I haven't checked more recent versions or > other compilers). > > Brad, can you please take a look at it? Yeah it looks like I'll need to add conditional compilation to take debug iterators into account. I'm assuming that's how the compiler is deducing type `int*' from types `std::deque::iterator, std::basic_string::iterator, and std::vector::iterator`. Brad.
RE: HP aCC 3.63 compilation error in 21.string.append.stdcxx-438.cpp
>Martin Sebor wrote: > >The test fails to compile with HP aCC 3.63. The error messages >point to the patch for the issue: > > http://svn.apache.org/viewvc?view=rev&revision=629550 Actually, I think it was me that caused the problem, in the following change: http://svn.apache.org/viewvc?view=rev&revision=669747 The fix was for STDCXX-170 and friends, but break on every compiler when the Iterator::operator*() returns a temporary (which is legal). It looks like I'd need to do a special case when the iterator type is pointer. I don't see any way to legally check for no overlap without that, so the only option I can see then is to always make the copy and fix it with an overload selection trick (which would only be appropriate for 4.3.x). Travis > >Looking at the patch I don't see how the reinterpret_cast to >const_reference can possibly be correct, and I'm not sure we >satisfactorily resolved the same question the first time it >was raised back in March: > > http://markmail.org/message/eijfmt3wxhg25bvs > >Farid? > >Thanks >Martin >
HP aCC 3.63 compilation error in 21.string.append.stdcxx-438.cpp
The test fails to compile with HP aCC 3.63. The error messages point to the patch for the issue: http://svn.apache.org/viewvc?view=rev&revision=629550 Looking at the patch I don't see how the reinterpret_cast to const_reference can possibly be correct, and I'm not sure we satisfactorily resolved the same question the first time it was raised back in March: http://markmail.org/message/eijfmt3wxhg25bvs Farid? Thanks Martin aCC -c -I$(TOPDIR)/include -I$(BUILDDIR)/include -I$(TOPDIR)/tests/include -AA +O2 +w +W392,655,684,818,819,849 $(TOPDIR)/tests/regress/21.string.append.stdcxx-438.cpp Error 280: "$(TOPDIR)/include/string.cc", line 523 # Operator & expects lvalue operand. _RWSTD_REINTERPRET_CAST (const_pointer, &*__first2); ^^^ Error 280: "$(TOPDIR)/include/string.cc", line 525 # Operator & expects lvalue operand. _RWSTD_REINTERPRET_CAST (const_pointer, &*__last2); ^^^ Error 556: "$(TOPDIR)/tests/regress/21.string.append.stdcxx-438.cpp", line 85 # Unable to generate specialization "std::basic_string,std::allocator > &std::__rw_replace,std::allocator,char *,InputIterator>(std::basic_string,std::allocator > &,char *,char *,InputIterator,InputIterator)" due to errors during generation. str.append (first, last); Error 556: "$(TOPDIR)/tests/regress/21.string.append.stdcxx-438.cpp", line 85 # Unable to generate specialization "std::basic_string,std::allocator > &std::__rw_replace,std::allocator,char *,InputIterator>(std::basic_string,std::allocator > &,char *,char *,InputIterator,InputIterator)" due to errors during generation. str.append (first, last); gmake: *** [21.string.append.stdcxx-438.o] Error 2
Re: svn commit: r662845 - in /stdcxx/branches/4.2.x: examples/include/ examples/tutorial/ tests/iostream/ tests/localization/ tests/regress/ tests/utilities/
[EMAIL PROTECTED] wrote:
Author: elemings
Date: Tue Jun 3 10:24:08 2008
New Revision: 662845
URL: http://svn.apache.org/viewvc?rev=662845&view=rev
Log:
2008-06-03 Eric Lemings <[EMAIL PROTECTED]>
STDCXX-550
[...]
* tests/utilities/20.operators.cpp (RandomNumberGenerator):
Change parameter type of RNG from hard-coded `int' to template
parameter `T'.
(test_random_access_iterators): Instantiate RNG using difference
type of iterator rather than value type as specified by
`random_shuffle' requirements.
[...]
I suspect this change is causing the test to fail to compile
with HP aCC 3.63 (I haven't checked more recent versions or
other compilers).
Brad, can you please take a look at it?
Thanks
Martin
Modified: stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp?rev=662845&r1=662844&r2=662845&view=diff
==
--- stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp (original)
+++ stdcxx/branches/4.2.x/tests/utilities/20.operators.cpp Tue Jun 3 10:24:08
2008
@@ -169,7 +169,7 @@
template
struct RandomNumberGenerator
{
-T operator() (int) const {
+T operator() (T) const {
return T ();
}
};
@@ -397,7 +397,7 @@
typedef RandomAccessIterator I;
-RandomNumberGenerator rndgen;
+RandomNumberGenerator rndgen;
std::random_shuffle (I (), I ());
std::random_shuffle (I (), I (), rndgen);
RE: svn commit: r668347 - /stdcxx/branches/4.3.x/tests/utilities/20.meta.rel.cpp
Martin Sebor wrote: > >[EMAIL PROTECTED] wrote: >> Author: vitek >> Date: Mon Jun 16 16:35:21 2008 >> New Revision: 668347 >> >> URL: http://svn.apache.org/viewvc?rev=668347&view=rev >> Log: >> 2008-06-16 Travis Vitek <[EMAIL PROTECTED]> >> >[...] >> @@ -346,7 +332,7 @@ >> TEST (std::is_convertible, int (), int (&)(char), false); >> >> TEST (std::is_convertible, int*, void*, true); >> -TEST (std::is_convertible, int (*)(), void*, true); >> +TEST (std::is_convertible, int (*)(), void*, false); > >Should the convertibility of functions with different language >linkages, and that of member function pointers, be exercised >as well? Absolutely. Will enhance test. > >Martin > >
Re: svn commit: r669735 - in /stdcxx/branches/4.3.x: include/rw/_meta_other.h include/type_traits tests/utilities/20.meta.trans.other.cpp
[EMAIL PROTECTED] wrote:
Author: vitek
Date: Thu Jun 19 15:52:34 2008
New Revision: 669735
URL: http://svn.apache.org/viewvc?rev=669735&view=rev
Log:
2008-06-19 Travis Vitek <[EMAIL PROTECTED]>
STDCXX-926
[...]
Modified: stdcxx/branches/4.3.x/include/rw/_meta_other.h
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.3.x/include/rw/_meta_other.h?rev=669735&r1=669734&r2=669735&view=diff
==
--- stdcxx/branches/4.3.x/include/rw/_meta_other.h (original)
+++ stdcxx/branches/4.3.x/include/rw/_meta_other.h Thu Jun 19 15:52:34 2008
@@ -37,50 +37,318 @@
[...]
+template ::value>
struct __rw_aligned_storage
{
+_RWSTD_STATIC_ASSERT (_Size != 0,
+ "Unsupported size");
+
+_RWSTD_STATIC_ASSERT ((_Align & (_Align - 1)) == 0 || _Align == 0,
+ "Unsupported alignment"); // expect power of 2
+
+_RWSTD_STATIC_ASSERT (_Align <= _RWSTD_TT_MAX_ALIGNMENT,
+ "Unsupported alignment"); // expect less than max
+
typedef union {
-unsigned char __data [_Len];
-// not implemented
+unsigned char __size [_Size];
+
+typename
+__rw_aligned_storage_impl<_Align>::_C_type __align;
I believe there are platforms where unions are aligned on
the boundary given by the first member. This one looks like
it might be one of them: http://tinyurl.com/472744. Unless
I'm mistaken we should switch the order of the two members
to make sure the union is properly aligned.
Also, strictly speaking, names of data members should have
the _C_ prefix (double underscores are used for locals and
function parameters).
Martin
Re: svn commit: r668347 - /stdcxx/branches/4.3.x/tests/utilities/20.meta.rel.cpp
[EMAIL PROTECTED] wrote: Author: vitek Date: Mon Jun 16 16:35:21 2008 New Revision: 668347 URL: http://svn.apache.org/viewvc?rev=668347&view=rev Log: 2008-06-16 Travis Vitek <[EMAIL PROTECTED]> [...] @@ -346,7 +332,7 @@ TEST (std::is_convertible, int (), int (&)(char), false); TEST (std::is_convertible, int*, void*, true); -TEST (std::is_convertible, int (*)(), void*, true); +TEST (std::is_convertible, int (*)(), void*, false); Should the convertibility of functions with different language linkages, and that of member function pointers, be exercised as well? Martin
Re: svn commit: r663373 - in /stdcxx/branches/4.2.x: include/valarray tests/numerics/26.gslice.array.cassign.cpp
[EMAIL PROTECTED] wrote:
Author: vitek
Date: Wed Jun 4 13:53:00 2008
New Revision: 663373
URL: http://svn.apache.org/viewvc?rev=663373&view=rev
Log:
2008-06-04 Travis Vitek <[EMAIL PROTECTED]>
[...]
Added: stdcxx/branches/4.2.x/tests/numerics/26.gslice.array.cassign.cpp
URL:
http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/tests/numerics/26.gslice.array.cassign.cpp?rev=663373&view=auto
[...]
+
+if (!repeat)
+{
Please correct the brace placement :)
+buf [i++] = std::size_t (val);
+}
+else
+{
Same here.
+const std::size_t n = buf [i-1];
[...]
+template
+void test_mul_assign (const T*, const char *tname, const char *opname)
+{
+rw_info (0, 0, __LINE__,
+ "std::gslice_array<%s>::operator%s (const std::valarray<%1$s>&)",
+ tname, opname);
+
+void (std::gslice_array::*op)(const std::valarray&) const =
+&std::gslice_array::operator*=;
Please keep an eye on this test. Many older compilers tend
to have problems with taking the address of member functions
of class templates.
+
[...]
+int main (int argc, char *argv[])
+{
+// FIXME: add command line options to enable/disable each operator
Seems this is done below, no?
+return rw_test (argc, argv, __FILE__,
+"gslice.array.comp.assign",
+0 /* no comment */,
+run_test,
+"|-times~ "
+"|-divide~ "
+"|-modulo~ "
+"|-plus~ "
+"|-minus~ "
+"|-xor~ "
+"|-and~ "
+"|-or~ "
+"|-shift_left~ "
+"|-shift_right~",
+opt_assign + inx_mul_assign,
+opt_assign + inx_div_assign,
+opt_assign + inx_mod_assign,
+opt_assign + inx_add_assign,
+opt_assign + inx_sub_assign,
+opt_assign + inx_xor_assign,
+opt_assign + inx_and_assign,
+opt_assign + inx_or_assign,
+opt_assign + inx_shl_assign,
+opt_assign + inx_shr_assign,
+(void*)0 /* sentinel */);
+}
\ No newline at end of file
Don't forget to add it (the missing newline).
Great test, btw.!
Martin
Re: :decay related question
Travis Vitek wrote: Eric Lemings wrote: Page 490, section 20.3.1.2, paragraph 1 in the latest draft says this: "Let Ui be decay::type for each Ti in Types. Then each Vi in VTypes is X& if Ui equals reference_wrapper, otherwise Vi is Ui." What do you suppose the relationship is between type `X' and types `Ti' and `Ui'? I see how the latter two types are deduced from the type list `Types' but not so sure about how type `X' is deduced from `Types'. I'm looking at this and I have no idea where VTypes and X are coming from. Is that an issue, or am I missing something? Have you found an issue for any of this? (If not, we/I will need to open one.) Martin That said, I think X is supposed to be Ti. If that were the case then the definition would make some sense [at least to me]. Let Ui be decay::type for each Ti in Types. Then each Vi in VTypes is Ti& if Ui equals reference_wrapper, otherwise Vi is Ui. If that is right, then it essentially says that the 'make_tuple' function transforms reference_wrapper back to T& and for other types does the normal decay transformation [function to funciton pointer, array to array pointer, and cv-stripping of all other types]. Travis Brad.
RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 9:00 AM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r667636 - > /stdcxx/branches/4.3.x/include/rw/_forward.h > > Eric Lemings wrote: > > > > > >> -Original Message- > >> From: Martin Sebor [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, June 24, 2008 6:55 AM > >> To: dev@stdcxx.apache.org > >> Subject: Re: svn commit: r667636 - > >> /stdcxx/branches/4.3.x/include/rw/_forward.h > >> > >> Eric Lemings wrote: > > ... > >>> BTW, I'm still trying to figure out what it is that you are > >> proposing > >>> exactly. :D > >> We have an established (albeit undocumented) process and > >> infrastructure for documenting code and publishing the > >> documentation. The onus is on you and Travis to come up > >> with a proposal if you want to change how things are done. > > > > I thought I did. To repeat...for the record, write new > documentation > > using Doxygen comments now. Migrate the old HTML docs later. > > Sorry. One sentence doesn't make a proposal, certainly not > one this vague. I can write a 1000 word, detailed proposal in about an hour if that would do any good. In the meantime, most of the details are in the Jira issue. http://issues.apache.org/jira/browse/STDCXX-964 > ... > The current process is to maintain the existing docs in HTML, > using the existing infrastructure to publish the docs on the > site. You want to change it? Fine. Propose in detail how and > when this will change will take place and when we can expect > it to be done. Okay. Brad.
Re: tests/utilities/20.meta.help.cpp
Martin Sebor wrote:
Travis Vitek wrote:
[...]
IMO, the class should have an explicit requirement on the first
template argument. If there isn't one I would propose adding
paragraph 2 with the text:
-2- The template parameter T shall have an integral type (3.9.1).
integral_constant::value shall be a integral constant
expression (5.19).
With concepts, we would change the definition of the class like
this (I think):
template
Actually, I don't think this is quite sufficient. T is more
constrained than that. If there were an OR in Concepts it
would be:
template
requires IntegralType || EnumerationType
struct integral_constant;
I've written up an issue/proposal to fix this without using
concepts that I plan to send to the list shortly unless you
see a better way of dealing with it. Here's the proposal:
Add a new paragraph to [meta.help] with the following
requirement:
-2- The template parameter T shall have an integral type
(3.9.1) or be an enumeration (3.9.2).
integral_constant::value shall be an integral
constant expression (5.19).
In addition, declare the value data member of the template
constexpr:
template
struct integral_constant {
typedef T value_type;
typedef integral_constant type;
static constexpr value_type value = v;
};
struct integral_constant {
// ...
};
Strangely, this isn't in N2625:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2625.pdf
Incidentally, it also seems to me that value should be declared
constexpr (both in our implementation and in the spec).
Travis
Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
Eric Lemings wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2008 6:55 AM To: dev@stdcxx.apache.org Subject: Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h Eric Lemings wrote: ... BTW, I'm still trying to figure out what it is that you are proposing exactly. :D We have an established (albeit undocumented) process and infrastructure for documenting code and publishing the documentation. The onus is on you and Travis to come up with a proposal if you want to change how things are done. I thought I did. To repeat...for the record, write new documentation using Doxygen comments now. Migrate the old HTML docs later. Sorry. One sentence doesn't make a proposal, certainly not one this vague. So far you've decided on your own, despite my objections and without establishing consensus, to start adding Doxygen style comments to new headers, without reconciling the differences between the existing process and your new one, and without providing a clear path to such a reconciliation in the foreseeable future. Hmm. Let me see if I can summarize your objections: 1. You don't like Doxygen. I think that's pretty evident. :) Not at all. You completely misinterpreted what I said. Nothing wrong with that. I think it's the best damn doc tool on the market...but that's just me. But if you know of a better tool and/or format, we're all ears. 2. We shouldn't write any documentation comments because it's not conventional. Nope. Again, you're missing my point. I'm saying changes to process should be made only with a solid plan in place and with consensus. Convention isn't really the right: this is becoming more like dogma. Travis and I both realize what this means -- breaking with this convention -- moving forward. It's not easy writing docs and code at the same time, and the new code will look different from the older code (for a period of time at least), but it is the right thing to do we believe. I disagree. Unless these issues are satisfactorily resolved and until there is a viable plan for producing a adequate replacement for the existing class reference on a reasonable schedule I have to insist that the Doxygen comments be removed from the newly added headers. And then what? Hope that the documentation magically appears? I'd be glad to remove it...if you have a better plan, solution, proposal... something in mind. The current process is to maintain the existing docs in HTML, using the existing infrastructure to publish the docs on the site. You want to change it? Fine. Propose in detail how and when this will change will take place and when we can expect it to be done. But just removing the documentation comments is not "a clear path to such reconciliation in the foreseeable future" either. It's the absolute last thing we should be contemplating in fact.
RE: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2008 6:55 AM > To: dev@stdcxx.apache.org > Subject: Re: svn commit: r667636 - > /stdcxx/branches/4.3.x/include/rw/_forward.h > > Eric Lemings wrote: ... > > BTW, I'm still trying to figure out what it is that you are > proposing > > exactly. :D > > We have an established (albeit undocumented) process and > infrastructure for documenting code and publishing the > documentation. The onus is on you and Travis to come up > with a proposal if you want to change how things are done. I thought I did. To repeat...for the record, write new documentation using Doxygen comments now. Migrate the old HTML docs later. > > So far you've decided on your own, despite my objections > and without establishing consensus, to start adding Doxygen > style comments to new headers, without reconciling the > differences between the existing process and your new one, > and without providing a clear path to such a reconciliation > in the foreseeable future. Hmm. Let me see if I can summarize your objections: 1. You don't like Doxygen. I think that's pretty evident. :) Nothing wrong with that. I think it's the best damn doc tool on the market...but that's just me. But if you know of a better tool and/or format, we're all ears. 2. We shouldn't write any documentation comments because it's not conventional. Convention isn't really the right: this is becoming more like dogma. Travis and I both realize what this means -- breaking with this convention -- moving forward. It's not easy writing docs and code at the same time, and the new code will look different from the older code (for a period of time at least), but it is the right thing to do we believe. > > Unless these issues are satisfactorily resolved and until > there is a viable plan for producing a adequate replacement > for the existing class reference on a reasonable schedule > I have to insist that the Doxygen comments be removed from > the newly added headers. And then what? Hope that the documentation magically appears? I'd be glad to remove it...if you have a better plan, solution, proposal... something in mind. But just removing the documentation comments is not "a clear path to such reconciliation in the foreseeable future" either. It's the absolute last thing we should be contemplating in fact. Brad.
Re: problem with Apache standard library
pendiala jaipal wrote: Hi all, I built Apache Standard Library (stdcxx-4.2.1) on HPUX with acc 3.80 on 11.23PA platform. when i create binary using libstd.sl it is giving errors. I followed these steps: aCC /home/jaipal/stdcxx-4.2.1/build/include -mt -c -o t.o ex.cpp aCC /home/jaipal/stdcxx-4.2.1/build/lib -mt t.o ./libstd.sl -o prog You're missing some options on your command line. The most important one is probably -AA (unless 3.80 changed the default from -Ap to -AA). You can see the command line options we use when building our tests and examples with stdcxx in our nightly build logs, for example in this LP64 build: http://stdcxx.apache.org/builds/4.2.x/logs/hpux-11.23-pa-acc-3.73-12D-670084-log.gz.txt compile: -AA -mt +O2 +DD64 +w +W392,655,684,818,819,849 link: -AA -mt +nostl +DD64 -Wl,+s An easy way to check that things work as they should is to compile, link, and run one of the example programs provided with the library: $ cd $BUILDDIR/examples && gmake accumulate && ./accumulate where BUILDDIR is the root of the directory where you chose to build stdcxx ($TOPDIR/build by default, with TOPDIR being the root of the stdcxx source tree where you expanded the tarball). Martin it is giving error as : /usr/ccs/bin/ld: /home/jaipal/Stdcxx/stdcxx-4.2.1.good/build/lib: Not a valid object file (invalid system id) if i run aCC mt t.o ./libstd.sl -o prog the prog binary is creating. when i run the binary it is giving error as : aCC runtime: Error 215 from shl_findsym ( home/jaipal/stdcxx-4.2.1/build/lib/libstd.sl ,_shlInit)' signal 11 Can you please help me on this issue and also can you tell me how to test this apache standard library . Thanks in Advance, Jaipal Reddy P.
Re: svn commit: r667636 - /stdcxx/branches/4.3.x/include/rw/_forward.h
Eric Lemings wrote: On Jun 23, 2008, at 9:31 PM, Martin Sebor wrote: Travis Vitek wrote: Martin Sebor wrote: [...] I gave a number of arguments against Doxygen comments in stdcxx headers: 1) existing code doesn't use it and converting the raw HTML docs to Doxygen is an enormous task that none of us has the time to take on; Doxygenating new code without doing the same for the existing code is inconsistent and won't help us produce end-user documentation for the finished product Since we aren't providing any html documentation for any c++0x code at this time, maybe we should stop using html documentation? :P So the options are-- a) not document the c++0x code at all b) write up documentation for all new code in html to be consistent with what is used currently c) move all existing documentation over to doxygen before a single doxygen comment is added to the new code Assuming we want to have C++ 0x fully documented in 5.0 or shortly thereafter which of (b) and (c) do you think is viable? I don't think any of those choice are viable _in the near term_ but if I had to choose? C. If only to get a better idea of how much work we're really talking about. [...] BTW, I'm still trying to figure out what it is that you are proposing exactly. :D We have an established (albeit undocumented) process and infrastructure for documenting code and publishing the documentation. The onus is on you and Travis to come up with a proposal if you want to change how things are done. So far you've decided on your own, despite my objections and without establishing consensus, to start adding Doxygen style comments to new headers, without reconciling the differences between the existing process and your new one, and without providing a clear path to such a reconciliation in the foreseeable future. Unless these issues are satisfactorily resolved and until there is a viable plan for producing a adequate replacement for the existing class reference on a reasonable schedule I have to insist that the Doxygen comments be removed from the newly added headers. Martin
problem with Apache standard library
Hi all, I built Apache Standard Library (stdcxx-4.2.1) on HPUX with acc 3.80 on 11.23PA platform. when i create binary using libstd.sl it is giving errors. I followed these steps: aCC /home/jaipal/stdcxx-4.2.1/build/include -mt -c -o t.o ex.cpp aCC /home/jaipal/stdcxx-4.2.1/build/lib -mt t.o ./libstd.sl -o prog it is giving error as : /usr/ccs/bin/ld: /home/jaipal/Stdcxx/stdcxx-4.2.1.good/build/lib: Not a valid object file (invalid system id) if i run aCC mt t.o ./libstd.sl -o prog the prog binary is creating. when i run the binary it is giving error as : aCC runtime: Error 215 from shl_findsym ( home/jaipal/stdcxx-4.2.1/build/lib/libstd.sl ,_shlInit)' signal 11 Can you please help me on this issue and also can you tell me how to test this apache standard library . Thanks in Advance, Jaipal Reddy P.
