On 03/06/2015 06:03 PM, Ville Voutilainen wrote:
So.. just to clarify that we're on the same page.. making volatile-qualified
types non-trivially copyable is ok, but making wrappers of volatile-qualified
types non-trivially copyable is not ok? That's easily doable
implementation-wise,
but it mak
On 6 March 2015 at 23:58, Jason Merrill wrote:
> On 01/19/2015 11:28 AM, Ville Voutilainen wrote:
>>
>> * class.c (check_field_decls): If any field is volatile, make
>> the class type have complex copy/move operations.
>
>
> Discussion on the cxx-abi list points out that this breaks ABI
On 01/19/2015 11:28 AM, Ville Voutilainen wrote:
* class.c (check_field_decls): If any field is volatile, make
the class type have complex copy/move operations.
Discussion on the cxx-abi list points out that this breaks ABI
compatibility between C and C++, and is therefore unacceptab
On 30 January 2015 at 23:06, Ville Voutilainen
wrote:
> Let's drop libstdc++, this discussion is about a test that doesn't
> really concern them.
>
> On 30 January 2015 at 22:51, Jason Merrill wrote:
>> The patch changes all the static_assert strings to "", which is not very
>> useful; let's keep
On 01/30/2015 03:05 PM, Ville Voutilainen wrote:
-#define TRY(expr) static_assert (expr, #expr)
The patch changes all the static_assert strings to "", which is not very
useful; let's keep the macro.
Jason
Let's drop libstdc++, this discussion is about a test that doesn't
really concern them.
On 30 January 2015 at 22:51, Jason Merrill wrote:
> The patch changes all the static_assert strings to "", which is not very
> useful; let's keep the macro.
Ok. How about this one? It reuses the macro and ke
On 30 January 2015 at 21:59, Ville Voutilainen
wrote:
> So, a new patch attached. The only change to the previous one is the change
> to the trivial1.C test.
Oops. The No-template was borken and there was remnants of the macros
in commented
code. Let's try that again, shall we? :) Attached.
diff
On 30 January 2015 at 20:25, Jason Merrill wrote:
> On 01/30/2015 01:13 PM, Ville Voutilainen wrote:
>>>
>>> Why would void *const volatile still be trivial?
>>
>>
>> Ah. It isn't. YES and YES2 are macros, so YES2(void*) expands to
>> is_trivial::value, which is true, whereas
>> is_trivial
On 01/30/2015 01:13 PM, Ville Voutilainen wrote:
Why would void *const volatile still be trivial?
Ah. It isn't. YES and YES2 are macros, so YES2(void*) expands to
is_trivial::value, which is true, whereas
is_trivial::value is false.
I think it would be reasonable to convert these macro
On 30 January 2015 at 19:46, Jason Merrill wrote:
> On 01/20/2015 09:27 AM, Ville Voutilainen wrote:
>>
>> +#define YES2(type) TRY(std::is_trivial::value); \
>> + TRY(std::is_trivial::value); \
>> TRY(std::is_trivial::value)
>
>
>> +YES2(void *);
>> +YES2(int A::*);
>
>
> Why would void *cons
On 01/20/2015 09:27 AM, Ville Voutilainen wrote:
+#define YES2(type) TRY(std::is_trivial::value); \
+ TRY(std::is_trivial::value); \
TRY(std::is_trivial::value)
+YES2(void *);
+YES2(int A::*);
Why would void *const volatile still be trivial?
Jason
On 20 January 2015 at 15:06, Jason Merrill wrote:
> On 01/19/2015 06:06 PM, Ville Voutilainen wrote:
>>
>> + return (trivial_type_p (type1)
>> + || (scalarish_type_p (type1) && CP_TYPE_VOLATILE_P (type1))
>> + || type_code1 == REFERENCE_TYPE
>> || (CLASS_
On 01/19/2015 06:06 PM, Ville Voutilainen wrote:
+ return (trivial_type_p (type1)
+ || (scalarish_type_p (type1) && CP_TYPE_VOLATILE_P (type1))
+ || type_code1 == REFERENCE_TYPE
|| (CLASS_TYPE_P (type1)
&& TYPE_HAS_TRIVIAL_DESTRUCTOR (t
On 19 January 2015 at 21:12, Ville Voutilainen
wrote:
> On 19 January 2015 at 18:28, Ville Voutilainen
> wrote:
>> When I patched the triviality test for volatile types, I missed two cases:
>> 1) volatile members in a class should make the class non-trivial.
>> 2) a volatile class type should its
On 19 January 2015 at 18:28, Ville Voutilainen
wrote:
> When I patched the triviality test for volatile types, I missed two cases:
> 1) volatile members in a class should make the class non-trivial.
> 2) a volatile class type should itself be non-trivial.
> (based on [basic.types]/9, [class]/6, [c
When I patched the triviality test for volatile types, I missed two cases:
1) volatile members in a class should make the class non-trivial.
2) a volatile class type should itself be non-trivial.
(based on [basic.types]/9, [class]/6, [class.copy]/12 and [class.copy]/25)
I haven't completed testing
16 matches
Mail list logo
