Re: r279076 - [libclang] Add clang_getAllSkippedRanges function

[H.J. Lu via cfe-commits]

On Thu, Aug 18, 2016 at 8:43 AM, Cameron Desrochers via cfe-commits
 wrote:
> Author: cameron314
> Date: Thu Aug 18 10:43:55 2016
> New Revision: 279076
>
> URL: http://llvm.org/viewvc/llvm-project?rev=279076=rev
> Log:
> [libclang] Add clang_getAllSkippedRanges function
>
> This complements the clang_getSkippedRanges function which returns skipped 
> ranges filtered by a specific file.
>
> This function is useful when all the ranges are desired (and a lot more 
> efficient than the equivalent of asking for the ranges file by file, since 
> the implementation of clang_getSkippedRanges iterates over all ranges anyway).
>
> Differential Revision: https://reviews.llvm.org/D20132
>
> Modified:
> cfe/trunk/include/clang-c/Index.h
> cfe/trunk/tools/libclang/CIndex.cpp
> cfe/trunk/unittests/libclang/LibclangTest.cpp
>

libclangTests fails for me on Linux:

cd 
/export/build/gnu/llvm-clang/build-x86_64-linux/tools/clang/unittests/libclang
&& /usr/bin/cmake -E cmake_link_script
CMakeFiles/libclangTests.dir/link.txt --verbose=1
/usr/bin/g++  -m64   -fPIC -fvisibility-inlines-hidden -Wall -W
-Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment
-Werror=date-time -std=c++11 -ffunction-sections -fdata-sections
-fno-common -Woverloaded-virtual -fno-strict-aliasing -O2 -g -DNDEBUG
 -Wl,-allow-shlib-undefined  -Wl,-O3 -Wl,--gc-sections
CMakeFiles/libclangTests.dir/LibclangTest.cpp.o  -o libclangTests
../../../../lib/libLLVMSupport.a -lpthread
../../../../lib/libgtest_main.a ../../../../lib/libgtest.a -lpthread
../../../../lib/libclang.so.4.0 ../../../../lib/libLLVMSupport.a -lrt
-ldl -ltinfo -lpthread -lz -lm -lpthread -Wl,-rpath,"\$ORIGIN/../lib"
CMakeFiles/libclangTests.dir/LibclangTest.cpp.o: In function
`LibclangParseTest_AllSkippedRanges_Test::TestBody()':
/export/gnu/import/git/llvm/tools/clang/unittests/libclang/LibclangTest.cpp:441:
undefined reference to `clang_getAllSkippedRanges'
collect2: error: ld returned 1 exit status
tools/clang/unittests/libclang/CMakeFiles/libclangTests.dir/build.make:99:
recipe for target 'tools/clang/unittests/libclang/libclangTests'
failed
gmake[4]: *** [tools/clang/unittests/libclang/libclangTests] Error 1
gmake[4]: Leaving directory '/export/build/gnu/llvm-clang/build-x86_64-linux'
CMakeFiles/Makefile2:32037: recipe for target
'tools/clang/unittests/libclang/CMakeFiles/libclangTests.dir/all'
failed

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

[H.J Lu via cfe-commits]

hjl.tools added a comment.

In https://reviews.llvm.org/D22045#506996, @joerg wrote:

> For what it is worth, this certainly seems to be misnamed. By nature, if it 
> doesn't preserve at least the stack pointer, there is no way to recover on 
> return, right?


This is the best name we came up with and has been implemented in GCC.


https://reviews.llvm.org/D22045



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

[H.J Lu via cfe-commits]

hjl.tools added a comment.

no_caller_saved_registers attribute can be used with any calling conventions.


https://reviews.llvm.org/D22045



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 its subobjects (recursively)
 are of class, structure, union, or array type.
 ---

 excluded

 struct empty
 {
 empty () = default;
 };
>>>
>>>
>>> Why would that be excluded?  There are no subobjects, hence all of them
>>> are of class, structure, union or array type, hence this is an empty type.
>>> (And that's good, it indeed looks quite empty to me).  Even if you would
>>> add a non-trivial copy ctor, making this thing not trivially copyable
>>> anymore, it would still be empty.  Hence, given your proposed language in
>>> the psABI, without reference to any other ABI (in particular not to the
>>> Itanium C++ ABI), you would then need to pass it without registers.  That
>>> can't be done, and that's exactly why I find that wording incomplete.  It
>>> needs implicit references to other languages ABIs to work.
>>>
>>
>> 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 object of empty type that's
>> trivially copyable.
>> ---
>>
>> Any comments?
>
> Yes. "trivially copyable" is the wrong restriction. See
> http://mentorembedded.github.io/cxx-abi/abi.html#normal-call for the
> actual Itanium C++ ABI rule.

I looked it up.  " trivially copyable" is covered by C++ ABI.

> It's also completely nonsensical to mention this as a special case in
> relation to empty types. The special case applies to all function
> parameters, irrespective of whether they're empty -- this rule applies
> *long* before you consider whether the type is empty. For instance, in
> the x86-64 psABI, this should go right at the start of section 2.2.3
> ("Parameter Passing and Returning Values"). But please don't add it
> there -- it's completely redundant, as section 5.1 already says that
> the Itanium C++ ABI is used, so it's not necessary to duplicate rules
> from there.

Here is the final wording:

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.

Footnote: Array of empty type can only passed by reference in C and C++.

Michael, can you put it in x86-64 psABI?  I will update i386 and IA MCU
psABIs.

Thanks.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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
>> {
>> empty () = default;
>> };
>
>
> Why would that be excluded?  There are no subobjects, hence all of them
> are of class, structure, union or array type, hence this is an empty type.
> (And that's good, it indeed looks quite empty to me).  Even if you would
> add a non-trivial copy ctor, making this thing not trivially copyable
> anymore, it would still be empty.  Hence, given your proposed language in
> the psABI, without reference to any other ABI (in particular not to the
> Itanium C++ ABI), you would then need to pass it without registers.  That
> can't be done, and that's exactly why I find that wording incomplete.  It
> needs implicit references to other languages ABIs to work.
>

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 object of empty type that's
trivially copyable.
---

Any comments?


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 or return an object of empty type that's
>> > trivially copyable.
>> > ---
>> >
>> > (With possibly a self-sufficient definition of trivially copyable, that's
>> > language agnostic)
>> >
>>
>> Do you have an example in which an empty type defined above isn't
>> "trivially copyable"?
>
> The ones we've always talked about: empty C++ types with non-trivial copy
> ctors or dtors.  Yes, I'm aware of the fact that the Itanium C++ ABI
> doesn't invoke the underlying psABI for these types (or better, it
> specifies them to be passed by reference).  But first, there are other
> languages that have such constructs, but don't necessarily have an
> written-down ABI (OO fortran anyone? Ada?).  Second, there may be other
> C++ ABIs that don't contain such language (which would be an ommission,
> but well, happens).  And third even for our C++ needs (based on the
> Itanium ABI) I feel it's simply more clear and self-sufficient to be
> explicit about this restriction.
>
> It's not that we have any sort of upper bound on the number of words we're
> allowed to use in the psABI, and I also don't think anything is gained by
> being as terse as possible.  Succinct, sure, but not as arcane as we can
> make it while still being correct.
>
> So, question back: can you imaging any cases where the "restriction" to
> trivially copyable would _not_ do the thing we want?

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;
};

Adding "trivially copyable" extends, not limiting, the scope of
empty type.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 correct. Whether a type is trivially copyable is unrelated to
>> whether it is empty.
>
> I would still feel more comfortable to include the restriction to
> trivially copyable types, not in the part of definition of empty type, of
> course, but as part of the restrictions of when a type can be passed in no
> registers.  Basically to clarify the intent in the psABI if there's any
> doubt.  I.e. like so:
>
> ---
> 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.
> ---
>
> (With possibly a self-sufficient definition of trivially copyable, that's
> language agnostic)
>

Do you have an example in which an empty type defined above isn't
"trivially copyable"?

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 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
>> >> > the default constructor, in which case there's no function body).
>> >>
>> >> How about this?
>> >>
>> >> An empty type is a type where it and all of its subobjects
>> >> (recursively)
>> >> are of class, structure, union, or array type.  An empty type may only
>> >> have static member functions, default  constructor, default copy
>> >> constructor, default copy assignment operator or default destructor.
>> >
>> > No, that's the wrong rule still. Please leave the C++ rule here to the
>> > C++
>> > ABI rather than trying to reinvent it. Whether a type is empty is
>> > completely
>> > orthogonal to whether it must be passed through memory for C++ ABI /
>> > semantics reasons.
>>
>> What is the correct wording?  The last one:
>>
>> 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 whether
> it is empty.

Let get me what you were suggesting.  The x86 psABIs define the empty
type as

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.

Footnote: Array of empty type can only passed by reference in C and C++.

As for what other C++ types, which aren't empty type as defined by x86
psABIs, can be passed and returned without memory slot nor register
belong to C++ ABI.

Am I correct?

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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
>> >> 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
>> > the default constructor, in which case there's no function body).
>>
>> How about this?
>>
>> An empty type is a type where it and all of its subobjects (recursively)
>> are of class, structure, union, or array type.  An empty type may only
>> have static member functions, default  constructor, default copy
>> constructor, default copy assignment operator or default destructor.
>
> No, that's the wrong rule still. Please leave the C++ rule here to the C++
> ABI rather than trying to reinvent it. Whether a type is empty is completely
> orthogonal to whether it must be passed through memory for C++ ABI /
> semantics reasons.

What is the correct wording?  The last one:

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".

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 thread. It has no
> non-static data members, has standard layout, and has a trivial
> default constructor, but it has a non-trivial copy constructor and
> non-trivial destructor.
>

Can a compiler tell if a copy constructor or destructor is trivial
from the class declaration without function body?

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 [i];
>> }
>>
>> dummy0 *
>> bar (dummy d, int i)
>> {
>>   return d.foo (i);
>> }
>
> 1. This has undefined behaviour due to returning a pointer to a local variable
> 2. There's still no need for the reference to the original argument
> since copying it is a nop.

Given:

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.

Footnote: Array of empty type can only passed by reference in C and C++.

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?

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 type.  No
>>> >> memory slot nor register should be used to pass or return an object
>>> >> of empty type.
>>> >
>>> > 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, yes, but we don't want to define something for only C and C++, but
>> language independend (so far as possible).  And given only the above
>> language I think this type:
>>
>> struct S {
>>   S() {something();}
>> };
>>
>> would be an empty type, and that's not what we want.
>
> Yes it is. Did you mean to give S a copy constructor, copy assignment
> operator, or destructor instead?
>
>> "Trivially copyable"
>> is a reasonably common abstraction (if in doubt we could even define it in
>> the ABI), and captures the idea that we need well (namely that a bit-copy
>> is enough).

In this case:

struct dummy0
{
};

struct dummy
{
  dummy0 d[20];

  dummy0 * foo (int i);
};

dummy0 *
dummy::foo (int i)
{
  return [i];
}

dummy0 *
bar (dummy d, int i)
{
  return d.foo (i);
}

dummy shouldn't be passed as empty type.  We need to have a clear
definition for what kinds of member functions are allowed in an empty
type.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 object around. Its copy constructor is a nop and requires no
> reference to the original object.
>

Do you have a precise wording to describe it?

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 or return an object
>> >> of empty type.
>> >
>> > 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, yes, but we don't want to define something for only C and C++, but
> language independend (so far as possible).  And given only the above
> language I think this type:
>
> struct S {
>   S() {something();}
> };


Does "a type where it and all of its subobjects  (recursively) are of
class, structure, union, or array type." exclude the above?  If not,
we need better
wording.  We want to include static member functions and exclude
non-static member functions.

> would be an empty type, and that's not what we want.  "Trivially copyable"
> is a reasonably common abstraction (if in doubt we could even define it in
> the ABI), and captures the idea that we need well (namely that a bit-copy
> is enough).
>
>
> Ciao,
> Michael.



-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 should be used to pass or return an object of empty type.
>
> The trivially copyable is gone again.  Why is it not necessary?
>

I think we want to cover

struct
{
  unsigned int : 8;
};

but not

struct
{
  unsigned int  i :8;
};

" trivially copyable" applies to both.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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, 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, 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 function 
>> >> and
>> >> a variable in the namespace of A, which however do not have any
>> >> relevant impact here.)
>> >>
>> >
>> > Thanks for all the feedbacks.  Here is the new proposal:
>> >
>> > 1. "empty type".  An empty type is a trivially-copyable aggregate
>> > occupying zero bytes (excluding any padding).
>> > 2. No memory slot nor register should be used to pass or return an 
>> > object
>> > of empty type.
>> >
>> > Footnote: Array of empty type can only passed by reference in 
>> > C/C++.
>> >
>>
>> I updated intel386, x86-64 and IA MCU psABIs:
>>
>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>
>> to specify:
>>
>> Empty type is defined as a trivially-copyable aggregate occupying 
>> zero bytes
>> (excluding any padding).
>
> I think this is now extremely unclear. Does an empty struct in C++
> occupy zero bytes? sizeof applied to it will produce at least 1.

 Can it be considered as padding?
>>>
>>> Perhaps, but I would contend that that's unclear in at least some
>>> cases (when the class is used as the type of a member, ...). What
>>> about this case:
>>>
>>>   struct X { unsigned : 15; };
>>>
>>> Is that empty or not? Do we have a formal definition somewhere of what
>>> does, and does not, count as padding?
>>
>> How about this?
>>
>> Empty type is defined as a trivially-copyable aggregate occupying zero 
>> bytes
>> (excluding any padding or contributing zero bytes to the size of derived
>> classes in C++).
>>
>> This will cover
>>
>> struct dummy0
>> {
>>   void bar (void);
>> };
>> struct dummy1
>> {
>>   void foo (void);
>> };
>> struct dummy : dummy0, dummy1 { };
>>
>> But not
>>
>> struct dummy0
>> {
>> };
>> struct dummy1
>> {
>>   unsigned : 15;
>> };
>> struct dummy : dummy0, dummy1
>> {
>> };
>
> Why not? That looks empty to me. The ABI will classify the
> corresponding eightbyte as NO_CLASS, as it has no members, so it
> should not be passed.

 Do you have a wording to describe it?
>>>
>>> Yes, something like what you had before was fine:
>>>
>>>   "empty type". An empty type is a type where it and all of its
>>> subobjects (recursively) are of class, structure, union, or array
>>> type.
>>>
>>> Or, if you think it makes the intent clearer, reverse the sense:
>>>
>>>   A type is non-empty if it or any subobject (recursively) is of any
>>> type other than class, structure, union, or array type.
>>
>> Does the above cover
>>
>> struct dummy0
>> {
>>   void bar (void);
>> };
>> struct dummy1
>> {
>>   void foo (void);
>> };
>> struct dummy : dummy0, dummy1 { };
>
> Yes
>

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.

Footnote: Array of empty type can only passed by reference in C and C++.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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, 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 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.)
 >>
 >
 > Thanks for all the feedbacks.  Here is the new proposal:
 >
 > 1. "empty type".  An empty type is a trivially-copyable aggregate
 > occupying zero bytes (excluding any padding).
 > 2. No memory slot nor register should be used to pass or return an 
 > object
 > of empty type.
 >
 > Footnote: Array of empty type can only passed by reference in C/C++.
 >

 I updated intel386, x86-64 and IA MCU psABIs:

 https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

 to specify:

 Empty type is defined as a trivially-copyable aggregate occupying zero 
 bytes
 (excluding any padding).
>>>
>>> I think this is now extremely unclear. Does an empty struct in C++
>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>
>> Can it be considered as padding?
>
> Perhaps, but I would contend that that's unclear in at least some
> cases (when the class is used as the type of a member, ...). What
> about this case:
>
>   struct X { unsigned : 15; };
>
> Is that empty or not? Do we have a formal definition somewhere of what
> does, and does not, count as padding?

 How about this?

 Empty type is defined as a trivially-copyable aggregate occupying zero 
 bytes
 (excluding any padding or contributing zero bytes to the size of derived
 classes in C++).

 This will cover

 struct dummy0
 {
   void bar (void);
 };
 struct dummy1
 {
   void foo (void);
 };
 struct dummy : dummy0, dummy1 { };

 But not

 struct dummy0
 {
 };
 struct dummy1
 {
   unsigned : 15;
 };
 struct dummy : dummy0, dummy1
 {
 };
>>>
>>> Why not? That looks empty to me. The ABI will classify the
>>> corresponding eightbyte as NO_CLASS, as it has no members, so it
>>> should not be passed.
>>
>> Do you have a wording to describe it?
>
> Yes, something like what you had before was fine:
>
>   "empty type". An empty type is a type where it and all of its
> subobjects (recursively) are of class, structure, union, or array
> type.
>
> Or, if you think it makes the intent clearer, reverse the sense:
>
>   A type is non-empty if it or any subobject (recursively) is of any
> type other than class, structure, union, or array type.

Does the above cover

struct dummy0
{
  void bar (void);
};
struct dummy1
{
  void foo (void);
};
struct dummy : dummy0, dummy1 { };

> If you like, you could add notes that a parameter type is never an
> array type, and that unnamed bit-fields are not subobjects, but they
> seem redundant given the wording of the relevant standards. (You don't
> need to say anything about "POD for the purpose of layout", or
> destructors, or whatever else, because the C++ ABI only delegates to
> the C psABI for cases that are valid to pass in registers from a C++
> language semantics point of view.)



-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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, 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;
>> >>> };
>> >>
>> >> 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.)
>> >>
>> >
>> > Thanks for all the feedbacks.  Here is the new proposal:
>> >
>> > 1. "empty type".  An empty type is a trivially-copyable aggregate
>> > occupying zero bytes (excluding any padding).
>> > 2. No memory slot nor register should be used to pass or return an 
>> > object
>> > of empty type.
>> >
>> > Footnote: Array of empty type can only passed by reference in C/C++.
>> >
>>
>> I updated intel386, x86-64 and IA MCU psABIs:
>>
>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>
>> to specify:
>>
>> Empty type is defined as a trivially-copyable aggregate occupying zero 
>> bytes
>> (excluding any padding).
>
> I think this is now extremely unclear. Does an empty struct in C++
> occupy zero bytes? sizeof applied to it will produce at least 1.

 Can it be considered as padding?
>>>
>>> Perhaps, but I would contend that that's unclear in at least some
>>> cases (when the class is used as the type of a member, ...). What
>>> about this case:
>>>
>>>   struct X { unsigned : 15; };
>>>
>>> Is that empty or not? Do we have a formal definition somewhere of what
>>> does, and does not, count as padding?
>>
>> How about this?
>>
>> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
>> (excluding any padding or contributing zero bytes to the size of derived
>> classes in C++).
>>
>> This will cover
>>
>> struct dummy0
>> {
>>   void bar (void);
>> };
>> struct dummy1
>> {
>>   void foo (void);
>> };
>> struct dummy : dummy0, dummy1 { };
>>
>> But not
>>
>> struct dummy0
>> {
>> };
>> struct dummy1
>> {
>>   unsigned : 15;
>> };
>> struct dummy : dummy0, dummy1
>> {
>> };
>
> Why not? That looks empty to me. The ABI will classify the
> corresponding eightbyte as NO_CLASS, as it has no members, so it
> should not be passed.

Do you have a wording to describe it?


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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, 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 do not have any
 >> relevant impact here.)
 >>
 >
 > Thanks for all the feedbacks.  Here is the new proposal:
 >
 > 1. "empty type".  An empty type is a trivially-copyable aggregate
 > occupying zero bytes (excluding any padding).
 > 2. No memory slot nor register should be used to pass or return an object
 > of empty type.
 >
 > Footnote: Array of empty type can only passed by reference in C/C++.
 >

 I updated intel386, x86-64 and IA MCU psABIs:

 https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

 to specify:

 Empty type is defined as a trivially-copyable aggregate occupying zero 
 bytes
 (excluding any padding).
>>>
>>> I think this is now extremely unclear. Does an empty struct in C++
>>> occupy zero bytes? sizeof applied to it will produce at least 1.
>>
>> Can it be considered as padding?
>
> Perhaps, but I would contend that that's unclear in at least some
> cases (when the class is used as the type of a member, ...). What
> about this case:
>
>   struct X { unsigned : 15; };
>
> Is that empty or not? Do we have a formal definition somewhere of what
> does, and does not, count as padding?

How about this?

Empty type is defined as a trivially-copyable aggregate occupying zero bytes
(excluding any padding or contributing zero bytes to the size of derived
classes in C++).

This will cover

struct dummy0
{
  void bar (void);
};
struct dummy1
{
  void foo (void);
};
struct dummy : dummy0, dummy1 { };

But not

struct dummy0
{
};
struct dummy1
{
  unsigned : 15;
};
struct dummy : dummy0, dummy1
{
};


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 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.)
>> >>
>> >
>> > Thanks for all the feedbacks.  Here is the new proposal:
>> >
>> > 1. "empty type".  An empty type is a trivially-copyable aggregate
>> > occupying zero bytes (excluding any padding).
>> > 2. No memory slot nor register should be used to pass or return an object
>> > of empty type.
>> >
>> > Footnote: Array of empty type can only passed by reference in C/C++.
>> >
>>
>> I updated intel386, x86-64 and IA MCU psABIs:
>>
>> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI
>>
>> to specify:
>>
>> Empty type is defined as a trivially-copyable aggregate occupying zero bytes
>> (excluding any padding).
>
> I think this is now extremely unclear. Does an empty struct in C++
> occupy zero bytes? sizeof applied to it will produce at least 1.

Can it be considered as padding?

>> No memory slot nor register should be used to pass or
>> return an object object of empty type.
>>
>> with footnote: Array of empty type can only passed by reference in C and C++.
>>
>> Any comments?
>>
>> Thanks.
>>
>>
>> --
>> H.J.



-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 function and
>> a variable in the namespace of A, which however do not have any
>> relevant impact here.)
>>
>
> Thanks for all the feedbacks.  Here is the new proposal:
>
> 1. "empty type".  An empty type is a trivially-copyable aggregate
> occupying zero bytes (excluding any padding).
> 2. No memory slot nor register should be used to pass or return an object
> of empty type.
>
> Footnote: Array of empty type can only passed by reference in C/C++.
>

I updated intel386, x86-64 and IA MCU psABIs:

https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

to specify:

Empty type is defined as a trivially-copyable aggregate occupying zero bytes
(excluding any padding). No memory slot nor register should be used to pass or
return an object object of empty type.

with footnote: Array of empty type can only passed by reference in C and C++.

Any comments?

Thanks.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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
> denote a (or the) type with no values.  The closest thing C has would be
> an empty enum when using -fstrict-enums.  (Declaring it as return type
> implies [[noreturn]] or undefined behaviour.)
>
> A type with a unique value (such as void or an empty struct) is usually
> known as a unit type.
>
> BTW, being standard layout is not sufficient (nor required afaict) for
> zero-register passing of a unit type.  The requirement you need is
> trivially-copyable.  Example:
>
> #include 
> #include 
> #include 
>
> using namespace std;
>
> class EmptyInt {
> static map< const EmptyInt *, int > values;
>
> public:
> EmptyInt() = default;
> EmptyInt( int x ) {  values[this] = x;  }
> ~EmptyInt() {  values.erase(this);  }
>
> operator int () const {  return values[this];  }
> };
>
> typeof( EmptyInt::values ) EmptyInt::values;
>
> EmptyInt foo() {
> return 42;
> }
>
> int main() {
> cout << is_standard_layout{} << endl;
> cout << foo() << endl;
> return 0;
> }

My current proposal is

1. "class type".  A class type is a structure, union or C++ class.
2. "empty type".  An empty type is Plain Old Data (POD) for the
   purposes of layout, and.a type where it and all of its subobjects
   are of class or array type.

> This evil contraption satisfies all POD-requirements except for not
> being trivially-copyable.  On the other hand taking this example from
> http://en.cppreference.com/w/cpp/concept/StandardLayoutType
>
> struct Q {};
> struct S : Q {};
> struct T : Q {};
> struct U : S, T {}; // not a standard-layout class
>
> Even though U is not standard-layout, it is trivially-copyable and I see
> no reason to allocate a register to pass it.
>

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.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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".
>>
>> As Richard pointed out, it's defined in the C++ ABI.
>
> Which is C++y as well (and hence doesn't in itself solve the C/C++
> compatibility we should strive for in the ABI).  I'll concur with Matthijs
> and think that trivially copyable is the correct distinction for passing
> without registers (in addition of it being clearer than a strangly defined
> concept of "POD-but-not-quite-POD").  Do you think different?  Are there
> non-trivially copyable examples that we'd wish to pass without registers
> as well?
>
>

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

struct A { };
struct B { };
struct C : A, B { };

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 layout", and I can only
> interpret it as being equivalent to "standard-layout". The property of
> being trivially copyable/destructible is not a statement about layout
> and my EmptyInt example is POD in every other aspect.

"POD for the purpose of layout" is defined in the Itanium C++ ABI here:

http://mentorembedded.github.io/cxx-abi/abi.html#definitions


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 the C++ standard,
> which depend on C++ specific features.

Yes, I used this C++ ABI definition to make C++ and C equivalent in
empty type definition.

> This makes no sense to me.
>
> Note that triviality of copying/destruction holds for all C types and
> is easy to formulate in languages other than C++. (As is the notion of

Can you point out which C++ features for empty type with C counter parts
aren't covered by "POD for the purpose of layout"?

> an aggregate requiring no storage, other than padding. The whole
> argument about array parameters seems a bit silly since this is mere
> syntax sugar, C/C++ do not support passing an actual array by value.)
>
> Matthijs van Duin



-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
 wrote:
> H.J,
>
> I think we are fragmenting with too many standards and mailing lists. This
> new discussion group and eventually the resulting standards, all might be
> put under LSB http://refspecs.linuxfoundation.org/lsb.shtml
>
> The Intro on LSB says:
> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html
>
> And thats what this proposal is intended for.
>
> And we can use the LSB mailing list
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all
> discussions.
>
> What do you think?
>

LSB lists extensions which have been implemented.  But it isn't a spec
you can use to implement them.  For example:

http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html

lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO.
But it gives no details.  Linux ABI group is the place where we propose
extensions before they get implemented.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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
>> subobjects are of class or array type.
>>
>> Does it cover
>>
>> struct A { };
>> struct B { };
>> struct C : A, B { };
>
> I think this is covered by the above points.  But without further
> restriction I don't see how e.g. the above example with ctors and dtors
> would be ruled out (except if you regard a ctor as a sub-object).  For
> that you seem to need trivially-copyable, or that POD-ly thing.  So,
> perhaps simply amend (2) "... is a trivially copyable type where it ...".
>
>
> Ciao,
> Michael.

How about

struct A {
static void foo (void) ();
static int xxx;
};

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Thu, Feb 11, 2016 at 8:05 AM, Suprateeka R Hegde
 wrote:
> On 11-Feb-2016 07:21 PM, H.J. Lu wrote:
>>
>> On Thu, Feb 11, 2016 at 2:26 AM, Suprateeka R Hegde
>>  wrote:
>>>
>>> H.J,
>>>
>>> I think we are fragmenting with too many standards and mailing lists.
>>> This
>>> new discussion group and eventually the resulting standards, all might be
>>> put under LSB http://refspecs.linuxfoundation.org/lsb.shtml
>>>
>>> The Intro on LSB says:
>>>
>>> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/elfintro.html
>>>
>>> And thats what this proposal is intended for.
>>>
>>> And we can use the LSB mailing list
>>> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss for all
>>> discussions.
>>>
>>> What do you think?
>>>
>>
>> LSB lists extensions which have been implemented.  But it isn't a spec
>> you can use to implement them.  For example:
>>
>>
>> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/progheader.html
>>
>> lists PT_GNU_EH_FRAME, PT_GNU_STACK and PT_GNU_RELRO.
>> But it gives no details.  Linux ABI group is the place where we propose
>> extensions before they get implemented.
>
>
> How to implement, according to me, is design details of a particular
> product. It also depends on the language used to develop the product.
> Standards, in most cases, are not tied to a language and hence do not
> enforce implementation details.
>
>

That is exactly what Linux ABI group tries to address.  Please see
the Linux gABI extension draft at

https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI

It describes the conventions and constraints on the implementa-
tion of these extensions for interoperability between various tools.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 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, 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 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 purpose of standard-layout" was
> >> > unnecessary and just confused things.
> >>
> >> Here is the revised proposal:
> >>
> >> 1. "class type".  A class type is a structure, union or C++ class.
> >> 2. "empty class type".  An empty class type is:
> >>a. A class type without member.  Or
> >>b. A class type with only members of empty class types.  Or
> >
> >
> > (a) is a special case of (b).
> >
> >>c. An array of empty class types.
> >
> >
> > It seems confusing to call an array a class type. Instead, how 
> > about:
> >
> >   2. An empty type is either an array of empty types or a class 
> > type where
> > every member is of empty type.
> >
> >> 3. "empty record".  An empty record is Plain Old Data (POD) for the
> >>purposes of layout and
> >>a. A class type without member.  Or
> >>b. A class type with only members of empty class types.
> >
> >
> > (a) is a special case of (b).
> >
> >> 4. No memory slot nor register should be used to pass or return an 
> >> object
> >> of empty record.
> >
> >
> > Objects of array type are never passed or returned (but if through 
> > some
> > language extension they were, we'd want this rule to apply). So you 
> > don't
> > need rule 3 and this can be just:
> >
> >  3. No memory slot nor register should be used to pass or return an 
> > object
> > of empty type.
>
> Thanks very much for your inputs.  Here is the proposal:
>
> 1. "class type".  A class type is a structure, union or C++ class.
> 2. "empty type".  An empty type is either an array of empty types or a
> class type where every member is of empty type.
> 3. No memory slot nor register should be used to pass or return an 
> object
> of empty type.

 David Majnemer points out that we also need to say something about
 base classes. We could handle that case like this:

  2. "empty type".  An empty type is a type where it and all of its
 subobjects are of class or array type.

 Following the C++ rules, this also means that a class that contains
 only unnamed bitfields is empty, because unnamed bitfields are not
 subobjects, but might be worth explicitly stating for the C case. That
 also matches Clang's behavior.
>>>
>>> Like this?
>>>
>>> 1. "class type".  A class type is a structure, union or C++ class.
>>> 2. "empty type".  An empty type is
>>>a. A type where it and all of its subobjects are of class or array
>>>type. And
>>>b. Either an array of empty types or a class type where every member
>>>is of empty type.
>>
>> You don't need (b). It's implied by (a).
>
> Does (a) cover empty type?

 Yes, (a) is a complete definition of "empty type" by itself: the
 definition is, essentially, that a complete recursive walk of the type
 and all its subobjects never sees anything that would require any
 storage (that is, it only sees class types and array types).
>>>
>>> Is there a definition of subobject?
>>
>> Yes, the C++ standard defines the term (as an 

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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?
>
> An empty structure, such as struct A.
>
> One of the requirements for standard-layout classes is "has all
> non-static data members and bit-fields in the class and its base
> classes first declared in the same class" so standard layout classes
> are allowed to have base classes, as long as either the base class is
> empty (so doesn't alter layout) or the derived class doesn't add
> members (so has the same layout as the base). If neither the base
> class is an empty record, and the derived class doesn't add any
> non-static data members or bit-fields, then the base class should be
> an empty record too.

if it is the case

struct A { };
struct B { };
struct C : A, B { };

is an empty record.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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
>>
>> Here is the updated proposal for  Intel386, x86-64 and IA MCU psABIs:
>>
>> 1. "collection".  A collection is a structure, union or C++ class.
>
> These are all "class types". Why invent a new term?

Because it applies to both C and C++.  There is no class in C.

>> 2. "empty collection".  An empty collection is:
>>a. A collection without member.  Or
>
> What about base classes?
>
> What about bit-fields of length 0?

Is a collection with them standard-layout POD type?

>>b. A collection with only empty collections.  Or
>
> What does "with" mean? Only members, or bases too?

Is "A collection with only members of empty collections" better?

>>c. An array of empty collections.
>> 3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
>>of standard-layout and
>
> "For the purposes of standard-layout" doesn't mean anything.
>
> 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 ..."?

> Do you mean "An empty record is a standard-layout type and..."
>
>>a. A collection without member.  Or
>>b. A collection with only empty collections.
>
> ?
>

Is "A collection with only members of empty collections" better?

>
>> 4. No memory slot nor register should be used to pass or return an object of
>> empty record.



-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 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 psABIs:

 1. "collection".  A collection is a structure, union or C++ class.
>>>
>>> These are all "class types". Why invent a new term?
>>
>> Because it applies to both C and C++.  There is no class in C.
>
> Then you could use the term "class type" in the ABI, defining it to
> mean structure or union in C, or class type in C++. No need for a new
> term.

I will do it.

>
 2. "empty collection".  An empty collection is:
a. A collection without member.  Or
>>>
>>> What about base classes?
>>>
>>> What about bit-fields of length 0?
>>
>> Is a collection with them standard-layout POD type?
>
> (I'm not sure what the "bit-fields of length 0" part is for, but my
> point is it would be useful to examine similar concepts in the
> standard and align with them, not just make up entirely new
> classifications.)

I am replying on C++ compiler to tell if it is standard-layout
or not.

> For base classes, yes. A standard-layout class can have base classes
> of standard-layout type.
>
> struct A { };
> struct B { };
> struct C : A, B { };
>
> C is a standard-layout type. Is it an empty collection?

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?

b. A collection with only empty collections.  Or
>>>
>>> What does "with" mean? Only members, or bases too?
>>
>> Is "A collection with only members of empty collections" better?
>
> Should it mention base classes?

It depends on the answer of my question above.

>
c. An array of empty collections.
 3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
of standard-layout and
>>>
>>> "For the purposes of standard-layout" doesn't mean anything.
>>>
>>> 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.
>

I will update it.

Thanks.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 3:08 PM, Joseph Myers  wrote:
> On Mon, 8 Feb 2016, H.J. Lu wrote:
>
>> >> I was referring to program properties:
>> >>
>> >> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>> >
>> > This looks more like an ELF topic to me, not really ABI.
>> >
>> > Please discuss this on a GNU project list because it affects the
>> > entire GNU project.
>> >
>>
>> gABI is ELF and affects all users, including GNU project, of gABI.
>> Linux-abi discusses Linux-specific extensions to gABI. It is for tools
>> like compilers, assembler, linker and run-time.  It isn't appropriate
>> for any GNU project list.
>
> I find it extremely unlikely that many well-thought-out extensions would
> be appropriate for GNU systems using the Linux kernel but not for GNU
> systems using Hurd or other kernels - the only such cases would be for
> things very closely related to kernel functionality.  There is a strong
> presumption that toolchain configuration should apply to all GNU systems
> rather than being specific to GNU/Linux without good reason.
>

Most of extensions aren't Linux kernel specific.  But some extensions
will require kernel support to function properly.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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   emptyempty
 s4   emptyempty
 s5   non-emptyempty

 I believe s3, s4, s5 are non-empty according to your rules.  Why put
 both compilers in the wrong?  That doesn't make sense to me.
>>>
>>> Please try testcases in
>>>
>>> https://llvm.org/bugs/show_bug.cgi?id=26337
>>>
>>> with clang on both ia32 and x86-64.  Clang isn't consistent between
>>> ia32 and x86-64.
>>
>> Okay, with -m32, I get non-empty passing for s5 from Clang as well.
>> But I still don't think it makes sense to change the ABI for s3 and
>> s4, and even for s5, the Clang/x86_64 behavior is arguably more
>> correct.
>
> Not really.  For
>
> struct dummy0 { };
> struct dummy { struct dummy0 d[PAD_SIZE]; };
>
> clang changes behavior when PAD_SIZE > 16 on x86-64 and PAD_SIZE > 1
> on ia32.
>
 Jason already indicated he intends GCC to move towards more empty
 arguments, not fewer.

>> How do existing C++ compilers implement empty array members (an
>> extension)?  Does the type of such members affect whether a class is a
>> standard-layout class?

> Are they "POD for the purpose of layout"? If yes, they are covered here.

 The C++ standard does not define this.
>>>
>>> GCC has
>>>
>>> * Nonzero means that this class type is not POD for the purpose of layout
>>>(as defined in the ABI).  This is different from the language's POD.  */
>>> #define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
>>>
>>> We can use this definition for ia32, x86-64 and IA MCU psABIs.
>>
>> It still has to be spelled out in non-GCC terms, IMHO.
>
> Sure.  Do you care to propose a wording for "POD for the purpose of layout"?
>

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 psABIs:

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 collection with only empty collections.  Or
   c. An array of empty collections.
3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
   of standard-layout and
   a. A collection without member.  Or
   b. A collection with only empty collections.
4. No memory slot nor register should be used to pass or return an object of
empty record.



-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 types are POD types.  GCC has

/* Nonzero means that this class type is not POD for the purpose of layout
   (as defined in the ABI).  This is different from the language's POD.  */
CLASSTYPE_NON_LAYOUT_POD_P

and

/* Nonzero means that this class type is a non-standard-layout class.  */
#define CLASSTYPE_NON_STD_LAYOUT

They aren't the same.

struct A { };
struct B { };
struct C : A, B { };

C is a standard-layout type, but not a standard-layout POD type.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 "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 types are POD types.  GCC has
>>>
>>> /* Nonzero means that this class type is not POD for the purpose of layout
>>>(as defined in the ABI).  This is different from the language's POD.  */
>>> CLASSTYPE_NON_LAYOUT_POD_P
>>>
>>> and
>>>
>>> /* Nonzero means that this class type is a non-standard-layout class.  */
>>> #define CLASSTYPE_NON_STD_LAYOUT
>>>
>>> They aren't the same.
>>>
>>> struct A { };
>>> struct B { };
>>> struct C : A, B { };
>>>
>>> C is a standard-layout type, but not a standard-layout POD type.
>>
>> As the comment says, "POD for the purposes of layout" is different
>> from the language's POD. All standard-layout types are POD types
>> according to the language.
>>
>> So when you previously had "POD for the purposes of layout" that was
>> at least partially clear that you meant something other than what the
>> language means. But as pointed out, using a GCC-specific term is not
>> ideal.
>>
>> When you changed it to "POD for the purpose of standard-layout" that
>> became a completely meaningless term. Where is that defined?
>>
>> Your next suggestion was "standard-layout Plain Old Data (POD)" which
>> is even worse, now you're using two terms defined by the C++ language,
>> but you mean something different.
>>
>> When you mean something that is the same as the language (like "class
>> type") it makes sense to use the same term.
>>
>> When you mean something that is not the same as the language (like
>> "POD") it makes sense to use a different term, or clearly define how
>> you are using it.
>
> To be clear: it's really confusing to take two terms defined by the
> language, "POD" and "standard-layout", and smash them together to mean
> something new.
>
> According to your proposal, struct C is a POD type, and  a
> standard-layout type, but not a "standard-layout POD type". That's
> just crazy.

Can you suggest a better wording?

Another issue, if I define

1. "class type".  A class type is a structure, union or C++ class.
2. "empty class type".  An empty class type is:
   a. A class type without member.  Or
   b. A class type with only members of empty class types.  Or
   c. An array of empty class types.
^

Will it confuse people?


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 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 types are POD types.  GCC has
>
> /* Nonzero means that this class type is not POD for the purpose of layout
>(as defined in the ABI).  This is different from the language's POD.  
> */
> CLASSTYPE_NON_LAYOUT_POD_P
>
> and
>
> /* Nonzero means that this class type is a non-standard-layout class.  */
> #define CLASSTYPE_NON_STD_LAYOUT
>
> They aren't the same.
>
> struct A { };
> struct B { };
> struct C : A, B { };
>
> C is a standard-layout type, but not a standard-layout POD type.

 As the comment says, "POD for the purposes of layout" is different
 from the language's POD. All standard-layout types are POD types
 according to the language.

 So when you previously had "POD for the purposes of layout" that was
 at least partially clear that you meant something other than what the
 language means. But as pointed out, using a GCC-specific term is not
 ideal.

 When you changed it to "POD for the purpose of standard-layout" that
 became a completely meaningless term. Where is that defined?

 Your next suggestion was "standard-layout Plain Old Data (POD)" which
 is even worse, now you're using two terms defined by the C++ language,
 but you mean something different.

 When you mean something that is the same as the language (like "class
 type") it makes sense to use the same term.

 When you mean something that is not the same as the language (like
 "POD") it makes sense to use a different term, or clearly define how
 you are using it.
>>>
>>> To be clear: it's really confusing to take two terms defined by the
>>> language, "POD" and "standard-layout", and smash them together to mean
>>> something new.
>>>
>>> According to your proposal, struct C is a POD type, and  a
>>> standard-layout type, but not a "standard-layout POD type". That's
>>> just crazy.
>>
>> Can you suggest a better wording?
>
> I don't know what the definition of "POD for the purposes of layout"
> is, but if I was trying to define a better name for it I would start
> by trying to understand how it is specified, instead of just throwing
> existing terms together.
>
>
>> Another issue, if I define
>>
>> 1. "class type".  A class type is a structure, union or C++ class.
>> 2. "empty class type".  An empty class type is:
>>a. A class type without member.  Or
>>b. A class type with only members of empty class types.  Or
>>c. An array of empty class types.
>> ^
>>
>> Will it confuse people?
>
> Yes :-)
>
> But that was already confusing when you called it an "empty
> collection" because an array isn't a collection.
>
> If I understand correctly, your proposal says that given:
>
> struct A { };  // empty class type
> typedef A A2[2];  // array of empty class types
>
> struct B { A a[2]; };  // empty record?
>
> struct B is an empty record ... is that right?

Yes, struct B is an empty record.   And also in

struct A { };
struct B { };
struct C : A, B { };

C isn't an empty record.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 for the purposes of layout",
> and the change to "POD for the purpose of standard-layout" was
> unnecessary and just confused things.

Here is the revised proposal:

1. "class type".  A class type is a structure, union or C++ class.
2. "empty class type".  An empty class type is:
   a. A class type without member.  Or
   b. A class type with only members of empty class types.  Or
   c. An array of empty class types.
3. "empty record".  An empty record is Plain Old Data (POD) for the
   purposes of layout and
   a. A class type without member.  Or
   b. A class type with only members of empty class types.
4. No memory slot nor register should be used to pass or return an object
of empty record.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 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 purpose of standard-layout" was
>> > unnecessary and just confused things.
>>
>> Here is the revised proposal:
>>
>> 1. "class type".  A class type is a structure, union or C++ class.
>> 2. "empty class type".  An empty class type is:
>>a. A class type without member.  Or
>>b. A class type with only members of empty class types.  Or
>
>
> (a) is a special case of (b).
>
>>c. An array of empty class types.
>
>
> It seems confusing to call an array a class type. Instead, how about:
>
>   2. An empty type is either an array of empty types or a class type where
> every member is of empty type.
>
>> 3. "empty record".  An empty record is Plain Old Data (POD) for the
>>purposes of layout and
>>a. A class type without member.  Or
>>b. A class type with only members of empty class types.
>
>
> (a) is a special case of (b).
>
>> 4. No memory slot nor register should be used to pass or return an object
>> of empty record.
>
>
> Objects of array type are never passed or returned (but if through some
> language extension they were, we'd want this rule to apply). So you don't
> need rule 3 and this can be just:
>
>  3. No memory slot nor register should be used to pass or return an object
> of empty type.

Thanks very much for your inputs.  Here is the proposal:

1. "class type".  A class type is a structure, union or C++ class.
2. "empty type".  An empty type is either an array of empty types or a
class type where every member is of empty type.
3. No memory slot nor register should be used to pass or return an object
of empty type.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer  wrote:
> * H. J. Lu:
>
>> I created a mailing list to discuss Linux specific,.processor independent
>> modification and extension of generic System V Application Binary Interface:
>>
>> https://groups.google.com/d/forum/linux-abi
>>
>> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
>> I will propose some new extensions soon.
>
> Why can't you use the existing C++ ABI list?  Is there no overlap at
> all?
>
:
I wasn't referring to empty class

https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html

I was referring to program properties:

https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Linux-abi group

[H.J. Lu via cfe-commits]

Hi,

I created a mailing list to discuss Linux specific,.processor independent
modification and extension of generic System V Application Binary Interface:

https://groups.google.com/d/forum/linux-abi

I will start to document existing Linux extensions, like STT_GNU_IFUNC.
I will propose some new extensions soon.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 11:33 AM, Szabolcs Nagy  wrote:
> * H.J. Lu  [2016-02-08 11:24:53 -0800]:
>> I created a mailing list to discuss Linux specific,.processor independent
>> modification and extension of generic System V Application Binary Interface:
>>
>> https://groups.google.com/d/forum/linux-abi
>>
>> I will start to document existing Linux extensions, like STT_GNU_IFUNC.
>> I will propose some new extensions soon.
>>
>
> seems to require a registered email address at google.
> (and the archive does not work from any console based browser
> or using direct http get tools.)

Do you want me to add you?

> the kernel seems to have a lot of mailing lists, may be
> they can handle this list too?
>
> thanks

It is used to discuss more tool-oriented extensions than
the kernel-oriented ones, like STT_GNU_IFUNC which
has nothing to do with kernel.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Linux-abi group

[H.J. Lu via cfe-commits]

On Mon, Feb 8, 2016 at 11:44 AM, Florian Weimer  wrote:
> * H. J. Lu:
>
>> On Mon, Feb 8, 2016 at 11:32 AM, Florian Weimer  wrote:
>>> * H. J. Lu:
>>>
 I created a mailing list to discuss Linux specific,.processor independent
 modification and extension of generic System V Application Binary 
 Interface:

 https://groups.google.com/d/forum/linux-abi

 I will start to document existing Linux extensions, like STT_GNU_IFUNC.
 I will propose some new extensions soon.
>>>
>>> Why can't you use the existing C++ ABI list?  Is there no overlap at
>>> all?
>>>
>> :
>> I wasn't referring to empty class
>>
>> https://gcc.gnu.org/ml/gcc/2016-02/msg00057.html
>
> But still there is going to be some overlap?

I was told that it didn't belong to C++ ABI.  Please free feel to
raise the this issue with C++ ABI group.

>> I was referring to program properties:
>>
>> https://groups.google.com/forum/#!topic/generic-abi/fyIXttIsYc8
>
> This looks more like an ELF topic to me, not really ABI.
>
> Please discuss this on a GNU project list because it affects the
> entire GNU project.
>

gABI is ELF and affects all users, including GNU project, of gABI.
Linux-abi discusses Linux-specific extensions to gABI. It is for tools
like compilers, assembler, linker and run-time.  It isn't appropriate
for any GNU project list.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 is not passed. So the
> proposed change would only affect the behavior of types larger than 16
> bytes that contain no data. It doesn't seem worth breaking ABI to more
> efficiently pass those.
>

Clang isn't consistent between ia32 and x86-64.  GCC isn't compatible
with clang.  My proposal will make GCC and clang compatible.  It also
makes GCC and clang behave the same on both ia32 and x86-64.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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, 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 
 >> >> 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 purpose of standard-layout" was
 >> > unnecessary and just confused things.
 >>
 >> Here is the revised proposal:
 >>
 >> 1. "class type".  A class type is a structure, union or C++ class.
 >> 2. "empty class type".  An empty class type is:
 >>a. A class type without member.  Or
 >>b. A class type with only members of empty class types.  Or
 >
 >
 > (a) is a special case of (b).
 >
 >>c. An array of empty class types.
 >
 >
 > It seems confusing to call an array a class type. Instead, how about:
 >
 >   2. An empty type is either an array of empty types or a class type 
 > where
 > every member is of empty type.
 >
 >> 3. "empty record".  An empty record is Plain Old Data (POD) for the
 >>purposes of layout and
 >>a. A class type without member.  Or
 >>b. A class type with only members of empty class types.
 >
 >
 > (a) is a special case of (b).
 >
 >> 4. No memory slot nor register should be used to pass or return an 
 >> object
 >> of empty record.
 >
 >
 > Objects of array type are never passed or returned (but if through some
 > language extension they were, we'd want this rule to apply). So you don't
 > need rule 3 and this can be just:
 >
 >  3. No memory slot nor register should be used to pass or return an 
 > object
 > of empty type.

 Thanks very much for your inputs.  Here is the proposal:

 1. "class type".  A class type is a structure, union or C++ class.
 2. "empty type".  An empty type is either an array of empty types or a
 class type where every member is of empty type.
 3. No memory slot nor register should be used to pass or return an object
 of empty type.
>>>
>>> David Majnemer points out that we also need to say something about
>>> base classes. We could handle that case like this:
>>>
>>>  2. "empty type".  An empty type is a type where it and all of its
>>> subobjects are of class or array type.
>>>
>>> Following the C++ rules, this also means that a class that contains
>>> only unnamed bitfields is empty, because unnamed bitfields are not
>>> subobjects, but might be worth explicitly stating for the C case. That
>>> also matches Clang's behavior.
>>
>> Like this?
>>
>> 1. "class type".  A class type is a structure, union or C++ class.
>> 2. "empty type".  An empty type is
>>a. A type where it and all of its subobjects are of class or array
>>type. And
>>b. Either an array of empty types or a class type where every member
>>is of empty type.
>
> You don't need (b). It's implied by (a).

Does (a) cover empty type?

>> 3. No memory slot nor register should be used to pass or return an object
>> of empty type.
>>
>>
>> --
>> H.J.



-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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:
>> >> > 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 purpose of standard-layout" was
>> >> > unnecessary and just confused things.
>> >>
>> >> Here is the revised proposal:
>> >>
>> >> 1. "class type".  A class type is a structure, union or C++ class.
>> >> 2. "empty class type".  An empty class type is:
>> >>a. A class type without member.  Or
>> >>b. A class type with only members of empty class types.  Or
>> >
>> >
>> > (a) is a special case of (b).
>> >
>> >>c. An array of empty class types.
>> >
>> >
>> > It seems confusing to call an array a class type. Instead, how about:
>> >
>> >   2. An empty type is either an array of empty types or a class type where
>> > every member is of empty type.
>> >
>> >> 3. "empty record".  An empty record is Plain Old Data (POD) for the
>> >>purposes of layout and
>> >>a. A class type without member.  Or
>> >>b. A class type with only members of empty class types.
>> >
>> >
>> > (a) is a special case of (b).
>> >
>> >> 4. No memory slot nor register should be used to pass or return an object
>> >> of empty record.
>> >
>> >
>> > Objects of array type are never passed or returned (but if through some
>> > language extension they were, we'd want this rule to apply). So you don't
>> > need rule 3 and this can be just:
>> >
>> >  3. No memory slot nor register should be used to pass or return an object
>> > of empty type.
>>
>> Thanks very much for your inputs.  Here is the proposal:
>>
>> 1. "class type".  A class type is a structure, union or C++ class.
>> 2. "empty type".  An empty type is either an array of empty types or a
>> class type where every member is of empty type.
>> 3. No memory slot nor register should be used to pass or return an object
>> of empty type.
>
> David Majnemer points out that we also need to say something about
> base classes. We could handle that case like this:
>
>  2. "empty type".  An empty type is a type where it and all of its
> subobjects are of class or array type.
>
> Following the C++ rules, this also means that a class that contains
> only unnamed bitfields is empty, because unnamed bitfields are not
> subobjects, but might be worth explicitly stating for the C case. That
> also matches Clang's behavior.

Like this?

1. "class type".  A class type is a structure, union or C++ class.
2. "empty type".  An empty type is
   a. A type where it and all of its subobjects are of class or array
   type. And
   b. Either an array of empty types or a class type where every member
   is of empty type.
3. No memory slot nor register should be used to pass or return an object
of empty type.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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, 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:
>> >> >> "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 purpose of standard-layout" was
>> >> > unnecessary and just confused things.
>> >>
>> >> Here is the revised proposal:
>> >>
>> >> 1. "class type".  A class type is a structure, union or C++ class.
>> >> 2. "empty class type".  An empty class type is:
>> >>a. A class type without member.  Or
>> >>b. A class type with only members of empty class types.  Or
>> >
>> >
>> > (a) is a special case of (b).
>> >
>> >>c. An array of empty class types.
>> >
>> >
>> > It seems confusing to call an array a class type. Instead, how about:
>> >
>> >   2. An empty type is either an array of empty types or a class type 
>> > where
>> > every member is of empty type.
>> >
>> >> 3. "empty record".  An empty record is Plain Old Data (POD) for the
>> >>purposes of layout and
>> >>a. A class type without member.  Or
>> >>b. A class type with only members of empty class types.
>> >
>> >
>> > (a) is a special case of (b).
>> >
>> >> 4. No memory slot nor register should be used to pass or return an 
>> >> object
>> >> of empty record.
>> >
>> >
>> > Objects of array type are never passed or returned (but if through some
>> > language extension they were, we'd want this rule to apply). So you 
>> > don't
>> > need rule 3 and this can be just:
>> >
>> >  3. No memory slot nor register should be used to pass or return an 
>> > object
>> > of empty type.
>>
>> Thanks very much for your inputs.  Here is the proposal:
>>
>> 1. "class type".  A class type is a structure, union or C++ class.
>> 2. "empty type".  An empty type is either an array of empty types or a
>> class type where every member is of empty type.
>> 3. No memory slot nor register should be used to pass or return an object
>> of empty type.
>
> David Majnemer points out that we also need to say something about
> base classes. We could handle that case like this:
>
>  2. "empty type".  An empty type is a type where it and all of its
> subobjects are of class or array type.
>
> Following the C++ rules, this also means that a class that contains
> only unnamed bitfields is empty, because unnamed bitfields are not
> subobjects, but might be worth explicitly stating for the C case. That
> also matches Clang's behavior.

 Like this?

 1. "class type".  A class type is a structure, union or C++ class.
 2. "empty type".  An empty type is
a. A type where it and all of its subobjects are of class or array
type. And
b. Either an array of empty types or a class type where every member
is of empty type.
>>>
>>> You don't need (b). It's implied by (a).
>>
>> Does (a) cover empty type?
>
> Yes, (a) is a complete definition of "empty type" by itself: the
> definition is, essentially, that a complete recursive walk of the type
> and all its subobjects never sees anything that would require any
> storage (that is, it only sees class types and array types).

Is there a definition of subobject?

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 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 behavior of types larger than 16
>>> bytes that contain no data. It doesn't seem worth breaking ABI to more
>>> efficiently pass those.
>>>
>>
>> Clang isn't consistent between ia32 and x86-64.  GCC isn't compatible
>> with clang.  My proposal will make GCC and clang compatible.  It also
>> makes GCC and clang behave the same on both ia32 and x86-64.
>
> OK, but if the ABI is already saying what we want, and the only
> problem is that GCC and Clang don't conform to the ABI in some cases,
> then we just need to fix the compilers and not the ABI. Which cases do
> we think the existing ABI rule misclassifies?

I want to make it explicit in psABIs to avoid any possible
confusion and x86-64 classification rules don't apply to ia32.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

Empty struct value is passed differently in C and C++ on Intel386 and x86-64.
Different compilers use different calling conventions on the same platform:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336

The same compiler behaves different on different platforms:

https://llvm.org/bugs/show_bug.cgi?id=26337

In some case, empty struct can't be passed in C++ at all:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336

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 collection with only empty collections.  Or
   c. An array of empty collections.
3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
   of layout and
   a. A collection without member.  Or
   b. A collection with only empty collections.
4. No memory slot nor register should be used to pass or return an object of
empty collection.

The proposed Intel386, x86-64 and IA MCU psABIs are at

https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

Any comments?

Thanks.

-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 or C++ class.
>>> 2. "empty collection".  An empty collection is:
>>>a. A collection without member.  Or
>>>b. A collection with only empty collections.  Or
>>>c. An array of empty collections.
>>> 3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
>>>of layout and
>>>a. A collection without member.  Or
>>>b. A collection with only empty collections.
>>> 4. No memory slot nor register should be used to pass or return an object of
>>> empty collection.
>>
>> “Aggregate” may be the more standard term instead of collection.
>
> Aggregate also include array, which is excluded here.
>
>> I think you mean “empty record” under 4.
>
> Yes. I will fix it.

This typo isn't in the proposed x86 psABIs:

https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

which has "No memory slot nor register should be used to pass or return an
object of empty record."



H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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-data members do not count.
>>
>> They do count here.  That is why I used "POD for the purpose of
>> layout.
>
> Let's see what happens today.
>
> struct s0 {
>   s0();
> };
>
> struct s1 {
>   static int a;
> };
>
> struct s2 {
>   void member();
> };
>
> struct s3 {
>   int a[0];
> };
>
> struct s4 {
>   s0 a[0];
> };
>
> struct s5 {
>   s1 a[1];
> };
>
>
> 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 to your rules.  Why put
> both compilers in the wrong?  That doesn't make sense to me.

Please try testcases in

https://llvm.org/bugs/show_bug.cgi?id=26337

with clang on both ia32 and x86-64.  Clang isn't consistent between
ia32 and x86-64.

> Jason already indicated he intends GCC to move towards more empty
> arguments, not fewer.
>
>>> How do existing C++ compilers implement empty array members (an
>>> extension)?  Does the type of such members affect whether a class is a
>>> standard-layout class?
>
>> Are they "POD for the purpose of layout"? If yes, they are covered here.
>
> The C++ standard does not define this.

GCC has

* Nonzero means that this class type is not POD for the purpose of layout
   (as defined in the ABI).  This is different from the language's POD.  */
#define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \

We can use this definition for ia32, x86-64 and IA MCU psABIs.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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   non-emptyempty
>>>
>>> I believe s3, s4, s5 are non-empty according to your rules.  Why put
>>> both compilers in the wrong?  That doesn't make sense to me.
>>
>> Please try testcases in
>>
>> https://llvm.org/bugs/show_bug.cgi?id=26337
>>
>> with clang on both ia32 and x86-64.  Clang isn't consistent between
>> ia32 and x86-64.
>
> Okay, with -m32, I get non-empty passing for s5 from Clang as well.
> But I still don't think it makes sense to change the ABI for s3 and
> s4, and even for s5, the Clang/x86_64 behavior is arguably more
> correct.

Not really.  For

struct dummy0 { };
struct dummy { struct dummy0 d[PAD_SIZE]; };

clang changes behavior when PAD_SIZE > 16 on x86-64 and PAD_SIZE > 1
on ia32.

>>> Jason already indicated he intends GCC to move towards more empty
>>> arguments, not fewer.
>>>
> How do existing C++ compilers implement empty array members (an
> extension)?  Does the type of such members affect whether a class is a
> standard-layout class?
>>>
 Are they "POD for the purpose of layout"? If yes, they are covered here.
>>>
>>> The C++ standard does not define this.
>>
>> GCC has
>>
>> * Nonzero means that this class type is not POD for the purpose of layout
>>(as defined in the ABI).  This is different from the language's POD.  */
>> #define CLASSTYPE_NON_LAYOUT_POD_P(NODE) \
>>
>> We can use this definition for ia32, x86-64 and IA MCU psABIs.
>
> It still has to be spelled out in non-GCC terms, IMHO.

Sure.  Do you care to propose a wording for "POD for the purpose of layout"?


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu via cfe-commits]

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 collection is:
>>a. A collection without member.  Or
>>b. A collection with only empty collections.  Or
>>c. An array of empty collections.
>> 3. "empty record".  An empty record is Plain Old Data (POD) for the purpose
>>of layout and
>>a. A collection without member.  Or
>>b. A collection with only empty collections.
>> 4. No memory slot nor register should be used to pass or return an object of
>> empty collection.
>
> “Aggregate” may be the more standard term instead of collection.

Aggregate also include array, which is excluded here.

> I think you mean “empty record” under 4.

Yes. I will fix it.

> 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 used "POD for the purpose of
layout.

> Does the definition of POD vary between C++ standards?  Then the
> calling convention would vary as well, which is probably not what we
> want.

I believe that POD for the purpose of layout doesn't change between
C++ standards.

> How do existing C++ compilers implement empty array members (an
> extension)?  Does the type of such members affect whether a class is a
> standard-layout class?
>
> Florian

Are they "POD for the purpose of layout"? If yes, they are covered here.


-- 
H.J.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union

[H.J Lu via cfe-commits]

hjl.tools added a comment.

I am planning to update i386, x86-64 and IA MCU psABIs to address how to
pass and return C++ empty class after resolving:

https://llvm.org/bugs/show_bug.cgi?id=26337

by updating C++ ABI to explicitly pass and return C++ empty class like C empty
structure.


http://reviews.llvm.org/D16808



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union

[H.J Lu via cfe-commits]

hjl.tools added a subscriber: hjl.tools.
hjl.tools added a comment.

Why should empty structs and unions) be return in memory? I don't remember
I called for it in MCU psABI.


http://reviews.llvm.org/D16808



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D16779: Fix attribute((mode([word|unwind_word]))) for x32

[H.J Lu via cfe-commits]

hjl.tools created this revision.
hjl.tools added reviewers: rnk, rafael.
hjl.tools added a subscriber: cfe-commits.

```
typedef unsigned int gcc_word __attribute__((mode(word)));
```
and

```
typedef unsigned int gcc_unwind_word __attribute__((mode(unwind_word)));
```
define the largest unsigned integer types which can be stored in a
general purpose register, which may not be the pointer type.  For x32,
they aren't pointer nor unsigned long.  We should

1. Make getUnwindWordWidth and getRegisterWidth virtual,
2. Override them for x32, similar to hasInt128Type.
3. Use getRegisterWidth for __attribute__((mode(word)));

This fixes PR 24706.


http://reviews.llvm.org/D16779

Files:
  include/clang/Basic/TargetInfo.h
  lib/Basic/Targets.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/Sema/attr-mode.c

Index: test/Sema/attr-mode.c
===
--- test/Sema/attr-mode.c
+++ test/Sema/attr-mode.c
@@ -4,6 +4,8 @@
 // RUN:   -verify %s
 // RUN: %clang_cc1 -triple powerpc64-pc-linux-gnu -DTEST_64BIT_PPC64 
-fsyntax-only \
 // RUN:   -verify %s
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnux32 -DTEST_64BIT_X86 
-fsyntax-only \
+// RUN:   -verify %s
 
 typedef int i16_1 __attribute((mode(HI)));
 int i16_1_test[sizeof(i16_1) == 2 ? 1 : -1];
@@ -63,8 +65,17 @@
 void test_long_to_i64(long long* y) { f_i64_arg(y); }
 void test_long_to_ui64(unsigned long long* y) { f_ui64_arg(y); }
 #elif TEST_64BIT_X86
+#ifdef __ILP32__
+typedef unsigned int gcc_word __attribute__((mode(word)));
+int foo[sizeof(gcc_word) == 8 ? 1 : -1];
+typedef unsigned int gcc_unwind_word __attribute__((mode(unwind_word)));
+int foo[sizeof(gcc_unwind_word) == 8 ? 1 : -1];
+void test_long_to_i64(long long* y) { f_i64_arg(y); }
+void test_long_to_ui64(unsigned long long* y) { f_ui64_arg(y); }
+#else
 void test_long_to_i64(long* y) { f_i64_arg(y); }
 void test_long_to_ui64(unsigned long* y) { f_ui64_arg(y); }
+#endif
 typedef  float f128ibm __attribute__ ((mode (TF))); // 
expected-error{{unsupported machine mode 'TF'}}
 #elif TEST_64BIT_PPC64
 typedef  float f128ibm __attribute__ ((mode (TF)));
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -3332,7 +3332,7 @@
 // FIXME: glibc uses 'word' to define register_t; this is narrower than a
 // pointer on PIC16 and other embedded platforms.
 if (Str == "word")
-  DestWidth = S.Context.getTargetInfo().getPointerWidth(0);
+  DestWidth = S.Context.getTargetInfo().getRegisterWidth();
 else if (Str == "byte")
   DestWidth = S.Context.getTargetInfo().getCharWidth();
 break;
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -4029,6 +4029,8 @@
 
   // for x32 we need it here explicitly
   bool hasInt128Type() const override { return true; }
+  unsigned getUnwindWordWidth() const override { return 64; }
+  unsigned getRegisterWidth() const override { return 64; }
 
   bool validateGlobalRegisterVariable(StringRef RegName,
   unsigned RegSize,
Index: include/clang/Basic/TargetInfo.h
===
--- include/clang/Basic/TargetInfo.h
+++ include/clang/Basic/TargetInfo.h
@@ -413,10 +413,10 @@
   }
 
   // Return the size of unwind_word for this target.
-  unsigned getUnwindWordWidth() const { return getPointerWidth(0); }
+  virtual unsigned getUnwindWordWidth() const { return getPointerWidth(0); }
 
   /// \brief Return the "preferred" register width on this target.
-  unsigned getRegisterWidth() const {
+  virtual unsigned getRegisterWidth() const {
 // Currently we assume the register width on the target matches the pointer
 // width, we can introduce a new variable for this if/when some target 
wants
 // it.


Index: test/Sema/attr-mode.c
===
--- test/Sema/attr-mode.c
+++ test/Sema/attr-mode.c
@@ -4,6 +4,8 @@
 // RUN:   -verify %s
 // RUN: %clang_cc1 -triple powerpc64-pc-linux-gnu -DTEST_64BIT_PPC64 -fsyntax-only \
 // RUN:   -verify %s
+// RUN: %clang_cc1 -triple x86_64-pc-linux-gnux32 -DTEST_64BIT_X86 -fsyntax-only \
+// RUN:   -verify %s
 
 typedef int i16_1 __attribute((mode(HI)));
 int i16_1_test[sizeof(i16_1) == 2 ? 1 : -1];
@@ -63,8 +65,17 @@
 void test_long_to_i64(long long* y) { f_i64_arg(y); }
 void test_long_to_ui64(unsigned long long* y) { f_ui64_arg(y); }
 #elif TEST_64BIT_X86
+#ifdef __ILP32__
+typedef unsigned int gcc_word __attribute__((mode(word)));
+int foo[sizeof(gcc_word) == 8 ? 1 : -1];
+typedef unsigned int gcc_unwind_word __attribute__((mode(unwind_word)));
+int foo[sizeof(gcc_unwind_word) == 8 ? 1 : -1];
+void test_long_to_i64(long long* y) { f_i64_arg(y); }
+void test_long_to_ui64(unsigned long long* y) { f_ui64_arg(y); }

Re: [PATCH] D16469: Pass --wrap=pthread_create to linker for -fsplit-stack

[H.J Lu via cfe-commits]

hjl.tools added a comment.

Can you check it in for me? Thanks.


http://reviews.llvm.org/D16469



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D16469: Pass --wrap=pthread_create to linker for -fsplit-stack

[H.J Lu via cfe-commits]

hjl.tools created this revision.
hjl.tools added a reviewer: rsmith.
hjl.tools added a subscriber: cfe-commits.

From

https://gcc.gnu.org/ml/gcc-patches/2010-09/msg01807.html

-fsplit-stack should pass --wrap=pthread_create to linker for -fsplit-stack
It is needed to initialize the stack guard.  This fixes PR 20148.

http://reviews.llvm.org/D16469

Files:
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -9001,6 +9001,9 @@
   if (WantPthread && !isAndroid)
 CmdArgs.push_back("-lpthread");
 
+  if (Args.hasArg(options::OPT_fsplit_stack))
+CmdArgs.push_back("--wrap=pthread_create");
+
   CmdArgs.push_back("-lc");
 
   if (Args.hasArg(options::OPT_static))


Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -9001,6 +9001,9 @@
   if (WantPthread && !isAndroid)
 CmdArgs.push_back("-lpthread");
 
+  if (Args.hasArg(options::OPT_fsplit_stack))
+CmdArgs.push_back("--wrap=pthread_create");
+
   CmdArgs.push_back("-lc");
 
   if (Args.hasArg(options::OPT_static))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits