date:20200224


Hi all,

I have committed a quip for OpenACC and AMD GCN. Comments and 
suggestions are welcome. Thanks for Andrew and Sandra for comments on an 
early draft.


Tobias

PS: The linked OpenACC wiki page is unfortunately not yet fully up to date…

commit 8c9fba2f83ef9bdace2fb6288f555c78949adfb6
Author: Tobias Burnus 
Date:   Mon Feb 24 10:29:11 2020 +0100

OpenACC + AMD GCN entry for gcc-10/changes.html

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 2920714a..83b1f071 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -142,7 +142,25 @@ a work-in-progress.
   
 
 
-New Languages and Language specific improvements
+New Languages and Language-Specific Improvements
+
+
+  
+Version 2.6 of the https://www.openacc.org/";>OpenACC
+specification is now supported in the C, C++ and Fortran compilers.
+See the https://gcc.gnu.org/wiki/OpenACC#status-10";>implementation
+status section on the OpenACC wiki page and the
+https://gcc.gnu.org/onlinedocs/libgomp/#toc-Enabling-OpenACC-1";>
+run-time library documentation for further information.
+  
+  
+OpenMP and OpenACC now support
+https://gcc.gnu.org/wiki/Offloading";>offloading to AMD Radeon
+(GCN) GPUs; supported are the third-generation Fiji (fiji)
+and the fifth-generation VEGA 10/VEGA 20 (gfx900 or
+gfx906).
+  
+
 
 
 
@@ -533,6 +551,12 @@ a work-in-progress.
   
 
 
+AMD Radeon (GCN)
+
+  The code generation and in particular the vectorization support has been
+  much improved.
+
+
 
 
 arm

Re: patch to fix PR93564

Hi,

On Sun, 23 Feb 2020 at 22:26, Vladimir Makarov  wrote:
>
> The following patch is for
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
>
> The patch was successfully bootstrapped on x86-64 and benchmarked on
> SPEC2000.
>


It seems this patch causes regression on some arm cores (seen on
cortex-a15 and cortex-57).
When configuring
--target arm-none-linux-gnueabihf
--with-cpu cortex-a57
--with-fpu crypto-neon-fp-armv8

gcc.target/arm/unaligned-memcpy-2.c: ldrd found 1 times
FAIL: gcc.target/arm/unaligned-memcpy-2.c scan-assembler-times ldrd 0
gcc.target/arm/unaligned-memcpy-2.c: strd found 2 times
FAIL: gcc.target/arm/unaligned-memcpy-2.c scan-assembler-times strd 1

This one regresses only on cortex-a15:
gcc.target/arm/unaligned-memcpy-3.c: ldrd found 2 times
FAIL: gcc.target/arm/unaligned-memcpy-3.c scan-assembler-times ldrd 1
gcc.target/arm/unaligned-memcpy-3.c: strd found 1 times
FAIL: gcc.target/arm/unaligned-memcpy-3.c scan-assembler-times strd 0

Christophe

Re: [PATCH] Do not propagate self-dependent value (PR ipa/93763)

Hi,

On Fri, 21 Feb 2020 at 21:23, Jeff Law  wrote:
>
> On Fri, 2020-02-21 at 18:59 +0100, Martin Jambor wrote:
> > Hi,
> >
> > On Tue, Feb 18 2020, Feng Xue OS wrote:
> > > Currently, for self-recursive call, we never use value originated from 
> > > non-passthrough
> > > jump function as source to avoid propagation explosion, but 
> > > self-dependent value is
> > > missed. This patch is made to fix the bug.
> > >
> > > Bootstrapped/regtested on x86_64-linux and aarch64-linux.
> > >
> > > Feng
> > > ---
> > > 2020-02-18  Feng Xue  
> > >
> > > PR ipa/93763
> > > * ipa-cp.c (self_recursively_generated_p): Mark self-dependent 
> > > value as
> > > self-recursively generated.
> >
> > Honza, this is OK.
> Thanks.  I went ahead and installed Feng's patch.
>

I'm seeing errors with the new testcase:
 end of struct or union
/gcc/testsuite/gcc.dg/ipa/pr93763.c:8:1: warning: data definition has
no type or storage class
/gcc/testsuite/gcc.dg/ipa/pr93763.c:8:1: warning: type defaults to
'int' in declaration of 'e' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:8:4: warning: type defaults to
'int' in declaration of 'k' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:8:7: warning: type defaults to
'int' in declaration of 'ah' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:8:11: warning: type defaults to
'int' in declaration of 'al' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:9:1: warning: return type defaults
to 'int' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:9:1: warning: type of 'aa'
defaults to 'int' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:14:3: warning: implicit
declaration of function 'h' [-Wimplicit-function-declaration]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:16:1: warning: return type
defaults to 'int' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:19:5: warning: implicit
declaration of function 'i' [-Wimplicit-function-declaration]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:22:1: warning: return type
defaults to 'int' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:25:1: warning: return type
defaults to 'int' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:27:3: warning: implicit
declaration of function 'j' [-Wimplicit-function-declaration]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:29:1: warning: return type
defaults to 'int' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:33:1: warning: return type
defaults to 'int' [-Wimplicit-int]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:45:6: warning: passing argument 1
of 'ai' from incompatible pointer type [-Wincompatible-pointer-types]
/gcc/testsuite/gcc.dg/ipa/pr93763.c:45:10: warning: passing argument 2 of 'ai'

I thought I could fix what seemed obvious typos, but it seems the
testcase is bogus (missing types, incompatible arguments, )

I'm probably missing something, but I'm not the only one according to
gcc-testresults: that test fails on many targets.

Christophe

> jeff
> >
>

Re: [Patch,wwwdocs,committed] OpenACC + AMD GCN entry for gcc-10/changes.html


… and fixing the syntax error (duplicated ).

Tobias

commit 8c721971af041d5df125d83df5a5b2d1390d77ac
Author: Tobias Burnus 
Date:   Mon Feb 24 11:28:31 2020 +0100

htdocs/gcc-10/changes.html – fix syntax

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 83b1f071..53d0ca08 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -158,7 +158,7 @@ a work-in-progress.
 https://gcc.gnu.org/wiki/Offloading";>offloading to AMD Radeon
 (GCN) GPUs; supported are the third-generation Fiji (fiji)
 and the fifth-generation VEGA 10/VEGA 20 (gfx900 or
-gfx906).
+gfx906).

Re: [PATCH] libstd++: Library-side tests for parenthesized aggregate init (c++/92878, c++/92947)


On 23/02/20 15:18 +0200, Ville Voutilainen wrote:

This shebang adds library tests for all cases of parenthesized aggregate
initialization that I could find. Tested locally on Linux-x64, going to
test with full suite on Linux-PPC64, OK for trunk if tests pass?


Please add: { dg-do run { target c++2a } }

Tests that aren't valid in all modes should be marked as such. Some
day I'd like the library tests to be able to run automatically for
multiple -std variations, like the front end tests do. To do that we'd
want to remove all -std flags from dg-options, and at that point we
need the tests to be correctly marked so they won't try to run for
-std=c++98 etc.

OK with that change if testing passes, thanks.

[Patch, Fortran, committed] OpenACC tile clause – apply exit/cycle checks (PR 93552)

All is about OpenACC. First, when testing, I found out that "kernels 
loop" wasn't checked for – only serial/parallel loop and an "acc loop".


For nested loops, besides using the "collapse" clause also the "tile" 
clause can be used. Internally, those are processed identically (on the 
FE side) but "tile" wins if both are specified. Hence:


NOTE: I only do check of "tile" – if tile is for a nest level of n while 
collapse is for a nest level > n, invalid use related to collapse, only, 
are not detected. That's in line with the later implementation where 
"tile" has a higher priority.


For "collapse" exits from the loop and "cycle" to any but the innermost 
loop was ready rejected – for "tile" this was not checked for – and, 
hence, accepted. As the rest of the code wasn't prepared for it, it lead 
to an ICE.


In my understanding of the OpenACC spec ("tightly nested loop", 
semantic) "tile" and "collapse" have the same restriction such that the 
attached test case is invalid. (However, the bug reported marked it as 
'ice-on-valid-code'.)


Committed as Rev. r10-6808-g2bd8c3ff3511df8781dd9f3777efab20572d29ab

Cheers,

Tobias

commit 2bd8c3ff3511df8781dd9f3777efab20572d29ab
Author: Tobias Burnus 
Date:   Mon Feb 24 12:18:04 2020 +0100

OpenACC tile clause – apply exit/cycle checks (PR 93552)

PR fortran/93552
* match.c (match_exit_cycle): With OpenACC, check the kernels loop
directive and tile clause as well.

PR fortran/93552
* gfortran.dg/goacc/tile-4.f90: New.
---
 gcc/fortran/ChangeLog  |  6 ++
 gcc/fortran/match.c| 25 -
 gcc/testsuite/ChangeLog|  7 ++-
 gcc/testsuite/gfortran.dg/goacc/tile-4.f90 | 27 +++
 4 files changed, 59 insertions(+), 6 deletions(-)

diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 1ed6a97366e..94ceb5c8aa3 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,9 @@
+2020-02-24  Tobias Burnus  
+
+	PR fortran/93552
+	* match.c (match_exit_cycle): With OpenACC, check the kernels loop
+	directive and tile clause as well.
+
 2020-02-23  Thomas Koenig  
 
 	PR fortran/93889
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index e4d52245976..17196eb1ae6 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -2878,6 +2878,7 @@ match_exit_cycle (gfc_statement st, gfc_exec_op op)
   && o != NULL
   && o->state == COMP_OMP_STRUCTURED_BLOCK
   && (o->head->op == EXEC_OACC_LOOP
+	  || o->head->op == EXEC_OACC_KERNELS_LOOP
 	  || o->head->op == EXEC_OACC_PARALLEL_LOOP
 	  || o->head->op == EXEC_OACC_SERIAL_LOOP))
 {
@@ -2887,9 +2888,20 @@ match_exit_cycle (gfc_statement st, gfc_exec_op op)
 		  || o->head->next->op == EXEC_DO_WHILE)
 		  && o->previous != NULL
 		  && o->previous->tail->op == o->head->op);
-  if (o->previous->tail->ext.omp_clauses != NULL
-	  && o->previous->tail->ext.omp_clauses->collapse > 1)
-	collapse = o->previous->tail->ext.omp_clauses->collapse;
+  if (o->previous->tail->ext.omp_clauses != NULL)
+	{
+	  /* Both collapsed and tiled loops are lowered the same way, but are not
+	 compatible.  In gfc_trans_omp_do, the tile is prioritized.  */
+	  if (o->previous->tail->ext.omp_clauses->tile_list)
+	{
+	  collapse = 0;
+	  gfc_expr_list *el = o->previous->tail->ext.omp_clauses->tile_list;
+	  for ( ; el; el = el->next)
+		++collapse;
+	}
+	  else if (o->previous->tail->ext.omp_clauses->collapse > 1)
+	collapse = o->previous->tail->ext.omp_clauses->collapse;
+	}
   if (st == ST_EXIT && cnt <= collapse)
 	{
 	  gfc_error ("EXIT statement at %C terminating !$ACC LOOP loop");
@@ -2897,8 +2909,11 @@ match_exit_cycle (gfc_statement st, gfc_exec_op op)
 	}
   if (st == ST_CYCLE && cnt < collapse)
 	{
-	  gfc_error ("CYCLE statement at %C to non-innermost collapsed"
-		 " !$ACC LOOP loop");
+	  gfc_error (o->previous->tail->ext.omp_clauses->tile_list
+		 ? G_("CYCLE statement at %C to non-innermost tiled"
+			  " !$ACC LOOP loop")
+		 : G_("CYCLE statement at %C to non-innermost collapsed"
+			  " !$ACC LOOP loop"));
 	  return MATCH_ERROR;
 	}
 }
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 13c1a132cc1..bd50ffdbd68 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-02-24  Tobias Burnus  
+
+	PR fortran/93552
+	* gfortran.dg/goacc/tile-4.f90: New.
+
 2020-02-24  Prathamesh Kulkarni  
 	Kugan Vivekandarajah  
 
@@ -43,7 +48,7 @@
 2020-02-21  Jan Hubicka  
 	Richard Biener  
 
-  	PR tree-optimization/93586
+	PR tree-optimization/93586
 	* gcc.dg/torture/pr93586.c: New testcase.
 
 2020-02-21  Martin Jambor  
diff --git a/gcc/testsuite/gfortran.dg/goacc/tile-4.f90 b/gcc/testsuite/gfortran.dg/goacc/tile-4.f90
new file mode 100644
index 000..86c22df9b66
--- /dev/null
+++ b/gcc/testsuite/gfortra

Re: [PATCH] Avoid collect2 calling signal unsafe functions and/or unlink, with uninitialized memory (for gcc-9 branch)

2020-02-24 Thread Richard Biener

On Fri, 21 Feb 2020, Bernd Edlinger wrote:

> Hi,
> 
> this fixes the signal handler calling signal unsafe vfprintf and/or passing
> uninitialized memory to unlink in signal handler.
> 
> This time it is the patch for the gcc-9 branch.
> 
> The difference to the gcc-8 branch is in tool_cleanup:
> The variable that suppress the vfprintf is verbose = false;
> not debug = false, to match the different logic in maybe_unlink.
> 
> 
> Bootstrapped and reg-tested with x86_64-pc-linux-gnu.
> Is it OK for the gcc-9 branch?

OK.

Richard.

Re: [PATCH] sccvn: Handle bitfields in push_partial_def [PR93582]

2020-02-24 Thread Richard Biener

On Sat, 22 Feb 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following patch adds support for bitfields to push_partial_def.
> Previously pd.offset and pd.size were counted in bytes and maxsizei
> in bits, now everything is counted in bits.
> 
> Not really sure how much of the further code can be outlined and moved, e.g. 
> the full def and partial def code doesn't have pretty much anything in
> common (the partial defs case basically have some load bit range and a set
> of store bit ranges that at least partially overlap and we need to handle
> all the different cases, like negative pd.offset or non-negative, little vs. 
> bit endian, size so small that we need to preserve original bits on both
> sides of the byte, size that fits or is too large.
> Perhaps the storing of some value into a middle of existing buffer (i.e.
> what push_partial_def now does in the loop) could, but the candidate for
> sharing would be most likely store-merging rather than the other spots in
> sccvn, and I think it is better not to touch store-merging at this stage.
> 
> Yes, I've thought about trying to do everything in place, but the code is
> quite hard to understand and get right already now and if we tried to do the
> optimize on the fly, it would need more special cases and would for gcov
> coverage need more testcases to cover it.  Most of the time the sizes will
> be small.  Furthermore, for bitfields native_encode_expr stores actually
> number of bytes in the mode and not say actual bitsize rounded up to bytes,
> so it wouldn't be just a matter of saving/restoring bytes at the start and
> end, but we might need even 7 further bytes e.g. for __int128 bitfields.
> Perhaps we could have just a fast path for the case where everything is byte
> aligned and (for integral types the mode bitsize is equal to the size too)?
> 
> Bootstrapped/regtested on {x86_64,i686,powerpc64{,le}}-linux, on
> powerpc64-linux with -m32/-m64 testing, on {x86_64,i686}-linux
> bootstrap/regtests together I've also gathered statistics, where the
> new code (where something in the partial defs handling wasn't byte
> aligned/sized and still found a constant) triggered 5266 times,
> attached is sort | uniq -c | sort -n list of those, i.e. first column
> is number of times it hit in the same file/function/wordsize (across
> the 2 bootstraps/regtests), second is BITS_PER_WORD, third is filename
> and last is current_function_name ().
> 
> Ok for trunk?

OK.

Thanks,
Richard.

> 2020-02-22  Jakub Jelinek  
> 
>   PR tree-optimization/93582
>   * tree-ssa-sccvn.c (vn_walk_cb_data::push_partial_def): Consider
>   pd.offset and pd.size to be counted in bits rather than bytes, add
>   support for maxsizei that is not a multiple of BITS_PER_UNIT and
>   handle bitfield stores and loads.
>   (vn_reference_lookup_3): Don't call ranges_known_overlap_p with
>   uncomparable quantities - bytes vs. bits.  Allow push_partial_def
>   on offsets/sizes that aren't multiple of BITS_PER_UNIT and adjust
>   pd.offset/pd.size to be counted in bits rather than bytes.
>   Formatting fix.  Rename shadowed len variable to buflen.
> 
>   * gcc.dg/tree-ssa/pr93582-4.c: New test.
>   * gcc.dg/tree-ssa/pr93582-5.c: New test.
>   * gcc.dg/tree-ssa/pr93582-6.c: New test.
>   * gcc.dg/tree-ssa/pr93582-7.c: New test.
>   * gcc.dg/tree-ssa/pr93582-8.c: New test.
> 
> --- gcc/tree-ssa-sccvn.c.jj   2020-02-18 08:52:26.156952846 +0100
> +++ gcc/tree-ssa-sccvn.c  2020-02-18 15:44:53.446837342 +0100
> @@ -1774,7 +1774,11 @@ vn_walk_cb_data::push_partial_def (const
>const HOST_WIDE_INT bufsize = 64;
>/* We're using a fixed buffer for encoding so fail early if the object
>   we want to interpret is bigger.  */
> -  if (maxsizei > bufsize * BITS_PER_UNIT)
> +  if (maxsizei > bufsize * BITS_PER_UNIT
> +  || CHAR_BIT != 8
> +  || BITS_PER_UNIT != 8
> +  /* Not prepared to handle PDP endian.  */
> +  || BYTES_BIG_ENDIAN != WORDS_BIG_ENDIAN)
>  return (void *)-1;
>  
>bool pd_constant_p = (TREE_CODE (pd.rhs) == CONSTRUCTOR
> @@ -1854,41 +1858,39 @@ vn_walk_cb_data::push_partial_def (const
>/* Now we have merged newr into the range tree.  When we have covered
>   [offseti, sizei] then the tree will contain exactly one node which has
>   the desired properties and it will be 'r'.  */
> -  if (!known_subrange_p (0, maxsizei / BITS_PER_UNIT, r->offset, r->size))
> +  if (!known_subrange_p (0, maxsizei, r->offset, r->size))
>  /* Continue looking for partial defs.  */
>  return NULL;
>  
>/* Now simply native encode all partial defs in reverse order.  */
>unsigned ndefs = partial_defs.length ();
>/* We support up to 512-bit values (for V8DFmode).  */
> -  unsigned char buffer[bufsize];
> +  unsigned char buffer[bufsize + 1];
> +  unsigned char this_buffer[bufsize + 1];
>int len;
>  
> +  memset (buffer, 0, bufsize + 1);
> +  unsigned needed_len = ROUND_UP (maxsizei, BITS_P

[PATCH] testsuite: Fix recently added ipa testcases [PR93763]

2020-02-24 Thread Jakub Jelinek

On Mon, Feb 24, 2020 at 11:09:58AM +0100, Christophe Lyon wrote:
> I'm seeing errors with the new testcase:
>  end of struct or union
> /gcc/testsuite/gcc.dg/ipa/pr93763.c:8:1: warning: data definition has
> no type or storage class
...

Seems the test has been badly reduced (if the original doesn't emit
warnings, it is always better in the reduction script avoid introducing new
ones).
Also, the g++.dg/ipa/ test fails with -std=c++98 because it is written in
C++11.

Fixed thusly, ok for trunk?

2020-02-24  Jakub Jelinek  

PR ipa/93763
* gcc.dg/ipa/pr93763.c: Adjust the test so that it compiles without
warnings and still ICEs before the ipa-cp.c fix.
* g++.dg/ipa/pr93763.C: Require c++11 effective target.

--- gcc/testsuite/gcc.dg/ipa/pr93763.c.jj   2020-02-24 12:44:09.626326146 
+0100
+++ gcc/testsuite/gcc.dg/ipa/pr93763.c  2020-02-24 12:40:48.707320934 +0100
@@ -3,44 +3,48 @@
 
 typedef struct a a;
 struct a {
-  a *b
+  a *b;
 } d;
-e, k, ah, al;
-f(aa) {
+int e, k, ah, al;
+void h(void);
+void
+f(aa) int aa; {
   if (aa & 1)
 goto g;
   f(aa | 2);
 g:
   h();
 }
+void i();
+void
 l() {
-  {
 f(072);
 i(e, d, 92);
-  }
 }
+void
 ag() {
-  { i(e, d, 36); }
+  i(e, d, 36);
 }
+void j();
+void
 ai(a *m, a *n, unsigned aa) {
   f(aa);
   j(k, l, ah, 1);
 }
+void
 j(int c, a m, int aj, int aa) {
   int ak = aa;
-  { i(e, d, ak); }
+  i(e, d, ak);
 }
+void
 i(int c, a *m, unsigned aa) {
-  {
-{ i(c, 
(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(
+  i(c, 
(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(
 
*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(
 
*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*m).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
 
.b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
 
.b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
 
.b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
 
.b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b,
 0);
-}
-  }
   int am = aa;
-  ai(ag, al, am);
+  ai((a *) (void *) ag, (a *) (__INTPTR_TYPE__) al, am);
 }
--- gcc/testsuite/g++.dg/ipa/pr93763.C.jj   2020-02-21 21:54:56.616348316 
+0100
+++ gcc/testsuite/g++.dg/ipa/pr93763.C  2020-02-24 12:35:02.061484741 +0100
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target c++11 } } */
 /* { dg-options "-O3" } */
 
 struct search_param {


Jakub

Re: [Regression, patch][Fortran] ICE in gfc_conv_constant_to_tree PR93604


**ping**

On 17/02/2020 11:26, Mark Eggleston wrote:

Please find attached patch for PR93604.

gcc/fortran/ChangeLog

    Steven G. Kargl  

    PR fortran/93604
    * decl.c (gfc_match_data) : Check whether the data expression
    is a derived type and is a constructor. If a BOZ constant
    is encountered in the constructor output an error and return
    MATCH_ERROR.

gcc/testsuite/ChangeLog

    Mark Eggleston  

    PR fortran/93604
    * gfortran.dg/pr93604.f90 : New test.

OK to commit?


--
https://www.codethink.co.uk/privacy.html

[committed] libstdc++: enable_view has false positives (LWG 3326)

* include/std/ranges (__deep_const_range, __enable_view_impl): Remove.
(ranges::enable_view): Simplify (LWG 3326).
* include/bits/range_access.h (ranges::enable_view): Declare.
* include/bits/regex.h (__enable_view_impl): Remove partial
specialization.
* include/bits/stl_multiset.h (__enable_view_impl): Likewise.
* include/bits/stl_set.h (__enable_view_impl): Likewise.
* include/bits/unordered_set.h (__enable_view_impl): Likewise.
* include/debug/multiset.h (__enable_view_impl): Likewise.
* include/debug/set.h (__enable_view_impl): Likewise.
* include/debug/unordered_set (__enable_view_impl): Likewise.
* include/experimental/string_view (ranges::enable_view): Define
partial specialization.
* include/std/span (ranges::enable_view): Likewise.
* include/std/string_view (ranges::enable_view): Likewise.
* testsuite/std/ranges/view.cc: Check satisfaction of updated concept.

Tested powerpc64le-linux, committed to master.

commit 3841739c29a54c0141c3156cdd47891c258b2b88
Author: Jonathan Wakely 
Date:   Mon Feb 24 11:45:20 2020 +

libstdc++: enable_view has false positives (LWG 3326)

* include/std/ranges (__deep_const_range, __enable_view_impl): 
Remove.
(ranges::enable_view): Simplify (LWG 3326).
* include/bits/range_access.h (ranges::enable_view): Declare.
* include/bits/regex.h (__enable_view_impl): Remove partial
specialization.
* include/bits/stl_multiset.h (__enable_view_impl): Likewise.
* include/bits/stl_set.h (__enable_view_impl): Likewise.
* include/bits/unordered_set.h (__enable_view_impl): Likewise.
* include/debug/multiset.h (__enable_view_impl): Likewise.
* include/debug/set.h (__enable_view_impl): Likewise.
* include/debug/unordered_set (__enable_view_impl): Likewise.
* include/experimental/string_view (ranges::enable_view): Define
partial specialization.
* include/std/span (ranges::enable_view): Likewise.
* include/std/string_view (ranges::enable_view): Likewise.
* testsuite/std/ranges/view.cc: Check satisfaction of updated 
concept.

diff --git a/libstdc++-v3/include/bits/range_access.h 
b/libstdc++-v3/include/bits/range_access.h
index eb91ade35ff..8b276fd6625 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -346,6 +346,9 @@ namespace ranges
   template
 inline constexpr bool enable_borrowed_range = false;
 
+  template
+extern const bool enable_view;
+
   namespace __detail
   {
 template
diff --git a/libstdc++-v3/include/bits/regex.h 
b/libstdc++-v3/include/bits/regex.h
index 3307e1c917c..dcae83eea4e 100644
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -2058,16 +2058,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 
 _GLIBCXX_END_NAMESPACE_CXX11
 
-#if __cplusplus > 201703L
-namespace ranges::__detail
-{
-  template extern inline const bool __enable_view_impl;
-  template
-inline constexpr bool __enable_view_impl>
-  = false;
-} // namespace ranges::__detail
-#endif // C++20
-
   // [28.11.2] Function template regex_match
   /**
* @name Matching, Searching, and Replacing
diff --git a/libstdc++-v3/include/bits/stl_multiset.h 
b/libstdc++-v3/include/bits/stl_multiset.h
index b8b82912c91..ab62df1e508 100644
--- a/libstdc++-v3/include/bits/stl_multiset.h
+++ b/libstdc++-v3/include/bits/stl_multiset.h
@@ -1038,17 +1038,6 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
   _S_get_tree(_GLIBCXX_STD_C::multiset<_Val, _Cmp2, _Alloc>& __set)
   { return __set._M_t; }
 };
-
-#if __cplusplus > 201703L
-namespace ranges::__detail
-{
-  template extern inline const bool __enable_view_impl;
-  template
-inline constexpr bool
-  __enable_view_impl<_GLIBCXX_STD_C::multiset<_Key, _Compare, _Alloc>>
-   = false;
-} // namespace ranges::__detail
-#endif // C++20
 #endif // C++17
 
 _GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/include/bits/stl_set.h 
b/libstdc++-v3/include/bits/stl_set.h
index 5f3e78dc470..4f8d631bb3b 100644
--- a/libstdc++-v3/include/bits/stl_set.h
+++ b/libstdc++-v3/include/bits/stl_set.h
@@ -1051,15 +1051,6 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
   _S_get_tree(_GLIBCXX_STD_C::multiset<_Val, _Cmp2, _Alloc>& __set)
   { return __set._M_t; }
 };
-#if __cplusplus > 201703L
-namespace ranges::__detail
-{
-  template extern inline const bool __enable_view_impl;
-  template
-inline constexpr bool
-  __enable_view_impl<_GLIBCXX_STD_C::set<_Key, _Compare, _Alloc>> = false;
-} // namespace ranges::__detail
-#endif // C++20
 #endif // C++17
 
 _GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/include/bits/unordered_set.h 
b/libstdc++-v3/include/bits/unordered_set.h
index 824eedbae3e..9c2cd45be9c 100644
--- a/libstdc++-v3/include/bit

Re: Patch to fix PR93272

2020-02-24 Thread Matthias Klose

On 1/28/20 9:52 PM, Vladimir Makarov wrote:
> The following patch fixes
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
> 
> The patch was successfully tested and bootstrapped on x86_64.
> 
> Unfortunately it is hard to create a test case for the patch.  So there is no
> test for this PR.

the bug report asks for a backport to the gcc-8 and gcc-9 branches.

[9/10 Regression, fortran, patch] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

Please find attached a patch to fix PR93835. This patch ensures that the 
array returned by SHAPE has its shape defined, the original patch from 
Steve Kargl handled the lack of shape for the returned array.


The bonus white space issues fixed in the original patch have been retained.

A side affect of the patch is a change in the errors expected by the 
test case pr77351.f90. Instead of "Error: Different shape for elemental 
binary operation at (1) on dimension 1 (1 and 2)" and "Error: Array 
operands are incommensurate at (1)" there is only "Error: Shapes for 
operands at (1) and (2) are not conformable" which is effectively the same.


gcc/fortran/ChangeLog

    Mark Eggleston 
    Steven G. Kargl 

    PR fortran/93835
    * decl.c (gfc_match_data) : Check whether the data expression
    is a derived type and is a constructor. If a BOZ constant
    is encountered in the constructor output an error and return
    MATCH_ERROR.

gcc/testsuite/ChangeLog

    Mark Eggleston 

    PR fortran/93835
    * gfortran.dg/pr77351.f90 : Check for one error instead of two.
    * gfortran.dg/pr93835.f08 : New test.

--
https://www.codethink.co.uk/privacy.html

--
https://www.codethink.co.uk/privacy.html

>From b4a3defca6a9a7fa0c8b407a4d2f906dc074079d Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Thu, 20 Feb 2020 13:25:39 +
Subject: [PATCH] fortran: ICE using SHAPE with FINDLOC PR93835

The expression reprenting the array returned by SHAPE does not
have its shape defined. An ICE occurs when FINDLOC attempts to
use the shape of the array.

Whitespace issues identified by Steven G. Kargl  
have also been fixed.

gcc/fortran/ChangeLog

	PR fortran/93835
	* simplify.c (simplify_findloc_nodim) : Fix whitespace issues.
	(gfc_simplify_shape) : Create and initialise one shape value
	for the result expression. Set shape value with the rank of
	the source array.

gcc/testsuite/ChangeLog

	PR fortran/93835
	* gfortran.dg/pr77351.f90 : Check for one error instead of two.
	* gfortran.dg/pr93835.f08 : New test.
---
 gcc/fortran/simplify.c| 12 
 gcc/testsuite/gfortran.dg/pr77351.f90 |  6 --
 gcc/testsuite/gfortran.dg/pr93835.f08 |  8 
 3 files changed, 20 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr93835.f08

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 613fdafd1a6..eb9d2f2c759 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -5497,7 +5497,7 @@ simplify_findloc_nodim (gfc_expr *result, gfc_expr *value, gfc_expr *array,
   bool continue_loop;
   bool ma;
 
-  for (i = 0; irank; i++)
+  for (i = 0; i < array->rank; i++)
 res[i] = -1;
 
   /* Shortcut for constant .FALSE. MASK.  */
@@ -5540,7 +5540,7 @@ simplify_findloc_nodim (gfc_expr *result, gfc_expr *value, gfc_expr *array,
 
 	  if (ma && gfc_compare_expr (a, value, INTRINSIC_EQ) == 0)
 	{
-	  for (i = 0; irank; i++)
+	  for (i = 0; i < array->rank; i++)
 		res[i] = count[i];
 	  if (!back_val)
 		goto finish;
@@ -5565,9 +5565,9 @@ simplify_findloc_nodim (gfc_expr *result, gfc_expr *value, gfc_expr *array,
 	} while (count[n] == extent[n]);
 }
 
- finish:
+finish:
   result_ctor = gfc_constructor_first (result->value.constructor);
-  for (i = 0; irank; i++)
+  for (i = 0; i < array->rank; i++)
 {
   gfc_expr *r_expr;
   r_expr = result_ctor->expr;
@@ -7228,6 +7228,8 @@ gfc_simplify_shape (gfc_expr *source, gfc_expr *kind)
 return NULL;
 
   result = gfc_get_array_expr (BT_INTEGER, k, &source->where);
+  result->shape = gfc_get_shape (1);
+  mpz_init (result->shape[0]);
 
   if (source->rank == 0)
 return result;
@@ -7284,6 +7286,8 @@ gfc_simplify_shape (gfc_expr *source, gfc_expr *kind)
   if (t)
 gfc_clear_shape (shape, source->rank);
 
+  mpz_set_si (result->shape[0], source->rank);
+  
   return result;
 }
 
diff --git a/gcc/testsuite/gfortran.dg/pr77351.f90 b/gcc/testsuite/gfortran.dg/pr77351.f90
index 76ce5c528b2..e3e8bc4f64b 100644
--- a/gcc/testsuite/gfortran.dg/pr77351.f90
+++ b/gcc/testsuite/gfortran.dg/pr77351.f90
@@ -1,6 +1,8 @@
 ! { dg-do compile }
+!
+! PR93835 resulted in different but valid error message
 program p
integer :: z(4) = [1, 2, 3, 4]
-   print *, any(shape(z) /= [4,1])  ! { dg-error "shape for elemental binary" }
+   print *, any(shape(z) /= [4,1])  ! { dg-error "Shapes for operands at .1. and .2. are not conformable" }
 end
-! { dg-excess-errors "operands are incommensurate" }
+
diff --git a/gcc/testsuite/gfortran.dg/pr93835.f08 b/gcc/testsuite/gfortran.dg/pr93835.f08
new file mode 100644
index 000..933e249e632
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr93835.f08
@@ -0,0 +1,8 @@
+! {dg-do run }
+!
+! PR fortran/93835 - the following code resulted in an ICE
+!
+program p
+  if (any(findloc(shape(1), 1) .ne. 0)) stop 1
+end
+
-- 
2.11.0

Re: [PATCH] testsuite: Fix recently added ipa testcases [PR93763]

On Mon, 24 Feb 2020 at 12:50, Jakub Jelinek  wrote:
>
> On Mon, Feb 24, 2020 at 11:09:58AM +0100, Christophe Lyon wrote:
> > I'm seeing errors with the new testcase:
> >  end of struct or union
> > /gcc/testsuite/gcc.dg/ipa/pr93763.c:8:1: warning: data definition has
> > no type or storage class
> ...
>
> Seems the test has been badly reduced (if the original doesn't emit
> warnings, it is always better in the reduction script avoid introducing new
> ones).
> Also, the g++.dg/ipa/ test fails with -std=c++98 because it is written in
> C++11.
>
> Fixed thusly, ok for trunk?

Works for me, thanks

>
> 2020-02-24  Jakub Jelinek  
>
> PR ipa/93763
> * gcc.dg/ipa/pr93763.c: Adjust the test so that it compiles without
> warnings and still ICEs before the ipa-cp.c fix.
> * g++.dg/ipa/pr93763.C: Require c++11 effective target.
>
> --- gcc/testsuite/gcc.dg/ipa/pr93763.c.jj   2020-02-24 12:44:09.626326146 
> +0100
> +++ gcc/testsuite/gcc.dg/ipa/pr93763.c  2020-02-24 12:40:48.707320934 +0100
> @@ -3,44 +3,48 @@
>
>  typedef struct a a;
>  struct a {
> -  a *b
> +  a *b;
>  } d;
> -e, k, ah, al;
> -f(aa) {
> +int e, k, ah, al;
> +void h(void);
> +void
> +f(aa) int aa; {
>if (aa & 1)
>  goto g;
>f(aa | 2);
>  g:
>h();
>  }
> +void i();
> +void
>  l() {
> -  {
>  f(072);
>  i(e, d, 92);
> -  }
>  }
> +void
>  ag() {
> -  { i(e, d, 36); }
> +  i(e, d, 36);
>  }
> +void j();
> +void
>  ai(a *m, a *n, unsigned aa) {
>f(aa);
>j(k, l, ah, 1);
>  }
> +void
>  j(int c, a m, int aj, int aa) {
>int ak = aa;
> -  { i(e, d, ak); }
> +  i(e, d, ak);
>  }
> +void
>  i(int c, a *m, unsigned aa) {
> -  {
> -{ i(c, 
> (*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(
> +  i(c, 
> (*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(
>  
> *(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(
>  
> *(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*m).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
>  
> .b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
>  
> .b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
>  
> .b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b)
>  
> .b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b).b,
>  0);
> -}
> -  }
>int am = aa;
> -  ai(ag, al, am);
> +  ai((a *) (void *) ag, (a *) (__INTPTR_TYPE__) al, am);
>  }
> --- gcc/testsuite/g++.dg/ipa/pr93763.C.jj   2020-02-21 21:54:56.616348316 
> +0100
> +++ gcc/testsuite/g++.dg/ipa/pr93763.C  2020-02-24 12:35:02.061484741 +0100
> @@ -1,4 +1,4 @@
> -/* { dg-do compile } */
> +/* { dg-do compile { target c++11 } } */
>  /* { dg-options "-O3" } */
>
>  struct search_param {
>
>
> Jakub
>

Re: [9/10 Regression, fortran, patch] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513


Forgot to add the purpose of the e-mail: OK to commit?

On 24/02/2020 12:24, Mark Eggleston wrote:
Please find attached a patch to fix PR93835. This patch ensures that 
the array returned by SHAPE has its shape defined, the original patch 
from Steve Kargl handled the lack of shape for the returned array.


The bonus white space issues fixed in the original patch have been 
retained.


A side affect of the patch is a change in the errors expected by the 
test case pr77351.f90. Instead of "Error: Different shape for 
elemental binary operation at (1) on dimension 1 (1 and 2)" and 
"Error: Array operands are incommensurate at (1)" there is only 
"Error: Shapes for operands at (1) and (2) are not conformable" which 
is effectively the same.


gcc/fortran/ChangeLog

    Mark Eggleston 
    Steven G. Kargl 

    PR fortran/93835
    * decl.c (gfc_match_data) : Check whether the data expression
    is a derived type and is a constructor. If a BOZ constant
    is encountered in the constructor output an error and return
    MATCH_ERROR.

gcc/testsuite/ChangeLog

    Mark Eggleston 

    PR fortran/93835
    * gfortran.dg/pr77351.f90 : Check for one error instead of two.
    * gfortran.dg/pr93835.f08 : New test.


--
https://www.codethink.co.uk/privacy.html

PING^8: [PATCH 00/10] i386: Properly encode xmm16-xmm31/ymm16-ymm31 for vector move

2020-02-24 Thread H.J. Lu

On Sat, Feb 15, 2020 at 7:26 AM H.J. Lu  wrote:
>
> This patch set was originally submitted in Feb 2019:
>
> https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01841.html
>
> I broke it into 10 smaller patches for easy review.
>
> On x86, when AVX and AVX512 are enabled, vector move instructions can
> be encoded with either 2-byte/3-byte VEX (AVX) or 4-byte EVEX (AVX512):
>
>0:   c5 f9 6f d1 vmovdqa %xmm1,%xmm2
>4:   62 f1 fd 08 6f d1   vmovdqa64 %xmm1,%xmm2
>
> We prefer VEX encoding over EVEX since VEX is shorter.  Also AVX512F
> only supports 512-bit vector moves.  AVX512F + AVX512VL supports 128-bit
> and 256-bit vector moves.  Mode attributes on x86 vector move patterns
> indicate target preferences of vector move encoding.  For vector register
> to vector register move, we can use 512-bit vector move instructions to
> move 128-bit/256-bit vector if AVX512VL isn't available.  With AVX512F
> and AVX512VL, we should use VEX encoding for 128-bit/256-bit vector moves
> if upper 16 vector registers aren't used.  This patch adds a function,
> ix86_output_ssemov, to generate vector moves:
>
> 1. If zmm registers are used, use EVEX encoding.
> 2. If xmm16-xmm31/ymm16-ymm31 registers aren't used, SSE or VEX encoding
> will be generated.
> 3. If xmm16-xmm31/ymm16-ymm31 registers are used:
>a. With AVX512VL, AVX512VL vector moves will be generated.
>b. Without AVX512VL, xmm16-xmm31/ymm16-ymm31 register to register
>   move will be done with zmm register move.
>
> Tested on AVX2 and AVX512 with and without --with-arch=native.
>
> H.J. Lu (10):
>   i386: Properly encode vector registers in vector move
>   i386: Use ix86_output_ssemov for XImode TYPE_SSEMOV
>   i386: Use ix86_output_ssemov for OImode TYPE_SSEMOV
>   i386: Use ix86_output_ssemov for TImode TYPE_SSEMOV
>   i386: Use ix86_output_ssemov for DImode TYPE_SSEMOV
>   i386: Use ix86_output_ssemov for SImode TYPE_SSEMOV
>   i386: Use ix86_output_ssemov for TFmode TYPE_SSEMOV
>   i386: Use ix86_output_ssemov for DFmode TYPE_SSEMOV
>   i386: Use ix86_output_ssemov for SFmode TYPE_SSEMOV
>   i386: Use ix86_output_ssemov for MMX TYPE_SSEMOV
>
>  gcc/config/i386/i386-protos.h |   2 +
>  gcc/config/i386/i386.c| 274 ++
>  gcc/config/i386/i386.md   | 212 +-
>  gcc/config/i386/mmx.md|  29 +-
>  gcc/config/i386/predicates.md |   5 -
>  gcc/config/i386/sse.md|  98 +--
>  .../gcc.target/i386/avx512vl-vmovdqa64-1.c|   7 +-
>  gcc/testsuite/gcc.target/i386/pr89229-2a.c|  15 +
>  gcc/testsuite/gcc.target/i386/pr89229-2b.c|  13 +
>  gcc/testsuite/gcc.target/i386/pr89229-2c.c|   6 +
>  gcc/testsuite/gcc.target/i386/pr89229-3a.c|  17 ++
>  gcc/testsuite/gcc.target/i386/pr89229-3b.c|   6 +
>  gcc/testsuite/gcc.target/i386/pr89229-3c.c|   7 +
>  gcc/testsuite/gcc.target/i386/pr89229-4a.c|  17 ++
>  gcc/testsuite/gcc.target/i386/pr89229-4b.c|   6 +
>  gcc/testsuite/gcc.target/i386/pr89229-4c.c|   7 +
>  gcc/testsuite/gcc.target/i386/pr89229-5a.c|  16 +
>  gcc/testsuite/gcc.target/i386/pr89229-5b.c|  12 +
>  gcc/testsuite/gcc.target/i386/pr89229-5c.c|   6 +
>  gcc/testsuite/gcc.target/i386/pr89229-6a.c|  16 +
>  gcc/testsuite/gcc.target/i386/pr89229-6b.c|   7 +
>  gcc/testsuite/gcc.target/i386/pr89229-6c.c|   6 +
>  gcc/testsuite/gcc.target/i386/pr89229-7a.c|  16 +
>  gcc/testsuite/gcc.target/i386/pr89229-7b.c|   6 +
>  gcc/testsuite/gcc.target/i386/pr89229-7c.c|   6 +
>  gcc/testsuite/gcc.target/i386/pr89346.c   |  15 +
>  26 files changed, 497 insertions(+), 330 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-2a.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-2b.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-2c.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-3a.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-3b.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-3c.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-4a.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-4b.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-4c.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-5a.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-5b.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-5c.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-6a.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-6b.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-6c.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-7a.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-7b.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89229-7c.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr89346.c
>

PING:

https://gcc.gnu.org/ml/

Re: [PR47785] COLLECT_AS_OPTIONS

On Mon, 24 Feb 2020 at 07:32, Prathamesh Kulkarni
 wrote:
>
> On Wed, 19 Feb 2020 at 19:54, Richard Biener  
> wrote:
> >
> > On Wed, Feb 19, 2020 at 12:19 AM Prathamesh Kulkarni
> >  wrote:
> > >
> > > On Tue, 18 Feb 2020 at 19:40, Richard Biener  
> > > wrote:
> > > >
> > > > On Tue, Feb 18, 2020 at 1:52 PM Prathamesh Kulkarni
> > > >  wrote:
> > > > >
> > > > > On Mon, 17 Feb 2020 at 19:52, Richard Biener 
> > > > >  wrote:
> > > > > >
> > > > > > On Mon, Feb 17, 2020 at 10:28 AM Prathamesh Kulkarni
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Thu, 6 Feb 2020 at 20:03, Prathamesh Kulkarni
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Thu, 6 Feb 2020 at 18:42, Richard Biener 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Feb 6, 2020 at 1:48 PM Prathamesh Kulkarni
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, 4 Feb 2020 at 19:44, Richard Biener 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Feb 3, 2020 at 12:37 PM Prathamesh Kulkarni
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, 30 Jan 2020 at 19:10, Richard Biener 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Jan 30, 2020 at 5:31 AM Prathamesh Kulkarni
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, 28 Jan 2020 at 17:17, Richard Biener 
> > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Jan 24, 2020 at 7:04 AM Prathamesh 
> > > > > > > > > > > > > > > Kulkarni
> > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Mon, 20 Jan 2020 at 15:44, Richard Biener 
> > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Jan 8, 2020 at 11:20 AM Prathamesh 
> > > > > > > > > > > > > > > > > Kulkarni
> > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, 5 Nov 2019 at 17:38, Richard Biener 
> > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2019 at 12:17 AM Kugan 
> > > > > > > > > > > > > > > > > > > Vivekanandarajah
> > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, 5 Nov 2019 at 03:57, H.J. Lu 
> > > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Sun, Nov 3, 2019 at 6:45 PM Kugan 
> > > > > > > > > > > > > > > > > > > > > Vivekanandarajah
> > > > > > > > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thanks for the reviews.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Sat, 2 Nov 2019 at 02:49, H.J. 
> > > > > > > > > > > > > > > > > > > > > > Lu  wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Thu, Oct 31, 2019 at 6:33 PM 
> > > > > > > > > > > > > > > > > > > > > > > Kugan Vivekanandarajah
> > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Wed, 30 Oct 2019 at 03:11, 
> > > > > > > > > > > > > > > > > > > > > > > > H.J. Lu  
> > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Oct 27, 2019 at 6:33 
> > > > > > > > > > > > > > > > > > > > > > > > > PM Kugan Vivekanandarajah
> > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Hi Richard,
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for the review.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 23 Oct 2019 at 
> > > > > > > > > > > > > > > > > > > > > > > > > > 23:07, Richard Biener 
> > > > > > > > > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Oct 21, 2019 at 
> > > > > > > > > > > > > > > > > > > > > > > > > > > 10:04 AM Kugan 
> > > > > > > > > > > > > > > > > > > > > > > > > > > Vivekanandarajah
> > > >

Re: [9/10 Regression, fortran, patch] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

2020-02-24 Thread Thomas Koenig


Hi Mark,

OK for both trunk and gcc-9.

Thanks for taking this up, and thanks to Steve for debugging
this in the first place!

Regards

Thomas

[PATCH] libstdc++: Add missing bits of P0896R4 pertaining to [back|front]_insert_iterator

This adds some missing pieces of the Ranges TS that make back_insert_iterator 
and
front_insert_iterator conform to the new output_iterator requirements.

It also fixes a bug in ranges::__copy_or_move and
ranges::__copy_or_move_backward in which we were inspecting the iter_value_t of
the output iterator, but iterators such as back_insert_iterator and
front_insert_iterator whose value_type is defined to be void do not have an
iter_value_t according to [readable.traits] p4.  The entire __use_memmove
condition can probably be refactored, but the simplest fix for now is to inspect
the iterator_traits of the output iterator instead.

libstdc++-v3/ChangeLog:

PR libstdc++/93884
* include/bits/ranges_algobase.h (__copy_or_move,
__copy_or_move_backward): Don't inspect the iter_value_t of the output
iterator, instead inspect its iterator_traits directly.
* include/bits/stl_iterator.h (back_insert_iterator::container):
Conditionally initialize.
(back_insert_iterator::difference_type): Conditionally define.
(back_insert_iterator::back_insert_iterator): Conditionally define this
default constructor.
(front_insert_iterator::container): Conditionally initialize.
(front_insert_iterator::difference_type): Conditionally define.
(front_insert_iterator::front_insert_iterator): Conditionally define
this default constructor.
---
 libstdc++-v3/include/bits/ranges_algobase.h   |  4 +-
 libstdc++-v3/include/bits/stl_iterator.h  | 22 ++
 .../back_insert_iterator/pr93884.C| 44 +++
 .../front_insert_iterator/pr93884.C   | 44 +++
 4 files changed, 112 insertions(+), 2 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/24_iterators/back_insert_iterator/pr93884.C
 create mode 100644 
libstdc++-v3/testsuite/24_iterators/front_insert_iterator/pr93884.C

diff --git a/libstdc++-v3/include/bits/ranges_algobase.h 
b/libstdc++-v3/include/bits/ranges_algobase.h
index 807822e99c8..739424e1a2d 100644
--- a/libstdc++-v3/include/bits/ranges_algobase.h
+++ b/libstdc++-v3/include/bits/ranges_algobase.h
@@ -249,7 +249,7 @@ namespace ranges
   else if constexpr (sized_sentinel_for<_Sent, _Iter>)
{
  using _ValueTypeI = iter_value_t<_Iter>;
- using _ValueTypeO = iter_value_t<_Out>;
+ using _ValueTypeO = iterator_traits<_Out>::value_type;
  constexpr bool __use_memmove
= (is_trivially_copyable_v<_ValueTypeI>
   && is_same_v<_ValueTypeI, _ValueTypeO>
@@ -386,7 +386,7 @@ namespace ranges
   else if constexpr (sized_sentinel_for<_Sent, _Iter>)
{
  using _ValueTypeI = iter_value_t<_Iter>;
- using _ValueTypeO = iter_value_t<_Out>;
+ using _ValueTypeO = iterator_traits<_Out>::value_type;
  constexpr bool __use_memmove
= (is_trivially_copyable_v<_ValueTypeI>
   && is_same_v<_ValueTypeI, _ValueTypeO>
diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
b/libstdc++-v3/include/bits/stl_iterator.h
index 372df223113..0f2742ae4cf 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -496,11 +496,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : public iterator
 {
 protected:
+#if __cplusplus > 201703L
+  _Container* container = nullptr;
+#else
   _Container* container;
+#endif
 
 public:
   /// A nested typedef for the type of whatever container you used.
   typedef _Container  container_type;
+#if __cplusplus > 201703L
+  using difference_type = ptrdiff_t;
+#endif
+
+#if __cplusplus > 201703L
+  constexpr back_insert_iterator() noexcept = default;
+#endif
 
   /// The only way to create this %iterator is with a container.
   explicit
@@ -588,11 +599,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : public iterator
 {
 protected:
+#if __cplusplus <= 201703L
   _Container* container;
+#else
+  _Container* container = nullptr;
+#endif
 
 public:
   /// A nested typedef for the type of whatever container you used.
   typedef _Container  container_type;
+#if __cplusplus > 201703L
+  using difference_type = ptrdiff_t;
+#endif
+
+#if __cplusplus > 201703L
+  constexpr front_insert_iterator() noexcept = default;
+#endif
 
   /// The only way to create this %iterator is with a container.
   explicit front_insert_iterator(_Container& __x)
diff --git a/libstdc++-v3/testsuite/24_iterators/back_insert_iterator/pr93884.C 
b/libstdc++-v3/testsuite/24_iterators/back_insert_iterator/pr93884.C
new file mode 100644
index 000..5a6287ddd40
--- /dev/null
+++ b/libstdc++-v3/testsuite/24_iterators/back_insert_iterator/pr93884.C
@@ -0,0 +1,44 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under

Re: [Regression, patch][Fortran] ICE in gfc_conv_constant_to_tree PR93604

2020-02-24 Thread Thomas Koenig


Hi Mark,


**ping**


OK!

Regards

Thomas

Re: [PATCH] libstdc++: Add missing bits of P0896R4 pertaining to [back|front]_insert_iterator

ZOn Mon, 24 Feb 2020, Patrick Palka wrote:

> This adds some missing pieces of the Ranges TS that make back_insert_iterator 
> and
> front_insert_iterator conform to the new output_iterator requirements.
> 
> It also fixes a bug in ranges::__copy_or_move and
> ranges::__copy_or_move_backward in which we were inspecting the iter_value_t 
> of
> the output iterator, but iterators such as back_insert_iterator and
> front_insert_iterator whose value_type is defined to be void do not have an
> iter_value_t according to [readable.traits] p4.  The entire __use_memmove
> condition can probably be refactored, but the simplest fix for now is to 
> inspect
> the iterator_traits of the output iterator instead.
> 
> libstdc++-v3/ChangeLog:
> 
>   PR libstdc++/93884
>   * include/bits/ranges_algobase.h (__copy_or_move,
>   __copy_or_move_backward): Don't inspect the iter_value_t of the output
>   iterator, instead inspect its iterator_traits directly.
>   * include/bits/stl_iterator.h (back_insert_iterator::container):
>   Conditionally initialize.
>   (back_insert_iterator::difference_type): Conditionally define.
>   (back_insert_iterator::back_insert_iterator): Conditionally define this
>   default constructor.
>   (front_insert_iterator::container): Conditionally initialize.
>   (front_insert_iterator::difference_type): Conditionally define.
>   (front_insert_iterator::front_insert_iterator): Conditionally define
>   this default constructor.
> ---
>  libstdc++-v3/include/bits/ranges_algobase.h   |  4 +-
>  libstdc++-v3/include/bits/stl_iterator.h  | 22 ++
>  .../back_insert_iterator/pr93884.C| 44 +++
>  .../front_insert_iterator/pr93884.C   | 44 +++
>  4 files changed, 112 insertions(+), 2 deletions(-)
>  create mode 100644 
> libstdc++-v3/testsuite/24_iterators/back_insert_iterator/pr93884.C
>  create mode 100644 
> libstdc++-v3/testsuite/24_iterators/front_insert_iterator/pr93884.C
> 
> diff --git a/libstdc++-v3/include/bits/ranges_algobase.h 
> b/libstdc++-v3/include/bits/ranges_algobase.h
> index 807822e99c8..739424e1a2d 100644
> --- a/libstdc++-v3/include/bits/ranges_algobase.h
> +++ b/libstdc++-v3/include/bits/ranges_algobase.h
> @@ -249,7 +249,7 @@ namespace ranges
>else if constexpr (sized_sentinel_for<_Sent, _Iter>)
>   {
> using _ValueTypeI = iter_value_t<_Iter>;
> -   using _ValueTypeO = iter_value_t<_Out>;
> +   using _ValueTypeO = iterator_traits<_Out>::value_type;
> constexpr bool __use_memmove
>   = (is_trivially_copyable_v<_ValueTypeI>
>  && is_same_v<_ValueTypeI, _ValueTypeO>
> @@ -386,7 +386,7 @@ namespace ranges
>else if constexpr (sized_sentinel_for<_Sent, _Iter>)
>   {
> using _ValueTypeI = iter_value_t<_Iter>;
> -   using _ValueTypeO = iter_value_t<_Out>;
> +   using _ValueTypeO = iterator_traits<_Out>::value_type;
> constexpr bool __use_memmove
>   = (is_trivially_copyable_v<_ValueTypeI>
>  && is_same_v<_ValueTypeI, _ValueTypeO>
> diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
> b/libstdc++-v3/include/bits/stl_iterator.h
> index 372df223113..0f2742ae4cf 100644
> --- a/libstdc++-v3/include/bits/stl_iterator.h
> +++ b/libstdc++-v3/include/bits/stl_iterator.h
> @@ -496,11 +496,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  : public iterator
>  {
>  protected:
> +#if __cplusplus > 201703L
> +  _Container* container = nullptr;
> +#else
>_Container* container;
> +#endif

Just noticed the order of this conditional is inconsistent with ...

>  
>  public:
>/// A nested typedef for the type of whatever container you used.
>typedef _Container  container_type;
> +#if __cplusplus > 201703L
> +  using difference_type = ptrdiff_t;
> +#endif
> +
> +#if __cplusplus > 201703L
> +  constexpr back_insert_iterator() noexcept = default;
> +#endif
>  
>/// The only way to create this %iterator is with a container.
>explicit
> @@ -588,11 +599,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>  : public iterator
>  {
>  protected:
> +#if __cplusplus <= 201703L
>_Container* container;
> +#else
> +  _Container* container = nullptr;
> +#endif

... this one.  Consider this fixed so that both conditionals are
__cplusplus <= 201703L, specifying the pre-C++20 version of the code
first.

[committed] libstdc++: Add default_sentinel support to stream iterators

Missing pieces of P0896R4 "The One Ranges Proposal" for C++20.

* include/bits/stream_iterator.h (istream_iterator(default_sentinel_t)):
Add constructor.
(operator==(istream_iterator, default_sentinel_t)): Add operator.
(ostream_iterator::difference_type): Define to ptrdiff_t for C++20.
* include/bits/streambuf_iterator.h
(istreambuf_iterator(default_sentinel_t)): Add constructor.
(operator==(istreambuf_iterator, default_sentinel_t)): Add operator.
* testsuite/24_iterators/istream_iterator/cons/sentinel.cc:
New test.
* testsuite/24_iterators/istream_iterator/sentinel.cc: New test.
* testsuite/24_iterators/istreambuf_iterator/cons/sentinel.cc:
New test.
* testsuite/24_iterators/istreambuf_iterator/sentinel.cc: New test.

Tested powerpc64le-linux, committed to master.


commit 120e873484f20d9a0b8400e2e464ac5b2088a747
Author: Jonathan Wakely 
Date:   Mon Feb 24 13:11:31 2020 +

libstdc++: Add default_sentinel support to stream iterators

Missing pieces of P0896R4 "The One Ranges Proposal" for C++20.

* include/bits/stream_iterator.h 
(istream_iterator(default_sentinel_t)):
Add constructor.
(operator==(istream_iterator, default_sentinel_t)): Add operator.
(ostream_iterator::difference_type): Define to ptrdiff_t for C++20.
* include/bits/streambuf_iterator.h
(istreambuf_iterator(default_sentinel_t)): Add constructor.
(operator==(istreambuf_iterator, default_sentinel_t)): Add operator.
* testsuite/24_iterators/istream_iterator/cons/sentinel.cc:
New test.
* testsuite/24_iterators/istream_iterator/sentinel.cc: New test.
* testsuite/24_iterators/istreambuf_iterator/cons/sentinel.cc:
New test.
* testsuite/24_iterators/istreambuf_iterator/sentinel.cc: New test.

diff --git a/libstdc++-v3/include/bits/stream_iterator.h 
b/libstdc++-v3/include/bits/stream_iterator.h
index 345a4d84e25..1ddf647f729 100644
--- a/libstdc++-v3/include/bits/stream_iterator.h
+++ b/libstdc++-v3/include/bits/stream_iterator.h
@@ -77,6 +77,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 _M_ok(__obj._M_ok)
   { }
 
+#if __cplusplus > 201703L
+  constexpr
+  istream_iterator(default_sentinel_t) noexcept
+  : istream_iterator() { }
+#endif
+
 #if __cplusplus >= 201103L
   istream_iterator& operator=(const istream_iterator&) = default;
   ~istream_iterator() = default;
@@ -145,6 +151,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   friend bool
   operator!=(const istream_iterator& __x, const istream_iterator& __y)
   { return !__x._M_equal(__y); }
+
+#if __cplusplus > 201703L
+  friend bool
+  operator==(const istream_iterator& __i, default_sentinel_t)
+  { return !__i._M_stream; }
+#endif
 };
 
   /**
@@ -166,6 +178,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 public:
   //@{
   /// Public typedef
+#if __cplusplus > 201703L
+  using difference_type = ptrdiff_t;
+#endif
   typedef _CharT char_type;
   typedef _Traitstraits_type;
   typedef basic_ostream<_CharT, _Traits> ostream_type;
diff --git a/libstdc++-v3/include/bits/streambuf_iterator.h 
b/libstdc++-v3/include/bits/streambuf_iterator.h
index fe612f39fe9..fc06c50040c 100644
--- a/libstdc++-v3/include/bits/streambuf_iterator.h
+++ b/libstdc++-v3/include/bits/streambuf_iterator.h
@@ -115,6 +115,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _GLIBCXX_CONSTEXPR istreambuf_iterator() _GLIBCXX_USE_NOEXCEPT
   : _M_sbuf(0), _M_c(traits_type::eof()) { }
 
+#if __cplusplus > 201703L
+  constexpr istreambuf_iterator(default_sentinel_t) noexcept
+  : istreambuf_iterator() { }
+#endif
+
 #if __cplusplus >= 201103L
   istreambuf_iterator(const istreambuf_iterator&) noexcept = default;
 
@@ -209,6 +214,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
const int_type __eof = traits_type::eof();
return traits_type::eq_int_type(__c, __eof);
   }
+
+#if __cplusplus > 201703L
+  friend bool
+  operator==(const istreambuf_iterator& __i, default_sentinel_t __s)
+  { return __i._M_at_eof(); }
+#endif
 };
 
   template
diff --git 
a/libstdc++-v3/testsuite/24_iterators/istream_iterator/cons/sentinel.cc 
b/libstdc++-v3/testsuite/24_iterators/istream_iterator/cons/sentinel.cc
new file mode 100644
index 000..77a19498817
--- /dev/null
+++ b/libstdc++-v3/testsuite/24_iterators/istream_iterator/cons/sentinel.cc
@@ -0,0 +1,27 @@
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; eit

Re: [PATCH] libstdc++: Add missing bits of P0896R4 pertaining to [back|front]_insert_iterator


On 24/02/20 08:29 -0500, Patrick Palka wrote:

This adds some missing pieces of the Ranges TS that make back_insert_iterator 
and
front_insert_iterator conform to the new output_iterator requirements.

It also fixes a bug in ranges::__copy_or_move and
ranges::__copy_or_move_backward in which we were inspecting the iter_value_t of
the output iterator, but iterators such as back_insert_iterator and
front_insert_iterator whose value_type is defined to be void do not have an
iter_value_t according to [readable.traits] p4.  The entire __use_memmove
condition can probably be refactored, but the simplest fix for now is to inspect
the iterator_traits of the output iterator instead.

libstdc++-v3/ChangeLog:

PR libstdc++/93884
* include/bits/ranges_algobase.h (__copy_or_move,
__copy_or_move_backward): Don't inspect the iter_value_t of the output
iterator, instead inspect its iterator_traits directly.
* include/bits/stl_iterator.h (back_insert_iterator::container):
Conditionally initialize.
(back_insert_iterator::difference_type): Conditionally define.
(back_insert_iterator::back_insert_iterator): Conditionally define this
default constructor.
(front_insert_iterator::container): Conditionally initialize.
(front_insert_iterator::difference_type): Conditionally define.
(front_insert_iterator::front_insert_iterator): Conditionally define
this default constructor.
---
libstdc++-v3/include/bits/ranges_algobase.h   |  4 +-
libstdc++-v3/include/bits/stl_iterator.h  | 22 ++
.../back_insert_iterator/pr93884.C| 44 +++
.../front_insert_iterator/pr93884.C   | 44 +++
4 files changed, 112 insertions(+), 2 deletions(-)
create mode 100644 
libstdc++-v3/testsuite/24_iterators/back_insert_iterator/pr93884.C
create mode 100644 
libstdc++-v3/testsuite/24_iterators/front_insert_iterator/pr93884.C

diff --git a/libstdc++-v3/include/bits/ranges_algobase.h 
b/libstdc++-v3/include/bits/ranges_algobase.h
index 807822e99c8..739424e1a2d 100644
--- a/libstdc++-v3/include/bits/ranges_algobase.h
+++ b/libstdc++-v3/include/bits/ranges_algobase.h
@@ -249,7 +249,7 @@ namespace ranges
  else if constexpr (sized_sentinel_for<_Sent, _Iter>)
{
  using _ValueTypeI = iter_value_t<_Iter>;
- using _ValueTypeO = iter_value_t<_Out>;
+ using _ValueTypeO = iterator_traits<_Out>::value_type;


I think this will fail to compile with Clang, because it needs
'typename' there.


  constexpr bool __use_memmove
= (is_trivially_copyable_v<_ValueTypeI>
   && is_same_v<_ValueTypeI, _ValueTypeO>
@@ -386,7 +386,7 @@ namespace ranges
  else if constexpr (sized_sentinel_for<_Sent, _Iter>)
{
  using _ValueTypeI = iter_value_t<_Iter>;
- using _ValueTypeO = iter_value_t<_Out>;
+ using _ValueTypeO = iterator_traits<_Out>::value_type;


Same here.

Re: [PATCH] libstdc++: P0769R2 Add shift to


On 21/02/20 16:12 -0500, Patrick Palka wrote:

On Fri, 21 Feb 2020, Patrick Palka wrote:


This patch adds std::shift_left and std::shift_right.  Alhough these are
STL-style algos, they are nonetheless placed in  because
they make use of some functions in the ranges namespace that are more easily
reachable from  than from , namely
ranges::next and ranges::swap_ranges.

This implementation of std::shift_right for non-bidirectional iterators deviates
from the reference implementation a bit.  The main difference is that this
implementation is significantly simpler, and yet saves around n/2 additional
iterator increments and n/2 iter_moves at the cost of around n/2 additional
iter_swaps (where n is the shift amount).


On second thought, this simplification of shift_right is a not a good
idea because the objects that were shifted and that are no longer a part
of the new range do not end up in a moved-from state at the end of the
algorithm.  Here is a version of the patch that instead adds something
akin to the reference implementation and improves the tests to verify
this moved-from property of both algorithms.

-- >8 --

Subject: [PATCH] libstdc++: P0769R2 Add shift to 

This patch adds std::shift_left and std::shift_right as per P0769R2.  Alhough
these are STL-style algos, this patch places them in 
because they make use of some functions in the ranges namespace that are more
easily reachable from  than from , namely
ranges::next.  In order to place these algos in , we would need
to include  from  which would undesirably
increase the size of .

libstdc++-v3/ChangeLog:

P0769R2 Add shift to 
* include/bits/ranges_algo.h (shift_left, shift_right): New.
* testsuite/25_algorithms/shift_left/1.cc: New test.
* testsuite/25_algorithms/shift_right/1.cc: New test.
---
libstdc++-v3/include/bits/ranges_algo.h   |  92 
.../testsuite/25_algorithms/shift_left/1.cc   | 104 ++
.../testsuite/25_algorithms/shift_right/1.cc  | 103 +
3 files changed, 299 insertions(+)
create mode 100644 libstdc++-v3/testsuite/25_algorithms/shift_left/1.cc
create mode 100644 libstdc++-v3/testsuite/25_algorithms/shift_right/1.cc

diff --git a/libstdc++-v3/include/bits/ranges_algo.h 
b/libstdc++-v3/include/bits/ranges_algo.h
index 7de1072abf0..7d7dbf04103 100644
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h


These new algos should go in  because they're not in
namespace ranges.


@@ -3683,6 +3683,98 @@ namespace ranges
  inline constexpr __prev_permutation_fn prev_permutation{};

} // namespace ranges
+
+  template
+constexpr ForwardIterator
+shift_left(ForwardIterator __first, ForwardIterator __last,
+  typename iterator_traits::difference_type __n)
+{
+  __glibcxx_assert(__n >= 0);


If I'm reading the current draft correctly, n < 0 is allowed (and does
nothing) so we shouldn't assert here.



+  if (__n == 0)
+   return __last;
+
+  auto __mid = ranges::next(__first, __n, __last);
+  if (__mid == __last)
+   return __first;
+  return std::move(std::move(__mid), std::move(__last), 
std::move(__first));
+}
+
+  template
+constexpr ForwardIterator
+shift_right(ForwardIterator __first, ForwardIterator __last,
+   typename iterator_traits::difference_type __n)
+{
+  __glibcxx_assert(__n >= 0);


Same here.

Re: [PATCH] libstdc++: Add missing bits of P0896R4 pertaining to [back|front]_insert_iterator

On Mon, 24 Feb 2020, Jonathan Wakely wrote:

> On 24/02/20 08:29 -0500, Patrick Palka wrote:
> > This adds some missing pieces of the Ranges TS that make
> > back_insert_iterator and
> > front_insert_iterator conform to the new output_iterator requirements.
> > 
> > It also fixes a bug in ranges::__copy_or_move and
> > ranges::__copy_or_move_backward in which we were inspecting the iter_value_t
> > of
> > the output iterator, but iterators such as back_insert_iterator and
> > front_insert_iterator whose value_type is defined to be void do not have an
> > iter_value_t according to [readable.traits] p4.  The entire __use_memmove
> > condition can probably be refactored, but the simplest fix for now is to
> > inspect
> > the iterator_traits of the output iterator instead.
> > 
> > libstdc++-v3/ChangeLog:
> > 
> > PR libstdc++/93884
> > * include/bits/ranges_algobase.h (__copy_or_move,
> > __copy_or_move_backward): Don't inspect the iter_value_t of the output
> > iterator, instead inspect its iterator_traits directly.
> > * include/bits/stl_iterator.h (back_insert_iterator::container):
> > Conditionally initialize.
> > (back_insert_iterator::difference_type): Conditionally define.
> > (back_insert_iterator::back_insert_iterator): Conditionally define
> > this
> > default constructor.
> > (front_insert_iterator::container): Conditionally initialize.
> > (front_insert_iterator::difference_type): Conditionally define.
> > (front_insert_iterator::front_insert_iterator): Conditionally define
> > this default constructor.
> > ---
> > libstdc++-v3/include/bits/ranges_algobase.h   |  4 +-
> > libstdc++-v3/include/bits/stl_iterator.h  | 22 ++
> > .../back_insert_iterator/pr93884.C| 44 +++
> > .../front_insert_iterator/pr93884.C   | 44 +++
> > 4 files changed, 112 insertions(+), 2 deletions(-)
> > create mode 100644
> > libstdc++-v3/testsuite/24_iterators/back_insert_iterator/pr93884.C
> > create mode 100644
> > libstdc++-v3/testsuite/24_iterators/front_insert_iterator/pr93884.C
> > 
> > diff --git a/libstdc++-v3/include/bits/ranges_algobase.h
> > b/libstdc++-v3/include/bits/ranges_algobase.h
> > index 807822e99c8..739424e1a2d 100644
> > --- a/libstdc++-v3/include/bits/ranges_algobase.h
> > +++ b/libstdc++-v3/include/bits/ranges_algobase.h
> > @@ -249,7 +249,7 @@ namespace ranges
> >   else if constexpr (sized_sentinel_for<_Sent, _Iter>)
> > {
> >   using _ValueTypeI = iter_value_t<_Iter>;
> > - using _ValueTypeO = iter_value_t<_Out>;
> > + using _ValueTypeO = iterator_traits<_Out>::value_type;
> 
> I think this will fail to compile with Clang, because it needs
> 'typename' there.
> 
> >   constexpr bool __use_memmove
> > = (is_trivially_copyable_v<_ValueTypeI>
> >&& is_same_v<_ValueTypeI, _ValueTypeO>
> > @@ -386,7 +386,7 @@ namespace ranges
> >   else if constexpr (sized_sentinel_for<_Sent, _Iter>)
> > {
> >   using _ValueTypeI = iter_value_t<_Iter>;
> > - using _ValueTypeO = iter_value_t<_Out>;
> > + using _ValueTypeO = iterator_traits<_Out>::value_type;
> 
> Same here.

Ah right... Here's v2 of the patch that adds typename to those two
aliases and fixes the file extensions on the tests.

-- >8 --

libstdc++-v3/ChangeLog:

PR libstdc++/93884
* include/bits/ranges_algobase.h (__copy_or_move,
__copy_or_move_backward): Don't inspect the iter_value_t of the output
iterator, instead inspect its iterator_traits directly.
* include/bits/stl_iterator.h (back_insert_iterator::container):
Conditionally initialize.
(back_insert_iterator::difference_type): Conditionally define.
(back_insert_iterator::back_insert_iterator): Conditionally define this
default constructor.
(front_insert_iterator::container): Conditionally initialize.
(front_insert_iterator::difference_type): Conditionally define.
(front_insert_iterator::front_insert_iterator): Conditionally define
this default constructor.
* 24_iterators/back_insert_iterator/pr93884.cc: New test.
* 24_iterators/front_insert_iterator/pr93884.cc: New test.
---
 libstdc++-v3/include/bits/ranges_algobase.h   |  4 +-
 libstdc++-v3/include/bits/stl_iterator.h  | 22 ++
 .../back_insert_iterator/pr93884.cc   | 44 +++
 .../front_insert_iterator/pr93884.cc  | 44 +++
 4 files changed, 112 insertions(+), 2 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/24_iterators/back_insert_iterator/pr93884.cc
 create mode 100644 
libstdc++-v3/testsuite/24_iterators/front_insert_iterator/pr93884.cc

diff --git a/libstdc++-v3/include/bits/ranges_algobase.h 
b/libstdc++-v3/include/bits/ranges_algobase.h
index 807822e99c8..73f0205ba7f 100644
--- a/libstdc++-v3/include/bits/ranges_algobase.h
+++ b/libstdc++-v3/include/bits/ranges_algobase.h
@@ -249,

[committed] c++: Fix C++20 variadic lambda init-capture grammar.

The grammar for variadic init-capture was fixed at the Prague C++ meeting
where we finalized C++20.

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

gcc/cp/ChangeLog
2020-02-24  Jason Merrill  

P0780R2: Resolve lambda init-capture pack grammar.
* parser.c (cp_parser_lambda_introducer): Expect &...x=y rather than
...&x=y.
---
 gcc/cp/parser.c| 15 +--
 gcc/testsuite/g++.dg/cpp2a/lambda-pack-init4.C | 10 ++
 2 files changed, 23 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-pack-init4.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ee534b5db21..87ed2a3a648 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -10620,6 +10620,7 @@ cp_parser_lambda_introducer (cp_parser* parser, tree 
lambda_expr)
 
   /* Record default capture mode.  "[&" "[=" "[&," "[=,"  */
   if (cp_lexer_next_token_is (parser->lexer, CPP_AND)
+  && !cp_lexer_nth_token_is (parser->lexer, 2, CPP_ELLIPSIS)
   && !cp_lexer_nth_token_is (parser->lexer, 2, CPP_NAME)
   && !cp_lexer_nth_token_is_keyword (parser->lexer, 2, RID_THIS))
 LAMBDA_EXPR_DEFAULT_CAPTURE_MODE (lambda_expr) = CPLD_REFERENCE;
@@ -10715,6 +10716,13 @@ cp_parser_lambda_introducer (cp_parser* parser, tree 
lambda_expr)
  continue;
}
 
+  /* Remember whether we want to capture as a reference or not.  */
+  if (cp_lexer_next_token_is (parser->lexer, CPP_AND))
+   {
+ capture_kind = BY_REFERENCE;
+ cp_lexer_consume_token (parser->lexer);
+   }
+
   bool init_pack_expansion = false;
   location_t ellipsis_loc = UNKNOWN_LOCATION;
   if (cp_lexer_next_token_is (parser->lexer, CPP_ELLIPSIS))
@@ -10727,9 +10735,12 @@ cp_parser_lambda_introducer (cp_parser* parser, tree 
lambda_expr)
  init_pack_expansion = true;
}
 
-  /* Remember whether we want to capture as a reference or not.  */
-  if (cp_lexer_next_token_is (parser->lexer, CPP_AND))
+  /* Early C++20 drafts had ...& instead of &...; be forgiving.  */
+  if (init_pack_expansion && capture_kind != BY_REFERENCE
+ && cp_lexer_next_token_is (parser->lexer, CPP_AND))
{
+ pedwarn (cp_lexer_peek_token (parser->lexer)->location,
+  0, "%<&%> should come before %<...%>");
  capture_kind = BY_REFERENCE;
  cp_lexer_consume_token (parser->lexer);
}
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-pack-init4.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-pack-init4.C
new file mode 100644
index 000..e7c815b92d4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-pack-init4.C
@@ -0,0 +1,10 @@
+// P2095R0
+// { dg-do compile { target c++2a } }
+// { dg-options "" }
+
+template 
+void f(T... t)
+{
+  [&...x=t]{};
+  [...&x=t]{}; // { dg-warning "7:&" }
+}

base-commit: f1a681a174cdfb82e62c246d6f4add9a25fc2e43
-- 
2.18.1

[PATCH] c++: P1937R2 - Fixing inconsistencies between const{expr,eval} functions

2020-02-24 Thread Jakub Jelinek

Hi!

The following patch implements my understanding of P1937R2, though I wonder
if https://eel.is/c++draft/expr.const#14.example-1 shouldn't have been
also either removed or adjusted by the P1937R2 paper.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-02-24  Jakub Jelinek  

P1937R2 - Fixing inconsistencies between const{expr,eval} functions
* call.c (build_over_call): Don't evaluate immediate functions in
unevaluated operands.

* g++.dg/ext/consteval1.C: Change dg-{message,error} into dg-bogus.
* g++.dg/cpp2a/consteval6.C: Likewise.
* g++.dg/cpp2a/consteval3.C: Change dg-error for unevaluated operands
into dg-bogus.

--- gcc/cp/call.c.jj2020-02-08 10:58:28.439866081 +0100
+++ gcc/cp/call.c   2020-02-15 22:18:20.311789273 +0100
@@ -8424,6 +8424,7 @@ build_over_call (struct z_candidate *can
current_function_returns_abnormally = 1;
   if (TREE_CODE (fn) == FUNCTION_DECL
  && DECL_IMMEDIATE_FUNCTION_P (fn)
+ && cp_unevaluated_operand == 0
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
  && (current_binding_level->kind != sk_function_parms
@@ -9060,6 +9061,7 @@ build_over_call (struct z_candidate *can
   tree fndecl = STRIP_TEMPLATE (TREE_OPERAND (fn, 0));
   if (TREE_CODE (fndecl) == FUNCTION_DECL
  && DECL_IMMEDIATE_FUNCTION_P (fndecl)
+ && cp_unevaluated_operand == 0
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
  && (current_binding_level->kind != sk_function_parms
--- gcc/testsuite/g++.dg/ext/consteval1.C.jj2020-01-12 11:54:37.166402048 
+0100
+++ gcc/testsuite/g++.dg/ext/consteval1.C   2020-02-15 22:33:12.690505111 
+0100
@@ -2,5 +2,5 @@
 // { dg-options "-std=c++2a" }
 
 consteval int foo (int x) { return x; }
-int d = 6; // { dg-message "'int d' is not const" }
-bool e = __builtin_has_attribute (foo (d), packed);// { dg-error "the 
value of 'd' is not usable in a constant expression" }
+int d = 6; // { dg-bogus "'int d' is not const" }
+bool e = __builtin_has_attribute (foo (d), packed);// { dg-bogus "the 
value of 'd' is not usable in a constant expression" }
--- gcc/testsuite/g++.dg/cpp2a/consteval3.C.jj  2020-01-12 11:54:37.140402440 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval3.C 2020-02-15 22:22:50.618765423 
+0100
@@ -33,9 +33,9 @@ struct V { consteval int v = 5; };// {
 struct W { consteval static int w; };  // { dg-error "static data member 'w' 
declared 'consteval'" }
 int i = sizeof (&f6);  // { dg-error "taking address of an 
immediate function 'consteval int f6\\(int\\)'" }
 using j = decltype (&f6);  // { dg-error "taking address of an 
immediate function 'consteval int f6\\(int\\)'" }
-int k = sizeof (f6 (d));   // { dg-error "the value of 'd' is not 
usable in a constant expression" }
-using l = decltype (f6 (d));   // { dg-error "the value of 'd' is not 
usable in a constant expression" }
-bool m = noexcept (f6 (d));// { dg-error "the value of 'd' is not 
usable in a constant expression" }
+int k = sizeof (f6 (d));   // { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
+using l = decltype (f6 (d));   // { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
+bool m = noexcept (f6 (d));// { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
 namespace std {
 using size_t = decltype (sizeof (0));
 }
--- gcc/testsuite/g++.dg/cpp2a/consteval6.C.jj  2020-01-12 11:54:37.140402440 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval6.C 2020-02-15 22:32:11.140421368 
+0100
@@ -3,7 +3,7 @@
 
 struct A {
   constexpr A () {}
-  A (A const&) = delete;   // { dg-message "declared here" }
+  A (A const&) = delete;   // { dg-bogus "declared here" }
 };
 
 template
@@ -19,8 +19,8 @@ consteval void
 bar ()
 {
   T t;
-  T u = t; // { dg-error "use of deleted function" }
+  T u = t; // { dg-bogus "use of deleted function" }
 }
 
 using B = decltype (foo ());
-using C = decltype (bar ());// { dg-message "required from here" }
+using C = decltype (bar ());// { dg-bogus "required from here" }

Jakub

Re: [PATCH] libstdc++: P0769R2 Add shift to

On Mon, 24 Feb 2020, Jonathan Wakely wrote:

> On 21/02/20 16:12 -0500, Patrick Palka wrote:
> > On Fri, 21 Feb 2020, Patrick Palka wrote:
> > 
> > > This patch adds std::shift_left and std::shift_right.  Alhough these are
> > > STL-style algos, they are nonetheless placed in 
> > > because
> > > they make use of some functions in the ranges namespace that are more
> > > easily
> > > reachable from  than from , namely
> > > ranges::next and ranges::swap_ranges.
> > > 
> > > This implementation of std::shift_right for non-bidirectional iterators
> > > deviates
> > > from the reference implementation a bit.  The main difference is that this
> > > implementation is significantly simpler, and yet saves around n/2
> > > additional
> > > iterator increments and n/2 iter_moves at the cost of around n/2
> > > additional
> > > iter_swaps (where n is the shift amount).
> > 
> > On second thought, this simplification of shift_right is a not a good
> > idea because the objects that were shifted and that are no longer a part
> > of the new range do not end up in a moved-from state at the end of the
> > algorithm.  Here is a version of the patch that instead adds something
> > akin to the reference implementation and improves the tests to verify
> > this moved-from property of both algorithms.
> > 
> > -- >8 --
> > 
> > Subject: [PATCH] libstdc++: P0769R2 Add shift to 
> > 
> > This patch adds std::shift_left and std::shift_right as per P0769R2.
> > Alhough
> > these are STL-style algos, this patch places them in 
> > because they make use of some functions in the ranges namespace that are
> > more
> > easily reachable from  than from ,
> > namely
> > ranges::next.  In order to place these algos in , we would
> > need
> > to include  from  which would
> > undesirably
> > increase the size of .
> > 
> > libstdc++-v3/ChangeLog:
> > 
> > P0769R2 Add shift to 
> > * include/bits/ranges_algo.h (shift_left, shift_right): New.
> > * testsuite/25_algorithms/shift_left/1.cc: New test.
> > * testsuite/25_algorithms/shift_right/1.cc: New test.
> > ---
> > libstdc++-v3/include/bits/ranges_algo.h   |  92 
> > .../testsuite/25_algorithms/shift_left/1.cc   | 104 ++
> > .../testsuite/25_algorithms/shift_right/1.cc  | 103 +
> > 3 files changed, 299 insertions(+)
> > create mode 100644 libstdc++-v3/testsuite/25_algorithms/shift_left/1.cc
> > create mode 100644 libstdc++-v3/testsuite/25_algorithms/shift_right/1.cc
> > 
> > diff --git a/libstdc++-v3/include/bits/ranges_algo.h
> > b/libstdc++-v3/include/bits/ranges_algo.h
> > index 7de1072abf0..7d7dbf04103 100644
> > --- a/libstdc++-v3/include/bits/ranges_algo.h
> > +++ b/libstdc++-v3/include/bits/ranges_algo.h
> 
> These new algos should go in  because they're not in
> namespace ranges.

Since their implementation uses ranges::next(__it, __n, __last), putting
them in  means we would need to include
 from , or reimplement the
ranges::next() routine in  (and its random access
iterator optimization) it seems.

> 
> > @@ -3683,6 +3683,98 @@ namespace ranges
> >   inline constexpr __prev_permutation_fn prev_permutation{};
> > 
> > } // namespace ranges
> > +
> > +  template
> > +constexpr ForwardIterator
> > +shift_left(ForwardIterator __first, ForwardIterator __last,
> > +  typename iterator_traits::difference_type __n)
> > +{
> > +  __glibcxx_assert(__n >= 0);
> 
> If I'm reading the current draft correctly, n < 0 is allowed (and does
> nothing) so we shouldn't assert here.

From what I can tell, this is changed by P1243R4 (Rangify new
algorithms) which adds the precondition n >= 0 to these routines.

> 
> 
> > +  if (__n == 0)
> > +   return __last;
> > +
> > +  auto __mid = ranges::next(__first, __n, __last);
> > +  if (__mid == __last)
> > +   return __first;
> > +  return std::move(std::move(__mid), std::move(__last),
> > std::move(__first));
> > +}
> > +
> > +  template
> > +constexpr ForwardIterator
> > +shift_right(ForwardIterator __first, ForwardIterator __last,
> > +   typename iterator_traits::difference_type
> > __n)
> > +{
> > +  __glibcxx_assert(__n >= 0);
> 
> Same here.

Re: [PATCH] c++: P1937R2 - Fixing inconsistencies between const{expr,eval} functions


On 2/24/20 9:06 AM, Jakub Jelinek wrote:

Hi!

The following patch implements my understanding of P1937R2, though I wonder
if https://eel.is/c++draft/expr.const#14.example-1 shouldn't have been
also either removed or adjusted by the P1937R2 paper.


Ah, good catch.


Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


OK.


2020-02-24  Jakub Jelinek  

P1937R2 - Fixing inconsistencies between const{expr,eval} functions
* call.c (build_over_call): Don't evaluate immediate functions in
unevaluated operands.

* g++.dg/ext/consteval1.C: Change dg-{message,error} into dg-bogus.
* g++.dg/cpp2a/consteval6.C: Likewise.
* g++.dg/cpp2a/consteval3.C: Change dg-error for unevaluated operands
into dg-bogus.

--- gcc/cp/call.c.jj2020-02-08 10:58:28.439866081 +0100
+++ gcc/cp/call.c   2020-02-15 22:18:20.311789273 +0100
@@ -8424,6 +8424,7 @@ build_over_call (struct z_candidate *can
current_function_returns_abnormally = 1;
if (TREE_CODE (fn) == FUNCTION_DECL
  && DECL_IMMEDIATE_FUNCTION_P (fn)
+ && cp_unevaluated_operand == 0
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
  && (current_binding_level->kind != sk_function_parms
@@ -9060,6 +9061,7 @@ build_over_call (struct z_candidate *can
tree fndecl = STRIP_TEMPLATE (TREE_OPERAND (fn, 0));
if (TREE_CODE (fndecl) == FUNCTION_DECL
  && DECL_IMMEDIATE_FUNCTION_P (fndecl)
+ && cp_unevaluated_operand == 0
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
  && (current_binding_level->kind != sk_function_parms
--- gcc/testsuite/g++.dg/ext/consteval1.C.jj2020-01-12 11:54:37.166402048 
+0100
+++ gcc/testsuite/g++.dg/ext/consteval1.C   2020-02-15 22:33:12.690505111 
+0100
@@ -2,5 +2,5 @@
  // { dg-options "-std=c++2a" }
  
  consteval int foo (int x) { return x; }

-int d = 6; // { dg-message "'int d' is not const" }
-bool e = __builtin_has_attribute (foo (d), packed);// { dg-error "the value of 
'd' is not usable in a constant expression" }
+int d = 6; // { dg-bogus "'int d' is not const" }
+bool e = __builtin_has_attribute (foo (d), packed);// { dg-bogus "the value of 
'd' is not usable in a constant expression" }
--- gcc/testsuite/g++.dg/cpp2a/consteval3.C.jj  2020-01-12 11:54:37.140402440 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval3.C 2020-02-15 22:22:50.618765423 
+0100
@@ -33,9 +33,9 @@ struct V { consteval int v = 5; };// {
  struct W { consteval static int w; }; // { dg-error "static data member 'w' 
declared 'consteval'" }
  int i = sizeof (&f6); // { dg-error "taking address of an 
immediate function 'consteval int f6\\(int\\)'" }
  using j = decltype (&f6); // { dg-error "taking address of an immediate 
function 'consteval int f6\\(int\\)'" }
-int k = sizeof (f6 (d));   // { dg-error "the value of 'd' is not 
usable in a constant expression" }
-using l = decltype (f6 (d));   // { dg-error "the value of 'd' is not 
usable in a constant expression" }
-bool m = noexcept (f6 (d));// { dg-error "the value of 'd' is not 
usable in a constant expression" }
+int k = sizeof (f6 (d));   // { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
+using l = decltype (f6 (d));   // { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
+bool m = noexcept (f6 (d));// { dg-bogus "the value of 'd' is not 
usable in a constant expression" }
  namespace std {
  using size_t = decltype (sizeof (0));
  }
--- gcc/testsuite/g++.dg/cpp2a/consteval6.C.jj  2020-01-12 11:54:37.140402440 
+0100
+++ gcc/testsuite/g++.dg/cpp2a/consteval6.C 2020-02-15 22:32:11.140421368 
+0100
@@ -3,7 +3,7 @@
  
  struct A {

constexpr A () {}
-  A (A const&) = delete;   // { dg-message "declared here" }
+  A (A const&) = delete;   // { dg-bogus "declared here" }
  };
  
  template

@@ -19,8 +19,8 @@ consteval void
  bar ()
  {
T t;
-  T u = t; // { dg-error "use of deleted function" }
+  T u = t; // { dg-bogus "use of deleted function" }
  }
  
  using B = decltype (foo ());

-using C = decltype (bar ());  // { dg-message "required from here" }
+using C = decltype (bar ());  // { dg-bogus "required from here" }

Jakub

Re: [PATCH] libstdc++: P0769R2 Add shift to

2020-02-24 Thread Daniel Krügler

Am Mo., 24. Feb. 2020 um 15:12 Uhr schrieb Patrick Palka :
>
> On Mon, 24 Feb 2020, Jonathan Wakely wrote:
>
[...]
> > > @@ -3683,6 +3683,98 @@ namespace ranges
> > >   inline constexpr __prev_permutation_fn prev_permutation{};
> > >
> > > } // namespace ranges
> > > +
> > > +  template
> > > +constexpr ForwardIterator
> > > +shift_left(ForwardIterator __first, ForwardIterator __last,
> > > +  typename iterator_traits::difference_type __n)
> > > +{
> > > +  __glibcxx_assert(__n >= 0);
> >
> > If I'm reading the current draft correctly, n < 0 is allowed (and does
> > nothing) so we shouldn't assert here.
>
> From what I can tell, this is changed by P1243R4 (Rangify new
> algorithms) which adds the precondition n >= 0 to these routines.

Yes, that's correct. This part of the wording applied the accepted
changes of p1233r1.

- Daniel

Re: [ARM] Fix -mpure-code for v6m

Ping?

I'd also like to backport this and the main patch (svn r279463,
r10-5505-ge24f6408df1e4c5e8c09785d7b488c492dfb68b3)
to the gcc-9 branch.

I found the problem addressed by this patch while validating the
backport to gcc-9: although the patch applies cleanly except for
testcases dg directives, there were some failures which I could
finally reproduce on trunk with -fdisable-rtl-fwprop2.

Here is a summary of the validations I ran using --target arm-eabi:
* without my patches:
(1) --with-cpu cortex-m0
(2) --with-cpu cortex-m4
(3) --with-cpu cortex-m4 CFLAGS_FOR_TARGET=-mpure-code (to build the
libs with -mpure-code)
(4) --with-cpu cortex-m4 CFLAGS_FOR_TARGET=-mpure-code
--target-board=-mpure-code (to also run the tests with -mpure-code)

* with my patches:
(5) --with-cpu cortex-m0 CFLAGS_FOR_TARGET=-mpure-code
--target-board=-mpure-code
(6) --with-cpu cortex-m4 CFLAGS_FOR_TARGET=-mpure-code
--target-board=-mpure-code

Comparing (4) and (6) ensured that my (v6m) patches introduce no
regression in v7m cases.

Comparison of (1) vs (5) gave results similar to (2) vs (6), there's a
bit of noise because some tests cases don't cope well with -mpure-code
despite my previous testsuite-only patch (svn r277828)

Comparison of (1) vs (2) gave similar results to (5) vs (6).

Ideally, we may also want to backport svn r277828 (testsuite-only
patch, to handle -mpure-code better), but that's not mandatory.

In summary, is this patch OK for trunk?

Are this patch and r279463,
r10-5505-ge24f6408df1e4c5e8c09785d7b488c492dfb68b3 OK to backport to
gcc-9?

Thanks,

Christophe

On Thu, 13 Feb 2020 at 11:14, Christophe Lyon
 wrote:
>
> On Mon, 10 Feb 2020 at 17:45, Richard Earnshaw (lists)
>  wrote:
> >
> > On 10/02/2020 09:27, Christophe Lyon wrote:
> > > On Fri, 7 Feb 2020 at 17:55, Richard Earnshaw (lists)
> > >  wrote:
> > >>
> > >> On 07/02/2020 16:43, Christophe Lyon wrote:
> > >>> On Fri, 7 Feb 2020 at 14:49, Richard Earnshaw (lists)
> > >>>  wrote:
> > 
> >  On 07/02/2020 13:19, Christophe Lyon wrote:
> > > When running the testsuite with -fdisable-rtl-fwprop2 and -mpure-code
> > > for cortex-m0, I noticed that some testcases were failing because we
> > > still generate "ldr rX, .LCY", which is what we want to avoid with
> > > -mpure-code. This is latent since a recent improvement in fwprop
> > > (PR88833).
> > >
> > > In this patch I change the thumb1_movsi_insn pattern so that it emits
> > > the desired instruction sequence when arm_disable_literal_pool is set.
> > >
> > > I tried to add a define_split instead, but couldn't make it work: the
> > > compiler then complains it cannot split the instruction, while my new
> > > define_split accepts the same operand types as thumb1_movsi_insn:
> > >
> > > c-c++-common/torture/complex-sign-mixed-add.c:41:1: error: could not 
> > > split insn
> > > (insn 2989 425 4844 (set (reg/f:SI 3 r3 [1342])
> > >(symbol_ref/u:SI ("*.LC6") [flags 0x2])) 836 
> > > {*thumb1_movsi_insn}
> > > (expr_list:REG_EQUIV (symbol_ref/u:SI ("*.LC6") [flags 0x2])
> > >(nil)))
> > > during RTL pass: final
> > >
> > > (define_split
> > >  [(set (match_operand:SI 0 "register_operand" "")
> > >(match_operand:SI 1 "general_operand" ""))]
> > >  "TARGET_THUMB1
> > >   && arm_disable_literal_pool
> > >   && GET_CODE (operands[1]) == SYMBOL_REF"
> > >  [(clobber (const_int 0))]
> > >  "
> > >gen_thumb1_movsi_symbol_ref(operands[0], operands[1]);
> > >DONE;
> > >  "
> > > )
> > > and I put this in thumb1_movsi_insn:
> > > if (GET_CODE (operands[1]) == SYMBOL_REF && arm_disable_literal_pool)
> > >  {
> > >return \"#\";
> > >  }
> > >  return \"ldr\\t%0, %1\";
> > >
> > > 2020-02-07  Christophe Lyon  
> > >
> > >* config/arm/thumb1.md (thumb1_movsi_insn): Fix ldr 
> > > alternative to
> > >work with -mpure-code.
> > >
> > 
> >  +case 0:
> >  +case 1:
> >  +  return \"movs%0, %1\";
> >  +case 2:
> >  +  return \"movw%0, %1\";
> > 
> >  This is OK, but please replace the hard tab in the strings for 
> >  MOVS/MOVW
> >  with \\t.
> > 
> > >>>
> > >>> OK that was merely a cut & paste from the existing code.
> > >>>
> > >>> I'm concerned that the length attribute is becoming wrong with my
> > >>> patch, isn't this a problem?
> > >>>
> > >>
> > >> Potentially yes.  The branch range code needs this to handle overly long
> > >> jumps correctly.
> > >>
> > >
> > > Do you mean that the probability of problems due to that shortcoming
> > > is low enough that I can commit my patch?
> >
> > It's hard to say that.  The number of instructions you generate for this
> > is significant, so it likely will throw off the calculations and
> >

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484


**ping**

The following was a reply to 
https://gcc.gnu.org/ml/fortran/2020-02/msg00042.html


see response below. OK to commit?
On 11/02/2020 15:23, Steve Kargl wrote:

On Tue, Feb 11, 2020 at 12:10:41PM +, Mark Eggleston wrote:

Please find attached a patch for PR93484.  The original author is Steve
Kargl. I have added the test cases.

OK for master?

I obviously think the patch is ok, but I'll let someone else review it.


     Steven G. Kargl  

     PR fortran/93484
     * match.c (gfc_match_type_spec): Replace gfc_match_init_expr with
     gfc_match_expr. Return m if m is MATCH_NO or MATCH_ERROR.

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index a74cb8c5c19..03adfca9bd9 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -,9 +,9 @@ gfc_match_type_spec (gfc_typespec *ts)
  
  found:
  
-  m = gfc_match_init_expr (&e);

+  m = gfc_match_expr (&e);
if (m == MATCH_NO || m == MATCH_ERROR)
-   return MATCH_NO;
+   return m;

Might need

 gfc_reduce_init_expr (e);

here.  The kind type parameter should be a constant expression.


Not needed. I've also checked use of the kind argument, it is evidently 
checked elsewhere: if k is allowed to be implicitly declared and is used 
as the kind argument errors are reported that it is not a constant, if 
implicit declaration is not allowed a "has no IMPLICIT type" error is 
produced.





/* If a comma appears, it is an intrinsic subprogram. */
gfc_gobble_whitespace ();


--
https://www.codethink.co.uk/privacy.html

Re: [committed] libstdc++: Add default_sentinel support to stream iterators


On 24/02/20 13:40 +, Jonathan Wakely wrote:

Missing pieces of P0896R4 "The One Ranges Proposal" for C++20.

* include/bits/stream_iterator.h (istream_iterator(default_sentinel_t)):
Add constructor.
(operator==(istream_iterator, default_sentinel_t)): Add operator.
(ostream_iterator::difference_type): Define to ptrdiff_t for C++20.
* include/bits/streambuf_iterator.h
(istreambuf_iterator(default_sentinel_t)): Add constructor.
(operator==(istreambuf_iterator, default_sentinel_t)): Add operator.
* testsuite/24_iterators/istream_iterator/cons/sentinel.cc:
New test.
* testsuite/24_iterators/istream_iterator/sentinel.cc: New test.
* testsuite/24_iterators/istreambuf_iterator/cons/sentinel.cc:
New test.
* testsuite/24_iterators/istreambuf_iterator/sentinel.cc: New test.


This fixes a dumb mistake in that commit.

Tested powerpc64le-linux, committed to master.


commit 8566286eaeb9a977339df88212826150767f1203
Author: Jonathan Wakely 
Date:   Mon Feb 24 14:22:21 2020 +

libstdc++: Fix noexcept-specifier for istream_iterator

Somehow I missed that the _M_value member can throw on construction.

* include/bits/stream_iterator.h (istream_iterator(default_sentinel_t)):
Make noexcept-specifier conditional.
* testsuite/24_iterators/istream_iterator/cons/sentinel.cc: Check
noexcept-specifier.

diff --git a/libstdc++-v3/include/bits/stream_iterator.h b/libstdc++-v3/include/bits/stream_iterator.h
index 1ddf647f729..9d8ead092b8 100644
--- a/libstdc++-v3/include/bits/stream_iterator.h
+++ b/libstdc++-v3/include/bits/stream_iterator.h
@@ -79,7 +79,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #if __cplusplus > 201703L
   constexpr
-  istream_iterator(default_sentinel_t) noexcept
+  istream_iterator(default_sentinel_t)
+  noexcept(is_nothrow_default_constructible_v<_Tp>)
   : istream_iterator() { }
 #endif
 
diff --git a/libstdc++-v3/testsuite/24_iterators/istream_iterator/cons/sentinel.cc b/libstdc++-v3/testsuite/24_iterators/istream_iterator/cons/sentinel.cc
index 77a19498817..b890f04f8e9 100644
--- a/libstdc++-v3/testsuite/24_iterators/istream_iterator/cons/sentinel.cc
+++ b/libstdc++-v3/testsuite/24_iterators/istream_iterator/cons/sentinel.cc
@@ -19,9 +19,18 @@
 // .
 
 #include 
+#include 
 
 // C++20 doesn't require this to be non-throwing.
 static_assert( std::is_nothrow_constructible_v,
 	   std::default_sentinel_t> );
 
 constexpr std::istream_iterator i = std::default_sentinel;
+
+struct X { X() noexcept(false); };
+std::istream& operator<<(std::istream&, X&);
+
+static_assert( std::is_constructible_v,
+   std::default_sentinel_t> );
+static_assert( ! std::is_nothrow_constructible_v,
+		 std::default_sentinel_t> );

Re: [PATCH] libstdc++: Add missing bits of P0896R4 pertaining to [back|front]_insert_iterator


On 24/02/20 08:53 -0500, Patrick Palka wrote:

On Mon, 24 Feb 2020, Jonathan Wakely wrote:


On 24/02/20 08:29 -0500, Patrick Palka wrote:
> This adds some missing pieces of the Ranges TS that make
> back_insert_iterator and
> front_insert_iterator conform to the new output_iterator requirements.
>
> It also fixes a bug in ranges::__copy_or_move and
> ranges::__copy_or_move_backward in which we were inspecting the iter_value_t
> of
> the output iterator, but iterators such as back_insert_iterator and
> front_insert_iterator whose value_type is defined to be void do not have an
> iter_value_t according to [readable.traits] p4.  The entire __use_memmove
> condition can probably be refactored, but the simplest fix for now is to
> inspect
> the iterator_traits of the output iterator instead.
>
> libstdc++-v3/ChangeLog:
>
>PR libstdc++/93884
>* include/bits/ranges_algobase.h (__copy_or_move,
>__copy_or_move_backward): Don't inspect the iter_value_t of the output
>iterator, instead inspect its iterator_traits directly.
>* include/bits/stl_iterator.h (back_insert_iterator::container):
>Conditionally initialize.
>(back_insert_iterator::difference_type): Conditionally define.
>(back_insert_iterator::back_insert_iterator): Conditionally define
> this
>default constructor.
>(front_insert_iterator::container): Conditionally initialize.
>(front_insert_iterator::difference_type): Conditionally define.
>(front_insert_iterator::front_insert_iterator): Conditionally define
>this default constructor.
> ---
> libstdc++-v3/include/bits/ranges_algobase.h   |  4 +-
> libstdc++-v3/include/bits/stl_iterator.h  | 22 ++
> .../back_insert_iterator/pr93884.C| 44 +++
> .../front_insert_iterator/pr93884.C   | 44 +++
> 4 files changed, 112 insertions(+), 2 deletions(-)
> create mode 100644
> libstdc++-v3/testsuite/24_iterators/back_insert_iterator/pr93884.C
> create mode 100644
> libstdc++-v3/testsuite/24_iterators/front_insert_iterator/pr93884.C
>
> diff --git a/libstdc++-v3/include/bits/ranges_algobase.h
> b/libstdc++-v3/include/bits/ranges_algobase.h
> index 807822e99c8..739424e1a2d 100644
> --- a/libstdc++-v3/include/bits/ranges_algobase.h
> +++ b/libstdc++-v3/include/bits/ranges_algobase.h
> @@ -249,7 +249,7 @@ namespace ranges
>   else if constexpr (sized_sentinel_for<_Sent, _Iter>)
>{
>  using _ValueTypeI = iter_value_t<_Iter>;
> -using _ValueTypeO = iter_value_t<_Out>;
> +using _ValueTypeO = iterator_traits<_Out>::value_type;

I think this will fail to compile with Clang, because it needs
'typename' there.

>  constexpr bool __use_memmove
>= (is_trivially_copyable_v<_ValueTypeI>
>   && is_same_v<_ValueTypeI, _ValueTypeO>
> @@ -386,7 +386,7 @@ namespace ranges
>   else if constexpr (sized_sentinel_for<_Sent, _Iter>)
>{
>  using _ValueTypeI = iter_value_t<_Iter>;
> -using _ValueTypeO = iter_value_t<_Out>;
> +using _ValueTypeO = iterator_traits<_Out>::value_type;

Same here.


Ah right... Here's v2 of the patch that adds typename to those two
aliases and fixes the file extensions on the tests.


OK for master, thanks.

Re: [PATCH] libstdc++: P0769R2 Add shift to


On 24/02/20 09:12 -0500, Patrick Palka wrote:

On Mon, 24 Feb 2020, Jonathan Wakely wrote:


On 21/02/20 16:12 -0500, Patrick Palka wrote:
> On Fri, 21 Feb 2020, Patrick Palka wrote:
>
> > This patch adds std::shift_left and std::shift_right.  Alhough these are
> > STL-style algos, they are nonetheless placed in 
> > because
> > they make use of some functions in the ranges namespace that are more
> > easily
> > reachable from  than from , namely
> > ranges::next and ranges::swap_ranges.
> >
> > This implementation of std::shift_right for non-bidirectional iterators
> > deviates
> > from the reference implementation a bit.  The main difference is that this
> > implementation is significantly simpler, and yet saves around n/2
> > additional
> > iterator increments and n/2 iter_moves at the cost of around n/2
> > additional
> > iter_swaps (where n is the shift amount).
>
> On second thought, this simplification of shift_right is a not a good
> idea because the objects that were shifted and that are no longer a part
> of the new range do not end up in a moved-from state at the end of the
> algorithm.  Here is a version of the patch that instead adds something
> akin to the reference implementation and improves the tests to verify
> this moved-from property of both algorithms.
>
> -- >8 --
>
> Subject: [PATCH] libstdc++: P0769R2 Add shift to 
>
> This patch adds std::shift_left and std::shift_right as per P0769R2.
> Alhough
> these are STL-style algos, this patch places them in 
> because they make use of some functions in the ranges namespace that are
> more
> easily reachable from  than from ,
> namely
> ranges::next.  In order to place these algos in , we would
> need
> to include  from  which would
> undesirably
> increase the size of .
>
> libstdc++-v3/ChangeLog:
>
>P0769R2 Add shift to 
>* include/bits/ranges_algo.h (shift_left, shift_right): New.
>* testsuite/25_algorithms/shift_left/1.cc: New test.
>* testsuite/25_algorithms/shift_right/1.cc: New test.
> ---
> libstdc++-v3/include/bits/ranges_algo.h   |  92 
> .../testsuite/25_algorithms/shift_left/1.cc   | 104 ++
> .../testsuite/25_algorithms/shift_right/1.cc  | 103 +
> 3 files changed, 299 insertions(+)
> create mode 100644 libstdc++-v3/testsuite/25_algorithms/shift_left/1.cc
> create mode 100644 libstdc++-v3/testsuite/25_algorithms/shift_right/1.cc
>
> diff --git a/libstdc++-v3/include/bits/ranges_algo.h
> b/libstdc++-v3/include/bits/ranges_algo.h
> index 7de1072abf0..7d7dbf04103 100644
> --- a/libstdc++-v3/include/bits/ranges_algo.h
> +++ b/libstdc++-v3/include/bits/ranges_algo.h

These new algos should go in  because they're not in
namespace ranges.


Since their implementation uses ranges::next(__it, __n, __last), putting
them in  means we would need to include
 from , or reimplement the
ranges::next() routine in  (and its random access
iterator optimization) it seems.


Ah right.


> @@ -3683,6 +3683,98 @@ namespace ranges
>   inline constexpr __prev_permutation_fn prev_permutation{};
>
> } // namespace ranges
> +
> +  template
> +constexpr ForwardIterator
> +shift_left(ForwardIterator __first, ForwardIterator __last,
> + typename iterator_traits::difference_type __n)
> +{
> +  __glibcxx_assert(__n >= 0);

If I'm reading the current draft correctly, n < 0 is allowed (and does
nothing) so we shouldn't assert here.


From what I can tell, this is changed by P1243R4 (Rangify new
algorithms) which adds the precondition n >= 0 to these routines.


Thanks, I forgot that paper still changed shuft_left and shift_right
even thogh it didn't add ranges::shift_left and ranges::shift_right.

OK for master then, thanks.

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

2020-02-24 Thread Thomas Koenig


Hi Mark,


Might need

 gfc_reduce_init_expr (e);

here.  The kind type parameter should be a constant expression.


Not needed. I've also checked use of the kind argument, it is evidently 
checked elsewhere: if k is allowed to be implicitly declared and is used 
as the kind argument errors are reported that it is not a constant, if 
implicit declaration is not allowed a "has no IMPLICIT type" error is 
produced.


Is there a test case that covers this already?  OK if such a test
case exists, also OK with such a test case (or if looking for it
is too bother :-)

Regards

Thomas

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.




On 2/23/20 11:33 AM, Jakub Jelinek wrote:

On Sun, Feb 23, 2020 at 10:42:17AM -0600, Bill Schmidt wrote:

Have I missed something crucial?

I haven't seen anything in the patch that would only enable it for ELFv2,
and while powerpc64le-linux probably assumes TARGET_VSX unconditionally
(haven't verified), powerpc64-linux or powerpc-linux certainly doesn't.
And it is just fine to have the ABI for those pass/return vectors in VSX
registers too, after all, it won't be used if the vectorized caller isn't
TARGET_VSX, the definitions of the declare simd functions could be compiled
with different ISA options.  And, if the ABI sais that the 'b' stuff assumes
certain ISA extensions, if the declare simd function definition is compiled
with e.g. -mno-vsx -mno-altivec, it would either not be able to get the
arguments/return values at all, or wouldn't benefit from the ISA guarantees
the ABI gives to it.

It's a problem with the patch that it doesn't limit the ABI to ELFv2.  That is
necessary, because there are aspects of the vector ABI that are incompatible
with ELFv1.  In particular, ELFv1 doesn't support returning homogeneous
aggregates of vectors in vector registers, which is called for in the proposed
sincos interface, and would also be needed for vectorized complex functions.

Is it really a problem?  I mean, it is perfectly fine if the declare simd
variants have a different ABI from the normal ABI, just for #pragma omp
declare variant it will be desirable if there is some attribute for such
different (or just slightly amended) ABI.  And vector complex is not an
issue right now, we punt on those on all architectures.


Well, it's a problem in the sense that the ABI as written does not work on
ELFv1, so until we have an ABI that does, we shouldn't allow it for anything
but ELFv2.  (Sections that don't apply to ELFv1 are Calling Convention, Vector
Length, Ordering of Vector Arguments.)

I know vector complex isn't currently an issue; just thinking ahead for
future potential improvements.

Bill



Jakub

libgo patch committed: Add hurd build tag

2020-02-24 Thread Ian Lance Taylor

This patch by Svante Signell adds a missing Hurd build tag.
Bootstrapped and ran Go tests on x86_64-pc-linux-gnu.  Committed to
mainline.

Ian
027a3f1c38727a1ea0969088b0680b2f6bb1e977
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index ce10ee1d8d4..47fbeaeda61 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-d5d00d310ec33aeb18f33f807956ec0c4eeea6bb
+4e6402f3153fad368830ff3fe57c6302179de806
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/go/internal/syscall/unix/nonblocking.go 
b/libgo/go/internal/syscall/unix/nonblocking.go
index 9b39bb24087..1734cdc5124 100644
--- a/libgo/go/internal/syscall/unix/nonblocking.go
+++ b/libgo/go/internal/syscall/unix/nonblocking.go
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build dragonfly freebsd linux netbsd openbsd
+// +build dragonfly freebsd hurd linux netbsd openbsd
 
 package unix

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484




On 24/02/2020 14:34, Thomas Koenig wrote:

Hi Mark,


Might need

 gfc_reduce_init_expr (e);

here.  The kind type parameter should be a constant expression.


Not needed. I've also checked use of the kind argument, it is 
evidently checked elsewhere: if k is allowed to be implicitly 
declared and is used as the kind argument errors are reported that it 
is not a constant, if implicit declaration is not allowed a "has no 
IMPLICIT type" error is produced.


Is there a test case that covers this already?  OK if such a test
case exists, also OK with such a test case (or if looking for it
is too bother :-)


I've had a quick look and there doesn't appear to be a test for using a 
non-constant for kind arguments. I think a proper set of tests for 
invalid kind arguments that covers declarations and intrinsic arguments 
should be added that is separate from this patch.  Should that be done 
while we're in stage 4 or should it wait for stage 1?


In the meantime I'll commit this patch either today or tomorrow.



Regards

Thomas


--
https://www.codethink.co.uk/privacy.html

Re: [PATCH v2] c++: Fix ICE with ill-formed array list-initialization [PR93712]


On 2/21/20 6:48 PM, Marek Polacek wrote:

On Thu, Feb 20, 2020 at 12:28:42AM +, Jason Merrill wrote:

On 2/19/20 7:30 PM, Marek Polacek wrote:

On Fri, Feb 14, 2020 at 09:12:58AM +0100, Jason Merrill wrote:

On 2/13/20 8:56 PM, Marek Polacek wrote:

My P0388R4 patch changed build_array_conv to create an identity
conversion at the start of the conversion chain.


Hmm, an identity conversion of {} suggests that it has a type, which it
doesn't in the language.  I'm not strongly against it, but what was the
reason for this change?


There are two reasons:
1) without it we couldn't get to the original expression at the start
of the conversion chain (saved in .u.expr), this is needed in compare_ics:
10660   tree n1 = nelts_initialized_by_list_init (t1);
10661   tree n2 = nelts_initialized_by_list_init (t2);
and nelts_initialized_by_list_init uses conv_get_original_expr for
arrays that have no dimensions.


Ah, ck_aggr and ck_list probably should have used u.expr like ck_identity
and ck_ambig


2) struct conversion says
/* An implicit conversion sequence, in the sense of [over.best.ics].
 The first conversion to be performed is at the end of the chain.
 That conversion is always a cr_identity conversion.  */
and we were breaking that promise.


...or, if we're going to enforce this, ck_ambig will need to change as well.

And build_aggr_conv and build_complex_conv will need adjusting (one way or
another).


Changed my mind :-).  Turned out using u.expr for ck_aggr is a much smaller
change.  Moreover, that struct conversion talks about cr_identity, a rank,
not ck_identity.

ck_list uses u.list, so I'm not changing that.

-- >8 --
My P0388R4 patch changed build_array_conv to create an identity
conversion at the start of the conversion chain and now we crash
in convert_like_real:

  7457 case ck_identity:
  7458   if (BRACE_ENCLOSED_INITIALIZER_P (expr))
  7459 {
  7460   int nelts = CONSTRUCTOR_NELTS (expr);
  7461   if (nelts == 0)
  7462 expr = build_value_init (totype, complain);
  7463   else if (nelts == 1)
  7464 expr = CONSTRUCTOR_ELT (expr, 0)->value;
  7465   else
  7466 gcc_unreachable ();  // HERE
  7467 }

in a test like this

   int f (int const (&)[2])
   { return f({1, "M"}); }

Instead of creating a ck_identity at the start of the conversion chain,
so that conv_get_original_expr can be used with a ck_aggr, let's set
u.expr for a ck_aggr, and adjust next_conversion not to try to see
what's next in the chain if it gets a ck_aggr.

Bootstrapped/regtested on x86_64-linux, built cmcstl2 and Boost, ok for
trunk?


OK.


2020-02-21  Marek Polacek  

PR c++/93712 - ICE with ill-formed array list-initialization.
* call.c (next_conversion): Return NULL for ck_aggr.
(build_aggr_conv): Set u.expr instead of u.next.
(build_array_conv): Likewise.
(build_complex_conv): Likewise.
(conv_get_original_expr): Handle ck_aggr.

* g++.dg/cpp0x/initlist-array11.C: New test.
---
  gcc/cp/call.c | 17 +
  gcc/testsuite/g++.dg/cpp0x/initlist-array11.C | 10 ++
  2 files changed, 19 insertions(+), 8 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-array11.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index f47f96bf1c2..84230b9ecb8 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -117,13 +117,13 @@ struct conversion {
  /* The next conversion in the chain.  Since the conversions are
 arranged from outermost to innermost, the NEXT conversion will
 actually be performed before this conversion.  This variant is
-   used only when KIND is neither ck_identity, ck_ambig nor
+   used only when KIND is neither ck_identity, ck_aggr, ck_ambig nor
 ck_list.  Please use the next_conversion function instead
 of using this field directly.  */
  conversion *next;
  /* The expression at the beginning of the conversion chain.  This
-   variant is used only if KIND is ck_identity or ck_ambig.  You can
-   use conv_get_original_expr to get this expression.  */
+   variant is used only if KIND is ck_identity, ck_aggr, or ck_ambig.
+   You can use conv_get_original_expr to get this expression.  */
  tree expr;
  /* The array of conversions for an initializer_list, so this
 variant is used only when KIN D is ck_list.  */
@@ -861,7 +861,8 @@ next_conversion (conversion *conv)
if (conv == NULL
|| conv->kind == ck_identity
|| conv->kind == ck_ambig
-  || conv->kind == ck_list)
+  || conv->kind == ck_list
+  || conv->kind == ck_aggr)
  return NULL;
return conv->u.next;
  }
@@ -1030,7 +1031,7 @@ build_aggr_conv (tree type, tree ctor, int flags, 
tsubst_flags_t complain)
c->rank = cr_exact;
c->user_conv_p = true;
c->check_narrowing = true;
-  c->u.next = NULL;
+  c->u.ex

Re: [PATCH] c++: Implement P1957R2, T* to bool should be considered narrowing.


On 2/21/20 2:14 PM, Marek Polacek wrote:

This was approved in the Prague 2020 WG21 meeting so let's adjust the
comment.  Since it's supposed to be a DR I think we should no longer
limit it to C++20.


I'm a bit nervous about the impact, but OK.  It's easy enough to turn 
off -Wnarrowing if it's a problem for users.



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

2020-02-21  Marek Polacek  

P1957R2
* typeck2.c (check_narrowing): Consider T* to bool narrowing
in C++11 and up.

* g++.dg/cpp0x/initlist92.C: Don't expect an error in C++20 only.
---
  gcc/cp/typeck2.c| 7 ---
  gcc/testsuite/g++.dg/cpp0x/initlist92.C | 2 +-
  2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 48920894b3b..68bc2e5c170 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1036,9 +1036,10 @@ check_narrowing (tree type, tree init, tsubst_flags_t 
complain,
  }
else if (TREE_CODE (type) == BOOLEAN_TYPE
   && (TYPE_PTR_P (ftype) || TYPE_PTRMEM_P (ftype)))
-/* This hasn't actually made it into C++20 yet, but let's add it now to get
-   an idea of the impact.  */
-ok = (cxx_dialect < cxx2a);
+/* C++20 P1957R2: converting from a pointer type or a pointer-to-member
+   type to bool should be considered narrowing.  This is a DR so is not
+   limited to C++20 only.  */
+ok = false;
  
bool almost_ok = ok;

if (!ok && !CONSTANT_CLASS_P (init) && (complain & tf_warning_or_error))
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist92.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist92.C
index 319264ae274..213b192d441 100644
--- a/gcc/testsuite/g++.dg/cpp0x/initlist92.C
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist92.C
@@ -23,7 +23,7 @@ bool Test4(std::initializer_list);
  
  int main ()

  {
-  ( Test1({"false"}) );  // { dg-error "narrowing" "" { target c++2a } }
+  ( Test1({"false"}) );  // { dg-error "narrowing" }
( Test2({123}) );
( Test3({456}) );
( Test4({"false"}) );

base-commit: dbfba41e95d1d93b17e907b7f516b52ed3a3c415

Re: [PATCH] c++: Implement P1957R2, T* to bool should be considered narrowing.


On 2/24/20 9:58 AM, Jason Merrill wrote:

On 2/21/20 2:14 PM, Marek Polacek wrote:

This was approved in the Prague 2020 WG21 meeting so let's adjust the
comment.  Since it's supposed to be a DR I think we should no longer
limit it to C++20.


I'm a bit nervous about the impact, but OK.  It's easy enough to turn 
off -Wnarrowing if it's a problem for users.


Hmm, have you tried doing a Fedora build with this change?


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

2020-02-21  Marek Polacek  

P1957R2
* typeck2.c (check_narrowing): Consider T* to bool narrowing
in C++11 and up.

* g++.dg/cpp0x/initlist92.C: Don't expect an error in C++20 only.
---
  gcc/cp/typeck2.c    | 7 ---
  gcc/testsuite/g++.dg/cpp0x/initlist92.C | 2 +-
  2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 48920894b3b..68bc2e5c170 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1036,9 +1036,10 @@ check_narrowing (tree type, tree init, 
tsubst_flags_t complain,

  }
    else if (TREE_CODE (type) == BOOLEAN_TYPE
 && (TYPE_PTR_P (ftype) || TYPE_PTRMEM_P (ftype)))
-    /* This hasn't actually made it into C++20 yet, but let's add it 
now to get

-   an idea of the impact.  */
-    ok = (cxx_dialect < cxx2a);
+    /* C++20 P1957R2: converting from a pointer type or a 
pointer-to-member
+   type to bool should be considered narrowing.  This is a DR so 
is not

+   limited to C++20 only.  */
+    ok = false;
    bool almost_ok = ok;
    if (!ok && !CONSTANT_CLASS_P (init) && (complain & 
tf_warning_or_error))
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist92.C 
b/gcc/testsuite/g++.dg/cpp0x/initlist92.C

index 319264ae274..213b192d441 100644
--- a/gcc/testsuite/g++.dg/cpp0x/initlist92.C
+++ b/gcc/testsuite/g++.dg/cpp0x/initlist92.C
@@ -23,7 +23,7 @@ bool Test4(std::initializer_list);
  int main ()
  {
-  ( Test1({"false"}) );    // { dg-error "narrowing" "" { target 
c++2a } }

+  ( Test1({"false"}) );    // { dg-error "narrowing" }
    ( Test2({123}) );
    ( Test3({456}) );
    ( Test4({"false"}) );

base-commit: dbfba41e95d1d93b17e907b7f516b52ed3a3c415

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484


On 2/24/20 3:50 PM, Mark Eggleston wrote:
I've had a quick look and there doesn't appear to be a test for using 
a non-constant for kind arguments. I think a proper set of tests for 
invalid kind arguments that covers declarations and intrinsic 
arguments should be added that is separate from this patch.  Should 
that be done while we're in stage 4 or should it wait for stage 1?


Test cases can always go in* – and usually having them earlier is better 
than later. Besides, they cannot get forgotten if done now – and you 
already have a stub. If we find bugs, we can still consider whether we 
want to have them fixed now (Stage 4) or later (GCC 11 Stage 1 + 
possibly backported).


Tobias

*Well, kind of. Some "dg-" syntax errors can break the testsuite – and 
the release manager do not like any commit when the branch is "frozen". 
(Directly before a release; approx. 1–3 days freeze; used to check that 
everything builds fine before actually tagging a release.)

Re: [PATCH] c++: Fix ICE with -Wmismatched-tags [PR93869]


On 2/21/20 1:06 PM, Marek Polacek wrote:

This is a crash in cp_parser_check_class_key:
   tree type_decl = TYPE_MAIN_DECL (type);
   tree name = DECL_NAME (type_decl); // HERE
because TYPE_MAIN_DECL of type was null as it's not a class type.
Instead of checking CLASS_TYPE_P we should simply check class_key
a bit earlier (in this case it was typename_type).

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


OK.


2020-02-21  Marek Polacek  

PR c++/93869 - ICE with -Wmismatched-tags.
* parser.c (cp_parser_check_class_key): Check class_key earlier.

* g++.dg/warn/Wmismatched-tags-2.C: New test.
---
  gcc/cp/parser.c| 14 +++---
  gcc/testsuite/g++.dg/warn/Wmismatched-tags-2.C |  6 ++
  2 files changed, 13 insertions(+), 7 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/warn/Wmismatched-tags-2.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ee534b5db21..d5f2c14d951 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30987,6 +30987,13 @@ cp_parser_check_class_key (cp_parser *parser, 
location_t key_loc,
if (!warn_mismatched_tags && !warn_redundant_tags)
  return;
  
+  /* Only consider the true class-keys below and ignore typename_type,

+ etc. that are not C++ class-keys.  */
+  if (class_key != class_type
+  && class_key != record_type
+  && class_key != union_type)
+return;
+
tree type_decl = TYPE_MAIN_DECL (type);
tree name = DECL_NAME (type_decl);
/* Look up the NAME to see if it unambiguously refers to the TYPE
@@ -30995,13 +31002,6 @@ cp_parser_check_class_key (cp_parser *parser, 
location_t key_loc,
tree decl = cp_parser_lookup_name_simple (parser, name, input_location);
pop_deferring_access_checks ();
  
-  /* Only consider the true class-keys below and ignore typename_type,

- etc. that are not C++ class-keys.  */
-  if (class_key != class_type
-  && class_key != record_type
-  && class_key != union_type)
-return;
-
/* The class-key is redundant for uses of the CLASS_TYPE that are
   neither definitions of it nor declarations, and for which name
   lookup returns just the type itself.  */
diff --git a/gcc/testsuite/g++.dg/warn/Wmismatched-tags-2.C 
b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-2.C
new file mode 100644
index 000..00193f02f61
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wmismatched-tags-2.C
@@ -0,0 +1,6 @@
+// PR c++/93869 - ICE with -Wmismatched-tags.
+// { dg-do compile }
+// { dg-options "-Wmismatched-tags" }
+
+namespace N { typedef int T; }
+typename N::T x;

base-commit: dbfba41e95d1d93b17e907b7f516b52ed3a3c415

Re: [PATCH] c++: Implement P1957R2, T* to bool should be considered narrowing.

On Mon, Feb 24, 2020 at 09:59:51AM -0500, Jason Merrill wrote:
> On 2/24/20 9:58 AM, Jason Merrill wrote:
> > On 2/21/20 2:14 PM, Marek Polacek wrote:
> > > This was approved in the Prague 2020 WG21 meeting so let's adjust the
> > > comment.  Since it's supposed to be a DR I think we should no longer
> > > limit it to C++20.
> > 
> > I'm a bit nervous about the impact, but OK.  It's easy enough to turn
> > off -Wnarrowing if it's a problem for users.
> 
> Hmm, have you tried doing a Fedora build with this change?

I'll admit I have not.

Jeff, would it be possible to apply this patch onto one of your testers?
We'd be much more comfortable going with this change then.

> > > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> > > 
> > > 2020-02-21  Marek Polacek  
> > > 
> > > P1957R2
> > > * typeck2.c (check_narrowing): Consider T* to bool narrowing
> > > in C++11 and up.
> > > 
> > > * g++.dg/cpp0x/initlist92.C: Don't expect an error in C++20 only.
> > > ---
> > >   gcc/cp/typeck2.c    | 7 ---
> > >   gcc/testsuite/g++.dg/cpp0x/initlist92.C | 2 +-
> > >   2 files changed, 5 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
> > > index 48920894b3b..68bc2e5c170 100644
> > > --- a/gcc/cp/typeck2.c
> > > +++ b/gcc/cp/typeck2.c
> > > @@ -1036,9 +1036,10 @@ check_narrowing (tree type, tree init,
> > > tsubst_flags_t complain,
> > >   }
> > >     else if (TREE_CODE (type) == BOOLEAN_TYPE
> > >  && (TYPE_PTR_P (ftype) || TYPE_PTRMEM_P (ftype)))
> > > -    /* This hasn't actually made it into C++20 yet, but let's add
> > > it now to get
> > > -   an idea of the impact.  */
> > > -    ok = (cxx_dialect < cxx2a);
> > > +    /* C++20 P1957R2: converting from a pointer type or a
> > > pointer-to-member
> > > +   type to bool should be considered narrowing.  This is a DR
> > > so is not
> > > +   limited to C++20 only.  */
> > > +    ok = false;
> > >     bool almost_ok = ok;
> > >     if (!ok && !CONSTANT_CLASS_P (init) && (complain &
> > > tf_warning_or_error))
> > > diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist92.C
> > > b/gcc/testsuite/g++.dg/cpp0x/initlist92.C
> > > index 319264ae274..213b192d441 100644
> > > --- a/gcc/testsuite/g++.dg/cpp0x/initlist92.C
> > > +++ b/gcc/testsuite/g++.dg/cpp0x/initlist92.C
> > > @@ -23,7 +23,7 @@ bool Test4(std::initializer_list);
> > >   int main ()
> > >   {
> > > -  ( Test1({"false"}) );    // { dg-error "narrowing" "" { target
> > > c++2a } }
> > > +  ( Test1({"false"}) );    // { dg-error "narrowing" }
> > >     ( Test2({123}) );
> > >     ( Test3({456}) );
> > >     ( Test4({"false"}) );
> > > 
> > > base-commit: dbfba41e95d1d93b17e907b7f516b52ed3a3c415
> > > 
> > 
> 

Marek

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

On 2/23/20 1:12 PM, Segher Boessenkool wrote:

On Sun, Feb 23, 2020 at 10:55:53AM -0600, Bill Schmidt wrote:

Though I'm usually uncomfortable with kicking the can down the road on these
sorts of things, I can probably be convinced in this case. Tulio and I were
wondering why the libmvec interface doesn't make use of ifunc capability for
this sort of thing. Something to look into when more advanced
implementations
are added later, I guess, and a valid reason to not lock ourselves into the
'c' ABI today.

I have some questions, too. Why is this called an ABI at all? Why will
it not work with *any* underlying ABI? What *is* this, what is it *for*,
where is the documentation, where is the design documentation? Etc.

So, I can answer a small amount of this, but I will say that overall, design
or implementation documentation seems to be between lacking and nonexistent.

This has to do with "#pragma omp simd" and providing the rules for vectorizing
functions into calls to libmvec. I tend to agree that it is a bit more like
API than ABI, but we are just fitting into existing frameworks and using the
same nomenclature.

The ABI that Bert has produced for us is available at
https://sourceware.org/glibc/wiki/HomePage?action=AttachFile&do=view&target=powerarchvectfuncabi.html.

It is based on a similar document for x86. I believe this is the most up-to-
date version:
https://software.intel.com/sites/default/files/managed/b4/c8/Intel-Vector-Function-ABI.pdf

There's been ongoing work in the same area for AArch64, with the most recent
version available here, I believe:
https://developer.arm.com/docs/101129/latest

I am not certain of the completion status of the AArch64 implementation.
The libmvec implementation for Intel has been around for a long time.

Hope that at least starts to help,
Bill

Segher

Re: [PATCH] Fix bug in recursiveness check for function to be cloned (ipa/pr93707)

2020-02-24 Thread Martin Jambor

Hi,

On Sat, Feb 22 2020, Feng Xue OS wrote:
> It is a good solution.
>

OK, so I'd like to go with my patch as it hopefully keeps some of the
predicates a tiny bit simpler.  I have re-based the patch on today's
trunk and amended function comments as necessary (which I forgot last
week).  The result is below, it has passed bootstrap and testing and
LTO+PGO bootstrap on x86_64-linux.

Honza, is it OK for trunk?

Thanks,

Martin


ipa-cp: Avoid an ICE processing self-recursive cloned edges (PR 93707)

2020-02-24  Martin Jambor  
Feng Xue  

PR ipa/93707
* ipa-cp.c (same_node_or_its_all_contexts_clone_p): Replaced with
new function calls_same_node_or_its_all_contexts_clone_p.
(cgraph_edge_brings_value_p): Use it.
(cgraph_edge_brings_value_p): Likewise.
(self_recursive_pass_through_p): Return false if caller is a clone.
(self_recursive_agg_pass_through_p): Likewise.

testsuite/
* gcc.dg/ipa/pr93707.c: New test.
---
 gcc/ChangeLog  | 11 ++
 gcc/ipa-cp.c   | 55 +-
 gcc/testsuite/ChangeLog|  6 
 gcc/testsuite/gcc.dg/ipa/pr93707.c | 31 +
 4 files changed, 79 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/ipa/pr93707.c

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 1d0c1ac0f35..27c020b8199 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -4035,15 +4035,25 @@ edge_clone_summary_t::duplicate (cgraph_edge *src_edge, 
cgraph_edge *dst_edge,
   src_data->next_clone = dst_edge;
 }
 
-/* Return true is NODE is DEST or its clone for all contexts.  */
+/* Return true is CS calls DEST or its clone for all contexts.  When
+   ALLOW_RECURSION_TO_CLONE is false, also return false for self-recursive
+   edges from/to an all-context clone.  */
 
 static bool
-same_node_or_its_all_contexts_clone_p (cgraph_node *node, cgraph_node *dest)
+calls_same_node_or_its_all_contexts_clone_p (cgraph_edge *cs, cgraph_node 
*dest,
+bool allow_recursion_to_clone)
 {
-  if (node == dest)
+  enum availability availability;
+  cgraph_node *callee = cs->callee->function_symbol (&availability);
+
+  if (availability <= AVAIL_INTERPOSABLE)
+return false;
+  if (callee == dest)
 return true;
+  if (!allow_recursion_to_clone && cs->caller == callee)
+return false;
 
-  class ipa_node_params *info = IPA_NODE_REF (node);
+  class ipa_node_params *info = IPA_NODE_REF (callee);
   return info->is_all_contexts_clone && info->ipcp_orig_node == dest;
 }
 
@@ -4055,11 +4065,8 @@ cgraph_edge_brings_value_p (cgraph_edge *cs, 
ipcp_value_source *src,
cgraph_node *dest, ipcp_value *dest_val)
 {
   class ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
-  enum availability availability;
-  cgraph_node *real_dest = cs->callee->function_symbol (&availability);
 
-  if (availability <= AVAIL_INTERPOSABLE
-  || !same_node_or_its_all_contexts_clone_p (real_dest, dest)
+  if (!calls_same_node_or_its_all_contexts_clone_p (cs, dest, !src->val)
   || caller_info->node_dead)
 return false;
 
@@ -4078,9 +4085,6 @@ cgraph_edge_brings_value_p (cgraph_edge *cs, 
ipcp_value_source *src,
 }
   else
 {
-  /* At the moment we do not propagate over arithmetic jump functions in
-SCCs, so it is safe to detect self-feeding recursive calls in this
-way.  */
   if (src->val == dest_val)
return true;
 
@@ -4115,11 +4119,8 @@ cgraph_edge_brings_value_p (cgraph_edge *cs,
ipcp_value *)
 {
   class ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
-  enum availability avail;
-  cgraph_node *real_dest = cs->callee->function_symbol (&avail);
 
-  if (avail <= AVAIL_INTERPOSABLE
-  || !same_node_or_its_all_contexts_clone_p (real_dest, dest)
+  if (!calls_same_node_or_its_all_contexts_clone_p (cs, dest, true)
   || caller_info->node_dead)
 return false;
   if (!src->val)
@@ -4619,9 +4620,10 @@ create_specialized_node (struct cgraph_node *node,
   return new_node;
 }
 
-/* Return true, if JFUNC, which describes a i-th parameter of call CS, is a
-   pass-through function to itself.  When SIMPLE is true, further check if
-   JFUNC is a simple no-operation pass-through.  */
+/* Return true if JFUNC, which describes a i-th parameter of call CS, is a
+   pass-through function to itself when the cgraph_node involved is not an
+   IPA-CP clone.  When SIMPLE is true, further check if JFUNC is a simple
+   no-operation pass-through.  */
 
 static bool
 self_recursive_pass_through_p (cgraph_edge *cs, ipa_jump_func *jfunc, int i,
@@ -4632,15 +4634,18 @@ self_recursive_pass_through_p (cgraph_edge *cs, 
ipa_jump_func *jfunc, int i,
   && availability > AVAIL_INTERPOSABLE
   && jfunc->type == IPA_JF_PASS_THROUGH
   && (!simple || ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
-  && ipa_get_j

Re: [PATCH] [arm] Implement Armv8.1-M low overhead loops

2020-02-24 Thread Andrea Corallo

Hi Roman,

Roman Zhuykov  writes:

>> SMS is disabled in tests not to break them when SMS does loop versioning.
>
> And I'm not really sure about this.  First of all, there are a lot of
> scan-assembler-times tests which fail when modulo-scheduler is enabled,
> probably the same happens when some unrolling parameters are not
> default.  It seems that any non-default optimization which creates more
> instruction copies can break scan-assembler-times check.  IMHO, it is
> not necessary to workaround this in few particular tests.  Second, I'm
> not sure how dg-skip-if directive works.  When one enables SMS setting
> "Init(1)" directly into common.opt this won't be catched, would it?

Agree on everything.  Also enabling SMS from common.opt apparently makes
dg-skip-if not effective.

Thanks for commenting I'm updating the patch.

  Andrea

Re: [PATCH] c++: Some improvements to concept diagnostics


On 2/20/20 7:27 PM, Patrick Palka wrote:

This patch improves our concept diagnostics in two ways.  First, it sets a more
precise location for the constraint expressions built in
finish_constraint_binary_op.  As a result, when a disjunction is unsatisfied we
now print e.g.

.../include/bits/range_access.h:467:2: note: neither operand of the disjunction 
is satisfied
   466 |  requires is_bounded_array_v> || 
__member_end<_Tp>
   |   

   467 |  || __adl_end<_Tp>
   |  ^

instead of

.../include/bits/range_access.h:467:2: note: neither operand of the disjunction 
is satisfied
   467 |  || __adl_end<_Tp>
   |  ^~


This hunk is OK.


Second, this patch changes diagnose_atomic_constraint to pretty-print
unsatisfied atomic constraint expressions with their template arguments
substituted in (if doing so does not result in a trivial expression).  So for
example we now emit

cpp2a/concepts-pr67719.C:9:8: note: the expression ‘((C() && C()) && 
C())’ evaluated to ‘false’

instead of

cpp2a/concepts-pr67719.C:9:8: note: the expression ‘(... &&(C)())’ 
evaluated to ‘false’


Generally with templates we try to print the dependent form and then the 
arguments; pp_cxx_atomic_constraint already wants to do that, but we 
don't get there from here.  Perhaps pass 'map' instead of 'args' into 
diagnose_atomic_constraint, and then build a new ATOMIC_CONSTR for 
printing with %E?



Tested on x86_64-pc-linux-gnu, and verified that all the diagnostics emitted in
our concept tests are no worse with this patch.  Does this look OK to commit?

gcc/cp/ChangeLog:

* constraint.cc (finish_constraint_binary_op): Set expr's location range
to the range of its operands.
(diagnose_atomic_constraint): Prefer to pretty-print the atomic
constraint with template arguments substituted in.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/diagnostic2.C: New test.
* g++.dg/concepts/diagnostic3.C: New test.
---
  gcc/cp/constraint.cc| 15 +++
  gcc/testsuite/g++.dg/concepts/diagnostic2.C | 30 +
  gcc/testsuite/g++.dg/concepts/diagnostic3.C | 19 +
  3 files changed, 59 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic2.C
  create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic3.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 58044cd0f9d..4f6bc11e7e8 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -155,14 +155,14 @@ finish_constraint_binary_op (location_t loc,
if (!check_constraint_operands (loc, lhs, rhs))
  return error_mark_node;
tree overload;
-  tree expr = build_x_binary_op (loc, code,
-lhs, TREE_CODE (lhs),
-rhs, TREE_CODE (rhs),
-&overload, tf_none);
+  cp_expr expr = build_x_binary_op (loc, code,
+   lhs, TREE_CODE (lhs),
+   rhs, TREE_CODE (rhs),
+   &overload, tf_none);
/* When either operand is dependent, the overload set may be non-empty.  */
if (expr == error_mark_node)
  return error_mark_node;
-  SET_EXPR_LOCATION (expr, loc);
+  expr.set_range (lhs.get_start (), rhs.get_finish ());
return expr;
  }
  
@@ -3330,6 +3330,11 @@ diagnose_atomic_constraint (tree t, tree args, subst_info info)

inform (loc, "%qE is never satisfied", expr);
break;
  default:
+  tree orig_expr = expr;
+  expr = tsubst_expr (expr, args, tf_none, NULL_TREE, false);
+  if (CONSTANT_CLASS_P (expr))
+   /* We are better off printing the original expression.  */
+   expr = orig_expr;
inform (loc, "the expression %qE evaluated to %", expr);
  }
  }
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic2.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic2.C
new file mode 100644
index 000..ce51b71fa8b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/diagnostic2.C
@@ -0,0 +1,30 @@
+// { dg-do compile { target c++2a } }
+// { dg-options "-fdiagnostics-show-caret" }
+
+template
+  inline constexpr bool foo_v = false;
+
+template
+  concept foo = foo_v || foo_v; // { dg-message "neither operand" }
+/* { dg-begin-multiline-output "" }
+   concept foo = foo_v || foo_v;
+ ~^~~~
+   { dg-end-multiline-output "" } */
+
+template
+  requires foo
+  void bar();
+/* { dg-begin-multiline-output "" }
+   void bar();
+   { dg-end-multiline-output "" } */
+/* { dg-prune-output "~" } */
+
+void
+baz()
+{
+  bar(); // { dg-error "unsatisfied constraints" }
+/* { dg-begin-multiline-output "" }
+   bar();
+^
+   { dg-end-multiline-output "" } */
+}
diff --git a/gcc/testsuite/g++.dg/concepts/diagnostic3.C 
b/gcc/testsuite/g++.dg/concepts/diagnostic3.C
new file mode 100644
index 000..

Re: [PATCH] avoid issuing -Wredundant-tags in shared C/C++ code in headers (PR 93804)


On 2/20/20 5:55 PM, Martin Sebor wrote:

On 2/19/20 5:09 PM, Jason Merrill wrote:

On 2/19/20 1:02 AM, Martin Sebor wrote:

PR 93804 points out that issuing -Wredundant-tags for declarations
in C headers included in C++ isn't helpful because the tags cannot
be removed without breaking C programs that depend on the headers.

Attached is a patch that avoids the warning in these cases tested
on x86_64-linux.  While strictly not a regression (and even though
I initially considered it a GCC 11 enhancement), since most C++
code includes some C headers, without the patch the warning would
likely cause too much noise to be widely useful.



+  const line_map_ordinary *map = NULL;
+  linemap_resolve_location (line_table, key_loc,
+    LRK_MACRO_DEFINITION_LOCATION,
+    &map);
+  if (!MAIN_FILE_P (map))
+    key_redundant = false;


Checking which file it came from seems like unnecessary complication; 
is it important to still warn in extern "C" blocks in the main source 
file?


It's only important if someone is relying on it to avoid the redundant
tags in all their C++ code, e.g., as part of cleaning up -Wmismatched-
tags.  The latter will complain about mismatches in extern "C" blocks
and suggest either dropping the tag or replacing it, whichever is
appropriate.  I'd view it as a bug if -Wredundant-tags didn't do
the same since that's its one and only job.

I attach a slightly revised patch that also handles enums (as pointed
out by Stephan), and with beefed up tests.  Retested on x86_64-linux.

If you find the linemap code distracting, or even the warning code,
I can factor it out and into a helper function.



+  && current_lang_name != lang_name_cplusplus
+  && current_namespace == global_namespace)
+{
+  /* Avoid issuing the diagnostic for apparently redundant (unscoped)
+enum tag in shared C/C++ code in files (such as headers) included
+in the main source file.  */
+  const line_map_ordinary *map = NULL;
+  linemap_resolve_location (line_table, key_loc,
+   LRK_MACRO_DEFINITION_LOCATION,
+   &map);
+  if (!MAIN_FILE_P (map))
+   return;


This much is common between the enum and class functions and could be 
factored out, but I don't feel strongly about it.  Also, why 
LRK_MACRO_DEFINITION_LOCATION rather than LRK_SPELLING_LOCATION?



+  /* Only consider the true class-keys below and ignore typename_type,
+ etc. that are not C++ class-keys.  */
+  if (class_key != class_type
+  && class_key != record_type
+  && class_key != union_type)
+return;
+
   /* Only consider the true class-keys below and ignore typename_type,
  etc. that are not C++ class-keys.  */
   if (class_key != class_type


This looks like a rebase glitch adding the same code again.  OK without 
this hunk.


Jason

[committed] analyzer: eliminate irrelevant control-flow edges from paths

Paths emitted by the analyzer can be quite verbose at the default of
-fanalyzer-verbosity=2.

Consider the double-free in this example:

  #include 

  int foo ();
  int bar ();

  void test (int a, int b, int c)
  {
void *p = malloc (1024);
while (a)
  foo ();
if (b)
  foo ();
else
  bar ();
if (c)
  free (p);
free (p);
  }

Previously, the analyzer would emit a checker_path containing all
control-flow information on the exploded_path leading to the
double-free:

  test.c: In function 'test':
  test.c:17:3: warning: double-'free' of 'p' [CWE-415] [-Wanalyzer-double-free]
 17 |   free (p);
|   ^~~~
'test': events 1-9
  |
  |8 |   void *p = malloc (1024);
  |  | ^
  |  | |
  |  | (1) allocated here
  |9 |   while (a)
  |  | ~
  |  | |
  |  | (2) following 'false' branch (when 'a == 0')...
  |   10 | foo ();
  |   11 |   if (b)
  |  |  ~
  |  |  |
  |  |  (3) ...to here
  |  |  (4) following 'false' branch (when 'b == 0')...
  |..
  |   14 | bar ();
  |  | ~~
  |  | |
  |  | (5) ...to here
  |   15 |   if (c)
  |  |  ~
  |  |  |
  |  |  (6) following 'true' branch (when 'c != 0')...
  |   16 | free (p);
  |  | 
  |  | |
  |  | (7) ...to here
  |  | (8) first 'free' here
  |   17 |   free (p);
  |  |   
  |  |   |
  |  |   (9) second 'free' here; first 'free' was at (8)
  |

despite the fact that only the "if (c)" is relevant to triggering the
double-free.

This patch implements pruning of control flow events at
-fanalyzer-verbosity=2, based on reachability information within the
exploded_graph.
The diagnostic_manager pre-computes reachability information about
which exploded_nodes can reach the exploded_node of the diagnostic,
and uses this to prune irrelvent control flow edges.

The patch also adds a -fanalyzer-verbosity=3 to preserve these edges,
so that the "show me everything" debugging level becomes
-fanalyzer-verbosity=4.

With these changes, the "while (a)" and "if (b)" edges are pruned from
the above example, leading to:

  test.c: In function 'test':
  test.c:17:3: warning: double-'free' of 'p' [CWE-415] [-Wanalyzer-double-free]
 17 |   free (p);
|   ^~~~
'test': events 1-5
  |
  |8 |   void *p = malloc (1024);
  |  | ^
  |  | |
  |  | (1) allocated here
  |..
  |   15 |   if (c)
  |  |  ~
  |  |  |
  |  |  (2) following 'true' branch (when 'c != 0')...
  |   16 | free (p);
  |  | 
  |  | |
  |  | (3) ...to here
  |  | (4) first 'free' here
  |   17 |   free (p);
  |  |   
  |  |   |
  |  |   (5) second 'free' here; first 'free' was at (4)
  |

The above example is gcc.dg/analyzer/edges-2.c.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 004f2c07b6d3fa543f0fe86c55a7b3c227de2bb6.

gcc/analyzer/ChangeLog:
* checker-path.cc (superedge_event::should_filter_p): Update
filter for empty descriptions to cover verbosity level 3 as well
as 2.
* diagnostic-manager.cc: Include "analyzer/reachability.h".
(class path_builder): New class.
(diagnostic_manager::emit_saved_diagnostic): Create a path_builder
and pass it to build_emission_path, rather passing eg; similarly
for add_events_for_eedge and ext_state.
(diagnostic_manager::build_emission_path): Replace "eg" param
with a path_builder, pass it to add_events_for_eedge.
(diagnostic_manager::add_events_for_eedge): Replace ext_state
param with path_builder; pass it to add_events_for_superedge.
(diagnostic_manager::significant_edge_p): New.
(diagnostic_manager::add_events_for_superedge): Add path_builder
param.  Reject insignificant edges at verbosity levels below 3.
(diagnostic_manager::prune_for_sm_diagnostic): Update highest
verbosity level to 4.
* diagnostic-manager.h (class path_builder): New forward decl.
(diagnostic_manager::build_emission_path): Replace "eg" param
with a path_builder.
(diagnostic_manager::add_events_for_eedge): Replace ext_state
param with path_builder.
(diagnostic_manager::significant_edge_p): New.
(diagnostic_manager::add_events_for_superedge): Add path_builder
param.
* reachability.h: New file.

gcc/ChangeLog:
* doc/invoke.texi (-fanalyzer-verbosity=): "2" only shows
significant c

[PATCH] c++: Fix ICE with constexpr init and [[no_unique_address]] [PR93803]

Here we crash when constexpr-initializing a class member of empty class
type with [[no_unique_address]].  Without the attribute we would have
a ctor (that initializes bar) of the form

  { .D.2173 = { .x = {} } }

but with the attribute reduced_constant_expression_p gets

  { .x = {} }

That means that "idx != field" is true for the latter and we see that
foo, the base class of bar, is an empty class, so we want to look at
the next initializable field (since empty class fields may not have an
initializer).  But in this case there are no more, therefore accessing
DECL_CHAIN (field) crashes.  Long story short, we need to avoid a crash
on a null field when we're initializing a class that only contains an
empty base class.

While poking into this I discovered c++/93898, but that's a different
problem.

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

2020-02-24  Marek Polacek  

PR c++/93803 - ICE with constexpr init and [[no_unique_address]].
* constexpr.c (reduced_constant_expression_p): Don't crash on a null
field.

* g++.dg/cpp2a/constexpr-init16.C: New test.
* g++.dg/cpp2a/constexpr-init17.C: New test.
---
 gcc/cp/constexpr.c| 16 +++-
 gcc/testsuite/g++.dg/cpp2a/constexpr-init16.C | 15 +++
 gcc/testsuite/g++.dg/cpp2a/constexpr-init17.C | 15 +++
 3 files changed, 37 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init16.C
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init17.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 128f760778b..3da1609cdaa 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2603,16 +2603,14 @@ reduced_constant_expression_p (tree t)
 element.  */
  if (!reduced_constant_expression_p (val))
return false;
+ /* Empty class field may or may not have an initializer.  */
+ for (; field && idx != field;
+  field = next_initializable_field (DECL_CHAIN (field)))
+   if (!is_really_empty_class (TREE_TYPE (field),
+   /*ignore_vptr*/false))
+ return false;
  if (field)
-   {
- /* Empty class field may or may not have an initializer.  */
- for (; idx != field;
-  field = next_initializable_field (DECL_CHAIN (field)))
-   if (!is_really_empty_class (TREE_TYPE (field),
-   /*ignore_vptr*/false))
- return false;
- field = next_initializable_field (DECL_CHAIN (field));
-   }
+   field = next_initializable_field (DECL_CHAIN (field));
}
   /* There could be a non-empty field at the end.  */
   for (; field; field = next_initializable_field (DECL_CHAIN (field)))
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-init16.C 
b/gcc/testsuite/g++.dg/cpp2a/constexpr-init16.C
new file mode 100644
index 000..16db2974f2a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-init16.C
@@ -0,0 +1,15 @@
+// PR c++/93803 - ICE with constexpr init and [[no_unique_address]].
+// { dg-do compile { target c++2a } }
+
+struct empty { };
+
+struct foo {
+  [[no_unique_address]] empty x;
+  constexpr foo() : x{} { }
+};
+
+struct bar : foo {
+  using foo::foo;
+};
+
+constexpr bar a{};
diff --git a/gcc/testsuite/g++.dg/cpp2a/constexpr-init17.C 
b/gcc/testsuite/g++.dg/cpp2a/constexpr-init17.C
new file mode 100644
index 000..34d9fe58ecb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/constexpr-init17.C
@@ -0,0 +1,15 @@
+// PR c++/93803 - ICE with constexpr init and [[no_unique_address]].
+// { dg-do compile { target c++2a } }
+
+struct empty { };
+
+struct foo {
+  [[no_unique_address]] empty x, x2, x3;
+  constexpr foo() : x{}, x2{} { }
+};
+
+struct bar : foo {
+  using foo::foo;
+};
+
+constexpr bar a{};

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

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.


On 2/14/20 2:24 PM, GT wrote:

Function rs6000_simd_clone_adjust, even though it's body is empty,
cannot simply be removed. I tried it. It resulted in ICE. In my
view, leaving it empty is preferable to modifying other files
unrelated to rs6000.c in order to avoid having a function whose
body is empty.

Bert.
From 1e8feec5e90ff1a879849714c8d2ea143e77e154 Mon Sep 17 00:00:00 2001
From: Bert Tenjy 
Date: Fri, 14 Feb 2020 13:31:53 -0600
Subject: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function
 ABI.

The Vector Function ABI document is tentatively located at:


Bill Schmidt of IBM Linux Tech. Center has committed to eventually
integrating this ABI into the official POWER Architecture specifications.
He is a GCC and Toolchain Architect so this should ease concerns over
how much to trust an ABI which is not an official release.

The implementation is very similar to those of x86_64 SSE and Aarch64.

The major test of this patch autovectorizes math functions and so requires
libmvec. PPC64 libmvec functionality is only available on GLIBC branch
tuliom/libmvec. Until that branch is merged to master, testing this ABI
will mean checking out GLIBC branch tuliom/libmvec, building and 
installing
to a non-system directory. Likewise, GCC will have to be built then 
installed

so that it doesn't interfere with the system's GCC.

Compiling with newly-built GCC against newly-built GLIBC requires these
options to GCC:
-L "${glibc_install_dir}/lib"
-I "${glibc_install_dir}/include"
-Wl,--rpath="${glibc_install_dir}/lib"
-Wl,--dynamic-linker="${glibc_install_dir}/lib/ld64.so.2"
---
 gcc/config/rs6000/rs6000.c | 152 +
 1 file changed, 152 insertions(+)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index fc36bb6714b..3329c96e6cc 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1266,6 +1266,147 @@ static const struct attribute_spec 
rs6000_attribute_table[] =

 #endif
   { NULL,    0, 0, false, false, false, false, NULL, NULL }
 };
+
+/* Implement TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN.  */
+
+static int
+rs6000_simd_clone_compute_vecsize_and_simdlen (struct cgraph_node *node,
+    struct cgraph_simd_clone *clonei,
+    tree base_type, int num)
+{
+  int ret = 1;
+
+  if (clonei->simdlen
+  && (clonei->simdlen < 2
+      || clonei->simdlen > 1024


Assuming that clonei->simdlen matches "vector length" in the ABI, 1024 is
too large a number.  We can have at most 8 vector registers containing
a homogeneous aggregate, each having up to 16 elements, so the correct
limit would be 128.


+      || (clonei->simdlen & (clonei->simdlen - 1)) != 0))
+    {
+  warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+          "unsupported simdlen %d", clonei->simdlen);
+  return 0;
+    }
+
+  tree ret_type = TREE_TYPE (TREE_TYPE (node->decl));
+  if (TREE_CODE (ret_type) != VOID_TYPE)
+    switch (TYPE_MODE (ret_type))
+  {
+  case E_QImode:
+  case E_HImode:
+  case E_SImode:
+  case E_DImode:
+  case E_SFmode:
+  case E_DFmode:
+  /* case E_SCmode: */
+  /* case E_DCmode: */


Remove the two preceding lines.


+    if (!AGGREGATE_TYPE_P (ret_type))
+      break;
+    /* FALLTHRU */
+  default:
+    warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+        "unsupported return type %qT for simd", ret_type);
+    return 0;
+  }
+
+  tree t;
+  int i;
+  tree type_arg_types = TYPE_ARG_TYPES (TREE_TYPE (node->decl));
+  bool decl_arg_p = (node->definition || type_arg_types == NULL_TREE);
+
+  for (t = (decl_arg_p ? DECL_ARGUMENTS (node->decl) : 
type_arg_types), i = 0;

+   t && t != void_list_node; t = TREE_CHAIN (t), i++)
+    {
+  tree arg_type = decl_arg_p ? TREE_TYPE (t) : TREE_VALUE (t);
+  switch (TYPE_MODE (arg_type))
+    {
+    case E_QImode:
+    case E_HImode:
+    case E_SImode:
+    case E_DImode:
+    case E_SFmode:
+    case E_DFmode:
+    /* case E_SCmode: */
+    /* case E_DCmode: */


Again, remove the two preceding lines.


+      if (!AGGREGATE_TYPE_P (arg_type))
+    break;
+      /* FALLTHRU */
+    default:
+      if (clonei->args[i].arg_type == SIMD_CLONE_ARG_TYPE_UNIFORM)
+    break;
+      warning_at (DECL_SOURCE_LOCATION (node->decl), 0,
+          "unsupported argument type %qT for simd", arg_type);
+      return 0;
+    }
+    }
+
+  if (TARGET_VSX)
+    {
+  clonei->vecsize_mangle = 'b';
+  ret = 1;
+    }
+  clonei->mask_mode = VOIDmode;
+  switch (clonei->vecsize_mangle)
+    {
+    case 'b':
+  clonei->vecsize_int = 128;
+  clonei->vecsize_float = 128;
+  break;
+    default:
+  gcc_unreachable ();
+    }
+  if (clonei->simdlen == 0)
+    {
+  if (SCALAR_INT_MODE_P (TYPE_MODE (base_type)))
+    clonei->simdlen = clonei->vecsize_int;
+  else
+    clonei->simdlen

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

2020-02-24 Thread Jakub Jelinek

On Mon, Feb 24, 2020 at 11:04:55AM -0600, Bill Schmidt wrote:
> > +  if (clonei->simdlen
> > +  && (clonei->simdlen < 2
> > +      || clonei->simdlen > 1024
> 
> Assuming that clonei->simdlen matches "vector length" in the ABI, 1024 is
> too large a number.  We can have at most 8 vector registers containing
> a homogeneous aggregate, each having up to 16 elements, so the correct
> limit would be 128.

Well, further arguments can be passed on the stack...

Jakub

Re: [PATCH] libstdc++: Add missing bits of P0896R4 pertaining to [back|front]_insert_iterator


This should do the same changes for std::insert_iterator, but it
currently crashes the compiler (PR 93907). I am not committing this
yet.


commit 2db20402125e6136d6768598f5974e917b2622c6
Author: Jonathan Wakely 
Date:   Mon Feb 24 15:50:59 2020 +

libstdc++: Add missing bits of P0896R4 pertaining to insert_iterator (PR 93884)

This completes the fix for PR 93884. In order to use ranges::iterator_t
in std::insert_iterator the definition of ranges::iterator_t and
ranges::begin need to be moved, to avoid a circular dependency between
 and .

As noted in a FIXME comment, the std::inserter function has the wrong
signature because LWG issue 561 was never implemented. That is tracked
by PR 93904.

PR libstdc++/93884
* include/bits/iterator_concepts.h (__detail::__maybe_borrowed_range)
(__cust_access::_Begin, ranges::iterator_t): Move from ...
* include/bits/range_access.h: ... here.
* include/bits/stl_iterator.h (insert_iterator, inserter): Implement
C++20 changes from P0896R4.
* testsuite/24_iterators/insert_iterator/pr93884.cc: New test.

diff --git a/libstdc++-v3/include/bits/iterator_concepts.h b/libstdc++-v3/include/bits/iterator_concepts.h
index 08e622259b4..ae0c207d0d9 100644
--- a/libstdc++-v3/include/bits/iterator_concepts.h
+++ b/libstdc++-v3/include/bits/iterator_concepts.h
@@ -835,6 +835,90 @@ namespace ranges
   struct default_sentinel_t { };
   inline constexpr default_sentinel_t default_sentinel{};
 
+namespace ranges
+{
+  template
+extern const bool enable_borrowed_range;
+
+  namespace __detail
+  {
+// Part of the constraints of ranges::borrowed_range
+template
+  concept __maybe_borrowed_range
+	= is_lvalue_reference_v<_Tp>
+	  || enable_borrowed_range>;
+  } // namespace __detail
+
+  namespace __cust_access
+  {
+template
+  constexpr decay_t<_Tp>
+  __decay_copy(_Tp&& __t)
+  noexcept(is_nothrow_convertible_v<_Tp, decay_t<_Tp>>)
+  { return std::forward<_Tp>(__t); }
+
+template
+  concept __member_begin = requires(_Tp& __t)
+	{
+	  __t.begin();
+	  requires input_or_output_iterator>;
+	};
+
+void begin(auto&) = delete;
+void begin(const auto&) = delete;
+
+template
+  concept __adl_begin
+	= std::__detail::__class_or_enum>
+	&& requires(_Tp& __t)
+	{
+	  begin(__t);
+	  requires input_or_output_iterator>;
+	};
+
+struct _Begin
+{
+private:
+  template
+	static constexpr bool
+	_S_noexcept()
+	{
+	  if constexpr (is_array_v>)
+	return true;
+	  else if constexpr (__member_begin<_Tp>)
+	return noexcept(__decay_copy(std::declval<_Tp&>().begin()));
+	  else
+	return noexcept(__decay_copy(begin(std::declval<_Tp&>(;
+	}
+
+public:
+  template<__detail::__maybe_borrowed_range _Tp>
+	requires is_array_v> || __member_begin<_Tp>
+	  || __adl_begin<_Tp>
+	constexpr auto
+	operator()(_Tp&& __t) const noexcept(_S_noexcept<_Tp>())
+	{
+	  if constexpr (is_array_v>)
+	{
+	  static_assert(is_lvalue_reference_v<_Tp>);
+	  using _Up = remove_all_extents_t>;
+	  static_assert(sizeof(_Up) != 0, "not array of incomplete type");
+	  return __t + 0;
+	}
+	  else if constexpr (__member_begin<_Tp>)
+	return __t.begin();
+	  else
+	return begin(__t);
+	}
+};
+  } // namespace __cust_access
+
+  template
+using iterator_t
+  = decltype(__cust_access::_Begin{}(std::declval<_Tp&>()));
+
+} // namespace ranges
+
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace std
 #endif // C++20 library concepts
diff --git a/libstdc++-v3/include/bits/range_access.h b/libstdc++-v3/include/bits/range_access.h
index 8b276fd6625..7ae08f58f67 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -359,13 +359,6 @@ namespace ranges
 template>
   using __make_unsigned_like_t
 	= conditional_t<_MaxDiff, __max_size_type, make_unsigned_t<_Tp>>;
-
-// Part of the constraints of ranges::borrowed_range
-template
-  concept __maybe_borrowed_range
-	= is_lvalue_reference_v<_Tp>
-	  || enable_borrowed_range>;
-
   } // namespace __detail
 
   namespace __cust_access
@@ -373,64 +366,6 @@ namespace ranges
 using std::ranges::__detail::__maybe_borrowed_range;
 using std::__detail::__class_or_enum;
 
-template
-  constexpr decay_t<_Tp>
-  __decay_copy(_Tp&& __t)
-  noexcept(is_nothrow_convertible_v<_Tp, decay_t<_Tp>>)
-  { return std::forward<_Tp>(__t); }
-
-template
-  concept __member_begin = requires(_Tp& __t)
-	{
-	  { __decay_copy(__t.begin()) } -> input_or_output_iterator;
-	};
-
-void begin(auto&) = delete;
-void begin(const auto&) = delete;
-
-template
-  concept __adl_begin = __class_or_enum>
-	&& requires(_Tp& __t)
-	{
-	  { __decay_copy(begin(__t)) } -> input_or_output_iterator;
-	};
-
-struct _Begin
-{
-private:
-  template
-	static con

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.




On 2/24/20 11:08 AM, Jakub Jelinek wrote:

On Mon, Feb 24, 2020 at 11:04:55AM -0600, Bill Schmidt wrote:

+  if (clonei->simdlen
+  && (clonei->simdlen < 2
+      || clonei->simdlen > 1024

Assuming that clonei->simdlen matches "vector length" in the ABI, 1024 is
too large a number.  We can have at most 8 vector registers containing
a homogeneous aggregate, each having up to 16 elements, so the correct
limit would be 128.

Well, further arguments can be passed on the stack...


Well, ELFv2 doesn't define such a thing as a qualified homogeneous aggregate.
See rs6000_discover_homogeneous_aggregate and "Parameter Passing in
Registers" in ELFv2.  So the entire aggregate would be passed in memory,
not just the excess after 128 bytes.  I don't think this is necessarily
something we want to encourage in an interface intended to improve
performance.  Is there any reason we need to permit a larger value?  Do we
need to add this constraint to rs6000_simd_clone_usable?

Thanks,
Bill



Jakub

Re: libgo patch committed: Add hurd build tag

2020-02-24 Thread Ian Lance Taylor

On Mon, Feb 24, 2020 at 6:42 AM Ian Lance Taylor  wrote:
>
> This patch by Svante Signell adds a missing Hurd build tag.
> Bootstrapped and ran Go tests on x86_64-pc-linux-gnu.  Committed to
> mainline.

And another one, also tested and committed to mainline.

Ian
263aaf33b06604dcff4dab6e6b9b0fb2fe864211
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 47fbeaeda61..7dcb9ecb4fd 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-4e6402f3153fad368830ff3fe57c6302179de806
+658fe4f48374167bf8688e8dbd5f85eee155749e
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/go/internal/poll/fcntl_syscall.go 
b/libgo/go/internal/poll/fcntl_syscall.go
index d232e51411a..fb82b9bd53b 100644
--- a/libgo/go/internal/poll/fcntl_syscall.go
+++ b/libgo/go/internal/poll/fcntl_syscall.go
@@ -2,7 +2,7 @@
 // Use of this source code is governed by a BSD-style
 // license that can be found in the LICENSE file.
 
-// +build dragonfly freebsd linux netbsd openbsd
+// +build dragonfly freebsd hurd linux netbsd openbsd
 
 package poll

Re: [PATCH] c++: Some improvements to concept diagnostics

On Mon, 24 Feb 2020, Jason Merrill wrote:

> On 2/20/20 7:27 PM, Patrick Palka wrote:
> > This patch improves our concept diagnostics in two ways.  First, it sets a
> > more
> > precise location for the constraint expressions built in
> > finish_constraint_binary_op.  As a result, when a disjunction is unsatisfied
> > we
> > now print e.g.
> > 
> > .../include/bits/range_access.h:467:2: note: neither operand of the
> > disjunction is satisfied
> >466 |  requires is_bounded_array_v> ||
> > __member_end<_Tp>
> >|
> > 
> >467 |  || __adl_end<_Tp>
> >|  ^
> > 
> > instead of
> > 
> > .../include/bits/range_access.h:467:2: note: neither operand of the
> > disjunction is satisfied
> >467 |  || __adl_end<_Tp>
> >|  ^~
> 
> This hunk is OK.
> 
> > Second, this patch changes diagnose_atomic_constraint to pretty-print
> > unsatisfied atomic constraint expressions with their template arguments
> > substituted in (if doing so does not result in a trivial expression).  So
> > for
> > example we now emit
> > 
> > cpp2a/concepts-pr67719.C:9:8: note: the expression ‘((C() && C > int>()) && C())’ evaluated to ‘false’
> > 
> > instead of
> > 
> > cpp2a/concepts-pr67719.C:9:8: note: the expression ‘(... &&(C)())’
> > evaluated to ‘false’
> 
> Generally with templates we try to print the dependent form and then the
> arguments; pp_cxx_atomic_constraint already wants to do that, but we don't get
> there from here.  Perhaps pass 'map' instead of 'args' into
> diagnose_atomic_constraint, and then build a new ATOMIC_CONSTR for printing
> with %E?

That works really well.  I had to add handling of TYPE_ARGUMENT_PACK to
cxx_pretty_printer::type_id because otherwise an "unsupported
type_argument_pack" placeholder would get printed in these diagnostics
instead.  For consistency with the way we print TYPE_ARGUMENT_PACKs and
NONTYPE_ARGUMENT_PACKs elsewhere I also made
cxx_pretty_printer::expression print curly braces around a
NONTYPE_ARGUMENT_PACK.  Tested on x86_64-pc-linux-gnu, does this look
OK?

-- >8 --

gcc/cp/ChangeLog:

* constraint.cc (finish_constraint_binary_op): Set expr's location range
to the range of its operands.
(satisfy_atom): Pass MAP instead of ARGS to diagnose_atomic_constraint.
(diagnose_trait_expr): Take the instantiated parameter mapping MAP
instead of the corresponding template arguments ARGS and adjust body
accordingly.
(diagnose_requires_expr): Likewise.
(diagnose_atomic_constraint): Likewise.  When printing an atomic
constraint expression, print the instantiated parameter mapping
alongside it.
* cxx-pretty-print.cc (cxx_pretty_printer::expression)
[NONTYPE_ARGUMENT_PACK]: Print braces around a NONTYPE_ARGUMENT_PACK.
(cxx_pretty_printer::type_id): Handle TYPE_ARGUMENT_PACK.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/diagnostic2.C: New test.
* g++.dg/concepts/diagnostic3.C: New test.
---
 gcc/cp/constraint.cc| 33 -
 gcc/cp/cxx-pretty-print.c   | 17 +++
 gcc/testsuite/g++.dg/concepts/diagnostic2.C | 30 +++
 gcc/testsuite/g++.dg/concepts/diagnostic3.C | 29 ++
 4 files changed, 95 insertions(+), 14 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic2.C
 create mode 100644 gcc/testsuite/g++.dg/concepts/diagnostic3.C

diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 58044cd0f9d..4e6ed440211 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -155,14 +155,14 @@ finish_constraint_binary_op (location_t loc,
   if (!check_constraint_operands (loc, lhs, rhs))
 return error_mark_node;
   tree overload;
-  tree expr = build_x_binary_op (loc, code,
-lhs, TREE_CODE (lhs),
-rhs, TREE_CODE (rhs),
-&overload, tf_none);
+  cp_expr expr = build_x_binary_op (loc, code,
+   lhs, TREE_CODE (lhs),
+   rhs, TREE_CODE (rhs),
+   &overload, tf_none);
   /* When either operand is dependent, the overload set may be non-empty.  */
   if (expr == error_mark_node)
 return error_mark_node;
-  SET_EXPR_LOCATION (expr, loc);
+  expr.set_range (lhs.get_start (), rhs.get_finish ());
   return expr;
 }
 
@@ -2547,7 +2547,7 @@ satisfy_atom (tree t, tree args, subst_info info)
   /* Compute the value of the constraint.  */
   result = satisfaction_value (cxx_constant_value (result));
   if (result == boolean_false_node && info.noisy ())
-diagnose_atomic_constraint (t, args, info);
+diagnose_atomic_constraint (t, map, info);
 
   return cache.save (result);
 }
@@ -3056,9 +3056,10 @@ get_constraint_error_location (tree t)
 /* Emit a diagnostic for a failed trait.  */

[PATCH] c++: Add test for DR 1423, Convertibility of nullptr to bool.

DR 1423, which supersedes DR 654, says that you can't copy-init
a bool from a std::nullptr_t:

  bool b = nullptr;  // error

Conversely, it works with direct-initialization which is more
permissive than copy-initialization.

No code changes necessary since we handle it right.

Tested on x86_64-linux, ok for trunk?

2020-02-24  Marek Polacek  

DR 1423, Convertibility of nullptr to bool.
* g++.dg/DRs/dr1423.C: New test.
---
 gcc/testsuite/g++.dg/DRs/dr1423.C | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/DRs/dr1423.C

diff --git a/gcc/testsuite/g++.dg/DRs/dr1423.C 
b/gcc/testsuite/g++.dg/DRs/dr1423.C
new file mode 100644
index 000..d82baae9985
--- /dev/null
+++ b/gcc/testsuite/g++.dg/DRs/dr1423.C
@@ -0,0 +1,7 @@
+// DR 1423 - Convertibility of nullptr to bool.
+// { dg-do compile { target c++11 } }
+
+bool b = nullptr; // { dg-error "converting to .bool. from .std::nullptr_t. 
requires direct-initialization" }
+bool b2(nullptr);
+bool b3{nullptr};
+bool b4 = { nullptr }; // { dg-error "converting to .bool. from 
.std::nullptr_t. requires direct-initialization" }

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

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

2020-02-24 Thread GT

‐‐‐ Original Message ‐‐‐
On Monday, February 24, 2020 10:20 AM, Bill Schmidt  
wrote:

> So, I can answer a small amount of this, but I will say that overall, design
> or implementation documentation seems to be between lacking and nonexistent.
>
> This has to do with "#pragma omp simd" and providing the rules for vectorizing
> functions into calls to libmvec.  I tend to agree that it is a bit more like
> API than ABI, but we are just fitting into existing frameworks and using the
> same nomenclature.
>
> The ABI that Bert has produced for us is available at
> https://sourceware.org/glibc/wiki/HomePage?action=AttachFile&do=view&target=powerarchvectfuncabi.html.
>
> It is based on a similar document for x86.  I believe this is the most up-to-
> date version:
> https://software.intel.com/sites/default/files/managed/b4/c8/Intel-Vector-Function-ABI.pdf
>
> There's been ongoing work in the same area for AArch64, with the most recent
> version available here, I believe:
> https://developer.arm.com/docs/101129/latest
>
> I am not certain of the completion status of the AArch64 implementation.
> The libmvec implementation for Intel has been around for a long time.
>
> Hope that at least starts to help,
> Bill

Additionally, here is GLIBC's introduction of libmvec: 
https://sourceware.org/glibc/wiki/libmvec

Bert.

Re: [RFC PATCH v0] PPC64: Implement POWER Architecure Vector Function ABI.

2020-02-24 Thread Tulio Magno Quites Machado Filho

Jakub Jelinek  writes:

> On Sun, Feb 23, 2020 at 10:55:53AM -0600, Bill Schmidt wrote:
>> > If/when it becomes necessary to have 'c' variants of functions, then a new 
>> > version of
>> > the Vector Function ABI document will be created. And GLIBC and GCC 
>> > modifications to
>> > comply with that new ABI will be made then.
>> 
>> Though I'm usually uncomfortable with kicking the can down the road on these
>> sorts of things, I can probably be convinced in this case.  Tulio and I were
>> wondering why the libmvec interface doesn't make use of ifunc capability for
>> this sort of thing.  Something to look into when more advanced 
>> implementations
>> are added later, I guess, and a valid reason to not lock ourselves into the
>> 'c' ABI today.
>
> Tulio, any concerns?

No. I agree to remove 'c' from the ABI now.

Thanks!

-- 
Tulio Magno

[PATCH,rs6000] Fix documentation for __builtin_crypto_vpmsum* builtin functions.

2020-02-24 Thread Carl Love

GCC maintianers:

The following patch fixes three typos in the gcc documentation file for
the __builtin_crypto_vpmsum* builtin function.  The issue was reported
in

   Bug 91276 - Doc typos in __builtin_crypto_vpmsum*

Please let me know if the patch is OK for mainline.

Thanks. 

Carl Love
 
---
PPC64, fix documentation for __builtin_crypto_vpmsum*
 builtin functions.

PR target/91276 - Doc typos in __builtin_crypto_vpmsum*

gcc/ChangeLog:

2020-02-24  Carl Love  

PR target/91276
* doc/extend.texi (PowerPC AltiVec/VSX  __builtin_crypto_vpmsum
Built-in Functions): Fix builtin name for function taking vector
unsigned short, vector unsigned int and vector unsigned long long
arguments.
---
 gcc/doc/extend.texi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ec99c38a6..a941cd5a1 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -20628,13 +20628,13 @@ vector unsigned long long __builtin_crypto_vpermxor 
(vector unsigned long long,
 vector unsigned char __builtin_crypto_vpmsumb (vector unsigned char,
vector unsigned char);
 
-vector unsigned short __builtin_crypto_vpmsumb (vector unsigned short,
+vector unsigned short __builtin_crypto_vpmsumh (vector unsigned short,
 vector unsigned short);
 
-vector unsigned int __builtin_crypto_vpmsumb (vector unsigned int,
+vector unsigned int __builtin_crypto_vpmsumw (vector unsigned int,
   vector unsigned int);
 
-vector unsigned long long __builtin_crypto_vpmsumb (vector unsigned long long,
+vector unsigned long long __builtin_crypto_vpmsumd (vector unsigned long long,
 vector unsigned long long);
 
 vector unsigned long long __builtin_crypto_vshasigmad (vector unsigned long 
long,
-- 
2.17.1

[PATCH] libstdc++: Implement integer-class types as defined in [iterator.concept.winc]

This implements signed and unsigned integer-class types, whose width is one bit
larger than the widest native signed and unsigned integral type respectively.
In our case this is either __int128 and unsigned __int128, or long long and
unsigned long long.

Internally, the two integer-class types are represented as a largest native
unsigned integral type plus one extra bit.  The signed integer-class type is
represented in two's complement form with the extra bit acting as the sign bit.

libstdc++-v3/ChangeLog:

* include/bits/iterator_concepts.h (ranges::__detail::__max_diff_type):
Remove definition, replace with forward declaration of class
__max_diff_type.
(ranges::__detail::__max_size_type): Remove definition, replace with
forward declaration of class __max_size_type.
(__detail::__is_integer_like): Accept __int128 and unsigned __int128.
(__detail::__is_signed_integer_like): Accept __int128.
* include/bits/range_access.h (__detail::__max_size_type): New class.
(__detail::__max_diff_type): New class.
(__detail::__max_size_type::__max_size_type): Define this constructor
out-of-line to break the cycle.
(__detail::__to_unsigned_like): New function.
(numeric_limits<__detail::__max_size_type>): New explicit 
specialization.
(numeric_limits<__detail::__max_diff_type>): New explicit 
specialization.
* testsuite/std/ranges/iota/differenc_type.cc: New test.
---
 libstdc++-v3/include/bits/iterator_concepts.h |  15 +-
 libstdc++-v3/include/bits/range_access.h  | 678 +-
 .../std/ranges/iota/difference_type.cc| 379 ++
 3 files changed, 1064 insertions(+), 8 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/iota/difference_type.cc

diff --git a/libstdc++-v3/include/bits/iterator_concepts.h 
b/libstdc++-v3/include/bits/iterator_concepts.h
index 08e622259b4..6eff0b82feb 100644
--- a/libstdc++-v3/include/bits/iterator_concepts.h
+++ b/libstdc++-v3/include/bits/iterator_concepts.h
@@ -482,20 +482,21 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   namespace ranges::__detail
   {
-#if __SIZEOF_INT128__
-using __max_diff_type = __int128;
-using __max_size_type = unsigned __int128;
-#else
-using __max_diff_type = long long;
-using __max_size_type = unsigned long long;
-#endif
+class __max_diff_type;
+class __max_size_type;
 
 template
   concept __is_integer_like = integral<_Tp>
+#if __SIZEOF_INT128__
+   || same_as<_Tp, __int128> || same_as<_Tp, unsigned __int128>
+#endif
|| same_as<_Tp, __max_diff_type> || same_as<_Tp, __max_size_type>;
 
 template
   concept __is_signed_integer_like = signed_integral<_Tp>
+#if __SIZEOF_INT128__
+   || same_as<_Tp, __int128>
+#endif
|| same_as<_Tp, __max_diff_type>;
 
   } // namespace ranges::__detail
diff --git a/libstdc++-v3/include/bits/range_access.h 
b/libstdc++-v3/include/bits/range_access.h
index 8b276fd6625..08140b5e77d 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -351,6 +351,628 @@ namespace ranges
 
   namespace __detail
   {
+// An unsigned integer-class type as per [iterator.concept.winc].
+class __max_size_type
+{
+public:
+  __max_size_type() = default;
+
+  template
+   constexpr
+   __max_size_type(_Tp __i) noexcept
+ : _M_val(__i), _M_msb(__i < 0)
+   { }
+
+  constexpr explicit
+  __max_size_type(const __max_diff_type& __d) noexcept;
+
+  template
+   constexpr explicit operator _Tp() const noexcept
+   { return _M_val; }
+
+  constexpr explicit
+  operator bool() const noexcept
+  { return _M_val != 0 || _M_msb != 0; }
+
+  constexpr __max_size_type
+  operator+() const noexcept
+  { return *this; }
+
+  constexpr __max_size_type
+  operator~() const noexcept
+  { return __max_size_type{~_M_val, !_M_msb}; }
+
+  constexpr __max_size_type
+  operator-() const noexcept
+  { return operator~() + 1; }
+
+  constexpr __max_size_type&
+  operator+=(const __max_size_type& __r) noexcept
+  {
+   const auto __sum = _M_val + __r._M_val;
+   const bool __overflow = (__sum < _M_val);
+   _M_msb = _M_msb ^ __r._M_msb ^ __overflow;
+   _M_val = __sum;
+   return *this;
+  }
+
+  constexpr __max_size_type&
+  operator-=(const __max_size_type& __r) noexcept
+  { return *this += -__r; }
+
+  constexpr __max_size_type&
+  operator*=(__max_size_type __r) noexcept
+  {
+   const bool __lsb = _M_val & 1;
+   const bool __rlsb = __r._M_val & 1;
+
+   constexpr auto __threshold = __rep(1) << (__rep_bits / 2 - 1);
+   if (!_M_msb && !__r._M_msb
+   && _M_val < __threshold && __r._M_val < __threshold) [[likely]]
+ _M_val = _M_val * __r._M_val;
+   else
+ {
+   *this >>= 1;
+   __r >>= 1;

[PATCH] c++: Fix ICE with static_cast when converting from int[] [PR93862]

This ICEs since my patch for P0388, which allowed conversions to arrays
of unknown bound, but not the reverse, so these two static_casts are
ill-formed.

[expr.static.cast]/3 says that "cv1 T1" and "cv2 T2" have to be
reference-compatible and the comment in build_static_cast_1 says it too
but then we actually use reference_related_p...  Fixed thus.

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

2020-02-24  Marek Polacek  

PR c++/93862 - ICE with static_cast when converting from int[].
* call.c (reference_compatible_p): No longer static.
* cp-tree.h (reference_compatible_p): Declare.
* typeck.c (build_static_cast_1): Use reference_compatible_p instead
if reference_related_p.

* g++.dg/cpp0x/rv-cast7.C: New test.
---
 gcc/cp/call.c | 3 +--
 gcc/cp/cp-tree.h  | 1 +
 gcc/cp/typeck.c   | 2 +-
 gcc/testsuite/g++.dg/cpp0x/rv-cast7.C | 6 ++
 4 files changed, 9 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/rv-cast7.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 7a7f07c9630..e07ee85c06e 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -204,7 +204,6 @@ static struct z_candidate *add_candidate
 conversion **, tree, tree, int, struct rejection_reason *, int);
 static tree source_type (conversion *);
 static void add_warning (struct z_candidate *, struct z_candidate *);
-static bool reference_compatible_p (tree, tree);
 static conversion *direct_reference_binding (tree, conversion *);
 static bool promoted_arithmetic_type_p (tree);
 static conversion *conditional_conversion (tree, tree, tsubst_flags_t);
@@ -1554,7 +1553,7 @@ reference_related_p (tree t1, tree t2)
 
 /* Returns nonzero if T1 is reference-compatible with T2.  */
 
-static bool
+bool
 reference_compatible_p (tree t1, tree t2)
 {
   /* [dcl.init.ref]
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index c1aafa1de3a..140d5d88b61 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6357,6 +6357,7 @@ extern tree make_temporary_var_for_ref_to_temp(tree, 
tree);
 extern bool type_has_extended_temps(tree);
 extern tree strip_top_quals(tree);
 extern bool reference_related_p(tree, tree);
+extern bool reference_compatible_p (tree, tree);
 extern int remaining_arguments (tree);
 extern tree perform_implicit_conversion(tree, tree, 
tsubst_flags_t);
 extern tree perform_implicit_conversion_flags  (tree, tree, tsubst_flags_t, 
int);
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index c0c98dad980..103a1a439ec 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -7383,7 +7383,7 @@ build_static_cast_1 (location_t loc, tree type, tree 
expr, bool c_cast_p,
   if (TYPE_REF_P (type)
   && TYPE_REF_IS_RVALUE (type)
   && (clk = real_lvalue_p (expr))
-  && reference_related_p (TREE_TYPE (type), intype)
+  && reference_compatible_p (TREE_TYPE (type), intype)
   && (c_cast_p || at_least_as_qualified_p (TREE_TYPE (type), intype)))
 {
   if (processing_template_decl)
diff --git a/gcc/testsuite/g++.dg/cpp0x/rv-cast7.C 
b/gcc/testsuite/g++.dg/cpp0x/rv-cast7.C
new file mode 100644
index 000..0eea24f9e85
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/rv-cast7.C
@@ -0,0 +1,6 @@
+// PR c++/93862 - ICE with static_cast when converting from int[].
+// { dg-do compile { target c++11 } }
+
+int(&&intu_rvref)[]{1,2,3,4};
+int(&int4_lvref)[4] = static_cast(intu_rvref); // { dg-error 
"invalid .static_cast." }
+int(&&int4_rvref)[4] = static_cast(intu_rvref); // { dg-error 
"invalid .static_cast." }

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

Re: [PATCH] c++: Fix ICE with static_cast when converting from int[] [PR93862]

On Mon, Feb 24, 2020 at 03:41:47PM -0500, Marek Polacek wrote:
> This ICEs since my patch for P0388, which allowed conversions to arrays
> of unknown bound, but not the reverse, so these two static_casts are
> ill-formed.
> 
> [expr.static.cast]/3 says that "cv1 T1" and "cv2 T2" have to be
> reference-compatible and the comment in build_static_cast_1 says it too
> but then we actually use reference_related_p...  Fixed thus.
> 
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
> 
> 2020-02-24  Marek Polacek  
> 
>   PR c++/93862 - ICE with static_cast when converting from int[].
>   * call.c (reference_compatible_p): No longer static.
>   * cp-tree.h (reference_compatible_p): Declare.
>   * typeck.c (build_static_cast_1): Use reference_compatible_p instead
>   if reference_related_p.

(Consider this typo fixed.)

Marek

Re: [PING^2][PATCH] Fix documentation of -mpoke-function-name ARM option

2020-02-24 Thread Sandra Loosemore


On 2/20/20 3:08 PM, Jérémy Lefaure wrote:

Hello,

Ping for https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01081.html.

Thank you,
Jérémy

On Sun, Dec 15, 2019 at 07:20:26PM +0100, Jérémy Lefaure wrote:

Hi!

Since in ARM state the value of PC is the address of the current
instruction plus 8 bytes, the code inspecting the value of PC stored at
FP + 0 should look at location PC - 16 : PC - 8 points to the stmfd
instruction, PC - 16 points two words before, where the top 8 bits are
set.

gcc/
2019-12-14  Jérémy Lefaure 

* config/arm/arm.c (-mpoke-function-name): Fix documentation in comment.
* doc/invoke.texi (-mpoke-function-name): Fix documentation.





The patch looks OK to me from a documentation point of view, but I'm no 
expert about the technical correctness of the change.  Maybe an ARM 
maintainer can review this?


-Sandra

[PATCH] rs6000: Use -mno-pcrel for tests requiring TOC

These two test cases have assembly code that requires a valid TOC.
Make sure that we don't use the PC-relative ABI extensions that
violate this requirement.

Tested and verified on powerpc64le-unknown-linux-gnu.  Is this
okay for trunk?

Thanks,
Bill

2020-02-24  Bill Schmidt  

* gcc.target/powerpc/ppc64-abi-1.c: Compile with -mno-pcrel.
* gcc.target/powerpc/ppc64-abi-2.c: Likewise.
---
 gcc/testsuite/gcc.target/powerpc/ppc64-abi-1.c | 2 +-
 gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/ppc64-abi-1.c 
b/gcc/testsuite/gcc.target/powerpc/ppc64-abi-1.c
index 921c46862e2..731c0d880aa 100644
--- a/gcc/testsuite/gcc.target/powerpc/ppc64-abi-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/ppc64-abi-1.c
@@ -1,6 +1,6 @@
 /* { dg-do run { target { powerpc*-*-* && lp64 } } } */
 /* { dg-skip-if "" { *-*-darwin* } } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -mno-pcrel" } */
 
 typedef __builtin_va_list va_list;
 #define va_start(ap, arg) __builtin_va_start (ap, arg)
diff --git a/gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c 
b/gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c
index eb1df7a2dc9..b490fc3c2fd 100644
--- a/gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c
+++ b/gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c
@@ -1,5 +1,5 @@
 /* { dg-do run { target { { powerpc*-*-linux* && lp64 } && powerpc_altivec_ok 
} } } */
-/* { dg-options "-O2 -fprofile -mprofile-kernel -maltivec -mabi=altivec" } */
+/* { dg-options "-O2 -fprofile -mprofile-kernel -maltivec -mabi=altivec 
-mno-pcrel" } */
 #include 
 #include 
 #include 
-- 
2.17.1

Minor regression with recent IRA changes

2020-02-24 Thread Jeff Law




I don't think this is worth reverting the IRA changes.  BUt in case
someone raises the issue

The bit_shift test for visium will fail with the recent IRA changes.

The change in register allocation results in not needing a move at the
start of the function.  This is generally good :-)  However in this
test that move previously allowed removal of a cmp insn during cmpelim.
With no move insn we can't eliminate the compare and the test fails.

Interestingly enough after cmpelim runs we run CE for if-conversion
which happens to put a suitable reg->reg copy in the right place to be
used to eliminate the compare.  But alas there's no cmpelim after CE,
so not only did we fail to eliminate the compare, there's a move in the
final assembly that would have worked just fine for our purposes.

There's a number of cascading effects (reorg) that make the resulting
code somewhat harder to follow from a performance standpoint.  But I
believe ultimately it is a regression, but one I consider very minor
and not worth reverting the IRA changes for since better register
allocation in general should trump compare/test elimination from a
performance standpoint.

Jeff

Re: [PATCH] avoid user-constructible types in reshape_init_array (PR 90938)


On 2/21/20 7:41 PM, Martin Sebor wrote:

On 2/17/20 10:54 AM, Jason Merrill wrote:

On 2/14/20 9:06 PM, Martin Sebor wrote:

On 2/13/20 3:59 PM, Jason Merrill wrote:

On 2/12/20 9:21 PM, Martin Sebor wrote:

On 2/11/20 5:28 PM, Jason Merrill wrote:

On 2/11/20 9:00 PM, Martin Sebor wrote:

r270155, committed in GCC 9, introduced a transformation that strips
redundant trailing zero initializers from array initializer lists in
order to support string literals as template arguments.

The transformation neglected to consider the case of array elements
of trivial class types with user-defined conversion ctors and either
defaulted or deleted default ctors.  (It didn't occur to me that
those qualify as trivial types despite the user-defined ctors.)  As
a result, some valid initialization expressions are rejected when
the explicit zero-initializers are dropped in favor of the (deleted)
default ctor,


Hmm, a type with only a deleted default constructor is not 
trivial, that should have been OK already.


For Marek's test case:
   struct A { A () == delete; A (int) = delete; };

trivial_type_p() returns true (as does __is_trivial (A) in both GCC
and Clang).

[class.prop] says that

   A trivial class is a class that is trivially copyable and has one
   or more default constructors (10.3.4.1), all of which are either
   trivial or deleted and at least one of which is not deleted.

That sounds like A above is not trivial because it doesn't have
at least one default ctor that's not deleted, but both GCC and
Clang say it is.  What am I missing?  Is there some other default
constructor hiding in there that I don't know about?


and others are eliminated in favor of the defaulted
ctor instead of invoking a user-defined conversion ctor, leading to
wrong code.


This seems like a bug in type_initializer_zero_p; it shouldn't 
treat 0 as a zero initializer for any class.


That does fix it, and it seems like the right solution to me as well.
Thanks for the suggestion.  I'm a little unsure about the condition
I put in place though.

Attached is an updated patch rested on x86_64-linux.



-  if (sized_array_p && trivial_type_p (elt_type))
+  if (sized_array_p
+  && trivial_type_p (elt_type)
+  && !TYPE_NEEDS_CONSTRUCTING (elt_type))


Do we still need this change?  If so, please add a comment about the 
trivial_type_p bug.


The change isn't needed with my patch as it was, but it would still
be needed with the changes you suggested (even then it doesn't help
with the problem I describe below).




   if (TREE_CODE (init) != CONSTRUCTOR

I might change this to

  if (!CP_AGGREGATE_TYPE_P (type))
    return initializer_zerop (init);


This behaves differently in C++ 2a mode (the whole condition evaluates
to true for class A below) than in earlier modes and causes a failure
in the new array55.C test:


True, my suggestion above does the wrong thing for non-aggregate classes.


+  /* A class can only be initialized by a non-class type if it has
+ a ctor that converts from that type.  Such classes are excluded
+ since their semantics are unknown.  */
+  if (RECORD_OR_UNION_TYPE_P (type)
+  && !RECORD_OR_UNION_TYPE_P (TREE_TYPE (init)))
+    return false;


How about if (!SCALAR_TYPE_P (type)) here?

More broadly, it seems like doing this optimization here at all is 
questionable, since we don't yet know whether there's a valid 
conversion from the zero-valued initializer to the element type.  It 
would seem better to do it in process_init_constructor_array after the 
call to massage_init_elt, when we know the actual value of the element.


Yes, it seems that it might be better to do it there.  Attached
is a revised patch that implements your suggestion.  It's probably
more intrusive than you envisioned.  The stripping of the redundant
trailing initializers was straightforward.  Most of the rest of
the changes are only necessary to strip redundant initializers
for pointers to data members.

Martin

PS I'm uneasy about this patch this late in the cycle.  The bug I'm
fixing was introduced at the end of the last release, as a result
of a last minute patch not unlike this one.  It caused at least two
codegen regressions in all language modes.  I'd hate for this change
to have similar repercussions.


Hmm, yes, the last_distinct logic is a bit opaque.  Please rework it so 
you aren't changing i within the loop.


Jason

Re: [PATCH v3] c++: Fix value-init crash in template [PR93676]


On 2/20/20 11:52 AM, Marek Polacek wrote:

On Thu, Feb 20, 2020 at 12:13:07AM +, Jason Merrill wrote:

On 2/19/20 10:15 PM, Marek Polacek wrote:

On Fri, Feb 14, 2020 at 12:24:30AM +0100, Jason Merrill wrote:

On 2/11/20 8:54 PM, Marek Polacek wrote:

Since  we
attempt to value-initialize in build_vec_init even when there's no
initializer but the type has a constexpr default constructor.  But
build_value_init doesn't work in templates, so I think let's avoid
this scenario; we'll go to the normal build_aggr_init path then.

Bootstrapped/regtested on x86_64-linux, ok for trunk and branches?

PR c++/93676 - value-init crash in template.
* init.c (build_vec_init): Don't perform value-init in a template.


Hmm, we really shouldn't even be calling build_vec_init in a template, that
builds up a lot of garbage that we'll throw away at the end of build_new.


Ah, it's true that build_new will just creates a NEW_EXPR in a template and
doesn't use the result of build_new_1.  Unfortunately I can't just call
build_special_member_call like we do in build_new_1 since that crashes for
array types.


We should call it for strip_array_types (type).


Since build_special_member_call takes an expression we'd have to modify
its type which I think is not pretty, but it works.  Is this along the
lines you had in mind?





I think I still like the v1 patch best but if you're fine with the
following, then am I.

-- >8 --
Since  we
attempt to value-initialize in build_vec_init even when there's no
initializer but the type has a constexpr default constructor.  But
build_value_init doesn't work in templates, and build_vec_init
creates a lot of garbage that would not be used anyway, so don't
call it in a template.

PR c++/93676 - value-init crash in template.
* init.c (build_new_1): Don't call build_vec_init in a template.

* g++.dg/cpp0x/nsdmi-template19.C: New test.
---
  gcc/cp/init.c |  6 +-
  gcc/testsuite/g++.dg/cpp0x/nsdmi-template19.C | 13 +
  2 files changed, 18 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/nsdmi-template19.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index d480660445e..c60f332313a 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -3511,13 +3511,17 @@ build_new_1 (vec **placement, tree type, 
tree nelts,
  explicit_value_init_p = true;
}
  
-  if (processing_template_decl && explicit_value_init_p)

+  if (processing_template_decl)
{
  /* build_value_init doesn't work in templates, and we don't need
 the initializer anyway since we're going to throw it away and
 rebuild it at instantiation time, so just build up a single
 constructor call to get any appropriate diagnostics.  */
  init_expr = cp_build_fold_indirect_ref (data_addr);
+ /* Avoid an ICE when converting to a base in build_simple_base_path.
+We'll throw this all away anyway, and build_new will create
+a NEW_EXPR.  */
+ TREE_TYPE (init_expr) = strip_array_types (TREE_TYPE (init_expr));


instead of this, how about casting data_addr to elt_type* before 
cp_build_fold_indirect_ref?


Jason

Re: [PATCH] Generalize -fuse-ld= to support absolute path or arbitrary ld.linker

2020-02-24 Thread Fangrui Song via gcc-patches


On 2020-02-13, Fangrui Song wrote:

On 2020-02-09, Fangrui Song wrote:

PR driver/93645
* common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c (driver_handle_option): Likewise.
* collect2.c (main): Likewise.
---
gcc/ChangeLog   |  8 ++
gcc/collect2.c  | 67 -
gcc/common.opt  | 14 ++
gcc/doc/invoke.texi | 15 +++---
gcc/gcc.c   | 14 --
gcc/opts.c  |  4 +--
6 files changed, 57 insertions(+), 65 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index feb2d066d0b..6bcec12d841 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-02-09  Fangrui Song  
+
+   PR driver/93645
+   * common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
+   * opts.c (common_handle_option): Handle OPT_fuse_ld_.
+   * gcc.c (driver_handle_option): Likewise.
+   * collect2.c (main): Likewise.
+
2020-02-09  Uroš Bizjak  

* recog.c: Move pass_split_before_sched2 code in front of
diff --git a/gcc/collect2.c b/gcc/collect2.c
index 502d629141c..a3ef525a93b 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -859,18 +859,12 @@ main (int argc, char **argv)
   {
 USE_DEFAULT_LD,
 USE_PLUGIN_LD,
-  USE_GOLD_LD,
-  USE_BFD_LD,
-  USE_LLD_LD,
-  USE_LD_MAX
+  USE_LD
   } selected_linker = USE_DEFAULT_LD;
-  static const char *const ld_suffixes[USE_LD_MAX] =
+  static const char *const ld_suffixes[USE_LD] =
   {
 "ld",
-  PLUGIN_LD_SUFFIX,
-  "ld.gold",
-  "ld.bfd",
-  "ld.lld"
+  PLUGIN_LD_SUFFIX
   };
 static const char *const real_ld_suffix = "real-ld";
 static const char *const collect_ld_suffix = "collect-ld";
@@ -882,7 +876,7 @@ main (int argc, char **argv)
 static const char *const strip_suffix = "strip";
 static const char *const gstrip_suffix = "gstrip";

-  const char *full_ld_suffixes[USE_LD_MAX];
+  const char *full_ld_suffixes[USE_LD];
#ifdef CROSS_DIRECTORY_STRUCTURE
 /* If we look for a program in the compiler directories, we just use
the short name, since these directories are already system-specific.
@@ -924,6 +918,7 @@ main (int argc, char **argv)
 const char **ld1;
 bool use_plugin = false;
 bool use_collect_ld = false;
+  const char *use_ld = NULL;

 /* The kinds of symbols we will have to consider when scanning the
outcome of a first pass link.  This is ALL to start with, then might
@@ -948,7 +943,7 @@ main (int argc, char **argv)
#endif
 int i;

-  for (i = 0; i < USE_LD_MAX; i++)
+  for (i = 0; i < USE_LD; i++)
   full_ld_suffixes[i]
#ifdef CROSS_DIRECTORY_STRUCTURE
 = concat (target_machine, "-", ld_suffixes[i], NULL);
@@ -1041,12 +1036,11 @@ main (int argc, char **argv)
if (selected_linker == USE_DEFAULT_LD)
  selected_linker = USE_PLUGIN_LD;
  }
-   else if (strcmp (argv[i], "-fuse-ld=bfd") == 0)
- selected_linker = USE_BFD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=gold") == 0)
- selected_linker = USE_GOLD_LD;
-   else if (strcmp (argv[i], "-fuse-ld=lld") == 0)
- selected_linker = USE_LLD_LD;
+   else if (!strncmp (argv[i], "-fuse-ld=", 9))
+ {
+   use_ld = argv[i] + 9;
+   selected_linker = USE_LD;
+ }
else if (strncmp (argv[i], "-o", 2) == 0)
  {
/* Parse the output filename if it's given so that we can make
@@ -1152,8 +1146,7 @@ main (int argc, char **argv)
 /* Maybe we know the right file to use (if not cross).  */
 ld_file_name = 0;
#ifdef DEFAULT_LINKER
-  if (selected_linker == USE_BFD_LD || selected_linker == USE_GOLD_LD ||
-  selected_linker == USE_LLD_LD)
+  if (!ld_file_name && selected_linker == USE_LD)
   {
 char *linker_name;
# ifdef HOST_EXECUTABLE_SUFFIX
@@ -1168,15 +1161,13 @@ main (int argc, char **argv)
  if (! strcmp (&default_linker[len], HOST_EXECUTABLE_SUFFIX))
{
  default_linker[len] = '\0';
- linker_name = concat (default_linker,
-   &ld_suffixes[selected_linker][2],
+ linker_name = concat (default_linker, ".", use_ld,
HOST_EXECUTABLE_SUFFIX, NULL);
}
}
 if (linker_name == NULL)
# endif
-  linker_name = concat (DEFAULT_LINKER,
-   &ld_suffixes[selected_linker][2],
+  linker_name = concat (DEFAULT_LINKER, ".", use_ld,
NULL);
 if (access (linker_name, X_OK) == 0)
ld_file_name = linker_name;
@@ -1197,14 +1188,28 @@ main (int argc, char **argv)
 ld_file_name = find_a_file (&cpath, collect_ld_suffix, X_OK);
 use_collect_ld = ld_file_name != 0;
   }
-  /* Search the compiler directories for `ld'.  We have protection against
- recursive calls in find_a_file.  */
-  if (ld_file_name == 0)
-ld_

[PATCH] libstdc++: LWG 3397 basic_istream_view::iterator should not provide iterator_category

libstdc++-v3/ChangeLog:

LWG 3397 basic_istream_view::iterator should not provide
iterator_category
* include/std/ranges (basic_istream_view:_Iterator::iterator_category):
Rename to ...
(basic_istream_view:_Iterator::iterator_concept): ... this.
* testsuite/std/ranges/istream_view.cc: Augment test.
---
 libstdc++-v3/include/std/ranges  |  2 +-
 .../testsuite/std/ranges/istream_view.cc | 16 
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 442d1d08098..a7f4da957ef 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -971,7 +971,7 @@ namespace views
   struct _Iterator
   {
   public:
-   using iterator_category = input_iterator_tag;
+   using iterator_concept = input_iterator_tag;
using difference_type = ptrdiff_t;
using value_type = _Val;
 
diff --git a/libstdc++-v3/testsuite/std/ranges/istream_view.cc 
b/libstdc++-v3/testsuite/std/ranges/istream_view.cc
index 1729459bce3..f74e05e347a 100644
--- a/libstdc++-v3/testsuite/std/ranges/istream_view.cc
+++ b/libstdc++-v3/testsuite/std/ranges/istream_view.cc
@@ -68,10 +68,26 @@ test03()
   VERIFY( ranges::equal(v, (int[]){0,1,2,3,4}) );
 }
 
+template
+concept has_iterator_category = requires { typename T::iterator_category; };
+
+void
+test04()
+{
+  std::istringstream s("12345");
+  auto v = ranges::istream_view(s);
+  // LWG 3397
+  using It = ranges::iterator_t;
+  static_assert(!has_iterator_category);
+  static_assert(std::input_iterator);
+  static_assert(!std::forward_iterator);
+}
+
 int
 main()
 {
   test01();
   test02();
   test03();
+  test04();
 }
-- 
2.25.1.291.ge68e29171c

[PATCH] libstdc++: LWG 3292 iota_view is under-constrained

libstdc++-v3/ChangeLog:

LWG 3292 iota_view is under-constrained
* include/std/ranges (iota_view): Require that _Winc models semiregular
  as per LWG 3292.
* testsuite/std/ranges/iota/lwg3292_neg.cc: New test.
---
 libstdc++-v3/include/std/ranges   |  1 +
 .../testsuite/std/ranges/iota/lwg3292_neg.cc  | 40 +++
 2 files changed, 41 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/iota/lwg3292_neg.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 0b2057c9661..ab8fbaca38f 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -615,6 +615,7 @@ namespace ranges
   template
 requires std::__detail::__weakly_eq_cmp_with<_Winc, _Bound>
+  && semiregular<_Winc>
 class iota_view : public view_interface>
 {
 private:
diff --git a/libstdc++-v3/testsuite/std/ranges/iota/lwg3292_neg.cc 
b/libstdc++-v3/testsuite/std/ranges/iota/lwg3292_neg.cc
new file mode 100644
index 000..80c392729b3
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/ranges/iota/lwg3292_neg.cc
@@ -0,0 +1,40 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// 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
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+
+#include 
+#include 
+
+namespace ranges = std::ranges;
+namespace views = std::views;
+
+void
+test01()
+{
+  std::istringstream s("1 2 3 4 5");
+  auto v = ranges::istream_view(s);
+  auto i = v.begin();
+  static_assert(!std::semiregular);
+  auto o = views::iota(std::move(i));
+  static_assert(false); // { dg-error "" }
+}
+
+// { dg-prune-output "no match" }
+// { dg-prune-output "deduction failed" }
+// { dg-prune-output "constraint failure" }
-- 
2.25.1.291.ge68e29171c

[PATCH] libstdc++: LWG 3301 transform_view::iterator has incorrect iterator_category

libstdc++-v3/ChangeLog:

LWG 3301 transform_view::_Iterator has incorrect iterator_category
* include/std/ranges (transform_view::_Iterator::_S_iter_cat): Adjust
determination of iterator_category as per LWG 3301.
* testsuite/std/ranges/adaptors/transform.cc: Augment test.
---
 libstdc++-v3/include/std/ranges   | 16 +
 .../std/ranges/adaptors/transform.cc  | 24 +++
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index ab8fbaca38f..aed90e9710e 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1570,12 +1570,18 @@ namespace views
  static constexpr auto
  _S_iter_cat()
  {
-   using _Cat
-  = typename iterator_traits<_Base_iter>::iterator_category;
-   if constexpr (derived_from<_Cat, contiguous_iterator_tag>)
- return random_access_iterator_tag{};
+   using _Res = invoke_result_t<_Fp&, range_reference_t<_Base>>;
+   if constexpr (is_lvalue_reference_v<_Res>)
+ {
+   using _Cat
+ = typename iterator_traits<_Base_iter>::iterator_category;
+   if constexpr (derived_from<_Cat, contiguous_iterator_tag>)
+ return random_access_iterator_tag{};
+   else
+ return _Cat{};
+ }
else
- return _Cat{};
+ return input_iterator_tag{};
  }
 
  static constexpr decltype(auto)
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/transform.cc 
b/libstdc++-v3/testsuite/std/ranges/adaptors/transform.cc
index ad51fffb43d..0845febe2cf 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/transform.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/transform.cc
@@ -77,10 +77,34 @@ test03()
   VERIFY( ranges::equal(v, (int[]){1,2,3,4,5}) );
 }
 
+void
+test04()
+{
+  // LWG 3302
+{
+  auto f = [] (int x) { return x; };
+  int x[] = {1,2,3,4,5};
+  auto v = x | views::transform(f);
+  auto i = v.begin();
+  using Cat = decltype(i)::iterator_category;
+  static_assert(std::same_as);
+}
+
+{
+  auto f = [] (int &x) -> int& { return x; };
+  int x[] = {1,2,3,4,5};
+  auto v = x | views::transform(f);
+  auto i = v.begin();
+  using Cat = decltype(i)::iterator_category;
+  static_assert(std::derived_from);
+}
+}
+
 int
 main()
 {
   test01();
   test02();
   test03();
+  test04();
 }
-- 
2.25.1.291.ge68e29171c

[PATCH] libstdc++: LWG 3325 Constrain return type of transformation function for transform_view

libstdc++-v3/ChangeLog:

LWG 3325 Constrain return type of transformation function for
transform_view
* include/std/ranges (transform_view): Constrain the return type of the
transformation function as per LWG 3325.
* testsuite/std/ranges/adaptors/lwg3325_neg.cc: New test.
---
 libstdc++-v3/include/std/ranges   |  2 ++
 .../std/ranges/adaptors/lwg3325_neg.cc| 35 +++
 2 files changed, 37 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/lwg3325_neg.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index ffdd3367b05..442d1d08098 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -1540,6 +1540,8 @@ namespace views
   template
 requires view<_Vp> && is_object_v<_Fp>
   && regular_invocable<_Fp&, range_reference_t<_Vp>>
+  && std::__detail::__can_reference>>
 class transform_view : public view_interface>
 {
 private:
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/lwg3325_neg.cc 
b/libstdc++-v3/testsuite/std/ranges/adaptors/lwg3325_neg.cc
new file mode 100644
index 000..ac174714574
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/lwg3325_neg.cc
@@ -0,0 +1,35 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// 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
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+
+#include 
+
+namespace ranges = std::ranges;
+namespace views = std::views;
+
+void
+test01()
+{
+  auto f = [] (int x) { };
+  int x[] = {1};
+  auto v = ranges::transform_view{x, f}; // { dg-error "deduction failed|no 
match" }
+}
+
+// { dg-prune-output "constraint failure" }
+// { dg-prune-output "in requirements" }
-- 
2.25.1.291.ge68e29171c

[PATCH] libstdc++: LWG 3313 join_view::iterator::operator-- is incorrectly constrained

libstdc++-v3/ChangeLog:

LWG 3313 join_view::_Iterator::operator-- is incorrectly constrained
* include/std/ranges (join_view::_Iterator::operator--): Require that
range_reference_t<_Base> models common_range.
* testsuite/std/ranges/adaptors/lwg3313_neg.cc: New test.
---
 libstdc++-v3/include/std/ranges   |  2 +
 .../std/ranges/adaptors/lwg3313_neg.cc| 40 +++
 2 files changed, 42 insertions(+)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/adaptors/lwg3313_neg.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index aed90e9710e..ffdd3367b05 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -2399,6 +2399,7 @@ namespace views
  operator--()
requires _S_ref_is_glvalue && bidirectional_range<_Base>
  && bidirectional_range>
+ && common_range>
  {
if (_M_outer == ranges::end(_M_parent->_M_base))
  _M_inner = ranges::end(*--_M_outer);
@@ -2412,6 +2413,7 @@ namespace views
  operator--(int)
requires _S_ref_is_glvalue && bidirectional_range<_Base>
  && bidirectional_range>
+ && common_range>
  {
auto __tmp = *this;
--*this;
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/lwg3313_neg.cc 
b/libstdc++-v3/testsuite/std/ranges/adaptors/lwg3313_neg.cc
new file mode 100644
index 000..054df92554b
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/lwg3313_neg.cc
@@ -0,0 +1,40 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// 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
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do compile { target c++2a } }
+
+#include 
+#include 
+#include 
+
+namespace ranges = std::ranges;
+namespace views = std::views;
+
+void
+test01()
+{
+  int x[] = {1};
+  auto rx = ranges::subrange{std::counted_iterator(x,1), 
std::default_sentinel};
+  std::array y = {rx, rx, rx, rx, rx,};
+  auto v = y | views::join;
+  auto i = v.begin();
+  ++i;
+  ++i;
+  --i; // { dg-error "no match" }
+  i--; // { dg-error "" }
+}
-- 
2.25.1.291.ge68e29171c

[committed] analyzer: fix ICE with OFFSET_TYPE [PR 93899]

PR analyzer/93899 reports an ICE within make_region_for_type when
handling a param of type OFFSET_TYPE within
exploded_graph::add_function_entry.

This patch fixes the ICE by further generalizing the "give up on this
tree code" logic from
  r10-6667-gf76a88ebf089871dcce215aa0cb1956ccc060895
 for PR analyzer/93388 and
  r10-6695-g2e6233935c77b56a68e939c629702f960b8e6fb2
 for PR analyzer/93778
by replacing the gcc_unreachable in make_region_for_type with a return
of NULL, and handling this in add_region_for_type by notifying the ctxt.

Doing so means that numerous places that create regions now need to have
a context passed to them, so most of the patch is churn involved in
passing a context around to where it's needed.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6827-g3a25f345d1fbe2de8c12cae84b0c7d2a76c0b78e.

gcc/analyzer/ChangeLog:
PR analyzer/93899
* engine.cc
(impl_region_model_context::impl_region_model_context): Add logger
param.
* engine.cc (exploded_graph::add_function_entry): Create an
impl_region_model_context and pass it to the push_frame call.
Bail if the resulting state is invalid.
(exploded_graph::build_initial_worklist): Likewise.
(exploded_graph::build_initial_worklist): Handle the case where
add_function_entry fails.
* exploded-graph.h
(impl_region_model_context::impl_region_model_context): Add logger
param.
* region-model.cc (map_region::get_or_create): Add ctxt param and
pass it to add_region_for_type.
(map_region::can_merge_p): Pass NULL as a ctxt to call to
get_or_create.
(array_region::get_element): Pass ctxt to call to get_or_create.
(array_region::get_or_create): Add ctxt param and pass it to
add_region_for_type.
(root_region::push_frame): Pass ctxt to get_or_create calls.
(region_model::get_lvalue_1): Likewise.
(region_model::make_region_for_unexpected_tree_code): Assert that
ctxt is non-NULL.
(region_model::get_rvalue_1): Pass ctxt to get_svalue_for_fndecl
and get_svalue_for_label calls.
(region_model::get_svalue_for_fndecl): Add ctxt param and pass it
to get_region_for_fndecl.
(region_model::get_region_for_fndecl): Add ctxt param and pass it
to get_or_create.
(region_model::get_svalue_for_label): Add ctxt param and pass it
to get_region_for_label.
(region_model::get_region_for_label): Add ctxt param and pass it
to get_region_for_fndecl and get_or_create.
(region_model::get_field_region): Add ctxt param and pass it to
get_or_create_view and get_or_create.
(make_region_for_type): Replace gcc_unreachable with return NULL.
(region_model::add_region_for_type): Add ctxt param.  Handle a
return of NULL from make_region_for_type by calling
make_region_for_unexpected_tree_code.
(region_model::get_or_create_mem_ref): Pass ctxt to calls to
get_or_create_view.
(region_model::get_or_create_view): Add ctxt param and pass it to
add_region_for_type.
(selftest::test_state_merging): Pass ctxt to get_or_create_view.
* region-model.h (region_model::get_or_create): Add ctxt param.
(region_model::add_region_for_type): Likewise.
(region_model::get_svalue_for_fndecl): Likewise.
(region_model::get_svalue_for_label): Likewise.
(region_model::get_region_for_fndecl): Likewise.
(region_model::get_region_for_label): Likewise.
(region_model::get_field_region): Likewise.
(region_model::get_or_create_view): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/93899
* g++.dg/analyzer/pr93899.C: New test.
---
 gcc/analyzer/engine.cc  |  20 +++-
 gcc/analyzer/exploded-graph.h   |   3 +-
 gcc/analyzer/region-model.cc| 118 ++--
 gcc/analyzer/region-model.h |  25 +++--
 gcc/testsuite/g++.dg/analyzer/pr93899.C |   2 +
 5 files changed, 106 insertions(+), 62 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/analyzer/pr93899.C

diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index de6bf1d394f..7f8a4223eed 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -90,8 +90,9 @@ impl_region_model_context (exploded_graph &eg,
 impl_region_model_context::
 impl_region_model_context (program_state *state,
   state_change *change,
-  const extrinsic_state &ext_state)
-: m_eg (NULL), m_logger (NULL), m_enode_for_diag (NULL),
+  const extrinsic_state &ext_state,
+  logger *logger)
+: m_eg (NULL), m_logger (logger), m_enode_for_diag (NULL),
   m_old_state (NULL),
   m_new_state (state),
   m_change (change),
@@ -1829,7 +1830,11 @@ exploded_graph::add_function_entry

[committed] analyzer: disable the "taint" checker by default

PR analyzer/93032 tracks a false negative where we fail to report
FILE * leaks within zlib/contrib/minizip/mztools.c.

The underlying issue is a combinatorial explosion of states within the
exploded graph.  In particular, the state of the "taint" checker is
exploding, leading to the analyzer bailing out.

I have a patch kit under construction that fixes the state explosion
issue enough for the "file" checker to report the leaks, but doing so
requires disabling the "taint" checker.  Given that the latter is more
of a proof-of-concept, this patch disables it by default, to stop it
breaking the other checkers.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r10-6828-gb3d788a2cd35c734a683444c976abe14afc5c1c1.

gcc/analyzer/ChangeLog:
PR analyzer/93032
* sm.cc (make_checkers): Require the "taint" checker to be
explicitly enabled.

gcc/ChangeLog:
PR analyzer/93032
* doc/invoke.texi (-Wnanalyzer-tainted-array-index): Note that
-fanalyzer-checker=taint is also required.
(-fanalyzer-checker=): Note that providing this option enables the
given checker, and doing so may be required for checkers that are
disabled by default.

gcc/testsuite/ChangeLog:
PR analyzer/93032
* gcc.dg/analyzer/pr93382.c: Add "-fanalyzer-checker=taint".
* gcc.dg/analyzer/taint-1.c: Likewise.
---
 gcc/analyzer/sm.cc  |  5 -
 gcc/doc/invoke.texi | 12 +---
 gcc/testsuite/gcc.dg/analyzer/pr93382.c |  2 ++
 gcc/testsuite/gcc.dg/analyzer/taint-1.c |  2 ++
 4 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/gcc/analyzer/sm.cc b/gcc/analyzer/sm.cc
index e94c691c16c..b1f156fecc9 100644
--- a/gcc/analyzer/sm.cc
+++ b/gcc/analyzer/sm.cc
@@ -111,7 +111,10 @@ make_checkers (auto_delete_vec  &out, 
logger *logger)
 {
   out.safe_push (make_malloc_state_machine (logger));
   out.safe_push (make_fileptr_state_machine (logger));
-  out.safe_push (make_taint_state_machine (logger));
+  /* The "taint" checker must be explicitly enabled (as it currently
+ leads to state explosions that stop the other checkers working).  */
+  if (flag_analyzer_checker)
+out.safe_push (make_taint_state_machine (logger));
   out.safe_push (make_sensitive_state_machine (logger));
   out.safe_push (make_signal_state_machine (logger));
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3591404055b..11ff45ed23e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -6629,8 +6629,9 @@ no longer exists, and likely lead to a crash (or worse).
 @item -Wno-analyzer-tainted-array-index
 @opindex Wanalyzer-tainted-array-index
 @opindex Wno-analyzer-tainted-array-index
-This warning requires @option{-fanalyzer}, which enables it; use
-@option{-Wno-analyzer-tainted-array-index} to disable it.
+This warning requires both @option{-fanalyzer} and
+@option{-fanalyzer-checker=taint} to enable it;
+use @option{-Wno-analyzer-tainted-array-index} to disable it.
 
 This diagnostic warns for paths through the code in which a value
 that could be under an attacker's control is used as the index
@@ -8436,7 +8437,12 @@ call site, and that are sufficiently complicated (as per
 
 @item -fanalyzer-checker=@var{name}
 @opindex fanalyzer-checker
-Restrict the analyzer to run just the named checker.
+Restrict the analyzer to run just the named checker, and enable it.
+
+Some checkers are disabled by default (even with @option{-fanalyzer}),
+such as the @code{taint} checker that implements
+@option{-Wanalyzer-tainted-array-index}, and this option is required
+to enable them.
 
 @item -fanalyzer-fine-grained
 @opindex fanalyzer-fine-grained
diff --git a/gcc/testsuite/gcc.dg/analyzer/pr93382.c 
b/gcc/testsuite/gcc.dg/analyzer/pr93382.c
index 7d18d16e444..dae32f5a2bb 100644
--- a/gcc/testsuite/gcc.dg/analyzer/pr93382.c
+++ b/gcc/testsuite/gcc.dg/analyzer/pr93382.c
@@ -1,3 +1,5 @@
+/* { dg-additional-options "-fanalyzer-checker=taint" } */
+
 typedef __SIZE_TYPE__ size_t;
 
 int idx;
diff --git a/gcc/testsuite/gcc.dg/analyzer/taint-1.c 
b/gcc/testsuite/gcc.dg/analyzer/taint-1.c
index 293ce286819..549e2660284 100644
--- a/gcc/testsuite/gcc.dg/analyzer/taint-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/taint-1.c
@@ -1,3 +1,5 @@
+/* { dg-additional-options "-fanalyzer-checker=taint" } */
+
 #include 
 #include 
 #include 
-- 
2.21.0

Re: [PATCH] libstdc++: LWG 3301 transform_view::iterator has incorrect iterator_category

On Mon, 24 Feb 2020, Patrick Palka wrote:

> libstdc++-v3/ChangeLog:
> 
>   LWG 3301 transform_view::_Iterator has incorrect iterator_category
>   * include/std/ranges (transform_view::_Iterator::_S_iter_cat): Adjust
>   determination of iterator_category as per LWG 3301.
>   * testsuite/std/ranges/adaptors/transform.cc: Augment test.
> ---
>  libstdc++-v3/include/std/ranges   | 16 +
>  .../std/ranges/adaptors/transform.cc  | 24 +++
>  2 files changed, 35 insertions(+), 5 deletions(-)
> 
> diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
> index ab8fbaca38f..aed90e9710e 100644
> --- a/libstdc++-v3/include/std/ranges
> +++ b/libstdc++-v3/include/std/ranges
> @@ -1570,12 +1570,18 @@ namespace views
> static constexpr auto
> _S_iter_cat()
> {
> - using _Cat
> -  = typename iterator_traits<_Base_iter>::iterator_category;
> - if constexpr (derived_from<_Cat, contiguous_iterator_tag>)
> -   return random_access_iterator_tag{};
> + using _Res = invoke_result_t<_Fp&, range_reference_t<_Base>>;

Consider this line fixed to use 'typename'.

> + if constexpr (is_lvalue_reference_v<_Res>)
> +   {
> + using _Cat
> +   = typename iterator_traits<_Base_iter>::iterator_category;
> + if constexpr (derived_from<_Cat, contiguous_iterator_tag>)
> +   return random_access_iterator_tag{};
> + else
> +   return _Cat{};
> +   }
>   else
> -   return _Cat{};
> +   return input_iterator_tag{};
> }
>  
> static constexpr decltype(auto)
> diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/transform.cc 
> b/libstdc++-v3/testsuite/std/ranges/adaptors/transform.cc
> index ad51fffb43d..0845febe2cf 100644
> --- a/libstdc++-v3/testsuite/std/ranges/adaptors/transform.cc
> +++ b/libstdc++-v3/testsuite/std/ranges/adaptors/transform.cc
> @@ -77,10 +77,34 @@ test03()
>VERIFY( ranges::equal(v, (int[]){1,2,3,4,5}) );
>  }
>  
> +void
> +test04()
> +{
> +  // LWG 3302

Consider this comment fixed to say 3301.

[PATCH] avoid -Wredundant-tags on a first declaration in use (PR 93824)

2020-02-24 Thread Martin Sebor


-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also somewhat improves the detection
of both issues in template declarations (though more work is still
needed there).

Tested on x86_64-linux.

Martin
PR c++/93824 - bogus -Wredundant-tags on a first declaration in use
PR c++/93810 - missing -Wmismatched-tags and -Wredundant-tags on a typedef of an implicit class template specialization

gcc/cp/ChangeLog:

	PR c++/93824
	PR c++/93810
	* parser.c (cp_parser_check_class_key): Move code...
	(class_decl_loc_t::add): ...to here.  Add parameters.  Avoid issuing
	-Wredundant-tags on first-time declarations in other declarators.
	(class_decl_loc_t::diag_mismatched_tags): Also expect to be called
	when -Wredundant-tags is enabled.

gcc/testsuite/ChangeLog:

	PR c++/93824
	PR c++/93810
	* g++.dg/warn/Wmismatched-tags-3.C: New test.
	* g++.dg/warn/Wredundant-tags-3.C: Remove xfails.
	* g++.dg/warn/Wredundant-tags-6.C: New test.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index ca85d899427..3cf2f2d8b34 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30924,8 +30924,9 @@ class class_decl_loc_t
   /* Issues -Wmismatched-tags for all classes.  */
   static void diag_mismatched_tags ();
 
-  /* Adds TYPE_DECL to the collection of class decls.  */
-  static void add (tree, tag_types, bool, bool);
+  /* Adds TYPE_DECL to the collection of class decls and diagnoses
+ redundant tags (if -Wredundant-tags is enabled).  */
+  static void add (cp_parser *, location_t, tag_types, tree, bool, bool);
 
   /* Either adds this decl to the collection of class decls
  or diagnoses it, whichever is appropriate.  */
@@ -31021,6 +31022,19 @@ cp_parser_check_class_key (cp_parser *parser, location_t key_loc,
   && class_key != union_type)
 return;
 
+  class_decl_loc_t::add (parser, key_loc, class_key, type, def_p, decl_p);
+}
+
+/* Adds TYPE to the collection of class decls and diagnoses redundant
+   tags (if -Wredundant-tags is enabled).
+   DEF_P is expected to be set for a definition of class TYPE.  DECL_P
+   is set for a declaration of class TYPE and clear for a reference to
+   it that is not a declaration of it.  */
+
+void
+class_decl_loc_t::add (cp_parser *parser, location_t key_loc,
+		   tag_types class_key, tree type, bool def_p, bool decl_p)
+{
   tree type_decl = TYPE_MAIN_DECL (type);
   tree name = DECL_NAME (type_decl);
   /* Look up the NAME to see if it unambiguously refers to the TYPE
@@ -31032,7 +31046,10 @@ cp_parser_check_class_key (cp_parser *parser, location_t key_loc,
   /* The class-key is redundant for uses of the CLASS_TYPE that are
  neither definitions of it nor declarations, and for which name
  lookup returns just the type itself.  */
-  bool key_redundant = !def_p && !decl_p && decl == type_decl;
+  bool key_redundant = (!def_p && !decl_p
+			&& (decl == type_decl
+			|| TREE_CODE (decl) == TEMPLATE_DECL
+			|| TYPE_BEING_DEFINED (type)));
 
   if (key_redundant
   && class_key != class_type
@@ -31050,29 +31067,8 @@ cp_parser_check_class_key (cp_parser *parser, location_t key_loc,
 	key_redundant = false;
 }
 
-  if (key_redundant)
-{
-  gcc_rich_location richloc (key_loc);
-  richloc.add_fixit_remove (key_loc);
-  warning_at (&richloc, OPT_Wredundant_tags,
-		  "redundant class-key %qs in reference to %q#T",
-		  class_key == union_type ? "union"
-		  : class_key == record_type ? "struct" : "class",
-		  type);
-}
-
-  if (seen_as_union || !warn_mismatched_tags)
-return;
-
-  class_decl_loc_t::add (type_decl, class_key, key_redundant, def_p);
-}
-
-/* Adds TYPE_DECL to the collection of class decls.  */
-
-void
-class_decl_loc_t::add (tree type_decl, tag_types class_key, bool redundant,
-		   bool def_p)
-{
+  /* Set if a declaration of TYPE has previously been seen or if it
+ must exist in a precompiled header.  */
   bool exist;
   class_decl_loc_t *rdl = &class2loc.get_or_insert (type_decl, &exist);
   if (!exist)
@@ -31082,30 +31078,51 @@ class_decl_loc_t::add (tree type_decl, tag_types class_key, bool redundant,
 	{
 	  /* TYPE_DECL is the first declaration or definition of the type
 	 (outside precompiled headers -- see below).  Just create
-	 a new entry for it.  */
+	 a new entry for it and return unless it's a declaration
+	 involving a template that may need to be diagnosed by
+	 -Wredundant-tags.  */
 	  *rdl = class_decl_loc_t (class_key, false, def_p);
-	  return;
+	  if (TREE_CODE (decl) != TEMPLATE_DECL)
+	return;
+	}
+  else
+	{
+	  /* TYPE was previously defined in some unknown precompiled hdeader.
+

Dead code in fortran/simplify.c

2020-02-24 Thread Steve Kargl

Dead code is probably not the right description.
Something like 'result that is not used' is better.
In event, the patch removes 3 useless lines.
Please commit.

Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c  (revision 280157)
+++ gcc/fortran/simplify.c  (working copy)
@@ -1774,11 +1792,6 @@ degrees_f (mpfr_t x, mpfr_rnd_t rnd_mode)
 {
   mpfr_t tmp;
   mpfr_init (tmp);
-
-  /* Set x = x % 2pi to avoid offsets with large angles.  */
-  mpfr_const_pi (tmp, rnd_mode);
-  mpfr_mul_ui (tmp, tmp, 2, rnd_mode);
-  mpfr_fmod (tmp, x, tmp, rnd_mode);
 
   /* Set x = x * 180.  */
   mpfr_mul_ui (x, x, 180, rnd_mode);

-- 
Steve

Re: [patch, fortran] PR93486 - ICE on valid with nested submodules and long submodule names

2020-02-24 Thread Andrew Benson

*ping*

On Tuesday, January 28, 2020 4:45:59 PM PST Andrew Benson wrote:
> I opened PR93486 for this problem:
> 
> The following causes an ICE with revision
> ad690d79cfbb905c5546c9333c5fd089d906505b:
> 
> module ivs
>   interface l
>  module procedure l_
>   end interface l
> contains
>   function l_()
>   end function l_
> end module ivs
> 
> module aModeratleyLongModuleName
>   use ivs
>   interface
>  module subroutine cmo()
>  end subroutine cmo
>   end interface
> end module aModeratleyLongModuleName
> 
> submodule (aModeratleyLongModuleName)
> aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill
> contains
>   module procedure cmo
>   end procedure cmo
> end submodule aNameForASubmoduleThatIsVeryLongButWhichIsLegalStill
> 
> submodule
> (aModeratleyLongModuleName:aNameForASubmoduleThatIsVeryLongButWhichIsLegalSt
> ill) sb
> end submodule sb
> 
> submodule (aModeratleyLongModuleName:sb) sc
> end submodule sc
> 
> 
> $ gfortran -v
> Using built-in specs.
> COLLECT_GCC=gfortran
> COLLECT_LTO_WRAPPER=/data001/abenson/Galacticus/Tools_Devel_Install/bin/../
> libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/
> Tools_Devel --enable-languages=c,c++,fortran --disable-multilib
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 10.0.1 20200128 (experimental) (GCC)
> 
> 
> $ gfortran -c test.F90 -o test.o
> f951: internal compiler error: Segmentation fault
> 0xe1bc9f crash_signal
> ../../gcc-git/gcc/toplev.c:328
> 0x7f98119c71ef ???
>
> /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/
> sysv/linux/x86_64/sigaction.c:0
> 0x84b3f0 gfc_use_modules()
> ../../gcc-git/gcc/fortran/module.c:7315
> 0x85acc8 use_modules
> ../../gcc-git/gcc/fortran/parse.c:114
> 0x866daa parse_module
> ../../gcc-git/gcc/fortran/parse.c:6111
> 0x86733c gfc_parse_file()
> ../../gcc-git/gcc/fortran/parse.c:6428
> 0x8b780f gfc_be_parse_file
> ../../gcc-git/gcc/fortran/f95-lang.c:210
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> 
> The ICE goes away if the module and/or submodule names are made shorter.
> 
> The problem is caused when loading (generic or operator) interfaces from a
> module file. The module name can include the submodule name, so a size of
> 2*GFC_MAX_SYMBOL_LEN+2 is required to read this in.
> 
> The attached patch fixes this problem and regression tests cleanly *if* the
> patch for PR87103 is applied (otherwise that problem gets triggered by the
> new test case).
> 
> PR87103 has been a long-standing issue - there's a patch that works (either
> my original ugly fix, or the better fix proposed by Bernhard at https://
> gcc.gnu.org/ml/fortran/2018-09/msg00044.html ). It would be very nice to
> get one of these patches committed.
> 
> -Andrew


-- 

* Andrew Benson: http://users.obs.carnegiescience.edu/abenson/contact.html

* Galacticus: https://github.com/galacticusorg/galacticus

[committed] analyzer: fix -fdump-analyzer

This patch fixes a bug with -fdump-analyzer, which is meant to write
purely a dumpfile, but was erroneously sending part of the dump to
stderr.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as f2ca2088bc393a7d3d8eef4ff85cbe949db3cde0.

gcc/analyzer/ChangeLog:
* engine.cc (exploded_graph::get_or_create_node): Dump the
program_state to the pp, rather than to stderr.
---
 gcc/analyzer/engine.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 7f8a4223eed..45578f5111f 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -1866,7 +1866,7 @@ exploded_graph::get_or_create_node (const program_point 
&point,
   logger->end_log_line ();
   logger->start_log_line ();
   pp_string (pp, "state: ");
-  state.dump (m_ext_state, true);
+  state.dump_to_pp (m_ext_state, true, pp);
   logger->end_log_line ();
 }
 
-- 
2.21.0

Re: [PATCH] libstdc++: Implement integer-class types as defined in [iterator.concept.winc]