22.locale.codecvt.out test failure
The named test fails on all platforms with an EXEC error. It looks like the problem is that when trying to build the executable '22.locale.codecvt.out', it actually generates an output file for the test '22.locale.codecvt', which is obviously not going to be executable. $ gmake 22.locale.codecvt.out gcc -c -I/amd/devco/vitek/stdcxx/trunk/include/ansi -D_RWSTDDEBUG -I/amd/devco/vitek/stdcxx/trunk/include -I/build/vitek/5.0.0/11S/include -I/amd/devco/vitek/stdcxx/trunk/tests/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /amd/devco/vitek/stdcxx/trunk/tests/localization/22.locale.codecvt.cpp gcc 22.locale.codecvt.o -o 22.locale.codecvt -L/build/vitek/5.0.0/11S/rwtest -lrwtest11S -L/build/vitek/5.0.0/11S/lib -lstd11S -lsupc++ -lm LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/build/vitek/5.0.0/11S/lib ./22.locale.codecvt >22.locale.codecvt.out 2>&1 I know this worked at one time because I was involved in the discussion for fixing this problem the last time it came up [http://tinyurl.com/5nv7qx]. Any ideas why this problem is back to haunt us? Travis
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
Martin Sebor wrote:
>
>[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
>[...]
>> +template >__rw_default_alignment<_Size>::value>
>> struct __rw_aligned_storage
>> {
[...]
>> 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.
>
I'm not absolutely sure I'm reading the documentation you linked to
correctly, but here goes...
The first paragraph of that documentation says
Individual members of a union are mapped the same way as members of the
structure. That is, each of the members, if not a union, is mapped as if
it were a member of a structure. This means that the first storage
locations for each of the members of a union do not overlay each other
if each of the members requires different alignment and therefore
different padding before the beginning of the member.
This violates C99 (6.7.2.1 p5)
As discussed in 6.2.5, a structure is a type consisting
of a sequence of members, whose storage is allocated in
an ordered sequence, and a union is a type consisting
of a sequence of members whose storage overlap.
And (6.7.2.1 p14)
The size of a union is sufficient to contain the largest
of its members. The value of at most one of the members
can be stored in a union object at any time. A pointer
to a union object, suitably converted, points to each of
its members, and vise versa.
It also voilates C++03 (expr.rel p2)
If two pointers point to data members of the same union
object, they compare equal (after conversion to void*,
if necessary).
Even so, the last paragraph of "Rules for mapping one pair" says
The pair is now a unit of fixed length and alignment
requirement, its length is the sum of the two lengths
plus padding, and its alignment requirement is the
higher of the two alignment requirements (if they
differ).
So the alignment would still be correct as the alignment requirement is
weakest (smallest) for char types, so the alignment that would be used
would be the alignment of the other type.
Please correct me if I'm misinterpreting any of this.
Travis
>Also, strictly speaking, names of data members should have
>the _C_ prefix (double underscores are used for locals and
>function parameters).
Agreed. I will fix.
>
>Martin
>
RE: svn commit: r669723 - in /stdcxx/branches/4.3.x: include/rw/_meta_cv.h include/rw/_tuple.h include/tuple tests/utilities/20.tuple.elem.cpp
>
>Author: elemings
>Date: Thu Jun 19 15:09:13 2008
>New Revision: 669723
>
>URL: http://svn.apache.org/viewvc?rev=669723&view=rev
>Log:
>2008-06-19 Eric Lemings <[EMAIL PROTECTED]>
>
> STDCXX-958
[...]
>+template
>+_TYPENAME tuple_element<_Index, tuple<_Head, _Tail...> >::_Ref
>+get (tuple<_Head, _Tail...>& __tuple)
>+{
>+typedef tuple_element<_Index, tuple<_Head, _Tail...> > _Tuple;
>+return _Tuple::__get (__tuple);
>+}
>+
>+template
>+_TYPENAME tuple_element<_Index, tuple<_Head, _Tail...> >::_ConstRef
>+get (const tuple<_Head, _Tail...>& __tuple)
>+{
>+typedef tuple_element<_Index, tuple<_Head, _Tail...> > _Tuple;
>+return _Tuple::__get (__tuple);
>+}
I just noticed LWG775. We should probably consider adopting the proposed
reslution.
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#775
Travis
RE: :decay related question
Martin Sebor wrote: > >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.) > I don't see one. Unless Brad knows something that we don't, I think it should be brought up. >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: __rw_and (Was RE: Some internal aliases for __rw_integral_constant?)
> -Original Message-
> From: Eric Lemings [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 25, 2008 11:41 AM
> To: dev@stdcxx.apache.org
> Subject: __rw_and (Was RE: Some internal aliases for
> __rw_integral_constant?)
>
>
>
> > -Original Message-
> > From: Eric Lemings [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 24, 2008 6:01 PM
> > To: dev@stdcxx.apache.org
> > Subject: 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.
>
> Okay, another proposal for inclusion though this particular utility
> may be a stretch unless you understand variadic templates very well.
>
> template
> struct __rw_and;
>
> template <>
> struct __rw_and<>: std::true_type {};
>
> template
> struct __rw_and<_Bool0, _BoolN...>
> : _RWSTD_BOOL_CONST (_Bool0 && __rw_and<_BoolN...>::value)
> {};
Actually that should probably be something like:
: std::conditional<_Bool0, __rw_and<_BoolN...>,
std::false_type>
Assuming the compiler isn't smart enough to short-circuit such
instantiations already.
Brad.
RE: __rw_and (Was RE: Some internal aliases for __rw_integral_constant?)
Eric Lemings wrote:
>
>Okay, another proposal for inclusion though this particular utility
>may be a stretch unless you understand variadic templates very well.
>
> template
> struct __rw_and;
>
> template <>
> struct __rw_and<>: std::true_type {};
>
> template
> struct __rw_and<_Bool0, _BoolN...>
> : _RWSTD_BOOL_CONST (_Bool0 && __rw_and<_BoolN...>::value)
>{};
>
>For example:
>
> template
> struct tuple {
>
> template
> struct __rw_is_compat
> : __rw_and_TypesU>::value...> {
>
> static_assert (sizeof... (_TypesT) == sizeof...
>(_TypesU),
> "tuple sizes must be equal");
> };
>
> };
>
Interesting. I have seen similar utilities, but they usually took two
parameters, so I never really saw them as useful. This, on the other
hand, does seem useful.
I'm assuming you are considering a fallback implementation like I have
for aligned_union when variadic templates aren't supported.
>Here are some quick tests that I tried out on it:
>
>typedef tuple T1;
>std::cout << T1::__rw_is_compat::value
> << std::endl;
>
>std::cout << T1::__rw_is_compatlong>::value
> << std::endl;
>
>std::cout << T1::__rw_is_compat::value
> << std::endl;
>
>std::cout << T1::__rw_is_compat::value
> << std::endl;
>
>// fires the static assertion
>//std::cout << T1::__rw_is_compat::value
> //<< std::endl;
>
>Might just save that one for later but worth posting at least. :)
>
>Brad.
>
__rw_and (Was RE: Some internal aliases for __rw_integral_constant?)
> -Original Message-
> From: Eric Lemings [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 24, 2008 6:01 PM
> To: dev@stdcxx.apache.org
> Subject: 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.
Okay, another proposal for inclusion though this particular utility
may be a stretch unless you understand variadic templates very well.
template
struct __rw_and;
template <>
struct __rw_and<>: std::true_type {};
template
struct __rw_and<_Bool0, _BoolN...>
: _RWSTD_BOOL_CONST (_Bool0 && __rw_and<_BoolN...>::value)
{};
For example:
template
struct tuple {
template
struct __rw_is_compat
: __rw_and::value...> {
static_assert (sizeof... (_TypesT) == sizeof...
(_TypesU),
"tuple sizes must be equal");
};
};
Here are some quick tests that I tried out on it:
typedef tuple T1;
std::cout << T1::__rw_is_compat::value
<< std::endl;
std::cout << T1::__rw_is_compat::value
<< std::endl;
std::cout << T1::__rw_is_compat::value
<< std::endl;
std::cout << T1::__rw_is_compat::value
<< std::endl;
// fires the static assertion
//std::cout << T1::__rw_is_compat::value
//<< std::endl;
Might just save that one for later but worth posting at least. :)
Brad.
RE: question about aligned_storage
Martin Sebor wrote:
>
>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... :)
You give me more credit than I deserve. I'm making this stuff up as I
go... :)
>
>> 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 ;-)
>
Yeah, I have a few long lines. I need to clean up the mess that I've
made.
>>
>> 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.)
Yes. I probably need to do something here, but I'm not sure what. Table
51 says
_Align shall be equal to alignment_of::value for some type
T or to `default-alignment'
This essentially says that I need to support all valid alignment values
on the platform. Fortunately, for the time being the power of two
restriction is okay. The only functionality I have available to me for
doing alignment (on the tested platforms) is __declspec(align(#)) on
Microsoft and __attribute__ ((aligned(#))) on gcc-4.3. Both of these
support functions require that the alignment value be a power of two.
The Microsoft compiler has the 8192 limit.
The draft shows a 'typical implementation' of aligned_storage that uses
the new alignas keyword, but alignas doesn't appear to be supported
anywhere. The following code is very similar to that typical
implementation, but it does not compile because value passed to the
aligned attribute has to be a literal, not a constant expression.
template ::value>
struct __rw_aligned_storage
{
typedef struct {
char _C_align [_Size] __attribute__ ((aligned(_Align)));
} type;
};
Travis
>
>Martin
>
>>
>>> See http://tinyurl.com/5kmvdy for reference.
>>>
>>> Martin
>>>
>>>
>
>
