[PATCHv4, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[HAO CHEN GUI via Gcc-patches]

Hi,
  I refined the patch according to reviewer's advice. The main change is to
check if buffer_p is set and buffered error exists. Also two regtests are
fixed by catching the new error.

  I sent out the revised one for review due to my limited knowledge on
Fortran front end.

  The patch escalates the failure when Hollerith constant to real conversion
fails in native_interpret_expr. It finally reports an "Cannot simplify
expression" error in do_simplify method.

  The patch for pr95450 added a verification for decoding/encoding checking
in native_interpret_expr. native_interpret_expr may fail on real type
conversion and returns a NULL tree then. But upper layer calls don't handle
the failure so that an ICE is reported when the verification fails.

  IBM long double is an example. It doesn't have a unique memory presentation
for some real values. So it may not pass the verification. The new test
case shows the problem.

  errorcount is used to check if an error is already reported or not when
getting a bad expr. Buffered errors need to be excluded as they don't
increase error count either.

  The patch passed regression test on Power and x86 linux platforms.

Thanks
Gui Haochen

ChangeLog
2023-03-21  Haochen Gui 

gcc/
PR target/103628
* fortran/target-memory.cc (gfc_interpret_float): Return FAIL when
native_interpret_expr gets a NULL tree.
* fortran/arith.cc (gfc_hollerith2real): Return NULL when
gfc_interpret_float fails.
* fortran/error.cc (gfc_buffered_p): Define.
* fortran/gfortran.h (gfc_buffered_p): Declare.
* fortran/intrinsic.cc: Add diagnostic.h to include list.
(do_simplify): Save errorcount and check it at finish.  Report a
"Cannot simplify expression" error on a bad result if error count
doesn't change and no other errors buffered.

gcc/testsuite/
PR target/103628
* gfortran.dg/assumed_size_refs_2.f90: Catch "Cannot simplify
expression" error.
* gfortran.dg/unpack_field_1.f90: Likewise.
* gfortran.dg/pr103628.f90: New.

Co-Authored-By: Tobias Burnus 


patch.diff
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index c0d12cfad9d..d3d38c7eb6a 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -2752,10 +2752,12 @@ gfc_hollerith2real (gfc_expr *src, int kind)
   result = gfc_get_constant_expr (BT_REAL, kind, &src->where);

   hollerith2representation (result, src);
-  gfc_interpret_float (kind, (unsigned char *) result->representation.string,
-  result->representation.length, result->value.real);
-
-  return result;
+  if (gfc_interpret_float (kind,
+  (unsigned char *) result->representation.string,
+  result->representation.length, result->value.real))
+return result;
+  else
+return NULL;
 }

 /* Convert character to real.  The constant will be padded or truncated.  */
diff --git a/gcc/fortran/error.cc b/gcc/fortran/error.cc
index 214fb78ba7b..872d42e731e 100644
--- a/gcc/fortran/error.cc
+++ b/gcc/fortran/error.cc
@@ -49,6 +49,13 @@ static gfc_error_buffer error_buffer;
 static output_buffer *pp_error_buffer, *pp_warning_buffer;
 static int warningcount_buffered, werrorcount_buffered;

+/* Return buffered_p.  */
+bool
+gfc_buffered_p (void)
+{
+  return buffered_p;
+}
+
 /* Return true if there output_buffer is empty.  */

 static bool
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 219ef8c7612..edfe11796a6 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3328,6 +3328,7 @@ void gfc_internal_error (const char *, ...) 
ATTRIBUTE_NORETURN ATTRIBUTE_GCC_GFC
 void gfc_clear_error (void);
 bool gfc_error_check (void);
 bool gfc_error_flag_test (void);
+bool gfc_buffered_p (void);

 notification gfc_notification_std (int);
 bool gfc_notify_std (int, const char *, ...) ATTRIBUTE_GCC_GFC(2,3);
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index e89131f5a71..2572b7a3448 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -25,6 +25,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "options.h"
 #include "gfortran.h"
 #include "intrinsic.h"
+#include "diagnostic.h" /* For errorcount.  */

 /* Namespace to hold the resolved symbols for intrinsic subroutines.  */
 static gfc_namespace *gfc_intrinsic_namespace;
@@ -4620,6 +4621,7 @@ do_simplify (gfc_intrinsic_sym *specific, gfc_expr *e)
 {
   gfc_expr *result, *a1, *a2, *a3, *a4, *a5, *a6;
   gfc_actual_arglist *arg;
+  int old_errorcount = errorcount;

   /* Max and min require special handling due to the variable number
  of args.  */
@@ -4708,7 +4710,12 @@ do_simplify (gfc_intrinsic_sym *specific, gfc_expr *e)

 finish:
   if (result == &gfc_bad_expr)
-return false;
+{
+  if (errorcount == old_errorcount
+ && (!gfc_buffered_p () && !gfc_error_flag_test ()))
+   gfc_error ("Cannot simplify expression at %L", &e->wh

Re: [PATCH] rs6000: Don't ICE when compiling the __builtin_vec_xst_trunc built-in [PR109178]

[Peter Bergner via Gcc-patches]

On 3/19/23 10:20 PM, Kewen.Lin via Gcc-patches wrote:
> Nice, OK for trunk and gcc12 branch, thanks!

Pushed to trunk and the GCC 12 release branch.  Thanks.

Peter

Re: Re: [PATCH] vect: Check that vector factor is a compile-time constant

[juzhe.zh...@rivai.ai]

I would prefer this is the branch based on gcc-13 where we backport
autovec-related patches once they've landed on trunk.

I won't do any development on this branch, instead, I would just use it for 
releasing my downstream GCC.

I will directly support auto-vectorization on the trunk since the most 
important thing for our RVV auto-vectorization landing
in GCC is reviewing from Richard Biener && Richard sandiford.

Besides, from my experience of development RVV GCC (rvv-next) and optimization 
of RVV LLVM (Rivai downstream LLVM). Now, I have a bunch of new ideas
of supporting RVV auto-vectorization. I think we can have a sync up meeting 
(share my current new ideas) before I start to support RVV auto-vectorization 
before GCC 14.


juzhe.zh...@rivai.ai
 
From: Palmer Dabbelt
Date: 2023-03-18 00:57
To: gcc-patches; Vineet Gupta
CC: Kito Cheng; collison; juzhe.zhong; gcc-patches; kito.cheng; 
richard.sandiford; richard.guenther
Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant
On Tue, 14 Mar 2023 10:48:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
>
>
> On 2/23/23 21:04, Kito Cheng wrote:
>> Hi Jeff:
>>
>>> What I'd been planning to do internally at Ventana was to update our
>>> codebase to gcc-13 once it's released.  Then I'd backport RVV autovec
>>> work from the gcc-14 dev tree into that Ventana branch.
>>>
>>> Instead, but along the same lines, we could have a public gcc-13 based
>>> branch which follows that same process and where Rivos, SiFive, Rivai,
>>> Ventana (and potentially others with an interest in this space) could
>>> collaborate.  Essentially it'd be gcc-13 + RVV autovec support.  We'd
>>> probably have to hash out a bit of policy with the shared branch, but
>>> I'd like to think we could make it work.
>>
>> +1, I like the idea, I could imagine we definitely will do the same
>> work more than four times by different companies if we don't have a
>> collaboration branch...
> So it looks like there's a general sense that a coordination branch off
> gcc-13 is reasonable.  So I'd like to hammer out a few details.
>
>
> First, I recommend we cut a branch from gcc-13 soon after gcc-13
> branches.  That way we've got a place to land the vector work.
>
> Second, I recommend we rebase that branch periodically so that it
> follows gcc-13.  That means downstream consumers may have non-ff pulls,
> but I think we want to follow gcc-13 fairly closely.  I'm open to other
> approaches here.
>
> Third, I was thinking that once a patch related to risc-v vectorization
> goes to the trunk, any one of the principals should be able to
> cherry-pick that patch onto our branch.
 
I'm a little bit confused about what the proposal is here: is the idea 
to have a branch based on gcc-13 where we coordinate work before it 
lands on trunk, or a branch based on gcc-13 where we backport 
autovec-related patches once they've landed on trunk?  In my mind those 
are actually two different things and I think they're both useful, maybe 
we should just do both?
 
Having a shared work-in-progress branch for the autovec stuff makes 
sense to me: it's a big patch set with engineers at multiple companies 
working on it, so having a shared patch stack should help with the 
coordination.  That branch will need to get re-written as patches get 
reviewed/merged, so having it rebase seems reasonable.  I'd have the 
branch based on trunk, as that's the eventual target for the patches, 
but trunk can be unstable so maybe that'll be too much of a headache.
 
For pretty much every other GCC release we've ended up with a "extra 
RISC-V backports" branch, where we end up with some patches that aren't 
suitable for proper upstream backports (usually because they're a 
performance improvement).  We've always talked about doing that as a FSF 
vendor branch, but I don't think we really ever got organized enough to 
do it.  We're doing that internally anyway at Rivos and I'd bet everyone 
else is too, it'd be great to find some way to share as much of that 
work as we can.
 
It's sort of a headache to just propose doing everything, but in this 
case I think we're going to end up with various flavors of both of these 
branches internally at the various companies so we might as well just 
try and do that in public where we can.
 
> That implies we need to identify the principals.  I'll suggest Kito,
> Juzhe, Michael and myself as the initial list.  I'm certainly open to
> others joining.
 
+Vineet, who's been handling our internal GCC branches.
 
We'll still have internal branches for 13 regardless of how the autovec 
stuff proceeds, but having any sort of upstream backport branch will 
make life easier as we'll be able to share some of that work.
 
> Other thoughts or suggestions?
 
Sorry if that throws a bit of a wrench in the works.
 
Just for context: in Rivos land we don't have any specific timelines 
around 13, so the goal on our end is just to keep the vectorization 
stuff progressing smoothly as we spin up more e

Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias

[Arsen Arsenović via Gcc-patches]

Sandra Loosemore  writes:

> On 3/18/23 14:14, Arsen Arsenović via Gcc-patches wrote:
>> Evening,
>> Ping on this patch series.
>> I believe we're close to being able to apply it, with contents of the
>> documentation changes being approved, and only a small build system
>> change and a revised patch series "shape" left to review.
>
> Yup.  I think you can go ahead and commit everything but the part with the
> configure/makefile hackery, which still needs somebody other than me to 
> approve
> it.
>
>> The former change of these two is in:
>> https://inbox.sourceware.org/gcc-patches/20230311203234.2257423-1-ar...@aarsen.me/
>> The patch adds a test for the presence of CONTENTS_OUTPUT_LOCATION into
>> the build system in order to avoid shortcontents coming after contents
>> in HTML output.  We've also updated Texinfo to output shortcontents
>> before contents by default as a result of the discussion here, though
>> that will only happen in newer versions.
>> The latter "shape" is a git log documented at:
>> https://inbox.sourceware.org/gcc-patches/87ttysppsc@aarsen.me/
>> As always, I've freshly rebased the patch series at
>>https://git.sr.ht/~arsen/gcc texinfo_improvements
>> ... or, in (git)web form, at:
>>https://git.sr.ht/~arsen/gcc/log/texinfo_improvements
>> ... with the render at:
>>https://www.aarsen.me/~arsen/final/
>> Thank you all in advance, have a lovely day.
>
> Joseph, could you maybe review the last piece?  A direct pointer to it in
> Arsen's git is
>
> https://git.sr.ht/~arsen/gcc/commit/bc734311cbca1085a1728f79b7eebef8cc7aeac3
>
> -Sandra

Thank you!  I'll do a final rebase and push in the morning.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias

[Arsen Arsenović via Gcc-patches]

Joseph Myers  writes:

> On Mon, 20 Mar 2023, Sandra Loosemore wrote:
>
>> Joseph, could you maybe review the last piece?  A direct pointer to it in
>> Arsen's git is
>> 
>> https://git.sr.ht/~arsen/gcc/commit/bc734311cbca1085a1728f79b7eebef8cc7aeac3
>
> That's OK, assuming I understand correctly that makeinfo will still 
> succeed with a warning when it's an older version (gcc.gnu.org, where 
> update_web_docs_git runs, has version 6.5).

It should, yes, but I'd like to ask for that server to be updated to
Texinfo straight from the press (the press is currently at commit
e2d30b1270deacf5a1eab1d383733a5a088827d6).  Mark told me that this needs
approval from the GCC admins to do.

The reason for this is that the in-dev versions of Texinfo produce more
accessible HTML documentation due to a few changes that I've
incorporated into them, as well as a few made by the Texinfo
maintainers.

Do you think that would be OK?

Thanks, have a lovely night.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias

[Joseph Myers]

On Mon, 20 Mar 2023, Sandra Loosemore wrote:

> Joseph, could you maybe review the last piece?  A direct pointer to it in
> Arsen's git is
> 
> https://git.sr.ht/~arsen/gcc/commit/bc734311cbca1085a1728f79b7eebef8cc7aeac3

That's OK, assuming I understand correctly that makeinfo will still 
succeed with a warning when it's an older version (gcc.gnu.org, where 
update_web_docs_git runs, has version 6.5).

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

[committed] libstdc++: Fix formatting in std::filesystem helper function

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* src/filesystem/ops-common.h (get_temp_directory_from_env): Fix
formatting.
---
 libstdc++-v3/src/filesystem/ops-common.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/filesystem/ops-common.h 
b/libstdc++-v3/src/filesystem/ops-common.h
index abbfca43e5c..c95511b5c95 100644
--- a/libstdc++-v3/src/filesystem/ops-common.h
+++ b/libstdc++-v3/src/filesystem/ops-common.h
@@ -625,7 +625,8 @@ _GLIBCXX_BEGIN_NAMESPACE_FILESYSTEM
   {
buf.resize(len);
len = GetTempPathW(buf.size(), buf.data());
-  } while (len > buf.size());
+  }
+while (len > buf.size());
 
 if (len == 0)
   ec = __last_system_error();
-- 
2.39.2

Re: [PATCH V4] Rework 128-bit complex multiply and divide.

[Segher Boessenkool]

On Mon, Mar 20, 2023 at 01:43:41PM -0400, Michael Meissner wrote:
> On Fri, Mar 17, 2023 at 02:35:16PM -0500, Segher Boessenkool wrote:
> > On Thu, Mar 09, 2023 at 08:40:36PM -0500, Michael Meissner wrote:
> > /* { dg-final { scan-assembler {\m__divtc3\M} } } */
> > 
> > It might well be that we can use a sloppier regexp here, but why would
> > we do that?  It is a good thing to use the \m and \M constraint escapes
> > pretty much always.
> 
> The last time I posted the patch, you said:
> 
> | > +/* { dg-final { scan-assembler "bl __divtc3" } } */
> |
> | This name depends on what object format and ABI is in use (some have an
> | extra leading underscore, or a dot, or whatever).
> 
> So the patch was an attempt to match the other cases.

I also said you could do {\mbl .?__divtc3\M} or similar, in cases where
you need to consider multiple ABIs.  Just searching for a substring is
very suboptimal always.

> > Does this need backports?
> 
> I think we will need backports for GCC 12.  The issue exists in GCC 11, but I
> don't think that GCC 11 can really work on systems with IEEE long double, 
> since
> a lot of the stuff to really finish up the support was not in GCC 11.  I think
> I tried dropping the patch into GCC 12, and it looks like something else may 
> be
> needed.  I will look into it.

Okay, thanks.  We'll see.


Segher

Re: [PATCH v2 1/2] libstdc++: also use sendfile for big files

[Jonathan Wakely via Gcc-patches]

On 20/03/23 22:27 +, Jonathan Wakely wrote:

On 06/03/23 20:52 +0100, Jannik Glückert wrote:

we were previously only using sendfile for files smaller than 2GB, as
sendfile needs to be called repeatedly for files bigger than that.

some quick numbers, copying a 16GB file, average of 10 repetitions:
  old:
  real: 13.4s
  user: 0.14s
  sys : 7.43s
  new:
  real: 8.90s
  user: 0.00s
  sys : 3.68s

Additionally, this fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178

libstdc++-v3/ChangeLog:

  * acinclude.m4 (_GLIBCXX_HAVE_LSEEK): define
  * config.h.in: Regenerate.
  * configure: Regenerate.
  * src/filesystem/ops-common.h: enable sendfile for files
>2GB in std::filesystem::copy_file, skip zero-length files


Also, the ChangeLog entry needs to be indented with tabs, name the
changed functions, and should be complete sentences, e.g.

* acinclude.m4 (_GLIBCXX_HAVE_LSEEK): Define.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/filesystem/ops-common.h (copy_file_sendfile): Define new
function for sendfile logic. Loop to support large files. Skip
zero-length files.
(do_copy_file): Use it.

Re: [PATCH v2 1/2] libstdc++: also use sendfile for big files

[Jonathan Wakely via Gcc-patches]

On 06/03/23 20:52 +0100, Jannik Glückert wrote:

we were previously only using sendfile for files smaller than 2GB, as
sendfile needs to be called repeatedly for files bigger than that.

some quick numbers, copying a 16GB file, average of 10 repetitions:
   old:
   real: 13.4s
   user: 0.14s
   sys : 7.43s
   new:
   real: 8.90s
   user: 0.00s
   sys : 3.68s

Additionally, this fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178

libstdc++-v3/ChangeLog:

   * acinclude.m4 (_GLIBCXX_HAVE_LSEEK): define
   * config.h.in: Regenerate.
   * configure: Regenerate.
   * src/filesystem/ops-common.h: enable sendfile for files
 >2GB in std::filesystem::copy_file, skip zero-length files

Signed-off-by: Jannik Glückert 
---
libstdc++-v3/acinclude.m4|  51 +
libstdc++-v3/config.h.in |   3 +
libstdc++-v3/configure   | 127 ---
libstdc++-v3/src/filesystem/ops-common.h |  86 ---
4 files changed, 175 insertions(+), 92 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index 5136c0571e8..85a09a5a869 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -4583,6 +4583,7 @@ dnl  _GLIBCXX_USE_FCHMOD
dnl  _GLIBCXX_USE_FCHMODAT
dnl  _GLIBCXX_USE_SENDFILE
dnl  HAVE_LINK
+dnl  HAVE_LSEEK
dnl  HAVE_READLINK
dnl  HAVE_SYMLINK
dnl
@@ -4718,25 +4719,6 @@ dnl
  if test $glibcxx_cv_fchmodat = yes; then
AC_DEFINE(_GLIBCXX_USE_FCHMODAT, 1, [Define if fchmodat is available in 
.])
  fi
-dnl
-  AC_CACHE_CHECK([for sendfile that can copy files],
-glibcxx_cv_sendfile, [dnl
-case "${target_os}" in
-  gnu* | linux* | solaris* | uclinux*)
-   GCC_TRY_COMPILE_OR_LINK(
- [#include ],
- [sendfile(1, 2, (off_t*)0, sizeof 1);],
- [glibcxx_cv_sendfile=yes],
- [glibcxx_cv_sendfile=no])
-   ;;
-  *)
-   glibcxx_cv_sendfile=no
-   ;;
-esac
-  ])
-  if test $glibcxx_cv_sendfile = yes; then
-AC_DEFINE(_GLIBCXX_USE_SENDFILE, 1, [Define if sendfile is available in 
.])
-  fi
dnl
  AC_CACHE_CHECK([for link],
glibcxx_cv_link, [dnl
@@ -4749,6 +4731,18 @@ dnl
  if test $glibcxx_cv_link = yes; then
AC_DEFINE(HAVE_LINK, 1, [Define if link is available in .])
  fi
+dnl
+  AC_CACHE_CHECK([for lseek],
+glibcxx_cv_lseek, [dnl
+GCC_TRY_COMPILE_OR_LINK(
+  [#include ],
+  [lseek(1, 0, SEEK_SET);],
+  [glibcxx_cv_lseek=yes],
+  [glibcxx_cv_lseek=no])
+  ])
+  if test $glibcxx_cv_lseek = yes; then
+AC_DEFINE(HAVE_LSEEK, 1, [Define if lseek is available in .])
+  fi
dnl
  AC_CACHE_CHECK([for readlink],
glibcxx_cv_readlink, [dnl
@@ -4785,6 +4779,25 @@ dnl
  if test $glibcxx_cv_truncate = yes; then
AC_DEFINE(HAVE_TRUNCATE, 1, [Define if truncate is available in 
.])
  fi
+dnl
+  AC_CACHE_CHECK([for sendfile that can copy files],
+glibcxx_cv_sendfile, [dnl
+case "${target_os}" in
+  gnu* | linux* | solaris* | uclinux*)
+   GCC_TRY_COMPILE_OR_LINK(
+ [#include ],
+ [sendfile(1, 2, (off_t*)0, sizeof 1);],
+ [glibcxx_cv_sendfile=yes],
+ [glibcxx_cv_sendfile=no])
+   ;;
+  *)
+   glibcxx_cv_sendfile=no
+   ;;
+esac
+  ])
+  if test $glibcxx_cv_sendfile = yes && test $glibcxx_cv_lseek = yes; then
+AC_DEFINE(_GLIBCXX_USE_SENDFILE, 1, [Define if sendfile is available in 
.])
+  fi
dnl
  AC_CACHE_CHECK([for fdopendir],
glibcxx_cv_fdopendir, [dnl
diff --git a/libstdc++-v3/src/filesystem/ops-common.h 
b/libstdc++-v3/src/filesystem/ops-common.h
index abbfca43e5c..9e1b1d41dc5 100644
--- a/libstdc++-v3/src/filesystem/ops-common.h
+++ b/libstdc++-v3/src/filesystem/ops-common.h
@@ -51,6 +51,7 @@
# include 
# ifdef _GLIBCXX_USE_SENDFILE
#  include  // sendfile
+#  include  // lseek
# endif
#endif

@@ -358,6 +359,32 @@ _GLIBCXX_BEGIN_NAMESPACE_FILESYSTEM
  }

#ifdef NEED_DO_COPY_FILE
+#if defined _GLIBCXX_USE_SENDFILE && ! defined _GLIBCXX_FILESYSTEM_IS_WINDOWS
+  bool
+  copy_file_sendfile(int fd_in, int fd_out, size_t length) noexcept
+  {
+// a zero-length file is either empty, or not copyable by this syscall
+// return early to avoid the syscall cost
+if (length == 0)
+  {
+errno = EINVAL;
+return false;
+  }
+size_t bytes_left = length;
+off_t offset = 0;
+ssize_t bytes_copied;
+do {
+  bytes_copied = ::sendfile(fd_out, fd_in, &offset, bytes_left);
+  bytes_left -= bytes_copied;
+} while (bytes_left > 0 && bytes_copied > 0);
+if (bytes_copied < 0)
+  {
+::lseek(fd_out, 0, SEEK_SET);
+return false;
+  }
+return true;
+  }
+#endif
  bool
  do_copy_file(const char_type* from, const char_type* to,
   std::filesystem::copy_options_existing_file options,
@@ -498,28 +525,30 @@ _GLIBCXX_BEGIN_NAMESPACE_FILESYSTEM
return false;
  }

-size_t count = from_st->st_size;
+bool has_copied = false;

Re: Should -ffp-contract=off the default on GCC?

[Jakub Jelinek via Gcc-patches]

On Mon, Mar 20, 2023 at 10:05:57PM +, Qing Zhao via Gcc-patches wrote:
> My question: is the above section the place in C standard “explicitly allows 
> contractions”? If not, where it is in C standard?

http://port70.net/%7Ensz/c/c99/n1256.html#6.5p8
http://port70.net/%7Ensz/c/c99/n1256.html#note78
http://port70.net/%7Ensz/c/c99/n1256.html#F.6

Jakub

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

[Ken Matsui via Gcc-patches]

Please disregard this email.


On Mon, Mar 20, 2023 at 6:26 AM Ken Matsui 
wrote:

> Thank you!
>
> On Mon, Mar 20, 2023 at 2:12 AM Jonathan Wakely 
> wrote:
>
>> On Mon, 20 Mar 2023 at 08:08, Ken Matsui 
>> wrote:
>> >
>> > Ooh... Thank you for pointing that out!
>> >
>> > > The helper doesn't need to be defined for the case where we don't use
>> it.
>> >
>> > I thought that macroing them out leads to compiler errors since users
>> > are possibly using those helpers. But do we not have to care about
>> > that?
>>
>> No, absolutely not.
>>
>> >
>> > ---
>> > libstdc++-v3/ChangeLog:
>> >
>> > * include/std/type_traits (remove_pointer): Use __remove_pointer
>> built-in trait.
>> >
>> > ---
>> > diff --git a/libstdc++-v3/include/std/type_traits
>> > b/libstdc++-v3/include/std/type_traits
>> > index 2bd607a8b8f..cba98091aad 100644
>> > --- a/libstdc++-v3/include/std/type_traits
>> > +++ b/libstdc++-v3/include/std/type_traits
>> > @@ -2025,17 +2025,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> >
>> >template
>> >  struct __remove_pointer_helper
>> > -{ typedef _Tp type; };
>> > +{ using type = _Tp; };
>> >
>> >template
>> >  struct __remove_pointer_helper<_Tp, _Up*>
>> > -{ typedef _Up type; };
>> > +{ using type = _Up; };
>> >
>> >/// remove_pointer
>> > +#if __has_builtin(__remove_pointer)
>> > +  template
>> > +struct remove_pointer
>> > +{ using type = __remove_pointer(_Tp); };
>> > +#else
>> >template
>> >  struct remove_pointer
>> >  : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
>> >  { };
>> > +#endif
>> >
>> >template
>> >  struct __add_pointer_helper
>> >
>> > On Mon, Mar 20, 2023 at 12:57 AM Jonathan Wakely 
>> wrote:
>> > >
>> > >
>> > >
>> > > On Mon, 20 Mar 2023, 07:32 Ken Matsui via Libstdc++, <
>> libstd...@gcc.gnu.org> wrote:
>> > >>
>> > >> CCing libstd...@gcc.gnu.org.
>> > >>
>> > >> On Sun, Mar 19, 2023 at 7:53 PM Ken Matsui <
>> kmat...@cs.washington.edu> wrote:
>> > >> >
>> > >> > libstdc++-v3/ChangeLog:
>> > >> >
>> > >> > * include/std/type_traits (is_reference): Use __remove_pointer
>> built-in trait.
>> > >
>> > >
>> > > The changelog entry says is_reference but the patch is for
>> remove_pointer.
>> > >
>> > >
>> > >> >
>> > >> > ---
>> > >> > diff --git a/libstdc++-v3/include/std/type_traits
>> > >> > b/libstdc++-v3/include/std/type_traits
>> > >> > index 2bd607a8b8f..cba98091aad 100644
>> > >> > --- a/libstdc++-v3/include/std/type_traits
>> > >> > +++ b/libstdc++-v3/include/std/type_traits
>> > >> > @@ -2025,17 +2025,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> > >> >
>> > >> >template
>> > >> >  struct __remove_pointer_helper
>> > >> > -{ typedef _Tp type; };
>> > >> > +{ using type = _Tp; };
>> > >> >
>> > >> >template
>> > >> >  struct __remove_pointer_helper<_Tp, _Up*>
>> > >> > -{ typedef _Up type; };
>> > >> > +{ using type = _Up; };
>> > >
>> > >
>> > > The helper doesn't need to be defined for the case where we don't use
>> it.
>> > >
>> > >
>> > >> >
>> > >> >/// remove_pointer
>> > >> > +#if __has_builtin(__remove_pointer)
>> > >> > +  template
>> > >> > +struct remove_pointer
>> > >> > +{ using type = __remove_pointer(_Tp); };
>> > >> > +#else
>> > >> >template
>> > >> >  struct remove_pointer
>> > >> >  : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
>> > >> >  { };
>> > >> > +#endif
>> > >> >
>> > >> >template
>> > >> >  struct __add_pointer_helper
>>
>

Re: [PATCH] c++: implement __remove_pointer built-in trait

[Ken Matsui via Gcc-patches]

Please disregard this email.


On Sun, Mar 19, 2023 at 1:21 PM Ken Matsui 
wrote:

> This patch implements built-in trait for std::remove_pointer.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __remove_pointer.
> * semantics.cc (finish_trait_type): Handle CPTK_REMOVE_POINTER.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/ext/has-builtin-1.C: Test existence of __remove_pointer.
> * g++.dg/ext/remove_pointer.C: New test.
>
> ---
> diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
> index bac593c0094..985b43e0d97 100644
> --- a/gcc/cp/cp-trait.def
> +++ b/gcc/cp/cp-trait.def
> @@ -90,6 +90,7 @@ DEFTRAIT_EXPR (IS_DEDUCIBLE, "__is_deducible ", 2)
>  DEFTRAIT_TYPE (REMOVE_CV, "__remove_cv", 1)
>  DEFTRAIT_TYPE (REMOVE_REFERENCE, "__remove_reference", 1)
>  DEFTRAIT_TYPE (REMOVE_CVREF, "__remove_cvref", 1)
> +DEFTRAIT_TYPE (REMOVE_POINTER, "__remove_pointer", 1)
>  DEFTRAIT_TYPE (UNDERLYING_TYPE,  "__underlying_type", 1)
>
>  /* These traits yield a type pack, not a type, and are represented by
> diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> index 87c2e8a7111..92db1f670ac 100644
> --- a/gcc/cp/semantics.cc
> +++ b/gcc/cp/semantics.cc
> @@ -12273,6 +12273,10 @@ finish_trait_type (cp_trait_kind kind, tree
> type1, tree type2)
>if (TYPE_REF_P (type1))
>   type1 = TREE_TYPE (type1);
>return cv_unqualified (type1);
> +case CPTK_REMOVE_POINTER:
> +  if (TYPE_PTR_P (type1))
> +type1 = TREE_TYPE (type1);
> +  return type1;
>
>  #define DEFTRAIT_EXPR(CODE, NAME, ARITY) \
>  case CPTK_##CODE:
> diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
> b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
> index f343e153e56..e21e0a95509 100644
> --- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
> +++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
> @@ -146,3 +146,6 @@
>  #if !__has_builtin (__remove_cvref)
>  # error "__has_builtin (__remove_cvref) failed"
>  #endif
> +#if !__has_builtin (__remove_pointer)
> +# error "__has_builtin (__remove_pointer) failed"
> +#endif
> diff --git a/gcc/testsuite/g++.dg/ext/remove_pointer.C
> b/gcc/testsuite/g++.dg/ext/remove_pointer.C
> new file mode 100644
> index 000..7b13db93950
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/ext/remove_pointer.C
> @@ -0,0 +1,51 @@
> +// { dg-do compile { target c++11 } }
> +
> +#define SA(X) static_assert((X),#X)
> +
> +SA(__is_same(__remove_pointer(int), int));
> +SA(__is_same(__remove_pointer(int*), int));
> +SA(__is_same(__remove_pointer(int**), int*));
> +
> +SA(__is_same(__remove_pointer(const int*), const int));
> +SA(__is_same(__remove_pointer(const int**), const int*));
> +SA(__is_same(__remove_pointer(int* const), int));
> +SA(__is_same(__remove_pointer(int** const), int*));
> +SA(__is_same(__remove_pointer(int* const* const), int* const));
> +
> +SA(__is_same(__remove_pointer(volatile int*), volatile int));
> +SA(__is_same(__remove_pointer(volatile int**), volatile int*));
> +SA(__is_same(__remove_pointer(int* volatile), int));
> +SA(__is_same(__remove_pointer(int** volatile), int*));
> +SA(__is_same(__remove_pointer(int* volatile* volatile), int* volatile));
> +
> +SA(__is_same(__remove_pointer(const volatile int*), const volatile int));
> +SA(__is_same(__remove_pointer(const volatile int**), const volatile
> int*));
> +SA(__is_same(__remove_pointer(const int* volatile), const int));
> +SA(__is_same(__remove_pointer(volatile int* const), volatile int));
> +SA(__is_same(__remove_pointer(int* const volatile), int));
> +SA(__is_same(__remove_pointer(const int** volatile), const int*));
> +SA(__is_same(__remove_pointer(volatile int** const), volatile int*));
> +SA(__is_same(__remove_pointer(int** const volatile), int*));
> +SA(__is_same(__remove_pointer(int* const* const volatile), int* const));
> +SA(__is_same(__remove_pointer(int* volatile* const volatile), int*
> volatile));
> +SA(__is_same(__remove_pointer(int* const volatile* const volatile),
> int* const volatile));
> +
> +SA(__is_same(__remove_pointer(int&), int&));
> +SA(__is_same(__remove_pointer(const int&), const int&));
> +SA(__is_same(__remove_pointer(volatile int&), volatile int&));
> +SA(__is_same(__remove_pointer(const volatile int&), const volatile int&));
> +
> +SA(__is_same(__remove_pointer(int&&), int&&));
> +SA(__is_same(__remove_pointer(const int&&), const int&&));
> +SA(__is_same(__remove_pointer(volatile int&&), volatile int&&));
> +SA(__is_same(__remove_pointer(const volatile int&&), const volatile
> int&&));
> +
> +SA(__is_same(__remove_pointer(int[3]), int[3]));
> +SA(__is_same(__remove_pointer(const int[3]), const int[3]));
> +SA(__is_same(__remove_pointer(volatile int[3]), volatile int[3]));
> +SA(__is_same(__remove_pointer(const volatile int[3]), const volatile
> int[3]));
> +
> +SA(__is_same(__remove_pointer(int(int)), int(int)));
> +SA(__is_same(__remove_pointer(int(*const)(int)), int(int)));
> +SA(__is_same(__remove_pointer(int(*volatile)(int)), int(int)));
> +SA(__is_same(__remove_pointer(int(*const volatile)(int)), int(int))

[PATCH 2/2] libstdc++: use new built-in trait __remove_pointer

[Ken Matsui via Gcc-patches]

This patch lets libstdc++ use new built-in trait __remove_pointer.

libstdc++-v3/ChangeLog:

* include/std/type_traits (remove_pointer): Use __remove_pointer 
built-in trait.
---
 libstdc++-v3/include/std/type_traits | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 2bd607a8b8f..8b0db4d37bc 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -2023,19 +2023,25 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // Pointer modifications.
 
+  /// remove_pointer
+#if __has_builtin(__remove_pointer)
+  template
+struct remove_pointer
+{ using type = __remove_pointer(_Tp); };
+#else
   template
 struct __remove_pointer_helper
-{ typedef _Tp type; };
+{ using type = _Tp; };
 
   template
 struct __remove_pointer_helper<_Tp, _Up*>
-{ typedef _Up type; };
+{ using type = _Up; };
 
-  /// remove_pointer
   template
 struct remove_pointer
 : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
 { };
+#endif
 
   template
 struct __add_pointer_helper
-- 
2.40.0

[PATCH 1/2] c++: implement __remove_pointer built-in trait

[Ken Matsui via Gcc-patches]

This patch implements built-in trait for std::remove_pointer.

gcc/cp/ChangeLog:

* cp-trait.def: Define __remove_pointer.
* semantics.cc (finish_trait_type): Handle CPTK_REMOVE_POINTER.

gcc/testsuite/ChangeLog:

* g++.dg/ext/has-builtin-1.C: Test existence of __remove_pointer.
* g++.dg/ext/remove_pointer.C: New test.
---
 gcc/cp/cp-trait.def   |  1 +
 gcc/cp/semantics.cc   |  4 ++
 gcc/testsuite/g++.dg/ext/has-builtin-1.C  |  3 ++
 gcc/testsuite/g++.dg/ext/remove_pointer.C | 51 +++
 4 files changed, 59 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/remove_pointer.C

diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
index bac593c0094..985b43e0d97 100644
--- a/gcc/cp/cp-trait.def
+++ b/gcc/cp/cp-trait.def
@@ -90,6 +90,7 @@ DEFTRAIT_EXPR (IS_DEDUCIBLE, "__is_deducible ", 2)
 DEFTRAIT_TYPE (REMOVE_CV, "__remove_cv", 1)
 DEFTRAIT_TYPE (REMOVE_REFERENCE, "__remove_reference", 1)
 DEFTRAIT_TYPE (REMOVE_CVREF, "__remove_cvref", 1)
+DEFTRAIT_TYPE (REMOVE_POINTER, "__remove_pointer", 1)
 DEFTRAIT_TYPE (UNDERLYING_TYPE,  "__underlying_type", 1)
 
 /* These traits yield a type pack, not a type, and are represented by
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 87c2e8a7111..92db1f670ac 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12273,6 +12273,10 @@ finish_trait_type (cp_trait_kind kind, tree type1, 
tree type2)
   if (TYPE_REF_P (type1))
type1 = TREE_TYPE (type1);
   return cv_unqualified (type1);
+case CPTK_REMOVE_POINTER:
+  if (TYPE_PTR_P (type1))
+type1 = TREE_TYPE (type1);
+  return type1;
 
 #define DEFTRAIT_EXPR(CODE, NAME, ARITY) \
 case CPTK_##CODE:
diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C 
b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
index f343e153e56..e21e0a95509 100644
--- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
+++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
@@ -146,3 +146,6 @@
 #if !__has_builtin (__remove_cvref)
 # error "__has_builtin (__remove_cvref) failed"
 #endif
+#if !__has_builtin (__remove_pointer)
+# error "__has_builtin (__remove_pointer) failed"
+#endif
diff --git a/gcc/testsuite/g++.dg/ext/remove_pointer.C 
b/gcc/testsuite/g++.dg/ext/remove_pointer.C
new file mode 100644
index 000..7b13db93950
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/remove_pointer.C
@@ -0,0 +1,51 @@
+// { dg-do compile { target c++11 } }
+
+#define SA(X) static_assert((X),#X)
+
+SA(__is_same(__remove_pointer(int), int));
+SA(__is_same(__remove_pointer(int*), int));
+SA(__is_same(__remove_pointer(int**), int*));
+
+SA(__is_same(__remove_pointer(const int*), const int));
+SA(__is_same(__remove_pointer(const int**), const int*));
+SA(__is_same(__remove_pointer(int* const), int));
+SA(__is_same(__remove_pointer(int** const), int*));
+SA(__is_same(__remove_pointer(int* const* const), int* const));
+
+SA(__is_same(__remove_pointer(volatile int*), volatile int));
+SA(__is_same(__remove_pointer(volatile int**), volatile int*));
+SA(__is_same(__remove_pointer(int* volatile), int));
+SA(__is_same(__remove_pointer(int** volatile), int*));
+SA(__is_same(__remove_pointer(int* volatile* volatile), int* volatile));
+
+SA(__is_same(__remove_pointer(const volatile int*), const volatile int));
+SA(__is_same(__remove_pointer(const volatile int**), const volatile int*));
+SA(__is_same(__remove_pointer(const int* volatile), const int));
+SA(__is_same(__remove_pointer(volatile int* const), volatile int));
+SA(__is_same(__remove_pointer(int* const volatile), int));
+SA(__is_same(__remove_pointer(const int** volatile), const int*));
+SA(__is_same(__remove_pointer(volatile int** const), volatile int*));
+SA(__is_same(__remove_pointer(int** const volatile), int*));
+SA(__is_same(__remove_pointer(int* const* const volatile), int* const));
+SA(__is_same(__remove_pointer(int* volatile* const volatile), int* volatile));
+SA(__is_same(__remove_pointer(int* const volatile* const volatile), int* const 
volatile));
+
+SA(__is_same(__remove_pointer(int&), int&));
+SA(__is_same(__remove_pointer(const int&), const int&));
+SA(__is_same(__remove_pointer(volatile int&), volatile int&));
+SA(__is_same(__remove_pointer(const volatile int&), const volatile int&));
+
+SA(__is_same(__remove_pointer(int&&), int&&));
+SA(__is_same(__remove_pointer(const int&&), const int&&));
+SA(__is_same(__remove_pointer(volatile int&&), volatile int&&));
+SA(__is_same(__remove_pointer(const volatile int&&), const volatile int&&));
+
+SA(__is_same(__remove_pointer(int[3]), int[3]));
+SA(__is_same(__remove_pointer(const int[3]), const int[3]));
+SA(__is_same(__remove_pointer(volatile int[3]), volatile int[3]));
+SA(__is_same(__remove_pointer(const volatile int[3]), const volatile int[3]));
+
+SA(__is_same(__remove_pointer(int(int)), int(int)));
+SA(__is_same(__remove_pointer(int(*const)(int)), int(int)));
+SA(__is_same(__remove_pointer(int(*volatile)(int)), int(int)));
+SA(__is_sa

[PATCH v2] c++: further -Wdangling-reference refinement [PR107532]

[Marek Polacek via Gcc-patches]

On Sat, Mar 18, 2023 at 08:35:36AM -0400, Jason Merrill wrote:
> On 3/17/23 16:29, Marek Polacek wrote:
> > Based on ,
> > it seems like we should treat *any* class with a reference member
> > as a reference wrapper.  This simplifies the code so I'm happy to
> > make that change.
> > 
> > The patch, however, does not suppress the warning in
> > 
> >int i = 42;
> >auto const& v = std::get<0>(std::tuple(i));
> 
> Why not?  tuple has an int& member, doesn't it?  Do we need to look
> into bases as well?

Indeed.  I don't know why I didn't do it right away; it's really not that
complicated:

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
Based on ,
it seems like we should treat *any* class with a reference member
as a reference wrapper.  To suppress the warning in

  int i = 42;
  auto const& v = std::get<0>(std::tuple(i));

we have to look into base classes as well.  For std::tuple, this means
that we have to check the _Head_base subobject, which is a non-direct
base class of std::tuple.  So I've employed a DFS walk.

PR c++/107532

gcc/cp/ChangeLog:

* call.cc (class_has_reference_member_p): New.
(class_has_reference_member_p_r): New.
(reference_like_class_p): Don't look for a specific constructor.
Use a DFS walk with class_has_reference_member_p_r.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wdangling-reference11.C: New test.
* g++.dg/warn/Wdangling-reference12.C: New test.
---
 gcc/cp/call.cc| 63 +++
 .../g++.dg/warn/Wdangling-reference11.C   | 23 +++
 .../g++.dg/warn/Wdangling-reference12.C   | 12 
 3 files changed, 72 insertions(+), 26 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/warn/Wdangling-reference11.C
 create mode 100644 gcc/testsuite/g++.dg/warn/Wdangling-reference12.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index c52a09b9be2..429170e43ea 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -13783,8 +13783,31 @@ std_pair_ref_ref_p (tree t)
 
 /* Return true if a class CTYPE is either std::reference_wrapper or
std::ref_view, or a reference wrapper class.  We consider a class
-   a reference wrapper class if it has a reference member and a
-   constructor taking the same reference type.  */
+   a reference wrapper class if it has a reference member.  We no
+   longer check that it has a constructor taking the same reference type
+   since that approach still generated too many false positives.  */
+
+static bool
+class_has_reference_member_p (tree t)
+{
+  for (tree fields = TYPE_FIELDS (t);
+   fields;
+   fields = DECL_CHAIN (fields))
+if (TREE_CODE (fields) == FIELD_DECL
+   && !DECL_ARTIFICIAL (fields)
+   && TYPE_REF_P (TREE_TYPE (fields)))
+  return true;
+  return false;
+}
+
+/* A wrapper for the above suitable as a callback for dfs_walk_once.  */
+
+static tree
+class_has_reference_member_p_r (tree binfo, void *)
+{
+  return (class_has_reference_member_p (BINFO_TYPE (binfo))
+ ? integer_one_node : NULL_TREE);
+}
 
 static bool
 reference_like_class_p (tree ctype)
@@ -13800,31 +13823,19 @@ reference_like_class_p (tree ctype)
   if (decl_in_std_namespace_p (tdecl))
 {
   tree name = DECL_NAME (tdecl);
-  return (name
- && (id_equal (name, "reference_wrapper")
- || id_equal (name, "span")
- || id_equal (name, "ref_view")));
-}
-  for (tree fields = TYPE_FIELDS (ctype);
-   fields;
-   fields = DECL_CHAIN (fields))
-{
-  if (TREE_CODE (fields) != FIELD_DECL || DECL_ARTIFICIAL (fields))
-   continue;
-  tree type = TREE_TYPE (fields);
-  if (!TYPE_REF_P (type))
-   continue;
-  /* OK, the field is a reference member.  Do we have a constructor
-taking its type?  */
-  for (tree fn : ovl_range (CLASSTYPE_CONSTRUCTORS (ctype)))
-   {
- tree args = FUNCTION_FIRST_USER_PARMTYPE (fn);
- if (args
- && same_type_p (TREE_VALUE (args), type)
- && TREE_CHAIN (args) == void_list_node)
-   return true;
-   }
+  if (name
+ && (id_equal (name, "reference_wrapper")
+ || id_equal (name, "span")
+ || id_equal (name, "ref_view")))
+   return true;
 }
+
+  /* Some classes, such as std::tuple, have the reference member in its
+ (non-direct) base class.  */
+  if (dfs_walk_once (TYPE_BINFO (ctype), class_has_reference_member_p_r,
+nullptr, nullptr))
+return true;
+
   return false;
 }
 
diff --git a/gcc/testsuite/g++.dg/warn/Wdangling-reference11.C 
b/gcc/testsuite/g++.dg/warn/Wdangling-reference11.C
new file mode 100644
index 000..667618e7196
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wdangling-reference11.C
@@ -0,0 +1,23 @@
+// PR c++/107532
+// { dg-do compile { t

[PATCH] testsuite: always use UTF-8 in scan-sarif-file[-not] [PR105959]

[David Malcolm via Gcc-patches]

c-c++-common/diagnostic-format-sarif-file-4.c is a test case for
quoting non-ASCII source code in a SARIF diagnostic log.

The SARIF standard mandates that .sarif files are UTF-8 encoded.

PR testsuite/105959 notes that the test case fails when the system
encoding is not UTF-8, such as when the "make" invocation is prefixed
with LC_ALL=C, whereas it works with in a UTF-8-locale.

The root cause is that dg-scan opens the file for reading using the
"system" encoding; I believe it is falling back to treating all files as
effectively ISO 8859-1 in a non-UTF-8 locale.

This patch fixes things by adding a mechanism to dg-scan to allow
callers to (optionally) specify an encoding to use when reading the
file, and updating scan-sarif-file (and the -not variant) to always
use UTF-8 when calling dg-scan, fixing the test case with LC_ALL=C.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Manually verified the problematic testcases work with this
with both LC_ALL=C and LC_ALL=en_US.UTF-8

OK for trunk?

gcc/testsuite/ChangeLog:
PR testsuite/105959
* gcc.dg-selftests/dg-final.exp
(dg_final_directive_check_num_args): Update expected maximum
number of args for the various directives using dg-scan.
* lib/scanasm.exp (append_encoding_arg): New procedure.
(dg-scan): Add optional 3rd argument: the encoding to use when
reading from the file.
* lib/scansarif.exp (scan-sarif-file): Treat the file as UTF-8
encoded when reading it.
(scan-sarif-file-not): Likewise.

Signed-off-by: David Malcolm 
---
 gcc/testsuite/gcc.dg-selftests/dg-final.exp | 22 ++---
 gcc/testsuite/lib/scanasm.exp   | 22 +++--
 gcc/testsuite/lib/scansarif.exp | 13 +++-
 3 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/gcc/testsuite/gcc.dg-selftests/dg-final.exp 
b/gcc/testsuite/gcc.dg-selftests/dg-final.exp
index e75fb45f44a..e34f29ab13a 100644
--- a/gcc/testsuite/gcc.dg-selftests/dg-final.exp
+++ b/gcc/testsuite/gcc.dg-selftests/dg-final.exp
@@ -104,17 +104,17 @@ proc dg_final_directive_check_num_args {} {
 
 global testname_with_flags
 set testname_with_flags "test.c"
-verify_args scan-assembler 1 2
-verify_args scan-assembler-not 1 2
-verify_args scan-hidden 1 2
-verify_args scan-not-hidden 1 2
-verify_args scan-file 2 3
-verify_args scan-file-not 2 3
-verify_args scan-stack-usage 1 2
-verify_args scan-stack-usage-not 1 2
-verify_args scan-ada-spec 1 2
-verify_args scan-ada-spec-not 1 2
-verify_args scan-lto-assembler 1 2
+verify_args scan-assembler 1 3
+verify_args scan-assembler-not 1 3
+verify_args scan-hidden 1 3
+verify_args scan-not-hidden 1 3
+verify_args scan-file 2 4
+verify_args scan-file-not 2 5
+verify_args scan-stack-usage 1 3
+verify_args scan-stack-usage-not 1 3
+verify_args scan-ada-spec 1 3
+verify_args scan-ada-spec-not 1 3
+verify_args scan-lto-assembler 1 3
 unset testname_with_flags
 }
 
diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
index 4b018abcf3d..fb53544d40c 100644
--- a/gcc/testsuite/lib/scanasm.exp
+++ b/gcc/testsuite/lib/scanasm.exp
@@ -24,19 +24,33 @@ proc make_pattern_printable { pattern } {
 return [string map {\t \\t \n \\n \r \\r \\ } $pattern]
 }
 
+# Append to ARGS to make it suitable for use by dg-scan to indicate
+# that encoding ENC should be used when reading from the file.
+
+proc append_encoding_arg { args enc } {
+if { [llength $args] < 2 } {
+   # Add target selector.
+   lappend args { target "*-*-*" }
+}
+# Add encoding ENC.
+lappend args $enc
+return $args
+}
+
 # Scan the OUTPUT_FILE for a pattern.  If it is present and POSITIVE
 # is non-zero, or it is not present and POSITIVE is zero, the test
 # passes.  The ORIG_ARGS is the list of arguments provided by dg-final
 # to scan-assembler.  The first element in ORIG_ARGS is the regular
 # expression to look for in the file.  The second element, if present,
-# is a DejaGNU target selector.
+# is a DejaGNU target selector.  The third element, if present, is the
+# encoding to use when reading from the file.
 
 proc dg-scan { name positive testcase output_file orig_args } {
 if { [llength $orig_args] < 1 } {
error "$name: too few arguments"
 return
 }
-if { [llength $orig_args] > 2 } {
+if { [llength $orig_args] > 3 } {
error "$name: too many arguments"
return
 }
@@ -59,6 +73,10 @@ proc dg-scan { name positive testcase output_file orig_args 
} {
return
 }
 set fd [open $output_file r]
+if { [llength $orig_args] >= 3 } {
+   set file_encoding [lindex $orig_args 2]
+   fconfigure $fd -encoding $file_encoding
+}
 set text [read $fd]
 close $fd
 
diff --git a/gcc/testsuite/lib/scansarif.exp b/gcc/testsuite/lib/scansarif.exp
index d06390b854f..05

Re: Should -ffp-contract=off the default on GCC?

[Qing Zhao via Gcc-patches]

Hi, 


> On Mar 16, 2023, at 12:53 PM, Jakub Jelinek  wrote:
> 
> On Thu, Mar 16, 2023 at 04:38:41PM +, Qing Zhao via Gcc-patches wrote:
>>> NO. We have this debate every few years and such.
>> 
>> So, what’s the major reason we keep the default  that is not IEEE754 
>> compliant from the beginning? 
> 
> It is compliant.  fusedMultiplyAdd is a standard IEEE 754 operation,

After checking the IEEE754, IEEE standard for Floating-Point Arithmetic, 
fusedMultiplyAdd is clearly documented:

"
fusedMultiplyAdd: The operation fusedMultiplyAdd(x, y, z) computes (x×y)+z as 
if with unbounded
range and precision, rounding only once to the destination format.
"

> and
> C explicitly allows contractions.

However, I failed to locate where in C standard the fusedMultiplyAdd is allowed.

I got the draft version of C89, C99 and C11 from the following links:
• C89 – Draft version in ANSI text format: 
(https://web.archive.org/web/20161223125339/http://flash-gordon.me.uk/ansi.c.txt)
• C89 – Draft version as HTML document: 
(http://port70.net/~nsz/c/c89/c89-draft.html)
• C99 – Draft version (N1256) as HTML document: 
(http://port70.net/~nsz/c/c99/n1256.html)
• C11 – Draft version (N1570) as HTML document: 
(http://port70.net/~nsz/c/c11/n1570.html)

In both C99 and C11, I Only found the following section:

http://port70.net/%7Ensz/c/c99/n1256.html#7.12.13:


7.12.13 Floating multiply-add

7.12.13.1 The fma functions

Synopsis

1

 #include 

 double fma(double x, double y, double z);
 float fmaf(float x, float y, float z);
 long double fmal(long double x, long double y,
  long double z);

Description

2 The fma functions compute (x y) + z, rounded as one ternary operation: they 
compute the value (as if) to infinite precision and round once to the result 
format, according to the current rounding mode. A range error may occur.

Returns

3 The fma functions return (x y) + z, rounded as one ternary operation.


My question: is the above section the place in C standard “explicitly allows 
contractions”? If not, where it is in C standard?

Another question to ARM port maintainers is:

Is fmadd instruction provided by Aarch64 architecture IEEE754 compliant? 

Thanks a lot for your help.

Qing


> 
>   Jakub
> 

Re: Ping (gcc/configure.ac, docs): [PATCH v2 4/5] Update texinfo.tex, remove the @gol macro/alias

[Sandra Loosemore]

On 3/18/23 14:14, Arsen Arsenović via Gcc-patches wrote:

Evening,

Ping on this patch series.

I believe we're close to being able to apply it, with contents of the
documentation changes being approved, and only a small build system
change and a revised patch series "shape" left to review.


Yup.  I think you can go ahead and commit everything but the part with 
the configure/makefile hackery, which still needs somebody other than me 
to approve it.



The former change of these two is in:
https://inbox.sourceware.org/gcc-patches/20230311203234.2257423-1-ar...@aarsen.me/
The patch adds a test for the presence of CONTENTS_OUTPUT_LOCATION into
the build system in order to avoid shortcontents coming after contents
in HTML output.  We've also updated Texinfo to output shortcontents
before contents by default as a result of the discussion here, though
that will only happen in newer versions.

The latter "shape" is a git log documented at:
https://inbox.sourceware.org/gcc-patches/87ttysppsc@aarsen.me/

As always, I've freshly rebased the patch series at

   https://git.sr.ht/~arsen/gcc texinfo_improvements

... or, in (git)web form, at:

   https://git.sr.ht/~arsen/gcc/log/texinfo_improvements

... with the render at:

   https://www.aarsen.me/~arsen/final/

Thank you all in advance, have a lovely day.


Joseph, could you maybe review the last piece?  A direct pointer to it 
in Arsen's git is


https://git.sr.ht/~arsen/gcc/commit/bc734311cbca1085a1728f79b7eebef8cc7aeac3

-Sandra

Re: [PATCH] Fortran: fix documentation of -fno-underscoring [PR109216]

[Sandra Loosemore]

On 3/20/23 14:05, Harald Anlauf via Gcc-patches wrote:

Dear all,

as reported, the implicit documentation of -funderscoring, which
is found under -fno-underscoring, has gone sideways long time ago.
The attached patch should fix it.

OK for mainline, or did I miss something?


This is OK.

-Sandra

Re: [patch, fortran, doc] Explicitly mention undefined overflow

[Harald Anlauf via Gcc-patches]

Hi Thomas,

Am 20.03.23 um 08:14 schrieb Thomas Koenig via Gcc-patches:

so it the general problem is not restricted to -O3 and not
to current trunk, it depends on the details.

I doubt that the result from 9.4.0 was expected, but rather
nobody noticed.  Or, bringing out the pseudo-RNG into a
different setting changed things.

So... any suggestions on how to improve the current wording?


how about changing:

"... relying on a specific, non-standard behavior may now generate 
unexpected results."


to

"... relying on a specific, non-standard behavior may generate 
unexpected results depending on optimization level and other compiler 
flags."


We cannot know all the codes used in the wild ...

Cheers,
Harald


Best regards

 Thomas

[PATCH] Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036]

[Harald Anlauf via Gcc-patches]

Dear all,

the attached trivial patch catches a MODULE PROCEDURE outside of a
module interface before we run into an internal error.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

This PR is marked as an 11/12/13 regression, so this is a candidate
for backporting.

Thanks,
Harald

From 9c59709fad91c99041a9cb770b98da17af01d260 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Mon, 20 Mar 2023 21:50:59 +0100
Subject: [PATCH] Fortran: reject MODULE PROCEDURE outside generic module
 interface [PR99036]

gcc/fortran/ChangeLog:

	PR fortran/99036
	* decl.cc (gfc_match_modproc): Reject MODULE PROCEDURE if not in a
	generic module interface.

gcc/testsuite/ChangeLog:

	PR fortran/99036
	* gfortran.dg/pr99036.f90: New test.
---
 gcc/fortran/decl.cc   | 1 +
 gcc/testsuite/gfortran.dg/pr99036.f90 | 9 +
 2 files changed, 10 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/pr99036.f90

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index c8f0bb83c2c..b29f491fe1f 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -9998,6 +9998,7 @@ gfc_match_modproc (void)
   if ((gfc_state_stack->state != COMP_INTERFACE
&& gfc_state_stack->state != COMP_CONTAINS)
   || gfc_state_stack->previous == NULL
+  || !current_interface.type
   || current_interface.type == INTERFACE_NAMELESS
   || current_interface.type == INTERFACE_ABSTRACT)
 {
diff --git a/gcc/testsuite/gfortran.dg/pr99036.f90 b/gcc/testsuite/gfortran.dg/pr99036.f90
new file mode 100644
index 000..a6e396f6f71
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr99036.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/99036 - ICE in gfc_current_interface_head
+! Contributed by G. Steinmetz
+
+module m
+contains
+  module procedure s ! { dg-error "must be in a generic module interface" }
+  end
+end
--
2.35.3

Re: [PATCH V4] Rework 128-bit complex multiply and divide.

[Michael Meissner via Gcc-patches]

On Mon, Mar 20, 2023 at 01:43:41PM -0400, Michael Meissner wrote:
> I think we will need backports for GCC 12.  The issue exists in GCC 11, but I
> don't think that GCC 11 can really work on systems with IEEE long double, 
> since
> a lot of the stuff to really finish up the support was not in GCC 11.  I think
> I tried dropping the patch into GCC 12, and it looks like something else may 
> be
> needed.  I will look into it.

The current patch applies to GCC 12 without changes, and it does fix the
problem.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Ken Matsui via Gcc-patches]

Thank you so much for taking the benchmark! This is a great improvement
than I thought.

In GCC contributions, do I need to benchmark (and report) every built-in
trait I implement?

On Mon, Mar 20, 2023 at 8:24 AM Patrick Palka  wrote:

> On Mon, Mar 20, 2023 at 5:56 AM Ken Matsui 
> wrote:
> >
> > > Does it actually make compilation faster though?
> > >
> > > Has it been measured?
> >
> > In my understanding, what I have implemented so far is so simple that
> > it does not affect the speed. These traits are what Partick kindly
> > recommended to get started. As explained on the GSoC page, some traits
> > might involve expensive instantiation of multiple class templates. So
> > IMHO, implementing built-in traits for those traits can make
> > compilation cheaper.
> >
> > I have not measured it, but Patrick might have done?
>
> Although the native implementation of using two partial
> specializations is very efficient, I'd suspect using a built-in would
> be even better because it'd avoid the work of having to figure out
> which of the two partial specializations to instantiate.
>
> I contrived the attached benchmark to measure this, which instantiates
> ~160k specializations of is_reference_v (it was simpler to write a
> benchmark for the variable template version). On my machine gcc trunk
> (release build) as well as Clang 15 use between 10-15% less
> time/memory with -DUSE_BUILTIN than without for this benchmark, so
> this suggests the built-in improves compile time/memory usage for this
> trait by at least 10-15%.  For more complicated traits the improvement
> should be even better.
>
> >
> > On Mon, Mar 20, 2023 at 2:14 AM Jonathan Wakely 
> wrote:
> > >
> > > On Mon, 20 Mar 2023 at 08:08, Xi Ruoyao via Libstdc++
> > >  wrote:
> > > >
> > > > On Mon, 2023-03-20 at 01:03 -0700, Ken Matsui wrote:
> > > > > Oops, I assumed those were my email... Thank you for your heads up
> and
> > > > > your comments!
> > > > >
> > > > > > Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces,
> nor
> > > > > > nothing) to indent the ChangeLog content.
> > > > >
> > > > > Do you mean like the following?
> > > > >
> > > > > ```
> > > > > libstdc++-v3/ChangeLog:
> > > > >
> > > > > [TAB]* include/std/type_traits (is_reference): Use __is_reference
> > > > > built-in
> > > > > trait.
> > > > > ```
> > > >
> > > > Yep.
> > > >
> > > > > > Is there any benefit to use a builtin, instead of the existing
> > > > > > implementation?  I can see no but maybe I'm stupid.
> > > > >
> > > > > My patches are based on the GSoC project "C++: Implement compiler
> > > > > built-in traits for the standard library traits". These built-in
> > > > > traits basically make the compilation faster.
> > > > >
> > > > > https://gcc.gnu.org/wiki/SummerOfCode
> > > >
> > > > Ok, to me making compilation faster is a valid reason.
> > >
> > > Does it actually make compilation faster though?
> > >
> > > Has it been measured?
> > >
> > > > > > The patch fails to apply.  It seems because your mail client
> inserted an
> > > > > > additional newline before "b/".  Try to use git-send-email or
> configure
> > > > > > the mail client properly.
> > > > >
> > > > > Let me try to use git-send-email instead. I stupidly don't
> understand
> > > > > how to use them, so I was making my patches manually...
> > > >
> > > > Or adjust the mail client correctly.  You can send the patch to
> yourself
> > > > first and see if it's not "mangled" by the mail client when you debug
> > > > such an issue...
> > > >
> > > > But when you finally end up sending 10 patches in a series you'll
> find
> > > > git send-email much easier :).
> > >
> > > Figuring out how to generate proper patches is an important part of
> > > contributing to GCC, so part of any GSoC project.
> >
>

[PATCH] Fortran: fix documentation of -fno-underscoring [PR109216]

[Harald Anlauf via Gcc-patches]

Dear all,

as reported, the implicit documentation of -funderscoring, which
is found under -fno-underscoring, has gone sideways long time ago.
The attached patch should fix it.

OK for mainline, or did I miss something?

Thanks,
Harald

From c296196044248f974b4907bb2f5bdeeea24adb5b Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Mon, 20 Mar 2023 20:55:00 +0100
Subject: [PATCH] Fortran: fix documentation of -fno-underscoring [PR109216]

gcc/fortran/ChangeLog:

	PR fortran/109216
	* invoke.texi: Correct documentation of how underscores are appended
	to external names.
---
 gcc/fortran/invoke.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 5679e2f2650..cbe7f377507 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1573,7 +1573,7 @@ Do not transform names of entities specified in the Fortran
 source file by appending underscores to them.

 With @option{-funderscoring} in effect, GNU Fortran appends one
-underscore to external names with no underscores.  This is done to ensure
+underscore to external names.  This is done to ensure
 compatibility with code produced by many UNIX Fortran compilers.

 @emph{Caution}: The default behavior of GNU Fortran is
@@ -1596,7 +1596,7 @@ I = J() + MAX_COUNT (MY_VAR, LVAR)
 @noindent
 is implemented as something akin to:
 @smallexample
-i = j_() + max_count__(&my_var__, &lvar);
+i = j_() + max_count_(&my_var, &lvar);
 @end smallexample

 With @option{-fno-underscoring}, the same statement is implemented as:
--
2.35.3

stor-layout: Set TYPE_TYPELESS_STORAGE consistently for type variants

[Joseph Myers]

I've observed an LTO wrong-code bug with a large testcase in GCC 12,
that results from TYPE_TYPELESS_STORAGE not being set consistently on
type variants.

Specifically, in the LTO stage of compilation, there is an aggregate
type passed to get_alias_set, whose TYPE_MAIN_VARIANT does not have
TYPE_TYPELESS_STORAGE set.  However, the TYPE_CANONICAL of that main
variant *does* have have TYPE_TYPELESS_STORAGE set; note that the use
of TYPE_CANONICAL in get_alias_set comes after the check of
TYPE_TYPELESS_STORAGE.  The effect is that when (one-argument)
record_component_aliases is called, the recursive call to
get_alias_set gives alias set 0, and the aggregate type ends up not
being considered to alias its members, with wrong-code consequences.

I haven't managed to produce a self-contained executable testcase to
demonstrate this, but it clearly seems appropriate for
TYPE_TYPELESS_STORAGE to be consistent on type variants, so this patch
makes it so, which appears to be sufficient to resolve the bug.  I've
attached a reduced test that does at least demonstrate main-variant
versions of a type (SB in this test) being written out to LTO IR both
with and without TYPE_TYPELESS_STORAGE, although not the subsequent
consequences of a type without TYPE_TYPELESS_STORAGE with a
TYPE_CANONICAL (as constructed after LTO type merging) with
TYPE_TYPELESS_STORAGE and following wrong-code.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.  OK to commit?

* stor-layout.cc (finalize_type_size): Copy TYPE_TYPELESS_STORAGE
to variants.

diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
index 45bf2d18639..023de8c37db 100644
--- a/gcc/stor-layout.cc
+++ b/gcc/stor-layout.cc
@@ -1996,6 +1996,7 @@ finalize_type_size (tree type)
   unsigned int user_align = TYPE_USER_ALIGN (type);
   machine_mode mode = TYPE_MODE (type);
   bool empty_p = TYPE_EMPTY_P (type);
+  bool typeless = AGGREGATE_TYPE_P (type) && TYPE_TYPELESS_STORAGE (type);
 
   /* Copy it into all variants.  */
   for (variant = TYPE_MAIN_VARIANT (type);
@@ -2020,6 +2021,8 @@ finalize_type_size (tree type)
  TYPE_PRECISION (variant) = precision;
  SET_TYPE_MODE (variant, mode);
  TYPE_EMPTY_P (variant) = empty_p;
+ if (AGGREGATE_TYPE_P (variant))
+   TYPE_TYPELESS_STORAGE (variant) = typeless;
}
 }
 }

-- 
Joseph S. Myers
jos...@codesourcery.comstruct S {
  int a;
  char b[8];
};
template  class SB {
public:
  operator bool() { return true; };
  S x;
};
class T : public SB<0> {};
template  class m1 {
public:
  m1(TT) {}
  void m2() {};
};
class U {
public:
  U(int, T c) {
auto v = m1([] {});
if (c)
  v.m2();
  }
};
void f() {
  T c = {};
  U(0, c);
}

Add notes for Go to gcc 12 and 13 changes file

[Ian Lance Taylor via Gcc-patches]

I committed this patch to the gcc-wwwdocs repo to add some notes about
Go to the gcc 12 and 13 changes file.

Ian

pat
e24f9ef56c11c69fc07bddf9a708ea2fc662f2b3
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index c47d3285..d565c217 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -618,7 +618,14 @@ function Multiply (S1, S2 : Sign) return Sign is
   
 
 
-
+Go
+
+
+  GCC 12 provides a complete implementation of the Go 1.18 user
+packages.
+  Although Go 1.18 includes support for generic programming, that
+support is not yet available in GCC.
+
 
 
 libgccjit
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index a4b71ffa..4fae1f7a 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -380,7 +380,14 @@ a work-in-progress.
   
 
 
-
+Go
+
+
+  GCC 13, like GCC 12, provides a complete implementation of the
+Go 1.18 user packages.
+  Although Go 1.18 includes support for generic programming, that
+support is not yet available in GCC.
+
 
 Modula-2
 

Re: [PATCH] c++, v2: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

[Jason Merrill via Gcc-patches]

On 3/20/23 15:26, Jakub Jelinek wrote:

On Mon, Mar 20, 2023 at 03:15:32PM -0400, Jason Merrill wrote:

+  else if (VAR_P (decl)
+  && CP_DECL_THREAD_LOCAL_P (decl)
+  && (!DECL_EXTERNAL (decl) || flag_extern_tls_init)


Hmm, I wonder why we don't check the above line in var_needs_tls_wrapper?


It is tested in get_tls_init_fn (one of the 2 previous callers of
var_needs_tls_wrapper).  No idea why it isn't in get_tls_wrapper_fn (the
other caller of it).


I suppose because we might see a definition of the variable later on, 
and we don't want to have previously decided to omit the wrapper because 
we hadn't seen it yet.


Jason

Re: [PATCH] c++, v2: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

[Jakub Jelinek via Gcc-patches]

On Mon, Mar 20, 2023 at 03:15:32PM -0400, Jason Merrill wrote:
> > +  else if (VAR_P (decl)
> > +  && CP_DECL_THREAD_LOCAL_P (decl)
> > +  && (!DECL_EXTERNAL (decl) || flag_extern_tls_init)
> 
> Hmm, I wonder why we don't check the above line in var_needs_tls_wrapper?

It is tested in get_tls_init_fn (one of the 2 previous callers of
var_needs_tls_wrapper).  No idea why it isn't in get_tls_wrapper_fn (the
other caller of it).

Jakub

Re: [PATCH] c++, v2: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

[Jason Merrill via Gcc-patches]

On 3/18/23 11:09, Jakub Jelinek wrote:

On Sat, Mar 18, 2023 at 01:54:58PM +0100, Jakub Jelinek via Gcc-patches wrote:

The patch is mostly about DECL_EXTERNAL cases, the others are supposedly
handled by the var_definition_p code there (or at least I assumed;
testcases certainly test only DECL_EXTERNAL).
I guess it could be done in cp_finish_decl, maybe better next to the
   /* A reference will be modified here, as it is initialized.  */
   if (! DECL_EXTERNAL (decl)
   && TREE_READONLY (decl)
   && TYPE_REF_P (type))
 {
   was_readonly = 1;
   TREE_READONLY (decl) = 0;
 }
spot, but we'd need to export the decl2.cc helpers for it,
because not all DECL_THREAD_LOCAL_P vars need to be treated that way.
   if (VAR_P (decl)
   && CP_DECL_THREAD_LOCAL_P (decl)
   && var_needs_tls_wrapper (decl)
   && (!DECL_EXTERNAL (decl) || flag_extern_tls_init))
 TREE_READONLY (decl) = 0;
where var_needs_tls_wrapper would need to be exported from decl2.cc.
Though, var_needs_tls_wrapper -> var_defined_without_dynamic_init
needs
DECL_NONTRIVIALLY_INITIALIZED_P/DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P,
so perhaps that is accurate only closer to the end of cp_finish_decl?


Here it is in patch form, tested so far on tls.exp:

2023-03-18  Jakub Jelinek  

PR c++/109164
* cp-tree.h (var_needs_tls_wrapper): Declare.
* decl2.cc (var_needs_tls_wrapper): No longer static.
* decl.cc (cp_finish_decl): Clear TREE_READONLY on TLS variables
for which a TLS wrapper will be needed.

* g++.dg/tls/thread_local13.C: New test.
* g++.dg/tls/thread_local13-aux.cc: New file.
* g++.dg/tls/thread_local14.C: New test.
* g++.dg/tls/thread_local14-aux.cc: New file.

--- gcc/cp/cp-tree.h.jj 2023-03-17 08:37:07.542937058 +0100
+++ gcc/cp/cp-tree.h2023-03-18 16:02:46.771230806 +0100
@@ -6989,6 +6989,7 @@ extern void copy_linkage  (tree, tree);
  extern tree get_guard (tree);
  extern tree get_guard_cond(tree, bool);
  extern tree set_guard (tree);
+extern bool var_needs_tls_wrapper  (tree);
  extern tree maybe_get_tls_wrapper_call(tree);
  extern void mark_needed   (tree);
  extern bool decl_needed_p (tree);
--- gcc/cp/decl2.cc.jj  2023-03-17 16:09:01.749244271 +0100
+++ gcc/cp/decl2.cc 2023-03-18 15:48:31.340642324 +0100
@@ -3623,7 +3623,7 @@ var_defined_without_dynamic_init (tree v
  /* Returns true iff VAR is a variable that needs uses to be
 wrapped for possible dynamic initialization.  */
  
-static bool

+bool
  var_needs_tls_wrapper (tree var)
  {
return (!error_operand_p (var)
--- gcc/cp/decl.cc.jj   2023-03-18 15:47:32.198500421 +0100
+++ gcc/cp/decl.cc  2023-03-18 16:00:04.565584266 +0100
@@ -8706,6 +8706,18 @@ cp_finish_decl (tree decl, tree init, bo
  if (!decl_maybe_constant_destruction (decl, type))
TREE_READONLY (decl) = 0;
}
+  else if (VAR_P (decl)
+  && CP_DECL_THREAD_LOCAL_P (decl)
+  && (!DECL_EXTERNAL (decl) || flag_extern_tls_init)


Hmm, I wonder why we don't check the above line in var_needs_tls_wrapper?

But the patch is OK.


+  && (was_readonly || TREE_READONLY (decl))
+  && var_needs_tls_wrapper (decl))
+   {
+ /* TLS variables need dynamic initialization by the TLS wrapper
+function, we don't want to hoist accesses to it before the
+wrapper.  */
+ was_readonly = 0;
+ TREE_READONLY (decl) = 0;
+   }
  
make_rtl_for_nonlocal_decl (decl, init, asmspec);
  
--- gcc/testsuite/g++.dg/tls/thread_local13.C.jj	2023-03-18 15:47:50.934228583 +0100

+++ gcc/testsuite/g++.dg/tls/thread_local13.C   2023-03-18 15:47:50.934228583 
+0100
@@ -0,0 +1,21 @@
+// PR c++/109164
+// { dg-do run { target c++11 } }
+// { dg-options "-O2" }
+// { dg-add-options tls }
+// { dg-require-effective-target tls_runtime }
+// { dg-additional-sources "thread_local13-aux.cc" }
+
+struct S { virtual void foo (); int s; };
+extern thread_local S &t;
+bool bar ();
+
+bool
+baz ()
+{
+  while (1)
+{
+  t.foo ();
+  if (!bar ())
+return false;
+}
+}
--- gcc/testsuite/g++.dg/tls/thread_local13-aux.cc.jj   2023-03-18 
15:47:50.934228583 +0100
+++ gcc/testsuite/g++.dg/tls/thread_local13-aux.cc  2023-03-18 
15:47:50.934228583 +0100
@@ -0,0 +1,35 @@
+// PR c++/109164
+
+struct S { virtual void foo (); int s; };
+extern bool baz ();
+
+void
+S::foo ()
+{
+  if (s != 42)
+__builtin_abort ();
+}
+
+S s;
+
+S &
+qux ()
+{
+  s.s = 42;
+  return s;
+}
+
+thread_local S &t = qux ();
+
+bool
+bar ()
+{
+  return false;
+}
+
+int
+main ()
+{
+  if (baz ())
+__builtin_abort ();
+}
--- gcc/testsuite/g++.dg/tls/thread_local14.C.jj2023-03-18 
15:47:50.934228583 +0100
+++ gcc/testsuite/g++.dg/tls/thread_local14.C  

Re: [PATCH] c++: explicit ctor and list-initialization [PR109159]

[Jason Merrill via Gcc-patches]

On 3/20/23 11:55, Marek Polacek wrote:

When I implemented explicit(bool) in r9-3735, I added this code to
add_template_candidate_real:
+  /* Now the explicit specifier might have been deduced; check if this
+ declaration is explicit.  If it is and we're ignoring non-converting
+ constructors, don't add this function to the set of candidates.  */
+  if ((flags & LOOKUP_ONLYCONVERTING) && DECL_NONCONVERTING_P (fn))
+return NULL;
but as this test demonstrates, that's incorrect when we're initializing
from a {}: for list-initialization we consider explicit constructors and
complain if one is chosen.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12?


OK.


PR c++/109159

gcc/cp/ChangeLog:

* call.cc (add_template_candidate_real): Add explicit decls to the
set of candidates when the initializer is a braced-init-list.

libstdc++-v3/ChangeLog:

* testsuite/20_util/pair/cons/explicit_construct.cc: Adjust dg-error.
* testsuite/20_util/tuple/cons/explicit_construct.cc: Likewise.
* testsuite/23_containers/span/explicit.cc: Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/explicit16.C: New test.
---
  gcc/cp/call.cc|  4 +-
  gcc/testsuite/g++.dg/cpp0x/explicit16.C   | 18 ++
  .../20_util/pair/cons/explicit_construct.cc   | 10 ++--
  .../20_util/tuple/cons/explicit_construct.cc  | 58 +--
  .../testsuite/23_containers/span/explicit.cc  |  4 +-
  5 files changed, 57 insertions(+), 37 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit16.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index c01e7b82457..c52a09b9be2 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -3612,7 +3612,9 @@ add_template_candidate_real (struct z_candidate 
**candidates, tree tmpl,
/* Now the explicit specifier might have been deduced; check if this
   declaration is explicit.  If it is and we're ignoring non-converting
   constructors, don't add this function to the set of candidates.  */
-  if ((flags & LOOKUP_ONLYCONVERTING) && DECL_NONCONVERTING_P (fn))
+  if (((flags & (LOOKUP_ONLYCONVERTING|LOOKUP_LIST_INIT_CTOR))
+   == LOOKUP_ONLYCONVERTING)
+  && DECL_NONCONVERTING_P (fn))
  return NULL;
  
if (DECL_CONSTRUCTOR_P (fn) && nargs == 2)

diff --git a/gcc/testsuite/g++.dg/cpp0x/explicit16.C 
b/gcc/testsuite/g++.dg/cpp0x/explicit16.C
new file mode 100644
index 000..bb5a823aee6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/explicit16.C
@@ -0,0 +1,18 @@
+// PR c++/109159
+// { dg-do compile { target c++11 } }
+
+struct A {
+  A(float) {}
+  template
+  explicit A(U) {}
+};
+
+void f(A t)
+{
+  t = {1}; // { dg-error "explicit constructor" }
+  t = 1;
+  A a1{1};
+  A a2 = {1}; // { dg-error "explicit constructor" }
+  A a3 = 1;
+  A a4(1);
+}
diff --git a/libstdc++-v3/testsuite/20_util/pair/cons/explicit_construct.cc 
b/libstdc++-v3/testsuite/20_util/pair/cons/explicit_construct.cc
index e875f0cbcd2..d550e9c604b 100644
--- a/libstdc++-v3/testsuite/20_util/pair/cons/explicit_construct.cc
+++ b/libstdc++-v3/testsuite/20_util/pair/cons/explicit_construct.cc
@@ -37,7 +37,7 @@ struct ExplicitDefaultDefault
  
  std::pair f1() {return {1,2};}
  
-std::pair f2() {return {1,2};} // { dg-error "could not convert" }

+std::pair f2() {return {1,2};} // { dg-error "explicit 
constructor" }
  
  std::pair f3() {return std::pair{1,2};}
  
@@ -52,7 +52,7 @@ std::pair v0{1,2};
  
  std::pair v1{1,2};
  
-std::pair v2 = {1,2}; // { dg-error "could not convert" }

+std::pair v2 = {1,2}; // { dg-error "explicit constructor" 
}
  
  std::pair v3{std::pair{1,2}};
  
@@ -99,7 +99,7 @@ void test_arg_passing()

  {
f6(v0); // { dg-error "could not convert" }
f6(v1);
-  f6({1,2}); // { dg-error "could not convert" }
+  f6({1,2}); // { dg-error "explicit constructor" }
f6(std::pair{});
f6(std::pair{}); // { dg-error "could not convert" }
f7(v0);
@@ -130,6 +130,6 @@ std::pair v14{nullptr, MoveOnly{}};
  std::pair v15{MoveOnly{}, nullptr};
  
  std::pair v16 =

-  {nullptr, MoveOnly{}}; // { dg-error "could not convert" }
+  {nullptr, MoveOnly{}}; // { dg-error "explicit constructor" }
  std::pair v17 =
-  {MoveOnly{}, nullptr}; // { dg-error "could not convert" }
+  {MoveOnly{}, nullptr}; // { dg-error "explicit constructor" }
diff --git a/libstdc++-v3/testsuite/20_util/tuple/cons/explicit_construct.cc 
b/libstdc++-v3/testsuite/20_util/tuple/cons/explicit_construct.cc
index 820ddef30b4..3352dd15f7d 100644
--- a/libstdc++-v3/testsuite/20_util/tuple/cons/explicit_construct.cc
+++ b/libstdc++-v3/testsuite/20_util/tuple/cons/explicit_construct.cc
@@ -45,11 +45,11 @@ std::tuple f1b() {return {1,2};}
  std::tuple f1c() {return {1,2,3};}
  
  std::tuple f2_a()

-{return {1};} // { dg-error "could not convert" }
+{return {1};} // { dg-error "explicit constructor" }
  std::tuple f2_b()
-{return {1,2};} // { dg-error "could not convert" }
+{return {1,2};} // { dg-err

Re: [PATCH] fix for __sanitizer_struct_mallinfo with mallinfo2

[Andrew Pinski via Gcc-patches]

On Sun, Mar 19, 2023 at 11:08 PM Reini Urban via Gcc-patches
 wrote:
>
> Fix sanititzers with mallinfo2
> e.g fedora already uses mallinfo2 with long v[10];

Parts of these patches should go upstream first.

Thanks,
Andrew

>
> --
> Reini Urban

Re: [PATCH] libstdc++: Fix handling of surrogate CP in codecvt [PR108976]

[Dimitrij Mijoski via Gcc-patches]

On Mon, 2023-03-20 at 15:21 +, Jonathan Wakely wrote:
> 
> Thanks, the patch looks OK to my uninformed eye, but I'm seeing a new
> regression:
> 
> /home/jwakely/src/gcc/gcc/libstdc++-
> v3/testsuite/22_locale/codecvt/codecvt_utf16/79980.cc:86: void
> test06(): Assertion 'result == u"from_bytes failed"' failed.
> FAIL: 22_locale/codecvt/codecvt_utf16/79980.cc execution test

Most likely this regression appears because the change related to the
case when odd number of bytes are given to std::codecvt_utf16::in().
The old test 79980.cc:86: void test06() is probably wrong and it should
be changed.


> Also, I see that libc++ fails some of your new tests the same way as
> current libstdc++ does:
> 
> unicode: /home/jwakely/src/gcc/gcc/libstdc++-
> v3/testsuite/22_locale/codecvt/codecvt_unicode.h:298: void
> utf8_to_utf32_in_error(const std::codecvt mbstate_t> &) [InternT = char32_t, ExternT = char]: Assertion `res ==
> cvt.error' failed.
> Aborted (core dumped)
> 
> Does that mean they have the same problem? Or is the test wrong? Or
> is your patch implementing something that contradicts the
> requirements of the standard? I think it's that libc++ has the same
> handling of surrogates, but I'd like to be sure that's right.

See bug https://github.com/llvm/llvm-project/issues/60177 . It can be
reproduced with the testsuite codecvt_unicode without this patch, it is
not related to surrogates. GCC had that bug too but I already fixed it
with my previous big patch on the codecvts.

Re: [PATCH V4] Rework 128-bit complex multiply and divide.

[Michael Meissner via Gcc-patches]

On Fri, Mar 17, 2023 at 02:35:16PM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Mar 09, 2023 at 08:40:36PM -0500, Michael Meissner wrote:
> > PR target/109067
> > * config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
> > (init_float128_ieee): Delete code to switch complex multiply and divide
> > for long double.
> > (complex_multiply_builtin_code): New helper function.
> > (complex_divide_builtin_code): Likewise.
> > (rs6000_mangle_decl_assembler_name): Add support for mangling the name
> > of complex 128-bit multiply and divide built-in functions.
> 
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/divic3-1.c
> > +/* { dg-final { scan-assembler "__divtc3" } } */
> 
> /* { dg-final { scan-assembler {\m__divtc3\M} } } */
> 
> It might well be that we can use a sloppier regexp here, but why would
> we do that?  It is a good thing to use the \m and \M constraint escapes
> pretty much always.

The last time I posted the patch, you said:

| > +/* { dg-final { scan-assembler "bl __divtc3" } } */
|
| This name depends on what object format and ABI is in use (some have an
| extra leading underscore, or a dot, or whatever).

So the patch was an attempt to match the other cases.

> Similar for the other three testcases of course.
> 
> This patch is okay for trunk, if you have tested it on all
> configurations (powerpc-linux, powerpc64-linux, powerpc64le-linux with
> and without default IEEE128 long double at least).  Thank you!
> 
> Does this need backports?

I think we will need backports for GCC 12.  The issue exists in GCC 11, but I
don't think that GCC 11 can really work on systems with IEEE long double, since
a lot of the stuff to really finish up the support was not in GCC 11.  I think
I tried dropping the patch into GCC 12, and it looks like something else may be
needed.  I will look into it.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com

Re: [PATCH] range-op-float: Fix up -ffinite-math-only range extension and don't extend into infinities [PR109008]

[Jakub Jelinek via Gcc-patches]

On Mon, Mar 13, 2023 at 09:41:47AM +0100, Aldy Hernandez wrote:
> On 3/13/23 09:06, Jakub Jelinek wrote:
> > On Mon, Mar 13, 2023 at 08:59:15AM +0100, Aldy Hernandez wrote:
> > > > Yes, sure - I just noticed that we're forced to use high-level API for
> > > > something that's quite low-level and should be internal (a range
> > > > "breaking" internal consistency checks).
> > > 
> > > Yeah, let's fix the API.  No sense hacking around things if what we need 
> > > is
> > > to tweak the design.
> > > 
> > > I don't like hacking around things.  It always comes back to bite me ;-).
> > 
> > Sure.  The current state is that I think the actual bugs are fixed except
> > for the !MODE_HAS_INFINITIES case which people rarely use, so fixing up the
> > API can wait even to next release.
> > 
> > For !MODE_HAS_INFINITIES, I wonder if the best fix wouldn't be to change
> > set and a few other spots, so that if the boundaries are
> > real_min_representable/real_max_representable, we widen them to -inf and inf
> > and change frange_val_min/max to also be dconstninf/dconstinf for
> > !MODE_HAS_INFINITIES, because the min/max for that case (probably) really 
> > work as
> > infinities.  Whenever we actually round that value to mode, it will become
> > real_min_representable/real_max_representable again.
> > But that can also wait a week.
> 
> That sounds very reasonable.  It would remove special casing and would make
> the code easier to read.  For that matter, that was what I had in the
> original implementation.

I think we don't want to remove the special casing for -ffinite-math-only
on types which do support infinities.
Thinking further on it, perhaps for !MODE_HAS_INFINITIES a better fix would
be to do something like the patch below.
Consider say having a range of VAX float type:
#define M0 -FLT_MAX
#define M1 nextafterf (F0, FLT_MAX)
#define M2 nextafterf (M1, FLT_MAX)
[M2, M2] - [M0, M1]
Or perhaps if one or both of the operands are in such a case a min and max,
perform real_arithmetic recurse on the argument replaced with
dconstninf/dconstinf and then depending on inf pick the mininum or maximum
of the two results (and carefully think about what to do if both operands
are min/max).

2023-03-20  Jakub Jelinek  

* range-op-float.cc (frange_arithmetic): For !MODE_HAS_INFINITIES
types, pretend operands with minimum or maximum values are actually
infinities.

--- gcc/range-op-float.cc.jj2023-03-10 12:40:19.673108938 +0100
+++ gcc/range-op-float.cc   2023-03-20 16:58:36.604981486 +0100
@@ -313,8 +313,26 @@ frange_arithmetic (enum tree_code code,
   REAL_VALUE_TYPE value;
   enum machine_mode mode = TYPE_MODE (type);
   bool mode_composite = MODE_COMPOSITE_P (mode);
+  const REAL_VALUE_TYPE *pop1 = &op1;
+  const REAL_VALUE_TYPE *pop2 = &op2;
 
-  bool inexact = real_arithmetic (&value, code, &op1, &op2);
+  if (!MODE_HAS_INFINITIES (mode))
+{
+  // If mode doesn't have infinities, the minimum and maximum
+  // values are saturating.  Pretend for real_arithmetic such
+  // values are actual infinities.  real_convert will then
+  // canonicalize the result not to be an infinity.
+  if (frange_val_is_min (op1, type))
+   pop1 = &dconstninf;
+  else if (frange_val_is_max (op1, type))
+   pop1 = &dconstinf;
+  if (frange_val_is_min (op2, type))
+   pop2 = &dconstninf;
+  else if (frange_val_is_max (op2, type))
+   pop2 = &dconstinf;
+}
+
+  bool inexact = real_arithmetic (&value, code, pop1, pop2);
   real_convert (&result, mode, &value);
 
   // Be extra careful if there may be discrepancies between the


Jakub

[PATCH] c++: explicit ctor and list-initialization [PR109159]

[Marek Polacek via Gcc-patches]

When I implemented explicit(bool) in r9-3735, I added this code to
add_template_candidate_real:
+  /* Now the explicit specifier might have been deduced; check if this
+ declaration is explicit.  If it is and we're ignoring non-converting
+ constructors, don't add this function to the set of candidates.  */
+  if ((flags & LOOKUP_ONLYCONVERTING) && DECL_NONCONVERTING_P (fn))
+return NULL;
but as this test demonstrates, that's incorrect when we're initializing
from a {}: for list-initialization we consider explicit constructors and
complain if one is chosen.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/12?

PR c++/109159

gcc/cp/ChangeLog:

* call.cc (add_template_candidate_real): Add explicit decls to the
set of candidates when the initializer is a braced-init-list.

libstdc++-v3/ChangeLog:

* testsuite/20_util/pair/cons/explicit_construct.cc: Adjust dg-error.
* testsuite/20_util/tuple/cons/explicit_construct.cc: Likewise.
* testsuite/23_containers/span/explicit.cc: Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/explicit16.C: New test.
---
 gcc/cp/call.cc|  4 +-
 gcc/testsuite/g++.dg/cpp0x/explicit16.C   | 18 ++
 .../20_util/pair/cons/explicit_construct.cc   | 10 ++--
 .../20_util/tuple/cons/explicit_construct.cc  | 58 +--
 .../testsuite/23_containers/span/explicit.cc  |  4 +-
 5 files changed, 57 insertions(+), 37 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit16.C

diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index c01e7b82457..c52a09b9be2 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -3612,7 +3612,9 @@ add_template_candidate_real (struct z_candidate 
**candidates, tree tmpl,
   /* Now the explicit specifier might have been deduced; check if this
  declaration is explicit.  If it is and we're ignoring non-converting
  constructors, don't add this function to the set of candidates.  */
-  if ((flags & LOOKUP_ONLYCONVERTING) && DECL_NONCONVERTING_P (fn))
+  if (((flags & (LOOKUP_ONLYCONVERTING|LOOKUP_LIST_INIT_CTOR))
+   == LOOKUP_ONLYCONVERTING)
+  && DECL_NONCONVERTING_P (fn))
 return NULL;
 
   if (DECL_CONSTRUCTOR_P (fn) && nargs == 2)
diff --git a/gcc/testsuite/g++.dg/cpp0x/explicit16.C 
b/gcc/testsuite/g++.dg/cpp0x/explicit16.C
new file mode 100644
index 000..bb5a823aee6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/explicit16.C
@@ -0,0 +1,18 @@
+// PR c++/109159
+// { dg-do compile { target c++11 } }
+
+struct A {
+  A(float) {}
+  template
+  explicit A(U) {}
+};
+
+void f(A t)
+{
+  t = {1}; // { dg-error "explicit constructor" }
+  t = 1;
+  A a1{1};
+  A a2 = {1}; // { dg-error "explicit constructor" }
+  A a3 = 1;
+  A a4(1);
+}
diff --git a/libstdc++-v3/testsuite/20_util/pair/cons/explicit_construct.cc 
b/libstdc++-v3/testsuite/20_util/pair/cons/explicit_construct.cc
index e875f0cbcd2..d550e9c604b 100644
--- a/libstdc++-v3/testsuite/20_util/pair/cons/explicit_construct.cc
+++ b/libstdc++-v3/testsuite/20_util/pair/cons/explicit_construct.cc
@@ -37,7 +37,7 @@ struct ExplicitDefaultDefault
 
 std::pair f1() {return {1,2};}
 
-std::pair f2() {return {1,2};} // { dg-error "could not 
convert" }
+std::pair f2() {return {1,2};} // { dg-error "explicit 
constructor" }
 
 std::pair f3() {return std::pair{1,2};}
 
@@ -52,7 +52,7 @@ std::pair v0{1,2};
 
 std::pair v1{1,2};
 
-std::pair v2 = {1,2}; // { dg-error "could not convert" }
+std::pair v2 = {1,2}; // { dg-error "explicit constructor" 
}
 
 std::pair v3{std::pair{1,2}};
 
@@ -99,7 +99,7 @@ void test_arg_passing()
 {
   f6(v0); // { dg-error "could not convert" }
   f6(v1);
-  f6({1,2}); // { dg-error "could not convert" }
+  f6({1,2}); // { dg-error "explicit constructor" }
   f6(std::pair{});
   f6(std::pair{}); // { dg-error "could not convert" }
   f7(v0);
@@ -130,6 +130,6 @@ std::pair v14{nullptr, MoveOnly{}};
 std::pair v15{MoveOnly{}, nullptr};
 
 std::pair v16 =
-  {nullptr, MoveOnly{}}; // { dg-error "could not convert" }
+  {nullptr, MoveOnly{}}; // { dg-error "explicit constructor" }
 std::pair v17 =
-  {MoveOnly{}, nullptr}; // { dg-error "could not convert" }
+  {MoveOnly{}, nullptr}; // { dg-error "explicit constructor" }
diff --git a/libstdc++-v3/testsuite/20_util/tuple/cons/explicit_construct.cc 
b/libstdc++-v3/testsuite/20_util/tuple/cons/explicit_construct.cc
index 820ddef30b4..3352dd15f7d 100644
--- a/libstdc++-v3/testsuite/20_util/tuple/cons/explicit_construct.cc
+++ b/libstdc++-v3/testsuite/20_util/tuple/cons/explicit_construct.cc
@@ -45,11 +45,11 @@ std::tuple f1b() {return {1,2};}
 std::tuple f1c() {return {1,2,3};}
 
 std::tuple f2_a()
-{return {1};} // { dg-error "could not convert" }
+{return {1};} // { dg-error "explicit constructor" }
 std::tuple f2_b()
-{return {1,2};} // { dg-error "could not convert" }
+{return {1,2};} // { dg-error "explicit constructor" }
 std::tuple f2_c()
-{return {1,2,3};} // { dg-error "could not c

Re: [PATCH] c++, v2: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164]

[Jakub Jelinek via Gcc-patches]

On Sat, Mar 18, 2023 at 04:09:55PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Sat, Mar 18, 2023 at 01:54:58PM +0100, Jakub Jelinek via Gcc-patches wrote:
> > The patch is mostly about DECL_EXTERNAL cases, the others are supposedly
> > handled by the var_definition_p code there (or at least I assumed;
> > testcases certainly test only DECL_EXTERNAL).
> > I guess it could be done in cp_finish_decl, maybe better next to the
> >   /* A reference will be modified here, as it is initialized.  */
> >   if (! DECL_EXTERNAL (decl)
> >   && TREE_READONLY (decl)
> >   && TYPE_REF_P (type))
> > {
> >   was_readonly = 1;
> >   TREE_READONLY (decl) = 0;
> > }
> > spot, but we'd need to export the decl2.cc helpers for it,
> > because not all DECL_THREAD_LOCAL_P vars need to be treated that way.
> >   if (VAR_P (decl)
> >   && CP_DECL_THREAD_LOCAL_P (decl)
> >   && var_needs_tls_wrapper (decl)
> >   && (!DECL_EXTERNAL (decl) || flag_extern_tls_init))
> > TREE_READONLY (decl) = 0;
> > where var_needs_tls_wrapper would need to be exported from decl2.cc.
> > Though, var_needs_tls_wrapper -> var_defined_without_dynamic_init
> > needs
> > DECL_NONTRIVIALLY_INITIALIZED_P/DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P,
> > so perhaps that is accurate only closer to the end of cp_finish_decl?
> 
> Here it is in patch form, tested so far on tls.exp:

And successfully bootstrapped/regtested on x86_64-linux and i686-linux over
the weekend.

> 2023-03-18  Jakub Jelinek  
> 
>   PR c++/109164
>   * cp-tree.h (var_needs_tls_wrapper): Declare.
>   * decl2.cc (var_needs_tls_wrapper): No longer static.
>   * decl.cc (cp_finish_decl): Clear TREE_READONLY on TLS variables
>   for which a TLS wrapper will be needed.
> 
>   * g++.dg/tls/thread_local13.C: New test.
>   * g++.dg/tls/thread_local13-aux.cc: New file.
>   * g++.dg/tls/thread_local14.C: New test.
>   * g++.dg/tls/thread_local14-aux.cc: New file.

Jakub

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Patrick Palka via Gcc-patches]

On Mon, Mar 20, 2023 at 5:56 AM Ken Matsui  wrote:
>
> > Does it actually make compilation faster though?
> >
> > Has it been measured?
>
> In my understanding, what I have implemented so far is so simple that
> it does not affect the speed. These traits are what Partick kindly
> recommended to get started. As explained on the GSoC page, some traits
> might involve expensive instantiation of multiple class templates. So
> IMHO, implementing built-in traits for those traits can make
> compilation cheaper.
>
> I have not measured it, but Patrick might have done?

Although the native implementation of using two partial
specializations is very efficient, I'd suspect using a built-in would
be even better because it'd avoid the work of having to figure out
which of the two partial specializations to instantiate.

I contrived the attached benchmark to measure this, which instantiates
~160k specializations of is_reference_v (it was simpler to write a
benchmark for the variable template version). On my machine gcc trunk
(release build) as well as Clang 15 use between 10-15% less
time/memory with -DUSE_BUILTIN than without for this benchmark, so
this suggests the built-in improves compile time/memory usage for this
trait by at least 10-15%.  For more complicated traits the improvement
should be even better.

>
> On Mon, Mar 20, 2023 at 2:14 AM Jonathan Wakely  wrote:
> >
> > On Mon, 20 Mar 2023 at 08:08, Xi Ruoyao via Libstdc++
> >  wrote:
> > >
> > > On Mon, 2023-03-20 at 01:03 -0700, Ken Matsui wrote:
> > > > Oops, I assumed those were my email... Thank you for your heads up and
> > > > your comments!
> > > >
> > > > > Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
> > > > > nothing) to indent the ChangeLog content.
> > > >
> > > > Do you mean like the following?
> > > >
> > > > ```
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > > [TAB]* include/std/type_traits (is_reference): Use __is_reference
> > > > built-in
> > > > trait.
> > > > ```
> > >
> > > Yep.
> > >
> > > > > Is there any benefit to use a builtin, instead of the existing
> > > > > implementation?  I can see no but maybe I'm stupid.
> > > >
> > > > My patches are based on the GSoC project "C++: Implement compiler
> > > > built-in traits for the standard library traits". These built-in
> > > > traits basically make the compilation faster.
> > > >
> > > > https://gcc.gnu.org/wiki/SummerOfCode
> > >
> > > Ok, to me making compilation faster is a valid reason.
> >
> > Does it actually make compilation faster though?
> >
> > Has it been measured?
> >
> > > > > The patch fails to apply.  It seems because your mail client inserted 
> > > > > an
> > > > > additional newline before "b/".  Try to use git-send-email or 
> > > > > configure
> > > > > the mail client properly.
> > > >
> > > > Let me try to use git-send-email instead. I stupidly don't understand
> > > > how to use them, so I was making my patches manually...
> > >
> > > Or adjust the mail client correctly.  You can send the patch to yourself
> > > first and see if it's not "mangled" by the mail client when you debug
> > > such an issue...
> > >
> > > But when you finally end up sending 10 patches in a series you'll find
> > > git send-email much easier :).
> >
> > Figuring out how to generate proper patches is an important part of
> > contributing to GCC, so part of any GSoC project.
>
#if USE_BUILTIN
template inline constexpr bool is_reference_v = __is_reference(T);
#else
template inline constexpr bool is_reference_v = false;
template inline constexpr bool is_reference_v = true;
template inline constexpr bool is_reference_v = true;
#endif


template struct A;

#define Y(N)\
  static_assert(!is_reference_v>); \
  static_assert(!is_reference_v*>);\
  static_assert(is_reference_v&>); \
  static_assert(is_reference_v&&>); \
  static_assert(is_reference_v&>); \
  static_assert(is_reference_v&&>); \
  static_assert(is_reference_v*&>); \
  static_assert(is_reference_v*&&>); \

#define X(N) Y(N) Y(-N)

int main() {
X(1);
X(2);
X(3);
X(4);
X(5);
X(6);
X(7);
X(8);
X(9);
X(10);
X(11);
X(12);
X(13);
X(14);
X(15);
X(16);
X(17);
X(18);
X(19);
X(20);
X(21);
X(22);
X(23);
X(24);
X(25);
X(26);
X(27);
X(28);
X(29);
X(30);
X(31);
X(32);
X(33);
X(34);
X(35);
X(36);
X(37);
X(38);
X(39);
X(40);
X(41);
X(42);
X(43);
X(44);
X(45);
X(46);
X(47);
X(48);
X(49);
X(50);
X(51);
X(52);
X(53);
X(54);
X(55);
X(56);
X(57);
X(58);
X(59);
X(60);
X(61);
X(62);
X(63);
X(64);
X(65);
X(66);
X(67);
X(68);
X(69);
X(70);
X(71);
X(72);
X(73);
X(74);
X(75);
X(76);
X(77);
X(78);
X(79);
X(80);
X(81);
X(82);
X(83);
X(84);
X(85);
X(86);
X(87);
X(88);
X(89);
X(90);
X(91);
X(92);
X(93);
X(94);
X(95);
X(96);
X(97);
X(98);
X(99);
X(100);
X(101);
X(102);
X(103);
X(104);
X(105);
X(106);
X(107);
X(108);
X(109);
X(110);
X(111);
X(112);
X(113);
X(114);
X(115);
X(116);
X(117);
X(118);
X(119);
X(120);
X(121);
X(122);
X(123);
X(124);
X(125);
X(126);
X(127);
X(128);
X(129);
X(130);
X(131);
X(132);
X(133);
X(134);
X(135);
X(136);
X(137)

Re: [PATCH] libstdc++: Fix handling of surrogate CP in codecvt [PR108976]

[Jonathan Wakely via Gcc-patches]

On Wed, 8 Mar 2023 at 14:09, Dimitrij Mijoski via Libstdc++ <
libstd...@gcc.gnu.org> wrote:

> This patch fixes the handling of surrogate code points in all standard
> facets for transcoding Unicode that are based on std::codecvt. Surrogate
> code points should always be treated as error. On the other hand
> surrogate code units can only appear in UTF-16 and only when they come
> in a proper pair.
>
> Additionally, it fixes a bug in std::codecvt_utf16::in() when odd number
> of bytes were given in the range [from, from_end), error was returned
> always. The last byte in such range does not form a full UTF-16 code
> unit and we can not make any decisions for error, instead partial should
> be returned.
>
> The testsuite for testing these facets was updated in the following
> order:
>
> 1. All functions that test codecvts that work with UTF-8 were refactored
>and made more generic so they accept codecvt that works with the char
>type char8_t.
> 2. The same functions were updated with new test cases for transcoding
>errors and now additionally test for surrogates, overlong UTF-8
>sequences, code points out of the Unicode range, and more tests for
>missing leading and trailing code units.
> 3. New tests were added to test codecvt_utf16 in both of its variants,
>UTF-16 <-> UTF-32/UCS-4 and UTF-16 <-> UCS-2.
>

Thanks, the patch looks OK to my uninformed eye, but I'm seeing a new
regression:

/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf16/79980.cc:86:
void test06(): Assertion 'result == u"from_bytes failed"' failed.
FAIL: 22_locale/codecvt/codecvt_utf16/79980.cc execution test


Also, I see that libc++ fails some of your new tests the same way as
current libstdc++ does:

unicode:
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_unicode.h:298:
void utf8_to_utf32_in_error(const std::codecvt
&) [InternT = char32_t, ExternT = char]: Assertion `res == cvt.error'
failed.
Aborted (core dumped)

Does that mean they have the same problem? Or is the test wrong? Or is your
patch implementing something that contradicts the requirements of the
standard? I think it's that libc++ has the same handling of surrogates, but
I'd like to be sure that's right.

Re: [PATCH v2 1/2] libstdc++: use copy_file_range, improve sendfile in filesystem::copy_file

[Jonathan Wakely via Gcc-patches]

On Mon, 20 Mar 2023 at 15:16, Jonathan Wakely wrote:

>
>
> On Wed, 15 Mar 2023 at 19:30, Jannik Glückert via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> This iteration improves error handling for copy_file_range,
>> particularly around undocumented error codes in earlier kernel
>> versions.
>> Additionally this fixes the userspace copy fallback to handle
>> zero-length files such as in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178.
>>
>> Lastly, the case "src gets resized during the copy loop" is now
>> considered and will return true once the loop hits EOF (this is the
>> only situation, aside from a zero-length src, where sendfile and
>> copy_file_range return 0).
>>
>
> I've applied this patch (with some whitespace fixes) and started testing
> it. I'm seeing some regressions:
>
> FAIL: experimental/filesystem/operations/copy.cc execution test
> FAIL: experimental/filesystem/operations/copy_file.cc execution test
>
> The failures in the log look like:
>
> terminate called after throwing an instance of
> 'std::experimental::filesystem::v1::__cxx11::filesystem_error'
>  what():  filesystem error: cannot copy: Input/output error
> [filesystem-test.copy.2900321341.ySWT77]
> [filesystem-test.copy.2900321342.vjeAar]
> FAIL: experimental/filesystem/operations/copy.cc execution test
>

Not just the Filesystem TS versions of those tests, but the std::filesystem
ones too:

FAIL: 27_io/filesystem/operations/copy.cc execution test
FAIL: 27_io/filesystem/operations/copy_file.cc execution test

Re: [PATCH v2 1/2] libstdc++: use copy_file_range, improve sendfile in filesystem::copy_file

[Jonathan Wakely via Gcc-patches]

On Wed, 15 Mar 2023 at 19:30, Jannik Glückert via Libstdc++ <
libstd...@gcc.gnu.org> wrote:

> This iteration improves error handling for copy_file_range,
> particularly around undocumented error codes in earlier kernel
> versions.
> Additionally this fixes the userspace copy fallback to handle
> zero-length files such as in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178.
>
> Lastly, the case "src gets resized during the copy loop" is now
> considered and will return true once the loop hits EOF (this is the
> only situation, aside from a zero-length src, where sendfile and
> copy_file_range return 0).
>

I've applied this patch (with some whitespace fixes) and started testing
it. I'm seeing some regressions:

FAIL: experimental/filesystem/operations/copy.cc execution test
FAIL: experimental/filesystem/operations/copy_file.cc execution test

The failures in the log look like:

terminate called after throwing an instance of
'std::experimental::filesystem::v1::__cxx11::filesystem_error'
 what():  filesystem error: cannot copy: Input/output error
[filesystem-test.copy.2900321341.ySWT77]
[filesystem-test.copy.2900321342.vjeAar]
FAIL: experimental/filesystem/operations/copy.cc execution test

Re: [committed] Docs: Fix formatting issues in BPF built-ins documentation

[Jose E. Marchesi via Gcc-patches]

Hi Sandra.

> This section of the GCC manual had some issues with lines in the
> example overflowing into the right margin of the PDF-format document,
> but as I looked at it more closely I also saw that it was full of
> missing or incorrect Texinfo markup, too.  I've cleaned it up thusly.

Thank you so much for fixing these issues in the manual.
Very much appreciated :)

>
> -Sandra
>
> commit 7ffbc74c8c202a16a5e987134f03c2359c531f0e
> Author: Sandra Loosemore 
> Date:   Thu Mar 16 21:07:18 2023 +
>
> Docs: Fix formatting issues in BPF built-ins documentation.
> 
> gcc/ChangeLog:
> * doc/extend.texi (BPF Built-in Functions): Fix numerous markup
> issues.  Add more line breaks to example so it doesn't overflow
> the margins.
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 39d45df8d89..8ecd9611201 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -15715,23 +15715,23 @@ void __builtin_bfin_ssync (void);
>  
>  The following built-in functions are available for eBPF targets.
>  
> -@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_byte 
> (unsigned long long @var{offset})
> +@deftypefn {Built-in Function} {unsigned long long} __builtin_bpf_load_byte 
> (unsigned long long @var{offset})
>  Load a byte from the @code{struct sk_buff} packet data pointed by the 
> register @code{%r6} and return it.
>  @end deftypefn
>  
> -@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_half 
> (unsigned long long @var{offset})
> -Load 16-bits from the @code{struct sk_buff} packet data pointed by the 
> register @code{%r6} and return it.
> +@deftypefn {Built-in Function} {unsigned long long} __builtin_bpf_load_half 
> (unsigned long long @var{offset})
> +Load 16 bits from the @code{struct sk_buff} packet data pointed by the 
> register @code{%r6} and return it.
>  @end deftypefn
>  
> -@deftypefn {Built-in Function} unsigned long long __builtin_bpf_load_word 
> (unsigned long long @var{offset})
> -Load 32-bits from the @code{struct sk_buff} packet data pointed by the 
> register @code{%r6} and return it.
> +@deftypefn {Built-in Function} {unsigned long long} __builtin_bpf_load_word 
> (unsigned long long @var{offset})
> +Load 32 bits from the @code{struct sk_buff} packet data pointed by the 
> register @code{%r6} and return it.
>  @end deftypefn
>  
> -@deftypefn {Built-in Function} void * __builtin_preserve_access_index 
> (@var{expr})
> +@deftypefn {Built-in Function} {void *} __builtin_preserve_access_index 
> (@var{expr})
>  BPF Compile Once-Run Everywhere (CO-RE) support. Instruct GCC to generate 
> CO-RE relocation records for any accesses to aggregate data structures 
> (struct, union, array types) in @var{expr}. This builtin is otherwise 
> transparent, the return value is whatever @var{expr} evaluates to. It is also 
> overloaded: @var{expr} may be of any type (not necessarily a pointer), the 
> return type is the same. Has no effect if @code{-mco-re} is not in effect 
> (either specified or implied).
>  @end deftypefn
>  
> -@deftypefn {Built-in Function} unsigned int __builtin_preserve_field_info 
> (@var{expr}, unsigned int @var{kind})
> +@deftypefn {Built-in Function} {unsigned int} __builtin_preserve_field_info 
> (@var{expr}, unsigned int @var{kind})
>  BPF Compile Once-Run Everywhere (CO-RE) support. This builtin is used to
>  extract information to aid in struct/union relocations.  @var{expr} is
>  an access to a field of a struct or union. Depending on @var{kind}, different
> @@ -15739,15 +15739,15 @@ information is returned to the program. A CO-RE 
> relocation for the access in
>  @var{expr} with kind @var{kind} is recorded if @code{-mco-re} is in effect.
>  
>  The following values are supported for @var{kind}:
> -@table @var
> +@table @code
>  @item FIELD_BYTE_OFFSET = 0
>  The returned value is the offset, in bytes, of the field from the
> -beginning of the containing structure. For bitfields, the byte offset
> +beginning of the containing structure. For bit-fields, this is the byte 
> offset
>  of the containing word.
>  
>  @item FIELD_BYTE_SIZE = 1
> -The returned value is the size, in bytes, of the field. For bitfields,
> -the size in bytes of the containing word.
> +The returned value is the size, in bytes, of the field. For bit-fields,
> +this is the size in bytes of the containing word.
>  
>  @item FIELD_EXISTENCE = 2
>  The returned value is 1 if the field exists, 0 otherwise. Always 1 at
> @@ -15759,25 +15759,26 @@ The returned value is 1 if the field is signed, 0 
> otherwise.
>  @item FIELD_LSHIFT_U64 = 4
>  @itemx FIELD_RSHIFT_U64 = 5
>  The returned value is the number of bits of left- or right-shifting
> -respectively needed in order to recover the original value of the field,
> -after it has been loaded by a read of FIELD_BYTE_SIZE bytes into an
> -unsigned 64-bit value. Primarily useful for reading bitfield values
> -from structures which may change between kern

Re: [PATCH v1] [RFC] Improve folding for comparisons with zero in tree-ssa-forwprop.

[Manolis Tsamis]

On Fri, Mar 17, 2023 at 10:31 AM Richard Biener
 wrote:
>
> On Thu, Mar 16, 2023 at 4:27 PM Manolis Tsamis  
> wrote:
> >
> > For this C testcase:
> >
> > void g();
> > void f(unsigned int *a)
> > {
> >   if (++*a == 1)
> > g();
> > }
> >
> > GCC will currently emit a comparison with 1 by using the value
> > of *a after the increment. This can be improved by comparing
> > against 0 and using the value before the increment. As a result
> > there is a potentially shorter dependancy chain (no need to wait
> > for the result of +1) and on targets with compare zero instructions
> > the generated code is one instruction shorter.
>
> The downside is we now need two registers and their lifetime overlaps.
>
> Your patch mixes changing / inverting a parameter (which seems unneeded
> for the actual change) with preferring compares against zero.
>

Indeed. I thought that without that change the original names wouldn't properly
describe what the parameter actually does and that's why I've changed it.
I can undo that in the next revision.

> What's the reason to specifically prefer compares against zero?  On x86
> we have add that sets flags, so ++*a == 0 would be preferred, but
> for your sequence we'd need a test reg, reg; branch on zero, so we do
> not save any instruction.
>

My reasoning is that zero is treated preferentially  in most if not
all architectures. Some specifically have zero/non-zero comparisons so
we get one less instruction. X86 doesn't explicitly have that but I
think that test reg, reg may not be always needed depending on the
rest of the code. By what Andrew mentions below there may even be
optimizations for zero in the microarchitecture level.

Because this is still an arch-specific thing I initially tried to make
it arch-depended by invoking the target's const functions (e.g. If I
recall correctly aarch64 will return a lower cost for zero
comparisons). But the code turned out complicated and messy so I came
up with this alternative that just treats zero preferentially.

If you have in mind a way that this can be done in a better way I
could try to implement it.

> We do have quite some number of bugreports with regards to making VRPs
> life harder when splitting things this way.  It's easier for VRP to handle
>
>   _1 = _2 + 1;
>   if (_1 == 1)
>
> than it is
>
>   _1 = _2 + 1;
>   if (_2 == 0)
>
> where VRP fails to derive a range for _1 on the _2 == 0 branch.  So besides
> the life-range issue there's other side-effects as well.  Maybe ranger 
> meanwhile
> can handle the above case?
>

Answered by Andrew MacLeod.

> What's the overall effect of the change on a larger code base?
>

I made some quick runs of SPEC2017 and got the following results (# of
folds of zero comparisons):

 gcc 2586
 xalancbmk 1456
 perlbench   375
 x264   307
 omnetpp 137
 leela   24
 deepsjeng  15
 exchange2  4
 xz4

My test runs on Aarch64 do not show any significant change in runtime.
In some cases (e.g. gcc) the binary is smaller in size, but that can
depend on a number of other things.

Thanks,
Manolis

> Thanks,
> Richard.
>
> >
> > Example from Aarch64:
> >
> > Before
> > ldr w1, [x0]
> > add w1, w1, 1
> > str w1, [x0]
> > cmp w1, 1
> > beq .L4
> > ret
> >
> > After
> > ldr w1, [x0]
> > add w2, w1, 1
> > str w2, [x0]
> > cbz w1, .L4
> > ret
> >
> > gcc/ChangeLog:
> >
> > * tree-ssa-forwprop.cc (combine_cond_expr_cond):
> > (forward_propagate_into_comparison_1): Optimize
> > for zero comparisons.
> >
> > Signed-off-by: Manolis Tsamis 
> > ---
> >
> >  gcc/tree-ssa-forwprop.cc | 41 +++-
> >  1 file changed, 28 insertions(+), 13 deletions(-)
> >
> > diff --git a/gcc/tree-ssa-forwprop.cc b/gcc/tree-ssa-forwprop.cc
> > index e34f0888954..93d5043821b 100644
> > --- a/gcc/tree-ssa-forwprop.cc
> > +++ b/gcc/tree-ssa-forwprop.cc
> > @@ -373,12 +373,13 @@ rhs_to_tree (tree type, gimple *stmt)
> >  /* Combine OP0 CODE OP1 in the context of a COND_EXPR.  Returns
> > the folded result in a form suitable for COND_EXPR_COND or
> > NULL_TREE, if there is no suitable simplified form.  If
> > -   INVARIANT_ONLY is true only gimple_min_invariant results are
> > -   considered simplified.  */
> > +   ALWAYS_COMBINE is false then only combine it the resulting
> > +   expression is gimple_min_invariant or considered simplified
> > +   compared to the original.  */
> >
> >  static tree
> >  combine_cond_expr_cond (gimple *stmt, enum tree_code code, tree type,
> > -   tree op0, tree op1, bool invariant_only)
> > +   tree op0, tree op1, bool always_combine)
> >  {
> >tree t;
> >
> > @@ -398,17 +399,31 @@ combine_cond_expr_cond (gimple *stmt, enum tree_code 
> > code, tree type,
> >/* Canonicalize the combined condition for use in a COND_EXPR.  */
> >

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

[Ken Matsui via Gcc-patches]

Thank you!

On Mon, Mar 20, 2023 at 2:12 AM Jonathan Wakely 
wrote:

> On Mon, 20 Mar 2023 at 08:08, Ken Matsui 
> wrote:
> >
> > Ooh... Thank you for pointing that out!
> >
> > > The helper doesn't need to be defined for the case where we don't use
> it.
> >
> > I thought that macroing them out leads to compiler errors since users
> > are possibly using those helpers. But do we not have to care about
> > that?
>
> No, absolutely not.
>
> >
> > ---
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/type_traits (remove_pointer): Use __remove_pointer
> built-in trait.
> >
> > ---
> > diff --git a/libstdc++-v3/include/std/type_traits
> > b/libstdc++-v3/include/std/type_traits
> > index 2bd607a8b8f..cba98091aad 100644
> > --- a/libstdc++-v3/include/std/type_traits
> > +++ b/libstdc++-v3/include/std/type_traits
> > @@ -2025,17 +2025,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >
> >template
> >  struct __remove_pointer_helper
> > -{ typedef _Tp type; };
> > +{ using type = _Tp; };
> >
> >template
> >  struct __remove_pointer_helper<_Tp, _Up*>
> > -{ typedef _Up type; };
> > +{ using type = _Up; };
> >
> >/// remove_pointer
> > +#if __has_builtin(__remove_pointer)
> > +  template
> > +struct remove_pointer
> > +{ using type = __remove_pointer(_Tp); };
> > +#else
> >template
> >  struct remove_pointer
> >  : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
> >  { };
> > +#endif
> >
> >template
> >  struct __add_pointer_helper
> >
> > On Mon, Mar 20, 2023 at 12:57 AM Jonathan Wakely 
> wrote:
> > >
> > >
> > >
> > > On Mon, 20 Mar 2023, 07:32 Ken Matsui via Libstdc++, <
> libstd...@gcc.gnu.org> wrote:
> > >>
> > >> CCing libstd...@gcc.gnu.org.
> > >>
> > >> On Sun, Mar 19, 2023 at 7:53 PM Ken Matsui 
> wrote:
> > >> >
> > >> > libstdc++-v3/ChangeLog:
> > >> >
> > >> > * include/std/type_traits (is_reference): Use __remove_pointer
> built-in trait.
> > >
> > >
> > > The changelog entry says is_reference but the patch is for
> remove_pointer.
> > >
> > >
> > >> >
> > >> > ---
> > >> > diff --git a/libstdc++-v3/include/std/type_traits
> > >> > b/libstdc++-v3/include/std/type_traits
> > >> > index 2bd607a8b8f..cba98091aad 100644
> > >> > --- a/libstdc++-v3/include/std/type_traits
> > >> > +++ b/libstdc++-v3/include/std/type_traits
> > >> > @@ -2025,17 +2025,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > >> >
> > >> >template
> > >> >  struct __remove_pointer_helper
> > >> > -{ typedef _Tp type; };
> > >> > +{ using type = _Tp; };
> > >> >
> > >> >template
> > >> >  struct __remove_pointer_helper<_Tp, _Up*>
> > >> > -{ typedef _Up type; };
> > >> > +{ using type = _Up; };
> > >
> > >
> > > The helper doesn't need to be defined for the case where we don't use
> it.
> > >
> > >
> > >> >
> > >> >/// remove_pointer
> > >> > +#if __has_builtin(__remove_pointer)
> > >> > +  template
> > >> > +struct remove_pointer
> > >> > +{ using type = __remove_pointer(_Tp); };
> > >> > +#else
> > >> >template
> > >> >  struct remove_pointer
> > >> >  : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
> > >> >  { };
> > >> > +#endif
> > >> >
> > >> >template
> > >> >  struct __add_pointer_helper
>

Re: [PATCH] c++: implement __is_reference built-in trait

[Ken Matsui via Gcc-patches]

I created new patches which is a series, but I couldn't figure out how
to associate them with this email and another email. Please disregard
this email.

On Sun, Mar 19, 2023 at 1:19 PM Ken Matsui  wrote:
>
> * cp-trait.def (names_builtin_p): Define __is_reference.
>
> This changelog should be the following.
>
> * cp-trait.def: Define __is_reference.
>
> I am sorry for the confusion.
>
> On Sat, Mar 18, 2023 at 9:07 PM Ken Matsui  wrote:
> >
> > This patch implements built-in trait for std::is_reference.
> >
> > gcc/cp/ChangeLog:
> >
> > * cp-trait.def (names_builtin_p): Define __is_reference.
> > * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_REFERENCE.
> > * semantics.cc (trait_expr_value): Likewise.
> > (finish_trait_expr): Likewise.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/ext/has-builtin-1.C: Test existence of __is_reference.
> > * g++.dg/ext/is_reference.C: New test.
> >
> > ---
> > diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> > index 273d15ab097..23e5bc24dbb 100644
> > --- a/gcc/cp/constraint.cc
> > +++ b/gcc/cp/constraint.cc
> > @@ -3701,6 +3701,9 @@ diagnose_trait_expr (tree expr, tree args)
> >  case CPTK_HAS_VIRTUAL_DESTRUCTOR:
> >inform (loc, "  %qT does not have a virtual destructor", t1);
> >break;
> > +case CPTK_IS_REFERENCE:
> > +  inform (loc, "  %qT is not a reference", t1);
> > +  break;
> >  case CPTK_IS_ABSTRACT:
> >inform (loc, "  %qT is not an abstract class", t1);
> >break;
> > diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
> > index bac593c0094..63a64152ce6 100644
> > --- a/gcc/cp/cp-trait.def
> > +++ b/gcc/cp/cp-trait.def
> > @@ -67,6 +67,7 @@ DEFTRAIT_EXPR (IS_CONVERTIBLE, "__is_convertible", 2)
> >  DEFTRAIT_EXPR (IS_EMPTY, "__is_empty", 1)
> >  DEFTRAIT_EXPR (IS_ENUM, "__is_enum", 1)
> >  DEFTRAIT_EXPR (IS_FINAL, "__is_final", 1)
> > +DEFTRAIT_EXPR (IS_REFERENCE, "__is_reference", 1)
> >  DEFTRAIT_EXPR (IS_LAYOUT_COMPATIBLE, "__is_layout_compatible", 2)
> >  DEFTRAIT_EXPR (IS_LITERAL_TYPE, "__is_literal_type", 1)
> >  DEFTRAIT_EXPR (IS_NOTHROW_ASSIGNABLE, "__is_nothrow_assignable", 2)
> > diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
> > index 87c2e8a7111..dce98af4f72 100644
> > --- a/gcc/cp/semantics.cc
> > +++ b/gcc/cp/semantics.cc
> > @@ -11995,6 +11995,9 @@ trait_expr_value (cp_trait_kind kind, tree
> > type1, tree type2)
> >  case CPTK_IS_FINAL:
> >return CLASS_TYPE_P (type1) && CLASSTYPE_FINAL (type1);
> >
> > +case CPTK_IS_REFERENCE:
> > +  return type_code1 == REFERENCE_TYPE;
> > +
> >  case CPTK_IS_LAYOUT_COMPATIBLE:
> >return layout_compatible_type_p (type1, type2);
> >
> > @@ -12139,6 +12142,7 @@ finish_trait_expr (location_t loc,
> > cp_trait_kind kind, tree type1, tree type2)
> >  case CPTK_HAS_TRIVIAL_COPY:
> >  case CPTK_HAS_TRIVIAL_DESTRUCTOR:
> >  case CPTK_HAS_UNIQUE_OBJ_REPRESENTATIONS:
> > +case CPTK_IS_REFERENCE:
> >if (!check_trait_type (type1))
> >   return error_mark_node;
> >break;
> > diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
> > b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
> > index f343e153e56..b697673790c 100644
> > --- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
> > +++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
> > @@ -146,3 +146,6 @@
> >  #if !__has_builtin (__remove_cvref)
> >  # error "__has_builtin (__remove_cvref) failed"
> >  #endif
> > +#if !__has_builtin (__is_reference)
> > +# error "__has_builtin (__is_reference) failed"
> > +#endif
> > diff --git a/gcc/testsuite/g++.dg/ext/is_reference.C
> > b/gcc/testsuite/g++.dg/ext/is_reference.C
> > new file mode 100644
> > index 000..b4f048538e5
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/ext/is_reference.C
> > @@ -0,0 +1,26 @@
> > +// { dg-do compile { target c++11 } }
> > +
> > +#define SA(X) static_assert((X),#X)
> > +
> > +SA(!__is_reference(void));
> > +SA(!__is_reference(int*));
> > +
> > +SA(__is_reference(int&));
> > +SA(__is_reference(const int&));
> > +SA(__is_reference(volatile int&));
> > +SA(__is_reference(const volatile int&));
> > +
> > +SA(__is_reference(int&&));
> > +SA(__is_reference(const int&&));
> > +SA(__is_reference(volatile int&&));
> > +SA(__is_reference(const volatile int&&));
> > +
> > +SA(!__is_reference(int[3]));
> > +SA(!__is_reference(const int[3]));
> > +SA(!__is_reference(volatile int[3]));
> > +SA(!__is_reference(const volatile int[3]));
> > +
> > +SA(!__is_reference(int(int)));
> > +SA(!__is_reference(int(*const)(int)));
> > +SA(!__is_reference(int(*volatile)(int)));
> > +SA(!__is_reference(int(*const volatile)(int)));

Re: [PATCH] tree-optimization/109170 - bogus use-after-free with __builtin_expect

[Jakub Jelinek via Gcc-patches]

On Mon, Mar 20, 2023 at 12:12:14PM +, Richard Biener wrote:
>   PR tree-optimization/109170
>   * gimple-range-op.cc (cfn_pass_through_arg1): New.
>   (gimple_range_op_handler::maybe_builtin_call): Handle
>   __builtin_expect and similar via cfn_pass_through_arg1
>   and inspecting the calls fnspec.
>   * builtins.cc (builtin_fnspec): Handle BUILT_IN_EXPECT
>   and BUILT_IN_EXPECT_WITH_PROBABILITY.

I'm still worried about this builtins.cc change, can't we defer
that part till GCC 14 where there will be enough time to see if it
doesn't result in some undesirable problems (__builtin_expect* being
optimized away when it still shouldn't etc.)?
> 
>   * gcc.dg/Wuse-after-free-pr109170.c: New testcase.
>   * gcc.dg/tree-ssa/ssa-lim-21.c: Adjust.
>   * gcc.dg/predict-20.c: Likewise.

Otherwise LGTM.

Jakub

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Ken Matsui via Gcc-patches]

It looks like I was able to use git send-email. The new patches became
a series, so I couldn't figure out how to associate them with this
email and another email. Please disregard this email.

On Mon, Mar 20, 2023 at 2:56 AM Ken Matsui  wrote:
>
> > Does it actually make compilation faster though?
> >
> > Has it been measured?
>
> In my understanding, what I have implemented so far is so simple that
> it does not affect the speed. These traits are what Partick kindly
> recommended to get started. As explained on the GSoC page, some traits
> might involve expensive instantiation of multiple class templates. So
> IMHO, implementing built-in traits for those traits can make
> compilation cheaper.
>
> I have not measured it, but Patrick might have done?
>
> On Mon, Mar 20, 2023 at 2:14 AM Jonathan Wakely  wrote:
> >
> > On Mon, 20 Mar 2023 at 08:08, Xi Ruoyao via Libstdc++
> >  wrote:
> > >
> > > On Mon, 2023-03-20 at 01:03 -0700, Ken Matsui wrote:
> > > > Oops, I assumed those were my email... Thank you for your heads up and
> > > > your comments!
> > > >
> > > > > Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
> > > > > nothing) to indent the ChangeLog content.
> > > >
> > > > Do you mean like the following?
> > > >
> > > > ```
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > > [TAB]* include/std/type_traits (is_reference): Use __is_reference
> > > > built-in
> > > > trait.
> > > > ```
> > >
> > > Yep.
> > >
> > > > > Is there any benefit to use a builtin, instead of the existing
> > > > > implementation?  I can see no but maybe I'm stupid.
> > > >
> > > > My patches are based on the GSoC project "C++: Implement compiler
> > > > built-in traits for the standard library traits". These built-in
> > > > traits basically make the compilation faster.
> > > >
> > > > https://gcc.gnu.org/wiki/SummerOfCode
> > >
> > > Ok, to me making compilation faster is a valid reason.
> >
> > Does it actually make compilation faster though?
> >
> > Has it been measured?
> >
> > > > > The patch fails to apply.  It seems because your mail client inserted 
> > > > > an
> > > > > additional newline before "b/".  Try to use git-send-email or 
> > > > > configure
> > > > > the mail client properly.
> > > >
> > > > Let me try to use git-send-email instead. I stupidly don't understand
> > > > how to use them, so I was making my patches manually...
> > >
> > > Or adjust the mail client correctly.  You can send the patch to yourself
> > > first and see if it's not "mangled" by the mail client when you debug
> > > such an issue...
> > >
> > > But when you finally end up sending 10 patches in a series you'll find
> > > git send-email much easier :).
> >
> > Figuring out how to generate proper patches is an important part of
> > contributing to GCC, so part of any GSoC project.

[PATCH 2/2] libstdc++: use new built-in trait __is_reference

[Ken Matsui via Gcc-patches]

This patch lets libstdc++ use new built-in trait __is_reference.

libstdc++-v3/ChangeLog:

* include/std/type_traits (is_reference): Use __is_reference built-in 
trait.
---
 libstdc++-v3/include/std/type_traits | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index 2bd607a8b8f..18408d8ceb6 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -639,6 +639,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // Composite type categories.
 
   /// is_reference
+#if __has_builtin(__is_reference)
+  template
+struct is_reference
+: public integral_constant
+{ };
+#else
   template
 struct is_reference
 : public false_type
@@ -653,6 +659,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 struct is_reference<_Tp&&>
 : public true_type
 { };
+#endif
 
   /// is_arithmetic
   template
-- 
2.40.0

[PATCH 1/2] c++: implement __is_reference built-in trait

[Ken Matsui via Gcc-patches]

This patch implements built-in trait for std::is_reference.

gcc/cp/ChangeLog:

* cp-trait.def: Define __is_reference.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_REFERENCE.
* semantics.cc (trait_expr_value): Likewise.
(finish_trait_expr): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/has-builtin-1.C: Test existence of __is_reference.
* g++.dg/ext/is_reference.C: New test.
---
 gcc/cp/constraint.cc |  3 +++
 gcc/cp/cp-trait.def  |  1 +
 gcc/cp/semantics.cc  |  4 
 gcc/testsuite/g++.dg/ext/has-builtin-1.C |  3 +++
 gcc/testsuite/g++.dg/ext/is_reference.C  | 26 
 5 files changed, 37 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/ext/is_reference.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 273d15ab097..23e5bc24dbb 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -3701,6 +3701,9 @@ diagnose_trait_expr (tree expr, tree args)
 case CPTK_HAS_VIRTUAL_DESTRUCTOR:
   inform (loc, "  %qT does not have a virtual destructor", t1);
   break;
+case CPTK_IS_REFERENCE:
+  inform (loc, "  %qT is not a reference", t1);
+  break;
 case CPTK_IS_ABSTRACT:
   inform (loc, "  %qT is not an abstract class", t1);
   break;
diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
index bac593c0094..63a64152ce6 100644
--- a/gcc/cp/cp-trait.def
+++ b/gcc/cp/cp-trait.def
@@ -67,6 +67,7 @@ DEFTRAIT_EXPR (IS_CONVERTIBLE, "__is_convertible", 2)
 DEFTRAIT_EXPR (IS_EMPTY, "__is_empty", 1)
 DEFTRAIT_EXPR (IS_ENUM, "__is_enum", 1)
 DEFTRAIT_EXPR (IS_FINAL, "__is_final", 1)
+DEFTRAIT_EXPR (IS_REFERENCE, "__is_reference", 1)
 DEFTRAIT_EXPR (IS_LAYOUT_COMPATIBLE, "__is_layout_compatible", 2)
 DEFTRAIT_EXPR (IS_LITERAL_TYPE, "__is_literal_type", 1)
 DEFTRAIT_EXPR (IS_NOTHROW_ASSIGNABLE, "__is_nothrow_assignable", 2)
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 87c2e8a7111..dce98af4f72 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -11995,6 +11995,9 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree 
type2)
 case CPTK_IS_FINAL:
   return CLASS_TYPE_P (type1) && CLASSTYPE_FINAL (type1);
 
+case CPTK_IS_REFERENCE:
+  return type_code1 == REFERENCE_TYPE;
+
 case CPTK_IS_LAYOUT_COMPATIBLE:
   return layout_compatible_type_p (type1, type2);
 
@@ -12139,6 +12142,7 @@ finish_trait_expr (location_t loc, cp_trait_kind kind, 
tree type1, tree type2)
 case CPTK_HAS_TRIVIAL_COPY:
 case CPTK_HAS_TRIVIAL_DESTRUCTOR:
 case CPTK_HAS_UNIQUE_OBJ_REPRESENTATIONS:
+case CPTK_IS_REFERENCE:
   if (!check_trait_type (type1))
return error_mark_node;
   break;
diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C 
b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
index f343e153e56..b697673790c 100644
--- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
+++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
@@ -146,3 +146,6 @@
 #if !__has_builtin (__remove_cvref)
 # error "__has_builtin (__remove_cvref) failed"
 #endif
+#if !__has_builtin (__is_reference)
+# error "__has_builtin (__is_reference) failed"
+#endif
diff --git a/gcc/testsuite/g++.dg/ext/is_reference.C 
b/gcc/testsuite/g++.dg/ext/is_reference.C
new file mode 100644
index 000..b4f048538e5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/is_reference.C
@@ -0,0 +1,26 @@
+// { dg-do compile { target c++11 } }
+
+#define SA(X) static_assert((X),#X)
+
+SA(!__is_reference(void));
+SA(!__is_reference(int*));
+
+SA(__is_reference(int&));
+SA(__is_reference(const int&));
+SA(__is_reference(volatile int&));
+SA(__is_reference(const volatile int&));
+
+SA(__is_reference(int&&));
+SA(__is_reference(const int&&));
+SA(__is_reference(volatile int&&));
+SA(__is_reference(const volatile int&&));
+
+SA(!__is_reference(int[3]));
+SA(!__is_reference(const int[3]));
+SA(!__is_reference(volatile int[3]));
+SA(!__is_reference(const volatile int[3]));
+
+SA(!__is_reference(int(int)));
+SA(!__is_reference(int(*const)(int)));
+SA(!__is_reference(int(*volatile)(int)));
+SA(!__is_reference(int(*const volatile)(int)));
-- 
2.40.0

Re: [PATCH] tree-optimization/109170 - bogus use-after-free with __builtin_expect

[Richard Biener via Gcc-patches]

On Mon, 20 Mar 2023, Richard Biener wrote:

> On Fri, 17 Mar 2023, Jakub Jelinek wrote:
> 
> > On Fri, Mar 17, 2023 at 02:18:52PM +, Richard Biener wrote:
> > > > And as you show on the testcases, it probably isn't a good idea for
> > > > BUILT_IN_EXPECT* either.
> > > > 
> > > > So, perhaps use op_cfn_pass_through_arg1 for the ERF_RETURNS_ARG 
> > > > functions
> > > > and BUILT_IN_EXPECT* ?
> > > 
> > > But that already causes the problems (I didn't yet finish testing
> > > adding RET1 to BUILT_IN_EXPECT*).  Note FRE currently does not use
> > > returns_arg but I have old patches that do - but those replace
> > > uses after a RET1 function with the return value to also reduce
> > > spilling around a call (they of course CSE equal calls).
> > 
> > I meant in your patch drop the builtins.cc hunk and add from your
> > other patch
> > > > +case CFN_BUILT_IN_EXPECT:
> > > > +case CFN_BUILT_IN_EXPECT_WITH_PROBABILITY:
> > > > +  m_valid = true;
> > > > +  m_op1 = gimple_call_arg (call, 0);
> > > > +  m_int = &op_cfn_pass_through_arg1;
> > > > +  break;
> > 
> > hunk to gimple_range_op_handler::maybe_builtin_call.
> > Does that already cause the problems?
> 
> Yes, that's basically what the first variant of the patch did and
> the FAILs quoted are from testing that variant.
> 
> There are no extra fails from the second more generic patch also
> touching builtins.cc
> 
> > I mean, if we e.g. see that a range of the argument is singleton,
> > then it is fine to optimize the __builtin_expect away.
> 
> Yes, it's somewhat odd that we handle the - case but not the +:
> 
> @@ -204,6 +206,7 @@
>_2 = b.0_1 < 0;
># RANGE [irange] long int [0, 1] NONZERO 0x1
>_3 = (long int) _2;
> +  # RANGE [irange] long int [0, 1] NONZERO 0x1
>_4 = __builtin_expect (_3, 0);
>if (_4 != 0)
>  goto ; [10.00%]
> ...
> @@ -224,13 +228,14 @@
>goto ; [100.00%]
>  
> [local count: 977105059]:
> -  # _9 = PHI <_4(3), 0(4)>
> +  # RANGE [irange] long int [0, 1] NONZERO 0x1
> +  # _9 = PHI <1(3), 0(4)>
>if (_9 != 0)
> -goto ; [10.00%]
> +goto ; [50.00%]
>else
> -goto ; [90.00%]
> +goto ; [50.00%]
> 
> 
>  Predictions for bb 5
> -  first match heuristics: 10.00%
> -  combined heuristics: 10.00%
> -  __builtin_expect heuristics of edge 5->6: 10.00%
> +  no prediction heuristics: 50.00%
> +  combined heuristics: 50.00%
> 
> the dumps don't get any hints on where the first matchor
> __builtin_expect heuristic came from, but it looks like we
> run expr_expected_value_1 on _9 != 0 which recurses for _9
> and runs into the PHI handling which then looks for
> a common value into the PHI.  In this case _4 is said
> to be zero by PRED_BUILTIN_EXPECT and probability 9000.
> But that seems wrong - it looks simply at the __builtin_expect
> def here, not taking into account the edge this flows through
> (the unlikely edge).
> 
> If we look at the recorded edge predictions we instead see
> 
> $28 = {ep_next = 0x43e4c80, ep_edge =  5)>, 
>   ep_predictor = PRED_BUILTIN_EXPECT, ep_probability = 1000}
> 
> so that's the same edge but unlikely now.  Of course there's
> no value recorded for this.  For the other edge into the PHI
> we get
> 
> $31 = {ep_next = 0x43c1e90, ep_edge =  5)>, 
>   ep_predictor = PRED_BUILTIN_EXPECT, ep_probability = 9000}
> 
> so to me a more reasonable approach would be to record '0' from
> the 2nd edge with a probability of 9000 (or for the '+' case IL
> '1' with a probability of 1000).  There's possibly a way to
> combine predictor + value (here we'd simply take the more
> probable value, or the constant for a PHI).  I also see that
> we handle any PHI this way, not just PHIs defined in the same
> BB as the condition which op we're ultimatively interested in.
> 
> So my conclusion is that currently it's pure luck the testcase
> "works", and thus adjusting it and opening a bug with the
> above findings would be appropriate?
> 
> Honza?

I filed PR109210 and updated the patch with adjustment of the
two failing testcases.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

OK?

Thanks,
Richard.

>From aac0ed731c49f74d7f363b80745150943b75bd4c Mon Sep 17 00:00:00 2001
From: Richard Biener 
Date: Fri, 17 Mar 2023 13:14:49 +0100
Subject: [PATCH] tree-optimization/109170 - bogus use-after-free with
 __builtin_expect
To: gcc-patches@gcc.gnu.org

The following adds a missing range-op for __builtin_expect which
helps -Wuse-after-free to detect the case a realloc original
pointer is used when the result was NULL.  The implementation
should handle all argument one pass-through builtins we handle
in the fnspec machinery.

The gcc.dg/tree-ssa/ssa-lim-21.c testcase needs adjustment because

   for (int j = 0; j < m; j++)
 if (__builtin_expect (m, 0))
   for (int i = 0; i < m; i++)

is now correctly optimized to a unconditional jump by EVRP - m
cannot be zero when the outer loop is entered.  I've adjusted
the outer loop to iterate 'n' times which makes us app

Re: [PATCH] New testcase

[Richard Biener via Gcc-patches]

On Mon, 20 Mar 2023, Jakub Jelinek wrote:

> On Tue, Mar 14, 2023 at 07:29:19AM +, Richard Biener via Gcc-patches 
> wrote:
> > This is a reduced testcase for an issue I ran into when trying to
> > improve PTA compile-time further, there wasn't any C family runfail
> > in the testsuite for this.
> > 
> > Pushed.
> > 
> > * g++.dg/torture/20230313.C: New testcase.
> 
> I've noticed this testcase FAILs on i686-linux with
> -fstack-protector-strong.
> 
> sizeof (auto_vec) == 16, which in this case contains
> 4-byte m_vec (which points to to m_auto), then 8-byte m_auto
> which contains just 8-byte m_vecpfx and finally 1 byte m_data,
> rest is padding.  We then try to push 2 ints to it, so 8 bytes,
> starting at the end of m_vecpfx aka address of m_data, but there
> is just 1 byte + 3 bytes of padding.
> In the lp64 case, I think sizeof (auto_vec) == 24,
> because there is 8-byte m_vec, 8-byte m_vecpfx and 1-byte m_char
> all with 8-byte alignment.
> 
> Can we just change
> --- gcc/testsuite/g++.dg/torture/20230313.C.jj2023-03-14 
> 12:24:55.930723588 +0100
> +++ gcc/testsuite/g++.dg/torture/20230313.C   2023-03-20 11:11:55.009044518 
> +0100
> @@ -60,7 +60,7 @@ struct auto_vec : vec
>  this->release ();
>}
>vec m_auto;
> -  char m_data;
> +  char m_data[2 * sizeof (int)];
>  };
>  template
>  struct vec
> 
> or does it go against what the testcase wants to verify?

That should be fine.

Thanks,
Richard.

Re: [RFC] internal documentation for OMP_FOR

[Tobias Burnus]

Hi Sandra,

https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612298.html

On 19.02.23 06:21, Sandra Loosemore wrote:

Here is a patch I put together for the internals manual; can other
people familiar with this functionality review it for technical
correctness?


Glancing at it,  it seems to be okay. (I have not cross checked by looking at 
the code.)


However, you may want to add something related to non-rectangular loops. For 
those, the
'N1' in OMP_FOR_INIT's @code{VAR = N1} and the
'N2' in OMP_FOR_COND's @code{VAR @{<,>,<=,>=@} N2}
have a special form; namely, the N1 and/or N2 are not normal expressions
but are TREE_VEC with three elements:
The outer loop variable (TREE_CODE_CLASS == tcc_declaration),
a multiplication factor,
and an offset.

Example: For the loop initialization 'i = j - 5', the result to be put into the
OMP_FOR_INIT vector is: 'MODIFY_EXPR (i, TREE_VEC)'

You could then also mention that OMP_FOR_NON_RECTANGULAR is/must be set
on the OMP_FOR statement in that case. (This flag is currently not mentioned in 
the .texi.)


Additionally, the doc/generic.texi could also mention that not only OMP_FOR
takes those operands but also OMP_SIMD, OMP_DISTRIBUTE, OMP_TASKLOOP, OMP_LOOP,
and OACC_LOOP (cf. tree.def or the actual code using it).

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [PATCHv3, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

[Tobias Burnus]

Hi,

sorry for the belated reply.

On 07.03.23 09:55, HAO CHEN GUI wrote:

2023-03-07  Haochen Gui 

gcc/
  PR target/103628
  * fortran/target-memory.cc (gfc_interpret_float): Return FAIL when
  native_interpret_expr gets a NULL tree.
  * fortran/arith.cc (gfc_hollerith2real): Return NULL when
  gfc_interpret_float fails.
  * fortran/error.cc (gfc_buffered_p): Define.
  * fortran/gfortran.h (gfc_buffered_p): Declare.
  * fortran/intrinsic.cc: Add diagnostic.h to include list.
  (do_simplify): Save errorcount and check it at finish.  Report a
  "Cannot simplify expression" error on a bad result if error count
  doesn't change and no other errors buffered.

gcc/testsuite/
  PR target/103628
  * gfortran.dg/pr103628.f90: New.

Co-Authored-By: Tobias Burnus 

...

--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc

...

@@ -4708,7 +4710,12 @@ do_simplify (gfc_intrinsic_sym *specific, gfc_expr *e)

  finish:
if (result == &gfc_bad_expr)
-return false;
+{
+  if (errorcount == old_errorcount
+   && (gfc_buffered_p () && !gfc_error_flag_test ()))
+   gfc_error ("Cannot simplify expression at %L", &e->where);
+  return false;
+}


The condition looks wrong. Shouldn't it be something like

+ && (!gfc_buffered_p () || !gfc_error_flag_test ()))

Namely:
* If there is no buffering, we know that no error has been printed → call error.
* With buffering, we additionally need to check for buffered errors.
  No buffered error → call error.

Otherwise LGTM.

Thus, if my comment makes sense to you + it regtests, modify it, and
go ahead and commit it.

Sorry for the delay - and thanks again for the patch!

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

Re: [PATCH] New testcase

[Jakub Jelinek via Gcc-patches]

On Tue, Mar 14, 2023 at 07:29:19AM +, Richard Biener via Gcc-patches wrote:
> This is a reduced testcase for an issue I ran into when trying to
> improve PTA compile-time further, there wasn't any C family runfail
> in the testsuite for this.
> 
> Pushed.
> 
>   * g++.dg/torture/20230313.C: New testcase.

I've noticed this testcase FAILs on i686-linux with
-fstack-protector-strong.

sizeof (auto_vec) == 16, which in this case contains
4-byte m_vec (which points to to m_auto), then 8-byte m_auto
which contains just 8-byte m_vecpfx and finally 1 byte m_data,
rest is padding.  We then try to push 2 ints to it, so 8 bytes,
starting at the end of m_vecpfx aka address of m_data, but there
is just 1 byte + 3 bytes of padding.
In the lp64 case, I think sizeof (auto_vec) == 24,
because there is 8-byte m_vec, 8-byte m_vecpfx and 1-byte m_char
all with 8-byte alignment.

Can we just change
--- gcc/testsuite/g++.dg/torture/20230313.C.jj  2023-03-14 12:24:55.930723588 
+0100
+++ gcc/testsuite/g++.dg/torture/20230313.C 2023-03-20 11:11:55.009044518 
+0100
@@ -60,7 +60,7 @@ struct auto_vec : vec
 this->release ();
   }
   vec m_auto;
-  char m_data;
+  char m_data[2 * sizeof (int)];
 };
 template
 struct vec

or does it go against what the testcase wants to verify?
Or
  char m_data[__alignof (void *) == 2 * sizeof (int) ? 1 : 2 * sizeof (int)];
to make it work almost as is (just char[1] instead of char) for LP64 and
use the exact size otherwise (ILP32, 128-bit pointers and the like)?

Jakub

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Ken Matsui via Gcc-patches]

> Does it actually make compilation faster though?
>
> Has it been measured?

In my understanding, what I have implemented so far is so simple that
it does not affect the speed. These traits are what Partick kindly
recommended to get started. As explained on the GSoC page, some traits
might involve expensive instantiation of multiple class templates. So
IMHO, implementing built-in traits for those traits can make
compilation cheaper.

I have not measured it, but Patrick might have done?

On Mon, Mar 20, 2023 at 2:14 AM Jonathan Wakely  wrote:
>
> On Mon, 20 Mar 2023 at 08:08, Xi Ruoyao via Libstdc++
>  wrote:
> >
> > On Mon, 2023-03-20 at 01:03 -0700, Ken Matsui wrote:
> > > Oops, I assumed those were my email... Thank you for your heads up and
> > > your comments!
> > >
> > > > Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
> > > > nothing) to indent the ChangeLog content.
> > >
> > > Do you mean like the following?
> > >
> > > ```
> > > libstdc++-v3/ChangeLog:
> > >
> > > [TAB]* include/std/type_traits (is_reference): Use __is_reference
> > > built-in
> > > trait.
> > > ```
> >
> > Yep.
> >
> > > > Is there any benefit to use a builtin, instead of the existing
> > > > implementation?  I can see no but maybe I'm stupid.
> > >
> > > My patches are based on the GSoC project "C++: Implement compiler
> > > built-in traits for the standard library traits". These built-in
> > > traits basically make the compilation faster.
> > >
> > > https://gcc.gnu.org/wiki/SummerOfCode
> >
> > Ok, to me making compilation faster is a valid reason.
>
> Does it actually make compilation faster though?
>
> Has it been measured?
>
> > > > The patch fails to apply.  It seems because your mail client inserted an
> > > > additional newline before "b/".  Try to use git-send-email or configure
> > > > the mail client properly.
> > >
> > > Let me try to use git-send-email instead. I stupidly don't understand
> > > how to use them, so I was making my patches manually...
> >
> > Or adjust the mail client correctly.  You can send the patch to yourself
> > first and see if it's not "mangled" by the mail client when you debug
> > such an issue...
> >
> > But when you finally end up sending 10 patches in a series you'll find
> > git send-email much easier :).
>
> Figuring out how to generate proper patches is an important part of
> contributing to GCC, so part of any GSoC project.

Re: [RFC/PATCH] sched: Consider debug insn in no_real_insns_p [PR108273]

[Kewen.Lin via Gcc-patches]

Hi Alexander,

Thanks a lot for your comments and suggestions!

on 2023/3/20 16:03, Alexander Monakov wrote:
> 
> On Mon, 20 Mar 2023, Kewen.Lin wrote:
> 
>> Hi,
> 
> Hi. Thank you for the thorough analysis. Since I analyzed
> PR108519, I'd like to offer my comments.
> 
>> As PR108273 shows, when there is one block which only has
>> NOTE_P and LABEL_P insns at non-debug mode while has some
>> extra DEBUG_INSN_P insns at debug mode, after scheduling
>> it, the DFA states would be different between debug mode
>> and non-debug mode.  Since at non-debug mode, the block
>> meets no_real_insns_p, it gets skipped; while at debug
>> mode, it gets scheduled, even it only has NOTE_P, LABEL_P
>> and DEBUG_INSN_P, the call of function advance_one_cycle
>> will change the DFA state.  PR108519 also shows this issue
>> issue can be exposed by some scheduler changes.
> 
> (yes, so an alternative is to avoid extraneous advance_one_cycle
> calls, but I think adjusting no_real_insns_p is preferable)
> 

Yeah, it looks no value to enter schedule_block for this kind
of no_real_nondebug_insns_p block.

>> This patch is to take debug insn into account in function
>> no_real_insns_p, which make us not try to schedule for the
>> block having only NOTE_P, LABEL_P and DEBUG_INSN_P insns,
>> resulting in consistent DFA states between non-debug and
>> debug mode.  Changing no_real_insns_p caused ICE when doing
>> free_block_dependencies, the root cause is that we create
>> dependencies for debug insns, those dependencies are
>> expected to be resolved during scheduling insns which gets
>> skipped after the change in no_real_insns_p.  By checking
>> the code, it looks it's reasonable to skip to compute block
>> dependencies for no_real_insns_p blocks.  It can be
>> bootstrapped and regtested but it hit one ICE when built
>> SPEC2017 bmks at option -O2 -g.  The root cause is that
>> initially there are no no_real_insns_p blocks in a region,
>> but in the later scheduling one block has one insn scheduled
>> speculatively then becomes no_real_insns_p, so we compute
>> dependencies and rgn_n_insns for this special block before
>> scheduling, later it gets skipped so not scheduled, the
>> following counts would mismatch:
>>
>> /* Sanity check: verify that all region insns were scheduled.  */
>>   gcc_assert (sched_rgn_n_insns == rgn_n_insns);
>>
>> , and we miss to release the allocated dependencies.
> 
> Hm, but it is quite normal for BBs to become empty via speculative
> scheduling in non-debug mode as well. So I don't think it's the
> right way to frame the problem.
> 
> I think the main issue here is that debug_insns are "not real insns"
> except we add them together with normal insns in the dependency graph,
> and then we verify that the graph was exhausted by the scheduler.

Thanks for your better description and explanation!  Yeah, it creates
dependencies and makes statistics for debug insns like the other normal
insns.

> 
> We already handle a situation when dbg_cnt is telling the scheduler
> to skip blocks. I guess the dbg_cnt handling is broken for a similar
> reason?

Yes, the dbg_cnt handlings looks wrong, I didn't dig into the history
but I guessed the original meaning (usage) of rgn_n_insns or
sched_rgn_n_insns have changed over time.

> 
> Can we fix this issue together with the debug_cnt issue by adjusting
> dbg_cnt handling in schedule_region, i.e. if no_real_insns_p || !dbg_cnt
> then adjust sched_rgn_n_insns and manually resolve+free dependencies?

Good idea!  I'll expand this to handle dbg_cnt issue.  One thing I'm not
sure about is that if it's a good idea to skip dependencies computing for
this kind of no_real_nondebug_insns_p block.  The pro is that it's more
efficient by skipping, while the con is that it needs an extra bitmap and
some checks.

> 
>> To avoid the unexpected mis-matchings, this patch adds one
>> bitmap to track this kind of special block which isn't
>> no_real_insns_p but becomes no_real_insns_p later, then we
>> can adjust the count and free deps for it.
> 
> Per above, I hope a simpler solution is possible.
> 
> (some comments on the patch below)
> 
>> This patch can be bootstrapped and regress-tested on
>> x86_64-redhat-linux, aarch64-linux-gnu and
>> powerpc64{,le}-linux-gnu.
>>
>> I also verified this patch can pass SPEC2017 both intrate
>> and fprate bmks building at -g -O2/-O3.
>>
>> This is for next stage 1, but since I know little on the
>> scheduler, I'd like to post it early for more comments.
>>
>> Is it on the right track?  Any thoughts?
>>
>> BR,
>> Kewen
>> -
>>  PR rtl-optimization/108273
>>
>> gcc/ChangeLog:
>>
>>  * haifa-sched.cc (no_real_insns_p): Consider DEBUG_INSN_P insn.
>>  * sched-rgn.cc (no_real_insns): New static bitmap variable.
>>  (compute_block_dependences): Skip for no_real_insns_p.
>>  (free_deps_for_bb_no_real_insns_p): New function.
>>  (free_block_dependencies): Call free_deps_for_bb_no_real_insns_p for
>>  no_real_insns_p b

Re: [PATCH] driver: Treat include path args the same way between cpp_unique_options and asm_options. [PR71850]

[Costas Argyris via Gcc-patches]

ping

On Thu, 9 Mar 2023 at 13:39, Costas Argyris 
wrote:

> Pinging list and driver reviewer.
>
> Details here:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71850
>
> On Thu, 2 Mar 2023 at 19:25, Costas Argyris 
> wrote:
>
>> This is a proposal to fix PR71850 by applying the existing logic for
>> passing include paths to cc1 to as.
>>
>> Thanks,
>> Costas
>>
>

[committed] libstdc++: Remove template-head from std::expected ctor [PR109182]

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk. Will backport to gcc-12 too.

-- >8 --

The presence of a template-head on this constructor is a copy & paste
error from the primary template.

libstdc++-v3/ChangeLog:

PR libstdc++/109182
* include/std/expected (expected::expected(in_place_t)):
Remove template-head.
---
 libstdc++-v3/include/std/expected | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/include/std/expected 
b/libstdc++-v3/include/std/expected
index 9a52e2574bf..567a5195e8d 100644
--- a/libstdc++-v3/include/std/expected
+++ b/libstdc++-v3/include/std/expected
@@ -1302,11 +1302,10 @@ namespace __expected
: _M_unex(std::move(__u).error()), _M_has_value(false)
{ }
 
-  template
-   constexpr explicit
-   expected(in_place_t) noexcept
-   : expected()
-   { }
+  constexpr explicit
+  expected(in_place_t) noexcept
+  : expected()
+  { }
 
   template
requires is_constructible_v<_Er, _Args...>
-- 
2.39.2

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Jonathan Wakely via Gcc-patches]

On Mon, 20 Mar 2023 at 08:08, Xi Ruoyao via Libstdc++
 wrote:
>
> On Mon, 2023-03-20 at 01:03 -0700, Ken Matsui wrote:
> > Oops, I assumed those were my email... Thank you for your heads up and
> > your comments!
> >
> > > Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
> > > nothing) to indent the ChangeLog content.
> >
> > Do you mean like the following?
> >
> > ```
> > libstdc++-v3/ChangeLog:
> >
> > [TAB]* include/std/type_traits (is_reference): Use __is_reference
> > built-in
> > trait.
> > ```
>
> Yep.
>
> > > Is there any benefit to use a builtin, instead of the existing
> > > implementation?  I can see no but maybe I'm stupid.
> >
> > My patches are based on the GSoC project "C++: Implement compiler
> > built-in traits for the standard library traits". These built-in
> > traits basically make the compilation faster.
> >
> > https://gcc.gnu.org/wiki/SummerOfCode
>
> Ok, to me making compilation faster is a valid reason.

Does it actually make compilation faster though?

Has it been measured?

> > > The patch fails to apply.  It seems because your mail client inserted an
> > > additional newline before "b/".  Try to use git-send-email or configure
> > > the mail client properly.
> >
> > Let me try to use git-send-email instead. I stupidly don't understand
> > how to use them, so I was making my patches manually...
>
> Or adjust the mail client correctly.  You can send the patch to yourself
> first and see if it's not "mangled" by the mail client when you debug
> such an issue...
>
> But when you finally end up sending 10 patches in a series you'll find
> git send-email much easier :).

Figuring out how to generate proper patches is an important part of
contributing to GCC, so part of any GSoC project.

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

[Jonathan Wakely via Gcc-patches]

On Mon, 20 Mar 2023 at 08:08, Ken Matsui  wrote:
>
> Ooh... Thank you for pointing that out!
>
> > The helper doesn't need to be defined for the case where we don't use it.
>
> I thought that macroing them out leads to compiler errors since users
> are possibly using those helpers. But do we not have to care about
> that?

No, absolutely not.

>
> ---
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (remove_pointer): Use __remove_pointer built-in 
> trait.
>
> ---
> diff --git a/libstdc++-v3/include/std/type_traits
> b/libstdc++-v3/include/std/type_traits
> index 2bd607a8b8f..cba98091aad 100644
> --- a/libstdc++-v3/include/std/type_traits
> +++ b/libstdc++-v3/include/std/type_traits
> @@ -2025,17 +2025,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>template
>  struct __remove_pointer_helper
> -{ typedef _Tp type; };
> +{ using type = _Tp; };
>
>template
>  struct __remove_pointer_helper<_Tp, _Up*>
> -{ typedef _Up type; };
> +{ using type = _Up; };
>
>/// remove_pointer
> +#if __has_builtin(__remove_pointer)
> +  template
> +struct remove_pointer
> +{ using type = __remove_pointer(_Tp); };
> +#else
>template
>  struct remove_pointer
>  : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
>  { };
> +#endif
>
>template
>  struct __add_pointer_helper
>
> On Mon, Mar 20, 2023 at 12:57 AM Jonathan Wakely  
> wrote:
> >
> >
> >
> > On Mon, 20 Mar 2023, 07:32 Ken Matsui via Libstdc++, 
> >  wrote:
> >>
> >> CCing libstd...@gcc.gnu.org.
> >>
> >> On Sun, Mar 19, 2023 at 7:53 PM Ken Matsui  
> >> wrote:
> >> >
> >> > libstdc++-v3/ChangeLog:
> >> >
> >> > * include/std/type_traits (is_reference): Use __remove_pointer built-in 
> >> > trait.
> >
> >
> > The changelog entry says is_reference but the patch is for remove_pointer.
> >
> >
> >> >
> >> > ---
> >> > diff --git a/libstdc++-v3/include/std/type_traits
> >> > b/libstdc++-v3/include/std/type_traits
> >> > index 2bd607a8b8f..cba98091aad 100644
> >> > --- a/libstdc++-v3/include/std/type_traits
> >> > +++ b/libstdc++-v3/include/std/type_traits
> >> > @@ -2025,17 +2025,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >> >
> >> >template
> >> >  struct __remove_pointer_helper
> >> > -{ typedef _Tp type; };
> >> > +{ using type = _Tp; };
> >> >
> >> >template
> >> >  struct __remove_pointer_helper<_Tp, _Up*>
> >> > -{ typedef _Up type; };
> >> > +{ using type = _Up; };
> >
> >
> > The helper doesn't need to be defined for the case where we don't use it.
> >
> >
> >> >
> >> >/// remove_pointer
> >> > +#if __has_builtin(__remove_pointer)
> >> > +  template
> >> > +struct remove_pointer
> >> > +{ using type = __remove_pointer(_Tp); };
> >> > +#else
> >> >template
> >> >  struct remove_pointer
> >> >  : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
> >> >  { };
> >> > +#endif
> >> >
> >> >template
> >> >  struct __add_pointer_helper

Re: [PATCH] tree-optimization/106912 - IPA profile and pure/const

[Richard Biener via Gcc-patches]

On Fri, 17 Mar 2023, Jakub Jelinek wrote:

> On Fri, Mar 17, 2023 at 08:40:34PM +0100, Jan Hubicka wrote:
> > > + /* Drop the const attribute from the call type (the pure
> > > +attribute is not available on types).  */
> > > + tree fntype = gimple_call_fntype (call);
> > > + if (fntype && TYPE_READONLY (fntype))
> > > +   gimple_call_set_fntype
> > > + (call, build_qualified_type (fntype, (TYPE_QUALS (fntype)
> > > +   & ~TYPE_QUAL_CONST)));
> > 
> > Sorry, now I am bit confused on why Jakub's fix did not need similar
> > fixup.  The flag is only set during the profiling stage and thus I would
> > expect it to still run into the problem that VOPs are missing.
> > Is it only becuase we do not sanity check?
> 
> My patch started from this point ignoring all TYPE_READONLY bits on
> all FUNCTION_TYPE/METHOD_TYPEs, while Richi's patch instead makes it
> explicit in the IL, TYPE_READONLY is honored as before but it shouldn't
> show up in any of the gimple_call_fntype types unless it is a direct
> call to a const function for which we don't have a body.
> 
> In either case, vops are added on the update_stmt a few lines later.
> 
> > Here is a testcase that shows the problem:
> > 
> > include 
> > float c;
> > 
> > __attribute__ ((const))
> > float
> > instrument(float v)
> > {
> > return sin (v);
> > }
> > __attribute__ ((no_profile_instrument_function,const,noinline))
> > float noinstrument (float v)
> > {
> > return instrument (v);
> > }
> > 
> > m()
> > {
> > c+=instrument(c);
> > if (!__builtin_expect (c,1))
> > {
> >   c+=noinstrument (c);
> > }
> > c+=instrument(c);
> > }
> > main()
> > {
> > m();
> > }
> > 
> > Compiling 
> > gcc -O0 t.c -fprofile-arcs -fno-early-inlining --coverage -lm 
> > -ftest-coverage -S ; gcc t.s -ftest-coverage -lm -fprofile-arcs
> > makes gcov to report 3 executions on instrument while with -O3 it is 2.

With my proposed patch it works fine and reports 3 executions on
'instrument' with both -O0 and -O3.  I checked it indeed reports only
2 executions with GCC 12.

So it seems the patch is a progression in general?

Thus, OK?

Thanks,
Richard.

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Ken Matsui via Gcc-patches]

Thank you!

On Mon, Mar 20, 2023 at 1:07 AM Xi Ruoyao  wrote:
>
> On Mon, 2023-03-20 at 01:03 -0700, Ken Matsui wrote:
> > Oops, I assumed those were my email... Thank you for your heads up and
> > your comments!
> >
> > > Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
> > > nothing) to indent the ChangeLog content.
> >
> > Do you mean like the following?
> >
> > ```
> > libstdc++-v3/ChangeLog:
> >
> > [TAB]* include/std/type_traits (is_reference): Use __is_reference
> > built-in
> > trait.
> > ```
>
> Yep.
>
> > > Is there any benefit to use a builtin, instead of the existing
> > > implementation?  I can see no but maybe I'm stupid.
> >
> > My patches are based on the GSoC project "C++: Implement compiler
> > built-in traits for the standard library traits". These built-in
> > traits basically make the compilation faster.
> >
> > https://gcc.gnu.org/wiki/SummerOfCode
>
> Ok, to me making compilation faster is a valid reason.
>
> > > The patch fails to apply.  It seems because your mail client inserted an
> > > additional newline before "b/".  Try to use git-send-email or configure
> > > the mail client properly.
> >
> > Let me try to use git-send-email instead. I stupidly don't understand
> > how to use them, so I was making my patches manually...
>
> Or adjust the mail client correctly.  You can send the patch to yourself
> first and see if it's not "mangled" by the mail client when you debug
> such an issue...
>
> But when you finally end up sending 10 patches in a series you'll find
> git send-email much easier :).
>
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

[Ken Matsui via Gcc-patches]

Ooh... Thank you for pointing that out!

> The helper doesn't need to be defined for the case where we don't use it.

I thought that macroing them out leads to compiler errors since users
are possibly using those helpers. But do we not have to care about
that?

---
libstdc++-v3/ChangeLog:

* include/std/type_traits (remove_pointer): Use __remove_pointer built-in trait.

---
diff --git a/libstdc++-v3/include/std/type_traits
b/libstdc++-v3/include/std/type_traits
index 2bd607a8b8f..cba98091aad 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -2025,17 +2025,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   template
 struct __remove_pointer_helper
-{ typedef _Tp type; };
+{ using type = _Tp; };

   template
 struct __remove_pointer_helper<_Tp, _Up*>
-{ typedef _Up type; };
+{ using type = _Up; };

   /// remove_pointer
+#if __has_builtin(__remove_pointer)
+  template
+struct remove_pointer
+{ using type = __remove_pointer(_Tp); };
+#else
   template
 struct remove_pointer
 : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
 { };
+#endif

   template
 struct __add_pointer_helper

On Mon, Mar 20, 2023 at 12:57 AM Jonathan Wakely  wrote:
>
>
>
> On Mon, 20 Mar 2023, 07:32 Ken Matsui via Libstdc++,  
> wrote:
>>
>> CCing libstd...@gcc.gnu.org.
>>
>> On Sun, Mar 19, 2023 at 7:53 PM Ken Matsui  wrote:
>> >
>> > libstdc++-v3/ChangeLog:
>> >
>> > * include/std/type_traits (is_reference): Use __remove_pointer built-in 
>> > trait.
>
>
> The changelog entry says is_reference but the patch is for remove_pointer.
>
>
>> >
>> > ---
>> > diff --git a/libstdc++-v3/include/std/type_traits
>> > b/libstdc++-v3/include/std/type_traits
>> > index 2bd607a8b8f..cba98091aad 100644
>> > --- a/libstdc++-v3/include/std/type_traits
>> > +++ b/libstdc++-v3/include/std/type_traits
>> > @@ -2025,17 +2025,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> >
>> >template
>> >  struct __remove_pointer_helper
>> > -{ typedef _Tp type; };
>> > +{ using type = _Tp; };
>> >
>> >template
>> >  struct __remove_pointer_helper<_Tp, _Up*>
>> > -{ typedef _Up type; };
>> > +{ using type = _Up; };
>
>
> The helper doesn't need to be defined for the case where we don't use it.
>
>
>> >
>> >/// remove_pointer
>> > +#if __has_builtin(__remove_pointer)
>> > +  template
>> > +struct remove_pointer
>> > +{ using type = __remove_pointer(_Tp); };
>> > +#else
>> >template
>> >  struct remove_pointer
>> >  : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
>> >  { };
>> > +#endif
>> >
>> >template
>> >  struct __add_pointer_helper

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Xi Ruoyao via Gcc-patches]

On Mon, 2023-03-20 at 01:03 -0700, Ken Matsui wrote:
> Oops, I assumed those were my email... Thank you for your heads up and
> your comments!
> 
> > Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
> > nothing) to indent the ChangeLog content.
> 
> Do you mean like the following?
> 
> ```
> libstdc++-v3/ChangeLog:
> 
> [TAB]* include/std/type_traits (is_reference): Use __is_reference
> built-in
> trait.
> ```

Yep.

> > Is there any benefit to use a builtin, instead of the existing
> > implementation?  I can see no but maybe I'm stupid.
> 
> My patches are based on the GSoC project "C++: Implement compiler
> built-in traits for the standard library traits". These built-in
> traits basically make the compilation faster.
> 
> https://gcc.gnu.org/wiki/SummerOfCode

Ok, to me making compilation faster is a valid reason.

> > The patch fails to apply.  It seems because your mail client inserted an
> > additional newline before "b/".  Try to use git-send-email or configure
> > the mail client properly.
> 
> Let me try to use git-send-email instead. I stupidly don't understand
> how to use them, so I was making my patches manually...

Or adjust the mail client correctly.  You can send the patch to yourself
first and see if it's not "mangled" by the mail client when you debug
such an issue...

But when you finally end up sending 10 patches in a series you'll find
git send-email much easier :).

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Ken Matsui via Gcc-patches]

Oops, I assumed those were my email... Thank you for your heads up and
your comments!

> Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
> nothing) to indent the ChangeLog content.

Do you mean like the following?

```
libstdc++-v3/ChangeLog:

[TAB]* include/std/type_traits (is_reference): Use __is_reference built-in
trait.
```

> Is there any benefit to use a builtin, instead of the existing
> implementation?  I can see no but maybe I'm stupid.

My patches are based on the GSoC project "C++: Implement compiler
built-in traits for the standard library traits". These built-in
traits basically make the compilation faster.

https://gcc.gnu.org/wiki/SummerOfCode

> The patch fails to apply.  It seems because your mail client inserted an
> additional newline before "b/".  Try to use git-send-email or configure
> the mail client properly.

Let me try to use git-send-email instead. I stupidly don't understand
how to use them, so I was making my patches manually...

> If a patch depends on another patch not applied yet, sent them in a
> series.  Or people are puzzled because when this patch is applied alone,
> the code fails to build.

Oooh, this one! [PATCH 3/7] - the third patch in a series of seven patches
I totally missed that. Thank you!

On Mon, Mar 20, 2023 at 12:51 AM Xi Ruoyao  wrote:
>
> On Mon, 2023-03-20 at 00:30 -0700, Ken Matsui wrote:
> > I see. Thank you!
>
> Please continue to read.  I guess you missed some inline comments from
> me...
>
> >
> > On Mon, Mar 20, 2023 at 12:26 AM Xi Ruoyao  wrote:
> > >
> > > You need to CC libstd...@gcc.gnu.org for any patches touching
> > > libstdc++.
> > >
> > > On Sat, 2023-03-18 at 21:21 -0700, Ken Matsui via Gcc-patches wrote:
> > > > libstdc++-v3/ChangeLog:
> > > >
> > > > * include/std/type_traits (is_reference): Use __is_reference
> > > > built-in
> > > > trait.
> > >
> > > Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
> > > nothing) to indent the ChangeLog content.
> > >
> > > Is there any benefit to use a builtin, instead of the existing
> > > implementation?  I can see no but maybe I'm stupid.
> > >
> > > > ---
> > > > diff --git a/libstdc++-v3/include/std/type_traits
> > > > b/libstdc++-v3/include/std/type_traits
> > >
> > > The patch fails to apply.  It seems because your mail client
> > > inserted an
> > > additional newline before "b/".  Try to use git-send-email or
> > > configure
> > > the mail client properly.
> > >
> > > > index 2bd607a8b8f..18408d8ceb6 100644
> > > > --- a/libstdc++-v3/include/std/type_traits
> > > > +++ b/libstdc++-v3/include/std/type_traits
> > > > @@ -639,6 +639,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > > >// Composite type categories.
> > > >
> > > >/// is_reference
> > > > +#if __has_builtin(__is_reference)
> > > > +  template
> > > > +struct is_reference
> > > > +: public integral_constant
> > >
> > > If a patch depends on another patch not applied yet, sent them in a
> > > series.  Or people are puzzled because when this patch is applied
> > > alone,
> > > the code fails to build.
> > >
> > > > +{ };
> > > > +#else
> > > >template
> > > >  struct is_reference
> > > >  : public false_type
> > > > @@ -653,6 +659,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > > >  struct is_reference<_Tp&&>
> > > >  : public true_type
> > > >  { };
> > > > +#endif
> > > >
> > > >/// is_arithmetic
> > > >template
> > >
> > > --
> > > Xi Ruoyao 
> > > School of Aerospace Science and Technology, Xidian University
>
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University

Re: [RFC/PATCH] sched: Consider debug insn in no_real_insns_p [PR108273]

[Alexander Monakov via Gcc-patches]

On Mon, 20 Mar 2023, Kewen.Lin wrote:

> Hi,

Hi. Thank you for the thorough analysis. Since I analyzed
PR108519, I'd like to offer my comments.

> As PR108273 shows, when there is one block which only has
> NOTE_P and LABEL_P insns at non-debug mode while has some
> extra DEBUG_INSN_P insns at debug mode, after scheduling
> it, the DFA states would be different between debug mode
> and non-debug mode.  Since at non-debug mode, the block
> meets no_real_insns_p, it gets skipped; while at debug
> mode, it gets scheduled, even it only has NOTE_P, LABEL_P
> and DEBUG_INSN_P, the call of function advance_one_cycle
> will change the DFA state.  PR108519 also shows this issue
> issue can be exposed by some scheduler changes.

(yes, so an alternative is to avoid extraneous advance_one_cycle
calls, but I think adjusting no_real_insns_p is preferable)

> This patch is to take debug insn into account in function
> no_real_insns_p, which make us not try to schedule for the
> block having only NOTE_P, LABEL_P and DEBUG_INSN_P insns,
> resulting in consistent DFA states between non-debug and
> debug mode.  Changing no_real_insns_p caused ICE when doing
> free_block_dependencies, the root cause is that we create
> dependencies for debug insns, those dependencies are
> expected to be resolved during scheduling insns which gets
> skipped after the change in no_real_insns_p.  By checking
> the code, it looks it's reasonable to skip to compute block
> dependencies for no_real_insns_p blocks.  It can be
> bootstrapped and regtested but it hit one ICE when built
> SPEC2017 bmks at option -O2 -g.  The root cause is that
> initially there are no no_real_insns_p blocks in a region,
> but in the later scheduling one block has one insn scheduled
> speculatively then becomes no_real_insns_p, so we compute
> dependencies and rgn_n_insns for this special block before
> scheduling, later it gets skipped so not scheduled, the
> following counts would mismatch:
> 
> /* Sanity check: verify that all region insns were scheduled.  */
>   gcc_assert (sched_rgn_n_insns == rgn_n_insns);
> 
> , and we miss to release the allocated dependencies.

Hm, but it is quite normal for BBs to become empty via speculative
scheduling in non-debug mode as well. So I don't think it's the
right way to frame the problem.

I think the main issue here is that debug_insns are "not real insns"
except we add them together with normal insns in the dependency graph,
and then we verify that the graph was exhausted by the scheduler.

We already handle a situation when dbg_cnt is telling the scheduler
to skip blocks. I guess the dbg_cnt handling is broken for a similar
reason?

Can we fix this issue together with the debug_cnt issue by adjusting
dbg_cnt handling in schedule_region, i.e. if no_real_insns_p || !dbg_cnt
then adjust sched_rgn_n_insns and manually resolve+free dependencies?

> To avoid the unexpected mis-matchings, this patch adds one
> bitmap to track this kind of special block which isn't
> no_real_insns_p but becomes no_real_insns_p later, then we
> can adjust the count and free deps for it.

Per above, I hope a simpler solution is possible.

(some comments on the patch below)

> This patch can be bootstrapped and regress-tested on
> x86_64-redhat-linux, aarch64-linux-gnu and
> powerpc64{,le}-linux-gnu.
> 
> I also verified this patch can pass SPEC2017 both intrate
> and fprate bmks building at -g -O2/-O3.
> 
> This is for next stage 1, but since I know little on the
> scheduler, I'd like to post it early for more comments.
> 
> Is it on the right track?  Any thoughts?
> 
> BR,
> Kewen
> -
>   PR rtl-optimization/108273
> 
> gcc/ChangeLog:
> 
>   * haifa-sched.cc (no_real_insns_p): Consider DEBUG_INSN_P insn.
>   * sched-rgn.cc (no_real_insns): New static bitmap variable.
>   (compute_block_dependences): Skip for no_real_insns_p.
>   (free_deps_for_bb_no_real_insns_p): New function.
>   (free_block_dependencies): Call free_deps_for_bb_no_real_insns_p for
>   no_real_insns_p bb.
>   (schedule_region): Fix up sched_rgn_n_insns for some block for which
>   rgn_n_insns is computed before, and move sched_rgn_local_finish after
>   free_block_dependencies loop.
>   (sched_rgn_local_init): Allocate and compute no_real_insns.
>   (sched_rgn_local_free): Free no_real_insns.
> ---
>  gcc/haifa-sched.cc |  8 -
>  gcc/sched-rgn.cc   | 84 +++---
>  2 files changed, 87 insertions(+), 5 deletions(-)
> 
> diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
> index 48b53776fa9..378f3b34cc0 100644
> --- a/gcc/haifa-sched.cc
> +++ b/gcc/haifa-sched.cc
> @@ -5040,7 +5040,13 @@ no_real_insns_p (const rtx_insn *head, const rtx_insn 
> *tail)
>  {
>while (head != NEXT_INSN (tail))
>  {
> -  if (!NOTE_P (head) && !LABEL_P (head))
> +  /* Take debug insn into account here, otherwise we can have different
> +  DFA states after scheduling a block which onl

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

[Jonathan Wakely via Gcc-patches]

On Mon, 20 Mar 2023, 07:32 Ken Matsui via Libstdc++, 
wrote:

> CCing libstd...@gcc.gnu.org.
>
> On Sun, Mar 19, 2023 at 7:53 PM Ken Matsui 
> wrote:
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/type_traits (is_reference): Use __remove_pointer built-in
> trait.
>

The changelog entry says is_reference but the patch is for remove_pointer.


>
> > ---
> > diff --git a/libstdc++-v3/include/std/type_traits
> > b/libstdc++-v3/include/std/type_traits
> > index 2bd607a8b8f..cba98091aad 100644
> > --- a/libstdc++-v3/include/std/type_traits
> > +++ b/libstdc++-v3/include/std/type_traits
> > @@ -2025,17 +2025,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >
> >template
> >  struct __remove_pointer_helper
> > -{ typedef _Tp type; };
> > +{ using type = _Tp; };
> >
> >template
> >  struct __remove_pointer_helper<_Tp, _Up*>
> > -{ typedef _Up type; };
> > +{ using type = _Up; };
>

The helper doesn't need to be defined for the case where we don't use it.


>
> >/// remove_pointer
> > +#if __has_builtin(__remove_pointer)
> > +  template
> > +struct remove_pointer
> > +{ using type = __remove_pointer(_Tp); };
> > +#else
> >template
> >  struct remove_pointer
> >  : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
> >  { };
> > +#endif
> >
> >template
> >  struct __add_pointer_helper
>

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Xi Ruoyao via Gcc-patches]

On Mon, 2023-03-20 at 00:30 -0700, Ken Matsui wrote:
> I see. Thank you!

Please continue to read.  I guess you missed some inline comments from
me...

> 
> On Mon, Mar 20, 2023 at 12:26 AM Xi Ruoyao  wrote:
> > 
> > You need to CC libstd...@gcc.gnu.org for any patches touching
> > libstdc++.
> > 
> > On Sat, 2023-03-18 at 21:21 -0700, Ken Matsui via Gcc-patches wrote:
> > > libstdc++-v3/ChangeLog:
> > > 
> > > * include/std/type_traits (is_reference): Use __is_reference
> > > built-in
> > > trait.
> > 
> > Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
> > nothing) to indent the ChangeLog content.
> > 
> > Is there any benefit to use a builtin, instead of the existing
> > implementation?  I can see no but maybe I'm stupid.
> > 
> > > ---
> > > diff --git a/libstdc++-v3/include/std/type_traits
> > > b/libstdc++-v3/include/std/type_traits
> > 
> > The patch fails to apply.  It seems because your mail client
> > inserted an
> > additional newline before "b/".  Try to use git-send-email or
> > configure
> > the mail client properly.
> > 
> > > index 2bd607a8b8f..18408d8ceb6 100644
> > > --- a/libstdc++-v3/include/std/type_traits
> > > +++ b/libstdc++-v3/include/std/type_traits
> > > @@ -639,6 +639,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > >    // Composite type categories.
> > > 
> > >    /// is_reference
> > > +#if __has_builtin(__is_reference)
> > > +  template
> > > +    struct is_reference
> > > +    : public integral_constant
> > 
> > If a patch depends on another patch not applied yet, sent them in a
> > series.  Or people are puzzled because when this patch is applied
> > alone,
> > the code fails to build.
> > 
> > > +    { };
> > > +#else
> > >    template
> > >  struct is_reference
> > >  : public false_type
> > > @@ -653,6 +659,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > >  struct is_reference<_Tp&&>
> > >  : public true_type
> > >  { };
> > > +#endif
> > > 
> > >    /// is_arithmetic
> > >    template
> > 
> > --
> > Xi Ruoyao 
> > School of Aerospace Science and Technology, Xidian University

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[PATCH] c++: implement __add_pointer built-in trait

[Ken Matsui via Gcc-patches]

This patch implements built-in trait for std::add_pointer.

gcc/cp/ChangeLog:

* cp-trait.def: Define __add_pointer.
* semantics.cc (finish_trait_type): Handle CPTK_ADD_POINTER.

gcc/testsuite/ChangeLog:

* g++.dg/ext/has-builtin-1.C: Test existence of __add_pointer.
* g++.dg/ext/add_pointer.C: New test.

---
diff --git a/gcc/cp/cp-trait.def b/gcc/cp/cp-trait.def
index bac593c0094..07fab8db26b 100644
--- a/gcc/cp/cp-trait.def
+++ b/gcc/cp/cp-trait.def
@@ -91,6 +91,7 @@ DEFTRAIT_TYPE (REMOVE_CV, "__remove_cv", 1)
 DEFTRAIT_TYPE (REMOVE_REFERENCE, "__remove_reference", 1)
 DEFTRAIT_TYPE (REMOVE_CVREF, "__remove_cvref", 1)
 DEFTRAIT_TYPE (UNDERLYING_TYPE,  "__underlying_type", 1)
+DEFTRAIT_TYPE (ADD_POINTER, "__add_pointer", 1)

 /* These traits yield a type pack, not a type, and are represented by
cp_parser_trait as a special BASES tree instead of a TRAIT_TYPE tree.  */
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 87c2e8a7111..3527f596983 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12273,6 +12273,10 @@ finish_trait_type (cp_trait_kind kind, tree
type1, tree type2)
   if (TYPE_REF_P (type1))
  type1 = TREE_TYPE (type1);
   return cv_unqualified (type1);
+case CPTK_ADD_POINTER:
+  if (TYPE_REF_P (type1))
+type1 = TREE_TYPE (type1);
+  return build_pointer_type (type1);

 #define DEFTRAIT_EXPR(CODE, NAME, ARITY) \
 case CPTK_##CODE:
diff --git a/gcc/testsuite/g++.dg/ext/add_pointer.C
b/gcc/testsuite/g++.dg/ext/add_pointer.C
new file mode 100644
index 000..e35873553c8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/add_pointer.C
@@ -0,0 +1,46 @@
+// { dg-do compile { target c++11 } }
+
+#define SA(X) static_assert((X),#X)
+
+SA(__is_same(__add_pointer(int), int*));
+SA(__is_same(__add_pointer(const int), const int*));
+SA(__is_same(__add_pointer(volatile int), volatile int*));
+SA(__is_same(__add_pointer(const volatile int), const volatile int*));
+
+SA(__is_same(__add_pointer(int*), int**));
+SA(__is_same(__add_pointer(const int*), const int**));
+SA(__is_same(__add_pointer(volatile int*), volatile int**));
+SA(__is_same(__add_pointer(const volatile int*), const volatile int**));
+
+SA(__is_same(__add_pointer(int* const), int* const*));
+SA(__is_same(__add_pointer(int* volatile), int* volatile*));
+SA(__is_same(__add_pointer(int* const volatile), int* const volatile*));
+
+SA(__is_same(__add_pointer(int&), int*));
+SA(__is_same(__add_pointer(const int&), const int*));
+SA(__is_same(__add_pointer(volatile int&), volatile int*));
+SA(__is_same(__add_pointer(const volatile int&), const volatile int*));
+
+SA(__is_same(__add_pointer(int&&), int*));
+SA(__is_same(__add_pointer(const int&&), const int*));
+SA(__is_same(__add_pointer(volatile int&&), volatile int*));
+SA(__is_same(__add_pointer(const volatile int&&), const volatile int*));
+
+SA(__is_same(__add_pointer(int[3]), int(*)[3]));
+SA(__is_same(__add_pointer(const int[3]), const int(*)[3]));
+SA(__is_same(__add_pointer(volatile int[3]), volatile int(*)[3]));
+SA(__is_same(__add_pointer(const volatile int[3]), const volatile int(*)[3]));
+
+SA(__is_same(__add_pointer(int(*)[3]), int(**)[3]));
+SA(__is_same(__add_pointer(const int(*)[3]), const int(**)[3]));
+SA(__is_same(__add_pointer(volatile int(*)[3]), volatile int(**)[3]));
+SA(__is_same(__add_pointer(const volatile int(*)[3]), const volatile
int(**)[3]));
+
+SA(__is_same(__add_pointer(int(* const)[3]), int(* const*)[3]));
+SA(__is_same(__add_pointer(int(* volatile)[3]), int(* volatile*)[3]));
+SA(__is_same(__add_pointer(int(* const volatile)[3]), int(* const
volatile*)[3]));
+
+SA(__is_same(__add_pointer(int(int)), int(*)(int)));
+SA(__is_same(__add_pointer(int(* const)(int)), int(* const*)(int)));
+SA(__is_same(__add_pointer(int(* volatile)(int)), int(* volatile*)(int)));
+SA(__is_same(__add_pointer(int(* const volatile)(int)), int(* const
volatile*)(int)));
diff --git a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
index f343e153e56..bed4f932bfa 100644
--- a/gcc/testsuite/g++.dg/ext/has-builtin-1.C
+++ b/gcc/testsuite/g++.dg/ext/has-builtin-1.C
@@ -146,3 +146,6 @@
 #if !__has_builtin (__remove_cvref)
 # error "__has_builtin (__remove_cvref) failed"
 #endif
+#if !__has_builtin (__add_pointer)
+# error "__has_builtin (__add_pointer) failed"
+#endif

Re: [PATCH] libstdc++: use new built-in trait __remove_pointer

[Ken Matsui via Gcc-patches]

CCing libstd...@gcc.gnu.org.

On Sun, Mar 19, 2023 at 7:53 PM Ken Matsui  wrote:
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_reference): Use __remove_pointer built-in trait.
>
> ---
> diff --git a/libstdc++-v3/include/std/type_traits
> b/libstdc++-v3/include/std/type_traits
> index 2bd607a8b8f..cba98091aad 100644
> --- a/libstdc++-v3/include/std/type_traits
> +++ b/libstdc++-v3/include/std/type_traits
> @@ -2025,17 +2025,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>template
>  struct __remove_pointer_helper
> -{ typedef _Tp type; };
> +{ using type = _Tp; };
>
>template
>  struct __remove_pointer_helper<_Tp, _Up*>
> -{ typedef _Up type; };
> +{ using type = _Up; };
>
>/// remove_pointer
> +#if __has_builtin(__remove_pointer)
> +  template
> +struct remove_pointer
> +{ using type = __remove_pointer(_Tp); };
> +#else
>template
>  struct remove_pointer
>  : public __remove_pointer_helper<_Tp, __remove_cv_t<_Tp>>
>  { };
> +#endif
>
>template
>  struct __add_pointer_helper

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Ken Matsui via Gcc-patches]

I see. Thank you!

On Mon, Mar 20, 2023 at 12:26 AM Xi Ruoyao  wrote:
>
> You need to CC libstd...@gcc.gnu.org for any patches touching libstdc++.
>
> On Sat, 2023-03-18 at 21:21 -0700, Ken Matsui via Gcc-patches wrote:
> > libstdc++-v3/ChangeLog:
> >
> > * include/std/type_traits (is_reference): Use __is_reference built-in
> > trait.
>
> Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
> nothing) to indent the ChangeLog content.
>
> Is there any benefit to use a builtin, instead of the existing
> implementation?  I can see no but maybe I'm stupid.
>
> > ---
> > diff --git a/libstdc++-v3/include/std/type_traits
> > b/libstdc++-v3/include/std/type_traits
>
> The patch fails to apply.  It seems because your mail client inserted an
> additional newline before "b/".  Try to use git-send-email or configure
> the mail client properly.
>
> > index 2bd607a8b8f..18408d8ceb6 100644
> > --- a/libstdc++-v3/include/std/type_traits
> > +++ b/libstdc++-v3/include/std/type_traits
> > @@ -639,6 +639,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >// Composite type categories.
> >
> >/// is_reference
> > +#if __has_builtin(__is_reference)
> > +  template
> > +struct is_reference
> > +: public integral_constant
>
> If a patch depends on another patch not applied yet, sent them in a
> series.  Or people are puzzled because when this patch is applied alone,
> the code fails to build.
>
> > +{ };
> > +#else
> >template
> >  struct is_reference
> >  : public false_type
> > @@ -653,6 +659,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >  struct is_reference<_Tp&&>
> >  : public true_type
> >  { };
> > +#endif
> >
> >/// is_arithmetic
> >template
>
> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University

Re: [PATCH] libstdc++: use new built-in trait __is_reference

[Xi Ruoyao via Gcc-patches]

You need to CC libstd...@gcc.gnu.org for any patches touching libstdc++.

On Sat, 2023-03-18 at 21:21 -0700, Ken Matsui via Gcc-patches wrote:
> libstdc++-v3/ChangeLog:
> 
> * include/std/type_traits (is_reference): Use __is_reference built-in
> trait.

Bad ChangeLog format.  You should have a tab (not 4 or 8 spaces, nor
nothing) to indent the ChangeLog content.

Is there any benefit to use a builtin, instead of the existing
implementation?  I can see no but maybe I'm stupid.

> ---
> diff --git a/libstdc++-v3/include/std/type_traits
> b/libstdc++-v3/include/std/type_traits

The patch fails to apply.  It seems because your mail client inserted an
additional newline before "b/".  Try to use git-send-email or configure
the mail client properly.

> index 2bd607a8b8f..18408d8ceb6 100644
> --- a/libstdc++-v3/include/std/type_traits
> +++ b/libstdc++-v3/include/std/type_traits
> @@ -639,6 +639,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>    // Composite type categories.
> 
>    /// is_reference
> +#if __has_builtin(__is_reference)
> +  template
> +    struct is_reference
> +    : public integral_constant

If a patch depends on another patch not applied yet, sent them in a
series.  Or people are puzzled because when this patch is applied alone,
the code fails to build.

> +    { };
> +#else
>    template
>  struct is_reference
>  : public false_type
> @@ -653,6 +659,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  struct is_reference<_Tp&&>
>  : public true_type
>  { };
> +#endif
> 
>    /// is_arithmetic
>    template

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: [patch, fortran, doc] Explicitly mention undefined overflow

[Thomas Koenig via Gcc-patches]

I wrote:




Yes, that's fine for trunk. I wonder if it is worth being explicit that
linear congruential pseudo-random number generators can and do fail at 
-O3?


I don't think we should put this into the docs, because that can change
at any time.  Maybe into porting_to.html, though (where I have only
mentioned this as a general issue with linear congruential generators,
without mentioning specific options. Current text can be seen at
https://gcc.gnu.org/gcc-13/porting_to.html ).

Hm


Breaking things actually goes back further than I thought.
Taking the random number generator from rnseed and running
it 10 times with my system gfortran 9.4.0 gets me, at
different levels of optimization:

$ for a in -O0 -O1 -O2; do echo $a; gfortran $a genuni.f90 && ./a.out; done
-O0
  0.269411892
  0.891386986
  0.444042951
  0.779210865
  0.500058949
  0.666437685
  0.666963458
  0.462416053
  0.376364112
   2.90278494E-02
-O1
  0.269411892
  0.891386986
  0.444042951
  0.779210865
  0.500058949
  0.666437685
  0.666963458
  0.462416053
  0.376364112
   2.90278494E-02
-O2
 -0.730588138
  0.891386986
 -0.555957019
 -0.220789105
 -0.499941051
  0.666437685
 -0.333036542
  0.462416053
  0.376364112
   2.90278494E-02

and for current trunk it is

$ for a in -O0 -O1 -O2; do echo $a; gfortran $a genuni.f90 && ./a.out; done
-O0
  0.269411892
  0.891386986
  0.444042951
  0.779210865
  0.500058949
  0.666437685
  0.666963458
  0.462416053
  0.376364112
   2.90278494E-02
-O1
  0.269411892
  0.891386986
  0.444042951
  0.779210865
  0.500058949
  0.666437685
  0.666963458
  0.462416053
  0.376364112
   2.90278494E-02
-O2
  0.211324871
  0.211324871
  0.211324871
  0.211324871
  0.211324871
  0.211324871
  0.211324871
  0.211324871
  0.211324871
  0.211324871

so it the general problem is not restricted to -O3 and not
to current trunk, it depends on the details.

I doubt that the result from 9.4.0 was expected, but rather
nobody noticed.  Or, bringing out the pseudo-RNG into a
different setting changed things.

So... any suggestions on how to improve the current wording?

Best regards

Thomas