Re: Can I provide a hint to gcc for return value optimization?

[Jonathan Wakely via Gcc]

On Mon, 15 Nov 2021, 06:47 unlvsur unlvsur via Gcc,  wrote:

> I want give a hint to gcc that allows std::string to rvo. Is that
> possible? Any attribute for doing that?
>

It's already allowed, and will be done automatically whenever it's possible.



>

RE: Can I provide a hint to gcc for return value optimization?

[unlvsur unlvsur via Gcc]

Oh I mean copy elision.

std::string str;
do_something(str);
return str;

Something like this.

Or factory function:
std::string foo()
{
return factory(a.begin(),a.end());
}

Sometimes the first one does not guarantee to happen?
Sent from Mail for Windows

From: Jonathan Wakely
Sent: Monday, November 15, 2021 03:05
To: unlvsur unlvsur
Cc: gcc@gcc.gnu.org
Subject: Re: Can I provide a hint to gcc for return value optimization?


On Mon, 15 Nov 2021, 06:47 unlvsur unlvsur via Gcc, 
mailto:gcc@gcc.gnu.org>> wrote:
I want give a hint to gcc that allows std::string to rvo. Is that possible? Any 
attribute for doing that?

It's already allowed, and will be done automatically whenever it's possible.

GCC 12.0.0 Status Report (2021-11-15), Stage 3 in effect NOW

[Richard Biener via Gcc]

Status
==

The GCC development branch now is open for general bugfixing (Stage 3).

Take the quality data below with a big grain of salt - most of the
new P3 classified bugs will become P1 or P2 (generally every
regression against GCC 11 is to be considered P1 if it concerns
primary or secondary platforms).


Quality Data


Priority  #   Change from last report
---   ---
P1   34   +  19
P2  306   +  24 
P3  237   +  44
P4  207   +   5
P5   25
---   ---
Total P1-P3 577   +  87
Total   809   +  92


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2021-October/237464.html

Re: GCC 12.0.0 Status Report (2021-11-15), Stage 3 in effect NOW

[H.J. Lu via Gcc]

On Mon, Nov 15, 2021 at 4:05 AM Richard Biener via Gcc-patches
 wrote:
>
>
> Status
> ==
>
> The GCC development branch now is open for general bugfixing (Stage 3).
>
> Take the quality data below with a big grain of salt - most of the
> new P3 classified bugs will become P1 or P2 (generally every
> regression against GCC 11 is to be considered P1 if it concerns
> primary or secondary platforms).
>
>
> Quality Data
> 
>
> Priority  #   Change from last report
> ---   ---
> P1   34   +  19
> P2  306   +  24
> P3  237   +  44
> P4  207   +   5
> P5   25
> ---   ---
> Total P1-P3 577   +  87
> Total   809   +  92
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/pipermail/gcc/2021-October/237464.html

Hi,

I'd like to add an option to disable copy relocation:

https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583022.html

Thanks.

-- 
H.J.

ISO C3X proposal: nonnull qualifier

[Alejandro Colomar (man-pages) via Gcc]

Hi all,

I'd like to propose the following feature for ISO C (and also ISO C++).
It is based on a mix of GCC's [[gnu::nonnull]] and Clang's _Nonnull,
with a pinch of salt of mine.

I'd like to get some feedback from GCC and Clang,
before sending it as an official proposal.

BTW, since the working group is probably very busy with C2X,
I may delay sending it more than a year.
Or I may propose it first to ISO C++,
and then to ISO C.

I wrote the initial draft in the form of a manual page,
whose source code can be found here:


It has a Makefile to easily transform it into a PDF.
I also rendered it with cat to inline it in this email.


Cheers,
Alex


---
nonnull(3)N   nonnull(3)

NAME
   nonnull - non‐null pointer

SYNOPSIS
   type‐qualifier:
const
nonnull
restrict
volatile
_Atomic

DESCRIPTION
   Constraints
   Types   other   than   pointer   types   shall   not   be
   nonnull‐qualified.

   Semantics
   The properties associated with qualified types are  mean‐
   ingfull only for expressions that are lvalues.

   If  the same qualifier appears more than once in the same
   specifier‐qualifier list or  as  declaration  specifiers,
   either directly or via one or more typedefs, the behavior
   is the same as if it appeared only once.  If other quali‐
   fiers  appear  along  with the _Atomic qualifier, the re‐
   sulting type is the so‐qualified atomic type.

   If an attempt is made to assign NULL to a pointer defined
   with  the  nonnull  qualifier, the behavior is undefined.
   If an attempt is made to refer to a pointer with a  non‐‐
   nonnull‐qualified  type through the use of an lvalue with
   nonnull‐qualified type, the behavior is undefined.

   The intended use of the nonnull and  restrict  qualifiers
   (like the register storage class) is to promote optimiza‐
   tion, and deleting all instances of  the  qualifier  from
   all  preprocessing translation units composing a conform‐
   ing program does not change its meaning (i.e., observable
   behavior).

NOTES
   These  rules  for  nonnull are somewhat of the reverse of
   const: Instead of forbidding the discarding of the quali‐
   fier,  we forbid the addition of the qualifier.  The rea‐
   son is that constant variables are a subset of variables,
   and  the  danger  is  in  treating a const as a variable.
   Similarly, nonnull pointers are a  subset  of  (possibly‐
   NULL)  pointers,  but the danger is in treating possibly‐
   NULL pointers as nonnull pointers.

   Prior art
   GCC has [[gnu::nonnull]].  Why is this better?

   It can be applied more specifically in the case of point‐
   ers  to pointers.  And, like with const, the nonnull‐ness
   can be better enforced by passing the qualifier around.

   However,  we  recognize  the  optimizations  allowed   by
   [[gnu::nonnull]],  and also allow them, by specifying the
   behavior as undefined when the qualifier is  misused,  as
   GCC does.

   Clang has _Nonnull.  Why is this better?

   Clang found that using a qualifier was better than an at‐
   tribute, since it allowed to more specifically  apply  it
   to pointers to pointers.  We recognize that, and also use
   a qualifier.

   Clang doesn't specify the behavior  as  being  undefined.
   That  forbids optimizations, that would otherwise be pos‐
   sible.  We prefer to allow for those optimizations.

   Clang considers this qualifier to be useful only as a di‐
   agnostics  generator.   We not only allow for diagnostics
   to be issued, but we have stricter  rules  that  make  it
   more difficult to produce incorrect code.

   Even  though the language has reserved identifiers start‐
   ing with underscore + uppercase for  this  kind  of  key‐
   words,  Clang has already used _Nonnull, and since we are
   changing the meaning, it might cause problems to existing
   code.  So nonnull seems a better name, which hopefully is
   not used by existing code, or at least it is less used.

EXAMPLES
   Correct
   strcpy(3) may be implemented in  the  following  way,  to
   signify that it cannot accept NULL as input to any of its
   arguments, and that it cannot ever return NULL either.

   char *nonnull strcpy(char *nonnull restrict dest,
const char *nonnull restrict src)
   {
char *d;

d = dest;
while ((*d++ = *src++) != '\0');

return dest;
   }

   Note that d need not be nonnull‐qualified, since possibly
   being NULL is a superset of not possibly being NULL.

   The  following variations of the above are incorrect, for
   the reasons that follow the 

Re: ISO C3X proposal: nonnull qualifier

[Alejandro Colomar (man-pages) via Gcc]

Hi,

On 11/15/21 5:01 PM, Alejandro Colomar (man-pages) wrote:
> Hi all,
> 
> I'd like to propose the following feature for ISO C (and also ISO C++).
> It is based on a mix of GCC's [[gnu::nonnull]] and Clang's _Nonnull,
> with a pinch of salt of mine.
> 
> I'd like to get some feedback from GCC and Clang,
> before sending it as an official proposal.
> 
> BTW, since the working group is probably very busy with C2X,
> I may delay sending it more than a year.
> Or I may propose it first to ISO C++,
> and then to ISO C.
> 
> I wrote the initial draft in the form of a manual page,
> whose source code can be found here:
> 
> 
> It has a Makefile to easily transform it into a PDF.
> I also rendered it with cat to inline it in this email.

I just came up with some addition to the initial draft:

$ git diff
diff --git a/nonnull.7 b/nonnull.7
index 1390b2d..75370e1 100644
--- a/nonnull.7
+++ b/nonnull.7
@@ -44,7 +44,10 @@ through the use of
 an lvalue with
 .BR \%nonnull -qualified
 type,
-the behavior is undefined.
+the behavior is undefined,
+except if preceeding code
+can prove at compile time that the pointer will not possibly be
+.BR NULL .
 .PP
 The intended use of the
 .B \%nonnull
@@ -212,6 +215,32 @@ since the user isn't properly informed that
 may cause undefined behavior in the implementation of the function
 .RI ( dest
 is dereferenced).
+.SS non-nonnull-qualified to nonnull-qualified valid assignment
+.EX
+int *nonnull foo(int *p)
+{
+   if (!p)
+   exit(EXIT_FAILURE);
+
+   return p;
+}
+.EE
+.PP
+The code above is guaranteed to behave correctly,
+since the check against
+.B NULL
+guarantees that the
+(otherwise causing undefined behaviour)
+assignment is only done if
+.I p
+is not
+.BR NULL .
+Forcing the user to add casts would be dangerous,
+since casts usually disable most compiler diagnostics.
+Since this qualifier pretends to improve programs' correctness,
+that would be disastrous.
+Casts also unnecessarily make code less readable.
+Letting the compiler decide if some assignment is valid is safer.
 .SH AUTHORS
 Alejandro Colomar
 .UR alx.manpa...@gmail.com


The affected paragraphs now render as:

[
   If an attempt is made to assign NULL to a pointer defined
   with  the  nonnull  qualifier, the behavior is undefined.
   If an attempt is made to refer to a pointer with a  non‐‐
   nonnull‐qualified  type through the use of an lvalue with
   nonnull‐qualified type, the behavior is undefined, except
   if  preceeding  code  can  prove at compile time that the
   pointer will not possibly be NULL.
]

[
   non‐nonnull‐qualified to nonnull‐qualified valid assignment
   int *nonnull foo(int *p)
   {
if (!p)
 exit(EXIT_FAILURE);

return p;
   }

   The code above is guaranteed to behave  correctly,  since
   the  check  against  NULL  guarantees that the (otherwise
   causing undefined behaviour) assignment is only done if p
   is not NULL.  Forcing the user to add casts would be dan‐
   gerous, since casts usually disable most  compiler  diag‐
   nostics.   Since  this qualifier pretends to improve pro‐
   grams' correctness, that would be disastrous.  Casts also
   unnecessarily  make code less readable.  Letting the com‐
   piler decide if some assignment is valid is safer.
]

However,
I'm not sure if this imposes too much complexity for compilers,
and maybe it's better to say that it's implementation-defined.


Thanks,
Alex


-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Re: Anything I can contribute?

[Philip Herron]

Hi Kaisheng,

There are plenty of places to get started on the Rust Front-end for
GCC if you are interested?

- https://github.com/Rust-GCC/gccrs
- https://github.com/Rust-GCC/gccrs/blob/master/CONTRIBUTING.md
- 
https://github.com/Rust-GCC/gccrs/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-pr

We keep a list of good first pr's which is the best place to start.
Hope this helps.

--Phil

On Sat, 13 Nov 2021 at 08:36, Deng Kaisheng  wrote:
>
> Hi,
>
> My name is Deng Kaisheng, a graduate student in National University of 
> Sinapore (NUS) now major in computer science. I've read the introduction of 
> your organization and I'm quite interested in what you're doing.
>
> I want to do something and contribute to the community, and I wonder if there 
> is something I can do. I major in computer science since undergraduate with a 
> solid foundation in CS, and I'm also confident in my fast-learning skills. I 
> have programming skills in C++, Python, Java, Objective-C, etc., and database 
> skills in MySQL and Cassandra.
>
> I wonder if your organization is going to take part in the GSoC 2022, if 
> possible, I would like to contribute to your project in GSOC 2022.
>
> I am looking forward to your reply!
>
> Best regards,
>
> Kaisheng

Re: ISO C3X proposal: nonnull qualifier

[Joseph Myers]

lvalue-to-rvalue conversion loses qualifiers, which makes any rules based 
on whether the RHS of an assignment was nonnull-qualified very 
problematic.  (The specification of restrict is exceedingly tricky and 
very unlikely to be a good basis for specifying any other feature.)

I don't think a manpage is a good form for proposing a language feature.  
Actual proposed normative wording for the C standard, showing all relevant 
changes to all relevant subclauses, is better.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ISO C3X proposal: nonnull qualifier

[Alejandro Colomar (man-pages) via Gcc]

Hi Joseph,

On 11/15/21 21:18, Joseph Myers wrote:

lvalue-to-rvalue conversion loses qualifiers, which makes any rules based
on whether the RHS of an assignment was nonnull-qualified very
problematic.  (The specification of restrict is exceedingly tricky and
very unlikely to be a good basis for specifying any other feature.)


Hmm.
restrict was the closest thing to a
const-like level of safety that I could think of.
It would allow a compiler to keep track of nullness
of every pointer,
and issue appropriate diagnostics
probably better than what -fanalyzer already does.

How is restrict handling that problem of lvalue-to-rvalue already?

Can you think of any other way nonnull-ness could be passed
to nested function calls with language enforcement?

The other option would be to propose plain [[gnu::nonnull]],
which couldn't be enforced across nested function calls
(or I could't think of how yet).
Well, the simplest cases (i.e., not pointer-to-pointer)
could be detected by the compiler,
but other than that, it's impossible.
But if that's the only way,
it's better than nothing.



I don't think a manpage is a good form for proposing a language feature.
Actual proposed normative wording for the C standard, showing all relevant
changes to all relevant subclauses, is better.



My intention is that the final PDF to be sent to the committee
will have those diffs.
But I have no clue of how to do that kind of things,
so for an initial draft to discuss on,
before even presenting it to the committee,
I think my "native" language for writing technical documents
will be easier.

Also,
I'm curious,
do you do those diffs usually by hand?
I mean, you can't diff(1) a PDF, can you? :)

Considering that C moves at a 10-years pace,
and we're late for C2X,
I have until around 2030 to learn how to do that :-)


Thanks!
and kind regards,
Alex


--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Re: ISO C3X proposal: nonnull qualifier

[Joseph Myers]

On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote:

> How is restrict handling that problem of lvalue-to-rvalue already?

restrict has tricky rules about "based on" (6.7.3.1).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: ISO C3X proposal: nonnull qualifier

[Alejandro Colomar (man-pages) via Gcc]

Hi Joseph,

On 11/15/21 23:17, Joseph Myers wrote:

On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote:


How is restrict handling that problem of lvalue-to-rvalue already?


restrict has tricky rules about "based on" (6.7.3.1).


Hmm, I think I can "base on" that,
to define what I had in mind. :)

I'll come back to you when I have something
(or when I desist trying to come up with that something).

Cheers,
Alex


--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Re: ISO C3X proposal: nonnull qualifier

[Joseph Myers]

On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote:

> Hi Joseph,
> 
> On 11/15/21 23:17, Joseph Myers wrote:
> > On Mon, 15 Nov 2021, Alejandro Colomar (man-pages) via Gcc wrote:
> > 
> > > How is restrict handling that problem of lvalue-to-rvalue already?
> > 
> > restrict has tricky rules about "based on" (6.7.3.1).
> 
> Hmm, I think I can "base on" that,
> to define what I had in mind. :)

"based on" is about optimizations; I think it's even less suited to 
anything relating to diagnostics than it is to optimization.

To restrict assignment between different kinds of pointers, I'd think 
you'd want pointer type variants that differ in some way *other* than 
qualifiers, a way that's unaffected by lvalue-to-rvalue conversion, but 
that comes with its own rules on implicit conversion as if by assignment 
(6.5.16.1) (though then you also need to work out what's allowed in terms 
of mixing these pointer type variants in all the other operations allowing 
pointers, what type results of pointer arithmetic have, etc.).  And there 
should surely also be some way of converting a normal pointer to this 
variant with a runtime check for NULL.

Note that discussion of prior art in such a proposal should also consider 
relevant prior art (for constraining possible values of a variable through 
the type system) in C++ or other languages if possible.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Can I provide a hint to gcc for return value optimization?

[Jason Merrill via Gcc]

On Mon, Nov 15, 2021 at 3:17 AM unlvsur unlvsur via Gcc 
wrote:

> Oh I mean copy elision.
>
> std::string str;
> do_something(str);
> return str;
>
> Something like this.
>
> Or factory function:
> std::string foo()
> {
> return factory(a.begin(),a.end());
> }
>

Neither return should involve a copy, you don't need any extra annotation.

Jason

Re: Anything I can contribute?

[Deng Kaisheng]

Thanks! 

> 在 2021年11月16日，上午1:17，Philip Herron  写道：
> 
> - External Email -
> 
> 
> 
> Hi Kaisheng,
> 
> There are plenty of places to get started on the Rust Front-end for
> GCC if you are interested?
> 
> - https://github.com/Rust-GCC/gccrs
> - https://github.com/Rust-GCC/gccrs/blob/master/CONTRIBUTING.md
> - 
> https://github.com/Rust-GCC/gccrs/issues?q=is%3Aissue+is%3Aopen+label%3Agood-first-pr
> 
> We keep a list of good first pr's which is the best place to start.
> Hope this helps.
> 
> --Phil
> 
>> On Sat, 13 Nov 2021 at 08:36, Deng Kaisheng  wrote:
>> 
>> Hi,
>> 
>> My name is Deng Kaisheng, a graduate student in National University of 
>> Sinapore (NUS) now major in computer science. I've read the introduction of 
>> your organization and I'm quite interested in what you're doing.
>> 
>> I want to do something and contribute to the community, and I wonder if 
>> there is something I can do. I major in computer science since undergraduate 
>> with a solid foundation in CS, and I'm also confident in my fast-learning 
>> skills. I have programming skills in C++, Python, Java, Objective-C, etc., 
>> and database skills in MySQL and Cassandra.
>> 
>> I wonder if your organization is going to take part in the GSoC 2022, if 
>> possible, I would like to contribute to your project in GSOC 2022.
>> 
>> I am looking forward to your reply!
>> 
>> Best regards,
>> 
>> Kaisheng