[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[glisse at gcc dot gnu.org]

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

--- Comment #13 from Marc Glisse  ---
(In reply to fdlbxtqi from comment #11)
> TBH. I would rather see the library does the optimization instead of the
> compiler. I do not trust the compiler can always optimize this stuff.

If we have both, that looks even safer ;-)

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #14 from fdlbxtqi  ---
I think It is worth the effort to rewrite these functions since they are so
fundamental to the performance of entire C++. What I am worry about is that
whether revamping these functions would be a new ABI breaking.

If it won’t, I would like to contribute my implementation.

Sent from Mail for Windows 10

From: glisse at gcc dot gnu.org
Sent: Sunday, December 29, 2019 03:22
To: euloa...@live.com
Subject: [Bug libstdc++/93059] char and char8_t does not talk with each other
with memcpy. std::copy std::copy_n, std::fill, std::fill_n,
std::uninitialized_copy std::uninitialized_copy_n, std::fill,
std::uninitialized_fill_n fails to convert to memxxx functions

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

--- Comment #13 from Marc Glisse  ---
(In reply to fdlbxtqi from comment #11)
> TBH. I would rather see the library does the optimization instead of the
> compiler. I do not trust the compiler can always optimize this stuff.

If we have both, that looks even safer ;-)

--
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #15 from fdlbxtqi  ---
(In reply to fdlbxtqi from comment #14)
> I think It is worth the effort to rewrite these functions since they are so
> fundamental to the performance of entire C++. What I am worry about is that
> whether revamping these functions would be a new ABI breaking.
> 
> If it won’t, I would like to contribute my implementation.
> 
> Sent from Mail for Windows 10
> 
> From: glisse at gcc dot gnu.org
> Sent: Sunday, December 29, 2019 03:22
> To: euloa...@live.com
> Subject: [Bug libstdc++/93059] char and char8_t does not talk with each
> other with memcpy. std::copy std::copy_n, std::fill, std::fill_n,
> std::uninitialized_copy std::uninitialized_copy_n, std::fill,
> std::uninitialized_fill_n fails to convert to memxxx functions
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
> 
> --- Comment #13 from Marc Glisse  ---
> (In reply to fdlbxtqi from comment #11)
> > TBH. I would rather see the library does the optimization instead of the
> > compiler. I do not trust the compiler can always optimize this stuff.
> 
> If we have both, that looks even safer ;-)
> 
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.

I think It is worth the effort to rewrite these functions since they are so
fundamental to the performance of entire C++. Revamping them would create 100%
of performance benefits in a lot of important benchmarks. What I am worried
about is that whether revamping these functions would be a new wave of ABI
breaking.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #16 from fdlbxtqi  ---
(In reply to Marc Glisse from comment #13)
> (In reply to fdlbxtqi from comment #11)
> > TBH. I would rather see the library does the optimization instead of the
> > compiler. I do not trust the compiler can always optimize this stuff.
> 
> If we have both, that looks even safer ;-)

Concepts are no doubt a huge deal breaker.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[glisse at gcc dot gnu.org]

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

--- Comment #17 from Marc Glisse  ---
(In reply to fdlbxtqi from comment #15)
> What I am worried about is that whether revamping these functions would be a 
> new wave of ABI breaking.

I don't foresee any ABI issue here. Do make sure your code doesn't break with
-std=c++03, and run the testsuite before submitting it.

[Bug target/93078] Missing fma and round functions auto-vectorization with x86-64 (sse2)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Sun Dec 29 11:03:25 2019
New Revision: 279754

URL: https://gcc.gnu.org/viewcvs?rev=279754&root=gcc&view=rev
Log:
PR target/93078
* config/i386/i386-builtins.c (ix86_builtin_vectorized_function):
Remove CASE_CFN_RINT handling.
* config/i386/i386-builtin.def (IX86_BUILTIN_RINTPD,
IX86_BUILTIN_RINTPS, IX86_BUILTIN_RINTPD256, IX86_BUILTIN_RINTPS256):
Remove.
* config/i386/sse.md (nearbyint2, rint2): New expanders
with VF iterator.

* gcc.target/i386/sse4_1-pr93078.c: New test.
* gcc.target/i386/avx-pr93078.c: New test.
* gcc.target/i386/avx512f-pr93078.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/avx-pr93078.c
trunk/gcc/testsuite/gcc.target/i386/avx512f-pr93078.c
trunk/gcc/testsuite/gcc.target/i386/sse4_1-pr93078.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-builtin.def
trunk/gcc/config/i386/i386-builtins.c
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug fortran/91310] Read overflow generated by character array assignment to self

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #5 from Thomas Koenig  ---
Just going through the test cases...

Test case number 1 is invalid.

F2018, 9.4.1:

3 Let the characters in the parent string be numbered 1, 2, 3, ..., n, where n
is the length of the parent string.
Then the characters in the substring are those from the parent string from the
starting point and proceeding in
sequence up to and including the ending point. If the starting point is greater
than the ending point, the substring
has length zero; otherwise, both the starting point and the ending point shall
be within the range 1, 2, ..., n. If
the starting point is not specified, the default value is 1. If the ending
point is not specified, the default value is
n.

[Bug fortran/91310] Read overflow generated by character array assignment to self

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Comment on attachment 46648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46648
test case 1

Oops, correction. If len is small enough, the test case can be
valid (well, it could be if str was ever assigned).

Digging further...

[Bug fortran/91310] Read overflow generated by character array assignment to self

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Thomas Koenig  ---
OK, so finally:

If len + 3 > 512, _then_ the test case is invalid.

It would be nice to add bounds checking for that case, but
that's another kettle if fish.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #18 from fdlbxtqi  ---
(In reply to Marc Glisse from comment #17)
> (In reply to fdlbxtqi from comment #15)
> > What I am worried about is that whether revamping these functions would be 
> > a new wave of ABI breaking.
> 
> I don't foresee any ABI issue here. Do make sure your code doesn't break
> with -std=c++03, and run the testsuite before submitting it.

Also, I have found another bug??? in both libstdc++ and libc++

memmove is not allowed for using volatile. Only MSVC passes the test.

libstdc++&libc++ are wrong.

https://godbolt.org/z/FoTCbk

I will fix this as well.

[Bug rtl-optimization/93094] New: [10 Regression] ICE in maybe_gen_insn, at optabs.c:7433

[asolokha at gmx dot com]

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

Bug ID: 93094
   Summary: [10 Regression] ICE in maybe_gen_insn, at
optabs.c:7433
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-10.0.0-alpha20191222 snapshot (r279712) ICEs when compiling the following
testcase w/ -mavx512bw -O3 -fno-tree-pre:

void
ll (char *un, char *rr, int te, int fp, int nb)
{
  const int xe = nb & 1;

  while (fp-- != 0)
{
  if ((rr[0] & xe) == 0)
un[0] = 0;

  un += te;
  rr += te;
}
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191222 -mavx512bw -O3
-fno-tree-pre -c rgldkcen.c
during RTL pass: expand
rgldkcen.c: In function 'll':
rgldkcen.c:9:15: internal compiler error: in maybe_gen_insn, at optabs.c:7433
9 | un[0] = 0;
  | ~~^~~
0x65fcb3 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/optabs.c:7433
0xc329db maybe_expand_insn(insn_code, unsigned int, expand_operand*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/optabs.c:7477
0xc329db expand_insn(insn_code, unsigned int, expand_operand*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/optabs.c:7508
0xaf75ee expand_mask_store_optab_fn
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/internal-fn.c:2542
0x8c9ebe expand_call_stmt
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/cfgexpand.c:2609
0x8c9ebe expand_gimple_stmt_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/cfgexpand.c:3679
0x8c9ebe expand_gimple_stmt
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/cfgexpand.c:3844
0x8ce352 expand_gimple_basic_block
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/cfgexpand.c:5884
0x8d02e3 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191222/work/gcc-10-20191222/gcc/cfgexpand.c:6539

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #19 from fdlbxtqi  ---
Created attachment 47559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559&action=edit
An untested patch

From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
From: expnkx 
Date: Sun, 29 Dec 2019 09:49:19 -0500
Subject: [PATCH] Untested patch fix volatile bug of std::copyXXX and
 std::uninitialized_copyXXX Support custom contiguous_iterator Fix undefined
 behavior of &*end constexpr std::fill Greatly improve performance of
 std::copyXXX and std::uninitialized_copyXX for different types and apply
 pipeline optimization to reduce branch misprediction

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #20 from fdlbxtqi  ---
Comment on attachment 47559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559
An untested patch

>From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
>From: expnkx 
>Date: Sun, 29 Dec 2019 09:49:19 -0500
>Subject: [PATCH] Untested patch fix volatile bug of std::copyXXX and
> std::uninitialized_copyXXX Support custom contiguous_iterator Fix undefined
> behavior of &*end constexpr std::fill Greatly improve performance of
> std::copyXXX and std::uninitialized_copyXX for different types and apply
> pipeline optimization to reduce branch misprediction
>
>---
> libstdc++-v3/include/bits/stl_algobase.h | 170 ---
> 1 file changed, 148 insertions(+), 22 deletions(-)
>
>diff --git a/libstdc++-v3/include/bits/stl_algobase.h 
>b/libstdc++-v3/include/bits/stl_algobase.h
>index 40d056ae8d5..01672a8f232 100644
>--- a/libstdc++-v3/include/bits/stl_algobase.h
>+++ b/libstdc++-v3/include/bits/stl_algobase.h
>@@ -1,6 +1,6 @@
> // Core algorithmic facilities -*- C++ -*-
> 
>-// Copyright (C) 2001-2019 Free Software Foundation, Inc.
>+// Copyright (C) 2001-2020 Free Software Foundation, Inc.
> //
> // This file is part of the GNU ISO C++ Library.  This library is free
> // software; you can redistribute it and/or modify it under the
>@@ -84,10 +84,37 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>* A constexpr wrapper for __builtin_memmove.
>* @param __num The number of elements of type _Tp (not bytes).
>*/
>+#ifndef __cpp_lib_concepts
>   template
>+  _GLIBCXX14_CONSTEXPR
>+inline void volatile*
>+__memmove(_Tp volatile* __dst, _Tp volatile const* __src, size_t __num)
>+{
>+for(; __num > 0; --__num)
>+  {
>+#if __cplusplus >= 201103L
>+if constexpr (_IsMove)
>+  *__dst = std::move(*__src);
>+else
>+#endif
>+  *__dst = *__src;
>+++__src;
>+++__dst;
>+  }
>+return __dst;
>+}
>+#endif
>+  template
>+/*
>+#ifdef __cpp_lib_concepts
>+requires (is_trivially_copyable_v<_Tp>&&!is_volatile_v<_Tp>
>+  &&is_trivially_copyable_v<_Tp_src>&&!is_volatile_v<_Tp_src>
>+  
>&&(same_as<_Tp,_Tp_src>||(sizeof(_Tp)==sizeof(_Tp_src)&&integral<_Tp>&&integral<_Tp_src>)))
>+#endif
>+*/
> _GLIBCXX14_CONSTEXPR
> inline void*
>-__memmove(_Tp* __dst, const _Tp* __src, size_t __num)
>+__memmove(_Tp* __dst, _Tp_src const* __src, size_t __num)
> {
> #ifdef __cpp_lib_is_constant_evaluated
>   if (std::is_constant_evaluated())
>@@ -106,9 +133,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   else
> #endif
>   return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
>-  return __dst;
> }
>-
>   /*
>* A constexpr wrapper for __builtin_memcmp.
>* @param __num The number of elements of type _Tp (not bytes).
>@@ -431,7 +456,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   }
> };
> #endif
>-
>+#ifndef __cpp_lib_concepts
>   template
> struct __copy_move<_IsMove, true, random_access_iterator_tag>
> {
>@@ -448,12 +473,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> static_assert( __assignable::type::value, "type is not assignable" );
> #endif
> const ptrdiff_t _Num = __last - __first;
>-if (_Num)
>-  std::__memmove<_IsMove>(__result, __first, _Num);
>+if (!_Num)
>+return __result + _Num;
>+//since before C++20, we do not have [[likely]] attribute. We need to do it 
>manually
>+std::__memmove<_IsMove>(__result, __first, _Num);
> return __result + _Num;
>   }
> };
>-
>+#endif
>   // Helpers for streambuf iterators (either istream or ostream).
>   // NB: avoid including , relatively large.
>   template
>@@ -491,11 +518,41 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   typedef typename iterator_traits<_II>::value_type _ValueTypeI;
>   typedef typename iterator_traits<_OI>::value_type _ValueTypeO;
>   typedef typename iterator_traits<_II>::iterator_category _Category;
>+#ifdef __cpp_lib_concepts
>+  if constexpr(
>+  ((!is_volatile_v>)&&
>+  is_trivially_copyable_v<_ValueTypeI>)&&
>+  ((!is_volatile_v>)&&
>+  is_trivially_copyable_v<_ValueTypeO>)&&
>+  contiguous_iterator<_II>&&
>+  contiguous_iterator<_OI>&&
>+  (same_as<_ValueTypeI,_ValueTypeO>
>+  ||(integral<_ValueTypeI>&&integral<_ValueTypeO>&&
>+  sizeof(_ValueTypeI)==sizeof(_ValueTypeO
>+  {
>+using __assignable = conditional<_IsMove,
>+ is_move_assignable<_OI>,
>+is_copy_assignable<_OI>>;
>+static_assert( __assignable::type::value, "result type is not 
>assignable" );
>+ptrdiff_t const _Num = __last - __first;
>+if (_Num)
>+#ifdef __has_cpp_attribute(likely)
>+//This if statement is by default bad since it affects CPU pipeline.
>+//needs likely attribute or the branch misprediction pen

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #23 from fdlbxtqi  ---
Comment on attachment 47559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559
An untested patch

>From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
>From: expnkx 
>Date: Sun, 29 Dec 2019 09:49:19 -0500
>Subject: [PATCH] Untested patch fix volatile bug of std::copyXXX and
> std::uninitialized_copyXXX Support custom contiguous_iterator Fix undefined
> behavior of &*end constexpr std::fill Greatly improve performance of
> std::copyXXX and std::uninitialized_copyXX for different types and apply
> pipeline optimization to reduce branch misprediction
>
>---
> libstdc++-v3/include/bits/stl_algobase.h | 170 ---
> 1 file changed, 148 insertions(+), 22 deletions(-)
>
>diff --git a/libstdc++-v3/include/bits/stl_algobase.h 
>b/libstdc++-v3/include/bits/stl_algobase.h
>index 40d056ae8d5..01672a8f232 100644
>--- a/libstdc++-v3/include/bits/stl_algobase.h
>+++ b/libstdc++-v3/include/bits/stl_algobase.h
>@@ -1,6 +1,6 @@
> // Core algorithmic facilities -*- C++ -*-
> 
>-// Copyright (C) 2001-2019 Free Software Foundation, Inc.
>+// Copyright (C) 2001-2020 Free Software Foundation, Inc.
> //
> // This file is part of the GNU ISO C++ Library.  This library is free
> // software; you can redistribute it and/or modify it under the
>@@ -84,10 +84,37 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>* A constexpr wrapper for __builtin_memmove.
>* @param __num The number of elements of type _Tp (not bytes).
>*/
>+#ifndef __cpp_lib_concepts
>   template
>+  _GLIBCXX14_CONSTEXPR
>+inline void volatile*
>+__memmove(_Tp volatile* __dst, _Tp volatile const* __src, size_t __num)
>+{
>+for(; __num > 0; --__num)
>+  {
>+#if __cplusplus >= 201103L
>+if constexpr (_IsMove)
>+  *__dst = std::move(*__src);
>+else
>+#endif
>+  *__dst = *__src;
>+++__src;
>+++__dst;
>+  }
>+return __dst;
>+}
>+#endif
>+  template
>+/*
>+#ifdef __cpp_lib_concepts
>+requires (is_trivially_copyable_v<_Tp>&&!is_volatile_v<_Tp>
>+  &&is_trivially_copyable_v<_Tp_src>&&!is_volatile_v<_Tp_src>
>+  
>&&(same_as<_Tp,_Tp_src>||(sizeof(_Tp)==sizeof(_Tp_src)&&integral<_Tp>&&integral<_Tp_src>)))
>+#endif
>+*/
> _GLIBCXX14_CONSTEXPR
> inline void*
>-__memmove(_Tp* __dst, const _Tp* __src, size_t __num)
>+__memmove(_Tp* __dst, _Tp_src const* __src, size_t __num)
> {
> #ifdef __cpp_lib_is_constant_evaluated
>   if (std::is_constant_evaluated())
>@@ -106,9 +133,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   else
> #endif
>   return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
>-  return __dst;
> }
>-
>   /*
>* A constexpr wrapper for __builtin_memcmp.
>* @param __num The number of elements of type _Tp (not bytes).
>@@ -431,7 +456,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   }
> };
> #endif
>-
>+#ifndef __cpp_lib_concepts
>   template
> struct __copy_move<_IsMove, true, random_access_iterator_tag>
> {
>@@ -448,12 +473,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> static_assert( __assignable::type::value, "type is not assignable" );
> #endif
> const ptrdiff_t _Num = __last - __first;
>-if (_Num)
>-  std::__memmove<_IsMove>(__result, __first, _Num);
>+if (!_Num)
>+return __result + _Num;
>+//since before C++20, we do not have [[likely]] attribute. We need to do it 
>manually
>+std::__memmove<_IsMove>(__result, __first, _Num);
> return __result + _Num;
>   }
> };
>-
>+#endif
>   // Helpers for streambuf iterators (either istream or ostream).
>   // NB: avoid including , relatively large.
>   template
>@@ -491,11 +518,41 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   typedef typename iterator_traits<_II>::value_type _ValueTypeI;
>   typedef typename iterator_traits<_OI>::value_type _ValueTypeO;
>   typedef typename iterator_traits<_II>::iterator_category _Category;
>+#ifdef __cpp_lib_concepts
>+  if constexpr(
>+  ((!is_volatile_v>)&&
>+  is_trivially_copyable_v<_ValueTypeI>)&&
>+  ((!is_volatile_v>)&&
>+  is_trivially_copyable_v<_ValueTypeO>)&&
>+  contiguous_iterator<_II>&&
>+  contiguous_iterator<_OI>&&
>+  (same_as<_ValueTypeI,_ValueTypeO>
>+  ||(integral<_ValueTypeI>&&integral<_ValueTypeO>&&
>+  sizeof(_ValueTypeI)==sizeof(_ValueTypeO
>+  {
>+using __assignable = conditional<_IsMove,
>+ is_move_assignable<_OI>,
>+is_copy_assignable<_OI>>;
>+static_assert( __assignable::type::value, "result type is not 
>assignable" );
>+ptrdiff_t const _Num = __last - __first;
>+if (_Num)
>+#ifdef __has_cpp_attribute(likely)
>+//This if statement is by default bad since it affects CPU pipeline.
>+//needs likely attribute or the branch misprediction pen

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #22 from fdlbxtqi  ---
Comment on attachment 47559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559
An untested patch

>From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
>From: expnkx 
>Date: Sun, 29 Dec 2019 09:49:19 -0500
>Subject: [PATCH] Untested patch fix volatile bug of std::copyXXX and
> std::uninitialized_copyXXX Support custom contiguous_iterator Fix undefined
> behavior of &*end constexpr std::fill Greatly improve performance of
> std::copyXXX and std::uninitialized_copyXX for different types and apply
> pipeline optimization to reduce branch misprediction
>
>---
> libstdc++-v3/include/bits/stl_algobase.h | 170 ---
> 1 file changed, 148 insertions(+), 22 deletions(-)
>
>diff --git a/libstdc++-v3/include/bits/stl_algobase.h 
>b/libstdc++-v3/include/bits/stl_algobase.h
>index 40d056ae8d5..01672a8f232 100644
>--- a/libstdc++-v3/include/bits/stl_algobase.h
>+++ b/libstdc++-v3/include/bits/stl_algobase.h
>@@ -1,6 +1,6 @@
> // Core algorithmic facilities -*- C++ -*-
> 
>-// Copyright (C) 2001-2019 Free Software Foundation, Inc.
>+// Copyright (C) 2001-2020 Free Software Foundation, Inc.
> //
> // This file is part of the GNU ISO C++ Library.  This library is free
> // software; you can redistribute it and/or modify it under the
>@@ -84,10 +84,37 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>* A constexpr wrapper for __builtin_memmove.
>* @param __num The number of elements of type _Tp (not bytes).
>*/
>+#ifndef __cpp_lib_concepts
>   template
>+  _GLIBCXX14_CONSTEXPR
>+inline void volatile*
>+__memmove(_Tp volatile* __dst, _Tp volatile const* __src, size_t __num)
>+{
>+for(; __num > 0; --__num)
>+  {
>+#if __cplusplus >= 201103L
>+if constexpr (_IsMove)
>+  *__dst = std::move(*__src);
>+else
>+#endif
>+  *__dst = *__src;
>+++__src;
>+++__dst;
>+  }
>+return __dst;
>+}
>+#endif
>+  template
>+/*
>+#ifdef __cpp_lib_concepts
>+requires (is_trivially_copyable_v<_Tp>&&!is_volatile_v<_Tp>
>+  &&is_trivially_copyable_v<_Tp_src>&&!is_volatile_v<_Tp_src>
>+  
>&&(same_as<_Tp,_Tp_src>||(sizeof(_Tp)==sizeof(_Tp_src)&&integral<_Tp>&&integral<_Tp_src>)))
>+#endif
>+*/
> _GLIBCXX14_CONSTEXPR
> inline void*
>-__memmove(_Tp* __dst, const _Tp* __src, size_t __num)
>+__memmove(_Tp* __dst, _Tp_src const* __src, size_t __num)
> {
> #ifdef __cpp_lib_is_constant_evaluated
>   if (std::is_constant_evaluated())
>@@ -106,9 +133,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   else
> #endif
>   return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
>-  return __dst;
> }
>-
>   /*
>* A constexpr wrapper for __builtin_memcmp.
>* @param __num The number of elements of type _Tp (not bytes).
>@@ -431,7 +456,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   }
> };
> #endif
>-
>+#ifndef __cpp_lib_concepts
>   template
> struct __copy_move<_IsMove, true, random_access_iterator_tag>
> {
>@@ -448,12 +473,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> static_assert( __assignable::type::value, "type is not assignable" );
> #endif
> const ptrdiff_t _Num = __last - __first;
>-if (_Num)
>-  std::__memmove<_IsMove>(__result, __first, _Num);
>+if (!_Num)
>+return __result + _Num;
>+//since before C++20, we do not have [[likely]] attribute. We need to do it 
>manually
>+std::__memmove<_IsMove>(__result, __first, _Num);
> return __result + _Num;
>   }
> };
>-
>+#endif
>   // Helpers for streambuf iterators (either istream or ostream).
>   // NB: avoid including , relatively large.
>   template
>@@ -491,11 +518,41 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   typedef typename iterator_traits<_II>::value_type _ValueTypeI;
>   typedef typename iterator_traits<_OI>::value_type _ValueTypeO;
>   typedef typename iterator_traits<_II>::iterator_category _Category;
>+#ifdef __cpp_lib_concepts
>+  if constexpr(
>+  ((!is_volatile_v>)&&
>+  is_trivially_copyable_v<_ValueTypeI>)&&
>+  ((!is_volatile_v>)&&
>+  is_trivially_copyable_v<_ValueTypeO>)&&
>+  contiguous_iterator<_II>&&
>+  contiguous_iterator<_OI>&&
>+  (same_as<_ValueTypeI,_ValueTypeO>
>+  ||(integral<_ValueTypeI>&&integral<_ValueTypeO>&&
>+  sizeof(_ValueTypeI)==sizeof(_ValueTypeO
>+  {
>+using __assignable = conditional<_IsMove,
>+ is_move_assignable<_OI>,
>+is_copy_assignable<_OI>>;
>+static_assert( __assignable::type::value, "result type is not 
>assignable" );
>+ptrdiff_t const _Num = __last - __first;
>+if (_Num)
>+#ifdef __has_cpp_attribute(likely)
>+//This if statement is by default bad since it affects CPU pipeline.
>+//needs likely attribute or the branch misprediction pen

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #21 from fdlbxtqi  ---
Comment on attachment 47559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559
An untested patch

>From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
>From: expnkx 
>Date: Sun, 29 Dec 2019 09:49:19 -0500
>Subject: [PATCH] Untested patch fix volatile bug of std::copyXXX and
> std::uninitialized_copyXXX Support custom contiguous_iterator Fix undefined
> behavior of &*end constexpr std::fill Greatly improve performance of
> std::copyXXX and std::uninitialized_copyXX for different types and apply
> pipeline optimization to reduce branch misprediction
>
>---
> libstdc++-v3/include/bits/stl_algobase.h | 170 ---
> 1 file changed, 148 insertions(+), 22 deletions(-)
>
>diff --git a/libstdc++-v3/include/bits/stl_algobase.h 
>b/libstdc++-v3/include/bits/stl_algobase.h
>index 40d056ae8d5..01672a8f232 100644
>--- a/libstdc++-v3/include/bits/stl_algobase.h
>+++ b/libstdc++-v3/include/bits/stl_algobase.h
>@@ -1,6 +1,6 @@
> // Core algorithmic facilities -*- C++ -*-
> 
>-// Copyright (C) 2001-2019 Free Software Foundation, Inc.
>+// Copyright (C) 2001-2020 Free Software Foundation, Inc.
> //
> // This file is part of the GNU ISO C++ Library.  This library is free
> // software; you can redistribute it and/or modify it under the
>@@ -84,10 +84,37 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>* A constexpr wrapper for __builtin_memmove.
>* @param __num The number of elements of type _Tp (not bytes).
>*/
>+#ifndef __cpp_lib_concepts
>   template
>+  _GLIBCXX14_CONSTEXPR
>+inline void volatile*
>+__memmove(_Tp volatile* __dst, _Tp volatile const* __src, size_t __num)
>+{
>+for(; __num > 0; --__num)
>+  {
>+#if __cplusplus >= 201103L
>+if constexpr (_IsMove)
>+  *__dst = std::move(*__src);
>+else
>+#endif
>+  *__dst = *__src;
>+++__src;
>+++__dst;
>+  }
>+return __dst;
>+}
>+#endif
>+  template
>+/*
>+#ifdef __cpp_lib_concepts
>+requires (is_trivially_copyable_v<_Tp>&&!is_volatile_v<_Tp>
>+  &&is_trivially_copyable_v<_Tp_src>&&!is_volatile_v<_Tp_src>
>+  
>&&(same_as<_Tp,_Tp_src>||(sizeof(_Tp)==sizeof(_Tp_src)&&integral<_Tp>&&integral<_Tp_src>)))
>+#endif
>+*/
> _GLIBCXX14_CONSTEXPR
> inline void*
>-__memmove(_Tp* __dst, const _Tp* __src, size_t __num)
>+__memmove(_Tp* __dst, _Tp_src const* __src, size_t __num)
> {
> #ifdef __cpp_lib_is_constant_evaluated
>   if (std::is_constant_evaluated())
>@@ -106,9 +133,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   else
> #endif
>   return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
>-  return __dst;
> }
>-
>   /*
>* A constexpr wrapper for __builtin_memcmp.
>* @param __num The number of elements of type _Tp (not bytes).
>@@ -431,7 +456,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   }
> };
> #endif
>-
>+#ifndef __cpp_lib_concepts
>   template
> struct __copy_move<_IsMove, true, random_access_iterator_tag>
> {
>@@ -448,12 +473,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> static_assert( __assignable::type::value, "type is not assignable" );
> #endif
> const ptrdiff_t _Num = __last - __first;
>-if (_Num)
>-  std::__memmove<_IsMove>(__result, __first, _Num);
>+if (!_Num)
>+return __result + _Num;
>+//since before C++20, we do not have [[likely]] attribute. We need to do it 
>manually
>+std::__memmove<_IsMove>(__result, __first, _Num);
> return __result + _Num;
>   }
> };
>-
>+#endif
>   // Helpers for streambuf iterators (either istream or ostream).
>   // NB: avoid including , relatively large.
>   template
>@@ -491,11 +518,41 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   typedef typename iterator_traits<_II>::value_type _ValueTypeI;
>   typedef typename iterator_traits<_OI>::value_type _ValueTypeO;
>   typedef typename iterator_traits<_II>::iterator_category _Category;
>+#ifdef __cpp_lib_concepts
>+  if constexpr(
>+  ((!is_volatile_v>)&&
>+  is_trivially_copyable_v<_ValueTypeI>)&&
>+  ((!is_volatile_v>)&&
>+  is_trivially_copyable_v<_ValueTypeO>)&&
>+  contiguous_iterator<_II>&&
>+  contiguous_iterator<_OI>&&
>+  (same_as<_ValueTypeI,_ValueTypeO>
>+  ||(integral<_ValueTypeI>&&integral<_ValueTypeO>&&
>+  sizeof(_ValueTypeI)==sizeof(_ValueTypeO
>+  {
>+using __assignable = conditional<_IsMove,
>+ is_move_assignable<_OI>,
>+is_copy_assignable<_OI>>;
>+static_assert( __assignable::type::value, "result type is not 
>assignable" );
>+ptrdiff_t const _Num = __last - __first;
>+if (_Num)
>+#ifdef __has_cpp_attribute(likely)
>+//This if statement is by default bad since it affects CPU pipeline.
>+//needs likely attribute or the branch misprediction pen

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #24 from fdlbxtqi  ---
Comment on attachment 47559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47559
An untested patch

>From 1dfd714e1f29e229d69a0c7f6f84bf05dd4ee85d Mon Sep 17 00:00:00 2001
>From: expnkx 
>Date: Sun, 29 Dec 2019 09:49:19 -0500
>Subject: [PATCH] Untested patch fix volatile bug of std::copyXXX and
> std::uninitialized_copyXXX Support custom contiguous_iterator Fix undefined
> behavior of &*end constexpr std::fill Greatly improve performance of
> std::copyXXX and std::uninitialized_copyXX for different types and apply
> pipeline optimization to reduce branch misprediction
>
>---
> libstdc++-v3/include/bits/stl_algobase.h | 170 ---
> 1 file changed, 148 insertions(+), 22 deletions(-)
>
>diff --git a/libstdc++-v3/include/bits/stl_algobase.h 
>b/libstdc++-v3/include/bits/stl_algobase.h
>index 40d056ae8d5..01672a8f232 100644
>--- a/libstdc++-v3/include/bits/stl_algobase.h
>+++ b/libstdc++-v3/include/bits/stl_algobase.h
>@@ -1,6 +1,6 @@
> // Core algorithmic facilities -*- C++ -*-
> 
>-// Copyright (C) 2001-2019 Free Software Foundation, Inc.
>+// Copyright (C) 2001-2020 Free Software Foundation, Inc.
> //
> // This file is part of the GNU ISO C++ Library.  This library is free
> // software; you can redistribute it and/or modify it under the
>@@ -84,10 +84,37 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>* A constexpr wrapper for __builtin_memmove.
>* @param __num The number of elements of type _Tp (not bytes).
>*/
>+#ifndef __cpp_lib_concepts
>   template
>+  _GLIBCXX14_CONSTEXPR
>+inline void volatile*
>+__memmove(_Tp volatile* __dst, _Tp volatile const* __src, size_t __num)
>+{
>+for(; __num > 0; --__num)
>+  {
>+#if __cplusplus >= 201103L
>+if constexpr (_IsMove)
>+  *__dst = std::move(*__src);
>+else
>+#endif
>+  *__dst = *__src;
>+++__src;
>+++__dst;
>+  }
>+return __dst;
>+}
>+#endif
>+  template
>+/*
>+#ifdef __cpp_lib_concepts
>+requires (is_trivially_copyable_v<_Tp>&&!is_volatile_v<_Tp>
>+  &&is_trivially_copyable_v<_Tp_src>&&!is_volatile_v<_Tp_src>
>+  
>&&(same_as<_Tp,_Tp_src>||(sizeof(_Tp)==sizeof(_Tp_src)&&integral<_Tp>&&integral<_Tp_src>)))
>+#endif
>+*/
> _GLIBCXX14_CONSTEXPR
> inline void*
>-__memmove(_Tp* __dst, const _Tp* __src, size_t __num)
>+__memmove(_Tp* __dst, _Tp_src const* __src, size_t __num)
> {
> #ifdef __cpp_lib_is_constant_evaluated
>   if (std::is_constant_evaluated())
>@@ -106,9 +133,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   else
> #endif
>   return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
>-  return __dst;
> }
>-
>   /*
>* A constexpr wrapper for __builtin_memcmp.
>* @param __num The number of elements of type _Tp (not bytes).
>@@ -431,7 +456,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   }
> };
> #endif
>-
>+#ifndef __cpp_lib_concepts
>   template
> struct __copy_move<_IsMove, true, random_access_iterator_tag>
> {
>@@ -448,12 +473,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> static_assert( __assignable::type::value, "type is not assignable" );
> #endif
> const ptrdiff_t _Num = __last - __first;
>-if (_Num)
>-  std::__memmove<_IsMove>(__result, __first, _Num);
>+if (!_Num)
>+return __result + _Num;
>+//since before C++20, we do not have [[likely]] attribute. We need to do it 
>manually
>+std::__memmove<_IsMove>(__result, __first, _Num);
> return __result + _Num;
>   }
> };
>-
>+#endif
>   // Helpers for streambuf iterators (either istream or ostream).
>   // NB: avoid including , relatively large.
>   template
>@@ -491,11 +518,41 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>   typedef typename iterator_traits<_II>::value_type _ValueTypeI;
>   typedef typename iterator_traits<_OI>::value_type _ValueTypeO;
>   typedef typename iterator_traits<_II>::iterator_category _Category;
>+#ifdef __cpp_lib_concepts
>+  if constexpr(
>+  ((!is_volatile_v>)&&
>+  is_trivially_copyable_v<_ValueTypeI>)&&
>+  ((!is_volatile_v>)&&
>+  is_trivially_copyable_v<_ValueTypeO>)&&
>+  contiguous_iterator<_II>&&
>+  contiguous_iterator<_OI>&&
>+  (same_as<_ValueTypeI,_ValueTypeO>
>+  ||(integral<_ValueTypeI>&&integral<_ValueTypeO>&&
>+  sizeof(_ValueTypeI)==sizeof(_ValueTypeO
>+  {
>+using __assignable = conditional<_IsMove,
>+ is_move_assignable<_OI>,
>+is_copy_assignable<_OI>>;
>+static_assert( __assignable::type::value, "result type is not 
>assignable" );
>+ptrdiff_t const _Num = __last - __first;
>+if (_Num)
>+#ifdef __has_cpp_attribute(likely)
>+//This if statement is by default bad since it affects CPU pipeline.
>+//needs likely attribute or the branch misprediction pen

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #25 from fdlbxtqi  ---
Created attachment 47560
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47560&action=edit
forgot to_address

2nd patch

I am going to run testsuites

[Bug c++/93095] New: Build Latest GCC fail ../../gcc/gcc/gimple-fold.c:4146:8: error: expected unqualified-id before ‘throws’

[euloanty at live dot com]

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

Bug ID: 93095
   Summary: Build Latest GCC fail
../../gcc/gcc/gimple-fold.c:4146:8: error: expected
unqualified-id before ‘throws’
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: euloanty at live dot com
  Target Milestone: ---

g++ -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/home/cqwrteur/gcc-build/./gmp -I/home/cqwrteur/gcc/gmp
-I/home/cqwrteur/gcc-build/./mpfr/src -I/home/cqwrteur/gcc/mpfr/src
-I/home/cqwrteur/gcc/mpc/src  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/gcc/../libbacktrace -I/home/cqwrteur/gcc-build/./isl/include
-I/home/cqwrteur/gcc/isl/include  -o gimple-loop-versioning.o -MT
gimple-loop-versioning.o -MMD -MP -MF ./.deps/gimple-loop-versioning.TPo
../../gcc/gcc/gimple-loop-versioning.cc
g++ -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/home/cqwrteur/gcc-build/./gmp -I/home/cqwrteur/gcc/gmp
-I/home/cqwrteur/gcc-build/./mpfr/src -I/home/cqwrteur/gcc/mpfr/src
-I/home/cqwrteur/gcc/mpc/src  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/gcc/../libbacktrace -I/home/cqwrteur/gcc-build/./isl/include
-I/home/cqwrteur/gcc/isl/include  -o gimple-low.o -MT gimple-low.o -MMD -MP -MF
./.deps/gimple-low.TPo ../../gcc/gcc/gimple-low.c
../../gcc/gcc/gimple-fold.c: In function ‘void
fold_builtin_atomic_compare_exchange(gimple_stmt_iterator*)’:
../../gcc/gcc/gimple-fold.c:4146:8: error: expected unqualified-id before
‘throws’
 4146 |   bool throws = false;
  |^~
../../gcc/gcc/gimple-fold.c:4174:7: error: expected primary-expression before
‘throws’
 4174 |   throws = true;
  |   ^~
../../gcc/gcc/gimple-fold.c:4185:11: error: expected primary-expression before
‘throws’
 4185 |   if (throws)
  |   ^~
../../gcc/gcc/gimple-fold.c:4185:11: error: expected ‘)’ before ‘throws’
 4185 |   if (throws)
  |  ~^~
  |   )
../../gcc/gcc/gimple-fold.c:4197:7: error: expected primary-expression before
‘throws’
 4197 |   if (throws && oldlhs == NULL_TREE)
  |   ^~
../../gcc/gcc/gimple-fold.c:4197:7: error: expected ‘)’ before ‘throws’
 4197 |   if (throws && oldlhs == NULL_TREE)
  |  ~^~
  |   )
g++ -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/home/cqwrteur/gcc-build/./gmp -I/home/cqwrteur/gcc/gmp
-I/home/cqwrteur/gcc-build/./mpfr/src -I/home/cqwrteur/gcc/mpfr/src
-I/home/cqwrteur/gcc/mpc/src  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/gcc/../libbacktrace -I/home/cqwrteur/gcc-build/./isl/include
-I/home/cqwrteur/gcc/isl/include  -o gimple-pretty-print.o -MT
gimple-pretty-print.o -MMD -MP -MF ./.deps/gimple-pretty-print.TPo
../../gcc/gcc/gimple-pretty-print.c
Makefile:1117: recipe for target 'gimple-fold.o' failed
make[2]: *** [gimple-fold.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from ../../gcc/gcc/coretypes.h:444,
 from ../../gcc/gcc/expmed.c:26:
../../gcc/gcc/machmode.h: In function ‘rtx_def* emit_store_flag_1(rtx,
rtx_code, rtx, rtx, machine_mode, int, int, machine_mode)’:
../../gcc/gcc/machmode.h:546:42: warning: ‘int_mode’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
  546 |? mode_size_inline (mode) : mode_size[mode]);
  |  ^~~~
../../gcc/gcc/expmed.c:5623:19: note: ‘int_mode’ was declared here
 5623 |   scalar_int_mode int_mode;
  |   ^~~~
1make[2]: Leaving directory '/home/cqwrteur/gcc-build/gcc'
Makefile:4373: recipe for target 'al

[Bug libgcc/92988] crtstuff.c:387:21: error: '__dso_handle' undeclared (first use in this function)

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Created attachment 47561
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47561&action=edit
Patch

[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Author: mpolacek
Date: Sun Dec 29 16:44:41 2019
New Revision: 279755

URL: https://gcc.gnu.org/viewcvs?rev=279755&root=gcc&view=rev
Log:
PR c++/88337 - Implement P1327R1: Allow dynamic_cast in constexpr.

This patch implements
.

When build_dynamic_cast realizes that a dynamic_cast needs a run-time check, it
generates a call to __dynamic_cast -- see dyncast.cc in libsupc++ for its
definition.  The gist of my approach is to evaluate such a call at compile
time.

* constexpr.c (cxx_dynamic_cast_fn_p): New function.
(extract_obj_from_addr_offset): New function.
(get_component_with_type): New function.
(cxx_eval_dynamic_cast_fn): New function.
(cxx_eval_call_expression): Call cxx_eval_dynamic_cast_fn for a call
to __dynamic_cast.
(potential_constant_expression_1): Don't give up on
cxx_dynamic_cast_fn_p.
* rtti.c (build_dynamic_cast_1): When creating a call to
__dynamic_cast, use the location of the original expression.

* g++.dg/cpp2a/constexpr-dynamic1.C: New test.
* g++.dg/cpp2a/constexpr-dynamic10.C: New test.
* g++.dg/cpp2a/constexpr-dynamic11.C: New test.
* g++.dg/cpp2a/constexpr-dynamic12.C: New test.
* g++.dg/cpp2a/constexpr-dynamic13.C: New test.
* g++.dg/cpp2a/constexpr-dynamic14.C: New test.
* g++.dg/cpp2a/constexpr-dynamic15.C: New test.
* g++.dg/cpp2a/constexpr-dynamic16.C: New test.
* g++.dg/cpp2a/constexpr-dynamic17.C: New test.
* g++.dg/cpp2a/constexpr-dynamic2.C: New test.
* g++.dg/cpp2a/constexpr-dynamic3.C: New test.
* g++.dg/cpp2a/constexpr-dynamic4.C: New test.
* g++.dg/cpp2a/constexpr-dynamic5.C: New test.
* g++.dg/cpp2a/constexpr-dynamic6.C: New test.
* g++.dg/cpp2a/constexpr-dynamic7.C: New test.
* g++.dg/cpp2a/constexpr-dynamic8.C: New test.
* g++.dg/cpp2a/constexpr-dynamic9.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic1.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic10.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic11.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic12.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic13.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic14.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic15.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic16.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic17.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic2.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic3.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic4.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic5.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic6.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic7.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic8.C
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/rtti.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88337] Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of constexpr restrictions.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Marek Polacek  ---
Implemented in GCC 10.

[Bug c++/55004] [meta-bug] constexpr issues

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 88337, which changed state.

Bug 88337 Summary: Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of 
constexpr restrictions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug libgomp/93066] libgomp/target.c:525:46: error: expected expression before ')' token

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
Created attachment 47562
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47562&action=edit
Patch

I'm fine with the proposed changes to target.c but I think we need the include
fix as it's needed for other packages:
https://community.hpe.com/t5/Languages-and-Scripting/SIZE-MAX-undefined/td-p/4798688#

[Bug c++/88323] implement C++20 language features.

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 88337, which changed state.

Bug 88337 Summary: Implement P1002R1, P1327R1, P1330R0, C++20 relaxations of 
constexpr restrictions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/93096] New: detect [class.cdtor]/6 UB in constexpr dynamic_cast

[mpolacek at gcc dot gnu.org]

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

Bug ID: 93096
   Summary: detect [class.cdtor]/6 UB in constexpr dynamic_cast
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

We should detect the UB here:

struct V {
  virtual void f();
};

struct A : V { };

struct B : V {
  constexpr B(V*, A*);
};

struct D : A, B {
  constexpr D() : B((A*)this, this) { } 
};

constexpr B::B(V* v, A* a)
{
  // undefined behavior, a has type A*, A not a base of B
  dynamic_cast(a);
}

constexpr D d;

but currently we don't.  This is
.  See
 for another testcase
and possible approaches how to handle this.

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[ch3root at openwall dot com]

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

--- Comment #35 from Alexander Cherepanov  ---
What remains in this pr is the original problem.

1. The best way to demonstrate that there is indeed a bug here is probably to
compare representation of pointers directly:

--
#include 
#include 

__attribute__((noipa)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }

int main()
{
int x[5];
int y[2];

void *p = &x;
void *q = &y + 1;

printf("val1: %d\n", p == q);
printf("repr: %d\n", memcmp(&p, &q, sizeof(void *)) == 0);

opaque(&p); // move the next comparison to runtime
printf("val2: %d\n", p == q);

opaque(q);
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
val1: 0
repr: 1
val2: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191229 (experimental)
--

C11, 6.2.6.1p4: "Two values (other than NaNs) with the same object
representation compare equal". Our pointers are not NaNs and have the same
representation so should compare equal.

DR 260 allows one to argue that representation of these pointers could change
right between the checks but IMHO this part of DR 260 is just wrong as it makes
copying objects byte-by-byte impossible. See
https://bugs.llvm.org/show_bug.cgi?id=44188 for a nice illustration.

While at it, the testcase also demonstrates that the comparison `p == q` is
unstable.

I'm not taking sides here, just stating that the standard and the compiler
disagree.

2. C++ at some point made results of the discussed comparison unspecified --
https://eel.is/c++draft/expr.eq#3.1 . According to the DR linked to in comment
27, it's done to make the definition usable at compile time. Perhaps
harmonization of the standards should move in this direction, not vice versa.

3. OTOH clang was fixed to be complying with C11.

4. What seems missing in the discussion is a clear description of benefits of
the current gcc's approach. Does it make some optimizations easier to
implement? Does it enable other optimizations?
Obviously, it could be used to fold `a + i == b` to `0` if `a` and `b` are two
different known arrays and `i` is unknown (or known to be exactly the length of
`a`). But this is probably not helpful for aliasing analysis as AA doesn't deal
with past-the-end pointers. And optimization of loops like in comment 19 is
probably not superhelpful too:-)

[Bug libgomp/93097] New: Wrong OpenMP version reported

[build+...@de-korte.org]

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

Bug ID: 93097
   Summary: Wrong OpenMP version reported
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: build+...@de-korte.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Currently, version 201511 is reported in _OPENMP, which is OpenMP 4.5. The
actual version of OpenMP is 5, so version 201811 should be reported instead.

Offending line in libgomp/env.c is 1170:

-  fputs ("  _OPENMP = '201511'\n", stderr);
+  fputs ("  _OPENMP = '201811'\n", stderr);

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

[arthur.j.odwyer at gmail dot com]

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

Arthur O'Dwyer  changed:

   What|Removed |Added

 CC||arthur.j.odwyer at gmail dot 
com

--- Comment #6 from Arthur O'Dwyer  ---
(I got here from
https://stackoverflow.com/questions/47464819/uninitialized-copy-memcpy-memmove-optimization)

Jonathan, you wrote:
> The point of the condition is to decide whether to use std::copy, because for 
> trivially-copyable types that is optimized to memmove. But unlike 
> std::uninitialized_copy, std::copy calls no constructors, so the type must be 
> trivially default constructible, and if an exception is thrown, it calls no 
> destructors, so the type must be trivially destructible as well. So we can 
> only use the memmove optimization for types which [...]

What do you mean "if an exception is thrown"? If we call std::copy from here,
then it's because we are taking the memmove path. memmove never throws
exceptions, so how can we be worried about what happens "if an exception is
thrown"?

That is, the following code 100% definitely never attempts to destroy a `B`
object, so why does it matter that `B`'s destructor is non-trivial?

// https://godbolt.org/z/w7nTe5
struct A {
int i;
A() = default;
A(const A&) = default;
~A() = default;
};
struct B {
int i;
B() = default;
B(const B&) = default;
~B() {}
};

void copyAs(A *p, A *q, int n) {
std::uninitialized_copy(p, p+n, q);  // successfully uses memmove
}
void copyBs(B *p, B *q, int n) {
std::uninitialized_copy(p, p+n, q);  // fails to use memmove
}

[Bug c++/93095] Build Latest GCC fail ../../gcc/gcc/gimple-fold.c:4146:8: error: expected unqualified-id before ‘throws’

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-12-29
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce and don't see anything problematic on that code.
Unless e.g. the system headers are defining throws as a macro, can you e.g.
attach preprocessed gimple-fold.ii?  (E.g. do cd gcc; make gimple-fold.o
and cut'n'paste the command line, replace -c with -E -dD)?

[Bug target/93094] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7433

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-29
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r272239.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #26 from Bernd Edlinger  ---
(In reply to fdlbxtqi from comment #2)
> Also find a bug of __memmove
> 
>   /*
>* A constexpr wrapper for __builtin_memmove.
>* @param __num The number of elements of type _Tp (not bytes).
>*/
>   template
> _GLIBCXX14_CONSTEXPR
> inline void*
> __memmove(_Tp* __dst, const _Tp* __src, size_t __num)
> {
> #ifdef __cpp_lib_is_constant_evaluated
>   if (std::is_constant_evaluated())
>   {
> for(; __num > 0; --__num)
>   {
> if constexpr (_IsMove)
>   *__dst = std::move(*__src);
> else
>   *__dst = *__src;
> ++__src;
> ++__dst;
>   }
> return __dst;
>   }
>   else
> #endif
>   return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
>   return __dst;
> }
> 
> The last 2nd line return __dst is wrong. It should not exist.

Sorry, I don't know what this function is all about.
But to me the code in the ifdef looks totally bogus.
First it returns __dst+__num, while memmove is sopposed
to return __dst, and is is somehow clear that
__dst and __src do not overlap?

because if they do the loop would overwite the __dst buffer before
__src is fully copied?

[Bug target/93094] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7433

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Scalar MASK_STORE really shouldn't appear in the IL except in the copy of the
loop intended for vectorization only (when it is transformed into vectorized
MASK_STORE).  So I'm afraid the above change leaks the loop intended for
vectorization only into the IL somehow.

[Bug tree-optimization/93098] [10 Regression] ICE with negative shifter

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug tree-optimization/93098] New: [10 Regression] ICE with negative shifter

[pinskia at gcc dot gnu.org]

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

Bug ID: 93098
   Summary: [10 Regression] ICE with negative shifter
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Even though it is undefined code, we should not ICE on this code.
Try with -O2:
typedef unsigned long long uint64_t;
   int popcount64c_1 (uint64_t x)
   {
 x -= (x >> -1) & 0xULL;
 x = (x & 0xULL) + ((x >> 2) & 0xULL);
 x = (x + (x >> 4)) & 0x0f0f0f0f0f0f0f0fULL;
 return (x * 0x0101010101010101ULL) >> 56;
   }

Found this via inspection of match.pd after I was working on something else and
had the testcase for PR 50193 fails.

[Bug tree-optimization/93098] [10 Regression] ICE with negative shifter

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This was introduced with r276721 .

[Bug tree-optimization/93055] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Created attachment 47563
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47563&action=edit
fixed testcase

I have verified that building with 

g++ -O3 -march=bdver1 -fno-prefetch-loop-arrays ~/stepanov_vector.ii

gets me the lea into internal loop. This does not happen with gcc9.

[Bug c++/92745] [8/9 Regression] Initializing array with vec4 results in compile error

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Sun Dec 29 23:47:55 2019
New Revision: 279758

URL: https://gcc.gnu.org/viewcvs?rev=279758&root=gcc&view=rev
Log:
PR c++/92745
* g++.dg/cpp0x/initlist118.C: Add -Wno-psabi -w to dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/initlist118.C

[Bug libgomp/93097] Wrong OpenMP version reported

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
That would be incorrect, as OpenMP 5 is only partially supported, there are
various OpenMP 5 features missing, some of them on the compiler side only, but
others (e.g. the allocators) on the library side too.
We can only claim OpenMP 5 support when everything is supported (hopefully in
GCC 11).

[Bug c++/67834] Local references inside comdat groups

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin  ---
Created attachment 47564
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47564&action=edit
Patch

Untested fix.

[Bug c++/93095] Build Latest GCC fail ../../gcc/gcc/gimple-fold.c:4146:8: error: expected unqualified-id before ‘throws’

[euloanty at live dot com]

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

--- Comment #2 from fdlbxtqi  ---
(In reply to Jakub Jelinek from comment #1)
> Can't reproduce and don't see anything problematic on that code.
> Unless e.g. the system headers are defining throws as a macro, can you e.g.
> attach preprocessed gimple-fold.ii?  (E.g. do cd gcc; make gimple-fold.o
> and cut'n'paste the command line, replace -c with -E -dD)?

probably because I am working on a new Herbception's compiler?

BTW, throws should not be an identifier since Herb Sutter is going to use this
as his deterministic exception.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf


I am starting his herbception project.

https://github.com/expnkx/gcc/commit/41109f8f8c8f257e4b0ef691b27b1bcfe3d6d3ab

Can you give me some guidelines about how to start a new C++ branch???
Herbception is a huge change

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

[euloanty at live dot com]

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

--- Comment #27 from fdlbxtqi  ---
(In reply to Bernd Edlinger from comment #26)
> (In reply to fdlbxtqi from comment #2)
> > Also find a bug of __memmove
> > 
> >   /*
> >* A constexpr wrapper for __builtin_memmove.
> >* @param __num The number of elements of type _Tp (not bytes).
> >*/
> >   template
> > _GLIBCXX14_CONSTEXPR
> > inline void*
> > __memmove(_Tp* __dst, const _Tp* __src, size_t __num)
> > {
> > #ifdef __cpp_lib_is_constant_evaluated
> >   if (std::is_constant_evaluated())
> > {
> >   for(; __num > 0; --__num)
> > {
> >   if constexpr (_IsMove)
> > *__dst = std::move(*__src);
> >   else
> > *__dst = *__src;
> >   ++__src;
> >   ++__dst;
> > }
> >   return __dst;
> > }
> >   else
> > #endif
> > return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
> >   return __dst;
> > }
> > 
> > The last 2nd line return __dst is wrong. It should not exist.
> 
> Sorry, I don't know what this function is all about.
> But to me the code in the ifdef looks totally bogus.
> First it returns __dst+__num, while memmove is sopposed
> to return __dst, and is is somehow clear that
> __dst and __src do not overlap?
> 
> because if they do the loop would overwite the __dst buffer before
> __src is fully copied?

Nope. It is C++20's new feature if(std::is_constant_evaluated()) which allows
you to write functions can be used both in compile and runtime.

[Bug c++/93095] Build Latest GCC fail ../../gcc/gcc/gimple-fold.c:4146:8: error: expected unqualified-id before ‘throws’

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to fdlbxtqi from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > Can't reproduce and don't see anything problematic on that code.
> > Unless e.g. the system headers are defining throws as a macro, can you e.g.
> > attach preprocessed gimple-fold.ii?  (E.g. do cd gcc; make gimple-fold.o
> > and cut'n'paste the command line, replace -c with -E -dD)?
> 
> probably because I am working on a new Herbception's compiler?

oh.  So if that is the case, then you need to have a list of reserved
identifiers and start changing them.  But that change should go in at the
begining of stage 1.


> ...
> Can you give me some guidelines about how to start a new C++ branch???
> Herbception is a huge change

There are four ways:
1) have a svn branch (https://gcc.gnu.org/svn.html)
2) have a git only branch (https://gcc.gnu.org/wiki/GitMirror )
3) wait for the svn moved over to git and make a git branch.
4) have a local git branch which can be rebased on the new git after the move
has happened.

[Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO

[fxue at gcc dot gnu.org]

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

fxue at gcc dot gnu.org changed:

   What|Removed |Added

 CC||fxue at gcc dot gnu.org

--- Comment #5 from fxue at gcc dot gnu.org ---
I guess some situation is missed in self_recursively_generated_p(), this causes
propagation along scc explode.

[Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO

[fxue at gcc dot gnu.org]

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

--- Comment #6 from fxue at gcc dot gnu.org ---
Could you share how you build clang with PGO, and train workload?

[Bug target/93082] macOS Authorization.h needs fixinclude

[mcccs at gmx dot com]

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

--- Comment #2 from mcccs at gmx dot com ---
Reported on the "other side" https://bugs.llvm.org/show_bug.cgi?id=44406

Changing it to enum works too, my only doubt is that it has a different width
and sign (but better than not compiling)

Updated patch, thank you Andrew:

fix = {
hackname  = darwin_authorization;
mach  = "*-*-darwin*";
files = Frameworks/Security.framework/Headers/Authorization.h;
select=
"static const size_t kAuthorizationExternalFormLength = 32;\n";
c_fix = format;
c_fix_arg =
"enum { kAuthorizationExternalFormLength = 32 };\n";
test_text =
"static const size_t kAuthorizationExternalFormLength = 32;\n";
};

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[rguenther at suse dot de]

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

--- Comment #36 from rguenther at suse dot de  ---
On December 29, 2019 6:42:55 PM GMT+01:00, ch3root at openwall dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
>
>--- Comment #35 from Alexander Cherepanov 
>---
>What remains in this pr is the original problem.
>
>1. The best way to demonstrate that there is indeed a bug here is
>probably to
>compare representation of pointers directly:
>
>--
>#include 
>#include 
>
>__attribute__((noipa)) // imagine it in a separate TU
>static void *opaque(void *p) { return p; }
>
>int main()
>{
>int x[5];
>int y[2];
>
>void *p = &x;
>void *q = &y + 1;
>
>printf("val1: %d\n", p == q);
>printf("repr: %d\n", memcmp(&p, &q, sizeof(void *)) == 0);
>
>opaque(&p); // move the next comparison to runtime
>printf("val2: %d\n", p == q);
>
>opaque(q);
>}
>--
>$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
>val1: 0
>repr: 1
>val2: 1
>--
>gcc x86-64 version: gcc (GCC) 10.0.0 20191229 (experimental)
>--
>
>C11, 6.2.6.1p4: "Two values (other than NaNs) with the same object
>representation compare equal". Our pointers are not NaNs and have the
>same
>representation so should compare equal.
>
>DR 260 allows one to argue that representation of these pointers could
>change
>right between the checks but IMHO this part of DR 260 is just wrong as
>it makes
>copying objects byte-by-byte impossible. See
>https://bugs.llvm.org/show_bug.cgi?id=44188 for a nice illustration.
>
>While at it, the testcase also demonstrates that the comparison `p ==
>q` is
>unstable.
>
>I'm not taking sides here, just stating that the standard and the
>compiler
>disagree.
>
>2. C++ at some point made results of the discussed comparison
>unspecified --
>https://eel.is/c++draft/expr.eq#3.1 . According to the DR linked to in
>comment
>27, it's done to make the definition usable at compile time. Perhaps
>harmonization of the standards should move in this direction, not vice
>versa.
>
>3. OTOH clang was fixed to be complying with C11.
>
>4. What seems missing in the discussion is a clear description of
>benefits of
>the current gcc's approach. Does it make some optimizations easier to
>implement? Does it enable other optimizations?
>Obviously, it could be used to fold `a + i == b` to `0` if `a` and `b`
>are two
>different known arrays and `i` is unknown

That's indeed the main thing. Basically it allows points-to analysis work at
all in the presence of non-constant offsets. 

 (or known to be exactly the
>length of
>`a`). But this is probably not helpful for aliasing analysis as AA
>doesn't deal
>with past-the-end pointers. And optimization of loops like in comment
>19 is
>probably not superhelpful too:-)