nonnull, -Wnonnull, and do/while

[Stefan Sobernig]

Hi

We have a number of do/while loops with NULL checks in their exit
conditions:

#include 

static void f(const char *s) __attribute__((nonnull(1)));

int main(void)
{
  const char *p = "X";
  f(p);
}

static void f(const char *s)
{
  do {
printf("%s\n",s);
s = NULL;
  } while (s != NULL);

}

Under a recent gcc 6 [*], we run into -Wnonnull warnings using the
nonnull attribute:

test.c: In function 'f':
test.c:16:14: warning: nonnull argument 's' compared to NULL [-Wnonnull]
   } while (s != NULL);

Am I missing sth.? Is this a false positive?

I'd appreciate your guidance!

Stefan

[*] gcc-mp-6 (MacPorts gcc6 6-20160207_0) 6.0.0 20160207 (experimental)

Re: nonnull, -Wnonnull, and do/while

[Marek Polacek]

On Tue, Feb 16, 2016 at 10:43:08AM +0100, Stefan Sobernig wrote:
> Under a recent gcc 6 [*], we run into -Wnonnull warnings using the
> nonnull attribute:

Yes, this warning has been enhanced for GCC 6.
 
> test.c: In function 'f':
> test.c:16:14: warning: nonnull argument 's' compared to NULL [-Wnonnull]
>} while (s != NULL);
> 
> Am I missing sth.? Is this a false positive?

Well, it's just that "s" has the nonnull attribute so the compiler thinks it
should never be null in which case comparing it to null should be redundant.
Doesn't seem like a false positive to me, but maybe someone else feels
otherwise.

Marek

Re: nonnull, -Wnonnull, and do/while

[Jakub Jelinek]

On Tue, Feb 16, 2016 at 11:04:38AM +0100, Marek Polacek wrote:
> On Tue, Feb 16, 2016 at 10:43:08AM +0100, Stefan Sobernig wrote:
> > Under a recent gcc 6 [*], we run into -Wnonnull warnings using the
> > nonnull attribute:
> 
> Yes, this warning has been enhanced for GCC 6.
>  
> > test.c: In function 'f':
> > test.c:16:14: warning: nonnull argument 's' compared to NULL [-Wnonnull]
> >} while (s != NULL);
> > 
> > Am I missing sth.? Is this a false positive?
> 
> Well, it's just that "s" has the nonnull attribute so the compiler thinks it
> should never be null in which case comparing it to null should be redundant.
> Doesn't seem like a false positive to me, but maybe someone else feels
> otherwise.

The nonnull attribute should be solely about the value that is passed to the
function, it doesn't tell anything about the value of the argument after
it is changed.  So IMHO this warning change should be reverted and instead
we should warn somewhere soon after going into SSA, only when
the SSA_NAME_IS_DEFAULT_DEF of the PARM_DECL which has non-NULL attribute
is compared to NULL.

Jakub

Re: nonnull, -Wnonnull, and do/while

[Alexander Monakov]

On Tue, 16 Feb 2016, Marek Polacek wrote:
> Well, it's just that "s" has the nonnull attribute so the compiler thinks it
> should never be null in which case comparing it to null should be redundant.
> Doesn't seem like a false positive to me, but maybe someone else feels
> otherwise.

Please look at the posted code again:

static void f(const char *s)
{
  do {
printf("%s\n",s);
s = NULL;
  } while (s != NULL);
}

Since 's' is assigned to, the constraint from 'printf' is no longer useful for
warning at the point of comparison.  It clearly looks like a false positive to
me.

Alexander

Re: nonnull, -Wnonnull, and do/while

[Marek Polacek]

On Tue, Feb 16, 2016 at 11:11:21AM +0100, Jakub Jelinek wrote:
> On Tue, Feb 16, 2016 at 11:04:38AM +0100, Marek Polacek wrote:
> > On Tue, Feb 16, 2016 at 10:43:08AM +0100, Stefan Sobernig wrote:
> > > Under a recent gcc 6 [*], we run into -Wnonnull warnings using the
> > > nonnull attribute:
> > 
> > Yes, this warning has been enhanced for GCC 6.
> >  
> > > test.c: In function 'f':
> > > test.c:16:14: warning: nonnull argument 's' compared to NULL [-Wnonnull]
> > >} while (s != NULL);
> > > 
> > > Am I missing sth.? Is this a false positive?
> > 
> > Well, it's just that "s" has the nonnull attribute so the compiler thinks it
> > should never be null in which case comparing it to null should be redundant.
> > Doesn't seem like a false positive to me, but maybe someone else feels
> > otherwise.
> 
> The nonnull attribute should be solely about the value that is passed to the
> function, it doesn't tell anything about the value of the argument after
> it is changed.  So IMHO this warning change should be reverted and instead
> we should warn somewhere soon after going into SSA, only when
> the SSA_NAME_IS_DEFAULT_DEF of the PARM_DECL which has non-NULL attribute
> is compared to NULL.

In that case I take back what I wrote, sorry.

Marek

Re: gnu-gabi group

[Szabolcs Nagy]

On 15/02/16 17:36, Mike Frysinger wrote:
> On 15 Feb 2016 16:18, Szabolcs Nagy wrote:
>> you as a group admin can do that, others cannot join
>> without creating a account at google (which requires
>> the acceptance of the google tos etc).
> 
> that is annoying

i didn't know about list+subscr...@googlegroups.com
(thanks Florian and Joseph)

>> you also have censorship rights over others.
> 
> umm, every mailing list has that.  Google Groups is no different.

it's better if admin right is at some discussion related
organization. (e.g. in case anything happens to H.J.Lu)

>> even if you add users to the list they cannot access
>> the archive through standard http or https,
> 
> you're conflating things here.  of course access is through "standard
> http or https" -- that's the transport protocol that everyone has to
> implement according to the standard in order to work.  Goole is not
> different here.

the contents cannot be accessed with an http or https client.
(unless you know the magic urls below)

>> they need to allow google to execute javascript code on their
>> machine.
> 
> complaining that the web interface executes JS is a bit luddite-ish.

some of us tend to browse the web from terminal (== no js).

>> (so wget does not work).
> 
> every message has a link to the raw message you can use to fetch the
> mail directly.
> 
> perm link:
> https://groups.google.com/d/msg/x32-abi/IHmCJvigOEg/TyjZJYZ63DMJ

redirects me to
https://groups.google.com/forum/#!msg/x32-abi/IHmCJvigOEg/TyjZJYZ63DMJ

> which has a link to the raw message:
> https://groups.google.com/forum/message/raw?msg=x32-abi/IHmCJvigOEg/TyjZJYZ63DMJ

i didn't know about this raw url, it seems there is
https://groups.google.com/forum/print/msg/x32-abi/IHmCJvigOEg/TyjZJYZ63DMJ
too, so if i always change the urls i can browse the archive.
(this is not discoverable without js as far as i can see)

with the +subscribe@ and the raw msg options i'm no longer
against google groups hosting public discussions (provided
the project documents these somewhere), i still prefer more
accessible alternatives though.

> it's actually nicer than mailmain (i.e. sourceware) as it doesn't do all
> the trivial content mangling (s/@/ at/g).  it's not like e-mail scrapers
> today can't reverse that easily.
> 
>> and the url through which you visit a post is not a
>> reliable permanent link so linking to posts is hard.
> 
> every post has a "link" option to get a perm link.  needing the location
> in the URL bar be the perm link is a weak (dumb imo) requirement.
> -mike
> 

Re: gengtype: conditional GTY ? (to add before GCC 6 release)

[Mikhail Maltsev]

On 02/15/2016 06:34 PM, Michael Matz wrote:
> Hi,
> 
> On Fri, 12 Feb 2016, Richard Biener wrote:
> 
>>> What do you think about refactoring iterators in GCC 7?
>>
>> I think refactoring towards STL style iterators would be welcome.  It 
>> may be different for the actual instances though.
> 
> Oh God, please, for the live of all kittens, no.
Well, 'begin', 'end', 'operator++' and 'operator!=' are, unfortunately,
hardwired into the core language (I mean, [stmt.ranged]/1).

If anything, implement
> and use a range idiom like in D.
> 
Could you please elaborate on that?

> 
> Ciao,
> Michael.
> 

-- 
Regards,
Mikhail Maltsev

Placement new versus flifetime-dse

[Andrew Haley]

I'm fixing a bug which involves initialization of a field of an object
in its placement new function before the constructor is called.  This
is falling foul of DSE, which deletes the field initialization.

I see this:

  @item -fno-lifetime-dse
  @opindex fno-lifetime-dse
  In C++ the value of an object is only affected by changes within its
  lifetime: when the constructor begins, the object has an indeterminate
  value, and any changes during the lifetime of the object are dead when
  the object is destroyed.  Normally dead store elimination will take
  advantage of this; if your code relies on the value of the object
  storage persisting beyond the lifetime of the object, you can use this
  flag to disable this optimization.

I'm quite happy to believe this, and treat my bug simply as an error
between chair and keyboard, but I cannot find the language in the C++
standard which declares that the lifetime of an object begins with its
constructor, and thus any stores into the object performed by
placement new may be deleted.

Can someone please tell me Chapter and Verse in the standard, please?
Then I can close this one.

Thanks,

Andrew.

Re: Placement new versus flifetime-dse

[Jakub Jelinek]

On Tue, Feb 16, 2016 at 01:04:06PM +, Andrew Haley wrote:
> I'm fixing a bug which involves initialization of a field of an object
> in its placement new function before the constructor is called.  This
> is falling foul of DSE, which deletes the field initialization.
> 
> I see this:
> 
>   @item -fno-lifetime-dse
>   @opindex fno-lifetime-dse
>   In C++ the value of an object is only affected by changes within its
>   lifetime: when the constructor begins, the object has an indeterminate
>   value, and any changes during the lifetime of the object are dead when
>   the object is destroyed.  Normally dead store elimination will take
>   advantage of this; if your code relies on the value of the object
>   storage persisting beyond the lifetime of the object, you can use this
>   flag to disable this optimization.
> 
> I'm quite happy to believe this, and treat my bug simply as an error
> between chair and keyboard, but I cannot find the language in the C++
> standard which declares that the lifetime of an object begins with its
> constructor, and thus any stores into the object performed by
> placement new may be deleted.
> 
> Can someone please tell me Chapter and Verse in the standard, please?
> Then I can close this one.

I'd think [basic.life] describes this.

Jakub

Re: Placement new versus flifetime-dse

[Andrew Haley]

On 02/16/2016 01:16 PM, Jakub Jelinek wrote:
>> > Can someone please tell me Chapter and Verse in the standard, please?
>> > Then I can close this one.
> I'd think [basic.life] describes this.

For the record, I found it in C++98 [class.cdtor]:

  For an object of non-POD class type ... before the constructor
  begins execution ... referring to any non-static member or base
  class of the object results in undefined behavior

Thanks,

Andrew.

Re: Need some help regarding bug Bug 38612

[David Malcolm]

On Tue, 2016-02-16 at 12:25 +0530, Prasad Ghangal wrote:
> Hi !
> I am trying to fix bug 38612
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612).
> As mentioned in comment 4,  I am changing warning message in
> typeck2.c. TREE_TYPE(datum) gives type as 'X', but I want 'X*' 

I believe you want to use build_pointer_type (defined in gcc/tree.c) to
go from type X to type X*.

> also
> how to add notes as suggested in the comment ?

Somewhat confusingly, "inform" is the function to call to get a "note".

"inform" is defined in gcc/diagnostic.c.


Hope this is helpful
Dave

Re: gengtype: conditional GTY ? (to add before GCC 6 release)

[Michael Matz]

Hi,
On Tue, 16 Feb 2016, Mikhail Maltsev wrote:

> > If anything, implement and use a range idiom like in D.
> > 
> Could you please elaborate on that?

Motivation:
  http://accu.org/content/conf2009/AndreiAlexandrescu_iterators-must-go.pdf
Detailed intro of the concept:
  http://www.informit.com/articles/article.aspx?p=1407357
A bit discussion and smaller overview:
  
http://www.digitalmars.com/d/archives/digitalmars/D/Ranges_and_versus_iterators_107975.html

I believe ranges are implementable in C++, I'm not sure if efficiently 
already in c++98.  But whatever we implement as iteration scheme, should 
IMHO look more like ranges than explicit iterators (hell, I even much 
prefer the FOR_EACH macros over iterators).


Ciao,
Michael.

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

[H.J. Lu]

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.

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

[Richard Smith]

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.

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

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

[H.J. Lu]

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.

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

[Richard Smith]

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?

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

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

[H.J. Lu]

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.

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

[Richard Smith]

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.

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

[H.J. Lu]

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.

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

[Richard Smith]

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.

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

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

[H.J. Lu]

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.

gcc-5-20160216 is now available

[gccadmin]

Snapshot gcc-5-20160216 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160216/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 233476

You'll find:

 gcc-5-20160216.tar.bz2   Complete GCC

  MD5=ed8f7f9cad41d68a5545d81fa7ab55a7
  SHA1=dd9efb52ac597b1b0ec6b8a25869774cac29fcb0

Diffs from 5-20160209 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

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

[Richard Smith]

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

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

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

[H.J. Lu]

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.