Re: Test cases for mixed structured/dynamic data lifetimes with OpenACC [PR92843]

[Thomas Schwinge]

Hi!

On 2020-04-10T16:44:42+0200, I wrote:
> On 2020-01-17T12:18:18-0800, Julian Brown  wrote:
>> This patch series provides fixes for some cases of mixing static and
>
> (It's "structured", not "static".)  ;-)

Of course, that should be reflected...

>   libgomp/
>   PR libgomp/92843
>   * testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1-lib.c:
>   New file.
>   [...]

... in the test cases, too.

See attached for what I pushed to master branch in commit
af4c92573dc462a17a6c345756889d28054ed591 "Rename
'libgomp.oacc-c-c++-common/static-dynamic-lifetimes-*' to
'libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-*' [PR92843]",
and to releases/gcc-9 branch in commit
a99a8431e670a6c0ac861d738249ff4d94d6552e "Rename
'libgomp.oacc-c-c++-common/static-dynamic-lifetimes-*' to
'libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-*' [PR92843]".


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From af4c92573dc462a17a6c345756889d28054ed591 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 13 Apr 2020 08:56:03 +0200
Subject: [PATCH] Rename 'libgomp.oacc-c-c++-common/static-dynamic-lifetimes-*'
 to 'libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-*' [PR92843]

Fix-up for commit be9862dd96945772ae0692bc95b37ec6dbcabda0 "Test cases for
mixed structured/dynamic data lifetimes with OpenACC [PR92843]": it's
"structured", not "static" data lifetimes/reference counters.

	libgomp/
	PR libgomp/92843
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1-lib.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-1-lib.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-1.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-1.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2-lib.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-2-lib.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-2.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-2.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3-lib.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-3-lib.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-3.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-3.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4-lib.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-4-lib.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-4.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-4.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5-lib.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-5-lib.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-5.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-5.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6-lib.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-6-lib.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-6.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-6.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7-lib.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-7-lib.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-7.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-7.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8-lib.c:
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-8-lib.c:
	... this.
	* testsuite/libgomp.oacc-c-c++-common/static-dynamic-lifetimes-8.c::
	Rename to...
	* testsuite/libgomp.oacc-c-c++-common/structured-dynamic-lifetimes-8.c:
	... this.
---
 libgomp/ChangeLog | 68 +++
 .../static-dynamic-lifetimes-5-lib.c  |  3 -
 .../static-dynamic-lifetimes-6-lib.c  |  3 -
 .../static-dynamic-lifetimes-7-lib.c  |  3 -
 .../static-dynamic-lifetimes-8-lib.c  |  3 -
 ...c => structured-dynamic-lifetimes-1-lib.c} |  2 +-
 ...s-1.c => structured-dynamic-lifetimes-1.c} |  5 +-
 ...c => structured-dynamic-lifetimes-2-lib.c} |  2 +-
 ...s-2.c => structured-dynamic-lifetimes-2.c} |  2 +-
 ...c => structured-dynamic-lifetimes-3-lib.c} |  2 +-
 ...s-3.c => structured-dynamic-lifetimes-3.c} |  2 +-
 ...c => structured-dynamic-

Re: [PATCH] x86: Restore the frame pointer in word_mode

[Uros Bizjak via Gcc-patches]

On Sun, Apr 12, 2020 at 11:28 PM H.J. Lu  wrote:
>
> We must restore the frame pointer in word_mode for eh_return epilogues
> since the upper 32 bits of RBP register can have any values.
>
> Tested on Linux/x32 and Linux/x86-64.  OK for master and backport to
> GCC 8/9 branches?
>
> Thanks.
>
> H.J.
> ---
> PR target/94556
> * config/i386/i386.c (ix86_expand_epilogue): Restore the frame
> pointer in word_mode for eh_return epilogues.
> ---
>  gcc/config/i386/i386.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index ca3b7dc06c2..f9c8f75b559 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -9052,8 +9052,14 @@ ix86_expand_epilogue (int style)
>   t = plus_constant (Pmode, t, m->fs.fp_offset - UNITS_PER_WORD);
>   emit_insn (gen_rtx_SET (sa, t));
>
> - t = gen_frame_mem (Pmode, hard_frame_pointer_rtx);
> - insn = emit_move_insn (hard_frame_pointer_rtx, t);
> + /* NB: eh_return epilogues must restore the frame pointer
> +in word_mode since the upper 32 bits of RBP register
> +can have any values.  */
> + t = gen_frame_mem (word_mode, hard_frame_pointer_rtx);
> + rtx frame_reg = hard_frame_pointer_rtx;
> + if (Pmode != word_mode)
> +   frame_reg = gen_rtx_REG (word_mode, REGNO (frame_reg));
> + insn = emit_move_insn (frame_reg, t);

I didn't test it myself, but it looks to me that you can use

"rtx frame_reg = gen_rtx_REG (word_mode, HARD_FRAME_POINTER_REGNUM);"

unconditionally, since gen_rtx_REG has some bypass code to return
hard_frame_pointer_rtx when appropriate.

I don't know x32 enough for a functional review, so LGTM with the above change.

Please wait a week before backporting the patch.

Thanks,
Uros.

>   /* Note that we use SA as a temporary CFA, as the return
>  address is at the proper place relative to it.  We
> @@ -9068,7 +9074,7 @@ ix86_expand_epilogue (int style)
>   add_reg_note (insn, REG_CFA_DEF_CFA,
> plus_constant (Pmode, sa, UNITS_PER_WORD));
>   ix86_add_queued_cfa_restore_notes (insn);
> - add_reg_note (insn, REG_CFA_RESTORE, hard_frame_pointer_rtx);
> + add_reg_note (insn, REG_CFA_RESTORE, frame_reg);
>   RTX_FRAME_RELATED_P (insn) = 1;
>
>   m->fs.cfa_reg = sa;
> --
> 2.25.2
>

[committed] d: Merge front-end with upstream dmd d0d4f02a0

[Iain Buclaw via Gcc-patches]

Hi,

This patch merges the D front-end implementation with upstream dmd
d0d4f02a0.

Removes the implementation of __traits(argTypes), which only supported
x86_64 targets.  The only use of this trait is an unused va_arg()
function, this has been removed as well.

Bootstrapped and regression tested on x86_64-linux-gnu, committed to
mainline.

Regards
Iain

---
gcc/d/ChangeLog:

2020-04-12  Iain Buclaw  

* Make-lang.in (D_FRONTEND_OBJS): Remove d/argtypes.o.
* d-target.cc (Target::toArgTypes): New function.

libphobos/ChangeLog:

2020-04-12  Iain Buclaw  

* libdruntime/core/stdc/stdarg.d: Remove run-time va_list template.
---
 gcc/d/Make-lang.in|   1 -
 gcc/d/d-target.cc |  12 +
 gcc/d/dmd/MERGE   |   2 +-
 gcc/d/dmd/argtypes.c  | 484 --
 gcc/d/dmd/dstruct.c   |   4 +-
 gcc/d/dmd/expressionsem.c |   4 +-
 gcc/d/dmd/target.h|   2 +
 .../gdc.test/runnable/testargtypes.d  | 113 
 libphobos/libdruntime/core/stdc/stdarg.d  | 160 --
 9 files changed, 19 insertions(+), 764 deletions(-)
 delete mode 100644 gcc/d/dmd/argtypes.c
 delete mode 100644 gcc/testsuite/gdc.test/runnable/testargtypes.d

diff --git a/gcc/d/Make-lang.in b/gcc/d/Make-lang.in
index 71dccad5a74..ac04d074aa5 100644
--- a/gcc/d/Make-lang.in
+++ b/gcc/d/Make-lang.in
@@ -59,7 +59,6 @@ D_FRONTEND_OBJS = \
d/access.o \
d/aliasthis.o \
d/apply.o \
-   d/argtypes.o \
d/arrayop.o \
d/attrib.o \
d/blockexit.o \
diff --git a/gcc/d/d-target.cc b/gcc/d/d-target.cc
index 7e11bd64abb..b2df2660579 100644
--- a/gcc/d/d-target.cc
+++ b/gcc/d/d-target.cc
@@ -410,3 +410,15 @@ Target::systemLinkage (void)
 {
   return LINKc;
 }
+
+/* Generate a TypeTuple of the equivalent types used to determine if a
+   function argument of the given type can be passed in registers.
+   The results of this are highly platform dependent, and intended
+   primarly for use in implementing va_arg() with RTTI.  */
+
+TypeTuple *
+Target::toArgTypes (Type *)
+{
+  /* Not implemented, however this is not currently used anywhere.  */
+  return NULL;
+}
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index 7f0140708c6..374ec119ecf 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-3e10e2dd29e583f1d94d84de5e4bd858e0303669
+d0d4f02a0c43a95ff7aee2e296bab57ba7d06bf4
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/argtypes.c b/gcc/d/dmd/argtypes.c
deleted file mode 100644
index bed1d4020ab..000
--- a/gcc/d/dmd/argtypes.c
+++ /dev/null
@@ -1,484 +0,0 @@
-
-/* Compiler implementation of the D programming language
- * Copyright (C) 2010-2019 by The D Language Foundation, All Rights Reserved
- * written by Walter Bright
- * http://www.digitalmars.com
- * Distributed under the Boost Software License, Version 1.0.
- * http://www.boost.org/LICENSE_1_0.txt
- * https://github.com/D-Programming-Language/dmd/blob/master/src/argtypes.c
- */
-
-#include "root/dsystem.h"
-#include "root/checkedint.h"
-
-#include "mars.h"
-#include "dsymbol.h"
-#include "mtype.h"
-#include "scope.h"
-#include "init.h"
-#include "expression.h"
-#include "attrib.h"
-#include "declaration.h"
-#include "template.h"
-#include "id.h"
-#include "enum.h"
-#include "import.h"
-#include "aggregate.h"
-#include "hdrgen.h"
-
-/
- * This breaks a type down into 'simpler' types that can be passed to a 
function
- * in registers, and returned in registers.
- * It's highly platform dependent.
- * Params:
- *  t = type to break down
- * Returns:
- *  tuple of types, each element can be passed in a register.
- *  A tuple of zero length means the type cannot be passed/returned in 
registers.
- */
-
-TypeTuple *toArgTypes(Type *t)
-{
-class ToArgTypes : public Visitor
-{
-public:
-TypeTuple *result;
-
-ToArgTypes()
-{
-result = NULL;
-}
-
-void visit(Type *)
-{
-// not valid for a parameter
-}
-
-void visit(TypeError *)
-{
-result = new TypeTuple(Type::terror);
-}
-
-void visit(TypeBasic *t)
-{
-Type *t1 = NULL;
-Type *t2 = NULL;
-switch (t->ty)
-{
-case Tvoid:
- return;
-
-case Tbool:
-case Tint8:
-case Tuns8:
-case Tint16:
-case Tuns16:
-case Tint32:
-case Tuns32:
-case Tfloat32:
-case Tint64:
-case Tuns64:
-case Tint128:
-case Tuns128:
-case Tfloat64:
-  

[PATCH PR94574] ICE during GIMPLE pass: ccp

[yangyang (ET)]

Hi,

  This is a simple fix for pr94574.

  testcase testsuite/gcc.target/aarch64/sve/acle/general/deref_1.c ICEs when 
testing GCC trunk with -O2 -msve-vector-bits=256 -march=armv8.2-a+sve. 

  There is a gimple statement before the ccp pass as follow:

  MEM[(svuint32_t *)&res] = _2;

  The ccp pass tries to convert this gimple into:

  _7 = VIEW_CONVERT_EXPR(_2);
  res_9 = BIT_INSERT_EXPR ;

  However,  the size of _7 is larger than res_8(D) , leading to a verify_gimple 
failure. Since the replaced bits of BIT_INSERT_EXPR are supposed to fully 
inside the container, before doing the above optimitzaion, a check shall be 
added.  

  With this fix, a MEM_REF which visits the address of a vector will be 
rewritten into a BIT_INSERT_EXPR only when the size of the vector is larger 
than the size of MEM_REF. In this way, this kind of ICE can be avoided.
  
  a test case with which this problem will be exposed more easily is extracted 
and added for this. Bootstrapped/regtested on both x86_64 and aarch64 Linux 
platform.  
  Any suggestion?

Thanks,
Yang Yang

gcc:
+2020-04-13  Yang Yang  
+
+   PR tree-optimization/94574
+   * tree-ssa.c (non_rewritable_lvalue_p): Add size check when analyzing
+   whether a vector-insert is rewritable using a BIT_INSERT_EXPR.
 
gcc/testsuite:
+2020-04-13  Yang Yang 
+
+   PR tree-optimization/94574
+   * gcc.dg/pr94574.c: New test.


pr94574-v0.patch
Description: pr94574-v0.patch

[COMMITTED] MSP430: Fix memory offsets used by %C and %D asm output operand modifiers

[Jozef Lawrynowicz]

The %C and %D operand modifiers are supposed to access the 3rd and 4th
words of a 64-bit value, so for memory references they need to offset
the given address by 4 and 6 bytes respectively. Currently they incorrectly
offset the address by 3 and 4 bytes respectively.

Committed the attached patch as obvious.
From 14f27ee6c97c585018882ac8f1f5f2d64618ba66 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Mon, 13 Apr 2020 10:28:01 +0100
Subject: [PATCH] MSP430: Fix memory offsets used by %C and %D asm output
 operand modifiers

The %C and %D operand modifiers are supposed to access the 3rd and 4th
words of a 64-bit value, so for memory references they need to offset
the given address by 4 and 6 bytes respectively.

gcc/ChangeLog:

2020-04-13  Jozef Lawrynowicz  

	* config/msp430/msp430.c (msp430_print_operand): Offset a %C memory
	reference by 4 bytes, and %D memory reference by 6 bytes.

gcc/testsuite/ChangeLog:

2020-04-13  Jozef Lawrynowicz  

	* gcc.target/msp430/operand-modifiers.c: New test.
---
 gcc/ChangeLog |  5 
 gcc/config/msp430/msp430.c|  4 +--
 gcc/testsuite/ChangeLog   |  4 +++
 .../gcc.target/msp430/operand-modifiers.c | 30 +++
 4 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/msp430/operand-modifiers.c

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f3a226cc711..c0ac32dccf6 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-13  Jozef Lawrynowicz  
+
+	* config/msp430/msp430.c (msp430_print_operand): Offset a %C memory
+	reference by 4 bytes, and %D memory reference by 6 bytes.
+
 2020-04-11  Uroš Bizjak  
 
 	PR target/94494
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index e0d2d732ade..96532740ac1 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -3492,7 +3492,7 @@ msp430_print_operand (FILE * file, rtx op, int letter)
   switch (GET_CODE (op))
 	{
 	case MEM:
-	  op = adjust_address (op, Pmode, 3);
+	  op = adjust_address (op, Pmode, 4);
 	  break;
 	case REG:
 	  op = gen_rtx_REG (Pmode, REGNO (op) + 2);
@@ -3510,7 +3510,7 @@ msp430_print_operand (FILE * file, rtx op, int letter)
   switch (GET_CODE (op))
 	{
 	case MEM:
-	  op = adjust_address (op, Pmode, 4);
+	  op = adjust_address (op, Pmode, 6);
 	  break;
 	case REG:
 	  op = gen_rtx_REG (Pmode, REGNO (op) + 3);
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 1343b8bec06..b1f232ec0e6 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2020-04-13  Jozef Lawrynowicz  
+
+	* gcc.target/msp430/operand-modifiers.c: New test.
+
 2020-04-12  Thomas Koenig  
 
 	PR fortran/94091
diff --git a/gcc/testsuite/gcc.target/msp430/operand-modifiers.c b/gcc/testsuite/gcc.target/msp430/operand-modifiers.c
new file mode 100644
index 000..ad0a5310839
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/operand-modifiers.c
@@ -0,0 +1,30 @@
+volatile unsigned long si = 0x89abcdef;
+volatile unsigned long long di = 0xfedcba9876543210;
+
+unsigned int a, b, c, d;
+
+int
+main (void)
+{
+  /* Check that %A and %B extract the low and high words of a 32-bit value,
+ respectively.  */
+  __asm__("mov %A1, %0\n" : "=m" (a) : "m" (si));
+  __asm__("mov %B1, %0\n" : "=m" (b) : "m" (si));
+  if (a != ((unsigned)si)
+  || b != ((unsigned)(si >> 16)))
+return 1;
+
+  /* Check that %A, %B, %C and %D extract the 1st, 2nd, 3rd and 4th words of a
+ 64-bit value, respectively.  */
+  __asm__("mov %A1, %0\n" : "=m" (a) : "m" (di));
+  __asm__("mov %B1, %0\n" : "=m" (b) : "m" (di));
+  __asm__("mov %C1, %0\n" : "=m" (c) : "m" (di));
+  __asm__("mov %D1, %0\n" : "=m" (d) : "m" (di));
+  if (a != ((unsigned)di)
+  || b != ((unsigned)(di >> 16))
+  || c != ((unsigned)(di >> 32))
+  || d != ((unsigned)(di >> 48)))
+return 1;
+
+  return 0;
+}
-- 
2.17.1

[COMMITTED] MSP430: Don't add offsets to addresses when emitting asm for post_inc

[Jozef Lawrynowicz]

Some insns, which operate on SImode operands, output assembler template
that comprise of multiple instructions using HImode operands. To access
the high word of an SImode operand, an operand selector '%H' is used to
offset the operand value by a constant amount.

When one of these HImode operands is a memory reference to a post_inc,
the address does not need to be offset, since the preceding instruction
has already offset the address to the correct value.

This fixes an ICE in change_address_1, at emit-rtl.c:2318 for
gcc.c-torture/execute/pr20527-1.c in the "-mlarge -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects" configuration.

This test generated the following insn, and the attempt to output the
high part of the post_inc address caused the ICE.
(set (reg:SI 6 R6)
 (minus:SI (reg:SI 6 R6)
   (mem:SI (post_inc:PSI (reg:PSI 10 R10)) {subsi3}

Committed the attached patch as obvious.
>From 04637536a6b69c6bf7e22e2ccd5ff3bfc4892394 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Fri, 10 Apr 2020 17:31:33 +0100
Subject: [PATCH] MSP430: Dont add offsets to addresses when emitting asm for
 post_inc

Some insns, which operate on SImode operands, output assembler template
that comprise of multiple instructions using HImode operands. To access
the high word of an SImode operand, an operand selector '%H' is used to
offset the operand value by a constant amount.

When one of these HImode operands is a memory reference to a post_inc,
the address does not need to be offset, since the preceding instruction
has already offset the address to the correct value.

This fixes an ICE in change_address_1, at emit-rtl.c:2318 for
gcc.c-torture/execute/pr20527-1.c in the "-mlarge -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects" configuration.

This test generated the following insn, and the attempt to output the
high part of the post_inc address caused the ICE.
(set (reg:SI 6 R6)
 (minus:SI (reg:SI 6 R6)
   (mem:SI (post_inc:PSI (reg:PSI 10 R10)) {subsi3}

gcc/ChangeLog:

2020-04-13  Jozef Lawrynowicz  

	* config/msp430/msp430.c (msp430_print_operand): Don't add offsets to
	memory references in %B, %C and %D operand selectors when the inner
	operand is a post increment address.
---
 gcc/ChangeLog  |  6 ++
 gcc/config/msp430/msp430.c | 10 +++---
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index c0ac32dccf6..8bfc2127989 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-13  Jozef Lawrynowicz  
+
+	* config/msp430/msp430.c (msp430_print_operand): Don't add offsets to
+	memory references in %B, %C and %D operand selectors when the inner
+	operand is a post increment address.
+
 2020-04-13  Jozef Lawrynowicz  
 
 	* config/msp430/msp430.c (msp430_print_operand): Offset a %C memory
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index 96532740ac1..e77ca101599 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -3474,7 +3474,9 @@ msp430_print_operand (FILE * file, rtx op, int letter)
   switch (GET_CODE (op))
 	{
 	case MEM:
-	  op = adjust_address (op, Pmode, 2);
+	  /* We don't need to adjust the address for post_inc.  */
+	  op = adjust_address (op, Pmode,
+			   (GET_CODE (XEXP (op, 0)) == POST_INC) ? 0 : 2);
 	  break;
 	case REG:
 	  op = gen_rtx_REG (Pmode, REGNO (op) + 1);
@@ -3492,7 +3494,8 @@ msp430_print_operand (FILE * file, rtx op, int letter)
   switch (GET_CODE (op))
 	{
 	case MEM:
-	  op = adjust_address (op, Pmode, 4);
+	  op = adjust_address (op, Pmode,
+			   (GET_CODE (XEXP (op, 0)) == POST_INC) ? 0 : 4);
 	  break;
 	case REG:
 	  op = gen_rtx_REG (Pmode, REGNO (op) + 2);
@@ -3510,7 +3513,8 @@ msp430_print_operand (FILE * file, rtx op, int letter)
   switch (GET_CODE (op))
 	{
 	case MEM:
-	  op = adjust_address (op, Pmode, 6);
+	  op = adjust_address (op, Pmode,
+			   (GET_CODE (XEXP (op, 0)) == POST_INC) ? 0 : 6);
 	  break;
 	case REG:
 	  op = gen_rtx_REG (Pmode, REGNO (op) + 3);
-- 
2.17.1

[PATCH] realloc() was missing from parts of the documentation

[Zackery Spytz via Gcc-patches]

Hello,

The realloc() function was missing from parts of the documentation!

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 79e2c8cb87f..81bb7a47de2 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12434,6 +12434,7 @@ is called and the @var{flag} argument passed to it.
 @findex printf_unlocked
 @findex putchar
 @findex puts
+@findex realloc
 @findex remainder
 @findex remainderf
 @findex remainderl
@@ -12677,8 +12678,8 @@ The ISO C90 functions
 @code{toupper}, @code{labs}, @code{ldexp}, @code{log10}, @code{log},
 @code{malloc}, @code{memchr}, @code{memcmp}, @code{memcpy},
 @code{memset}, @code{modf}, @code{pow}, @code{printf}, @code{putchar},
-@code{puts}, @code{scanf}, @code{sinh}, @code{sin}, @code{snprintf},
-@code{sprintf}, @code{sqrt}, @code{sscanf}, @code{strcat},
+@code{puts}, @code{realloc}, @code{scanf}, @code{sinh}, @code{sin},
+@code{snprintf}, @code{sprintf}, @code{sqrt}, @code{sscanf}, @code{strcat},
 @code{strchr}, @code{strcmp}, @code{strcpy}, @code{strcspn},
 @code{strlen}, @code{strncat}, @code{strncmp}, @code{strncpy},
 @code{strpbrk}, @code{strrchr}, @code{strspn}, @code{strstr},


Zackery

[PATCH PR00002] aarch64：Add an error message in large code model for ilp32

[duanbo (C)]

Hi

This is a simple fix for pr94577.
The option -mabi=ilp32 should not be used in large code model. Like x86, using 
-mx32 and -mcmodel=large together will result in an error message.
On aarch64, there is no error message for this option conflict.
A solution to this problem can be found in the attached patch.
Bootstrap and tested on aarch64 Linux platform. No new regression witnessed.
Any suggestion?  

Thanks,
Duan bo
Log:

gcc:
+2020-04-13  Duan bo  
+
+   PR  target/94577
+   * config/aarch64/aarch64.c: add an error message for option conflict

gcc/testsuite:
+2020-04-13  Duan bo  
+
+   PR  target/94577
+   * gcc.target/aarch64/pr94577.c : New test


pr94577-v0.patch
Description: pr94577-v0.patch

[PATCH] c++: More self-modifying constexpr init [PR94470]

[Patrick Palka via Gcc-patches]

In this PR we're incorrectly rejecting a self-modifying constexpr initializer as
a consequence of the fix for PR78572.

It looks like however that the fix for PR78572 is obsoleted by the fix for
PR89336: the testcase from the former PR successfully compiles even with its fix
reverted.

But then further testing showed that the analogous testcase of PR78572 where the
array has an aggregate element type is still problematic (i.e. we ICE) even with
the fix for PR78572 applied.  The reason is that in cxx_eval_bare_aggregate we
attach a constructor_elt of aggregate type always to the end of the new
CONSTRUCTOR, but that's not necessarily correct if the CONSTRUCTOR is
self-modifying.  We should instead be using get_or_insert_ctor_field to attach
the constructor_elt.

So this patch reverts the PR78572 fix and makes the appropriate changes to
cxx_eval_bare_aggregate.  This fixes PR94470, and we now are also able to reduce
the initializers of 'arr' and 'arr2' in the new test array57.C to constant
initializers.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to commit?

gcc/cp/ChangeLog:

PR c++/94470
* constexpr.c (get_or_insert_ctor_field): Set default value of parameter
'pos_hint' to -1.
(cxx_eval_bare_aggregate): Use get_or_insert_ctor_field instead of
assuming the the next index belongs at the end of the new CONSTRUCTOR.
(cxx_eval_store_expression): Revert PR c++/78572 fix.

gcc/testsuite/ChangeLog:

PR c++/94470
* g++.dg/cpp1y/constexpr-nsdmi8.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi9.C: New test.
* g++.dg/init/array57.C: New test.
---
 gcc/cp/constexpr.c| 19 +++
 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi8.C | 11 +++
 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi9.C | 16 
 gcc/testsuite/g++.dg/init/array57.C   | 16 
 4 files changed, 50 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi8.C
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi9.C
 create mode 100644 gcc/testsuite/g++.dg/init/array57.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 4cf5812e8a5..182da1af8a3 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3212,7 +3212,7 @@ find_array_ctor_elt (tree ary, tree dindex, bool insert)
for the (integer) index of the matching constructor_elt within CTOR.  */
 
 static constructor_elt *
-get_or_insert_ctor_field (tree ctor, tree index, int pos_hint)
+get_or_insert_ctor_field (tree ctor, tree index, int pos_hint = -1)
 {
   /* Check the hint first.  */
   if (pos_hint >= 0 && (unsigned)pos_hint < CONSTRUCTOR_NELTS (ctor)
@@ -3911,14 +3911,15 @@ cxx_eval_bare_aggregate (const constexpr_ctx *ctx, tree 
t,
{
  /* If we built a new CONSTRUCTOR, attach it now so that other
 initializers can refer to it.  */
- CONSTRUCTOR_APPEND_ELT (*p, index, new_ctx.ctor);
- pos_hint = vec_safe_length (*p) - 1;
+ constructor_elt *cep = get_or_insert_ctor_field (ctx->ctor, index);
+ cep->value = new_ctx.ctor;
+ pos_hint = cep - (*p)->begin();
}
   else if (TREE_CODE (type) == UNION_TYPE)
/* Otherwise if we're constructing a non-aggregate union member, set
   the active union member now so that we can later detect and diagnose
   if its initializer attempts to activate another member.  */
-   CONSTRUCTOR_APPEND_ELT (*p, index, NULL_TREE);
+   get_or_insert_ctor_field (ctx->ctor, index);
   tree elt = cxx_eval_constant_expression (&new_ctx, value,
   lval,
   non_constant_p, overflow_p);
@@ -4718,13 +4719,7 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
tree t,
   /* And then find/build up our initializer for the path to the subobject
  we're initializing.  */
   tree *valp;
-  if (object == ctx->object && VAR_P (object)
-  && DECL_NAME (object) && ctx->call == NULL)
-/* The variable we're building up an aggregate initializer for is outside
-   the constant-expression, so don't evaluate the store.  We check
-   DECL_NAME to handle TARGET_EXPR temporaries, which are fair game.  */
-valp = NULL;
-  else if (DECL_P (object))
+  if (DECL_P (object))
 valp = ctx->global->values.get (object);
   else
 valp = NULL;
@@ -4820,7 +4815,7 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree 
t,
   vec_safe_push (indexes, index);
 
   constructor_elt *cep
-   = get_or_insert_ctor_field (*valp, index, /*pos_hint=*/-1);
+   = get_or_insert_ctor_field (*valp, index);
   index_pos_hints.safe_push (cep - CONSTRUCTOR_ELTS (*valp)->begin());
 
   if (code == UNION_TYPE)
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi8.C 
b/gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi8.C
new file mode 100644
index 000

Re: [PATCH, libphobos] Fix compilation dependencies on s390x-linux-musl

[Iain Buclaw via Gcc-patches]

On 08/04/2020 10:14, Iain Buclaw via Gcc-patches wrote:
> On 28/01/2020 05:00, Mathias Lang wrote:
>> diff -Nurp a/libphobos/configure.ac b/libphobos/configure.ac
>> --- a/libphobos/configure.ac
>> +++ b/libphobos/configure.ac
>> @@ -140,6 +140,14 @@ case ${host} in
>>  esac
>>  AC_MSG_RESULT($LIBPHOBOS_SUPPORTED)
>>
>> +AC_MSG_CHECKING([if target needs to link in swapcontext])
>> +AC_MSG_RESULT($LIBDRUNTIME_NEEDS_UCONTEXT)
>> +AS_IF([test "x$LIBDRUNTIME_NEEDS_UCONTEXT" = xyes], [
>> +   AC_SEARCH_LIBS([swapcontext], [c ucontext], [], [
>> +   AC_MSG_ERROR([[can't find library providing swapcontext]])
>> +  ])
>> +])
>> +
> 
> Rather than adding LIBDRUNTIME_NEEDS_UCONTEXT, couldn't you just add a 
> one-liner AC_SEARCH_LIBS to the WITH_LOCAL_DRUNTIME list?
> 
> Testing as I suggest locally, there is no problems on x86 and x86_64.
> 
> Iain.
> 

Hi Matthias,

Does the following change work well for you on s390x-musl?


Regards
Iain.

---
diff --git a/libphobos/configure b/libphobos/configure
index a6f5aec2bfd..333ac86c977 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -15043,6 +15043,77 @@ $as_echo "$druntime_cv_lib_sockets" >&6; }
   LIBS="$LIBS $druntime_cv_lib_sockets"
 
 
+  # Keep this in sync with core/thread.d, set druntime_fiber_asm_external to
+  # "yes" for targets that have 'version = AsmExternal'.
+  druntime_fiber_asm_external=no
+  case "$target_cpu" in
+aarch64* | \
+arm* | \
+i[34567]86|x86_64 | \
+powerpc)
+  druntime_fiber_asm_external=yes
+  ;;
+  esac
+  if test "$druntime_fiber_asm_external" = no; then
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing 
swapcontext" >&5
+$as_echo_n "checking for library containing swapcontext... " >&6; }
+if ${ac_cv_search_swapcontext+:} false; then :
+  $as_echo_n "(cached) " >&6
+else
+  ac_func_search_save_LIBS=$LIBS
+cat confdefs.h - <<_ACEOF >conftest.$ac_ext
+/* end confdefs.h.  */
+
+/* Override any GCC internal prototype to avoid an error.
+   Use char because int might match the return type of a GCC
+   builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+char swapcontext ();
+int
+main ()
+{
+return swapcontext ();
+  ;
+  return 0;
+}
+_ACEOF
+for ac_lib in '' c ucontext; do
+  if test -z "$ac_lib"; then
+ac_res="none required"
+  else
+ac_res=-l$ac_lib
+LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
+  fi
+  if ac_fn_c_try_link "$LINENO"; then :
+  ac_cv_search_swapcontext=$ac_res
+fi
+rm -f core conftest.err conftest.$ac_objext \
+conftest$ac_exeext
+  if ${ac_cv_search_swapcontext+:} false; then :
+  break
+fi
+done
+if ${ac_cv_search_swapcontext+:} false; then :
+
+else
+  ac_cv_search_swapcontext=no
+fi
+rm conftest.$ac_ext
+LIBS=$ac_func_search_save_LIBS
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_cv_search_swapcontext" >&5
+$as_echo "$ac_cv_search_swapcontext" >&6; }
+ac_res=$ac_cv_search_swapcontext
+if test "$ac_res" != no; then :
+  test "$ac_res" = "none required" || LIBS="$ac_res $LIBS"
+
+fi
+
+  fi
+
+
   ac_ext=c
 ac_cpp='$CPP $CPPFLAGS'
 ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
diff --git a/libphobos/configure.ac b/libphobos/configure.ac
index ffd12981d0b..47591668d9d 100644
--- a/libphobos/configure.ac
+++ b/libphobos/configure.ac
@@ -144,6 +144,7 @@ DRUNTIME_LIBRARIES_ATOMIC
 DRUNTIME_LIBRARIES_BACKTRACE
 DRUNTIME_LIBRARIES_DLOPEN
 DRUNTIME_LIBRARIES_NET
+DRUNTIME_LIBRARIES_UCONTEXT
 DRUNTIME_LIBRARIES_ZLIB
 DRUNTIME_INSTALL_DIRECTORIES
 
diff --git a/libphobos/m4/druntime/libraries.m4 
b/libphobos/m4/druntime/libraries.m4
index 9e8e210df5a..79a45d9fc3e 100644
--- a/libphobos/m4/druntime/libraries.m4
+++ b/libphobos/m4/druntime/libraries.m4
@@ -212,3 +212,26 @@ AC_DEFUN([DRUNTIME_LIBRARIES_CLIB],
   AC_SUBST(DCFG_HAVE_QSORT_R)
   AC_LANG_POP([C])
 ])
+
+# DRUNTIME_LIBRARIES_UCONTEXT
+# --
+# Autodetect and add ucontext library to LIBS if necessary.
+# This is only required if fiber_switchContext does not have
+# its own internal asm implementation.
+AC_DEFUN([DRUNTIME_LIBRARIES_UCONTEXT],
+[
+  # Keep this in sync with core/thread.d, set druntime_fiber_asm_external to
+  # "yes" for targets that have 'version = AsmExternal'.
+  druntime_fiber_asm_external=no
+  case "$target_cpu" in
+aarch64* | \
+arm* | \
+i[[34567]]86|x86_64 | \
+powerpc)
+  druntime_fiber_asm_external=yes
+  ;;
+  esac
+  if test "$druntime_fiber_asm_external" = no; then
+AC_SEARCH_LIBS([swapcontext], [c ucontext])
+  fi
+])

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

[Nathan Sidwell]

On 4/11/20 10:46 AM, Iain Sandoe wrote:

Hi Folks,
sorry for the long CC list - please feel free to ignore if you don’t care :)

I propose that this PR should be re-categorized as a “C++” one.

The reason is that this is not an oversight in the GCC implementation,
but a problem present in the general case.  Library implementors feel
strongly that absence of symmetric transfer on important targets is a
Bad Thing.

===   possibilities to resolve this …..

We have, in the case of coroutine tail-calls, a useful factor in that all
such calls pass a single pointer, to the coroutine state frame.  That
frame is initially set up in the DSO that spawns a given coroutine actor
function.  Thus, at the point the frame is built, we have access to the
TOC, GOT, PLT for the relevant DSO.

It would seem excessive to resort to some kind of trampoline when we
already have somewhere to put the data we need to restore.

So .. what I’d like to do is to prototype a solution (probably on PPC) and
then take the necessary (coroutine) ABI amendments to the “coroutines
ABI group” (I am the editor of the current doc - which doesn’t have any
ps-component).

=== band-aid to fix the PR for stage 4.

tested on x86_64-linux, darwin (no loss of tail-call)
powerpc64-linux-gnu (tail call is OK on m32, and bypassed on m64)
solaris2.11 (tail call is bypassed on m32 and 64).

OK for master?
thanks
Iain

=== this is the commit message.

For symmetric transfers to work with C++20 coroutines, it is
currently necessary to tail call the callee coroutine from resume
method of the caller coroutine.  The current codegen marks these
resume calls as "MUST_TAIL_CALL" to indicate that the tail call is
required for correctness.

Unfortunately, several targets have ABI constraints that prevent
an indirect tail-call, which results in the PRs compile error.

The change here tests the target sibcall hook for the resume
expression and only marks it as requiring a tail call if that's
supported.

This doesn't fix the underlying problem; that really a solution is
needed to allow the tail-calls (or equivalent) to take place - but
that will be deferred until next stage 1.


This is fine from my PoV for gcc 10.

nathan

--
Nathan Sidwell

[patch, fortran] Fix ICE on invalid, PR 94090

[Thomas Koenig via Gcc-patches]

Hello world,

the attached patch fixes an ICE on invalid: When the return type of
a function was misdeclared with a wrong rank, we issued a warning,
but not an error (unless with -pedantic); later on, an ICE ensued.

Nothing good can come from wrongly declaring a function type
(considering the ABI), so I changed that into a hard error.

OK for trunk?

Regards

Thomas

2020-04-13  Thomas Koenig  

PR fortran/94090
* gfortran.dg (gfc_compare_interfaces): Add
optional argument bad_result_characteristics.
* interface.c (gfc_check_result_characteristics): Fix
whitespace.
(gfc_compare_interfaces): Handle new argument; return
true if function return values are wrong.
* resolve.c (resolve_global_procedure): Hard error if
the return value of a function is wrong.

2020-04-13  Thomas Koenig  

PR fortran/94090
* gfortran.dg/interface_46.f90: New test.
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 0d77386ddae..4e1da8c88a0 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3445,7 +3445,8 @@ bool gfc_check_dummy_characteristics (gfc_symbol *, gfc_symbol *,
 bool gfc_check_result_characteristics (gfc_symbol *, gfc_symbol *,
    char *, int);
 bool gfc_compare_interfaces (gfc_symbol*, gfc_symbol*, const char *, int, int,
-			 char *, int, const char *, const char *);
+			 char *, int, const char *, const char *,
+			 bool *bad_result_characteristics = NULL);
 void gfc_check_interfaces (gfc_namespace *);
 bool gfc_procedure_use (gfc_symbol *, gfc_actual_arglist **, locus *);
 void gfc_ppc_use (gfc_component *, gfc_actual_arglist **, locus *);
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 75a50c999b7..5b375c65694 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -1529,7 +1529,7 @@ gfc_check_dummy_characteristics (gfc_symbol *s1, gfc_symbol *s2,
 
 bool
 gfc_check_result_characteristics (gfc_symbol *s1, gfc_symbol *s2,
-			  char *errmsg, int err_len)
+  char *errmsg, int err_len)
 {
   gfc_symbol *r1, *r2;
 
@@ -1695,12 +1695,16 @@ bool
 gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol *s2, const char *name2,
 			int generic_flag, int strict_flag,
 			char *errmsg, int err_len,
-			const char *p1, const char *p2)
+			const char *p1, const char *p2,
+			bool *bad_result_characteristics)
 {
   gfc_formal_arglist *f1, *f2;
 
   gcc_assert (name2 != NULL);
 
+  if (bad_result_characteristics)
+*bad_result_characteristics = false;
+
   if (s1->attr.function && (s2->attr.subroutine
   || (!s2->attr.function && s2->ts.type == BT_UNKNOWN
 	  && gfc_get_default_type (name2, s2->ns)->type == BT_UNKNOWN)))
@@ -1726,7 +1730,11 @@ gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol *s2, const char *name2,
 	  /* If both are functions, check result characteristics.  */
 	  if (!gfc_check_result_characteristics (s1, s2, errmsg, err_len)
 	  || !gfc_check_result_characteristics (s2, s1, errmsg, err_len))
-	return false;
+	{
+	  if (bad_result_characteristics)
+		*bad_result_characteristics = true;
+	  return false;
+	}
 	}
 
   if (s1->attr.pure && !s2->attr.pure)
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index ccd2a5e3b7d..36659790ddf 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -2605,11 +2605,24 @@ resolve_global_procedure (gfc_symbol *sym, locus *where, int sub)
 	/* Turn erros into warnings with -std=gnu and -std=legacy.  */
 	gfc_errors_to_warnings (true);
 
+  /* If a function returns a wrong type, this can lead to
+	 all kinds of ICEs and wrong code; issue a hard error
+	 in this case.  */
+
+  bool bad_result_characteristics;
   if (!gfc_compare_interfaces (sym, def_sym, sym->name, 0, 1,
-   reason, sizeof(reason), NULL, NULL))
+   reason, sizeof(reason), NULL, NULL,
+   &bad_result_characteristics))
 	{
-	  gfc_error_opt (0, "Interface mismatch in global procedure %qs at %L:"
+	  if (bad_result_characteristics)
+	{
+	  gfc_errors_to_warnings (false);
+	  gfc_error ("Interface mismatch in global procedure %qs at %L:"
 			 " %s", sym->name, &sym->declared_at, reason);
+	}
+	  else
+	gfc_error_opt (0, "Interface mismatch in global procedure %qs at %L:"
+			   " %s", sym->name, &sym->declared_at, reason);
 	  goto done;
 	}
 }
diff --git a/gcc/testsuite/gfortran.dg/interface_46.f90 b/gcc/testsuite/gfortran.dg/interface_46.f90
new file mode 100644
index 000..c1d87638fbe
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/interface_46.f90
@@ -0,0 +1,36 @@
+! { dg-do compile }
+! PR 94090 - this used to cause an ICE.
+!  Test case by José Rui Faustino de Sousa.
+function cntf(a) result(s)
+  implicit none
+
+  integer, intent(in) :: a(:)
+  
+  integer :: s(3)
+  
+  s = [1, 2, 3]
+  return
+end function cntf
+
+program ice_p
+
+  implicit none
+
+  interface
+function cntf(a) result(s)  ! { dg-error "Rank m

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

[Rainer Orth]

Hi Iain,

> diff --git 
> a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C 
> b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
> index 864846e365c..8211e8250ff 100644
> --- a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
> +++ b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
> @@ -1,4 +1,5 @@
> -//  { dg-do run }
> +// { dg-do run }
> +// { dg-xfail-run-if "no indirect tailcall" { { lp64 && { 
> powerpc64*-linux-gnu } } || { *-*-solaris2* *-*-aix* } } }
>  
>  #if __has_include()

unfortunately, the dg-xfail-run-if is wrong.  E.g. it causes XPASSes on
i386-pc-solaris2.11.

You should base this on the cpu part of the triplet in general, not on
the OS.  Besides, according to gcc-testresults postings, the test FAILs
on other targets as well: armv8l-unknown-linux-gnueabihf, hppa*, and ia64.

Besides, unless you want to introduce an effective-target keyword (with
documentation in sourcebuild.texi), probably overkill for a single use,
you can have more than one dg-xfail-run-if line to improve readibility.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

[Iain Sandoe]

Hi Rainer,

Rainer Orth  wrote:

diff --git  
a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C  
b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C

index 864846e365c..8211e8250ff 100644
---  
a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
+++  
b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C

@@ -1,4 +1,5 @@
-//  { dg-do run }
+// { dg-do run }
+// { dg-xfail-run-if "no indirect tailcall" { { lp64 && {  
powerpc64*-linux-gnu } } || { *-*-solaris2* *-*-aix* } } }


#if __has_include()


unfortunately, the dg-xfail-run-if is wrong.  E.g. it causes XPASSes on
i386-pc-solaris2.11.


.. so that behaves in a similar way to PPC?
fail on m64 pass on m32?
(I don’t have access to any x86 solaris testing)

according to my testing, sparc solaris fails for m32 and m64 (so the  
condition doesn’t need any multilib discriminator there)



You should base this on the cpu part of the triplet in general, not on
the OS.  Besides, according to gcc-testresults postings, the test FAILs
on other targets as well: armv8l-unknown-linux-gnueabihf, hppa*, and ia64.

Besides, unless you want to introduce an effective-target keyword (with
documentation in sourcebuild.texi), probably overkill for a single use,
you can have more than one dg-xfail-run-if line to improve readibility.


I’ll take a look at those  and make multiple xfail-run-if’s
(one per target might be the neatest, and easier for a target maintainer to  
add if one is missed).


thanks
Iain

Re: [PATCH] coroutines: Fix compile error with symmetric transfers [PR94359]

[Rainer Orth]

Hi Iain,

> Rainer Orth  wrote:
>
>>> diff --git
>>> a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
>>> b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
>>> index 864846e365c..8211e8250ff 100644
>>> ---  
>>> a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
>>> +++
>>> b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
>>> @@ -1,4 +1,5 @@
>>> -//  { dg-do run }
>>> +// { dg-do run }
>>> +// { dg-xfail-run-if "no indirect tailcall" { { lp64 && {
>>> powerpc64*-linux-gnu } } || { *-*-solaris2* *-*-aix* } } }
>>>
>>> #if __has_include()
>>
>> unfortunately, the dg-xfail-run-if is wrong.  E.g. it causes XPASSes on
>> i386-pc-solaris2.11.
>
> .. so that behaves in a similar way to PPC?
> fail on m64 pass on m32?
> (I don’t have access to any x86 solaris testing)

no, it PASSes for 32 and 64-bit alike, just as e.g. Linux/x86_64.

> according to my testing, sparc solaris fails for m32 and m64 (so the
> condition doesn’t need any multilib discriminator there)

Right, same here.

>> You should base this on the cpu part of the triplet in general, not on
>> the OS.  Besides, according to gcc-testresults postings, the test FAILs
>> on other targets as well: armv8l-unknown-linux-gnueabihf, hppa*, and ia64.
>>
>> Besides, unless you want to introduce an effective-target keyword (with
>> documentation in sourcebuild.texi), probably overkill for a single use,
>> you can have more than one dg-xfail-run-if line to improve readibility.
>
> I’ll take a look at those  and make multiple xfail-run-if’s
> (one per target might be the neatest, and easier for a target maintainer to
> add if one is missed).

I thought about separate ones for cases that need additional conditions
and an alphabetical list of target triplets (just -*-*)
for the rest.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH][PR target/94542]Don't allow PC-relative addressing for TLS data

[will schmidt via Gcc-patches]

On Fri, 2020-04-10 at 18:00 -0500, acsawdey via Gcc-patches wrote:
> One of the things that address_to_insn_form() is used for is
> determining 
> whether a PC-relative addressing instruction could be used. In 
> particular predicate pcrel_external_address and function 
> prefixed_paddi_p() both use it for this purpose. So what emerged in 
> PR/94542 is that it should be looking to see if the associated 
> symbol_ref is a TLS symbol of some kind. TLS symbols cannot be
> addressed 
> with PC-relative. This patch fixes both places in
> address_to_insn_form() 
> where it is looking at a symbol_ref.
> 
> Regression tests passed with trunk 
> 38e62001c576b8c6ba2e08eb4673d69ec4c5b0f9 on ppc64le power9, and 
> PC-relative code is now correct. OK for trunk?
> 
> Thanks!
> Aaron
> 
> 2020-04-10  Aaron Sawdey  
> 
>   PR target/94542
>   * config/rs6000/rs6000.c (address_to_insn_form): Do not attempt
> to
>   use PC-relative addressing for TLS references.

> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 2b6613bcb7e..c77e60a718f 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -24824,15 +24824,21 @@ address_to_insn_form (rtx addr,
>if (GET_RTX_CLASS (GET_CODE (addr)) == RTX_AUTOINC)
>  return INSN_FORM_UPDATE;
>  
> -  /* Handle PC-relative symbols and labels.  Check for both local and 
> external
> - symbols.  Assume labels are always local.  */
> +  /* Handle PC-relative symbols and labels.  Check for both local and
> + external symbols.  Assume labels are always local. TLS symbols
> + are not PC-relative.  */

Does the assumption need a qualifier for target rs6000?  (or some combination
of TLS/PC-relative?)   There are users of the LABEL_REF_NONLOCAL_P() for
mips,pa,sparc targets.

>if (TARGET_PCREL)
>  {
> -  if (SYMBOL_REF_P (addr) && !SYMBOL_REF_LOCAL_P (addr))
> - return INSN_FORM_PCREL_EXTERNAL;
> -
> -  if (SYMBOL_REF_P (addr) || LABEL_REF_P (addr))
> +  if (LABEL_REF_P (addr))
>   return INSN_FORM_PCREL_LOCAL;

lgtm.

> +
> +  if (SYMBOL_REF_P (addr) && !SYMBOL_REF_TLS_MODEL (addr))
> + {
> +   if (!SYMBOL_REF_LOCAL_P (addr))
> + return INSN_FORM_PCREL_EXTERNAL;
> +   else
> + return INSN_FORM_PCREL_LOCAL;
> + }
>  }

lgtm.

>  
>if (GET_CODE (addr) == CONST)
> @@ -24866,14 +24872,19 @@ address_to_insn_form (rtx addr,
>  return INSN_FORM_BAD;
>  
>/* Check for local and external PC-relative addresses.  Labels are always
> - local.  */
> + local.  TLS symbols are not PC-relative.  */
>if (TARGET_PCREL)
>  {
> -  if (SYMBOL_REF_P (op0) && !SYMBOL_REF_LOCAL_P (op0))
> - return INSN_FORM_PCREL_EXTERNAL;
> -
> -  if (SYMBOL_REF_P (op0) || LABEL_REF_P (op0))
> +  if (LABEL_REF_P (op0))
>   return INSN_FORM_PCREL_LOCAL;
> +
> +  if (SYMBOL_REF_P (op0) && !SYMBOL_REF_TLS_MODEL (op0))
> + {
> +   if (!SYMBOL_REF_LOCAL_P (op0))
> + return INSN_FORM_PCREL_EXTERNAL;
> +   else
> + return INSN_FORM_PCREL_LOCAL;
> + }

lgtm

Thanks
-Will


>  }
>  
>/* If it isn't PC-relative, the address must use a base register.  */
> 

Re: ICE on wrong code [PR94192]

[Fritz Reese via Gcc-patches]

On Sat, Apr 11, 2020 at 10:27 AM Linus König  wrote:
>
> Hi,
>
> Here is the patch with some of the null pointer tests removed.
>
> This is regression-tested. ChangeLog and test case are as in
> https://gcc.gnu.org/pipermail/fortran/2020-April/054193.html .

Thanks. Sorry I missed the ChangeLog entry and tests in my previous
email. Those look good.


> The list of test cases that fail without the remaining NULL
> check is below. Is this OK for trunk?

Thank you for the test listing.

I apologize for being pedantic, but the remaining NULL check is still
superfluous. The check can be removed simply by moving the new code
past the BT_CLASS and EXPR_VARIABLE checks, just before the loop, like
in my previous diffs. The idea is that when array->expr_type is
EXPR_VARIABLE, array->symtree is guaranteed not to be NULL. If this
invariant was violated, there are at least five functions in
simplify.c alone which would segfault, including simplify_bound, even
with this patch. Therefore I prefer not to check array->symtree for
NULL before the EXPR_VARIABLE test.

With that change I will OK the patch. If you and the regression tests
concur, I can commit for you. I believe this is appropriate for
backporting to 8 and 9 as well. Thanks again for your work.

---
Fritz

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Jason Merrill via Gcc-patches]

On 4/12/20 9:43 AM, Patrick Palka wrote:

On Sat, 11 Apr 2020, Jason Merrill wrote:


On 4/10/20 5:47 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Jason Merrill wrote:

On 4/10/20 2:15 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Patrick Palka wrote:


On Fri, 10 Apr 2020, Jason Merrill wrote:


On 4/10/20 1:04 PM, Patrick Palka wrote:

On Thu, 9 Apr 2020, Patrick Palka wrote:

On Thu, 9 Apr 2020, Jason Merrill wrote:


On 4/8/20 7:49 PM, Patrick Palka wrote:

When evaluating the initializer of 'a' in the following
example

   struct A { A *p = this; };
   constexpr A foo() { return {}; }
   constexpr A a = foo();

the PLACEHOLDER_EXPR for 'this' in the aggregate initializer
returned
by foo
gets resolved to the RESULT_DECL of foo.  But due to
guaranteed
RVO,
the
'this'
should really be resolved to '&a'.



It seems to me that the right approach would be to
immediately
resolve
the
PLACEHOLDER_EXPR to the correct target object during
evaluation
of
'foo()',
so
that we could use 'this' to access objects adjacent to the
current
object in
the
ultimate storage location.  (I think #c2 of PR c++/94537 is
an
example
of
such
usage of 'this', which currently doesn't work.  But as #c1
shows
we
don't
seem
to handle this case correctly in non-constexpr
initialization
either.)


As I commented in the PR, the standard doesn't require this to
work
because A
is trivially copyable, and our ABI makes it impossible.  But
there's
still a
constexpr bug when we add

A() = default; A(const A&);

clang doesn't require the constructors to make this work for
constant
initialization, but similarly can't make it work for
non-constant
initialization.


That makes a lot of sense, thanks for the detailed explanation.




I haven't yet been able to make a solution using the above
approach
work --
making sure we use the ultimate object instead of the
RESULT_DECL
whenever
we
access ctx->global->values is proving to be tricky and
subtle.


Do we need to go through ctx->global->values?  Would it work
for
the
RESULT_DECL case in cxx_eval_constant_expression to go to
straight
to
ctx->object or ctx->ctor instead?


I attempted that at some point, but IIRC we still end up not
resolving
some RESULT_DECLs because not all of them get processed through
cxx_eval_constant_expression before we manipulate
ctx->global->values
with them.  I'll try this approach more carefully and report
back
with
more specifics.


It turns out that immediately resolving RESULT_DECLs/'this' to the
ultimate ctx->object would not interact well with constexpr_call
caching:

  struct A { A() = default; A(const A&); A *ap = this; };
  constexpr A foo() { return {}; }
  constexpr A a = foo();
  constexpr A b = foo();
  static_assert(b.ap == &b); // fails

Evaluation of the first call to foo() returns {&a}, since we
resolve
'this' to &a due to guaranteed RVO, and we cache this result.
Evaluation of the second call to foo() just returns the cached
result
from the constexpr_call cache, and so we get {&a} again.

So it seems we would have to mark the result of a constexpr call
as
not
cacheable whenever this RVO applies during its evaluation, even
when
doing the RVO has no observable difference in the final result
(i.e.
the
constructor does not try to save the 'this' pointer).

Would the performance impact of disabling caching whenever RVO
applies
during constexpr call evaluation be worth it, or should we go with
something like my first patch which "almost works," and which
marks a
constexpr call as not cacheable only when we replace a RESULT_DECL
in
the result of the call?


Could we search through the result of the call for ctx->object and
cache
if we
don't find it?


Hmm, I think the result of the call could still depend on ctx->object
without ctx->object explicitly appearing in the result.  Consider the
following testcase:

 struct A {
   A() = default; A(const A&);
   constexpr A(const A *q) : d{this - p} { }


Oops sorry, that 'q' should be a 'p'.


   long d = 0;
 };

 constexpr A baz(const A *q) { return A(p); };


And same here.


 constexpr A a = baz(&a);
 constexpr A b = baz(&a); // no error

The initialization of 'b' should be ill-formed, but the result of the
first call to baz(&a) would be {0}, so we would cache it and then
reuse
the result when initializing 'b'.


Ah, true.  Can we still cache if we're initializing something that isn't
TREE_STATIC?


Hmm, we correctly compile the analogous non-TREE_STATIC testcase

  struct A {
A() = default; A(const A&);
constexpr A(const A *p) : d{this == p} { }
bool d;
  };

  constexpr A baz(const A *p) { return A(p); }

  void foo() {
constexpr A x = baz(&x);
constexpr A y = baz(&x);
static_assert(!y.d);
  }

because the calls 'baz(&x)' are considered to have non-constant arguments.


Unfortunately, we can come up with another trick to fool the constexpr_call
cache in the presence of RVO even in the 

Re: [patch, fortran] Fix ICE on invalid, PR 94090

[Fritz Reese via Gcc-patches]

On Mon, Apr 13, 2020 at 10:20 AM Thomas Koenig via Fortran
 wrote:
>
> Hello world,
>
> the attached patch fixes an ICE on invalid: When the return type of
> a function was misdeclared with a wrong rank, we issued a warning,
> but not an error (unless with -pedantic); later on, an ICE ensued.
>
> Nothing good can come from wrongly declaring a function type
> (considering the ABI), so I changed that into a hard error.
>
> OK for trunk?
>
> Regards
>
> Thomas
>
> 2020-04-13  Thomas Koenig  
>
>  PR fortran/94090
>  * gfortran.dg (gfc_compare_interfaces): Add
>  optional argument bad_result_characteristics.
>  * interface.c (gfc_check_result_characteristics): Fix
>  whitespace.
>  (gfc_compare_interfaces): Handle new argument; return
>  true if function return values are wrong.
>  * resolve.c (resolve_global_procedure): Hard error if
>  the return value of a function is wrong.
>
> 2020-04-13  Thomas Koenig  
>
>  PR fortran/94090
>  * gfortran.dg/interface_46.f90: New test.

Thomas,

I agree with your assessment and the spirit of the patch.

I wonder: could you simply replace the gfc_error_opt(0, ...) call with
gfc_error? From what I can tell, gfc_error() is simply a short-cut for
gfc_error_opt(0, ...). This has the nice side-effects of reducing the
annoying 81-character line, and using only one copy of the error call:

@@ -2605,11 +2605,19 @@ resolve_global_procedure (gfc_symbol *sym,
locus *where, int sub)
/* Turn erros into warnings with -std=gnu and -std=legacy.  */
gfc_errors_to_warnings (true);

+  /* If a function returns a wrong type, this can lead to
+all kinds of ICEs and wrong code; issue a hard error
+in this case.  */
+
+  bool bad_result_characteristics;
   if (!gfc_compare_interfaces (sym, def_sym, sym->name, 0, 1,
-  reason, sizeof(reason), NULL, NULL))
+  reason, sizeof(reason), NULL, NULL,
+  &bad_result_characteristics))
{
- gfc_error_opt (0, "Interface mismatch in global procedure %qs at %L:"
-" %s", sym->name, &sym->declared_at, reason);
+ if (bad_result_characteristics)
+   gfc_errors_to_warnings (false);
+ gfc_error ("Interface mismatch in global procedure %qs at %L:"
+" %s", sym->name, &sym->declared_at, reason);
  goto done;
}
 }

Otherwise LGTM, thanks for the fix.

---
Fritz Reese

Re: [PATCH] c++: More self-modifying constexpr init [PR94470]

[Jason Merrill via Gcc-patches]

On 4/13/20 9:18 AM, Patrick Palka wrote:

In this PR we're incorrectly rejecting a self-modifying constexpr initializer as
a consequence of the fix for PR78572.

It looks like however that the fix for PR78572 is obsoleted by the fix for
PR89336: the testcase from the former PR successfully compiles even with its fix
reverted.

But then further testing showed that the analogous testcase of PR78572 where the
array has an aggregate element type is still problematic (i.e. we ICE) even with
the fix for PR78572 applied.  The reason is that in cxx_eval_bare_aggregate we
attach a constructor_elt of aggregate type always to the end of the new
CONSTRUCTOR, but that's not necessarily correct if the CONSTRUCTOR is
self-modifying.  We should instead be using get_or_insert_ctor_field to attach
the constructor_elt.

So this patch reverts the PR78572 fix and makes the appropriate changes to
cxx_eval_bare_aggregate.  This fixes PR94470, and we now are also able to reduce
the initializers of 'arr' and 'arr2' in the new test array57.C to constant
initializers.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to commit?


OK.


gcc/cp/ChangeLog:

PR c++/94470
* constexpr.c (get_or_insert_ctor_field): Set default value of parameter
'pos_hint' to -1.
(cxx_eval_bare_aggregate): Use get_or_insert_ctor_field instead of
assuming the the next index belongs at the end of the new CONSTRUCTOR.
(cxx_eval_store_expression): Revert PR c++/78572 fix.

gcc/testsuite/ChangeLog:

PR c++/94470
* g++.dg/cpp1y/constexpr-nsdmi8.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi9.C: New test.
* g++.dg/init/array57.C: New test.
---
  gcc/cp/constexpr.c| 19 +++
  gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi8.C | 11 +++
  gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi9.C | 16 
  gcc/testsuite/g++.dg/init/array57.C   | 16 
  4 files changed, 50 insertions(+), 12 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi8.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi9.C
  create mode 100644 gcc/testsuite/g++.dg/init/array57.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 4cf5812e8a5..182da1af8a3 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3212,7 +3212,7 @@ find_array_ctor_elt (tree ary, tree dindex, bool insert)
 for the (integer) index of the matching constructor_elt within CTOR.  */
  
  static constructor_elt *

-get_or_insert_ctor_field (tree ctor, tree index, int pos_hint)
+get_or_insert_ctor_field (tree ctor, tree index, int pos_hint = -1)
  {
/* Check the hint first.  */
if (pos_hint >= 0 && (unsigned)pos_hint < CONSTRUCTOR_NELTS (ctor)
@@ -3911,14 +3911,15 @@ cxx_eval_bare_aggregate (const constexpr_ctx *ctx, tree 
t,
{
  /* If we built a new CONSTRUCTOR, attach it now so that other
 initializers can refer to it.  */
- CONSTRUCTOR_APPEND_ELT (*p, index, new_ctx.ctor);
- pos_hint = vec_safe_length (*p) - 1;
+ constructor_elt *cep = get_or_insert_ctor_field (ctx->ctor, index);
+ cep->value = new_ctx.ctor;
+ pos_hint = cep - (*p)->begin();
}
else if (TREE_CODE (type) == UNION_TYPE)
/* Otherwise if we're constructing a non-aggregate union member, set
   the active union member now so that we can later detect and diagnose
   if its initializer attempts to activate another member.  */
-   CONSTRUCTOR_APPEND_ELT (*p, index, NULL_TREE);
+   get_or_insert_ctor_field (ctx->ctor, index);
tree elt = cxx_eval_constant_expression (&new_ctx, value,
   lval,
   non_constant_p, overflow_p);
@@ -4718,13 +4719,7 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, 
tree t,
/* And then find/build up our initializer for the path to the subobject
   we're initializing.  */
tree *valp;
-  if (object == ctx->object && VAR_P (object)
-  && DECL_NAME (object) && ctx->call == NULL)
-/* The variable we're building up an aggregate initializer for is outside
-   the constant-expression, so don't evaluate the store.  We check
-   DECL_NAME to handle TARGET_EXPR temporaries, which are fair game.  */
-valp = NULL;
-  else if (DECL_P (object))
+  if (DECL_P (object))
  valp = ctx->global->values.get (object);
else
  valp = NULL;
@@ -4820,7 +4815,7 @@ cxx_eval_store_expression (const constexpr_ctx *ctx, tree 
t,
vec_safe_push (indexes, index);
  
constructor_elt *cep

-   = get_or_insert_ctor_field (*valp, index, /*pos_hint=*/-1);
+   = get_or_insert_ctor_field (*valp, index);
index_pos_hints.safe_push (cep - CONSTRUCTOR_ELTS (*valp)->begin());
  
if (code == UNION_TYPE)

diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi8.

[committed] Darwin, testsuite: Fix darwin-version-1.c fails with XCode 11.4.

[Iain Sandoe]

Hi,

>From XCode 11.4 on 10.14/15 use of 10.6 and 10.7 is deprecated.
The tools issue diagnostics if -mmacosx-version-min= < 10.8

Adjust the testcase to avoid that usage on 10.14, 10.15 for now.

tested on x86_64-darwin10, 19
applied to master
thanks
Iain

gcc/testsuite/ChangeLog:

2020-04-13  Iain Sandoe  

* gcc.dg/darwin-version-1.c: Use -mmacosx-version-min= 10.8
for system versions 10.14 and 10.15.

diff --git a/gcc/testsuite/gcc.dg/darwin-version-1.c 
b/gcc/testsuite/gcc.dg/darwin-version-1.c
index ad7f7da3b63..2ca34c6c007 100644
--- a/gcc/testsuite/gcc.dg/darwin-version-1.c
+++ b/gcc/testsuite/gcc.dg/darwin-version-1.c
@@ -5,7 +5,9 @@
 /* Later Darwin linkers decline to link for less than Darwin8/MacOS 10.4.
However, we need to make the link for 10.6 because the relevant libgcc_s
shim files for 10.4 and 10.5 are also not installed in later SDKs.  */
-/* { dg-options "-mmacosx-version-min=10.6" { target *-*-darwin[123]* } } */
+/* { dg-options "-mmacosx-version-min=10.6" { target *-*-darwin1[01234567]* } 
} */
+/* From XCode 11.4 on 10.14/15 10.6 and 10.7 are also deprecated.  */
+/* { dg-options "-mmacosx-version-min=10.8" { target *-*-darwin1[89]* } } */
 /* { dg-do link { target *-*-darwin* } } */
 
 int main()

[PATCH] correct format of flexible array members in diagnostics (PR c/92326)

[Martin Sebor via Gcc-patches]

GCC 10 has changed the formatting of zero-length arrays in diagnostics
to include their bound, but it also inadvertently added the zero bound
to flexible array members which are confusingly represented differently
between the C and C++ front ends.

The attached patch corrects the problem so both zero-length arrays and
flexible array members are formatted consistently by both front ends
(i.e., as T[0] and T[]).

Tested on x86_64-linux.

Martin
PR c/92326 - wrong bound in zero-length array diagnostics

gcc/c-family/ChangeLog:

	PR c/92326
	* c-pretty-print.c (c_pretty_printer::direct_abstract_declarator): Avoid
	printing array bound for flexible array members.

gcc/testsuite/ChangeLog:

	PR c/92326
	* c-c++-common/Warray-bounds-8.c: New test.
	* gcc.dg/Warray-bounds-46.c: Adjust expected format of flexible array
	memebrs in diagnostics.
	* gcc.dg/Warray-bounds-49.c: Same.

diff --git a/gcc/c-family/c-pretty-print.c b/gcc/c-family/c-pretty-print.c
index 0e4303f1a49..eccb63096fd 100644
--- a/gcc/c-family/c-pretty-print.c
+++ b/gcc/c-family/c-pretty-print.c
@@ -593,7 +593,9 @@ c_pretty_printer::direct_abstract_declarator (tree t)
 		expression (fold_build2 (PLUS_EXPR, type, maxval,
 	 build_int_cst (type, 1)));
 	}
-	  else
+	  else if (TYPE_SIZE (t))
+	/* Print zero for zero-length arrays but not for flexible
+	   array members whose TYPE_SIZE is null.  */
 	pp_string (this, "0");
 	}
   pp_c_right_bracket (this);
diff --git a/gcc/testsuite/c-c++-common/Warray-bounds-8.c b/gcc/testsuite/c-c++-common/Warray-bounds-8.c
new file mode 100644
index 000..64202ddd5df
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/Warray-bounds-8.c
@@ -0,0 +1,22 @@
+/* PR c/92326 - wrong bound in zero-length array diagnostics
+   { dg-do compile }
+   { dg-options "-O2 -Wall" } */
+
+extern int a0[0];
+extern int ax[];
+
+void warn_global_array (void)
+{
+  a0[0] = 0;// { dg-warning "array bounds of 'int *\\\[0]'" }
+  ax[-1] = 0;   // { dg-warning "array bounds of 'int *\\\[]'" }
+}
+
+
+struct S0 { int n, a0[0]; } s0;
+struct Sx { int n, ax[]; } sx = { 0 };
+
+void warn_member_array (void)
+{
+  s0.a0[0] = 0; // { dg-warning "array bounds of 'int *\\\[0]'" }
+  sx.ax[0] = 0; // { dg-warning "array bounds of 'int *\\\[]'" }
+}
diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-46.c b/gcc/testsuite/gcc.dg/Warray-bounds-46.c
index 74e78cbdbe8..9078c6f5998 100644
--- a/gcc/testsuite/gcc.dg/Warray-bounds-46.c
+++ b/gcc/testsuite/gcc.dg/Warray-bounds-46.c
@@ -95,13 +95,13 @@ void strcpy_global_array (void)
   /* GMA2 is external but because it's an array its definition in another
  translation unit may not provide an initializer for the flexible array
  member.  Verify that a warning is issued for access to it.  */
-  T (gma2[0].ax, 1);  // { dg-warning "'strcpy' offset \\\[157, 158] from the object at 'gma2' is out of the bounds of referenced subobject 'ax' with type 'char\\\[0]' at offset 157" }
-  T (gma2[0].ax, 7);  // { dg-warning "'strcpy' offset \\\[157, 164] from the object at 'gma2' is out of the bounds of referenced subobject 'ax' with type 'char\\\[0]' at offset 157" }
+  T (gma2[0].ax, 1);  // { dg-warning "'strcpy' offset \\\[157, 158] from the object at 'gma2' is out of the bounds of referenced subobject 'ax' with type 'char\\\[]' at offset 157" }
+  T (gma2[0].ax, 7);  // { dg-warning "'strcpy' offset \\\[157, 164] from the object at 'gma2' is out of the bounds of referenced subobject 'ax' with type 'char\\\[]' at offset 157" }
 
-  /* IGMA_ is internal and provides on definition for the flexible array
- member.  Verify that a warnin is issued for out-of-bounds accesses
+  /* IGMA2_ is internal and provides no definition for the flexible array
+ member.  Verify that a warning is issued for out-of-bounds accesses
  to it.  */
-  T (igma2_[0].ax, 1);// { dg-warning "'strcpy' offset \\\[157, 158] from the object at 'igma2_' is out of the bounds of referenced subobject 'ax' with type 'char\\\[0]' at offset 157" }
+  T (igma2_[0].ax, 1);// { dg-warning "'strcpy' offset \\\[157, 158] from the object at 'igma2_' is out of the bounds of referenced subobject 'ax' with type 'char\\\[]' at offset 157" }
 
   T (igma_3.ax, 0);
   T (igma_3.ax, 1);
@@ -134,7 +134,7 @@ void strcpy_local (void)
   T (lma.a17, 16);
   T (lma.a17, 17);// { dg-warning "'strcpy' offset 157 from the object at 'lma' is out of the bounds of referenced subobject 'a17' with type 'char\\\[17]' at offset 140" }
 
-  T (lma.ax, 0);  // { dg-warning "'strcpy' offset 157 from the object at 'lma' is out of the bounds of referenced subobject 'ax' with type 'char\\\[0]' at offset 157" }
+  T (lma.ax, 0);  // { dg-warning "'strcpy' offset 157 from the object at 'lma' is out of the bounds of referenced subobject 'ax' with type 'char\\\[]' at offset 157" }
 }
 
 
@@ -191,11 +191,11 @@ void strcpy_ref (struct MA17 *pma)
  array.  The warning assumes that P

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Patrick Palka via Gcc-patches]

On Mon, 13 Apr 2020, Jason Merrill wrote:

> On 4/12/20 9:43 AM, Patrick Palka wrote:
> > On Sat, 11 Apr 2020, Jason Merrill wrote:
> > 
> > > On 4/10/20 5:47 PM, Patrick Palka wrote:
> > > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > > > On 4/10/20 2:15 PM, Patrick Palka wrote:
> > > > > > On Fri, 10 Apr 2020, Patrick Palka wrote:
> > > > > > 
> > > > > > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > > > > > 
> > > > > > > > On 4/10/20 1:04 PM, Patrick Palka wrote:
> > > > > > > > > On Thu, 9 Apr 2020, Patrick Palka wrote:
> > > > > > > > > > On Thu, 9 Apr 2020, Jason Merrill wrote:
> > > > > > > > > > 
> > > > > > > > > > > On 4/8/20 7:49 PM, Patrick Palka wrote:
> > > > > > > > > > > > When evaluating the initializer of 'a' in the following
> > > > > > > > > > > > example
> > > > > > > > > > > > 
> > > > > > > > > > > >struct A { A *p = this; };
> > > > > > > > > > > >constexpr A foo() { return {}; }
> > > > > > > > > > > >constexpr A a = foo();
> > > > > > > > > > > > 
> > > > > > > > > > > > the PLACEHOLDER_EXPR for 'this' in the aggregate
> > > > > > > > > > > > initializer
> > > > > > > > > > > > returned
> > > > > > > > > > > > by foo
> > > > > > > > > > > > gets resolved to the RESULT_DECL of foo.  But due to
> > > > > > > > > > > > guaranteed
> > > > > > > > > > > > RVO,
> > > > > > > > > > > > the
> > > > > > > > > > > > 'this'
> > > > > > > > > > > > should really be resolved to '&a'.
> > > > > > > > > > > 
> > > > > > > > > > > > It seems to me that the right approach would be to
> > > > > > > > > > > > immediately
> > > > > > > > > > > > resolve
> > > > > > > > > > > > the
> > > > > > > > > > > > PLACEHOLDER_EXPR to the correct target object during
> > > > > > > > > > > > evaluation
> > > > > > > > > > > > of
> > > > > > > > > > > > 'foo()',
> > > > > > > > > > > > so
> > > > > > > > > > > > that we could use 'this' to access objects adjacent to
> > > > > > > > > > > > the
> > > > > > > > > > > > current
> > > > > > > > > > > > object in
> > > > > > > > > > > > the
> > > > > > > > > > > > ultimate storage location.  (I think #c2 of PR c++/94537
> > > > > > > > > > > > is
> > > > > > > > > > > > an
> > > > > > > > > > > > example
> > > > > > > > > > > > of
> > > > > > > > > > > > such
> > > > > > > > > > > > usage of 'this', which currently doesn't work.  But as
> > > > > > > > > > > > #c1
> > > > > > > > > > > > shows
> > > > > > > > > > > > we
> > > > > > > > > > > > don't
> > > > > > > > > > > > seem
> > > > > > > > > > > > to handle this case correctly in non-constexpr
> > > > > > > > > > > > initialization
> > > > > > > > > > > > either.)
> > > > > > > > > > > 
> > > > > > > > > > > As I commented in the PR, the standard doesn't require
> > > > > > > > > > > this to
> > > > > > > > > > > work
> > > > > > > > > > > because A
> > > > > > > > > > > is trivially copyable, and our ABI makes it impossible.
> > > > > > > > > > > But
> > > > > > > > > > > there's
> > > > > > > > > > > still a
> > > > > > > > > > > constexpr bug when we add
> > > > > > > > > > > 
> > > > > > > > > > > A() = default; A(const A&);
> > > > > > > > > > > 
> > > > > > > > > > > clang doesn't require the constructors to make this work
> > > > > > > > > > > for
> > > > > > > > > > > constant
> > > > > > > > > > > initialization, but similarly can't make it work for
> > > > > > > > > > > non-constant
> > > > > > > > > > > initialization.
> > > > > > > > > > 
> > > > > > > > > > That makes a lot of sense, thanks for the detailed
> > > > > > > > > > explanation.
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > I haven't yet been able to make a solution using the
> > > > > > > > > > > > above
> > > > > > > > > > > > approach
> > > > > > > > > > > > work --
> > > > > > > > > > > > making sure we use the ultimate object instead of the
> > > > > > > > > > > > RESULT_DECL
> > > > > > > > > > > > whenever
> > > > > > > > > > > > we
> > > > > > > > > > > > access ctx->global->values is proving to be tricky and
> > > > > > > > > > > > subtle.
> > > > > > > > > > > 
> > > > > > > > > > > Do we need to go through ctx->global->values?  Would it
> > > > > > > > > > > work
> > > > > > > > > > > for
> > > > > > > > > > > the
> > > > > > > > > > > RESULT_DECL case in cxx_eval_constant_expression to go to
> > > > > > > > > > > straight
> > > > > > > > > > > to
> > > > > > > > > > > ctx->object or ctx->ctor instead?
> > > > > > > > > > 
> > > > > > > > > > I attempted that at some point, but IIRC we still end up not
> > > > > > > > > > resolving
> > > > > > > > > > some RESULT_DECLs because not all of them get processed
> > > > > > > > > > through
> > > > > > > > > > cxx_eval_constant_expression before we manipulate
> > > > > > > > > > ctx->global->values
> > > > > > > > > > with them.  I'll try this approach more carefully and report
> > > > > > > > > > back
> > > > > > > > > > with
> > > > > > > > > > more specifics.
> > > > > > > > > 
> > > > > > > > > It turns out that immediately reso

Re: [PATCH] correct format of flexible array members in diagnostics (PR c/92326)

[Jeff Law via Gcc-patches]

On Mon, 2020-04-13 at 12:39 -0600, Martin Sebor via Gcc-patches wrote:
> GCC 10 has changed the formatting of zero-length arrays in diagnostics
> to include their bound, but it also inadvertently added the zero bound
> to flexible array members which are confusingly represented differently
> between the C and C++ front ends.
> 
> The attached patch corrects the problem so both zero-length arrays and
> flexible array members are formatted consistently by both front ends
> (i.e., as T[0] and T[]).
> 
> Tested on x86_64-linux.
This is fine.

Though I don't see that it actually addressed the qemu or grub2 issues raised by
Martin L.  ISTM those really should be a separate bug independent of the wrong-
bound in the diagnostic.  It looks like Martin L's claim is that for qemu & 
grub2
we've got new false positives from the warning.  Thoughts?

Jeff

Re: [PATCH] realloc() was missing from parts of the documentation

[Jeff Law via Gcc-patches]

On Mon, 2020-04-13 at 06:25 -0600, Zackery Spytz via Gcc-patches wrote:
> Hello,
> 
> The realloc() function was missing from parts of the documentation!
THanks.  Applied.
jeff
> 

Re: [PATCH] correct format of flexible array members in diagnostics (PR c/92326)

[Martin Sebor via Gcc-patches]

On 4/13/20 1:25 PM, Jeff Law wrote:

On Mon, 2020-04-13 at 12:39 -0600, Martin Sebor via Gcc-patches wrote:

GCC 10 has changed the formatting of zero-length arrays in diagnostics
to include their bound, but it also inadvertently added the zero bound
to flexible array members which are confusingly represented differently
between the C and C++ front ends.

The attached patch corrects the problem so both zero-length arrays and
flexible array members are formatted consistently by both front ends
(i.e., as T[0] and T[]).

Tested on x86_64-linux.

This is fine.

Though I don't see that it actually addressed the qemu or grub2 issues raised by
Martin L.  ISTM those really should be a separate bug independent of the wrong-
bound in the diagnostic.  It looks like Martin L's claim is that for qemu & 
grub2
we've got new false positives from the warning.  Thoughts?


I don't see how this could cause false positives, unless something
is set up to filter out the specific text of the warning and this
change makes the filtering fail.

I had asked Martin (CC'd) about it but didn't understand his answer
in c#5 on the bug.  Martin?

M.

[committed] coroutines: Rename the coroutines cpp builtin.

[Iain Sandoe]

Hi,

this is a small piece of housekeeping:

The current standard draft (n4861) renamed the cpp builtin for
coroutines to ‘__cpp_impl_coroutine’.  No other change.

(NOTE; there are other defines to be added to  and  but 
that’s
 a separate issue from this renaming).

tested on x86_64-darwin16
applied to master as obvious

thanks
Iain

gcc/c-family/ChangeLog:

2020-04-13  Iain Sandoe  

* c-cppbuiltin.c (c_cpp_builtins): Update coroutines builtin
define, per n4861.

gcc/testsuite/ChangeLog:

2020-04-13  Iain Sandoe  

* g++.dg/coroutines/coro-pre-proc.C: Update coroutines builtin
define, per n4861.
* g++.dg/coroutines/coro.h: Likewise.

libstdc++-v3/ChangeLog:

2020-04-13  Iain Sandoe  

* include/std/coroutine: Update coroutines builtin define,
per n4861.

 2020-04-02  Richard Biener  
 
PR c/94392
diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
index 5532ae46ae1..db91a36794a 100644
--- a/gcc/c-family/c-cppbuiltin.c
+++ b/gcc/c-family/c-cppbuiltin.c
@@ -1012,7 +1012,7 @@ c_cpp_builtins (cpp_reader *pfile)
 cpp_define (pfile, "__cpp_concepts=201507L");
 }
   if (flag_coroutines)
-   cpp_define (pfile, "__cpp_coroutines=201902L"); /* n4835, C++20 CD */
+   cpp_define (pfile, "__cpp_impl_coroutine=201902L"); /* n4861, DIS */
   if (flag_tm)
/* Use a value smaller than the 201505 specified in
   the TS, since we don't yet support atomic_cancel.  */

diff --git a/gcc/testsuite/g++.dg/coroutines/coro-pre-proc.C 
b/gcc/testsuite/g++.dg/coroutines/coro-pre-proc.C
index f22a5e08332..eacdb35d3c7 100644
--- a/gcc/testsuite/g++.dg/coroutines/coro-pre-proc.C
+++ b/gcc/testsuite/g++.dg/coroutines/coro-pre-proc.C
@@ -1,9 +1,9 @@
 // Only need to compile this, with the default options from the .exp.
 
-#ifndef __cpp_coroutines
+#ifndef __cpp_impl_coroutine
 #error "coroutines should engaged."
 #endif
 
-#if __cpp_coroutines != 201902L
+#if __cpp_impl_coroutine != 201902L
 #error "coroutine version out of sync."
 #endif
diff --git a/gcc/testsuite/g++.dg/coroutines/coro.h 
b/gcc/testsuite/g++.dg/coroutines/coro.h
index 31336549f82..a1bd38b8d12 100644
--- a/gcc/testsuite/g++.dg/coroutines/coro.h
+++ b/gcc/testsuite/g++.dg/coroutines/coro.h
@@ -29,7 +29,7 @@ namespace coro = std::experimental;
 // Fragments (with short-cuts) to mimic enough of the library header to
 // make some progress.
 
-#  if __cpp_coroutines
+#  if __cpp_impl_coroutine
 
 namespace std {
 inline namespace __n4835 {

diff --git a/libstdc++-v3/include/std/coroutine 
b/libstdc++-v3/include/std/coroutine
index 363402330e4..2e45c451450 100644
--- a/libstdc++-v3/include/std/coroutine
+++ b/libstdc++-v3/include/std/coroutine
@@ -54,7 +54,7 @@ namespace std _GLIBCXX_VISIBILITY (default)
 {
   _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
-#if __cpp_coroutines
+#if __cpp_impl_coroutine
   inline namespace __n4835 {
 
   // 17.12.2 coroutine traits

Re: [PATCH] c++: Infinite diagnostic loop with decltype([]{}) [PR94521]

[Jason Merrill via Gcc-patches]

On 4/12/20 9:48 AM, Patrick Palka wrote:

We are hitting a recursive loop when printing the signature of a function
containing a decltype([]{}) type.  The loop is

   dump_function_decl -> dump_substitution
 -> dump_template_bindings
 -> dump_type
 -> dump_aggr_type
 -> dump_scope -> dump_function_decl

and we loop because dump_template_bindings wants to print the resolved type of
decltype([]{}) (i.e. just a lambda type), so it calls dump_aggr_type, which
wants to print the function scope of the lambda type.  But the function scope of
the lambda type is the function which we're in the middle of printing.

This patch breaks the loop by passing TFF_NO_FUNCTION_ARGUMENTS to
dump_function_decl from dump_scope, so that we avoid recursing into
dump_substitution and ultimately looping.

This also means we no longer print a "[with ...]" clause when printing a
function template scope, and we instead just print its template argument list in
a more natural way, e.g. instead of
 foo(int, char) [with T=bool]::x
we would now print
 foo::x
which seems like an improvement on its own.


Hmm.  That no longer distinguishes between multiple template overloads 
of foo, but I suppose we should always print the full function as part 
of the same diagnostic, so having a terser form here is OK.



The full signature of the function 'spam' in the below testcase is now
   void spam(decltype ()*) [with T = int; decltype () = 
spam::]

Successfully bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK to commit?


OK.


gcc/cp/ChangeLog:

PR c++/94521
* error.c (dump_scope): Pass TFF_NO_FUNCTION_ARGUMENTS to
dump_function_decl when printing a function template instantiation as a
scope.

gcc/testsuite/ChangeLog:

PR c++/94521
* g++.dg/cpp2a/lambda-uneval12.C: New test.
---
  gcc/cp/error.c   |  2 ++
  gcc/testsuite/g++.dg/cpp2a/lambda-uneval12.C | 13 +
  2 files changed, 15 insertions(+)
  create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-uneval12.C

diff --git a/gcc/cp/error.c b/gcc/cp/error.c
index 61d1218dc90..98c163db572 100644
--- a/gcc/cp/error.c
+++ b/gcc/cp/error.c
@@ -211,6 +211,8 @@ dump_scope (cxx_pretty_printer *pp, tree scope, int flags)
  }
else if ((flags & TFF_SCOPE) && TREE_CODE (scope) == FUNCTION_DECL)
  {
+  if (DECL_USE_TEMPLATE (scope))
+   f |= TFF_NO_FUNCTION_ARGUMENTS;
dump_function_decl (pp, scope, f);
pp_cxx_colon_colon (pp);
  }
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-uneval12.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval12.C
new file mode 100644
index 000..24d2e701e44
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval12.C
@@ -0,0 +1,13 @@
+// PR c++/94521
+// { dg-do compile { target c++2a } }
+
+template 
+void spam(decltype([]{}) *s)
+{
+  static_assert(__is_same(int, decltype(s))); // { dg-error "static assertion 
failed" }
+}
+
+void foo()
+{
+  spam(nullptr);
+}

Re: [PATCH PR00002] aarch64：Add an error message in large code model for ilp32

[Wilco Dijkstra]

Hi Duanbo,

> This is a simple fix for pr94577.
> The option -mabi=ilp32 should not be used in large code model. Like x86, 
> using -mx32 and -mcmodel=large together will result in an error message.
> On aarch64, there is no error message for this option conflict.
> A solution to this problem can be found in the attached patch.
> Bootstrap and tested on aarch64 Linux platform. No new regression witnessed.
> Any suggestion?  

Thanks for your patch, more than 4GB doesn't make any sense with ILP32 indeed.
A few suggestions:

It would be good to also update the documentation for -mcmodel=large to state 
it is
incompatible with -fpic, -fPIC and -mabi=ilp32.

The patch adds a another switch statement on mcmodel that ignores the previous
processing done (which may changes the selected mcmodel). It would be safer and
more concise to use one switch at the top level and in each case use an if 
statement
to handle the special cases.

A few minor nitpics:

+   PR  target/94577
+   * gcc.target/aarch64/pr94577.c : New test

Just like comments, there should be a '.' at the end of changelog entries.

AFAICT the format isn't exactly specified, but the email header should be like:

[PATCH][AArch64] PR94577: Add an error message in large code model for ilp32

Sometimes the PR number is also placed in brackets.

Cheers,
Wilco

New Swedish PO file for 'gcc' (version 10.1-b20200322)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-10.1-b20200322.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[committed] update & correct -Wall and -Wrestrict documentation

[Martin Sebor via Gcc-patches]

-Wall was missing a couple of options and -Wrestrict mentioned
its negative form as if was enabled by default (it's in -Wall).
I just pushed the patch below to correct these minor mistakes:

  https://gcc.gnu.org/pipermail/gcc-cvs/2020-April/279540.html

Martin

Re: [PATCH][PR target/94542]Don't allow PC-relative addressing for TLS data

[acsawdey via Gcc-patches]

On 2020-04-13 10:08, will schmidt wrote:

On Fri, 2020-04-10 at 18:00 -0500, acsawdey via Gcc-patches wrote:

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 2b6613bcb7e..c77e60a718f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -24824,15 +24824,21 @@ address_to_insn_form (rtx addr,
   if (GET_RTX_CLASS (GET_CODE (addr)) == RTX_AUTOINC)
 return INSN_FORM_UPDATE;

-  /* Handle PC-relative symbols and labels.  Check for both local and 
external

- symbols.  Assume labels are always local.  */
+  /* Handle PC-relative symbols and labels.  Check for both local and
+ external symbols.  Assume labels are always local. TLS symbols
+ are not PC-relative.  */


Does the assumption need a qualifier for target rs6000?  (or some 
combination
of TLS/PC-relative?)   There are users of the LABEL_REF_NONLOCAL_P() 
for

mips,pa,sparc targets.


Yeah I think it's reasonable to say "TLS symbols are not PC-relative on 
target

rs6000." That was certainly my intent.

Aaron

[PATCH] xtensa: fix PR target/94584

[Max Filippov via Gcc-patches]

Patterns zero_extendhisi2, zero_extendqisi2 and extendhisi2_internal can
load value from memory, but they don't treat volatile memory correctly.
Add %v1 before load instructions to emit 'memw' instruction when
-mserialize-volatile is in effect.

2020-04-13  Max Filippov  
gcc/
* config/xtensa/xtensa.md (zero_extendhisi2, zero_extendqisi2)
(extendhisi2_internal): Add %v1 before the load instructions.

gcc/testsuite/
* gcc.target/xtensa/pr94584.c: New test.
---
 gcc/config/xtensa/xtensa.md   |  6 +++---
 gcc/testsuite/gcc.target/xtensa/pr94584.c | 24 +++
 2 files changed, 27 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/xtensa/pr94584.c

diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index 5b803d3cbe65..749fe477d562 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -538,7 +538,7 @@
   ""
   "@
extui\t%0, %1, 0, 16
-   l16ui\t%0, %1"
+   %v1l16ui\t%0, %1"
   [(set_attr "type""arith,load")
(set_attr "mode""SI")
(set_attr "length"  "3,3")])
@@ -549,7 +549,7 @@
   ""
   "@
extui\t%0, %1, 0, 8
-   l8ui\t%0, %1"
+   %v1l8ui\t%0, %1"
   [(set_attr "type""arith,load")
(set_attr "mode""SI")
(set_attr "length"  "3,3")])
@@ -575,7 +575,7 @@
   ""
   "@
sext\t%0, %1, 15
-   l16si\t%0, %1"
+   %v1l16si\t%0, %1"
   [(set_attr "type""arith,load")
(set_attr "mode""SI")
(set_attr "length"  "3,3")])
diff --git a/gcc/testsuite/gcc.target/xtensa/pr94584.c 
b/gcc/testsuite/gcc.target/xtensa/pr94584.c
new file mode 100644
index ..1577285b8a68
--- /dev/null
+++ b/gcc/testsuite/gcc.target/xtensa/pr94584.c
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mserialize-volatile" } */
+
+unsigned long load32 (volatile unsigned long *s)
+{
+  return *s;
+}
+
+short load16s (volatile short *s)
+{
+  return *s;
+}
+
+unsigned short load16u (volatile unsigned short *s)
+{
+  return *s;
+}
+
+unsigned char load8 (volatile unsigned char *s)
+{
+  return *s;
+}
+
+/* { dg-final { scan-assembler-times "memw" 4 } } */
-- 
2.20.1

[PATCH] c++: Improve redeclared parameter name diagnostic [PR94588]

[Marek Polacek via Gcc-patches]

While reviewing [basic.scope.param] I noticed we don't show the location
of the previous declaration when giving an error about "A parameter name
shall not be redeclared in the outermost block of the function definition".

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

PR c++/94588
* name-lookup.c (check_local_shadow): Add an inform call.

* g++.dg/diagnostic/redeclaration-1.C: Add dg-message.
---
 gcc/cp/name-lookup.c  | 9 ++---
 gcc/testsuite/g++.dg/diagnostic/redeclaration-1.C | 2 +-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 8dd0b0d723e..9b68b15be60 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -2670,8 +2670,8 @@ check_local_shadow (tree decl)
}
   /* Don't complain if it's from an enclosing function.  */
   else if (DECL_CONTEXT (old) == current_function_decl
- && TREE_CODE (decl) != PARM_DECL
- && TREE_CODE (old) == PARM_DECL)
+  && TREE_CODE (decl) != PARM_DECL
+  && TREE_CODE (old) == PARM_DECL)
{
  /* Go to where the parms should be and see if we find
 them there.  */
@@ -2681,11 +2681,14 @@ check_local_shadow (tree decl)
/* Skip the ctor/dtor cleanup level.  */
b = b->level_chain;
 
- /* ARM $8.3 */
+ /* [basic.scope.param] A parameter name shall not be redeclared
+in the outermost block of the function definition.  */
  if (b->kind == sk_function_parms)
{
  error_at (DECL_SOURCE_LOCATION (decl),
"declaration of %q#D shadows a parameter", decl);
+ inform (DECL_SOURCE_LOCATION (old),
+ "%q#D previously declared here", old);
  return;
}
}
diff --git a/gcc/testsuite/g++.dg/diagnostic/redeclaration-1.C 
b/gcc/testsuite/g++.dg/diagnostic/redeclaration-1.C
index a41a2b8f1c4..f0e43d414a8 100644
--- a/gcc/testsuite/g++.dg/diagnostic/redeclaration-1.C
+++ b/gcc/testsuite/g++.dg/diagnostic/redeclaration-1.C
@@ -1,5 +1,5 @@
 void
-foo (int i)
+foo (int i) // { dg-message "10:.int i. previously declared here" }
 {
   int i  // { dg-error "7:declaration of .int i. shadows a parameter" }
 (0);

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

set_rtx_cost used wrongly, should be set_src_cost

[Alan Modra via Gcc-patches]

I believe set_rtx_cost is meant to handle a SET, not a PLUS as is
passed in these two locations.  Using the proper function for a PLUS
doesn't make a huge difference: the only arg change to rtx_cost of any
consequence is outer_code of SET rather than INSN.  A mode of
word_mode rather than VOIDmode makes no difference at all since the
mode is taken from the PLUS.  An opno of 1 rather than 4 also doesn't
change anything since the only backend that does anything with opno
(besides pass it back to a recursive rtx_cost call) is nios2, and
there "opno == 0" is the only use of opno.

Bootstrapped and regression tested powerpc64le-linux and x86_64-linux.
OK for next stage1?

* tree-ssa-reassoc.c (optimize_range_tests_to_bit_test): Replace
set_rtx_cost with set_src_cost.
* tree-switch-conversion.c (bit_test_cluster::emit): Likewise.

diff --git a/gcc/tree-ssa-reassoc.c b/gcc/tree-ssa-reassoc.c
index ec1c033a2cf..af8faf2e6ea 100644
--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -3208,8 +3208,9 @@ optimize_range_tests_to_bit_test (enum tree_code opcode, 
int first, int length,
  HOST_WIDE_INT m = tree_to_uhwi (lowi);
  rtx reg = gen_raw_REG (word_mode, 1);
  bool speed_p = optimize_bb_for_speed_p (gimple_bb (stmt));
- cost_diff = set_rtx_cost (gen_rtx_PLUS (word_mode, reg,
- GEN_INT (-m)), speed_p);
+ cost_diff = set_src_cost (gen_rtx_PLUS (word_mode, reg,
+ GEN_INT (-m)),
+   word_mode, speed_p);
  rtx r = immed_wide_int_const (mask, word_mode);
  cost_diff += set_src_cost (gen_rtx_AND (word_mode, reg, r),
 word_mode, speed_p);
diff --git a/gcc/tree-switch-conversion.c b/gcc/tree-switch-conversion.c
index bf910dd62b5..4b435941d12 100644
--- a/gcc/tree-switch-conversion.c
+++ b/gcc/tree-switch-conversion.c
@@ -1541,8 +1541,9 @@ bit_test_cluster::emit (tree index_expr, tree index_type,
   HOST_WIDE_INT m = tree_to_uhwi (minval);
   rtx reg = gen_raw_REG (word_mode, 1);
   bool speed_p = optimize_insn_for_speed_p ();
-  cost_diff = set_rtx_cost (gen_rtx_PLUS (word_mode, reg,
- GEN_INT (-m)), speed_p);
+  cost_diff = set_src_cost (gen_rtx_PLUS (word_mode, reg,
+ GEN_INT (-m)),
+   word_mode, speed_p);
   for (i = 0; i < count; i++)
{
  rtx r = immed_wide_int_const (test[i].mask, word_mode);

-- 
Alan Modra
Australia Development Lab, IBM

[PATCH], Fix target/94557 PowerPC regression on GCC 9 (variable vec_extract)

[Michael Meissner via Gcc-patches]

This patch fixes PR target/94557, on PowerPC.  It was a regression on the GCC 9
branch caused by my recent patch for PR target/93932.

The patch for 93932 was a back port from the master branch of a fix for the
vec_extract built-in function.  This patch fixes the case where we are
optimizing a vector extract from an vector in memory to be a scalar load
instead of loading the vector to a register and then doing an extract.  In the
tests that fail, the index for the vector extract built-in function goes
outside of the bounds of the vector.

In the master branch, I had made a previous change to limit the variable
extraction to be valid via masking.  I had done this as part of optimizing
vector extracts for PC-relative addresses.  When I back ported the fix for PR
target/93932, I did not include this masking.  I had originally only tested the
fix for PR target/93932 on a little endian power8 system.  The test cases that
fail do not fail on a little endian power8 system, but they would fail on a
little endian power9 system and also a big endian power8 system.

This patch adds in the masking of the vector index that is in the master
branch.  I re-implemented the change for GCC 9, since the changes on the master
branch are more extensive, and include PC-relative support that is not in GCC
9.

I have tested this patch via compiler bootstrap and running the make check
options on the following systems.  There were no regressions in the run, and
several of the tests that started to fail with my last patch are now fixed.
Can I check this into the GCC 9 branch?

little endian power8 running Linux
little endian power9 running Linux
big endian power8 running Linux

2020-04-13  Michael Meissner  

PR target/94557
* config/rs6000/rs6000.c (rs6000_adjust_vec_address): Mask
variable vector extract index so it does not go beyond the vector
when extracting a vector element from memory.  This change is a
simplification of the 2020-02-03 patch that went into the trunk.

--- /tmp/4XFFqK_rs6000.c2020-04-13 15:28:33.514011024 -0500
+++ gcc/config/rs6000/rs6000.c  2020-04-13 14:24:01.296932921 -0500
@@ -7047,18 +7047,25 @@ rs6000_adjust_vec_address (rtx scalar_re
 element_offset = GEN_INT (INTVAL (element) * scalar_size);
   else
 {
+  /* Mask the element to make sure the element number is between 0 and the
+maximum number of elements - 1 so that we don't generate an address
+outside the vector.  */
+  rtx num_ele_m1 = GEN_INT (GET_MODE_NUNITS (GET_MODE (mem)) - 1);
+  rtx and_op = gen_rtx_AND (Pmode, element, num_ele_m1);
+  emit_insn (gen_rtx_SET (base_tmp, and_op));
+
   int byte_shift = exact_log2 (scalar_size);
   gcc_assert (byte_shift >= 0);
 
   if (byte_shift == 0)
-   element_offset = element;
+   element_offset = base_tmp;
 
   else
{
  if (TARGET_POWERPC64)
-   emit_insn (gen_ashldi3 (base_tmp, element, GEN_INT (byte_shift)));
+   emit_insn (gen_ashldi3 (base_tmp, base_tmp, GEN_INT (byte_shift)));
  else
-   emit_insn (gen_ashlsi3 (base_tmp, element, GEN_INT (byte_shift)));
+   emit_insn (gen_ashlsi3 (base_tmp, base_tmp, GEN_INT (byte_shift)));
 
  element_offset = base_tmp;
}


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] reject scalar array initialization with nullptr [PR94510]

[Jason Merrill via Gcc-patches]

On 4/12/20 5:49 PM, Martin Sebor wrote:

On 4/10/20 8:52 AM, Jason Merrill wrote:

On 4/9/20 4:23 PM, Martin Sebor wrote:

On 4/9/20 1:32 PM, Jason Merrill wrote:

On 4/9/20 3:24 PM, Martin Sebor wrote:

On 4/9/20 1:03 PM, Jason Merrill wrote:

On 4/8/20 1:23 PM, Martin Sebor wrote:

On 4/7/20 3:36 PM, Marek Polacek wrote:

On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote:

On 4/7/20 1:50 PM, Marek Polacek wrote:
On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via 
Gcc-patches wrote:
Among the numerous regressions introduced by the change 
committed
to GCC 9 to allow string literals as template arguments is a 
failure
to recognize the C++ nullptr and GCC's __null constants as 
pointers.
For one, I didn't realize that nullptr, being a null pointer 
constant,
doesn't have a pointer type, and two, I didn't think of 
__null (which

is a special integer constant that NULL sometimes expands to).

The attached patch adjusts the special handling of trailing zero
initializers in reshape_init_array_1 to recognize both kinds of
constants and avoid treating them as zeros of the array integer
element type.  This restores the expected diagnostics when 
either

constant is used in the initializer list.

Martin


PR c++/94510 - nullptr_t implicitly cast to zero twice in 
std::array


gcc/cp/ChangeLog:

PR c++/94510
* decl.c (reshape_init_array_1): Exclude mismatches with 
all kinds

of pointers.

gcc/testsuite/ChangeLog:

PR c++/94510
* g++.dg/init/array57.C: New test.
* g++.dg/init/array58.C: New test.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index a127734af69..692c8ed73f4 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6041,9 +6041,14 @@ reshape_init_array_1 (tree elt_type, 
tree max_index, reshape_iter *d,

   TREE_CONSTANT (new_init) = false;
 /* Pointers initialized to strings must be treated 
as non-zero

- even if the string is empty.  */
+ even if the string is empty.  Handle all kinds of 
pointers,
+ including std::nullptr and GCC's __nullptr, neither of 
which

+ has a pointer type.  */
 tree init_type = TREE_TYPE (elt_init);
-  if (POINTER_TYPE_P (elt_type) != POINTER_TYPE_P 
(init_type)

+  bool init_is_ptr = (POINTER_TYPE_P (init_type)
+  || NULLPTR_TYPE_P (init_type)
+  || null_node_p (elt_init));
+  if (POINTER_TYPE_P (elt_type) != init_is_ptr
 || !type_initializer_zero_p (elt_type, elt_init))
   last_nonzero = index;


It looks like this still won't handle e.g. pointers to member 
functions,

e.g.

struct S { };
int arr[3] = { (void (S::*) ()) 0, 0, 0 };

would still be accepted.  You could use TYPE_PTR_OR_PTRMEM_P 
instead of

POINTER_TYPE_P to catch this case.


Good catch!  That doesn't fail because unlike null data member 
pointers
which are represented as -1, member function pointers are 
represented

as a zero.

I had looked for an API that would answer the question: "is this
expression a pointer?" without having to think of all the 
different
kinds of them but all I could find was null_node_p().  Is this 
a rare,
isolated case that having an API like that wouldn't be worth 
having

or should I add one like in the attached update?

Martin


PR c++/94510 - nullptr_t implicitly cast to zero twice in 
std::array


gcc/cp/ChangeLog:

PR c++/94510
* decl.c (reshape_init_array_1): Exclude mismatches with 
all kinds

of pointers.
* gcc/cp/cp-tree.h (null_pointer_constant_p): New function.


(Drop the gcc/cp/.)

+/* Returns true if EXPR is a null pointer constant of any 
type.  */

+
+inline bool
+null_pointer_constant_p (tree expr)
+{
+  STRIP_ANY_LOCATION_WRAPPER (expr);
+  if (expr == null_node)
+    return true;
+  tree type = TREE_TYPE (expr);
+  if (NULLPTR_TYPE_P (type))
+    return true;
+  if (POINTER_TYPE_P (type))
+    return integer_zerop (expr);
+  return null_member_pointer_value_p (expr);
+}
+


We already have a null_ptr_cst_p so it would be sort of 
confusing to have
this as well.  But are you really interested in whether it's a 
null pointer,

not just a pointer?


The goal of the code is to detect a mismatch in "pointerness" 
between
an initializer expression and the type of the initialized 
element, so

it needs to know if the expression is a pointer (non-nulls pointers
are detected in type_initializer_zero_p).  That means testing a 
number

of IMO unintuitive conditions:

   TYPE_PTR_OR_PTRMEM_P (TREE_TYPE (expr))
   || NULLPTR_TYPE_P (TREE_TYPE (expr))
   || null_node_p (expr)

I don't know if this type of a query is common in the C++ FE but 
unless
this is an isolated use case then besides fixing the bug I 
thought it
would be nice to make it easier to get the test above right, or 
at least

come close to it.

Since null_pointer_constant_p already exists (but isn't suitable 
here

because it returns true for plain literal zeros)


Why is that unsuitable?  A literal zero is a perfectly good 
zero-initializer for a pointer.


Right, that's 

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Jason Merrill via Gcc-patches]

On 4/13/20 2:49 PM, Patrick Palka wrote:

On Mon, 13 Apr 2020, Jason Merrill wrote:


On 4/12/20 9:43 AM, Patrick Palka wrote:

On Sat, 11 Apr 2020, Jason Merrill wrote:


On 4/10/20 5:47 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Jason Merrill wrote:

On 4/10/20 2:15 PM, Patrick Palka wrote:

On Fri, 10 Apr 2020, Patrick Palka wrote:


On Fri, 10 Apr 2020, Jason Merrill wrote:


On 4/10/20 1:04 PM, Patrick Palka wrote:

On Thu, 9 Apr 2020, Patrick Palka wrote:

On Thu, 9 Apr 2020, Jason Merrill wrote:


On 4/8/20 7:49 PM, Patrick Palka wrote:

When evaluating the initializer of 'a' in the following
example

struct A { A *p = this; };
constexpr A foo() { return {}; }
constexpr A a = foo();

the PLACEHOLDER_EXPR for 'this' in the aggregate
initializer
returned
by foo
gets resolved to the RESULT_DECL of foo.  But due to
guaranteed
RVO,
the
'this'
should really be resolved to '&a'.



It seems to me that the right approach would be to
immediately
resolve
the
PLACEHOLDER_EXPR to the correct target object during
evaluation
of
'foo()',
so
that we could use 'this' to access objects adjacent to
the
current
object in
the
ultimate storage location.  (I think #c2 of PR c++/94537
is
an
example
of
such
usage of 'this', which currently doesn't work.  But as
#c1
shows
we
don't
seem
to handle this case correctly in non-constexpr
initialization
either.)


As I commented in the PR, the standard doesn't require
this to
work
because A
is trivially copyable, and our ABI makes it impossible.
But
there's
still a
constexpr bug when we add

A() = default; A(const A&);

clang doesn't require the constructors to make this work
for
constant
initialization, but similarly can't make it work for
non-constant
initialization.


That makes a lot of sense, thanks for the detailed
explanation.




I haven't yet been able to make a solution using the
above
approach
work --
making sure we use the ultimate object instead of the
RESULT_DECL
whenever
we
access ctx->global->values is proving to be tricky and
subtle.


Do we need to go through ctx->global->values?  Would it
work
for
the
RESULT_DECL case in cxx_eval_constant_expression to go to
straight
to
ctx->object or ctx->ctor instead?


I attempted that at some point, but IIRC we still end up not
resolving
some RESULT_DECLs because not all of them get processed
through
cxx_eval_constant_expression before we manipulate
ctx->global->values
with them.  I'll try this approach more carefully and report
back
with
more specifics.


It turns out that immediately resolving RESULT_DECLs/'this' to
the
ultimate ctx->object would not interact well with
constexpr_call
caching:

   struct A { A() = default; A(const A&); A *ap = this; };
   constexpr A foo() { return {}; }
   constexpr A a = foo();
   constexpr A b = foo();
   static_assert(b.ap == &b); // fails

Evaluation of the first call to foo() returns {&a}, since we
resolve
'this' to &a due to guaranteed RVO, and we cache this result.
Evaluation of the second call to foo() just returns the cached
result
from the constexpr_call cache, and so we get {&a} again.

So it seems we would have to mark the result of a constexpr
call
as
not
cacheable whenever this RVO applies during its evaluation,
even
when
doing the RVO has no observable difference in the final result
(i.e.
the
constructor does not try to save the 'this' pointer).

Would the performance impact of disabling caching whenever RVO
applies
during constexpr call evaluation be worth it, or should we go
with
something like my first patch which "almost works," and which
marks a
constexpr call as not cacheable only when we replace a
RESULT_DECL
in
the result of the call?


Could we search through the result of the call for ctx->object
and
cache
if we
don't find it?


Hmm, I think the result of the call could still depend on
ctx->object
without ctx->object explicitly appearing in the result.  Consider
the
following testcase:

  struct A {
A() = default; A(const A&);
constexpr A(const A *q) : d{this - p} { }


Oops sorry, that 'q' should be a 'p'.


long d = 0;
  };

  constexpr A baz(const A *q) { return A(p); };


And same here.


  constexpr A a = baz(&a);
  constexpr A b = baz(&a); // no error

The initialization of 'b' should be ill-formed, but the result of
the
first call to baz(&a) would be {0}, so we would cache it and then
reuse
the result when initializing 'b'.


Ah, true.  Can we still cache if we're initializing something that
isn't
TREE_STATIC?


Hmm, we correctly compile the analogous non-TREE_STATIC testcase

   struct A {
 A() = default; A(const A&);
 constexpr A(const A *p) : d{this == p} { }
 bool d;
   };

   constexpr A baz(const A *p) { return A(p); }

   void foo() {
 constexpr A x = baz(&x);
 constexpr A y = baz(&x);
 static_assert(!y.d);
   }

because the calls 'baz(&x)' are considered to have non-constant
arguments.


Unfor

Re: [PATCH] c++: Improve redeclared parameter name diagnostic [PR94588]

[Jason Merrill via Gcc-patches]

On 4/13/20 7:43 PM, Marek Polacek wrote:

While reviewing [basic.scope.param] I noticed we don't show the location
of the previous declaration when giving an error about "A parameter name
shall not be redeclared in the outermost block of the function definition".

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


OK.


PR c++/94588
* name-lookup.c (check_local_shadow): Add an inform call.

* g++.dg/diagnostic/redeclaration-1.C: Add dg-message.
---
  gcc/cp/name-lookup.c  | 9 ++---
  gcc/testsuite/g++.dg/diagnostic/redeclaration-1.C | 2 +-
  2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 8dd0b0d723e..9b68b15be60 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -2670,8 +2670,8 @@ check_local_shadow (tree decl)
}
/* Don't complain if it's from an enclosing function.  */
else if (DECL_CONTEXT (old) == current_function_decl
- && TREE_CODE (decl) != PARM_DECL
- && TREE_CODE (old) == PARM_DECL)
+  && TREE_CODE (decl) != PARM_DECL
+  && TREE_CODE (old) == PARM_DECL)
{
  /* Go to where the parms should be and see if we find
 them there.  */
@@ -2681,11 +2681,14 @@ check_local_shadow (tree decl)
/* Skip the ctor/dtor cleanup level.  */
b = b->level_chain;
  
-	  /* ARM $8.3 */

+ /* [basic.scope.param] A parameter name shall not be redeclared
+in the outermost block of the function definition.  */
  if (b->kind == sk_function_parms)
{
  error_at (DECL_SOURCE_LOCATION (decl),
"declaration of %q#D shadows a parameter", decl);
+ inform (DECL_SOURCE_LOCATION (old),
+ "%q#D previously declared here", old);
  return;
}
}
diff --git a/gcc/testsuite/g++.dg/diagnostic/redeclaration-1.C 
b/gcc/testsuite/g++.dg/diagnostic/redeclaration-1.C
index a41a2b8f1c4..f0e43d414a8 100644
--- a/gcc/testsuite/g++.dg/diagnostic/redeclaration-1.C
+++ b/gcc/testsuite/g++.dg/diagnostic/redeclaration-1.C
@@ -1,5 +1,5 @@
  void
-foo (int i)
+foo (int i) // { dg-message "10:.int i. previously declared here" }
  {
int i  // { dg-error "7:declaration of .int i. shadows a parameter" }
  (0);

base-commit: 09f041390245da60411a9f0e08c4bedf7430585a

Re: [PATCH] Fix use of singleton in optinfo framework

[Hans-Peter Nilsson]

On Mon, 6 Apr 2020, Gustavo Romero via Gcc-patches wrote:

> Currently an use of get() method of dump_context singleton in optinfo
> framework causes a new class to be instantiated, which calls the singleton
> dtor when the class is destroyed, freeing memory that is referenced after
> free() is called, generating an ICE error.
>
> This commit fixes the issue by using singleton's static member get()
> directly to get the singleton's active instance, which doesn't instantiate
> a new class, so no dtor is called.
>
> gcc/Changelog:
> 2020-04-06  Gustavo Romero  
>
>   * dumpfile.c:
>   (selftest::temp_dump_context::temp_dump_context): Fix ctor.

Better formatted ChangeLogentry; removing ":" (and breaking at
column 70 seems better than after with leaving a single word on
the next line):

* dumpfile.c (selftest::temp_dump_context::temp_dump_context):
Fix ctor.

Sadly this patch doesn't fix PR bootstrap/87252; I just checked
against f8e72b8d9f2:f81653ba8c1:2dd4ceacd8b (truncated from
LAST_UPDATED; I don't remember which field is the actual
commit).

brgds, H-P

Re: [PATCH] c++: Stray RESULT_DECLs in result of constexpr function call [PR94034]

[Patrick Palka via Gcc-patches]

On Mon, 13 Apr 2020, Jason Merrill wrote:

> On 4/13/20 2:49 PM, Patrick Palka wrote:
> > On Mon, 13 Apr 2020, Jason Merrill wrote:
> > 
> > > On 4/12/20 9:43 AM, Patrick Palka wrote:
> > > > On Sat, 11 Apr 2020, Jason Merrill wrote:
> > > > 
> > > > > On 4/10/20 5:47 PM, Patrick Palka wrote:
> > > > > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > > > > > On 4/10/20 2:15 PM, Patrick Palka wrote:
> > > > > > > > On Fri, 10 Apr 2020, Patrick Palka wrote:
> > > > > > > > 
> > > > > > > > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > > > > > > > 
> > > > > > > > > > On 4/10/20 1:04 PM, Patrick Palka wrote:
> > > > > > > > > > > On Thu, 9 Apr 2020, Patrick Palka wrote:
> > > > > > > > > > > > On Thu, 9 Apr 2020, Jason Merrill wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > On 4/8/20 7:49 PM, Patrick Palka wrote:
> > > > > > > > > > > > > > When evaluating the initializer of 'a' in the
> > > > > > > > > > > > > > following
> > > > > > > > > > > > > > example
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > struct A { A *p = this; };
> > > > > > > > > > > > > > constexpr A foo() { return {}; }
> > > > > > > > > > > > > > constexpr A a = foo();
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > the PLACEHOLDER_EXPR for 'this' in the aggregate
> > > > > > > > > > > > > > initializer
> > > > > > > > > > > > > > returned
> > > > > > > > > > > > > > by foo
> > > > > > > > > > > > > > gets resolved to the RESULT_DECL of foo.  But due to
> > > > > > > > > > > > > > guaranteed
> > > > > > > > > > > > > > RVO,
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > 'this'
> > > > > > > > > > > > > > should really be resolved to '&a'.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > It seems to me that the right approach would be to
> > > > > > > > > > > > > > immediately
> > > > > > > > > > > > > > resolve
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > PLACEHOLDER_EXPR to the correct target object during
> > > > > > > > > > > > > > evaluation
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > 'foo()',
> > > > > > > > > > > > > > so
> > > > > > > > > > > > > > that we could use 'this' to access objects adjacent
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > current
> > > > > > > > > > > > > > object in
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > ultimate storage location.  (I think #c2 of PR
> > > > > > > > > > > > > > c++/94537
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > an
> > > > > > > > > > > > > > example
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > such
> > > > > > > > > > > > > > usage of 'this', which currently doesn't work.  But
> > > > > > > > > > > > > > as
> > > > > > > > > > > > > > #c1
> > > > > > > > > > > > > > shows
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > seem
> > > > > > > > > > > > > > to handle this case correctly in non-constexpr
> > > > > > > > > > > > > > initialization
> > > > > > > > > > > > > > either.)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > As I commented in the PR, the standard doesn't require
> > > > > > > > > > > > > this to
> > > > > > > > > > > > > work
> > > > > > > > > > > > > because A
> > > > > > > > > > > > > is trivially copyable, and our ABI makes it
> > > > > > > > > > > > > impossible.
> > > > > > > > > > > > > But
> > > > > > > > > > > > > there's
> > > > > > > > > > > > > still a
> > > > > > > > > > > > > constexpr bug when we add
> > > > > > > > > > > > > 
> > > > > > > > > > > > > A() = default; A(const A&);
> > > > > > > > > > > > > 
> > > > > > > > > > > > > clang doesn't require the constructors to make this
> > > > > > > > > > > > > work
> > > > > > > > > > > > > for
> > > > > > > > > > > > > constant
> > > > > > > > > > > > > initialization, but similarly can't make it work for
> > > > > > > > > > > > > non-constant
> > > > > > > > > > > > > initialization.
> > > > > > > > > > > > 
> > > > > > > > > > > > That makes a lot of sense, thanks for the detailed
> > > > > > > > > > > > explanation.
> > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > I haven't yet been able to make a solution using the
> > > > > > > > > > > > > > above
> > > > > > > > > > > > > > approach
> > > > > > > > > > > > > > work --
> > > > > > > > > > > > > > making sure we use the ultimate object instead of
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > RESULT_DECL
> > > > > > > > > > > > > > whenever
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > access ctx->global->values is proving to be tricky
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > subtle.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Do we need to go through ctx->global->values?  Would
> > > > > > > > > > > > > it
> > > > > > > > > > > > > work
> > > > > > > > > > > > > for
> > > > > > > > > > > > > the
> > > > > > > > > > > > > RES

[PATCH v4] Fix alignment for local variable [PR90811]

[Kito Cheng]

 - The alignment for local variable was adjust during estimate_stack_frame_size,
   however it seems wrong spot to adjust that, expand phase will adjust that
   but it little too late to some gimple optimization, which rely on certain
   target hooks need to check alignment, forwprop is an example for
   that, result of simplify_builtin_call rely on the alignment on some
   target like ARM or RISC-V.

 - Exclude static local var and hard register var in the process of
   alignment adjustment.

 - This patch fix gfortran.dg/pr45636.f90 for arm and riscv.

 - Regression test on riscv32/riscv64 and x86_64-linux-gnu, no new fail
   introduced.

gcc/ChangeLog

PR target/90811
* Makefile.in (OBJS): Add tree-adjust-alignment.o.
* tree-adjust-alignment.cc (pass_data_adjust_alignment): New.
(pass_adjust_alignment): New.
(-pass_adjust_alignment::execute): New.
(make_pass_adjust_alignment): New.
* tree-pass.h (make_pass_adjust_alignment): New.
* passes.def: Add pass_adjust_alignment.
---
 gcc/Makefile.in  |  1 +
 gcc/passes.def   |  1 +
 gcc/tree-adjust-alignment.cc | 92 
 gcc/tree-pass.h  |  1 +
 4 files changed, 95 insertions(+)
 create mode 100644 gcc/tree-adjust-alignment.cc

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index fa9923bb270..9b73288f776 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1545,6 +1545,7 @@ OBJS = \
ubsan.o \
sanopt.o \
sancov.o \
+   tree-adjust-alignment.o \
tree-call-cdce.o \
tree-cfg.o \
tree-cfgcleanup.o \
diff --git a/gcc/passes.def b/gcc/passes.def
index 2bf2cb78fc5..92cbe587a8a 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -183,6 +183,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_oacc_device_lower);
   NEXT_PASS (pass_omp_device_lower);
   NEXT_PASS (pass_omp_target_link);
+  NEXT_PASS (pass_adjust_alignment);
   NEXT_PASS (pass_all_optimizations);
   PUSH_INSERT_PASSES_WITHIN (pass_all_optimizations)
   NEXT_PASS (pass_remove_cgraph_callee_edges);
diff --git a/gcc/tree-adjust-alignment.cc b/gcc/tree-adjust-alignment.cc
new file mode 100644
index 000..77f38f6949b
--- /dev/null
+++ b/gcc/tree-adjust-alignment.cc
@@ -0,0 +1,92 @@
+/* Adjust alignment for local variable.
+   Copyright (C) 2003-2020 Free Software Foundation, Inc.
+   Contributed by Dorit Naishlos 
+
+This file is part of GCC.
+
+GCC 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.
+
+GCC 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 GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "backend.h"
+#include "target.h"
+#include "tree.h"
+#include "gimple.h"
+#include "tree-pass.h"
+#include "cgraph.h"
+#include "fold-const.h"
+#include "gimple-iterator.h"
+#include "tree-cfg.h"
+#include "cfgloop.h"
+#include "tree-vectorizer.h"
+#include "tm_p.h"
+
+namespace {
+
+const pass_data pass_data_adjust_alignment =
+{
+  GIMPLE_PASS, /* type */
+  "adjust_alignment", /* name */
+  OPTGROUP_NONE, /* optinfo_flags */
+  TV_NONE, /* tv_id */
+  0, /* properties_required */
+  0, /* properties_provided */
+  0, /* properties_destroyed */
+  0, /* todo_flags_start */
+  0, /* todo_flags_finish */
+};
+
+class pass_adjust_alignment : public gimple_opt_pass
+{
+public:
+  pass_adjust_alignment (gcc::context *ctxt)
+: gimple_opt_pass (pass_data_adjust_alignment, ctxt)
+  {}
+
+  virtual unsigned int execute (function *);
+
+}; // class pass_adjust_alignment
+
+} // anon namespace
+
+/* Entry point to adjust_alignment pass.  */
+unsigned int
+pass_adjust_alignment::execute (function *fun) {
+  size_t i;
+  tree var;
+  unsigned int align;
+
+  FOR_EACH_LOCAL_DECL (fun, i, var)
+{
+  /* Don't adjust aligment for static local var and hard register var.  */
+  if (is_global_var (var) || DECL_HARD_REGISTER (var))
+   continue;
+
+  align = LOCAL_DECL_ALIGNMENT (var);
+
+  /* Make sure alignment only increase.  */
+  gcc_assert (align >= DECL_ALIGN (var));
+
+  SET_DECL_ALIGN (var, align);
+}
+  return 0;
+}
+
+gimple_opt_pass *
+make_pass_adjust_alignment (gcc::context *ctxt)
+{
+  return new pass_adjust_alignment (ctxt);
+}
diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
index a1207a20a3c..576b3f67434 100644
--- a/gcc/tree-pass.h
+++ b/gcc/tree-pass.h
@@ -480,6 +480,7 @@ extern gimple_opt_pass *make_pass_sprintf_length 
(gcc::context *ctxt);