On Tue, Mar 1, 2016 at 8:43 AM, Michael Matz via cfe-commits
wrote:
> Hi,
>
> On Mon, 29 Feb 2016, Jason Merrill wrote:
>
>> > Also this insistence that all of "trivially copyable" is already quite
>> > nicely specified in the C++ ABI is still not really relevant because
>> > C++ _is not the only
On 03/01/2016 11:43 AM, Michael Matz wrote:
Hi,
On Mon, 29 Feb 2016, Jason Merrill wrote:
Also this insistence that all of "trivially copyable" is already quite
nicely specified in the C++ ABI is still not really relevant because
C++ _is not the only language out there_. I'm not sure how ofte
Hi,
On Mon, 29 Feb 2016, Jason Merrill wrote:
> > Also this insistence that all of "trivially copyable" is already quite
> > nicely specified in the C++ ABI is still not really relevant because
> > C++ _is not the only language out there_. I'm not sure how often I
> > have to repeat this unti
On 02/29/2016 10:13 AM, Michael Matz via cfe-commits wrote:
Also this insistence that all of "trivially copyable" is
already quite nicely specified in the C++ ABI is still not really relevant
because C++ _is not the only language out there_. I'm not sure how often
I have to repeat this until peo
Hi,
On Fri, 26 Feb 2016, H.J. Lu wrote:
> >> It is clear to me now. Let's go with
> >>
> >> ---
> >> An empty type is a type where it and all of its subobjects (recursively)
> >> are of class, structure, union, or array type. No memory slot nor
> >> register should be used to pass or return an
On Tue, Feb 23, 2016 at 5:14 PM, Richard Smith wrote:
> On Tue, Feb 23, 2016 at 8:28 AM, H.J. Lu wrote:
>> On Tue, Feb 23, 2016 at 8:15 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Tue, 23 Feb 2016, H.J. Lu wrote:
>>>
I thought
---
An empty type is a type where it and all of it
On Tue, Feb 23, 2016 at 8:28 AM, H.J. Lu wrote:
> On Tue, Feb 23, 2016 at 8:15 AM, Michael Matz wrote:
>> Hi,
>>
>> On Tue, 23 Feb 2016, H.J. Lu wrote:
>>
>>> I thought
>>>
>>> ---
>>> An empty type is a type where it and all of its subobjects (recursively)
>>> are of class, structure, union, or
On Tue, Feb 23, 2016 at 8:15 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 23 Feb 2016, H.J. Lu wrote:
>
>> I thought
>>
>> ---
>> An empty type is a type where it and all of its subobjects (recursively)
>> are of class, structure, union, or array type.
>> ---
>>
>> excluded
>>
>> struct empty
>> {
>>
Hi,
On Tue, 23 Feb 2016, H.J. Lu wrote:
> I thought
>
> ---
> An empty type is a type where it and all of its subobjects (recursively)
> are of class, structure, union, or array type.
> ---
>
> excluded
>
> struct empty
> {
> empty () = default;
> };
Why would that be excluded? There are no
On Tue, Feb 23, 2016 at 7:30 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 23 Feb 2016, H.J. Lu wrote:
>
>> > ---
>> > An empty type is a type where it and all of its subobjects (recursively)
>> > are of class, structure, union, or array type. No memory slot nor
>> > register should be used to pass o
Hi,
On Tue, 23 Feb 2016, H.J. Lu wrote:
> > ---
> > An empty type is a type where it and all of its subobjects (recursively)
> > are of class, structure, union, or array type. No memory slot nor
> > register should be used to pass or return an object of empty type that's
> > trivially copyable.
On Mon, Feb 22, 2016 at 4:50 AM, Michael Matz wrote:
> Hi,
>
> On Sat, 20 Feb 2016, Richard Smith wrote:
>
>> > An empty type is a type where it and all of its subobjects
>> > (recursively) are of class, structure, union, or array type.
>> >
>> > doesn't cover "trivially-copyable".
>>
>> That's co
Hi,
On Sat, 20 Feb 2016, Richard Smith wrote:
> > An empty type is a type where it and all of its subobjects
> > (recursively) are of class, structure, union, or array type.
> >
> > doesn't cover "trivially-copyable".
>
> That's correct. Whether a type is trivially copyable is unrelated to
> w
Hi,
On Fri, 19 Feb 2016, Richard Smith wrote:
> >> > The trivially copyable is gone again. Why is it not necessary?
> >>
> >> The C++ ABI doesn't defer to the C psABI for types that aren't
> >> trivially-copyable. See
> >> http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
> >
> > Hmm,
On Sat, Feb 20, 2016 at 10:48 PM, Richard Smith wrote:
> On 20 Feb 2016 10:01 p.m., "H.J. Lu" wrote:
>>
>> On Sat, Feb 20, 2016 at 9:47 PM, Richard Smith
>> wrote:
>> > On 20 Feb 2016 6:54 p.m., "H.J. Lu" wrote:
>> >>
>> >> On Sat, Feb 20, 2016 at 4:57 PM, Matthijs van Duin
>> >> wrote:
>> >>
On Sat, Feb 20, 2016 at 9:47 PM, Richard Smith wrote:
> On 20 Feb 2016 6:54 p.m., "H.J. Lu" wrote:
>>
>> On Sat, Feb 20, 2016 at 4:57 PM, Matthijs van Duin
>> wrote:
>> > On 20 February 2016 at 23:35, H.J. Lu wrote:
>> >> Can a compiler tell if a copy constructor or destructor is trivial
>> >>
On Sat, Feb 20, 2016 at 4:57 PM, Matthijs van Duin
wrote:
> On 20 February 2016 at 23:35, H.J. Lu wrote:
>> Can a compiler tell if a copy constructor or destructor is trivial
>> from the class declaration without function body?
>
> Yes, the mere presence of the declaration suffices to render it
>
On 20 February 2016 at 23:35, H.J. Lu wrote:
> Can a compiler tell if a copy constructor or destructor is trivial
> from the class declaration without function body?
Yes, the mere presence of the declaration suffices to render it
non-trivial (unless explicitly declared "= default" like I did with
On Sat, Feb 20, 2016 at 11:40 AM, Matthijs van Duin
wrote:
> On 20 February 2016 at 20:34, H.J. Lu wrote:
>> Is there a class, which meets the above definition, with a member function
>> which can't be passed without a memory slot or a register?
>
> The EmptyInt class in my first post in this th
On 20 February 2016 at 20:34, H.J. Lu wrote:
> Is there a class, which meets the above definition, with a member function
> which can't be passed without a memory slot or a register?
The EmptyInt class in my first post in this thread. It has no
non-static data members, has standard layout, and h
On Sat, Feb 20, 2016 at 10:50 AM, Matthijs van Duin
wrote:
> On 20 February 2016 at 18:55, H.J. Lu wrote:
>> struct dummy0
>> {
>> };
>>
>> struct dummy
>> {
>> dummy0 d[20];
>>
>> dummy0 * foo (int i);
>> };
>>
>> dummy0 *
>> dummy::foo (int i)
>> {
>> return &d[i];
>> }
>>
>> dummy0 *
>>
On 20 February 2016 at 18:55, H.J. Lu wrote:
> struct dummy0
> {
> };
>
> struct dummy
> {
> dummy0 d[20];
>
> dummy0 * foo (int i);
> };
>
> dummy0 *
> dummy::foo (int i)
> {
> return &d[i];
> }
>
> dummy0 *
> bar (dummy d, int i)
> {
> return d.foo (i);
> }
1. This has undefined behavio
On Sat, 20 Feb 2016, H.J. Lu wrote:
On Fri, Feb 19, 2016 at 1:07 PM, Richard Smith wrote:
On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz wrote:
Hi,
On Thu, 18 Feb 2016, Richard Smith wrote:
An empty type is a type where it and all of its subobjects
(recursively) are of class, structure, un
On Fri, Feb 19, 2016 at 1:07 PM, Richard Smith wrote:
> On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 18 Feb 2016, Richard Smith wrote:
>>
>>> >> An empty type is a type where it and all of its subobjects
>>> >> (recursively) are of class, structure, union, or array ty
On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 18 Feb 2016, Richard Smith wrote:
>
>> >> An empty type is a type where it and all of its subobjects
>> >> (recursively) are of class, structure, union, or array type. No
>> >> memory slot nor register should be used to pass o
On Fri, Feb 19, 2016 at 11:03 AM, Matthijs van Duin
wrote:
> On 19 February 2016 at 14:35, Michael Matz wrote:
>> struct S {
>> S() {something();}
>> };
>>
>> would be an empty type, and that's not what we want.
>
> Why not? The default constructor is never invoked as part of passing
> such an
On 19 February 2016 at 14:35, Michael Matz wrote:
> struct S {
> S() {something();}
> };
>
> would be an empty type, and that's not what we want.
Why not? The default constructor is never invoked as part of passing
such an object around. Its copy constructor is a nop and requires no
reference t
On 19 February 2016 at 16:27, H.J. Lu wrote:
> We want to include static member functions and exclude non-static member
> functions.
There's no reason to disallow non-static member functions in general; they
have no impact on being trivially copyable or not, only the presence of a
non-trivial cop
On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 18 Feb 2016, Richard Smith wrote:
>
>> >> An empty type is a type where it and all of its subobjects
>> >> (recursively) are of class, structure, union, or array type. No
>> >> memory slot nor register should be used to pass o
Hi,
On Thu, 18 Feb 2016, H.J. Lu wrote:
> >> An empty type is a type where it and all of its subobjects
> >> (recursively) are of class, structure, union, or array type. No
> >> memory slot nor register should be used to pass or return an object
> >> of empty type.
> >
> > The trivially copya
Hi,
On Thu, 18 Feb 2016, Richard Smith wrote:
> >> An empty type is a type where it and all of its subobjects
> >> (recursively) are of class, structure, union, or array type. No
> >> memory slot nor register should be used to pass or return an object
> >> of empty type.
> >
> > The trivially
On Thu, Feb 18, 2016 at 6:35 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 16 Feb 2016, H.J. Lu wrote:
>
>> Here is the new definition:
>>
>> An empty type is a type where it and all of its subobjects (recursively)
>> are of class, structure, union, or array type. No memory slot nor
>> register shoul
On Thu, Feb 18, 2016 at 6:35 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 16 Feb 2016, H.J. Lu wrote:
>
>> Here is the new definition:
>>
>> An empty type is a type where it and all of its subobjects (recursively)
>> are of class, structure, union, or array type. No memory slot nor
>> register shoul
Hi,
On Tue, 16 Feb 2016, H.J. Lu wrote:
> Here is the new definition:
>
> An empty type is a type where it and all of its subobjects (recursively)
> are of class, structure, union, or array type. No memory slot nor
> register should be used to pass or return an object of empty type.
The triv
On Tue, Feb 16, 2016 at 3:36 PM, Richard Smith wrote:
> On Tue, Feb 16, 2016 at 1:48 PM, H.J. Lu wrote:
>> On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith wrote:
>>> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu wrote:
On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith
wrote:
> On Tue, Fe
On Tue, Feb 16, 2016 at 1:48 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu wrote:
>>> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith
>>> wrote:
On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2
On Tue, Feb 16, 2016 at 1:45 PM, Richard Smith wrote:
> On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu wrote:
>> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith wrote:
>>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith
wrote:
> On Tue, Fe
On Tue, Feb 16, 2016 at 1:21 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
>>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith
>>> wrote:
On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
> On Tue, Feb 16,
On Tue, Feb 16, 2016 at 1:15 PM, Richard Smith wrote:
> On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
>> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith wrote:
>>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
wrote:
> On Tue,
On Tue, Feb 16, 2016 at 1:10 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
>>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
>>> wrote:
On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>
> On Fri,
On Tue, Feb 16, 2016 at 1:02 PM, Richard Smith wrote:
> On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
>> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith
>> wrote:
>>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
> On Fri,
On Tue, Feb 16, 2016 at 12:25 PM, H.J. Lu wrote:
> On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith wrote:
>> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>>
>>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>>> > wrote:
>>> >> On
On Tue, Feb 16, 2016 at 12:22 PM, Richard Smith wrote:
> On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>>
>> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
>> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
>> > wrote:
>> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
>> >>> struct
On Tue, Feb 16, 2016 at 10:24 AM, H.J. Lu wrote:
>
> On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
> > On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
> > wrote:
> >> On 11 February 2016 at 16:31, H.J. Lu wrote:
> >>> struct A {
> >>> static void foo (void) ();
> >>> static int xxx;
> >>>
On Fri, Feb 12, 2016 at 11:39 AM, H.J. Lu wrote:
> On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
> wrote:
>> On 11 February 2016 at 16:31, H.J. Lu wrote:
>>> struct A {
>>> static void foo (void) ();
>>> static int xxx;
>>> };
>>
>> What about it? It's an empty struct. (And it declares a f
On Fri, Feb 12, 2016 at 6:58 AM, Matthijs van Duin
wrote:
> On 11 February 2016 at 16:31, H.J. Lu wrote:
>> struct A {
>> static void foo (void) ();
>> static int xxx;
>> };
>
> What about it? It's an empty struct. (And it declares a function and
> a variable in the namespace of A, which however
On 11 February 2016 at 16:31, H.J. Lu wrote:
> struct A {
> static void foo (void) ();
> static int xxx;
> };
What about it? It's an empty struct. (And it declares a function and
a variable in the namespace of A, which however do not have any
relevant impact here.)
Matthijs van Duin
On Thu, Feb 11, 2016 at 6:54 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 11 Feb 2016, H.J. Lu wrote:
>
>> Any suggestions on new wording, something like
>>
>> 1. "class type". A class type is a structure, union or C++ class.
>> 2. "empty type". An empty type is a type where it and all of its
>>
To avoid depending again on precise wording of definitions in C++
standard it may be worth being explicit about the requirement to be
trivially copyable *and* destructible, since although the former
implies the latter in the C++ standard this is not obvious from the
terminology (although you also n
Hi,
On Thu, 11 Feb 2016, H.J. Lu wrote:
> Any suggestions on new wording, something like
>
> 1. "class type". A class type is a structure, union or C++ class.
> 2. "empty type". An empty type is a type where it and all of its
> subobjects are of class or array type.
>
> Does it cover
>
>
On Thu, Feb 11, 2016 at 6:30 AM, Michael Matz wrote:
> Hi,
>
> On Thu, 11 Feb 2016, Jonathan Wakely wrote:
>
>> On 11 February 2016 at 12:40, Matthijs van Duin wrote:
>> > You never define "POD for the purposes of layout", and I can only
>> > interpret it as being equivalent to "standard-layout".
Hi,
On Thu, 11 Feb 2016, Jonathan Wakely wrote:
> On 11 February 2016 at 12:40, Matthijs van Duin wrote:
> > You never define "POD for the purposes of layout", and I can only
> > interpret it as being equivalent to "standard-layout".
>
> As Richard pointed out, it's defined in the C++ ABI.
Whic
On Thu, Feb 11, 2016 at 6:18 AM, Matthijs van Duin
wrote:
> On 11 February 2016 at 15:00, H.J. Lu wrote:
>> I intentionally exclude C++ specific features in my propose.
>
> Yet you use a definition from the Itanium C++ ABI which itself depends
> on multiple definitions in a particular version of
On 11 February 2016 at 15:00, H.J. Lu wrote:
> I intentionally exclude C++ specific features in my propose.
Yet you use a definition from the Itanium C++ ABI which itself depends
on multiple definitions in a particular version of the C++ standard,
which depend on C++ specific features.
This make
On Thu, Feb 11, 2016 at 5:44 AM, Matthijs van Duin
wrote:
> On 11 February 2016 at 13:58, H.J. Lu wrote:
>> "POD for the purpose of layout" is defined in the Itanium C++ ABI here:
>>
>> http://mentorembedded.github.io/cxx-abi/abi.html#definitions
>
> Sorry, I overlooked that.
>
> I still stand by
On 11 February 2016 at 13:58, H.J. Lu wrote:
> "POD for the purpose of layout" is defined in the Itanium C++ ABI here:
>
> http://mentorembedded.github.io/cxx-abi/abi.html#definitions
Sorry, I overlooked that.
I still stand by my viewpoint however that triviality of copying and
destruction is th
On Thu, Feb 11, 2016 at 4:40 AM, Matthijs van Duin
wrote:
> On 11 February 2016 at 11:53, H.J. Lu wrote:
>> Since this isn't Plain Old Data (POD) for the purposes of layout, it
>> isn't covered by my proposal for psABI. I leave this to C++ ABI.
>
> You never define "POD for the purposes of layou
On 11 February 2016 at 12:40, Matthijs van Duin wrote:
> You never define "POD for the purposes of layout", and I can only
> interpret it as being equivalent to "standard-layout".
As Richard pointed out, it's defined in the C++ ABI.
On 11 February 2016 at 11:53, H.J. Lu wrote:
> Since this isn't Plain Old Data (POD) for the purposes of layout, it
> isn't covered by my proposal for psABI. I leave this to C++ ABI.
You never define "POD for the purposes of layout", and I can only
interpret it as being equivalent to "standard-l
On Thu, Feb 11, 2016 at 2:47 AM, Matthijs van Duin
wrote:
> On 8 February 2016 at 22:40, H.J. Lu wrote:
>> "empty type". An empty type is either an array of empty types or a
>> class type where every member is of empty type.
>
> Note that the term "empty type" is commonly used in type theory to
On 8 February 2016 at 22:40, H.J. Lu wrote:
> "empty type". An empty type is either an array of empty types or a
> class type where every member is of empty type.
Note that the term "empty type" is commonly used in type theory to
denote a (or the) type with no values. The closest thing C has wo
On Tue, Feb 9, 2016 at 6:45 AM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 3:28 PM, Richard Smith wrote:
>> On Mon, Feb 8, 2016 at 3:01 PM, H.J. Lu wrote:
>>> On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote:
On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 2:51
On Mon, Feb 8, 2016 at 3:28 PM, Richard Smith wrote:
> On Mon, Feb 8, 2016 at 3:01 PM, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote:
>>> On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote:
On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith
wrote:
> On Mon, Feb 8,
On Mon, Feb 8, 2016 at 3:01 PM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote:
>> On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote:
>>> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote:
On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 2:35
On Mon, Feb 8, 2016 at 2:55 PM, Richard Smith wrote:
> On Mon, Feb 8, 2016 at 2:49 PM, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 2:42 PM, Richard Smith wrote:
>>> Do we really need an 'empty type' special case?
>>>
>>> The x86_64 psABI already seems clear that empty types with size <= 16
>>> are
On Mon, Feb 8, 2016 at 2:58 PM, Richard Smith wrote:
> On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote:
>>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote:
On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith
wrote:
> On Mon, Feb 8,
On Mon, Feb 8, 2016 at 2:54 PM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote:
>> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote:
>>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote:
On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote:
>
> On Mon, Feb 8, 2016 a
On Mon, Feb 8, 2016 at 2:49 PM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 2:42 PM, Richard Smith wrote:
>> Do we really need an 'empty type' special case?
>>
>> The x86_64 psABI already seems clear that empty types with size <= 16
>> are not passed at all. Following the algorithm in section 3.2.3,
On Mon, Feb 8, 2016 at 2:51 PM, Richard Smith wrote:
> On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote:
>>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote:
On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith
wrote:
> On Mon,
On Mon, Feb 8, 2016 at 2:46 PM, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote:
>> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote:
>>>
>>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith
>>> wrote:
>>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote:
>>> >>
>>> >> On Mon,
On Mon, Feb 8, 2016 at 2:42 PM, Richard Smith wrote:
> Do we really need an 'empty type' special case?
>
> The x86_64 psABI already seems clear that empty types with size <= 16
> are not passed at all. Following the algorithm in section 3.2.3, each
> eightbyte is classified as NO_CLASS, and thus i
On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith wrote:
> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote:
>>
>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote:
>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote:
>> >>
>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely
>> >> wrote:
>> >>
Do we really need an 'empty type' special case?
The x86_64 psABI already seems clear that empty types with size <= 16
are not passed at all. Following the algorithm in section 3.2.3, each
eightbyte is classified as NO_CLASS, and thus is not passed. So the
proposed change would only affect the beha
On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu wrote:
>
> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote:
> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote:
> >>
> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely
> >> wrote:
> >> > On 8 February 2016 at 19:23, Richard Smith wrote:
> >> >> "P
On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith wrote:
> On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu wrote:
>>
>> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely
>> wrote:
>> > On 8 February 2016 at 19:23, Richard Smith wrote:
>> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI
On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 19:23, Richard Smith wrote:
>> "POD for the purpose of layout" is defined in the Itanium C++ ABI here:
>>
>> http://mentorembedded.github.io/cxx-abi/abi.html#definitions
>
> Thanks. So there's no problem using "POD f
On 8 February 2016 at 19:23, Richard Smith wrote:
> "POD for the purpose of layout" is defined in the Itanium C++ ABI here:
>
> http://mentorembedded.github.io/cxx-abi/abi.html#definitions
Thanks. So there's no problem using "POD for the purposes of layout",
and the change to "POD for the purpos
On Mon, Feb 8, 2016 at 10:46 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 18:31, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely
>> wrote:
>>> On 8 February 2016 at 18:26, Jonathan Wakely wrote:
On 8 February 2016 at 17:58, H.J. Lu wrote:
> On Mon, Feb 8, 2016
On 8 February 2016 at 18:31, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely
> wrote:
>> On 8 February 2016 at 18:26, Jonathan Wakely wrote:
>>> On 8 February 2016 at 17:58, H.J. Lu wrote:
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
wrote:
>>> A type is a s
On 8 February 2016 at 17:58, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote:
A type is a standard-layout type, or it isn't.
>>>
>>> How about "An empty record is standard-layout Plain Old Data (POD)
>>> type and ..."?
>>
>> That's redundant, all POD types are standard-
On Mon, Feb 8, 2016 at 10:30 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 18:26, Jonathan Wakely wrote:
>> On 8 February 2016 at 17:58, H.J. Lu wrote:
>>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
>>> wrote:
>> A type is a standard-layout type, or it isn't.
>
> How about
On 8 February 2016 at 18:26, Jonathan Wakely wrote:
> On 8 February 2016 at 17:58, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely
>> wrote:
> A type is a standard-layout type, or it isn't.
How about "An empty record is standard-layout Plain Old Data (POD)
ty
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote:
>>> A type is a standard-layout type, or it isn't.
>>
>> How about "An empty record is standard-layout Plain Old Data (POD)
>> type and ..."?
>
> That's redundant, all POD types are standard-layout types.
>
Apparently, not all standard-layout
On Mon, Feb 8, 2016 at 8:15 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 16:05, H.J. Lu wrote:
>> My understanding is
>>
>> A type that is standard-layout means that it orders and packs its
>> members in a way that is compatible with C.
>>
>> What is the corresponding compatible type in C?
>
On 8 February 2016 at 16:05, H.J. Lu wrote:
> My understanding is
>
> A type that is standard-layout means that it orders and packs its
> members in a way that is compatible with C.
>
> What is the corresponding compatible type in C?
An empty structure, such as struct A.
One of the requirements f
On Mon, Feb 8, 2016 at 7:59 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 15:42, H.J. Lu wrote:
>> On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely
>> wrote:
>>> On 8 February 2016 at 13:54, H.J. Lu wrote:
On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
The standard-layout
On 8 February 2016 at 15:42, H.J. Lu wrote:
> On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely wrote:
>> On 8 February 2016 at 13:54, H.J. Lu wrote:
>>> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
>>>
>>> The standard-layout POD is well defined:
>>>
>>> https://en.wikipedia.org/wiki/C%2B%2B1
On Mon, Feb 8, 2016 at 7:02 AM, Jonathan Wakely wrote:
> On 8 February 2016 at 13:54, H.J. Lu wrote:
>> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
>>
>> The standard-layout POD is well defined:
>>
>> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
>>
On 8 February 2016 at 13:54, H.J. Lu wrote:
> On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
>
> The standard-layout POD is well defined:
>
> https://en.wikipedia.org/wiki/C%2B%2B11#Modification_to_the_definition_of_plain_old_data
>
> Here is the updated proposal for Intel386, x86-64 and IA MCU
On Sun, Feb 7, 2016 at 12:52 PM, H.J. Lu wrote:
> On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer wrote:
>> * H. J. Lu:
>>
I tested GCC 5.3.1 and Clang 3.5.0.
GCC Clang
s0 non-emptynon-empty
s1 non-emptyempty
s2 non-emptyempty
s3
On Sun, Feb 7, 2016 at 12:48 PM, Florian Weimer wrote:
> * H. J. Lu:
>
>>> I tested GCC 5.3.1 and Clang 3.5.0.
>>>
>>> GCC Clang
>>> s0 non-emptynon-empty
>>> s1 non-emptyempty
>>> s2 non-emptyempty
>>> s3 emptyempty
>>> s4 emptyempty
>>> s5 no
* H. J. Lu:
>> I tested GCC 5.3.1 and Clang 3.5.0.
>>
>> GCC Clang
>> s0 non-emptynon-empty
>> s1 non-emptyempty
>> s2 non-emptyempty
>> s3 emptyempty
>> s4 emptyempty
>> s5 non-emptyempty
>>
>> I believe s3, s4, s5 are non-empty according
On Sun, Feb 7, 2016 at 12:08 PM, Florian Weimer wrote:
> * H. J. Lu:
>
>>> Any syntactical array argument (at the C level) is should be passed as
>>> a pointer. The language appears to change that.
>>
>> I didn't use aggregate so that array is excluded here.
>>
>>> For 2., static members and non-
* H. J. Lu:
>> Any syntactical array argument (at the C level) is should be passed as
>> a pointer. The language appears to change that.
>
> I didn't use aggregate so that array is excluded here.
>
>> For 2., static members and non-data members do not count.
>
> They do count here. That is why I
On Sun, Feb 7, 2016 at 11:36 AM, H.J. Lu wrote:
> On Sun, Feb 7, 2016 at 11:31 AM, Florian Weimer wrote:
>> * H. J. Lu:
>>
>>> I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify
>>> how to pass/return empty struct:
>>>
>>> 1. "collection". A collection is a structure, union o
On Sun, Feb 7, 2016 at 11:31 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>> I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify
>> how to pass/return empty struct:
>>
>> 1. "collection". A collection is a structure, union or C++ class.
>> 2. "empty collection". An empty collecti
* H. J. Lu:
> I am proposing to update Intel386, x86-64 and IA MCU psABIs to specify
> how to pass/return empty struct:
>
> 1. "collection". A collection is a structure, union or C++ class.
> 2. "empty collection". An empty collection is:
>a. A collection without member. Or
>b. A collec
97 matches
Mail list logo
