[Bug fortran/90350] ubound ICE on assumed size array even though explicit bound is specified

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Thomas Koenig  ---
Fixen on trunk, closing.

Thanks for the bug report!

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Jeffrey A. Law from comment #6)
> THe whole point of that change is to not require a dominating load if the
> object comes from the stack.

Yeah, but I find that flawed.  One can do it after performing
get_ref_base_and_extent and verifying the offset is const and the whole access
must be within the object, or one could do it with VR verification again
verifying the access is fully within the object, but otherwise it can't be done
and one needs to find dominating load, just the noload needs to handle also
ARRAY_REFs etc., not only MEM_REFs.

libgo patch committed: increase test timeout

[Ian Lance Taylor via Gcc-patches]

This libgo patch by Eric Fang increases the test timeout to 10
minutes, so that tests can pass on some slow machines.  This matches
the timeout for the gc tests.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
483096e3130c468a0e1bd224504b394b42662748
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index e48abcf71d6..5aecee18dd6 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-b76c83f34c006938fe6c3311d949496990bc5db9
+761d68dacefc578e45ff299761f20989aef67823
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/testsuite/gotest b/libgo/testsuite/gotest
index 33f99d77a31..2bd6b5e2b2a 100755
--- a/libgo/testsuite/gotest
+++ b/libgo/testsuite/gotest
@@ -36,7 +36,7 @@ keep=false
 pkgpath=
 prefix=
 dejagnu=no
-timeout=240
+timeout=600
 testname=""
 bench=""
 trace=false

RE: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max

[Zhanghaijian (A)]

Thanks for your suggestions. For safety, I put back 
flag_unsafe_math_optimizations.
Attached please find the v3 patch which is suitable for git am. Bootstrap and 
tested on aarch64 Linux platform.
Is the v3 patch ok?

>From aafcad7ed5d3d156eee1cabbb4958e2cce7899c6 Mon Sep 17 00:00:00 2001
From: z00219097 
Date: Fri, 24 Apr 2020 08:56:25 +0800
Subject: [PATCH] rtl combine should consider NaNs when generate fp min/max
 [PR94708]

As discussed on PR94708, it's unsafe for rtl combine to generate fp
min/max under -funsafe-math-optimizations, considering NaNs. In
addition to flag_unsafe_math_optimizations check, we also need to
do extra mode feature testing here: && !HONOR_NANS (mode)
&& !HONOR_SIGNED_ZEROS (mode)

2020-04-24  Haijian Zhang 

gcc/
PR rtl-optimization/94708
* combine.c (simplify_if_then_else): Add check for
!HONOR_NANS (mode) && !HONOR_SIGNED_ZEROS (mode).
gcc/testsuite/
PR fortran/94708
* gfortran.dg/pr94708.f90: New test.
---
 gcc/ChangeLog |  6 ++
 gcc/combine.c |  5 -
 gcc/testsuite/ChangeLog   |  5 +
 gcc/testsuite/gfortran.dg/pr94708.f90 | 13 +
 4 files changed, 28 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr94708.f90

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index cf97cfed626..6032e681d7f 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-24  Haijian Zhang 
+
+   PR rtl-optimization/94708
+   * combine.c (simplify_if_then_else): Add check for
+   !HONOR_NANS (mode) && !HONOR_SIGNED_ZEROS (mode).
+
 2020-04-23  Martin Sebor  
 
PR driver/90983
diff --git a/gcc/combine.c b/gcc/combine.c
index cff76cd3303..4c324f38660 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -6643,7 +6643,10 @@ simplify_if_then_else (rtx x)
 
   /* Look for MIN or MAX.  */
 
-  if ((! FLOAT_MODE_P (mode) || flag_unsafe_math_optimizations)
+  if ((! FLOAT_MODE_P (mode)
+   || (flag_unsafe_math_optimizations
+  && !HONOR_NANS (mode)
+  && !HONOR_SIGNED_ZEROS (mode)))
   && comparison_p
   && rtx_equal_p (XEXP (cond, 0), true_rtx)
   && rtx_equal_p (XEXP (cond, 1), false_rtx)
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 86331cd1211..4d80ee3a3a0 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-24  Haijian Zhang 
+
+   PR fortran/94708
+   * gfortran.dg/pr94708.f90: New test.
+
 2020-04-23  Martin Sebor  
 
PR driver/90983
diff --git a/gcc/testsuite/gfortran.dg/pr94708.f90 
b/gcc/testsuite/gfortran.dg/pr94708.f90
new file mode 100644
index 000..9b5f1389f09
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr94708.f90
@@ -0,0 +1,13 @@
+! { dg-do compile { target aarch64*-*-* } }
+! { dg-options "-O2 -funsafe-math-optimizations -fdump-rtl-combine" }
+
+subroutine f(vara,varb,varc,res)
+  REAL, INTENT(IN) :: vara,varb,varc
+  REAL, INTENT(out) :: res
+
+  res = vara
+  if (res .lt. varb)  res = varb
+  if (res .gt. varc)  res = varc
+end subroutine
+
+! { dg-final { scan-rtl-dump-not "smin" "combine" } }
-- 
2.19.1


-Original Message-
From: Segher Boessenkool [mailto:seg...@kernel.crashing.org] 
Sent: Friday, April 24, 2020 1:05 AM
To: Zhanghaijian (A) 
Cc: Richard Biener ; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp 
min/max

Hi!

On Thu, Apr 23, 2020 at 02:34:03PM +, Zhanghaijian (A) wrote:
> Thanks for your suggestions. I have modified accordingly.
> Attached please find the adapted patch. Bootstrap and tested on aarch64 Linux 
> platform.
> Does the v2 patch look better?
> 
> diff --git a/gcc/combine.c b/gcc/combine.c index 
> cff76cd3303..ad8a385fc48 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -6643,7 +6643,8 @@ simplify_if_then_else (rtx x)
>  
>/* Look for MIN or MAX.  */
>  
> -  if ((! FLOAT_MODE_P (mode) || flag_unsafe_math_optimizations)
> +  if ((! FLOAT_MODE_P (mode)
> +   || (!HONOR_NANS (mode) && !HONOR_SIGNED_ZEROS (mode)))
>&& comparison_p
>&& rtx_equal_p (XEXP (cond, 0), true_rtx)
>&& rtx_equal_p (XEXP (cond, 1), false_rtx)

> > The GENERIC folding routine producing min/max is avoiding it when 
> > those are honored (and it doesn't check 
> > flag_unsafe_math_optmizations at all).
> > 
> > Certainly the patch is an incremental correct fix, with the flag 
> > testing replaced by the mode feature testing.
> 
> Yeah, and the SMAX etc. definition is so weak that it isn't obvious 
> that this combine transform is valid without this flag.  We can or 
> should fix that, of course :-)

Please put flag_unsafe_math_optimizations back?  It isn't clear at all that we 
do not need it.

Also, do you have a changelog entry?


Segher


pr94708-v3.patch
Description: pr94708-v3.patch

[Bug target/94740] ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

[acsawdey at gcc dot gnu.org]

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

--- Comment #1 from acsawdey at gcc dot gnu.org ---
Reduced test case:



struct __attribute__((scalar_storage_order("big-endian"))) {
  int a;
  int b[];
} c;
int d;
int e() { d = c.b[0]; }

[Bug target/94740] New: ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

[acsawdey at gcc dot gnu.org]

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

Bug ID: 94740
   Summary: ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future
-mpcrel -O1
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acsawdey at gcc dot gnu.org
  Target Milestone: ---

Compiler is trunk 3bcdb5dec72b6d7b197821c2b814bc9fc07f4628 on ppc64le power9
host.

~/work/gcc/trunk/build/gcc/xgcc -B/home2/sawdey/work/gcc/trunk/build/gcc
/home2/sawdey/work/gcc/trunk/gcc/gcc/testsuite/gcc.dg/sso/t5.c -mcpu=future
-mpcrel -O1 -lm -o ./t5.exe
during RTL pass: reload
/home2/sawdey/work/gcc/trunk/gcc/gcc/testsuite/gcc.dg/sso/t5.c: In function
‘main’:
/home2/sawdey/work/gcc/trunk/gcc/gcc/testsuite/gcc.dg/sso/t5.c:73:1: internal
compiler error: in set_address_disp, at rtlanal.c:6254
   73 | }
  | ^
0x10a50ca3 set_address_disp
../../gcc/gcc/rtlanal.c:6254
0x10a50ca3 set_address_disp
../../gcc/gcc/rtlanal.c:6252
0x10a50ca3 decompose_automod_address
../../gcc/gcc/rtlanal.c:6297
0x10a50ca3 decompose_address(address_info*, rtx_def**, machine_mode, unsigned
char, rtx_code)
../../gcc/gcc/rtlanal.c:6457
0x10887973 process_address_1
../../gcc/gcc/lra-constraints.c:3367
0x10889b9b process_address
../../gcc/gcc/lra-constraints.c:3641
0x10889b9b curr_insn_transform
../../gcc/gcc/lra-constraints.c:3956
0x1088f95f lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:5029
0x1087119f lra(_IO_FILE*)
../../gcc/gcc/lra.c:2440
0x10810b9b do_reload
../../gcc/gcc/ira.c:5523
0x10810b9b execute
../../gcc/gcc/ira.c:5709
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/94739] New: GCC won't build on CET enabled Linux OS

[hjl.tools at gmail dot com]

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

Bug ID: 94739
   Summary: GCC won't build on CET enabled Linux OS
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

[hjl@gnu-tgl-1 build-x86_64-linux]$ readelf -n /bin/ld 2>&1|more

Displaying notes found in: .note.gnu.property
  OwnerData sizeDescription
  GNU  0x0030   NT_GNU_PROPERTY_TYPE_0
  Properties: x86 feature: IBT, SHSTK
x86 ISA used: CMOV, SSE, SSE2
x86 feature used: x86, XMM

and I got

build-x86_64-linux/./gcc/liblto_plugin.so: indirect branch tracking isn't
enabled: Invalid argument
collect2: error: ld returned 1 exit status
make[7]: *** [Makefile:994: libgcc_s.so] Error 1

Since ld is CET enabled, dlopen failed on liblto_plugin.so since it isn't CET
enabled.  On CET enabled Linux OS, we need to always enable CET on
liblto_plugin.so.

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
THe whole point of that change is to not require a dominating load if the
object comes from the stack.

We conditionally load from the same location, then have a PHI which selects
that loaded value or "1" and we store the result.  That's precisely what is
supposed to be happening.

The loop in question looks like:

;;   basic block 3, loop depth 1
;;pred:   2
;;6
  # ivtmp.13_9 = PHI <0(2), ivtmp.13_7(6)>
  _4 = MEM[base: in_21(D), index: ivtmp.13_9, step: 8, offset: 0B];
  if (_4 == 0B)
goto ; [5.50%]
  else
goto ; [94.50%]
;;succ:   13
;;4

;;   basic block 4, loop depth 1
;;pred:   3
  if (ivtmp.13_9 != 2)
goto ; [28.10%]
  else
goto ; [71.90%]
;;succ:   6
;;5

;;   basic block 5, loop depth 1
;;pred:   4
  cstore_32 = MEM[symbol: arr, index: ivtmp.13_9, step: 4, offset: 0B];
;;succ:   6

;;   basic block 6, loop depth 1
;;pred:   5
;;4
  # cstore_31 = PHI 
  MEM[symbol: arr, index: ivtmp.13_9, step: 4, offset: 0B] = cstore_31;
  _40 = (unsigned int) ivtmp.13_9;
  _38 = _40 + 1;
  _37 = (int) _38;
  ivtmp.13_7 = ivtmp.13_9 + 1;
  sum_a_27 = (int) ivtmp.13_7;
  if (n_16(D) > sum_a_27)
goto ; [94.50%]
  else
goto ; [5.50%]
;;succ:   3
;;7

You can see the load from the same stock slot in bb5, the selecting PHI in bb6
and the store in bb6.

THe test in bb4 looks weird and is the source of the problem I believe.

[Bug libstdc++/91807] [9/10 Regression] std::variant with multiple identical types assignment fail to compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug libstdc++/92156] Cannot in-place construct std::any with std::any

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |10.0
 Status|NEW |RESOLVED

--- Comment #5 from Jonathan Wakely  ---
Fixed for GCC 10.

[Bug libstdc++/90415] [9 Regression] std::is_copy_constructible> is incomplete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[9/10 Regression]   |[9 Regression]
   |std::is_copy_constructible< |std::is_copy_constructible<
   |std::tuple> is|std::tuple> is
   |incomplete  |incomplete

--- Comment #14 from Jonathan Wakely  ---
Fixed on master so far, backport to follow soon.

Re: [PATCH][libstd++][PR92156]

[Jonathan Wakely via Gcc-patches]

On 24/04/20 00:20 +0100, Jonathan Wakely wrote:

On 21/04/20 20:58 +0530, kamlesh kumar via Libstdc++ wrote:

added VERIFY in test and changed the template parameter naming.

diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index 6b7e68f0e63..d350d0b2575 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -176,36 +176,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 typename __any_constructible::type;

   /// Construct with a copy of @p __value as the contained object.
-template ,
-  typename _Mgr = _Manager<_Tp>,
-  __any_constructible_t<_Tp, _ValueType&&> = true,
-  enable_if_t::value, bool> = true>
-  any(_ValueType&& __value)
+template ,
+  typename _Mgr = _Manager<_VTp>,
+  enable_if_t::value &&
+  !__is_in_place_type<_VTp>::value, bool> = true>
+  any(_Tp&& __value)
 : _M_manager(&_Mgr::_S_manage)
 {
-_Mgr::_S_create(_M_storage, std::forward<_ValueType>(__value));
-  }
-
-/// Construct with a copy of @p __value as the contained object.
-template ,
-  typename _Mgr = _Manager<_Tp>,
-  enable_if_t<__and_v,
-  __not_>,
-  __not_<__is_in_place_type<_Tp>>>,
-  bool> = false>
-  any(_ValueType&& __value)
-  : _M_manager(&_Mgr::_S_manage)
-  {
-_Mgr::_S_create(_M_storage, __value);
+_Mgr::_S_create(_M_storage, std::forward<_Tp>(__value));
 }

   /// Construct with an object created from @p __args as the
contained object.


Thanks for the patch, the changes look great ... but the patch is
completely mangled by being pasted into the email body.

You should send patches as attachments so gmail doesn't replace tabs
with spaces and break lines (like the comment line above), preventing
the patch from applying.

But I can't use the patch anyway, as you don't have a copyright
assignment for GCC. Would yo be willing to complete an assignment?

See https://gcc.gnu.org/contribute.html#legal for details.

Anyway, that aside ...


diff --git a/libstdc++-v3/testsuite/20_util/any/misc/92156.cc
b/libstdc++-v3/testsuite/20_util/any/misc/92156.cc
new file mode 100644
index 000..df6c9deff1b
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/any/misc/92156.cc
@@ -0,0 +1,39 @@
+// { dg-options "-std=gnu++17" }
+// { dg-do compile }


This dg-do directive means the test is only compiled, not executed.

It should also use an effective-target of c++17 to indicate it isn't
valid for earlier standards:

// { dg-do run { target c++17 } }



+// Copyright (C) 2014-2020 Free Software Foundation, Inc.


As this is a new test its copyright date should be 2020 only.


+//
+// 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
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+int main() {
+auto a = std::any(std::in_place_type, 5);
+VERIFY(std::any_cast(a) == 5);


This test cannot possibly pass. It will throw an exception, because
the type used in the any_cast is not the type of the contained value.


+auto b = std::any(std::in_place_type, {1});
+VERIFY(std::any_cast(b) == 1);


Same here.


+std::any p = std::pair(1, 1);
+VERIFY((std::any_cast>(p) == std::pair(1,1)));


And here.


+std::any t = std::tuple(1);
+VERIFY((std::any_cast>(t) == std::tuple(1)));


And here.

So if I change the test from { dg-do compile } to { dg-do run } I get:

terminate called after throwing an instance of 'std::bad_any_cast'
 what():  bad any_cast
FAIL: 20_util/any/misc/92156.cc execution test


And I also get these because the line numbers have changed (which is
easy to fix):

FAIL: 20_util/any/misc/any_cast_neg.cc  (test for errors, line 461)
FAIL: 20_util/any/misc/any_cast_neg.cc  (test for errors, line 457)
FAIL: 20_util/any/misc/any_cast_neg.cc  (test for errors, line 483)
FAIL: 20_util/any/misc/any_cast_neg.cc  (test for errors, line 501)
FAIL: 20_util/any/misc/any_cast_neg.cc  (test for errors, line 497)
FAIL: 20_util/any/misc/any_cast_neg.cc (test for excess errors)

Was the patch properly tested?



I've used your solution as part of my own fix, and also applied
Ville's suggestions for renaming things and fixing the emplace
members. This attached patch has been tested on powerpc64le-linux and
has now been committed to master. I'll backport it to gcc-9 soon too.

[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:d1462b0782555354b4480e1f46498586d5882972

commit r10-7935-gd1462b0782555354b4480e1f46498586d5882972
Author: Jonathan Wakely 
Date:   Fri Apr 24 00:54:20 2020 +0100

libstdc++: Fix constructor constraints for std::any  (PR 90415)

This removes a non-standard extension to std::any which causes errors
for valid code, due to recursive instantiation of a trait that isn't
supposed to be in the constraints.

It also removes some incorrect constraints on the in_place_type
constructors and emplace members, which were preventing creating a
std::any object with another std::any as the contained value.

2020-04-24  Kamlesh Kumar  
Jonathan Wakely  

PR libstdc++/90415
PR libstdc++/92156
* include/std/any (any): Rename template parameters for consistency
with the standard.
(any::_Decay): Rename to _Decay_if_not_any.
(any::any(T&&):: Remove is_constructible from constraints. Remove
non-standard overload.
(any::any(in_place_type_t, Args&&...))
(any::any(in_place_type_t, initializer_list, Args&&...))
(any::emplace(Args&&...))
(any::emplace(initializer_list, Args&&...)):
Use decay_t instead of _Decay.
* testsuite/20_util/any/cons/90415.cc: New test.
* testsuite/20_util/any/cons/92156.cc: New Test.
* testsuite/20_util/any/misc/any_cast_neg.cc: Make dg-error
directives
more robust.
* testsuite/20_util/any/modifiers/92156.cc: New test.

[Bug libstdc++/92156] Cannot in-place construct std::any with std::any

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:d1462b0782555354b4480e1f46498586d5882972

commit r10-7935-gd1462b0782555354b4480e1f46498586d5882972
Author: Jonathan Wakely 
Date:   Fri Apr 24 00:54:20 2020 +0100

libstdc++: Fix constructor constraints for std::any  (PR 90415)

This removes a non-standard extension to std::any which causes errors
for valid code, due to recursive instantiation of a trait that isn't
supposed to be in the constraints.

It also removes some incorrect constraints on the in_place_type
constructors and emplace members, which were preventing creating a
std::any object with another std::any as the contained value.

2020-04-24  Kamlesh Kumar  
Jonathan Wakely  

PR libstdc++/90415
PR libstdc++/92156
* include/std/any (any): Rename template parameters for consistency
with the standard.
(any::_Decay): Rename to _Decay_if_not_any.
(any::any(T&&):: Remove is_constructible from constraints. Remove
non-standard overload.
(any::any(in_place_type_t, Args&&...))
(any::any(in_place_type_t, initializer_list, Args&&...))
(any::emplace(Args&&...))
(any::emplace(initializer_list, Args&&...)):
Use decay_t instead of _Decay.
* testsuite/20_util/any/cons/90415.cc: New test.
* testsuite/20_util/any/cons/92156.cc: New Test.
* testsuite/20_util/any/misc/any_cast_neg.cc: Make dg-error
directives
more robust.
* testsuite/20_util/any/modifiers/92156.cc: New test.

[Bug driver/90983] [9 Regression] manual documents `-Wno-stack-usage` flag, but it is unrecognized

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|10.0|
   Target Milestone|--- |9.5
Summary|[9/10 Regression] manual|[9 Regression] manual
   |documents   |documents
   |`-Wno-stack-usage` flag,|`-Wno-stack-usage` flag,
   |but it is unrecognized  |but it is unrecognized

--- Comment #10 from Martin Sebor  ---
Fixed for GCC 10.

[Bug driver/90983] [9/10 Regression] manual documents `-Wno-stack-usage` flag, but it is unrecognized

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:ae962e573ea5063fda7e86f93d9622e64cea9a7e

commit r10-7934-gae962e573ea5063fda7e86f93d9622e64cea9a7e
Author: Martin Sebor 
Date:   Thu Apr 23 17:49:01 2020 -0600

PR driver/90983 - manual documents `-Wno-stack-usage` flag but it is
unrecognized

gcc/ChangeLog:

PR driver/90983
* common.opt (-Wno-frame-larger-than): New option.
(-Wno-larger-than, -Wno-stack-usage): Same.

gcc/testsuite/ChangeLog:

PR driver/90983
* gcc.dg/Wframe-larger-than-3.c: New test.
* gcc.dg/Wlarger-than4.c: New test.
* gcc.dg/Wstack-usage.c: New test.

[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257

[rafael at espindo dot la]

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

--- Comment #13 from Rafael Avila de Espindola  ---
Thank you so much. I can confirm that scylla now builds with gcc master with
just a few fixes on the scylla side (we build with -Werror).

There is a couple of test failures. I will try to reduce those and open new
bugs as appropriate.

Re: [PATCHv2] [Stage1] Refactor tree-ssa-operands.c

[Giuliano Belinassi via Gcc-patches]

Hi, Thank you for your quick review :)

This patch refactors tree-ssa-operands.c by wrapping the global
variables into a class, and also removes unused code.

In this version, we now move struct function and gimple stmt
arguments previously in the methods to the object constructor,
so that we avoid passing down these values to every function.

Bootstrapped and ran the testsuite in Linux x86_64.

gcc/ChangeLog:
2020-04-23  Giuliano Belinassi  

* tree-ssa-operands.c (operands_scanner): New class.
(operands_bitmap_obstack): Remove.
(n_initialized): Remove.
(build_uses): Move to operands_scanner class.
(build_vuse): Same as above.
(build_vdef): Same as above.
(verify_ssa_operands): Same as above.
(finalize_ssa_uses): Same as above.
(cleanup_build_arrays): Same as above.
(finalize_ssa_stmt_operands): Same as above.
(start_ssa_stmt_operands): Same as above.
(append_use): Same as above.
(append_vdef): Same as above.
(add_virtual_operand): Same as above.
(add_stmt_operand): Same as above.
(get_mem_ref_operands): Same as above.
(get_tmr_operands): Same as above.
(maybe_add_call_vops): Same as above.
(get_asm_stmt_operands): Same as above.
(get_expr_operands): Same as above.
(parse_ssa_operands): Same as above.
(finalize_ssa_defs): Same as above.
(build_ssa_operands): Same as above, plus create a C-like wrapper.
(update_stmt_operands): Create an instance of operands_scanner.
>From d6393c00d228164a40985288eae405b5130d676a Mon Sep 17 00:00:00 2001
From: Giuliano Belinassi 
Date: Tue, 21 Apr 2020 19:38:37 -0300
Subject: [PATCH] Refactor tree-ssa-operands.c

Refactor tree-ssa-operands.c by wrapping the global
variables into a class, and also removes unused code.

gcc/ChangeLog:
2020-04-23  Giuliano Belinassi  

	* tree-ssa-operands.c (operands_scanner): New class.
	(operands_bitmap_obstack): Remove.
	(n_initialized): Remove.
	(build_uses): Move to operands_scanner class.
	(build_vuse): Same as above.
	(build_vdef): Same as above.
	(verify_ssa_operands): Same as above.
	(finalize_ssa_uses): Same as above.
	(cleanup_build_arrays): Same as above.
	(finalize_ssa_stmt_operands): Same as above.
	(start_ssa_stmt_operands): Same as above.
	(append_use): Same as above.
	(append_vdef): Same as above.
	(add_virtual_operand): Same as above.
	(add_stmt_operand): Same as above.
	(get_mem_ref_operands): Same as above.
	(get_tmr_operands): Same as above.
	(maybe_add_call_vops): Same as above.
	(get_asm_stmt_operands): Same as above.
	(get_expr_operands): Same as above.
	(parse_ssa_operands): Same as above.
	(finalize_ssa_defs): Same as above.
	(build_ssa_operands): Same as above, plus create a C-like wrapper.
	(update_stmt_operands): Create an instance of operands_scanner.
---
 gcc/tree-ssa-operands.c | 302 
 1 file changed, 185 insertions(+), 117 deletions(-)

diff --git a/gcc/tree-ssa-operands.c b/gcc/tree-ssa-operands.c
index b525ee318a4..5cd5fc05dcc 100644
--- a/gcc/tree-ssa-operands.c
+++ b/gcc/tree-ssa-operands.c
@@ -99,23 +99,107 @@ along with GCC; see the file COPYING3.  If not see
 /* Operand is having its address taken.  */
 #define opf_address_taken (1 << 5)
 
-/* Array for building all the use operands.  */
-static vec build_uses;
+/* Class containing temporary per-stmt state.  */
 
-/* The built VDEF operand.  */
-static tree build_vdef;
+class operands_scanner
+{
+  public:
+operands_scanner (struct function *fun, gimple *statement)
+  {
+	build_vuse = NULL_TREE;
+	build_vdef = NULL_TREE;
+	fn = fun;
+	stmt = statement;
+  }
+
+/* Create an operands cache for STMT.  */
+void build_ssa_operands (void);
+
+/* Verifies SSA statement operands.  */
+DEBUG_FUNCTION bool verify_ssa_operands (void);
+
+  private:
+/* Array for building all the use operands.  */
+auto_vec build_uses;
+
+/* The built VDEF operand.  */
+tree build_vdef;
+
+/* The built VUSE operand.  */
+tree build_vuse;
+
+/* Function which STMT belongs to.  */
+struct function *fn;
+
+/* Statement to work on.  */
+gimple *stmt;
+
+/* Takes elements from build_uses and turns them into use operands of STMT.  */
+inline void finalize_ssa_uses (void);
+
+/* Clear the in_list bits and empty the build array for VDEFs and
+   VUSEs.  */
+inline void cleanup_build_arrays (void);
+
+/* Finalize all the build vectors, fill the new ones into INFO.  */
+inline void finalize_ssa_stmt_operands (void);
+
+/* Start the process of building up operands vectors in INFO.  */
+inline void start_ssa_stmt_operands (void);
+
+/* Add USE_P to the list of pointers to operands.  */
+inline void append_use (tree *use_p);
+
+/* Add VAR to the set of variables that require a VDEF operator.  */
+inline void append_vdef (tree var);
 
-/* The built 

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
All the PR89430 testcases have such a load.

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
+  int cstore_31;
+  int cstore_32;

[local count: 114863530]:
   goto ; [100.00%]

[local count: 1014686026]:
   _1 = (long unsigned int) sum_a_7;
   _2 = _1 * 8;
   _3 = input_21(D) + _2;
   _4 = *_3;
   if (_4 == 0B)
 goto ; [5.50%]
   else
 goto ; [94.50%]

[local count: 958878296]:
   if (sum_a_7 <= 1)
-goto ; [28.10%]
+goto ; [28.10%]
   else
-goto ; [71.90%]
+goto ; [71.90%]

-   [local count: 269444804]:
-  arr[sum_a_7] = 1;
+   [local count: 689433492]:
+  cstore_32 = MEM  [(void *)][sum_a_7];

[local count: 958878296]:
+  # cstore_31 = PHI <1(4), cstore_32(5)>
+  MEM  [(void *)][sum_a_7] = cstore_31;
   sum_a_23 = sum_a_7 + 1;

done by cselim looks just plain wrong, there is no dominating load from that
memory, so even when the variable is an automatic variable, there is no
guarantee it won't be out of bounds and thus crash already on the load, or just
modify random unrelated memory.

Re: [PATCH][libstd++][PR92156]

[Jonathan Wakely via Gcc-patches]

On 21/04/20 20:58 +0530, kamlesh kumar via Libstdc++ wrote:

added VERIFY in test and changed the template parameter naming.

diff --git a/libstdc++-v3/include/std/any b/libstdc++-v3/include/std/any
index 6b7e68f0e63..d350d0b2575 100644
--- a/libstdc++-v3/include/std/any
+++ b/libstdc++-v3/include/std/any
@@ -176,36 +176,23 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  typename __any_constructible::type;

/// Construct with a copy of @p __value as the contained object.
-template ,
-  typename _Mgr = _Manager<_Tp>,
-  __any_constructible_t<_Tp, _ValueType&&> = true,
-  enable_if_t::value, bool> = true>
-  any(_ValueType&& __value)
+template ,
+  typename _Mgr = _Manager<_VTp>,
+  enable_if_t::value &&
+  !__is_in_place_type<_VTp>::value, bool> = true>
+  any(_Tp&& __value)
  : _M_manager(&_Mgr::_S_manage)
  {
-_Mgr::_S_create(_M_storage, std::forward<_ValueType>(__value));
-  }
-
-/// Construct with a copy of @p __value as the contained object.
-template ,
-  typename _Mgr = _Manager<_Tp>,
-  enable_if_t<__and_v,
-  __not_>,
-  __not_<__is_in_place_type<_Tp>>>,
-  bool> = false>
-  any(_ValueType&& __value)
-  : _M_manager(&_Mgr::_S_manage)
-  {
-_Mgr::_S_create(_M_storage, __value);
+_Mgr::_S_create(_M_storage, std::forward<_Tp>(__value));
  }

/// Construct with an object created from @p __args as the
contained object.


Thanks for the patch, the changes look great ... but the patch is
completely mangled by being pasted into the email body.

You should send patches as attachments so gmail doesn't replace tabs
with spaces and break lines (like the comment line above), preventing
the patch from applying.

But I can't use the patch anyway, as you don't have a copyright
assignment for GCC. Would yo be willing to complete an assignment?

See https://gcc.gnu.org/contribute.html#legal for details.

Anyway, that aside ...


diff --git a/libstdc++-v3/testsuite/20_util/any/misc/92156.cc
b/libstdc++-v3/testsuite/20_util/any/misc/92156.cc
new file mode 100644
index 000..df6c9deff1b
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/any/misc/92156.cc
@@ -0,0 +1,39 @@
+// { dg-options "-std=gnu++17" }
+// { dg-do compile }


This dg-do directive means the test is only compiled, not executed.

It should also use an effective-target of c++17 to indicate it isn't
valid for earlier standards:

// { dg-do run { target c++17 } }



+// Copyright (C) 2014-2020 Free Software Foundation, Inc.


As this is a new test its copyright date should be 2020 only.


+//
+// 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
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+int main() {
+auto a = std::any(std::in_place_type, 5);
+VERIFY(std::any_cast(a) == 5);


This test cannot possibly pass. It will throw an exception, because
the type used in the any_cast is not the type of the contained value.


+auto b = std::any(std::in_place_type, {1});
+VERIFY(std::any_cast(b) == 1);


Same here.


+std::any p = std::pair(1, 1);
+VERIFY((std::any_cast>(p) == std::pair(1,1)));


And here.


+std::any t = std::tuple(1);
+VERIFY((std::any_cast>(t) == std::tuple(1)));


And here.

So if I change the test from { dg-do compile } to { dg-do run } I get:

terminate called after throwing an instance of 'std::bad_any_cast'
  what():  bad any_cast
FAIL: 20_util/any/misc/92156.cc execution test


And I also get these because the line numbers have changed (which is
easy to fix):

FAIL: 20_util/any/misc/any_cast_neg.cc  (test for errors, line 461)
FAIL: 20_util/any/misc/any_cast_neg.cc  (test for errors, line 457)
FAIL: 20_util/any/misc/any_cast_neg.cc  (test for errors, line 483)
FAIL: 20_util/any/misc/any_cast_neg.cc  (test for errors, line 501)
FAIL: 20_util/any/misc/any_cast_neg.cc  (test for errors, line 497)
FAIL: 20_util/any/misc/any_cast_neg.cc (test for excess errors)

Was the patch properly tested?

Re: [PATCH v2] c++: Explicit constructor called in copy-initialization [PR90320]

[Marek Polacek via Gcc-patches]

On Thu, Apr 23, 2020 at 02:48:38PM -0400, Jason Merrill wrote:
> On 4/22/20 11:27 PM, Marek Polacek wrote:
> > This test is rejected with a bogus "use of deleted function" error
> > starting with r225705 whereby convert_like_real/ck_base no longer
> > sets LOOKUP_ONLYCONVERTING for user_conv_p conversions.  This does
> > not seem to be always correct.  To recap, when we have something like
> > T t = x where T is a class type and the type of x is not T or derived
> > from T, we perform copy-initialization, something like:
> >1. choose a user-defined conversion to convert x to T, the result is
> >   a prvalue,
> >2. use this prvalue to direct-initialize t.
> > 
> > In the second step, explicit constructors should be considered, since
> > we're direct-initializing.  This is what r225705 fixed.
> > 
> > In this PR we are dealing with the first step, I think, where explicit
> > constructors should be skipped.  [over.match.copy] says "The converting
> > constructors of T are candidate functions" which clearly eliminates
> > explicit constructors.  But we also have to copy-initialize the argument
> > we are passing to such a converting constructor, and here we should
> > disregard explicit constructors too.
> > 
> > In this testcase we have
> > 
> >V v = m;
> > 
> > and we choose V::V(M) to convert m to V.  But we wrongly choose
> > the explicit M::M(M&) to copy-initialize the argument; it's
> > a better match for a non-const lvalue than the implicit M::M(const M&)
> > but because it's explicit, we shouldn't use it.
> > 
> > When convert_like is processing the ck_user conversion -- the convfn is
> > V::V(M) -- it can see that cand->flags contains LOOKUP_ONLYCONVERTING,
> > but then when we're in build_over_call for this convfn, we have no way
> > to pass the flag to convert_like for the argument 'm', because convert_like
> > doesn't take flags.  So I've resorted to setting need_temporary_p in
> > a ck_rvalue, thus far unused, to signal that we're only interested in
> > non-explicit constructors.
> > 
> > LOOKUP_COPY_PARM looks relevant, but again, it's a LOOKUP_* flag, so
> > can't pass it to convert_like.  DR 899 also seemed related, but that
> > deals with direct-init contexts only.
> > 
> > Does this make sense?
> > 
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > 
> > PR c++/90320
> > * call.c (standard_conversion): Set need_temporary_p if FLAGS demands
> > LOOKUP_ONLYCONVERTING.
> > (convert_like_real) : If a ck_rvalue has
> > need_temporary_p set, or LOOKUP_ONLYCONVERTING into FLAGS.
> > 
> > * g++.dg/cpp0x/explicit13.C: New test.
> > ---
> >   gcc/cp/call.c   | 24 +---
> >   gcc/testsuite/g++.dg/cpp0x/explicit13.C | 14 ++
> >   2 files changed, 31 insertions(+), 7 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit13.C
> > 
> > diff --git a/gcc/cp/call.c b/gcc/cp/call.c
> > index c58231601c9..d802f1a0c2f 100644
> > --- a/gcc/cp/call.c
> > +++ b/gcc/cp/call.c
> > @@ -92,10 +92,10 @@ struct conversion {
> >language standards, e.g. disregarding pointer qualifiers or
> >converting integers to pointers.  */
> > BOOL_BITFIELD bad_p : 1;
> > -  /* If KIND is ck_ref_bind ck_base_conv, true to indicate that a
> > +  /* If KIND is ck_ref_bind or ck_base, true to indicate that a
> >temporary should be created to hold the result of the
> > - conversion.  If KIND is ck_ambig or ck_user, true means force
> > - copy-initialization.  */
> > + conversion.  If KIND is ck_ambig, ck_rvalue, or ck_user, true means
> > + force copy-initialization.  */
> > BOOL_BITFIELD need_temporary_p : 1;
> > /* If KIND is ck_ptr or ck_pmem, true to indicate that a conversion
> >from a pointer-to-derived to pointer-to-base is being performed.  */
> > @@ -1252,6 +1252,8 @@ standard_conversion (tree to, tree from, tree expr, 
> > bool c_cast_p,
> > if (flags & LOOKUP_PREFER_RVALUE)
> > /* Tell convert_like_real to set LOOKUP_PREFER_RVALUE.  */
> > conv->rvaluedness_matches_p = true;
> > +  if (flags & LOOKUP_ONLYCONVERTING)
> > +   conv->need_temporary_p = true;
> 
> Presumably we want the same thing for ck_base?

We actually already set need_temporary_p for ck_base in standard_conversion:
1529   conv->need_temporary_p = !(flags & LOOKUP_NO_TEMP_BIND);

> > @@ -7654,10 +7656,18 @@ convert_like_real (conversion *convs, tree expr, 
> > tree fn, int argnum,
> >  destination [is treated as direct-initialization].  [dcl.init] */
> > flags = LOOKUP_NORMAL;
> > if (convs->user_conv_p)
> > -   /* This conversion is being done in the context of a user-defined
> > -  conversion (i.e. the second step of copy-initialization), so
> > -  don't allow any more.  */
> > -   flags |= LOOKUP_NO_CONVERSION;
> > +   {
> > + /* This conversion is being done in the context of a user-defined
> > +conversion 

[Bug fortran/94737] BIND(C) names are not always treated as case sensitive. Versions < 8 are ok.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org
   Last reconfirmed||2020-04-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||10.0, 8.1.0

--- Comment #1 from kargl at gcc dot gnu.org ---
This also fails with trunk as svn revision 280157.  The following trivial patch
allows your code to compile.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 280157)
+++ gcc/fortran/resolve.c   (working copy)
@@ -2517,8 +2517,14 @@ resolve_global_procedure (gfc_symbol *sym, locus *wher
   gsym = gfc_get_gsymbol (sym->binding_label ? sym->binding_label : sym->name,
  sym->binding_label != NULL);

-  if ((gsym->type != GSYM_UNKNOWN && gsym->type != type))
-gfc_global_used (gsym, where);
+  if (gsym->type != GSYM_UNKNOWN && gsym->type != type)
+{
+  if (sym->binding_label && gsym->binding_label
+ && strcmp (sym->binding_label, gsym->binding_label) != 0)
+   ;
+  else
+   gfc_global_used (gsym, where);
+}

   if ((sym->attr.if_source == IFSRC_UNKNOWN
|| sym->attr.if_source == IFSRC_IFBODY)




Passing the created *.mod file through gunzip shows

3 'func1' 'foo' 'c_func' 1 ((PROCEDURE UNKNOWN-INTENT EXTERNAL-PROC BODY
UNKNOWN 0 0 EXTERNAL FUNCTION IS_BIND_C IS_C_INTEROP
ARRAY_OUTER_DEPENDENCY) () (INTEGER 4 0 1 0 INTEGER ()) 4 0 (5) () 6 ()
() () 0 0)

11 'sub1' 'foo' 'c_Func' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC BODY
UNKNOWN 0 0 EXTERNAL SUBROUTINE IS_BIND_C IS_C_INTEROP
ARRAY_OUTER_DEPENDENCY) () (UNKNOWN 0 0 1 0 UNKNOWN ()) 12 0 (13 14) ()

so I suspect it works.  Probably, need to expand the test to skip the
error path to do comparisons involving sym->name and gsym->name.  Just
details for someone else to consider.

[Bug libstdc++/91630] std::any SFINAE breaks valid code since 9.1

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Jonathan Wakely  ---
Indeed. Thanks, Daniel.

*** This bug has been marked as a duplicate of bug 90415 ***

[Bug libstdc++/90415] [9/10 Regression] std::is_copy_constructible> is incomplete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||alabuzhev at gmail dot com

--- Comment #12 from Jonathan Wakely  ---
*** Bug 91630 has been marked as a duplicate of this bug. ***

Re: [Version 3][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

[David Malcolm via Gcc-patches]

On Thu, 2020-04-23 at 16:05 -0500, Qing Zhao wrote:
> Hi, Richard,
> 
> This is the 3rd version of the patch, updated based on your previous
> comments.
> 
> Please take a look at it and let me know whether it’s okay to commit?
> 
> Thanks a lot for all your help.
> 
> Qing.
> 
> gcc/ChangeLog:
> 
> 2020-04-22  qing zhao  
> 
>   PR c/94230
>   * common.opt: Add -flarge-source-files.
>   * doc/invoke.texi: Document it.
>   * toplev.c (process_options): set line_table-
> >default_range_bits
>   to 0 when flag_large_source_files is true.
> 
> 
> gcc/c-family/ChangeLog:
> 
> 2020-04-22  qing zhao  
> 
>   PR c/94230
>   * c-indentation.c (get_visual_column): Add a hint to use the
> new
>   -flarge-source-files option.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-04-22  qing zhao  
> 
>   PR c/94230
>   * gcc.dg/plugin/location-overflow-test-1.c (fn_1): New message
> to 
>   provide hint to use the new -flarge-source-files option.
> 
> 
> > On Apr 23, 2020, at 1:27 PM, Richard Sandiford <
> > richard.sandif...@arm.com> wrote:
> > 
> > Qing Zhao  writes:
> > > ---
> > > gcc/c-family/c-indentation.c   |  3 +++
> > > gcc/common.opt |  5 +
> > > gcc/doc/invoke.texi| 15
> > > ++-
> > > gcc/testsuite/gcc.dg/plugin/location-overflow-test-1.c |  2 +-
> > > gcc/toplev.c   |  3 +++
> > > 5 files changed, 26 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/gcc/c-family/c-indentation.c b/gcc/c-family/c-
> > > indentation.c
> > > index f737555..7074b10 100644
> > > --- a/gcc/c-family/c-indentation.c
> > > +++ b/gcc/c-family/c-indentation.c
> > > @@ -67,6 +67,9 @@ get_visual_column (expanded_location exploc,
> > > location_t loc,
> > > "%<-Wmisleading-indentation%> is disabled from this
> > > point"
> > > " onwards, since column-tracking was disabled due to"
> > > " the size of the code/headers");
> > > +   inform (loc,
> > > +   "please add %<-flarge-source-files%> to invoke more" 
> > > +   " column-tracking for large source files");
> > >   }
> > >   return false;
> > > }
> > 
> > This should be conditional on !flag_large_source_files.
> > 
> > > diff --git a/gcc/common.opt b/gcc/common.opt
> > > index 4368910..10a3d5b 100644
> > > --- a/gcc/common.opt
> > > +++ b/gcc/common.opt
> > > @@ -1597,6 +1597,11 @@ fkeep-gc-roots-live
> > > Common Undocumented Report Var(flag_keep_gc_roots_live)
> > > Optimization
> > > ; Always keep a pointer to a live memory block
> > > 
> > > +flarge-source-files
> > > +Common Report Var(flag_large_source_files) Init(0)
> > > +Adjust GCC to cope with large source files to provide more
> > > accurate
> > > +column information.
> > > +
> > 
> > I'm having difficulty suggesting wording here, but I think would be
> > good
> > to mention the downside.  How about:
> > 
> > --
> > Improve GCC's ability to track column numbers in large source
> > files,
> > at the expense of slower compilation.
> > --
> > 
> > > floop-parallelize-all
> > > Common Report Var(flag_loop_parallelize_all) Optimization
> > > Mark all loops as parallel.
> > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > > index 96a9516..c6ea9ef 100644
> > > --- a/gcc/doc/invoke.texi
> > > +++ b/gcc/doc/invoke.texi
> > > @@ -574,7 +574,7 @@ Objective-C and Objective-C++ Dialects}.
> > > -fdebug-cpp  -fdirectives-only  -fdollars-in-identifiers  @gol
> > > -fexec-charset=@var{charset}  -fextended-identifiers  @gol
> > > -finput-charset=@var{charset}  -fmacro-prefix-map=@var{old}=@var{
> > > new}  @gol
> > > --fmax-include-depth=@var{depth} @gol
> > > +-fmax-include-depth=@var{depth} -flarge-source-files @gol
> > > -fno-canonical-system-headers  -fpch-deps  -fpch-preprocess  @gol
> > > -fpreprocessed  -ftabstop=@var{width}  -ftrack-macro-
> > > expansion  @gol
> > > -fwide-exec-charset=@var{charset}  -fworking-directory @gol
> > 
> > This should be kept in alphabetical order, so after -finput-
> > charset.
> > 
> > > @@ -14151,6 +14151,19 @@ This option may be useful in conjunction
> > > with the @option{-B} or
> > > perform additional processing of the program source between
> > > normal preprocessing and compilation.
> > > 
> > > +@item -flarge-source-files
> > > +@opindex flarge-source-files
> > > +Adjust GCC to cope with large source files to provide more
> > > accurate
> > > +column information. 
> > > +By default, GCC will lose accurate column information if the
> > > source 
> > > +file is very large.
> > > +If this option is provided, GCC will adapt accordingly to
> > > provide more
> > > +accurate column information. 
> > > +This option may be useful when any user hits the @option{-
> > > Wmisleading-indent} 
> > > +note, "is disabled from this point onwards, since column-
> > > tracking was disabled 
> > > +due to the size 

Re: [PATCH] handle initialized flexible array members in __builtin_object_size [PR92815]

[Martin Sebor via Gcc-patches]

On 4/23/20 9:42 AM, Jeff Law wrote:

On Wed, 2020-04-22 at 15:36 -0600, Martin Sebor via Gcc-patches wrote:

When computing the size of an object with a flexible array member
the object size pass doesn't consider that the initializer of such
an object can result in its size being in excess of the size of
the enclosing type.  As a result, stores into such objects by
string functions causes false positive warnings and can abort
at runtime.

The warnings are an old regression but as more of them make use
of the object size results more of them are affected by the bug.
The abort goes back to when support for _FORTIFY_SOURCE was added.

The same problem has already been independently fixed in GCC 10
for -Warray-bounds which doesn't use the object size checking pass,
but the object size bug still remains.  The attached patch corrects
it as well.

Tested on x86_64-linux.

Do you need to change guarding condition to use decl_init_size instead of
DECL_SIZE_UNIT as well?

  else if (pt_var
&& DECL_P (pt_var)
&& tree_fits_uhwi_p (DECL_SIZE_UNIT (pt_var))
 ^^
&& tree_to_uhwi (DECL_SIZE_UNIT (pt_var)) < offset_limit)
 ^^


It doesn't see that changing it is strictly necessary.  If the tests
above pass and the result doesn't satisfy the conditions because it's
either null or doesn't fit in UHWI it's handled later by returning
false.  With offset_limit set to SIZE_MAX / 2, I don't think the result
can as big as that or bigger: it would imply the whole object, including
its initializer, is bigger than half the address space and GCC rejects
such objects with an error.  I've added another test in the patch to
to verify this.

I do agree it would be better to validate the final result the same
way.  That makes the change a little more intrusive to avoid validating
the size multiple times, but I think it also improves the readability
of the code, so the updated patch does that.  It passes testing on
x86_64-linux.

Let me know which one of the two you prefer, or if you'd rather hold
off until stage 1.

Martin


 {
   *pdecl = pt_var;
   pt_var_size = DECL_SIZE_UNIT (pt_var);
 }

Jeff



PR middle-end/92815 - spurious -Wstringop-overflow writing into a flexible array of an extern struct

gcc/ChangeLog:

	PR middle-end/92815
	* tree-object-size.c (decl_init_size): New function.
	(addr_object_size): Call it.
	* tree.h (last_field): Declare.
	(first_field): Add attribute nonnull.

gcc/testsuite/ChangeLog:

	PR middle-end/92815
	* gcc.dg/Warray-bounds-56.c: Remove xfails.
	* gcc.dg/builtin-object-size-20.c: New test.
	* gcc.dg/builtin-object-size-21.c: New test.

diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-56.c b/gcc/testsuite/gcc.dg/Warray-bounds-56.c
index 399c9b263b3..04c26a659ad 100644
--- a/gcc/testsuite/gcc.dg/Warray-bounds-56.c
+++ b/gcc/testsuite/gcc.dg/Warray-bounds-56.c
@@ -42,8 +42,8 @@ struct Flex f3 = { 3, { 1, 2, 3 } };
 
 NOIPA void test_strcpy_flexarray (void)
 {
-  T (S (0), fx);// { dg-bogus "\\\[-Warray-bounds" "pr92815" { xfail *-*-*} }
-  T (S (9), fx);// { dg-bogus "\\\[-Warray-bounds" "pr92815" { xfail *-*-*} }
+  T (S (0), fx);// { dg-bogus "\\\[-Warray-bounds" "pr92815" }
+  T (S (9), fx);// { dg-bogus "\\\[-Warray-bounds" "pr92815" }
 
   T (S (0), f1);
   T (S (1), f1);// { dg-warning "\\\[-Warray-bounds" }
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-20.c b/gcc/testsuite/gcc.dg/builtin-object-size-20.c
new file mode 100644
index 000..47821c06d76
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-20.c
@@ -0,0 +1,315 @@
+/* PR middle-end/92815 - spurious -Wstringop-overflow writing into
+   a flexible array of an extern struct
+   { dg-do compile }
+   { dg-options "-Wall -fdump-tree-optimized" } */
+
+#define ASSERT(expr) ((expr) ? (void)0 : fail (__LINE__))
+#define bos0(expr) __builtin_object_size (expr, 1)
+#define bos1(expr) __builtin_object_size (expr, 1)
+#define bos2(expr) __builtin_object_size (expr, 2)
+#define bos3(expr) __builtin_object_size (expr, 3)
+
+typedef __INT16_TYPE__ int16_t;
+typedef __INT32_TYPE__ int32_t;
+typedef __INT64_TYPE__ int64_t;
+typedef __SIZE_TYPE__  size_t;
+
+
+extern void fail (int);
+
+
+/* Verify sizes of a struct with a flexible array member and no padding.  */
+
+struct ACX { char n, a[]; };
+
+struct ACX ac0 = { };
+struct ACX ac1 = { 1, { 1 } };
+struct ACX ac2 = { 2, { 1, 2 } };
+struct ACX ac3 = { 3, { 1, 2, 3 } };
+
+extern struct ACX eacx;
+
+void facx (void)
+{
+  ASSERT (bos0 () == sizeof ac0);
+  ASSERT (bos0 () == 2);
+  ASSERT (bos0 () == 3);
+  ASSERT (bos0 () == 4);
+  ASSERT (bos0 () == (size_t)-1);
+
+  ASSERT (bos1 () == sizeof ac0);
+  ASSERT (bos1 () == 2);
+  ASSERT (bos1 () == 3);
+  ASSERT (bos1 () == 4);
+  ASSERT (bos1 () == (size_t)-1);
+
+  ASSERT (bos2 () == sizeof ac0);
+  ASSERT (bos2 () == 

[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:f9f166251f181ddcee64092d89aecbc1166ca706

commit r10-7932-gf9f166251f181ddcee64092d89aecbc1166ca706
Author: Patrick Palka 
Date:   Thu Apr 23 17:29:55 2020 -0400

c++: Lambda in friend of constrained class [PR94645]

In the testcase below, when grokfndecl processes the operator() decl for
the
lambda inside the friend function foo, processing_template_decl is rightly
1,
but template_class_depth on the lambda's closure type incorrectly returns 0
instead of 1.

Since processing_template_decl > template_class_depth, this makes
grokfndecl
think that the operator() has its own set of template arguments, and so we
attach the innermost set of constraints -- those belonging to struct l --
to the
operator() decl.  We then get confused when checking
constraints_satisfied_p on
the operator() because it doesn't have template information and yet has
constraints associated with it.

This patch fixes template_class_depth to return the correct template
nesting
level in cases like these, in that when it hits a friend function it walks
into
the DECL_FRIEND_CONTEXT of the friend rather than into the CP_DECL_CONTEXT.

gcc/cp/ChangeLog:

PR c++/94645
* pt.c (template_class_depth): Walk into the DECL_FRIEND_CONTEXT of
a
friend declaration rather than into its CP_DECL_CONTEXT.

gcc/testsuite/ChangeLog:

PR c++/94645
* g++.dg/cpp2a/concepts-lambda6.C: New test.

[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error since r10-7554-gf1ad7bac76b66257

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #12 from Patrick Palka  ---
Fixed.

[Bug fortran/94738] New: C descriptor passed to Fortran from C apepars to have wrong type information.

[longb at cray dot com]

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

Bug ID: 94738
   Summary: C descriptor passed to Fortran from C apepars to have
wrong type information.
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

> cat main.c
#include 
#include 
#include "ISO_Fortran_binding.h"

int main (int argc, char *argv[]) {

int ret;
int line;
int my_errno;
int i;
CFI_CDESC_T(1) cdesc;
CFI_rank_t rank = 1;
int version = CFI_VERSION;
CFI_attribute_t attribute = CFI_attribute_allocatable;
CFI_type_t typ = CFI_type_double;
CFI_index_t extents[rank];
CFI_index_t lower_bounds[rank];
CFI_index_t upper_bounds[rank];
size_t elem_len; // value doesn't matter
void sub (CFI_cdesc_t *);

for (i = 0; i < rank; i++) {
extents[i] = 100;
lower_bounds[i] = 1;
upper_bounds[i] = 100;
}
ret = CFI_establish ((CFI_cdesc_t *), 0, attribute, typ, elem_len, rank,
extents);
if (ret != CFI_SUCCESS) {
   line = __LINE__;
   goto done;
} 
ret = CFI_allocate ((CFI_cdesc_t *), lower_bounds, upper_bounds,
elem_len);
 if (ret != CFI_SUCCESS) {
line = __LINE__;
goto done;
 }
 sub ((CFI_cdesc_t *) );
 line = 0;

done:

 if (line != 0) {
asm ("hlt");
 }
 return 0;
}

> cat sub.f90
subroutine sub (a) bind (c)
  use,intrinsic :: iso_c_binding
  real(C_double), allocatable :: a(:)
  do i = 1, size(a, 1)
 a(i) = i
  end do
  print *, a
end subroutine sub
> 
> ftn -c sub.f90
> cc main.c sub.o
> ./a.out
At line 7 of file sub.f90 (unit = 6, file = 'stdout')
Internal Error: list_formatted_write(): Bad type


It appears that the C descriptor, after being converted to a Fortran
descriptor, has the wrong type information encoded.

> cc --version
gcc (GCC) 9.3.0 20200312 (Cray Inc.)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

> ftn --version
GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Output from other compilers:

> module swap PrgEnv-gnu PrgEnv-cray
> ftn -c sub.f90
> cc main.c sub.o
>  ./a.out
 1.,  2.,  3.,  4.,  5.,  6.,  7.,  8.,  9.,  10.,  11.,  12.,  13.,  14., 
15.,  16.,  17.,  18.,  19.,  20.,  21.,  22.,  23.,  24.,  25.,  26.,  27., 
28.,  29.,  30.,  31.,  32.,  33.,  34.,  35.,  36.,  37.,  38.,  39.,  40., 
41.,  42.,  43.,  44.,  45.,  46.,  47.,  48.,  49.,  50.,  51.,  52.,  53., 
54.,  55.,  56.,  57.,  58.,  59.,  60.,  61.,  62.,  63.,  64.,  65.,  66., 
67.,  68.,  69.,  70.,  71.,  72.,  73.,  74.,  75.,  76.,  77.,  78.,  79., 
80.,  81.,  82.,  83.,  84.,  85.,  86.,  87.,  88.,  89.,  90.,  91.,  92., 
93.,  94.,  95.,  96.,  97.,  98.,  99.,  100.
> module swap PrgEnv-cray PrgEnv-intel
> ftn -c sub.f90
> cc main.c sub.o
> ./a.out
   1.002.003.00 
   4.005.006.00 
   7.008.009.00 
   10.011.012.0 
   13.014.015.0 
   16.017.018.0 
   19.020.021.0 
   22.023.024.0 
   25.026.027.0 
   28.029.030.0 
   31.032.033.0 
   34.035.036.0 
   37.038.039.0 
   40.041.042.0 
   43.044.045.0 
   46.047.048.0 
   49.050.051.0 
   52.053.054.0 
   55.056.057.0 
   58.059.060.0 
   61.062.063.0 
   64.065.066.0 
   67.068.0

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Looks like we're running past the end of the array with the stores in the loop.

Re: [PATCH] c++: Lambda in friend of constrained class [PR94645]

[Jason Merrill via Gcc-patches]

On 4/23/20 4:09 PM, Patrick Palka wrote:

In the testcase below, when grokfndecl processes the operator() decl for the
lambda inside the friend function foo, processing_template_decl is rightly 1,
but template_class_depth on the lambda's closure type incorrectly returns 0
instead of 1.

Since processing_template_decl > template_class_depth, this makes grokfndecl
think that the operator() has its own set of template arguments, and so we
attach the innermost set of constraints -- those belonging to struct l -- to the
operator() decl.  We then get confused when checking constraints_satisfied_p on
the operator() because it doesn't have template information and yet has
constraints associated with it.

This patch fixes template_class_depth to return the correct template nesting
level in cases like these, so that when it hits a friend function it walks into
the DECL_FRIEND_CONTEXT of the friend rather than into the CP_DECL_CONTEXT.

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on cmcstl2,
range-v3, and fmt libraries.


OK.


gcc/cp/ChangeLog:

PR c++/94645
* pt.c (template_class_depth): Walk into the DECL_FRIEND_CONTEXT of a
friend declaration rather than into its CP_DECL_CONTEXT.

gcc/testsuite/ChangeLog:

PR c++/94645
* g++.dg/cpp2a/concepts-lambda6.C: New test.
---
  gcc/cp/pt.c   |  7 ++-
  gcc/testsuite/g++.dg/cpp2a/concepts-lambda6.C | 19 +++
  2 files changed, 25 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-lambda6.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 0e3e7b2039a..08a35c41007 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -390,7 +390,12 @@ template_class_depth (tree type)
++depth;
  
if (DECL_P (type))

-   type = CP_DECL_CONTEXT (type);
+   {
+ if (tree fctx = DECL_FRIEND_CONTEXT (type))
+   type = fctx;
+ else
+   type = CP_DECL_CONTEXT (type);
+   }
else if (LAMBDA_TYPE_P (type) && LAMBDA_TYPE_EXTRA_SCOPE (type))
type = LAMBDA_TYPE_EXTRA_SCOPE (type);
else
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda6.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda6.C
new file mode 100644
index 000..244421e64ec
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda6.C
@@ -0,0 +1,19 @@
+// PR c++/94632
+// { dg-do compile { target concepts } }
+
+struct unordered_map {
+  int cend() const noexcept;
+};
+
+template  concept HasMapInterface = requires(a t) { t.cend(); };
+
+template  requires HasMapInterface
+struct l {
+  friend void foo(l opt) { ([]() {})(); }
+};
+
+struct p {
+  static unordered_map map();
+};
+
+void g(l *y) { foo(*y); }

Re: [PATCH] c++: zero_init_expr_p of dependent expression

[Jason Merrill via Gcc-patches]

On 4/23/20 4:09 PM, Patrick Palka wrote:

This fixes a ICE coming from mangle.c:write_expression when compiling the
ranges-v3 testsuite; the added testcase is a reduced reproducer of the ICE.

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on the
cmcstl2, fmt and range-v3 libraries.  Does this look OK to commit?


OK.


gcc/cp/ChangeLog:

* tree.c (zero_init_expr_p): Use uses_template_parms instead of
dependent_type_p.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/dependent3.C: New test.
---
  gcc/cp/tree.c   |  2 +-
  gcc/testsuite/g++.dg/cpp0x/dependent3.C | 28 +
  2 files changed, 29 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/dependent3.C

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 090c565c093..8840932dba2 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -4486,7 +4486,7 @@ bool
  zero_init_expr_p (tree t)
  {
tree type = TREE_TYPE (t);
-  if (!type || dependent_type_p (type))
+  if (!type || uses_template_parms (type))
  return false;
if (zero_init_p (type))
  return initializer_zerop (t);
diff --git a/gcc/testsuite/g++.dg/cpp0x/dependent3.C 
b/gcc/testsuite/g++.dg/cpp0x/dependent3.C
new file mode 100644
index 000..caf7e1cd4a4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/dependent3.C
@@ -0,0 +1,28 @@
+// { dg-do compile { target c++11 } }
+
+template
+struct d
+{
+  using e = c;
+};
+
+template
+struct g
+{
+  using h = typename d::e;
+
+  template
+  auto operator()(i, j k) -> decltype(h{k});
+};
+
+template
+void m()
+{
+  int a[1];
+  l{}(a, a);
+}
+
+int main()
+{
+  m>();
+}

Re: Not usable email content encoding

[Tom Tromey]

> "Segher" == Segher Boessenkool  writes:

Segher> My point was that this should *never* be part of patches, already.

FWIW, I use a few scripts so that I can keep ChangeLogs as files.
That's what I do when working on gdb.

https://github.com/tromey/git-gnu-changelog

This is easier on the whole, IME, because it means there is no extra
manual step before pushing.

Of course, better would be to remove ChangeLogs entirely (including not
putting anything like them into a commit message), because they are
largely not useful and are just make-work.  Again IMNSHO -- I know there
are some folks who read them, but I basically never have since switching
to git.

Tom

[Bug fortran/94737] New: BIND(C) names are not always treated as case sensitive. Versions < 8 are ok.

[busby1 at llnl dot gov]

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

Bug ID: 94737
   Summary: BIND(C) names are not always treated as case
sensitive.  Versions < 8 are ok.
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: busby1 at llnl dot gov
  Target Milestone: ---

Created attachment 48365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48365=edit
A fortran module.  Compilation instructions (Linux) and output are in it

I will attach a small reproducer for the problem.  There is an obvious
workaround in this case, to use a C name that is unique even if case
sensitivity is disregarded.  I do not have easy access to gfortran version 9 or
10, sorry I cannot report on those.

Thank you,
Lee Busby

[committed] amdgcn: Swap mov_exec operands

[Andrew Stubbs]

I've just committed this patch. It doesn't change anything externally 
visible; it's just a code clean up that prepares the way for another 
patch I have in development.


There's no rule how these non-standard "*_exec" patterns should look, 
but every one but this has the exec-mask operand last except this one.


Andrew
amdgcn: Swap mov_exec operands

Every other *_exec insn has the exec operand last.  This being the other way
around is a cause of bugs, and prevents use in macro templates.

2020-04-23  Andrew Stubbs  

	gcc/
	* config/gcn/gcn-valu.md (mov_exec): Swap the numbers on operands
	2 and 3.
	(mov_exec): Likewise.
	(trunc2_exec): Swap parameters to gen_mov_exec.
	(2_exec): Likewise.

diff --git a/gcc/config/gcn/gcn-valu.md b/gcc/config/gcn/gcn-valu.md
index 24843a0b43e..0422e153cf3 100644
--- a/gcc/config/gcn/gcn-valu.md
+++ b/gcc/config/gcn/gcn-valu.md
@@ -232,16 +232,16 @@
   [(set (match_operand:V_1REG 0 "nonimmediate_operand"	 "=v, v, v, v, v, m")
 	(vec_merge:V_1REG
 	  (match_operand:V_1REG 1 "general_operand"	 "vA, B, v,vA, m, v")
-	  (match_operand:V_1REG 3 "gcn_alu_or_unspec_operand"
+	  (match_operand:V_1REG 2 "gcn_alu_or_unspec_operand"
 			 "U0,U0,vA,vA,U0,U0")
-	  (match_operand:DI 2 "register_operand"	 " e, e,cV,Sv, e, e")))
+	  (match_operand:DI 3 "register_operand"	 " e, e,cV,Sv, e, e")))
(clobber (match_scratch: 4			 "=X, X, X, X,,"))]
   "!MEM_P (operands[0]) || REG_P (operands[1])"
   "@
v_mov_b32\t%0, %1
v_mov_b32\t%0, %1
-   v_cndmask_b32\t%0, %3, %1, vcc
-   v_cndmask_b32\t%0, %3, %1, %2
+   v_cndmask_b32\t%0, %2, %1, vcc
+   v_cndmask_b32\t%0, %2, %1, %3
#
#"
   [(set_attr "type" "vop1,vop1,vop2,vop3a,*,*")
@@ -283,9 +283,9 @@
   [(set (match_operand:V_2REG 0 "nonimmediate_operand" "= v,   v,   v, v, m")
 	(vec_merge:V_2REG
 	  (match_operand:V_2REG 1 "general_operand""vDB,  v0,  v0, m, v")
-	  (match_operand:V_2REG 3 "gcn_alu_or_unspec_operand"
+	  (match_operand:V_2REG 2 "gcn_alu_or_unspec_operand"
 		   " U0,vDA0,vDA0,U0,U0")
-	  (match_operand:DI 2 "register_operand"   "  e,  cV,  Sv, e, e")))
+	  (match_operand:DI 3 "register_operand"   "  e,  cV,  Sv, e, e")))
(clobber (match_scratch: 4		   "= X,   X,   X,,"))]
   "!MEM_P (operands[0]) || REG_P (operands[1])"
   {
@@ -295,11 +295,11 @@
 	case 0:
 	  return "v_mov_b32\t%L0, %L1\;v_mov_b32\t%H0, %H1";
 	case 1:
-	  return "v_cndmask_b32\t%L0, %L3, %L1, vcc\;"
-		 "v_cndmask_b32\t%H0, %H3, %H1, vcc";
+	  return "v_cndmask_b32\t%L0, %L2, %L1, vcc\;"
+		 "v_cndmask_b32\t%H0, %H2, %H1, vcc";
 	case 2:
-	  return "v_cndmask_b32\t%L0, %L3, %L1, %2\;"
-		 "v_cndmask_b32\t%H0, %H3, %H1, %2";
+	  return "v_cndmask_b32\t%L0, %L2, %L1, %3\;"
+		 "v_cndmask_b32\t%H0, %H2, %H1, %3";
 	}
 else
   switch (which_alternative)
@@ -307,11 +307,11 @@
 	case 0:
 	  return "v_mov_b32\t%H0, %H1\;v_mov_b32\t%L0, %L1";
 	case 1:
-	  return "v_cndmask_b32\t%H0, %H3, %H1, vcc\;"
-		 "v_cndmask_b32\t%L0, %L3, %L1, vcc";
+	  return "v_cndmask_b32\t%H0, %H2, %H1, vcc\;"
+		 "v_cndmask_b32\t%L0, %L2, %L1, vcc";
 	case 2:
-	  return "v_cndmask_b32\t%H0, %H3, %H1, %2\;"
-		 "v_cndmask_b32\t%L0, %L3, %L1, %2";
+	  return "v_cndmask_b32\t%H0, %H2, %H1, %3\;"
+		 "v_cndmask_b32\t%L0, %L2, %L1, %3";
 	}
 
 return "#";
@@ -2487,7 +2487,7 @@
 if (mode != mode)
   emit_insn (gen_trunc2_exec (out, inlo, merge, exec));
 else
-  emit_insn (gen_mov_exec (out, inlo, exec, merge));
+  emit_insn (gen_mov_exec (out, inlo, merge, exec));
   }
   [(set_attr "type" "vop2")
(set_attr "length" "4")])
@@ -2539,7 +2539,7 @@
 if (mode != mode)
   emit_insn (gen_2_exec (outlo, in, mergelo, exec));
 else
-  emit_insn (gen_mov_exec (outlo, in, exec, mergelo));
+  emit_insn (gen_mov_exec (outlo, in, mergelo, exec));
 if ('' == 's')
   emit_insn (gen_ashr3_exec (outhi, outlo, GEN_INT (31), mergehi,
    exec));

[Version 3][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

[Qing Zhao via Gcc-patches]

Hi, Richard,

This is the 3rd version of the patch, updated based on your previous comments.

Please take a look at it and let me know whether it’s okay to commit?

Thanks a lot for all your help.

Qing.

gcc/ChangeLog:

2020-04-22  qing zhao  

PR c/94230
* common.opt: Add -flarge-source-files.
* doc/invoke.texi: Document it.
* toplev.c (process_options): set line_table->default_range_bits
to 0 when flag_large_source_files is true.


gcc/c-family/ChangeLog:

2020-04-22  qing zhao  

PR c/94230
* c-indentation.c (get_visual_column): Add a hint to use the new
-flarge-source-files option.

gcc/testsuite/ChangeLog:

2020-04-22  qing zhao  

PR c/94230
* gcc.dg/plugin/location-overflow-test-1.c (fn_1): New message to 
provide hint to use the new -flarge-source-files option.



PR94230.patch
Description: Binary data


> On Apr 23, 2020, at 1:27 PM, Richard Sandiford  
> wrote:
> 
> Qing Zhao  writes:
>> ---
>> gcc/c-family/c-indentation.c   |  3 +++
>> gcc/common.opt |  5 +
>> gcc/doc/invoke.texi| 15 ++-
>> gcc/testsuite/gcc.dg/plugin/location-overflow-test-1.c |  2 +-
>> gcc/toplev.c   |  3 +++
>> 5 files changed, 26 insertions(+), 2 deletions(-)
>> 
>> diff --git a/gcc/c-family/c-indentation.c b/gcc/c-family/c-indentation.c
>> index f737555..7074b10 100644
>> --- a/gcc/c-family/c-indentation.c
>> +++ b/gcc/c-family/c-indentation.c
>> @@ -67,6 +67,9 @@ get_visual_column (expanded_location exploc, location_t 
>> loc,
>>"%<-Wmisleading-indentation%> is disabled from this point"
>>" onwards, since column-tracking was disabled due to"
>>" the size of the code/headers");
>> +  inform (loc,
>> +  "please add %<-flarge-source-files%> to invoke more" 
>> +  " column-tracking for large source files");
>>  }
>>   return false;
>> }
> 
> This should be conditional on !flag_large_source_files.
> 
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index 4368910..10a3d5b 100644
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -1597,6 +1597,11 @@ fkeep-gc-roots-live
>> Common Undocumented Report Var(flag_keep_gc_roots_live) Optimization
>> ; Always keep a pointer to a live memory block
>> 
>> +flarge-source-files
>> +Common Report Var(flag_large_source_files) Init(0)
>> +Adjust GCC to cope with large source files to provide more accurate
>> +column information.
>> +
> 
> I'm having difficulty suggesting wording here, but I think would be good
> to mention the downside.  How about:
> 
> --
> Improve GCC's ability to track column numbers in large source files,
> at the expense of slower compilation.
> --
> 
>> floop-parallelize-all
>> Common Report Var(flag_loop_parallelize_all) Optimization
>> Mark all loops as parallel.
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index 96a9516..c6ea9ef 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -574,7 +574,7 @@ Objective-C and Objective-C++ Dialects}.
>> -fdebug-cpp  -fdirectives-only  -fdollars-in-identifiers  @gol
>> -fexec-charset=@var{charset}  -fextended-identifiers  @gol
>> -finput-charset=@var{charset}  -fmacro-prefix-map=@var{old}=@var{new}  @gol
>> --fmax-include-depth=@var{depth} @gol
>> +-fmax-include-depth=@var{depth} -flarge-source-files @gol
>> -fno-canonical-system-headers  -fpch-deps  -fpch-preprocess  @gol
>> -fpreprocessed  -ftabstop=@var{width}  -ftrack-macro-expansion  @gol
>> -fwide-exec-charset=@var{charset}  -fworking-directory @gol
> 
> This should be kept in alphabetical order, so after -finput-charset.
> 
>> @@ -14151,6 +14151,19 @@ This option may be useful in conjunction with the 
>> @option{-B} or
>> perform additional processing of the program source between
>> normal preprocessing and compilation.
>> 
>> +@item -flarge-source-files
>> +@opindex flarge-source-files
>> +Adjust GCC to cope with large source files to provide more accurate
>> +column information. 
>> +By default, GCC will lose accurate column information if the source 
>> +file is very large.
>> +If this option is provided, GCC will adapt accordingly to provide more
>> +accurate column information. 
>> +This option may be useful when any user hits the 
>> @option{-Wmisleading-indent} 
>> +note, "is disabled from this point onwards, since column-tracking was 
>> disabled 
>> +due to the size of the code/headers", or hits the limit at which columns get
>> +dropped from diagnostics.
>> +
> 
> On a similar vein, how about:
> 
> --
> Adjust GCC to expect large source files, at the expense of slower
> compilation and higher memory usage.
> 
> Specifically, GCC normally tracks both column numbers and line numbers
> within source files and it normally prints both of these 

Re: [PATCH] Mark experimental::net::system_context ctor deleted

[Thomas Rodgers via Gcc-patches]

Tested x86_64_linux.
Commited to master, backported to releases/gcc-9.

Jonathan Wakely writes:

> On 23/04/20 13:09 -0700, Thomas Rodgers via Libstdc++ wrote:
>>
>>  * include/experimental/net/executor: Mark
>>  system_context::system_context() = default.
>
> s/default/delete/ :-)
>
> But the affected function/type/thingie should be named in parens, not
> in the comment i.e.
>
>   * include/experimental/net/executor (system_context): Define default
> constructor as deleted.
>
>>  * testsuite/experimental/net/executor/1.cc: Add new
>>  test for deleted system_context ::system_context().
>
> There's a stray space in there.
>
> It would be more accurate to say "check system_context isn't default
> constructible" because you can't test if it's deleted, as opposed to
> private or just doesn't exist.
>
> OK with those changelog tweaks.
>
> Please backport to gcc-9 too.
>
>
>
>>---
>> libstdc++-v3/include/experimental/executor| 2 +-
>> libstdc++-v3/testsuite/experimental/net/executor/1.cc | 7 +++
>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>
>>diff --git a/libstdc++-v3/include/experimental/executor 
>>b/libstdc++-v3/include/experimental/executor
>>index b5c6e18a19a..fa39eaa0468 100644
>>--- a/libstdc++-v3/include/experimental/executor
>>+++ b/libstdc++-v3/include/experimental/executor
>>@@ -850,7 +850,7 @@ inline namespace v1
>>
>> // construct / copy / destroy:
>>
>>-system_context() = default;
>>+system_context() = delete;
>> system_context(const system_context&) = delete;
>> system_context& operator=(const system_context&) = delete;
>>
>>diff --git a/libstdc++-v3/testsuite/experimental/net/executor/1.cc 
>>b/libstdc++-v3/testsuite/experimental/net/executor/1.cc
>>index 456d620e193..cd0af4b7737 100644
>>--- a/libstdc++-v3/testsuite/experimental/net/executor/1.cc
>>+++ b/libstdc++-v3/testsuite/experimental/net/executor/1.cc
>>@@ -85,9 +85,16 @@ test02()
>>   VERIFY( e == g );
>> }
>>
>>+void
>>+test03()
>>+{
>>+  static_assert( ! 
>>std::is_default_constructible::value, "" );
>>+}
>>+
>> int
>> main()
>> {
>>   test01();
>>   test02();
>>+  test03();
>> }
>> -- 
>>2.25.3
>>
>>
>>

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Jeff Law via Gcc-patches]

On Thu, 2020-04-23 at 15:16 -0500, Segher Boessenkool wrote:
> On Thu, Apr 23, 2020 at 08:40:50AM -0600, Jeff Law wrote:
> > On Thu, 2020-04-23 at 15:07 +0200, Richard Biener wrote:
> > > On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool
> > >  wrote:
> > > > On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote:
> > > > > > > But being stuck with something means no progress...  I know
> > > > > > > very well it's 100 times harder to get rid of something than to
> > > > > > > add something new ontop.
> > > > > > 
> > > > > > Well, what progress do you expect to make?  After expand that is :-)
> > > > > 
> > > > > I'd like the RTL pipeline before RA to shrink significantly, no PRE,
> > > > > no CSE, ...
> > > > 
> > > > RTL CSE for example is very much required to get any good code.  It
> > > > needs to CSE stuff that wasn't there before expand.
> > > 
> > > Sure, but then we should fix that!
> > Exactly.  It's purpose largely becomes dealing with the redundancies exposed
> > by
> > expansion.  ie, address arithmetic and the like.   A lot of its path
> > following
> > code should be throttled back.
> 
> Hrm, I never thought about it like this.  CSE was always there, I never
> stopped to question if we needed it :-)
:-) It's a dog-slow pass that isn't nearly as important as it once was.
> 
> Well, that's cse1 then.  What about cse2?
cse2's original purpose was to clean up after the loop optimizers and it should
be doing even less work than cse1.

The steps in my mind are to see what's left in the first jump pass, then the cse
path following code, then the core of cse itself.  lower-subreg is a wart that
could likely go away if we stop lying about the target's capabilities.

> 
> > > But valid RTL is instructions that are recognized.  Which means
> > > when the target doesn't support an SImode add we may not create
> > > one.  That's instruction selection ;)
> > That's always a point of tension.  But I think that in general continuing to
> > have
> > targets claim to support things they do not (such as double-wordsize
> > arithmetic,
> > logicals, moves, etc) is a mistake.  It made sense at one time, but I think
> > we've
> > got better mechansisms in place to deal with this stuff now.
> 
> Different targets have *very* different insns for add, mul, div, shifts;
> everything really.  Describing this at expand time with two-machine-word
> operations works pretty bloody well, for most or all targets -- this is
> just part of the power of define_expand (but an important part).  And
> define_expand is very very useful, it's the swiss army escape hatch, it
> lets you do everything optabs have a too small mind for.
Absolutely true, but most of the double-word-mode-crap was in there because we
couldn't really describe things like the carry bit.  That's long since been 
fixed
and I bet if we handled just that the vast majority pretending the target has
double-word support becomes unnecessary (and the need for early lower-subreg is
then reduced significantly as well).

And if we look at the number of tricks that are used to do things like optimize
double-word moves in the target files, it's just insane.  If we stop lying and
take advantage of improvements over the last 20 years we end up killing lots of
crappy target code.


> There are two kinds of costing.  The first only says which of A or B is
> better; that can perhaps be done on GIMPLE already, using
> target-specific costs.  The other gives a number to everything, which is
> much harder to get anywhere close to usably correct (what does the
> number even *mean*?  For performance, latency of the whole sequence is
> the most important number, but that is not easy to work with, or what we
> use for say insn_cost).
True.  I'm referring mostly to traditional costing.  ie, given form A & B, which
is preferred for the target.  Full sequence latency is distinct issue, though we
let it bleed into the former (for example by rewriting sequences with similar
costs into a sequence with fewer dependencies).

> 
> > But I think there is a place for adding target dependencies -- and that's at
> > the
> > end of the current gimple pipeline.
> 
> There are a *few* things in GIMPLE that use target costs (ivopts...)
> But yeah, most things should not.
Precisely.  Avoiding target dependencies is the aspiration goal, but we have to
also be sensible and realize that some things really do require a degree of
target knowledge.
> 

Jeff

[Bug target/94630] General bug for changes needed to switch the PowerPC long double default

[meissner at gcc dot gnu.org]

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

--- Comment #7 from Michael Meissner  ---
Created attachment 48364
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48364=edit
Propsed patch to build ibm-ldouble.c with -mno-gnu-attributes

ibm-ldouble.c in libgcc must be compiled without GNU attributes, so that the
__ibm128 functions can be called if long double is IEEE 128-bit.

Re: [committed 0/8] libstdc++: Add/update/fix feature test macros

[Jonathan Wakely via Gcc-patches]

On 22/04/20 22:57 +0100, Jonathan Wakely wrote:

This series of patches fixes a number of omissions and errors in the
feature test macros we define.

Tested powerpc64le-linux, committed to master.

Jonathan Wakely (8):
 libstdc++: Update value of __cpp_lib_jthread macro
 libstdc++: Remove non-standard feature test macros
 libstdc++: Add missing feature test macros
 libstdc++: Rename __cpp_lib_constexpr_invoke macro
 libstdc++: Update __cpp_lib_concepts value
 libstdc++: Do not define __cpp_lib_constexpr_algorithms in 
 libstdc++: Update (and revert) value of __cpp_lib_array_constexpr
 libstdc++: Define __cpp_lib_execution feature test macro



I've backported some of these changes (and other ones related to
feature test macros) to the gcc-9 branch. This means both master and
gcc-9 should define exactly the feature test macros for the features
they support.

With that done, I've also updated the C++20 status table in the docs
(only for master so far, but I'll do it for gcc-9 too).

The attached doc patch has been committed to master.

commit be0363c80f7ac93f1dbd00da6beb9ce0eed96d9d
Author: Jonathan Wakely 
Date:   Thu Apr 23 21:39:33 2020 +0100

libstdc++: Update C++20 library status docs

This reorganises the C++20 status table, grouping the proposals by
category. It also adds more proposals, and documents all the feature
test macros for C++20 library changes.

* doc/xml/manual/status_cxx2020.xml: Update C++20 status table.
* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
index 17f28887119..ade77cbb80b 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2020.xml
@@ -1,8 +1,8 @@
-http://docbook.org/ns/docbook; version="5.0" 
-	 xml:id="status.iso.2020" xreflabel="Status C++ 2020">
+http://docbook.org/ns/docbook; version="5.0"
+   xml:id="status.iso.2020" xreflabel="Status C++ 2020">
 
 
-C++ 202a
+C++ 2020
   
 ISO C++
 2020
@@ -26,17 +26,20 @@ not in any particular release.
 
 
 The following table lists new library features that have been accepted into
-the C++2a working draft. The "Proposal" column provides a link to the
+the C++20 working draft. The "Proposal" column provides a link to the
 ISO C++ committee proposal that describes the feature, while the "Status"
 column indicates the first version of GCC that contains an implementation of
 this feature (if it has been implemented).
-The "SD-6 Feature Test" column shows the corresponding macro or header from
+A dash () in the status column indicates that the changes in the proposal
+either do not affect the code in libstdc++, or the changes are not required for conformance.
+The "SD-6 Feature Test / Notes" column shows the corresponding macro or header from
 http://www.w3.org/1999/xlink; xlink:href="https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations;>SD-6:
-Feature-testing recommendations for C++.
+Feature-testing recommendations for C++ (where applicable)
+or any notes about the implementation.
 
 
-
-C++ 2020 Implementation Status
+
+C++ 2020 Library Features
 
 
 
@@ -48,44 +51,309 @@ Feature-testing recommendations for C++.
   Library Feature
   Proposal
   Status
-  SD-6 Feature Test
+  SD-6 Feature Test / Notes
 
   
 
   
 
 
-Endian just Endian 
-  
-http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0463r1.html;>
-	P0463R1
-	
+  
+Compile-time programming
   
-   8.1 
-  
+
+
+
+Add constexpr modifiers to functions in algorithm and utility Headers 
+  
+http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0202r3.html;>
+P0202R3 
+  
+   10.1 
+   __cpp_lib_constexpr_algorithms = 201703L 
+
+
+
+Constexpr for swap and swap related functions 
+  
+http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0879r0.html;>
+P0879R0 
+  
+   10.1 
+   __cpp_lib_constexpr_algorithms = 201806L 
+
+
+
+Constexpr for std::complex 
+  
+http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0415r1.html;>
+P0415R1 
+  
+   9.1 
+   __cpp_lib_constexpr_complex = 201711L (since 9.4, see Note 1) 
+
+
+
+P0595R2 std::is_constant_evaluated() 
+  
+http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0595r2.html;>
+P0595R2 
+  
+   9.1 
+   __cpp_lib_is_constant_evaluated = 201811L 
+
+
+
+More constexpr containers 
+  
+http://www.w3.org/1999/xlink; xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0784r7.html;>
+  

Re: [committed 7/8] libstdc++: Update (and revert) value of __cpp_lib_array_constexpr

[Jonathan Wakely via Gcc-patches]

On 22/04/20 22:59 +0100, Jonathan Wakely wrote:

This macro should have been updated to 201811 when the last C++20
changes were implemented. However those changes are not enabled for
C++17 mode, so the macro should only have the new value in C++20 mode.

This change ensures that the macro is defined to 201603 for C++17 and
201811 for C++20.

* include/bits/stl_iterator.h (__cpp_lib_array_constexpr): Define
different values for C++17 and C++20, to indicate different feature
sets. Update value for C++20 to indicate P1032R1 support.
* include/std/version (__cpp_lib_array_constexpr): Likewise.
* testsuite/23_containers/array/comparison_operators/constexpr.cc:
Check feature test macro.
* testsuite/23_containers/array/element_access/constexpr_c++17.cc:
New test.
* testsuite/23_containers/array/requirements/constexpr_fill.cc: Check
feature test macro.
* testsuite/23_containers/array/requirements/constexpr_iter.cc: Test
in C++17 mode and check feature test macro.


On second thoughts, changing __cpp_lib_array_constexpr for C++17 was
wrong, it should have been left at 201803.

This partially reverts my previous change related to this macro. The
C++20 constexpr iterator requirements are always met by array:iterator,
because it's just a pointer. So the macro can be set to 201803 even in
C++17 mode.

Tested powerpc64le-linux, committed to master.


commit 40541efe1c063e9ce894b5f11ff727e4aec56e8b
Author: Jonathan Wakely 
Date:   Thu Apr 23 21:39:33 2020 +0100

libstdc++: Change __cpp_lib_array_constexpr for C++17 again

This partially reverts my previous change related to this macro. The
C++20 constexpr iterator requirements are always met by array:iterator,
because it's just a pointer. So the macro can be set to 201803 even in
C++17 mode.

* include/bits/stl_iterator.h (__cpp_lib_array_constexpr): Revert
value for C++17 to 201803L because P0858R0 is supported for C++17.
* include/std/version (__cpp_lib_array_constexpr): Likewise.
* testsuite/23_containers/array/element_access/constexpr_c++17.cc:
Check for value corresponding to P0031R0 features being tested.
* testsuite/23_containers/array/requirements/constexpr_iter.cc:
Check for value corresponding to P0858R0 features being tested.

diff --git a/libstdc++-v3/include/bits/stl_iterator.h b/libstdc++-v3/include/bits/stl_iterator.h
index d7e85b84041..cc0b3e0a766 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -72,7 +72,7 @@
 #if __cplusplus > 201703L
 # define __cpp_lib_array_constexpr 201811L
 #elif __cplusplus == 201703L
-# define __cpp_lib_array_constexpr 201603L
+# define __cpp_lib_array_constexpr 201803L
 #endif
 
 #if __cplusplus > 201703L
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 1beb9aa938e..fa505f25e98 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -123,7 +123,7 @@
 #if _GLIBCXX_HOSTED
 #define __cpp_lib_any 201606L
 #define __cpp_lib_apply 201603
-#define __cpp_lib_array_constexpr 201603L
+#define __cpp_lib_array_constexpr 201803L
 #define __cpp_lib_as_const 201510
 #define __cpp_lib_boyer_moore_searcher 201603
 #define __cpp_lib_chrono 201611
diff --git a/libstdc++-v3/testsuite/23_containers/array/element_access/constexpr_c++17.cc b/libstdc++-v3/testsuite/23_containers/array/element_access/constexpr_c++17.cc
index 56d1cf256be..dd69645833f 100644
--- a/libstdc++-v3/testsuite/23_containers/array/element_access/constexpr_c++17.cc
+++ b/libstdc++-v3/testsuite/23_containers/array/element_access/constexpr_c++17.cc
@@ -24,8 +24,6 @@
 # error "Feature test macro for array constexpr is missing in "
 #elif __cpp_lib_array_constexpr < 201603L
 # error "Feature test macro for array constexpr has wrong value in "
-#elif __cpp_lib_array_constexpr > 201603L && __cplusplus == 201703
-# error "Feature test macro for array constexpr has wrong value for C++17"
 #endif
 
 constexpr std::size_t test01()
diff --git a/libstdc++-v3/testsuite/23_containers/array/requirements/constexpr_iter.cc b/libstdc++-v3/testsuite/23_containers/array/requirements/constexpr_iter.cc
index a119937f773..566388405b6 100644
--- a/libstdc++-v3/testsuite/23_containers/array/requirements/constexpr_iter.cc
+++ b/libstdc++-v3/testsuite/23_containers/array/requirements/constexpr_iter.cc
@@ -22,12 +22,13 @@
 
 #ifndef __cpp_lib_array_constexpr
 # error "Feature test macro for array constexpr is missing in "
-#elif __cpp_lib_array_constexpr < 201603L
+#elif __cpp_lib_array_constexpr < 201803L
 # error "Feature test macro for array constexpr has wrong value in "
-#elif __cpp_lib_array_constexpr > 201603L && __cplusplus == 201703
-# error "Feature test macro for array constexpr has wrong value for C++17"
 #endif
 
+// This test is compiled as C++17 because 

[committed 9/8] libstdc++: Define __cpp_lib_three_way_comparison for freestanding

[Jonathan Wakely via Gcc-patches]

The  header is always supported, not only for hosted configs.

* include/std/version (__cpp_lib_three_way_comparison): Define for
freestanding builds.

Tested powerpc64le-linux, committed to master.


commit a2dcb56c9443d1211e14889bd0c2c21360d54cdb
Author: Jonathan Wakely 
Date:   Thu Apr 23 21:39:33 2020 +0100

libstdc++: Define __cpp_lib_three_way_comparison for freestanding

The  header is always supported, not only for hosted configs.

* include/std/version (__cpp_lib_three_way_comparison): Define for
freestanding builds.

diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index d06d60c9106..1beb9aa938e 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -184,6 +184,9 @@
 #endif
 #define __cpp_lib_is_nothrow_convertible 201806L
 #define __cpp_lib_remove_cvref 201711L
+#if __cpp_impl_three_way_comparison >= 201907L && __cpp_lib_concepts
+# define __cpp_lib_three_way_comparison 201907L
+#endif
 #define __cpp_lib_type_identity 201806L
 #define __cpp_lib_unwrap_ref 201811L
 
@@ -215,9 +218,6 @@
 #define __cpp_lib_span 202002L
 #define __cpp_lib_ssize 201902L
 #define __cpp_lib_starts_ends_with 201711L
-#if __cpp_impl_three_way_comparison >= 201907L && __cpp_lib_concepts
-# define __cpp_lib_three_way_comparison 201907L
-#endif
 #define __cpp_lib_to_address 201711L
 #define __cpp_lib_to_array 201907L
 #endif

Re: Not usable email content encoding

[Segher Boessenkool]

Hi!

On Thu, Apr 23, 2020 at 12:57:43PM -0400, Frank Ch. Eigler wrote:
> > *Nothing* should touch changelog files :-)  They should be generated from 
> > the
> > VCS.  IMHO of course.
> 
> IMHO: the VCS should be the changelog.

The VCS shows what changed.  The changelog shows what was meant to be
changed.  The difference is very helpful for reviewers, and for
post-mortem purposes, etc.

This can be more than compensated for if submitters would write better
patch descriptions, of course.  But will that happen?


Segher

[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #8 from Eric Botcazou  ---
.

[Bug tree-optimization/94717] [10 Regression] segfault with -O2 -fnon-call-exceptions -ftracer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:cb76fcd7fb4a4f1e4d1688deca87969124f16fef

commit r10-7926-gcb76fcd7fb4a4f1e4d1688deca87969124f16fef
Author: Eric Botcazou 
Date:   Thu Apr 23 22:25:04 2020 +0200

Fix segfault with -O2 -fnon-call-exceptions -ftracer

The GIMPLE SSA store merging pass blows up when it is rewriting the
stores because it didn't realize that they don't belong to the same
EH region.  Fixed by refusing to merge them.

PR tree-optimization/94717
* gimple-ssa-store-merging.c (try_coalesce_bswap): Return false if
one of the stores doesn't have the same landing pad number as the
first.
(coalesce_immediate_stores): Do not try to coalesce the store using
bswap if it doesn't have the same landing pad number as the first.

Fix PR tree-optimization/94717

[Eric Botcazou]

This is a regression present on the mainline in the form of a segfault on the 
attached C testcase with -O2 -fnon-call-exceptions -ftracer.  The GIMPLE SSA 
store merging pass blows up when it is rewriting the stores because it didn't 
realize that they don't belong to the same EH region.

Fixed by refusing to merge them.  Tested on x86-64/Linux, pre-approved by 
Jakub and applied on the mainline.


2019-04-23  Eric Botcazou  

PR tree-optimization/94717
* gimple-ssa-store-merging.c (try_coalesce_bswap): Return false if one
of the stores doesn't have the same landing pad number as the first.
(coalesce_immediate_stores): Do not try to coalesce the store using
bswap if it doesn't have the same landing pad number as the first.


2019-04-23  Eric Botcazou  

* g++.dg/opt/store-merging-4.C: New test.

-- 
Eric Botcazoudiff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
index a6687cd9c98..25753517cc6 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gimple-ssa-store-merging.c
@@ -2435,6 +2435,7 @@ imm_store_chain_info::try_coalesce_bswap (merged_store_group *merged_store,
   for (unsigned int i = first + 1; i < len; ++i)
 {
   if (m_store_info[i]->bitpos != m_store_info[first]->bitpos + width
+	  || m_store_info[i]->lp_nr != merged_store->lp_nr
 	  || m_store_info[i]->ins_stmt == NULL)
 	return false;
   width += m_store_info[i]->bitsize;
@@ -2682,6 +2683,7 @@ imm_store_chain_info::coalesce_immediate_stores ()
   if (info->bitpos == merged_store->start + merged_store->width
 	  && merged_store->stores.length () == 1
 	  && merged_store->stores[0]->ins_stmt != NULL
+	  && info->lp_nr == merged_store->lp_nr
 	  && info->ins_stmt != NULL)
 	{
 	  unsigned int try_size;
// PR tree-optimization/94717
// Reported by Zdenek Sojka 

// { dg-do compile }
// { dg-options "-O2 -fnon-call-exceptions -ftracer" }

int abs (int);

static inline void
bar (int d)
{
  d && abs (d);
}

struct S
{
  int a;
  int b;
  int c;
  S (unsigned a, unsigned b) : a (a), b (b) { }
};

void
foo (S *x)
{
  bar (x->c);
  new S (x->a, x->b);
  bar (0);
}

Re: Not usable email content encoding

[Segher Boessenkool]

On Thu, Apr 23, 2020 at 09:33:47AM -0600, Jeff Law wrote:
> On Thu, 2020-04-23 at 06:46 -0500, Segher Boessenkool wrote:
> > Hi!
> > 
> > On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote:
> > > but trains for GCC Will likely be very short because of Changelog 
> > > conflicts.
> > 
> > Why that?  Your patches should *not* touch changelog files, ever.
> > 
> > For CI it is probably easiest if the CI never gets to see the changelog
> > at all, and that isn't hard to do ;-)
> *Nothing* should touch changelog files :-)  They should be generated from the
> VCS.  IMHO of course.

My point was that this should *never* be part of patches, already.

> That implies that the patch includes a proper ChangeLog entry in the commit
> message.  It also implies that if we muck one up, then we live with it rather
> than going back and rewriting them.

There also is the middle ground where we still have changelog files, but
normal checkins automatically update those from the commit message.
This is an intermediate step, but also makes it possible (and even easy)
to fix up mistakes.


Segher

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Joseph Myers]

On Thu, 23 Apr 2020, Richard Biener via Gcc-patches wrote:

> I think at least one step would be uncontroversical(?), namely moving
> the RTL expansion "magic"
> up to a GIMPLE pass.  Where the "magic" would be to turn
> GIMPLE stmts not directly expandable via an existing optab into
> GIMPLE that can be trivially expanded.  That includes eventually

I suspect some such pieces should actually happen before some GIMPLE 
optimizations are done, rather than as the last pass before expansion - 
though then you need to make sure subsequent GIMPLE passes don't 
reintroduce the operations you've lowered.

E.g. the special handling of arithmetic on bit-field types in expand is a 
good candidate for being a lowering step (lowering to operations on 
integer widths actually supported by the machine / that correspond to 
known machine modes) somewhere in GIMPLE processing (and you don't want to 
subsequently narrow back to operations on those widths that don't exist in 
hardware).  Note in that regard that there is a proposal for C2x to 
support integer types with a specified number of bits more generally than 
just as bit-fields.

> That said, I actually agree with that.  It's just that I hope we can
> make some of the knowledge just represented on the RTL side
> available on the GIMPLE side.  The more complicated parts,
> like calling conventions, that is.

On the other hand, there is some knowledge like that which should move out 
of the front ends, into a GIMPLE lowering step (front ends should not be 
calling targetm.calls.promote_prototypes and changing their internal 
representation accordingly, that information should be handled later in 
the compiler, probably on GIMPLE).

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

Re: [PATCH] Mark experimental::net::system_context ctor deleted

[Jonathan Wakely via Gcc-patches]

On 23/04/20 13:09 -0700, Thomas Rodgers via Libstdc++ wrote:


 * include/experimental/net/executor: Mark
 system_context::system_context() = default.


s/default/delete/ :-)

But the affected function/type/thingie should be named in parens, not
in the comment i.e.

* include/experimental/net/executor (system_context): Define default
constructor as deleted.


 * testsuite/experimental/net/executor/1.cc: Add new
 test for deleted system_context ::system_context().


There's a stray space in there.

It would be more accurate to say "check system_context isn't default
constructible" because you can't test if it's deleted, as opposed to
private or just doesn't exist.

OK with those changelog tweaks.

Please backport to gcc-9 too.




---
libstdc++-v3/include/experimental/executor| 2 +-
libstdc++-v3/testsuite/experimental/net/executor/1.cc | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/experimental/executor 
b/libstdc++-v3/include/experimental/executor
index b5c6e18a19a..fa39eaa0468 100644
--- a/libstdc++-v3/include/experimental/executor
+++ b/libstdc++-v3/include/experimental/executor
@@ -850,7 +850,7 @@ inline namespace v1

// construct / copy / destroy:

-system_context() = default;
+system_context() = delete;
system_context(const system_context&) = delete;
system_context& operator=(const system_context&) = delete;

diff --git a/libstdc++-v3/testsuite/experimental/net/executor/1.cc 
b/libstdc++-v3/testsuite/experimental/net/executor/1.cc
index 456d620e193..cd0af4b7737 100644
--- a/libstdc++-v3/testsuite/experimental/net/executor/1.cc
+++ b/libstdc++-v3/testsuite/experimental/net/executor/1.cc
@@ -85,9 +85,16 @@ test02()
  VERIFY( e == g );
}

+void
+test03()
+{
+  static_assert( ! std::is_default_constructible::value, 
"" );
+}
+
int
main()
{
  test01();
  test02();
+  test03();
}
--
2.25.3

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Segher Boessenkool]

On Thu, Apr 23, 2020 at 04:32:51PM +0100, Richard Sandiford wrote:
> I also wonder how difficult it would be to get recog to recognise
> gimple :-)

Since recog recognises single (rtl) insns: hard to impossible?


Segher

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Segher Boessenkool]

On Thu, Apr 23, 2020 at 08:40:50AM -0600, Jeff Law wrote:
> On Thu, 2020-04-23 at 15:07 +0200, Richard Biener wrote:
> > On Thu, Apr 23, 2020 at 2:52 PM Segher Boessenkool
> >  wrote:
> > > On Thu, Apr 23, 2020 at 02:25:40PM +0200, Richard Biener wrote:
> > > > > > But being stuck with something means no progress...  I know
> > > > > > very well it's 100 times harder to get rid of something than to
> > > > > > add something new ontop.
> > > > > 
> > > > > Well, what progress do you expect to make?  After expand that is :-)
> > > > 
> > > > I'd like the RTL pipeline before RA to shrink significantly, no PRE,
> > > > no CSE, ...
> > > 
> > > RTL CSE for example is very much required to get any good code.  It
> > > needs to CSE stuff that wasn't there before expand.
> > 
> > Sure, but then we should fix that!
> Exactly.  It's purpose largely becomes dealing with the redundancies exposed 
> by
> expansion.  ie, address arithmetic and the like.   A lot of its path following
> code should be throttled back.

Hrm, I never thought about it like this.  CSE was always there, I never
stopped to question if we needed it :-)

Well, that's cse1 then.  What about cse2?

> > But valid RTL is instructions that are recognized.  Which means
> > when the target doesn't support an SImode add we may not create
> > one.  That's instruction selection ;)
> That's always a point of tension.  But I think that in general continuing to 
> have
> targets claim to support things they do not (such as double-wordsize 
> arithmetic,
> logicals, moves, etc) is a mistake.  It made sense at one time, but I think 
> we've
> got better mechansisms in place to deal with this stuff now.

Different targets have *very* different insns for add, mul, div, shifts;
everything really.  Describing this at expand time with two-machine-word
operations works pretty bloody well, for most or all targets -- this is
just part of the power of define_expand (but an important part).  And
define_expand is very very useful, it's the swiss army escape hatch, it
lets you do everything optabs have a too small mind for.

> > > Oh no, I think we should do more earlier, and GIMPLE is a fine IR for
> > > there.  But for low-level, close-to-the-machine stuff, RTL is much
> > > better suited.  And we *do* want to optimise at that level as well, and
> > > much more than just peepholes.
> > 
> > Well, everything that requires costing (unrolling, vectorization,
> > IV selection to name a few) _is_ close-to-the-machine.  We're
> > just saying they are not because GIMPLE is so much easier to
> > work with here (not sure why exactly...).
> The primary motivation behind discouraging target costing and the like from
> gimple was to make it easier to implement and predict the behavior of the 
> gimple
> optimizers.   We've relaxed that somewhat, particularly for vectorization, 
> but I
> think the principle is still solid.

There are two kinds of costing.  The first only says which of A or B is
better; that can perhaps be done on GIMPLE already, using
target-specific costs.  The other gives a number to everything, which is
much harder to get anywhere close to usably correct (what does the
number even *mean*?  For performance, latency of the whole sequence is
the most important number, but that is not easy to work with, or what we
use for say insn_cost).

> 
> But I think there is a place for adding target dependencies -- and that's at 
> the
> end of the current gimple pipeline.

There are a *few* things in GIMPLE that use target costs (ivopts...)
But yeah, most things should not.


Segher

[Bug libstdc++/94702] std::unsequenced_policy should not be defined for C++17

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:9d13ebadf78821fe5a239600460a81c10def10cc

commit r9-8536-g9d13ebadf78821fe5a239600460a81c10def10cc
Author: Jonathan Wakely 
Date:   Thu Apr 23 18:48:50 2020 +0100

libstdc++: Define __cpp_lib_execution feature test

This macro has never been defined by libstdc++, despite supporting the
parallel algorithms. It should have a different value for C++17 and
C++20, because P1001R2 should not be supported in C++17, but
unsequenced_policy is defined for C++17 (see PR 94702).

Backport from mainline
2020-04-22  Jonathan Wakely  

* include/std/execution (__cpp_lib_execution): Define to indicate
support for P0024R2 and P1001R2.
* include/std/version (__cpp_lib_execution): Define.
* testsuite/25_algorithms/pstl/feature_test.cc: Only test macro
defined by , move other tests to new tests ...
* testsuite/25_algorithms/pstl/feature_test-2.cc: New test.
* testsuite/25_algorithms/pstl/feature_test-3.cc: New test.
* testsuite/25_algorithms/pstl/feature_test-4.cc: New test.
* testsuite/25_algorithms/pstl/feature_test-5.cc: New test.

[Bug c++/94583] [10 Regression] ICE in get_defaulted_eh_spec, at cp/method.c:2421

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[PATCH] c++: Lambda in friend of constrained class [PR94645]

[Patrick Palka via Gcc-patches]

In the testcase below, when grokfndecl processes the operator() decl for the
lambda inside the friend function foo, processing_template_decl is rightly 1,
but template_class_depth on the lambda's closure type incorrectly returns 0
instead of 1.

Since processing_template_decl > template_class_depth, this makes grokfndecl
think that the operator() has its own set of template arguments, and so we
attach the innermost set of constraints -- those belonging to struct l -- to the
operator() decl.  We then get confused when checking constraints_satisfied_p on
the operator() because it doesn't have template information and yet has
constraints associated with it.

This patch fixes template_class_depth to return the correct template nesting
level in cases like these, so that when it hits a friend function it walks into
the DECL_FRIEND_CONTEXT of the friend rather than into the CP_DECL_CONTEXT.

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on cmcstl2,
range-v3, and fmt libraries.

gcc/cp/ChangeLog:

PR c++/94645
* pt.c (template_class_depth): Walk into the DECL_FRIEND_CONTEXT of a
friend declaration rather than into its CP_DECL_CONTEXT.

gcc/testsuite/ChangeLog:

PR c++/94645
* g++.dg/cpp2a/concepts-lambda6.C: New test.
---
 gcc/cp/pt.c   |  7 ++-
 gcc/testsuite/g++.dg/cpp2a/concepts-lambda6.C | 19 +++
 2 files changed, 25 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-lambda6.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 0e3e7b2039a..08a35c41007 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -390,7 +390,12 @@ template_class_depth (tree type)
++depth;
 
   if (DECL_P (type))
-   type = CP_DECL_CONTEXT (type);
+   {
+ if (tree fctx = DECL_FRIEND_CONTEXT (type))
+   type = fctx;
+ else
+   type = CP_DECL_CONTEXT (type);
+   }
   else if (LAMBDA_TYPE_P (type) && LAMBDA_TYPE_EXTRA_SCOPE (type))
type = LAMBDA_TYPE_EXTRA_SCOPE (type);
   else
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-lambda6.C 
b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda6.C
new file mode 100644
index 000..244421e64ec
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-lambda6.C
@@ -0,0 +1,19 @@
+// PR c++/94632
+// { dg-do compile { target concepts } }
+
+struct unordered_map {
+  int cend() const noexcept;
+};
+
+template  concept HasMapInterface = requires(a t) { t.cend(); };
+
+template  requires HasMapInterface
+struct l {
+  friend void foo(l opt) { ([]() {})(); }
+};
+
+struct p {
+  static unordered_map map();
+};
+
+void g(l *y) { foo(*y); }
-- 
2.26.2.266.ge870325ee8

[PATCH] Mark experimental::net::system_context ctor deleted

[Thomas Rodgers via Gcc-patches]

  * include/experimental/net/executor: Mark
  system_context::system_context() = default.
  * testsuite/experimental/net/executor/1.cc: Add new
  test for deleted system_context ::system_context().
---
 libstdc++-v3/include/experimental/executor| 2 +-
 libstdc++-v3/testsuite/experimental/net/executor/1.cc | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/experimental/executor 
b/libstdc++-v3/include/experimental/executor
index b5c6e18a19a..fa39eaa0468 100644
--- a/libstdc++-v3/include/experimental/executor
+++ b/libstdc++-v3/include/experimental/executor
@@ -850,7 +850,7 @@ inline namespace v1
 
 // construct / copy / destroy:
 
-system_context() = default;
+system_context() = delete;
 system_context(const system_context&) = delete;
 system_context& operator=(const system_context&) = delete;
 
diff --git a/libstdc++-v3/testsuite/experimental/net/executor/1.cc 
b/libstdc++-v3/testsuite/experimental/net/executor/1.cc
index 456d620e193..cd0af4b7737 100644
--- a/libstdc++-v3/testsuite/experimental/net/executor/1.cc
+++ b/libstdc++-v3/testsuite/experimental/net/executor/1.cc
@@ -85,9 +85,16 @@ test02()
   VERIFY( e == g );
 }
 
+void
+test03()
+{
+  static_assert( ! std::is_default_constructible::value, 
"" );
+}
+
 int
 main()
 {
   test01();
   test02();
+  test03();
 }
-- 
2.25.3

 

[PATCH] c++: zero_init_expr_p of dependent expression

[Patrick Palka via Gcc-patches]

This fixes a ICE coming from mangle.c:write_expression when compiling the
ranges-v3 testsuite; the added testcase is a reduced reproducer of the ICE.

Bootstrapped and regtested on x86_64-pc-linux-gnu, and also tested on the
cmcstl2, fmt and range-v3 libraries.  Does this look OK to commit?

gcc/cp/ChangeLog:

* tree.c (zero_init_expr_p): Use uses_template_parms instead of
dependent_type_p.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/dependent3.C: New test.
---
 gcc/cp/tree.c   |  2 +-
 gcc/testsuite/g++.dg/cpp0x/dependent3.C | 28 +
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/dependent3.C

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 090c565c093..8840932dba2 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -4486,7 +4486,7 @@ bool
 zero_init_expr_p (tree t)
 {
   tree type = TREE_TYPE (t);
-  if (!type || dependent_type_p (type))
+  if (!type || uses_template_parms (type))
 return false;
   if (zero_init_p (type))
 return initializer_zerop (t);
diff --git a/gcc/testsuite/g++.dg/cpp0x/dependent3.C 
b/gcc/testsuite/g++.dg/cpp0x/dependent3.C
new file mode 100644
index 000..caf7e1cd4a4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/dependent3.C
@@ -0,0 +1,28 @@
+// { dg-do compile { target c++11 } }
+
+template
+struct d
+{
+  using e = c;
+};
+
+template
+struct g
+{
+  using h = typename d::e;
+
+  template
+  auto operator()(i, j k) -> decltype(h{k});
+};
+
+template
+void m()
+{
+  int a[1];
+  l{}(a, a);
+}
+
+int main()
+{
+  m>();
+}
-- 
2.26.2.266.ge870325ee8

[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:f51be2fb8653f81092f8158a0f0527275f86603b

commit r10-7924-gf51be2fb8653f81092f8158a0f0527275f86603b
Author: Jakub Jelinek 
Date:   Thu Apr 23 21:57:50 2020 +0200

Shortcut identity VEC_PERM expansion [PR94710]

This PR is about the rs6000 backend emitting wrong assembly
for whole vector shift by 0, and while I think it is desirable
to fix the backend, I don't see a point why the expander should
try to emit that, whole vector shift by 0 is identity, we can just
return the operand.

2020-04-23  Jakub Jelinek  

PR target/94710
* optabs.c (expand_vec_perm_const): For shift_amt const0_rtx
just return v2.

Re: [Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

[Qing Zhao via Gcc-patches]

Hi, Richard,


> On Apr 23, 2020, at 1:27 PM, Richard Sandiford  
> wrote:
> 
> Qing Zhao  writes:
>> ---
>> gcc/c-family/c-indentation.c   |  3 +++
>> gcc/common.opt |  5 +
>> gcc/doc/invoke.texi| 15 ++-
>> gcc/testsuite/gcc.dg/plugin/location-overflow-test-1.c |  2 +-
>> gcc/toplev.c   |  3 +++
>> 5 files changed, 26 insertions(+), 2 deletions(-)
>> 
>> diff --git a/gcc/c-family/c-indentation.c b/gcc/c-family/c-indentation.c
>> index f737555..7074b10 100644
>> --- a/gcc/c-family/c-indentation.c
>> +++ b/gcc/c-family/c-indentation.c
>> @@ -67,6 +67,9 @@ get_visual_column (expanded_location exploc, location_t 
>> loc,
>>"%<-Wmisleading-indentation%> is disabled from this point"
>>" onwards, since column-tracking was disabled due to"
>>" the size of the code/headers");
>> +  inform (loc,
>> +  "please add %<-flarge-source-files%> to invoke more" 
>> +  " column-tracking for large source files");
>>  }
>>   return false;
>> }
> 
> This should be conditional on !flag_large_source_files.

Yes, indeed, will add it.
> 
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index 4368910..10a3d5b 100644
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -1597,6 +1597,11 @@ fkeep-gc-roots-live
>> Common Undocumented Report Var(flag_keep_gc_roots_live) Optimization
>> ; Always keep a pointer to a live memory block
>> 
>> +flarge-source-files
>> +Common Report Var(flag_large_source_files) Init(0)
>> +Adjust GCC to cope with large source files to provide more accurate
>> +column information.
>> +
> 
> I'm having difficulty suggesting wording here, but I think would be good
> to mention the downside.  How about:
> 
> --
> Improve GCC's ability to track column numbers in large source files,
> at the expense of slower compilation.
> ———

Sounds better than my previous wording. Thanks.

> 
>> floop-parallelize-all
>> Common Report Var(flag_loop_parallelize_all) Optimization
>> Mark all loops as parallel.
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index 96a9516..c6ea9ef 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -574,7 +574,7 @@ Objective-C and Objective-C++ Dialects}.
>> -fdebug-cpp  -fdirectives-only  -fdollars-in-identifiers  @gol
>> -fexec-charset=@var{charset}  -fextended-identifiers  @gol
>> -finput-charset=@var{charset}  -fmacro-prefix-map=@var{old}=@var{new}  @gol
>> --fmax-include-depth=@var{depth} @gol
>> +-fmax-include-depth=@var{depth} -flarge-source-files @gol
>> -fno-canonical-system-headers  -fpch-deps  -fpch-preprocess  @gol
>> -fpreprocessed  -ftabstop=@var{width}  -ftrack-macro-expansion  @gol
>> -fwide-exec-charset=@var{charset}  -fworking-directory @gol
> 
> This should be kept in alphabetical order, so after -finput-charset.

Okay. 
> 
>> @@ -14151,6 +14151,19 @@ This option may be useful in conjunction with the 
>> @option{-B} or
>> perform additional processing of the program source between
>> normal preprocessing and compilation.
>> 
>> +@item -flarge-source-files
>> +@opindex flarge-source-files
>> +Adjust GCC to cope with large source files to provide more accurate
>> +column information. 
>> +By default, GCC will lose accurate column information if the source 
>> +file is very large.
>> +If this option is provided, GCC will adapt accordingly to provide more
>> +accurate column information. 
>> +This option may be useful when any user hits the 
>> @option{-Wmisleading-indent} 
>> +note, "is disabled from this point onwards, since column-tracking was 
>> disabled 
>> +due to the size of the code/headers", or hits the limit at which columns get
>> +dropped from diagnostics.
>> +
> 
> On a similar vein, how about:
> 
> --
> Adjust GCC to expect large source files, at the expense of slower
> compilation and higher memory usage.
> 
> Specifically, GCC normally tracks both column numbers and line numbers
> within source files and it normally prints both of these numbers in
> diagnostics.  However, once it has processed a certain number of source
> lines, it stops tracking column numbers and only tracks line numbers.
> This means that diagnostics for later lines do not include column numbers.
> It also means that options like @option{-Wmisleading-indent} cease to work
> at that point, although the compiler prints a note if this happens.
> Passing @option{-flarge-source-files} significantly increases the number
> of source lines that GCC can process before it stops tracking column
> numbers.
> ———

Thanks a lot for this paragraph. I will use it.

Qing
> 
> Thanks,
> Richard

[Bug c++/94288] co_await in while loop crashes g++

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:3dbc772128e944819b09e21021d4fcd5dc17f2d4

commit r10-7923-g3dbc772128e944819b09e21021d4fcd5dc17f2d4
Author: Iain Sandoe 
Date:   Thu Apr 23 16:59:00 2020 +0100

coroutines: Fix handling of conditional statements [PR94288]

Normally, when we find a statement containing an await expression
this will be expanded to a statement list implementing the control
flow implied.  The expansion process successively replaces each
await expression in a statement with the result of its await_resume().

In the case of conditional statements (if, while, do, switch) the
expansion of the condition (or expression in the case of do-while)
cannot take place 'inline', leading to the PR.

The solution is to evaluate the expression separately, and to
transform while and do-while loops into endless loops with a break
on the required condition.

In fixing this, I realised that I'd also made a thinko in the case
of expanding truth-and/or-if expressions, where one arm of the
expression might need to be short-circuited.  The mechanism for
expanding via the tree walk will not work correctly in this case and
we need to pre-expand any truth-and/or-if with an await expression
on its conditionally-taken arm.  This applies to any statement with
truth-and/or-if expressions, so can be handled generically.

gcc/cp/ChangeLog:

2020-04-23  Iain Sandoe  

PR c++/94288
* coroutines.cc (await_statement_expander): Simplify cases.
(struct susp_frame_data): Add fields for truth and/or if
cases, rename one field.
(analyze_expression_awaits): New.
(expand_one_truth_if): New.
(add_var_to_bind): New helper.
(coro_build_add_if_not_cond_break): New helper.
(await_statement_walker): Handle conditional expressions,
handle expansion of truth-and/or-if cases.
(bind_expr_find_in_subtree): New, checking-only.
(coro_body_contains_bind_expr_p): New, checking-only.
(morph_fn_to_coro): Ensure that we have a top level bind
expression.

gcc/testsuite/ChangeLog:

2020-04-23  Iain Sandoe  

PR c++/94288
* g++.dg/coroutines/torture/co-await-18-if-cond.C: New test.
* g++.dg/coroutines/torture/co-await-19-while-cond.C: New test.
* g++.dg/coroutines/torture/co-await-20-do-while-cond.C: New test.
* g++.dg/coroutines/torture/co-await-21-switch-value.C: New test.
* g++.dg/coroutines/torture/co-await-22-truth-and-of-if.C: New
test.
* g++.dg/coroutines/torture/co-ret-16-simple-control-flow.C: New
test.

Re: [PATCH][v3], rs6000: Use plq/pstq for atomic_{load, store} (PR94622)

[will schmidt via Gcc-patches]

On Wed, 2020-04-22 at 07:59 -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Tue, Apr 21, 2020 at 04:53:53PM -0500, Aaron Sawdey via Gcc-
> patches wrote:
> > For future architecture with prefix instructions, always use
> > plq/pstq
> > rather than lq/stq for atomic load of quadword. Then we never have
> > to
> > do the doubleword swap on little endian. Before this fix, -mno-
> > pcrel
> > would generate lq with the doubleword swap (which was ok) and
> > -mpcrel
> > would generate plq, also with the doubleword swap, which was wrong.
> > 2020-04-20  Aaron Sawdey  
> > 
> > PR target/94622
> > * config/rs6000/sync.md (load_quadpti): Add attr "prefixed"
> > if TARGET_PREFIXED.
> > (store_quadpti): Ditto.
> > (atomic_load): Do not swap doublewords if TARGET_PREFIXED
> > as
> > plq will be used and doesn't need it.
> > (atomic_store): Ditto, for pstq.
> > +;; Pattern load_quadpti will always use plq for atomic TImode if
> > +;; TARGET_PREFIXED.  It has the correct doubleword ordering on
> > either LE
> > +;; or BE, so we can just move the result into the output register
> > and
> > +;; do not need to do the doubleword swap for LE. Also this avoids
> > any
> > +;; confusion about whether the lq vs plq might be used based on
> > whether
> > +;; op1 has PC-relative addressing. We could potentially allow BE
> > to
> > +;; use lq because it doesn't have the doubleword ordering problem.
> 
> Two spaces after dot (twice).
> 
> Thanks for the nice comments :-)
> 
> > -  [(set_attr "type" "store")])
> > +  [(set_attr "type" "store")
> > +   (set (attr "prefixed") (if_then_else (match_test
> > "TARGET_PREFIXED")
> > +(const_string "yes")
> > +(const_string "no")))])
> 
> Every 8 leading spaces should be a tab (it's annoying to have a
> mixture
> of styles, and then later to have patches randomly change such things
> as
> well.  Spaces everywhere (no tabs ever) works fine for me, but that
> is
> not what we use, not in GCC, and not in our port.  We could change
> that
> in GCC 11 perhaps?  Opinions?)

Keep the port consistent with the rest of the project, whatever it is.
I tend to prefer just tabs, but also like to have >80 column windows.  
:-)

thanks
-Will


> 
> The patch is okay for trunk modulo those nits.  Thanks!
> 
> 
> Segher

Re: [PATCH] Shortcut identity VEC_PERM expansion [PR94710]

[Richard Biener]

On April 23, 2020 9:04:40 PM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>This PR is about the rs6000 backend emitting wrong assembly
>for whole vector shift by 0, and while I think it is desirable
>to fix the backend, I don't see a point why the expander should
>try to emit that, whole vector shift by 0 is identity, we can just
>return the operand.
>
>Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?

OK. 

Richard. 

>2020-04-23  Jakub Jelinek  
>
>   PR target/94710
>   * optabs.c (expand_vec_perm_const): For shift_amt const0_rtx
>   just return v2.
>
>--- gcc/optabs.c.jj2020-04-17 14:18:44.380437703 +0200
>+++ gcc/optabs.c   2020-04-23 11:50:07.931780323 +0200
>@@ -5627,6 +5627,8 @@ expand_vec_perm_const (machine_mode mode
>   if (shift_amt)
>   {
> class expand_operand ops[3];
>+if (shift_amt == const0_rtx)
>+  return v2;
> if (shift_code != CODE_FOR_nothing)
>   {
> create_output_operand ([0], target, mode);
>
>   Jakub

[Bug middle-end/91512] [10 Regression] Fortran compile time regression.

[meissner at gcc dot gnu.org]

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

--- Comment #31 from Michael Meissner  ---
For the Spec 2017 521.wrf_r benchmark on little endian PowerPC power9 systems,
there was no difference in runtime between a normal run using -Ofast
-mcpu=power9 and one with -Ofast -mcpu=power9 -fno-inline-arg-packing.

Of the seven rate benchmarks in Spec 2017 that use Fortran (548.exchange2_r,
503.bwaves_r, 507.cactuBSSN_r, 521.wrf_r, 527.cam4_r, 549.fotonik3d_r, and
554.roms_r) none of them vary by more tha 0.7% depending on whether the switch
is used or not.

I used the compiler checked out from the master branch on March 27, 2020 to
build and run the benchmarks.

As others have said, using -fno-inline-arg-packing does dramatically reduce the
time it takes to compile 521.wrf_r.

[Bug c++/90448] [8/9 Regression] decltype-based lambda parameter pack is rejected

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #6 from Rainer Orth  ---
I see the same ICE on 32-bit sparc-sun-solaris2.11.

Re: [PATCH] rs6000: Replace outdated link to ELFv2 ABI

[David Edelsohn via Gcc-patches]

On Thu, Apr 23, 2020 at 12:13 PM Bill Schmidt  wrote:
>
> A user reported that we are still referring to a public review
> draft of the ELFv2 ABI specification.  Replace that by a permalink.
>
> Tested with "make pdf" and verified the link is hot.  Is this okay
> for master?
>
> Thanks,
> Bill
>
> 2020-04-24  Bill Schmidt  
>
> * gcc/doc/extend.texi (PowerPC AltiVec/VSX Built-in Functions):
> Replace outdated link to ELFv2 ABI.

Okay.

This probably counts as obvious change.

Thanks, David

[Bug c++/94733] [10 Regression] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[committed] c-family: Fix ICE on attribute with -fgnu-tm [PR94733]

[Marek Polacek via Gcc-patches]

find_tm_attribute was using TREE_PURPOSE to get the attribute name,
which is breaking now that we preserve the C++11-style attribute
format past decl_attributes.  So use get_attribute_name which can
handle both formats of attributes.

Tested x86_64-pc-linux-gnu, applying to trunk.

PR c++/94733
* c-attribs.c (find_tm_attribute): Use get_attribute_name instead of
TREE_PURPOSE.

* g++.dg/tm/attrib-5.C: New test.
---
 gcc/c-family/c-attribs.c   | 2 +-
 gcc/testsuite/g++.dg/tm/attrib-5.C | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/tm/attrib-5.C

diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
index 1483b3540dc..ac936d5 100644
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -3314,7 +3314,7 @@ find_tm_attribute (tree list)
 {
   for (; list ; list = TREE_CHAIN (list))
 {
-  tree name = TREE_PURPOSE (list);
+  tree name = get_attribute_name (list);
   if (tm_attr_to_mask (name) != 0)
return name;
 }
diff --git a/gcc/testsuite/g++.dg/tm/attrib-5.C 
b/gcc/testsuite/g++.dg/tm/attrib-5.C
new file mode 100644
index 000..0b7bc728f06
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tm/attrib-5.C
@@ -0,0 +1,5 @@
+// PR c++/94733
+// { dg-do compile { target c++11 } }
+// { dg-options "-fgnu-tm" }
+
+struct [[gnu::may_alias]] pe { };

base-commit: dcf69ac5448fd6a16137cfe9fe6deadd0ec0243d
-- 
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

[Bug c++/94733] [10 Regression] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:7291b2edf6f87fba839b0d10c04b2562a5f6bd60

commit r10-7922-g7291b2edf6f87fba839b0d10c04b2562a5f6bd60
Author: Marek Polacek 
Date:   Thu Apr 23 14:38:58 2020 -0400

c-family: Fix ICE on attribute with -fgnu-tm [PR94733]

find_tm_attribute was using TREE_PURPOSE to get the attribute name,
which is breaking now that we preserve the C++11-style attribute
format past decl_attributes.  So use get_attribute_name which can
handle both formats of attributes.

PR c++/94733
* c-attribs.c (find_tm_attribute): Use get_attribute_name instead
of
TREE_PURPOSE.

* g++.dg/tm/attrib-5.C: New test.

[Bug middle-end/94724] [10 Regression] wrong code at -O0 on x86_64-linux-gnu since r10-7344-gca6c722561ce9b9d

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|jakub at redhat dot com|
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||10.0
 CC||liujiangning at gcc dot 
gnu.org,
   ||marxin at gcc dot gnu.org
Summary|Program crashes when|[10 Regression] Program
   |compiled with GCC 10|crashes when compiled with
   ||-O2 since
   ||r10-1892-gb9ef6a2e04bfd013
  Known to work||9.3.0
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |10.0
   Last reconfirmed||2020-04-23
 Ever confirmed|0   |1
   Priority|P3  |P1
   Keywords||wrong-code
  Component|c   |tree-optimization

--- Comment #2 from Martin Liška  ---
Confirmed, ASAN is also fine. Started with r10-1892-gb9ef6a2e04bfd013.

Re: [PATCH] rs6000: Replace outdated link to ELFv2 ABI

[will schmidt via Gcc-patches]

On Thu, 2020-04-23 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> A user reported that we are still referring to a public review
> draft of the ELFv2 ABI specification.  Replace that by a permalink.
> 
> Tested with "make pdf" and verified the link is hot.  Is this okay
> for master?
> 
Hi,

I have confirmed the URL goes to the right place.

lgtm :-)

Thanks
-Will



> Thanks,
> Bill
> 
> 2020-04-24  Bill Schmidt  
> 
>   * gcc/doc/extend.texi (PowerPC AltiVec/VSX Built-in Functions):
>   Replace outdated link to ELFv2 ABI.
> ---
>  gcc/doc/extend.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index c17b1040bde..936c22e2fe7 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -17633,7 +17633,7 @@ subject to change without notice.
> 
>  GCC complies with the OpenPOWER 64-Bit ELF V2 ABI Specification,
>  which may be found at
> -@uref{
> http://openpowerfoundation.org/wp-content/uploads/resources/leabi-prd/content/index.html
> }.
> +@uref{
> https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture
> }.
>  Appendix A of this document lists the vector API interfaces that
> must be
>  provided by compliant compilers.  Programmers should preferentially
> use
>  the interfaces described therein.  However, historically GCC has
> provided

[Bug middle-end/94724] [10 Regression] wrong code at -O0 on x86_64-linux-gnu since r10-7344-gca6c722561ce9b9d

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:bca558de2a24b2a78c6a321d6cec384e07759d77

commit r10-7921-gbca558de2a24b2a78c6a321d6cec384e07759d77
Author: Jakub Jelinek 
Date:   Thu Apr 23 21:11:36 2020 +0200

tree: Fix up get_narrower [PR94724]

In the recent get_narrower change, I wanted it to be efficient and avoid
recursion if there are many nested COMPOUND_EXPRs.  That builds the
COMPOUND_EXPR nest with the right arguments, but as build2_loc computes
some
flags like TREE_SIDE_EFFECTS, TREE_CONSTANT and TREE_READONLY, when it
is called with something that will not be the argument in the end, those
flags are computed incorrectly.
So, this patch instead uses an auto_vec and builds them in the reverse
order
so when they are built, they are built with the correct operands.

2020-04-23  Jakub Jelinek  

PR middle-end/94724
* tree.c (get_narrower): Instead of creating COMPOUND_EXPRs
temporarily with non-final second operand and updating it later,
push COMPOUND_EXPRs into a vector and process it in reverse,
creating COMPOUND_EXPRs with the final operands.

* gcc.c-torture/execute/pr94724.c: New test.

[PATCH] testsuite: C++14 vs. C++17 struct-layout-1.exp testing with ALT_CXX_UNDER_TEST [PR94383]

[Jakub Jelinek via Gcc-patches]

Hi!

On Tue, Apr 21, 2020 at 11:57:02AM +0200, Jakub Jelinek wrote:
> I haven't added (yet) checks if the alternate compiler does support these
> options (I think that can be done incrementally), so for now this testing is
> done only if the alternate compiler is not used.

This patch does that, so now when testing against not too old compiler
it can do the -std=c++14 vs. -std=c++17 testing also between under test and
alt compilers.

Tested on x86_64-linux, without ALT_CXX_UNDER_TEST (all tests still used),
with ALT_CXX_UNDER_TEST=g++ (all tests still used too), and after tweaking
it to test -std=c++20 instead of -std=c++17 that my system g++ doesn't
support, where it only used tests before *_32* and bootstrapped/regtested
on powerpc64{,le}-linux, ok for trunk?

2020-04-23  Jakub Jelinek  

PR c++/94383
* g++.dg/compat/struct-layout-1.exp: Use the -std=c++14 vs. -std=c++17
ABI compatibility testing even with ALT_CXX_UNDER_TEST, as long as
that compiler accepts -std=c++14 and -std=c++17 options.

--- gcc/testsuite/g++.dg/compat/struct-layout-1.exp.jj  2020-04-21 
17:07:52.004248153 +0200
+++ gcc/testsuite/g++.dg/compat/struct-layout-1.exp 2020-04-23 
15:56:16.057326947 +0200
@@ -142,7 +142,19 @@ if { $status == 0 } then {
 file delete -force $tstobjdir
 file mkdir $tstobjdir
 set generator_args "-s $srcdir/$subdir -d $tstobjdir"
-if { $use_alt == 0 } then {
+set test_cxx14_vs_cxx17 1
+if { $use_alt != 0 } then {
+   compat-use-alt-compiler
+   if { [check_no_compiler_messages_nocache compat_alt_has_cxx14 object {
+   int dummy; } "-std=c++14"] == 0 } {
+   set test_cxx14_vs_cxx17 0
+   } elseif { [check_no_compiler_messages_nocache compat_alt_has_cxx17 
object {
+   int dummy; } "-std=c++17"] == 0 } {
+   set test_cxx14_vs_cxx17 0
+   }
+   compat-use-tst-compiler
+}
+if { $test_cxx14_vs_cxx17 != 0 } then {
set generator_args "$generator_args -c"
 }
 if [info exists env(RUN_ALL_COMPAT_TESTS) ] then {


Jakub

[PATCH v3] aarch64: Add TX3 machine model

[Anton Youdkevitch]

Here is the patch introducing thunderxt311 maching model
for the scheduler. A name for the new chip was added to the
list of the names to be recognized as a valid parameter for mcpu
and mtune flags. The TX2 cost model was reused for TX3.

The previously used "cryptic" name for the command line
parameter is replaced with the same "thunderxt311" name.

Added the new chip name to the documentation. Fixed
copyright names and dates.

Bootstrapped on AArch64.

2020-04-23 Anton Youdkevitch 

* config/aarch64/aarch64-cores.def: Add the chip name.
* config/aarch64/aarch64-tune.md: Regenerated.
* config/aarch64/aarch64.c: Add the cost tables for the chip.
* config/aarch64/thunderx3t11.md: New file: add the new
machine model for the scheduler
* config/aarch64/aarch64.md: Include the new model.
* doc/invoke.texi: Add the new name to the list

---
gcc/config/aarch64/aarch64-cores.def |   3 +
gcc/config/aarch64/aarch64-tune.md   |   2 +-
gcc/config/aarch64/aarch64.c |  27 ++
gcc/config/aarch64/aarch64.md|   1 +
gcc/config/aarch64/thunderx3t11.md   | 686 +
gcc/doc/invoke.texi  |   2 +-
6 files changed, 719 insertions(+), 2 deletions(-)
>From 452ae6d022a5a882abdf236d8e58cbacf4f0b301 Mon Sep 17 00:00:00 2001
From: Anton Youdkevitch 
Date: Mon, 23 Mar 2020 13:22:35 -0700
Subject: [PATCH] TX3 scheduling and tuning implementation

Added the scheduler descriptions for TX3 and the
cost tables borrowed them from TX2.
---
 gcc/config/aarch64/aarch64-cores.def |   3 +
 gcc/config/aarch64/aarch64-tune.md   |   2 +-
 gcc/config/aarch64/aarch64.c |  27 ++
 gcc/config/aarch64/aarch64.md|   1 +
 gcc/config/aarch64/thunderx3t11.md   | 686 +++
 gcc/doc/invoke.texi  |   2 +-
 6 files changed, 719 insertions(+), 2 deletions(-)
 create mode 100644 gcc/config/aarch64/thunderx3t11.md

diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index ea9b98b..7224802 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -95,6 +95,9 @@ AARCH64_CORE("vulcan",  vulcan, thunderx2t99, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | AA
 /* Cavium ('C') cores. */
 AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x43, 0x0af, -1)
 
+/* Marvell cores (TX3). */
+AARCH64_CORE("thunderx3t11",  thunderx3t11,  thunderx3t11, 8_4A,  AARCH64_FL_FOR_ARCH8_4 | AARCH64_FL_CRYPTO | AARCH64_FL_SHA3, thunderx3t11, 0x43, 0x0b8, 0x0a)
+
 /* ARMv8.2-A Architecture Processors.  */
 
 /* ARM ('A') cores. */
diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
index 3cc1c4d..573a4a9 100644
--- a/gcc/config/aarch64/aarch64-tune.md
+++ b/gcc/config/aarch64/aarch64-tune.md
@@ -1,5 +1,5 @@
 ;; -*- buffer-read-only: t -*-
 ;; Generated automatically by gentune.sh from aarch64-cores.def
 (define_attr "tune"
-	"cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
+	"cortexa34,cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,octeontx,octeontxt81,octeontxt83,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,thunderx3t11,cortexa55,cortexa75,cortexa76,cortexa76ae,cortexa77,cortexa65,cortexa65ae,ares,neoversen1,neoversee1,octeontx2,octeontx2t98,octeontx2t96,octeontx2t93,octeontx2f95,octeontx2f95n,octeontx2f95mm,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
 	(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 24c055d..7abce6a 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1216,6 +1216,33 @@ static const struct tune_params thunderx2t99_tunings =
   _prefetch_tune
 };
 
+static const struct tune_params thunderx3t11_tunings =
+{
+  _extra_costs,
+  _addrcost_table,
+  _regmove_cost,
+  _vector_cost,
+  _branch_cost,
+  _approx_modes,
+  SVE_NOT_IMPLEMENTED, /* sve_width  */
+  4, /* memmov_cost.  */
+  4, /* issue_rate.  */
+  (AARCH64_FUSE_ALU_BRANCH | AARCH64_FUSE_AES_AESMC
+   | AARCH64_FUSE_ALU_CBZ), /* fusible_ops  */
+  "16",	/* function_align.  */
+  "8",	/* jump_align.  */
+  "16",	/* loop_align.  */
+  3,	/* int_reassoc_width.  */
+  2,	/* fp_reassoc_width.  */
+  

[PATCH] Shortcut identity VEC_PERM expansion [PR94710]

[Jakub Jelinek via Gcc-patches]

Hi!

This PR is about the rs6000 backend emitting wrong assembly
for whole vector shift by 0, and while I think it is desirable
to fix the backend, I don't see a point why the expander should
try to emit that, whole vector shift by 0 is identity, we can just
return the operand.

Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?

2020-04-23  Jakub Jelinek  

PR target/94710
* optabs.c (expand_vec_perm_const): For shift_amt const0_rtx
just return v2.

--- gcc/optabs.c.jj 2020-04-17 14:18:44.380437703 +0200
+++ gcc/optabs.c2020-04-23 11:50:07.931780323 +0200
@@ -5627,6 +5627,8 @@ expand_vec_perm_const (machine_mode mode
   if (shift_amt)
{
  class expand_operand ops[3];
+ if (shift_amt == const0_rtx)
+   return v2;
  if (shift_code != CODE_FOR_nothing)
{
  create_output_operand ([0], target, mode);

Jakub

Re: [PATCH] tree: Fix up get_narrower [PR94724]

[Richard Biener]

On April 23, 2020 8:19:55 PM GMT+02:00, Jakub Jelinek  wrote:
>Hi!
>
>In the recent get_narrower change, I wanted it to be efficient and
>avoid
>recursion if there are many nested COMPOUND_EXPRs.  That builds the
>COMPOUND_EXPR nest with the right arguments, but as build2_loc computes
>some
>flags like TREE_SIDE_EFFECTS, TREE_CONSTANT and TREE_READONLY, when it
>is called with something that will not be the argument in the end,
>those
>flags are computed incorrectly.
>So, this patch instead uses an auto_vec and builds them in the reverse
>order
>so when they are built, they are built with the correct operands.
>
>Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?

OK. 

Richard. 

>2020-04-23  Jakub Jelinek  
>
>   PR middle-end/94724
>   * tree.c (get_narrower): Instead of creating COMPOUND_EXPRs
>   temporarily with non-final second operand and updating it later,
>   push COMPOUND_EXPRs into a vector and process it in reverse,
>   creating COMPOUND_EXPRs with the final operands.
>
>   * gcc.c-torture/execute/pr94724.c: New test.
>
>--- gcc/tree.c.jj  2020-04-04 09:14:29.808002636 +0200
>+++ gcc/tree.c 2020-04-23 11:07:34.003675831 +0200
>@@ -8881,18 +8881,22 @@ get_narrower (tree op, int *unsignedp_pt
> 
>   if (TREE_CODE (op) == COMPOUND_EXPR)
> {
>-  while (TREE_CODE (op) == COMPOUND_EXPR)
>+  do
>   op = TREE_OPERAND (op, 1);
>+  while (TREE_CODE (op) == COMPOUND_EXPR);
>   tree ret = get_narrower (op, unsignedp_ptr);
>   if (ret == op)
>   return win;
>-  op = win;
>-  for (tree *p =  TREE_CODE (op) == COMPOUND_EXPR;
>- op = TREE_OPERAND (op, 1), p = _OPERAND (*p, 1))
>-  *p = build2_loc (EXPR_LOCATION (op), COMPOUND_EXPR,
>-   TREE_TYPE (ret), TREE_OPERAND (op, 0),
>-   ret);
>-  return win;
>+  auto_vec  v;
>+  unsigned int i;
>+  for (tree op = win; TREE_CODE (op) == COMPOUND_EXPR;
>+ op = TREE_OPERAND (op, 1))
>+  v.safe_push (op);
>+  FOR_EACH_VEC_ELT_REVERSE (v, i, op)
>+  ret = build2_loc (EXPR_LOCATION (op), COMPOUND_EXPR,
>+TREE_TYPE (win), TREE_OPERAND (op, 0),
>+ret);
>+  return ret;
> }
>   while (TREE_CODE (op) == NOP_EXPR)
> {
>--- gcc/testsuite/gcc.c-torture/execute/pr94724.c.jj   2020-04-23
>11:11:52.470736940 +0200
>+++ gcc/testsuite/gcc.c-torture/execute/pr94724.c  2020-04-23
>11:14:27.999367103 +0200
>@@ -0,0 +1,12 @@
>+/* PR middle-end/94724 */
>+
>+short a, b;
>+
>+int
>+main ()
>+{
>+  (0, (0, (a = 0 >= 0, b))) != 53601;
>+  if (a != 1)
>+__builtin_abort ();
>+  return 0;
>+}
>
>   Jakub

[Bug target/94736] New: Missing ENDBR at label

[hjl.tools at gmail dot com]

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

Bug ID: 94736
   Summary: Missing ENDBR at label
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
  Target Milestone: ---
Target: i386,x86-64

[hjl@gnu-cfl-2 gcc]$ cat /tmp/foo.c
#include 

typedef void *(*func_t) (void);

void *p;

void
__attribute__ ((noclone, noinline))
foo (int a)
{
  switch (a)
{
case 0:
a0:
  return;
case 1:
a1:
  p = &
case 2:
a2:
  p = &
case 3:
a3:
  p = &
case 4:
a4:
  p = &
case 5:
a5:
  p = &
case 6:
a6:
  p = &
case 7:
a7:
  p = &
case 8:
a8:
  p = &
case 9:
a9:
  p = &
case 10:
a10:
  p = &
default:
  p = &
}
  goto *p;
}

int
main ()
{
  foo (20);
  if (p == NULL)
abort ();
  ((func_t) p) ();
  return 0;
}
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2  -fcf-protection /tmp/foo.c
[hjl@gnu-cfl-2 gcc]$ cat foo.s
.file   "foo.c"
.text
.p2align 4
.globl  foo
.type   foo, @function
foo:
.LFB11:
.cfi_startproc
endbr64
testl   %edi, %edi
je  .L1
.L3:
endbr64
.L4:
.L5:
.L6:
.L7:
.L8:
.L9:
.L10:
.L11:
.L12:
movq$.L2, p(%rip)
.L2:
.L1:  Missing ENDBR
ret
.cfi_endproc
.LFE11:
.size   foo, .-foo
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.section.text.startup,"ax",@progbits
.LHOTB0:
.p2align 4
.globl  main
.type   main, @function
main:
.LFB12:
.cfi_startproc
endbr64
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$20, %edi
callfoo
movqp(%rip), %rax
testq   %rax, %rax
je  .L19
call*%rax
xorl%eax, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.section.text.unlikely
.cfi_startproc
.type   main.cold, @function
main.cold:
.LFSB12:
.L19:
.cfi_def_cfa_offset 16
callabort
.cfi_endproc
.LFE12:
.section.text.startup
.size   main, .-main
.section.text.unlikely
.size   main.cold, .-main.cold
.LCOLDE0:
.section.text.startup
.LHOTE0:
.globl  p
.bss
.align 8
.type   p, @object
.size   p, 8
p:
.zero   8
.ident  "GCC: (GNU) 10.0.1 20200422 (experimental)"
.section.note.GNU-stack,"",@progbits
.section.note.gnu.property,"a"
.align 8
.long1f - 0f
.long4f - 1f
.long5
0:
.string  "GNU"
1:
.align 8
.long0xc002
.long3f - 2f
2:
.long0x3
3:
.align 8
4:
[hjl@gnu-cfl-2 gcc]$

Re: [PATCH] Support the new ("v0") mangling scheme in rust-demangle.

[Eduard-Mihai Burtescu]

Ping 4: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html

Thanks,
- Eddy B.

On Mon, Apr 13, 2020, at 05:52, Eduard-Mihai Burtescu wrote:
> Ping 3: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
> 
> Thanks,
> - Eddy B.
> 
> On Tue, Apr 7, 2020, at 00:52, Eduard-Mihai Burtescu wrote:
> > Ping 2: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542012.html
> > 
> > Thanks,
> > - Eddy B.
> > 
> > On Fri, Mar 13, 2020, at 10:28 PM, Eduard-Mihai Burtescu wrote:
> > > This is the libiberty (mainly for binutils/gdb) counterpart of
> > > https://github.com/alexcrichton/rustc-demangle/pull/23.
> > > 
> > > Relevant links for the new Rust mangling scheme (aka "v0"):
> > > * Rust RFC: https://github.com/rust-lang/rfcs/pull/2603
> > > * tracking issue: https://github.com/rust-lang/rust/issues/60705
> > > * implementation: https://github.com/rust-lang/rust/pull/57967
> > > 
> > > This implementation includes full support for UTF-8 identifiers
> > > via punycode, so I've included a testcase for that as well.
> > > (Let me know if it causes any issues and I'll take it out)
> > > 
> > > Last year I've submitted several small patches to rust-demangle
> > > in preparation for upstreaming the entire new demangler, and
> > > feedback from that has proven useful.
> > > For example, I started with error-handling macros, but instead
> > > the code now has "rdm->errored = 1;" before several returns/gotos.
> > > 
> > > The patch is attached instead of inline, as it's over 1000 lines long.
> > > 
> > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > > 
> > > Also, I have no commit access, so I'd be thankful if
> > > someone would commit this for me if/once approved.
> > > Attachments:
> > > * 0001-Support-the-new-v0-mangling-scheme-in-rust-demangle.patch

Re: [PATCH] c++: Explicit constructor called in copy-initialization [PR90320]

[Jason Merrill via Gcc-patches]

On 4/22/20 11:27 PM, Marek Polacek wrote:

This test is rejected with a bogus "use of deleted function" error
starting with r225705 whereby convert_like_real/ck_base no longer
sets LOOKUP_ONLYCONVERTING for user_conv_p conversions.  This does
not seem to be always correct.  To recap, when we have something like
T t = x where T is a class type and the type of x is not T or derived
from T, we perform copy-initialization, something like:
   1. choose a user-defined conversion to convert x to T, the result is
  a prvalue,
   2. use this prvalue to direct-initialize t.

In the second step, explicit constructors should be considered, since
we're direct-initializing.  This is what r225705 fixed.

In this PR we are dealing with the first step, I think, where explicit
constructors should be skipped.  [over.match.copy] says "The converting
constructors of T are candidate functions" which clearly eliminates
explicit constructors.  But we also have to copy-initialize the argument
we are passing to such a converting constructor, and here we should
disregard explicit constructors too.

In this testcase we have

   V v = m;

and we choose V::V(M) to convert m to V.  But we wrongly choose
the explicit M::M(M&) to copy-initialize the argument; it's
a better match for a non-const lvalue than the implicit M::M(const M&)
but because it's explicit, we shouldn't use it.

When convert_like is processing the ck_user conversion -- the convfn is
V::V(M) -- it can see that cand->flags contains LOOKUP_ONLYCONVERTING,
but then when we're in build_over_call for this convfn, we have no way
to pass the flag to convert_like for the argument 'm', because convert_like
doesn't take flags.  So I've resorted to setting need_temporary_p in
a ck_rvalue, thus far unused, to signal that we're only interested in
non-explicit constructors.

LOOKUP_COPY_PARM looks relevant, but again, it's a LOOKUP_* flag, so
can't pass it to convert_like.  DR 899 also seemed related, but that
deals with direct-init contexts only.

Does this make sense?

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

PR c++/90320
* call.c (standard_conversion): Set need_temporary_p if FLAGS demands
LOOKUP_ONLYCONVERTING.
(convert_like_real) : If a ck_rvalue has
need_temporary_p set, or LOOKUP_ONLYCONVERTING into FLAGS.

* g++.dg/cpp0x/explicit13.C: New test.
---
  gcc/cp/call.c   | 24 +---
  gcc/testsuite/g++.dg/cpp0x/explicit13.C | 14 ++
  2 files changed, 31 insertions(+), 7 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/explicit13.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index c58231601c9..d802f1a0c2f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -92,10 +92,10 @@ struct conversion {
   language standards, e.g. disregarding pointer qualifiers or
   converting integers to pointers.  */
BOOL_BITFIELD bad_p : 1;
-  /* If KIND is ck_ref_bind ck_base_conv, true to indicate that a
+  /* If KIND is ck_ref_bind or ck_base, true to indicate that a
   temporary should be created to hold the result of the
- conversion.  If KIND is ck_ambig or ck_user, true means force
- copy-initialization.  */
+ conversion.  If KIND is ck_ambig, ck_rvalue, or ck_user, true means
+ force copy-initialization.  */
BOOL_BITFIELD need_temporary_p : 1;
/* If KIND is ck_ptr or ck_pmem, true to indicate that a conversion
   from a pointer-to-derived to pointer-to-base is being performed.  */
@@ -1252,6 +1252,8 @@ standard_conversion (tree to, tree from, tree expr, bool 
c_cast_p,
if (flags & LOOKUP_PREFER_RVALUE)
/* Tell convert_like_real to set LOOKUP_PREFER_RVALUE.  */
conv->rvaluedness_matches_p = true;
+  if (flags & LOOKUP_ONLYCONVERTING)
+   conv->need_temporary_p = true;


Presumably we want the same thing for ck_base?


@@ -7654,10 +7656,18 @@ convert_like_real (conversion *convs, tree expr, tree 
fn, int argnum,
 destination [is treated as direct-initialization].  [dcl.init] */
flags = LOOKUP_NORMAL;
if (convs->user_conv_p)
-   /* This conversion is being done in the context of a user-defined
-  conversion (i.e. the second step of copy-initialization), so
-  don't allow any more.  */
-   flags |= LOOKUP_NO_CONVERSION;
+   {
+ /* This conversion is being done in the context of a user-defined
+conversion (i.e. the second step of copy-initialization), so
+don't allow any more.  */
+ flags |= LOOKUP_NO_CONVERSION;
+ /* But we might also be performing a conversion of the argument
+to the user-defined conversion, i.e., not a conversion of the
+result of the user-defined conversion.  In which case we skip
+explicit constructors.  */
+ if (convs->kind == ck_rvalue && convs->need_temporary_p)
+   flags |= LOOKUP_ONLYCONVERTING;
+   }

Re: blacklisted after announce on GNU cauldron ?

[Christopher Faylor via Gcc]

On Thu, Apr 23, 2020 at 06:39:54PM +0100, Jonathan Wakely wrote:
>On Thu, 23 Apr 2020 at 18:02, Jonathan Wakely  wrote:
>>On Thu, 23 Apr 2020 at 16:46, Christopher Faylor wrote:
>>>All of the above is handled by whomever is responsible for the gcc web
>>>pages.  It would be nice if someone fixed those links.
>>
>>Yes, removing the broken subcription form on gcc.gnu.org/lists.html is
>>on my TODO list, but gcc-10 work is higher priority.
>
>Patch submitted for approval now:
>https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544461.html

Thanks!

cgf

[Bug analyzer/94732] Analyzer: false positive in MPFR's atan.c

[vincent-gcc at vinc17 dot net]

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

--- Comment #1 from Vincent Lefèvre  ---
Here's the corresponding simple testcase:

typedef struct { int *a; } S;
int *f (void);
static void g (S *x)
{
  int *p = x->a;
  p[0] = 0;
}
void h (void)
{
  S x[1];
  x->a = f ();
  g (x);
}

$ gcc-10 -c -fanalyzer bug.i
bug.i: In function ‘g’:
bug.i:6:8: warning: use of uninitialized value ‘p’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
6 |   p[0] = 0;
  |   ~^~~
  ‘h’: events 1-2
|
|8 | void h (void)
|  |  ^
|  |  |
|  |  (1) entry to ‘h’
|..
|   12 |   g (x);
|  |   ~
|  |   |
|  |   (2) calling ‘g’ from ‘h’
|
+--> ‘g’: events 3-4
   |
   |3 | static void g (S *x)
   |  | ^
   |  | |
   |  | (3) entry to ‘g’
   |..
   |6 |   p[0] = 0;
   |  |      
   |  ||
   |  |(4) use of uninitialized value ‘p’ here
   |

Re: [patch, fortran] Fix PR 93956, wrong pointer when returned via function

[Thomas Koenig via Gcc-patches]

Hi Paul,


You didn't attach the testcase but never mind, I am sure that it is OK :-)


You're right. I thought I had it in the git diff, but then again, I am
still learning the niceties (and not-so-niceties) of git.

Test case is attached, for completeness.


OK for trunk and, if you feel like it, for 9-branch.


Yes, I think this deserves a backport.

Thanks for the review!

Best regards

Thomas
! { dg-do run }
! PR 93956 - span was set incorrectly, leading to wrong code.
! Original test case by "martin".
program array_temps
  implicit none
  
  type :: tt
 integer :: u = 1
 integer :: v = 2
  end type tt

  type(tt), dimension(:), pointer :: r
  integer :: n
  integer, dimension(:), pointer :: p, q, u

  n = 10
  allocate(r(1:n))
  call foo(r%v,n)
  p => get(r(:))
  call foo(p, n)
  call get2(r,u)
  call foo(u,n)
  q => r%v
  call foo(q, n)

deallocate(r)

contains

   subroutine foo(a, n)
  integer, dimension(:), intent(in) :: a
  integer, intent(in) :: n
  if (sum(a(1:n)) /= 2*n) stop 1
   end subroutine foo

   function get(x) result(q)
  type(tt), dimension(:), target, intent(in) :: x
  integer, dimension(:), pointer :: q
  q => x(:)%v
   end function get

   subroutine get2(x,q)
  type(tt), dimension(:), target, intent(in) :: x
  integer, dimension(:), pointer, intent(out) :: q
  q => x(:)%v
end subroutine get2
end program array_temps

[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Thomas Kथà¤nig :

https://gcc.gnu.org/g:06eca1acafa27e19e82dc73927394a7a4d0bdbc5

commit r10-7920-g06eca1acafa27e19e82dc73927394a7a4d0bdbc5
Author: Thomas König 
Date:   Thu Apr 23 20:30:01 2020 +0200

Fix PR 93956, wrong pointer when returned via function.

This one took a bit of detective work.  When array pointers point
to components of derived types, we currently set the span field
and then create an array temporary when we pass the array
pointer to a procedure as a non-pointer or non-target argument.
(This is inefficient, but that's for another release).

Now, the compiler detected this case when there was a direct assignment
like p => a%b, but not when p was returned either as a function result
or via an argument.  This patch fixes that.

2020-04-23  Thomas Koenig  

PR fortran/93956
* expr.c (gfc_check_pointer_assign): Also set subref_array_pointer
when a function returns a pointer.
* interface.c (gfc_set_subref_array_pointer_arg): New function.
(gfc_procedure_use): Call it.

2020-04-23  Thomas Koenig  

PR fortran/93956
* gfortran.dg/pointer_assign_13.f90: New test.

Re: [Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

[Richard Sandiford]

Qing Zhao  writes:
> ---
>  gcc/c-family/c-indentation.c   |  3 +++
>  gcc/common.opt |  5 +
>  gcc/doc/invoke.texi| 15 ++-
>  gcc/testsuite/gcc.dg/plugin/location-overflow-test-1.c |  2 +-
>  gcc/toplev.c   |  3 +++
>  5 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/c-family/c-indentation.c b/gcc/c-family/c-indentation.c
> index f737555..7074b10 100644
> --- a/gcc/c-family/c-indentation.c
> +++ b/gcc/c-family/c-indentation.c
> @@ -67,6 +67,9 @@ get_visual_column (expanded_location exploc, location_t loc,
> "%<-Wmisleading-indentation%> is disabled from this point"
> " onwards, since column-tracking was disabled due to"
> " the size of the code/headers");
> +   inform (loc,
> +   "please add %<-flarge-source-files%> to invoke more" 
> +   " column-tracking for large source files");
>   }
>return false;
>  }

This should be conditional on !flag_large_source_files.

> diff --git a/gcc/common.opt b/gcc/common.opt
> index 4368910..10a3d5b 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -1597,6 +1597,11 @@ fkeep-gc-roots-live
>  Common Undocumented Report Var(flag_keep_gc_roots_live) Optimization
>  ; Always keep a pointer to a live memory block
>  
> +flarge-source-files
> +Common Report Var(flag_large_source_files) Init(0)
> +Adjust GCC to cope with large source files to provide more accurate
> +column information.
> +

I'm having difficulty suggesting wording here, but I think would be good
to mention the downside.  How about:

--
Improve GCC's ability to track column numbers in large source files,
at the expense of slower compilation.
--

>  floop-parallelize-all
>  Common Report Var(flag_loop_parallelize_all) Optimization
>  Mark all loops as parallel.
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 96a9516..c6ea9ef 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -574,7 +574,7 @@ Objective-C and Objective-C++ Dialects}.
>  -fdebug-cpp  -fdirectives-only  -fdollars-in-identifiers  @gol
>  -fexec-charset=@var{charset}  -fextended-identifiers  @gol
>  -finput-charset=@var{charset}  -fmacro-prefix-map=@var{old}=@var{new}  @gol
> --fmax-include-depth=@var{depth} @gol
> +-fmax-include-depth=@var{depth} -flarge-source-files @gol
>  -fno-canonical-system-headers  -fpch-deps  -fpch-preprocess  @gol
>  -fpreprocessed  -ftabstop=@var{width}  -ftrack-macro-expansion  @gol
>  -fwide-exec-charset=@var{charset}  -fworking-directory @gol

This should be kept in alphabetical order, so after -finput-charset.

> @@ -14151,6 +14151,19 @@ This option may be useful in conjunction with the 
> @option{-B} or
>  perform additional processing of the program source between
>  normal preprocessing and compilation.
>  
> +@item -flarge-source-files
> +@opindex flarge-source-files
> +Adjust GCC to cope with large source files to provide more accurate
> +column information. 
> +By default, GCC will lose accurate column information if the source 
> +file is very large.
> +If this option is provided, GCC will adapt accordingly to provide more
> +accurate column information. 
> +This option may be useful when any user hits the 
> @option{-Wmisleading-indent} 
> +note, "is disabled from this point onwards, since column-tracking was 
> disabled 
> +due to the size of the code/headers", or hits the limit at which columns get
> +dropped from diagnostics.
> +

On a similar vein, how about:

--
Adjust GCC to expect large source files, at the expense of slower
compilation and higher memory usage.

Specifically, GCC normally tracks both column numbers and line numbers
within source files and it normally prints both of these numbers in
diagnostics.  However, once it has processed a certain number of source
lines, it stops tracking column numbers and only tracks line numbers.
This means that diagnostics for later lines do not include column numbers.
It also means that options like @option{-Wmisleading-indent} cease to work
at that point, although the compiler prints a note if this happens.
Passing @option{-flarge-source-files} significantly increases the number
of source lines that GCC can process before it stops tracking column
numbers.
--

Thanks,
Richard

[Bug target/94697] aarch64: bti j at function start instead of bti c

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[PATCH] tree: Fix up get_narrower [PR94724]

[Jakub Jelinek via Gcc-patches]

Hi!

In the recent get_narrower change, I wanted it to be efficient and avoid
recursion if there are many nested COMPOUND_EXPRs.  That builds the
COMPOUND_EXPR nest with the right arguments, but as build2_loc computes some
flags like TREE_SIDE_EFFECTS, TREE_CONSTANT and TREE_READONLY, when it
is called with something that will not be the argument in the end, those
flags are computed incorrectly.
So, this patch instead uses an auto_vec and builds them in the reverse order
so when they are built, they are built with the correct operands.

Bootstrapped/regtested on powerpc64{,le}-linux, ok for trunk?

2020-04-23  Jakub Jelinek  

PR middle-end/94724
* tree.c (get_narrower): Instead of creating COMPOUND_EXPRs
temporarily with non-final second operand and updating it later,
push COMPOUND_EXPRs into a vector and process it in reverse,
creating COMPOUND_EXPRs with the final operands.

* gcc.c-torture/execute/pr94724.c: New test.

--- gcc/tree.c.jj   2020-04-04 09:14:29.808002636 +0200
+++ gcc/tree.c  2020-04-23 11:07:34.003675831 +0200
@@ -8881,18 +8881,22 @@ get_narrower (tree op, int *unsignedp_pt
 
   if (TREE_CODE (op) == COMPOUND_EXPR)
 {
-  while (TREE_CODE (op) == COMPOUND_EXPR)
+  do
op = TREE_OPERAND (op, 1);
+  while (TREE_CODE (op) == COMPOUND_EXPR);
   tree ret = get_narrower (op, unsignedp_ptr);
   if (ret == op)
return win;
-  op = win;
-  for (tree *p =  TREE_CODE (op) == COMPOUND_EXPR;
-  op = TREE_OPERAND (op, 1), p = _OPERAND (*p, 1))
-   *p = build2_loc (EXPR_LOCATION (op), COMPOUND_EXPR,
-TREE_TYPE (ret), TREE_OPERAND (op, 0),
-ret);
-  return win;
+  auto_vec  v;
+  unsigned int i;
+  for (tree op = win; TREE_CODE (op) == COMPOUND_EXPR;
+  op = TREE_OPERAND (op, 1))
+   v.safe_push (op);
+  FOR_EACH_VEC_ELT_REVERSE (v, i, op)
+   ret = build2_loc (EXPR_LOCATION (op), COMPOUND_EXPR,
+ TREE_TYPE (win), TREE_OPERAND (op, 0),
+ ret);
+  return ret;
 }
   while (TREE_CODE (op) == NOP_EXPR)
 {
--- gcc/testsuite/gcc.c-torture/execute/pr94724.c.jj2020-04-23 
11:11:52.470736940 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr94724.c   2020-04-23 
11:14:27.999367103 +0200
@@ -0,0 +1,12 @@
+/* PR middle-end/94724 */
+
+short a, b;
+
+int
+main ()
+{
+  (0, (0, (a = 0 >= 0, b))) != 53601;
+  if (a != 1)
+__builtin_abort ();
+  return 0;
+}

Jakub

[Bug c/94734] Program crashes when compiled with GCC 10

[john+gcc at hogberg dot online]

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

john+gcc at hogberg dot online changed:

   What|Removed |Added

  Attachment #48361|0   |1
is obsolete||

--- Comment #1 from john+gcc at hogberg dot online ---
Created attachment 48363
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48363=edit
Improved testcase

[Bug c++/94721] C++2a: Three-way comparison operator for function pointers rejected

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #3 from Marek Polacek  ---
(In reply to Daniel Krügler from comment #2)
> (In reply to Marek Polacek from comment #1)
> > Confirmed, thanks for the report.
> 
> Sigh, thanks. I'm starting to realize now, that it seems that the
> *intention* of
> https://wg21.link/p1959r0 adopted in November was to remove support of <=>
> on function pointers, but the current post-Prague wording paper seems to
> still have wording leftovers that mislead me to the interpretation expressed
> in this issue. I would like to withdraw this issue now and I'm starting a
> CWG discussion instead. My apologize for the false alarm.

No worries at all.  Closing as invalid then.

[Bug c/94730] [8/9/10 Regression] internal compiler error: in fold_convert_loc, at fold-const.c:2435

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
I'd suspect the code in finish_decl that deals with types determined from 
array initializers ("For global variables, update the copy of the type 
that exists in the binding.") of being involved here.

  if (b_ext->u.type && comptypes (b_ext->u.type, type))
b_ext->u.type = composite_type (b_ext->u.type, type);
  else
b_ext->u.type = type;

If the new type isn't compatible with the existing type of the 
declaration, it should probably not be stored in b_ext->u.type.

[Bug c++/94721] C++2a: Three-way comparison operator for function pointers rejected

[daniel.kruegler at googlemail dot com]

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

--- Comment #2 from Daniel Krügler  ---
(In reply to Marek Polacek from comment #1)
> Confirmed, thanks for the report.

Sigh, thanks. I'm starting to realize now, that it seems that the *intention*
of
https://wg21.link/p1959r0 adopted in November was to remove support of <=> on
function pointers, but the current post-Prague wording paper seems to still
have wording leftovers that mislead me to the interpretation expressed in this
issue. I would like to withdraw this issue now and I'm starting a CWG
discussion instead. My apologize for the false alarm.

[Bug c++/90448] [8/9 Regression] decltype-based lambda parameter pack is rejected

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The testcase ICEs on powerpc64-linux with -m32:
lambda-generic-variadic20.C:5:12: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:8075
5 |   auto L = [](auto ... a) {
  |^~~~
6 | auto M = [](decltype(a) ... b) -> void {
  | 
7 | };
  | ~~  
8 | return M;
  | ~
9 |   };
  |   ~ 
0xd9422a expand_expr_addr_expr_1
../../gcc/expr.c:8075
0xd94817 expand_expr_addr_expr
../../gcc/expr.c:8188
0xda0a68 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11363
0xd94bcd expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/expr.c:8358
0xc050ff expand_normal
../../gcc/expr.h:288
0xc0686f precompute_register_parameters
../../gcc/calls.c:982
0xc0fc27 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:4398
0xd9f9cb expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11135
0xd94bcd expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../gcc/expr.c:8358
0xd8cef5 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc/expr.c:5752
0xd8c194 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5514
0xc2860b expand_call_stmt
../../gcc/cfgexpand.c:2701
0xc2b6b5 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3682
0xc2bc49 expand_gimple_stmt
../../gcc/cfgexpand.c:3847
0xc32a16 expand_gimple_basic_block
../../gcc/cfgexpand.c:5887
0xc3401a execute
../../gcc/cfgexpand.c:6542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Re: blacklisted after announce on GNU cauldron ?

[Jonathan Wakely via Gcc]

On Thu, 23 Apr 2020 at 18:02, Jonathan Wakely  wrote:
>
> On Thu, 23 Apr 2020 at 16:46, Christopher Faylor via Gcc
>  wrote:
> >
> > On Thu, Apr 23, 2020 at 05:13:13PM +0200, Olivier Hainque wrote:
> > >Hi Frank,
> > >
> > >> On 23 Apr 2020, at 16:34, Frank Ch. Eigler  wrote:
> > >>
> > >> Hi -
> > >>
> >  A re-subscription attempt to the gcc mailing list just
> >  failed, expectedly I guess.
> > >>
> > >> I see no sign in the logs of Olivier being banned in any form.  Please
> > >> resubscribe online and forward complete failure symptoms if you
> > >> believe this is still happening.
> > >
> > >Thanks for your feedback!
> > >
> > >I managed to subscribe again by going through the gcc
> > >list specific info page :-)
> > >
> > >My previous attempts were issued from
> > >
> > >  https://gcc.gnu.org/lists.html#subscribe
> > >
> > >Subscribing from there doesn't work and leads
> > >to a page which provides instructions which don't work
> > >either.
> > >
> > >From there I thought the coincidence was troubling.
> > >
> > >There is actually a FAQ link on the instructions page,
> > >which I just checked, and ... it directs to a 404 page:
> > >
> > >  https://sourceware.org/pipermail/index.html#faqs
> > >
> > >I'll try to re-subscribe to gcc-patches now.
> >
> > All of the above is handled by whomever is responsible for the
> > gcc web pages.  It would be nice if someone fixed those links.
>
> Yes, removing the broken subcription form on gcc.gnu.org/lists.html is
> on my TODO list, but gcc-10 work is higher priority.

Patch submitted for approval now:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544461.html

[wwwdocs] Remove form for (un)subscribing from old mailing lists

[Jonathan Wakely via Gcc-patches]

This no longer works, so direct people to the mailman listinfo pages
instead.

OK to commit to wwwdocs?


commit 2ae426c876e6ddc026bc2a30e82cb56946c9031f
Author: Jonathan Wakely 
Date:   Thu Apr 23 18:38:00 2020 +0100

Remove form for (un)subscribing from old mailing lists

This no longer works, so direct people to the mailman listinfo pages
instead.

diff --git a/htdocs/lists.html b/htdocs/lists.html
index b05e1712..ea37aedc 100644
--- a/htdocs/lists.html
+++ b/htdocs/lists.html
@@ -194,46 +194,9 @@ it's assumed that no-one on these lists means to speak for 
their company.
 
 Subscribing/unsubscribing
 
-You will be able to subscribe or unsubscribe from any of the GCC mailing
-lists via this form:
-
-
-
-
-https://gcc.gnu.org/cgi-bin/ml-request;>
-  Mailing list: 
-  
-   gcc-announce
-   gcc
-   gcc-help
-   gcc-bugs
-   gcc-patches
-   gcc-testresults
-   gcc-cvs
-   gcc-cvs-wwwdocs
-   gcc-regression
-   libstdc++
-   libstdc++-cvs
-   fortran
-   jit
-   gnutools-advocacy
-  
- 
-  Your e-mail address:
-  
- 
-  Digest version
-  
-  
-subscribe
-unsubscribe
-  
-  
- 
-
-
+You can subscribe or unsubscribe from any of the GCC mailing
+lists by clicking on the list name above and then following the
+"more information about this list" link.
 
 If you're having trouble getting off a list, look at the
 List-Unsubscribe: header on a message sent to that list.

Re: [RFC] split pseudos during loop unrolling in RTL unroller

[Segher Boessenkool]

Hi!

On Thu, Apr 23, 2020 at 08:29:34AM -0600, Jeff Law wrote:
> On Thu, 2020-04-23 at 07:07 -0500, Segher Boessenkool wrote:
> > Most of expand is *other stuff*.  Expand does a *lot* of things that are
> > actually changing the code.  And much of that is not done anywhere else
> > either yet, so this cannot be fixed by simply deleting the offending code.
> A lot of what is done by the expansion pass is historical and dates back to 
> when
> we never optimized more than a statement at a time for trees and the real 
> heavy
> lifting was all done in RTL.

Yes.

> THe introduction of tree-ssa meant that all the expansion code which wanted to
> see a "nice" complex statement and generate good RTL code was useless and as a
> result we saw significant regressions in the end code quality.
> 
> That in turn brought in TER who's sole purpose was to reconstruct those more
> complex trees for the purposes of improving initial expansion.  I think 
> match.pd
> has the potential to make TER go away as match.pd is a generic combining
> framework.

Ooh that would be great news as well!

For moving stuff out of expand, it needs to *move*, not just be deleted.

> WRT extending SSA deeper, I'm all for it and it's always been something I 
> wanted
> to see happen.I've always believed we could do RTL SSA to the register
> allocation phase and that doing so would be a positive.

Well, since we have hard regs as well, it cannot really be SSA?  And SSA
doesn't fit RTL all that well anyway?  But the "webs always" idea is the
same of course.

> If we start at the front
> of the RTL pipeline and work towards the back we bump into CSE quickly, which
> would be good.  Our CSE is awful across multiple axis.

RTL CSE does quite many things that aren't really CSE...  Have to figure
out for each whether it still is useful, and what to do with it then.

> I suspect most RTL passes
> would be reimplementations rather than bolting SSA on the side and I suspect
> those reimplementations would be simpler than the existing stuff -- I'm a 
> strong
> believer there's a lot of dead code in the RTL passes as well.

Sure, but there also is a lot of stuff that perhaps is historical, and
perhaps is badly architected, but still does beneficial things.

If a reimplementation hugely improves things it's not bad in the end to
lose all such little things, but otherwise?


Segher

[Bug c/94735] MVE vector load/store pair getting removed with -O2.

[sripar01 at gcc dot gnu.org]

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |sripar01 at gcc dot 
gnu.org
 Target||arm-none-eabi
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-23

[Bug tree-optimization/94718] Failure to optimize opposite signs check

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
--- gcc/fold-const.c.jj 2020-03-31 11:06:14.063512214 +0200
+++ gcc/fold-const.c2020-04-23 18:39:15.399738420 +0200
@@ -11631,50 +11631,6 @@ fold_binary_loc (location_t loc, enum tr
  return omit_one_operand_loc (loc, type, res, arg0);
}

-  /* Fold (X & C) op (Y & C) as (X ^ Y) & C op 0", and symmetries.  */
-  if (TREE_CODE (arg0) == BIT_AND_EXPR
- && TREE_CODE (arg1) == BIT_AND_EXPR)
-   {
- tree arg00 = TREE_OPERAND (arg0, 0);
- tree arg01 = TREE_OPERAND (arg0, 1);
- tree arg10 = TREE_OPERAND (arg1, 0);
- tree arg11 = TREE_OPERAND (arg1, 1);
- tree itype = TREE_TYPE (arg0);
-
- if (operand_equal_p (arg01, arg11, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg10);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg00, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg01);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
- if (operand_equal_p (arg01, arg10, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg11);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg00, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg01);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
- if (operand_equal_p (arg00, arg11, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg10);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg01, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg00);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
- if (operand_equal_p (arg00, arg10, 0))
-   {
- tem = fold_convert_loc (loc, itype, arg11);
- tem = fold_build2_loc (loc, BIT_XOR_EXPR, itype, arg01, tem);
- tem = fold_build2_loc (loc, BIT_AND_EXPR, itype, tem, arg00);
- return fold_build2_loc (loc, code, type, tem,
- build_zero_cst (itype));
-   }
-   }
-
   if (TREE_CODE (arg0) == BIT_XOR_EXPR
  && TREE_CODE (arg1) == BIT_XOR_EXPR)
{
--- gcc/match.pd.jj 2020-03-11 18:33:50.341663648 +0100
+++ gcc/match.pd2020-04-23 19:17:37.954208051 +0200
@@ -4335,7 +4335,12 @@ (define_operator_list COND_TERNARY
  (simplify
   (cmp (convert? addr@0) integer_zerop)
   (if (tree_single_nonzero_warnv_p (@0, NULL))
-   { constant_boolean_node (cmp == NE_EXPR, type); })))
+   { constant_boolean_node (cmp == NE_EXPR, type); }))
+
+ /* (X & C) op (Y & C) into (X ^ Y) & C op 0.  */
+ (simplify
+  (cmp (bit_and:cs @0 @2) (bit_and:cs @1 @2))
+  (cmp (bit_and (bit_xor @0 @1) @2) { build_zero_cst (TREE_TYPE (@2)); })))

 /* If we have (A & C) == C where C is a power of 2, convert this into
(A & C) != 0.  Similarly for NE_EXPR.  */

is untested part without testsuite coverage that optimizes the above #c2 third
test the same as #c2 second test.  Unsure about :s.

[Bug c/94735] New: MVE vector load/store pair getting removed with -O2.

[sripar01 at gcc dot gnu.org]

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

Bug ID: 94735
   Summary: MVE vector load/store pair getting removed with -O2.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sripar01 at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48362=edit
test case

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/media/sripar01/2tb_work/Release/build-arm-none-eabi/install/libexec/gcc/arm-none-eabi/10.0.1/lto-wrapper
Target: arm-none-eabi
Configured with: /media/sripar01/2tb_work/Release/src/gcc/configure
--target=arm-none-eabi
--prefix=/media/sripar01/2tb_work/Release/build-arm-none-eabi/install//
--with-gmp=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--with-mpfr=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--with-mpc=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--with-isl=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c --without-cloog --without-isl
--with-newlib --without-headers --with-multilib-list=rmprofile
--with-pkgversion=unknown
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200423 (experimental) (unknown)

$ arm-none-eabi-gcc mve_vstore.i -S -O2 -march=armv8.1-m.main+mve
-mfloat-abi=hard

On compiling attached test case (mve_vstore.i) with -02 optimizes out a pair of
vector load/store statements.

Re: introduce target tmpnam and require it in tests relying on it

[Martin Sebor via Gcc-patches]

On 4/23/20 2:21 AM, Alexandre Oliva wrote:

On Apr 21, 2020, Bernhard Reutner-Fischer  wrote:


On 17 April 2020 21:21:41 CEST, Martin Sebor via Gcc-patches
 wrote:

On 4/17/20 11:48 AM, Alexandre Oliva wrote:

On Apr  9, 2020, Alexandre Oliva  wrote:


Some target C libraries that aren't recognized as freestanding don't
have filesystem support, so calling tmpnam, fopen/open and
remove/unlink fails to link.



This patch introduces a tmpnam effective target to the testsuite,

and

requires it in the tests that call tmpnam.



for  gcc/testsuite/ChangeLog



* lib/target-supports.exp (check_effective_target_tmpnam): New.
* gcc.c-torture/execute/fprintf-2.c: Require it.
* gcc.c-torture/execute/printf-2.c: Likewise.
* gcc.c-torture/execute/user-printf.c: Likewise.


Ping?

https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543672.html


I'm okay with the changes to the tests.

The target-supports.exp changes look reasonable to me as well but
I can't approve them.  Since you said it's for targets that don't
have file I/O functions I wonder if the name would better reflect
that if it were called, say, check_effective_target_fileio?



If you want a fileio predicate then please do not keys it off obsolescent 
functions.


I'd actually considered adding two expect/dejagnu procs, one for fileio,
one for tmpnam, possibly with the latter depending on the former, but
decided to take the simpler path on the grounds that all tests that
would have depended on fileio would also depend on tmpnam.

Plus, it did seem to make sense to test for tmpnam, since it probably
won't be found on freestanding environments (the affected tests require
non-freestanding effective target, but that translate to requiring I/O
support), and tmpnam might be removed from standards in the future.  We
might want to catch that, rather than silently skip the test, though.

I'd be glad to add an intermediate fileio effective target, or rename
the proposed one and drop tmpnam from it, if there's agreement such a
separate effective target would be more useful.


So, should I rename _tmpnam to _fileio and drop tmpnam() from the code
snippet in the effective target test?  Or should I keep _tmpnam and
introduce _fileio?  With or without a dependency of _tmpnam on _fileio?

Since Jeff Law approved the patch as is, would you guys mind if I make
any further changes as separate, followup patches?


Sure.  I'd go with _fileio but that's just a suggestion.  I don't
think there are enough uses of tmpnam in the test suite or risk
that it will disappear anytime soon to justify its own target test
or removing its uses, but I'm not opposed to it either.

Martin

[Bug c/94734] New: Program crashes when compiled with GCC 10

[john+gcc at hogberg dot online]

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

Bug ID: 94734
   Summary: Program crashes when compiled with GCC 10
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john+gcc at hogberg dot online
  Target Milestone: ---

Created attachment 48361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48361=edit
Test case program

The attached program crashes when it has been compiled with GCC 10 and -O2.
With -O3 or -Os it returns an incorrect value instead.

There are no warnings with `-Wall -Wextra` or `-fanalyzer`, and strangely
enough `-fsanitize=undefined` hides the crash without reporting any errors.

-fno-aggressive-loop-optimizations also makes the crash go away which made me
suspect that the code is wrong somehow, but `frama-c` insists that it's correct
and should always return 0. If there's a bug in there, I'm not seeing it. :(

Steps to reproduce:


$ gcc -O2 test.c -o bug
$ ./bug
Segmentation fault (core dumped)


GCC version:


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200423 (experimental) (GCC) 


It appears to work fine with GCC 7, I tested it with:


$ gcc-7 -v
Using built-in specs.
COLLECT_GCC=gcc-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max

[Segher Boessenkool]

Hi!

On Thu, Apr 23, 2020 at 02:34:03PM +, Zhanghaijian (A) wrote:
> Thanks for your suggestions. I have modified accordingly.
> Attached please find the adapted patch. Bootstrap and tested on aarch64 Linux 
> platform.
> Does the v2 patch look batter?
> 
> diff --git a/gcc/combine.c b/gcc/combine.c
> index cff76cd3303..ad8a385fc48 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -6643,7 +6643,8 @@ simplify_if_then_else (rtx x)
>  
>/* Look for MIN or MAX.  */
>  
> -  if ((! FLOAT_MODE_P (mode) || flag_unsafe_math_optimizations)
> +  if ((! FLOAT_MODE_P (mode)
> +   || (!HONOR_NANS (mode) && !HONOR_SIGNED_ZEROS (mode)))
>&& comparison_p
>&& rtx_equal_p (XEXP (cond, 0), true_rtx)
>&& rtx_equal_p (XEXP (cond, 1), false_rtx)

> > The GENERIC folding routine producing
> > min/max is avoiding it when those are honored (and it doesn't check 
> > flag_unsafe_math_optmizations at all).
> > 
> > Certainly the patch is an incremental correct fix, with the flag 
> > testing replaced by the mode feature testing.
> 
> Yeah, and the SMAX etc. definition is so weak that it isn't obvious that this 
> combine transform is valid without this flag.  We can or should fix that, of 
> course :-)

Please put flag_unsafe_math_optimizations back?  It isn't clear at all
that we do not need it.

Also, do you have a changelog entry?


Segher