[committed] wwwdocs: ada: Tweak link to GNAT: The GNU Ada Compiler.

[Gerald Pfeifer]

Nice that AdaCore put in a redirect.

Pushed.
---
 htdocs/readings.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 4101fc4b..40ad4d62 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -562,7 +562,7 @@ names.
  Other resources:
  
https://www.adacore.com/community";>AdaCore Community 
Site
-   https://www2.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
+   https://www.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
The GNU Ada Compiler
https://www.adaic.org/resources/add_content/docs/95style/html/cover.html";>Ada
Quality & Style Guide
-- 
2.26.0

Re: [committed] wwwdocs: ada: Tweak link to GNAT: The GNU Ada Compiler.

[Gerald Pfeifer]

On Wed, 1 Apr 2020, Gerald Pfeifer wrote:
> Nice that AdaCore put in a redirect.

I spoke too fast, that was a 404 page.

> -   https://www2.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
> +   https://www.adacore.com/gap-static/GNAT_Book/html/";>GNAT:

Arnaud, Eric, Pierre-Marie, what do you recommend?

https://www.adacore.com/books/gnat-the-gnu-ada-compiler only appears
to have a PDF.  Is there still HTML up somewhere?  (Should we remove
the link - in readings.html - maybe in favor of something else?)

Gerald

Re: [C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120)

[Thomas Schwinge]

Hi!

Oh, the OpenACC 'declare' implementation in GCC -- be careful to not look
too carefully, or you'll discover one problem after the other...  ;-/
..., and also, a number of issues are open in the OpenACC tracker
regarding the 'declare' clause.


On 2020-03-12T15:43:03+0100, Frederik Harwath  wrote:
> Tobias Burnus  writes:
>> Fortran patch: https://gcc.gnu.org/pipermail/gcc-patches/current/541774.html
>>
>> "A declare directive must be in the same scope
>>   as the declaration of any var that appears in
>>   the data clauses of the directive."
>>
>> ("A declare directive is used […] following a variable
>>declaration in C or C++".)
>>
>> NOTE for C++: This patch assumes that variables in a namespace
>> are handled in the same way as those which are at
>> global (namespace) scope; however, the OpenACC specification's
>> wording currently is "In C or C++ global scope, only …".
>> Hence, one can argue about this part of the patch; but as
>> it fixes an ICE and is a very sensible extension – the other
>> option is to reject it – I believe it is fine.
>> (On the OpenACC side, this is now Issue 288.)

Please in GCC PRs use the "See Also" field "to refer to bugs in other
installations".  That makes it easy to cross-reference GCC with OpenACC
tickets.

> Sounds reasonable to me.

Even if the ICE is then fixed, should we still keep
 open (with a note) until
 is
resolved/published?

Regarding the C/C++ patch you posted: I'm not at all familiar with the
front ends' scoping implementation.  But, given that your patch really
only touches the OpenACC 'declare' code paths, it can't cause any harm
otherwise, so we shall accept it.  Maybe Jakub has any comments, though?
(Patch attached again, for easy reference.)

>> --- a/gcc/c/c-decl.c
>> +++ b/gcc/c/c-decl.c

>> +bool
>> +c_check_oacc_same_scope (tree decl)
>> +{
>> +  struct c_binding *b = I_SYMBOL_BINDING (DECL_NAME (decl));
>> +  return b != NULL && B_IN_CURRENT_SCOPE (b);
>> +}
>
> Is the function really specific to OpenACC? If not, then "_oacc"
> could be dropped from its name. How about "c_check_current_scope"?

Yeah, that may be a good idea.  Similar constructs seem to be used in a
few other places, though without the 'DECL_NAME' indirection.

>> --- a/gcc/cp/parser.c
>> +++ b/gcc/cp/parser.c
>> [...]
>> -   if (global_bindings_p ())
>> +   if (current_binding_level->kind == sk_namespace)
>> [...]
>> -  if (error || global_bindings_p ())
>> +  if (error || current_binding_level->kind == sk_namespace)
>>  return NULL_TREE;
>
> So - just to be sure - the new namespace condition subsumes the old
> "global_bindings_p" condition because the global scope is also a namespace,
> right? Yes, now I see that you have a test case that demonstrates that
> the declare directive still works for global variables with those changes.


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
[C/C++, OpenACC] Reject vars of different scope in acc declare (PR94120)

2020-10-11  Tobias Burnus  

	gcc/c/
	PR middle-end/94120
	* c-decl.c (c_check_oacc_same_scope): New function.
	* c-tree.h (c_check_oacc_same_scope): Declare it.
	* c-parser.c (c_parser_oacc_declare): Add check that variables
	are declared in the same scope as the directive. Fix handling
	of namespace vars.

	gcc/c/
	PR middle-end/94120
	* paser.c (cp_parser_oacc_declare): Add check that variables
are declared in the same scope as the directive.

	gcc/testsuite/
	PR middle-end/94120
	* c-c++-common/goacc/declare-pr94120.c: New.
	* g++.dg/declare-pr94120.C: New.

	libgomp/testsuite/
	PR middle-end/94120
	* libgomp.oacc-c++/declare-pr94120.C: New.
	

 gcc/c/c-decl.c |  8 +++
 gcc/c/c-parser.c   |  9 
 gcc/c/c-tree.h |  1 +
 gcc/cp/parser.c| 21 +++-
 gcc/testsuite/c-c++-common/goacc/declare-pr94120.c | 23 +
 gcc/testsuite/g++.dg/declare-pr94120.C | 30 
 .../testsuite/libgomp.oacc-c++/declare-pr94120.C   | 57 ++
 7 files changed, 147 insertions(+), 2 deletions(-)

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index c819fd0d0d5..eda95d664de 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -12016,4 +12016,12 @@ c_check_omp_declare_reduction_r (tree *tp, int *, void *data)
   return NULL_TREE;
 }
 
+
+bool
+c_check_oacc_same_scope (tree decl)
+{
+  struct c_binding *b = I_SYMBOL_BINDING (DECL_NAME (decl));
+  return b != NULL && B_IN_CURRENT_SCOPE (b);
+}
+
 #include "gt-c-c-decl.h"
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 1e8f2f7108d..63e8ab0ad17 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -16573,6 +16573,15 @@ c_parser_oacc_declare (c_parser *parser)
 	  br

[PATCH] objsz: Don't call replace_uses_by on SSA_NAME_OCCURS_IN_ABNORMAL_PHI [PR94423]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs because the objsz pass calls replace_uses_by
on SSA_NAME_OCCURS_IN_ABNORMAL_PHI SSA_NAME.  The following patch instead
of that calls replace_call_with_value, which will turn it into
  xyz_123(ab) = 234;

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

2020-04-01  Jakub Jelinek  

PR middle-end/94423
* tree-object-size.c (pass_object_sizes::execute): Don't call
replace_uses_by for SSA_NAME_OCCURS_IN_ABNORMAL_PHI lhs, instead
call replace_call_with_value.

* gcc.dg/ubsan/pr94423.c: New test.

--- gcc/tree-object-size.c.jj   2020-01-12 11:54:38.498381952 +0100
+++ gcc/tree-object-size.c  2020-03-31 14:35:34.956831791 +0200
@@ -1393,7 +1393,10 @@ pass_object_sizes::execute (function *fu
}
 
  /* Propagate into all uses and fold those stmts.  */
- replace_uses_by (lhs, result);
+ if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
+   replace_uses_by (lhs, result);
+ else
+   replace_call_with_value (&i, result);
}
 }
 
--- gcc/testsuite/gcc.dg/ubsan/pr94423.c.jj 2020-03-31 14:38:15.101423280 
+0200
+++ gcc/testsuite/gcc.dg/ubsan/pr94423.c2020-03-31 14:32:31.562589949 
+0200
@@ -0,0 +1,17 @@
+/* PR middle-end/94423 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fsanitize=object-size" } */
+
+void foo (void);
+typedef struct { long buf[22]; } jmp_buf[1];
+extern int sigsetjmp (jmp_buf, int) __attribute__ ((__nothrow__));
+jmp_buf buf;
+
+void
+bar (int *c)
+{
+  while (*c)
+foo ();
+  while (*c)
+sigsetjmp (buf, 0);
+}

Jakub

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Richard Biener via Gcc-patches]

On Tue, Mar 31, 2020 at 3:28 PM Maciej W. Rozycki  wrote:
>
> Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
> detection.") and fix a typo in the __BYTE_ORDER fallback macro check
> that causes compilation errors like:
>
> .../include/plugin-api.h:162:2: error: #error "Could not detect architecture 
> endianess"
>
> on systems that do not provide the __BYTE_ORDER__ macro.
>
> include/
> PR lto/94249
> * plugin-api.h: Fix a typo in the __BYTE_ORDER macro check.
> ---
> On Tue, 24 Mar 2020, Martin Liška wrote:
>
> > >> +/* Detect endianess based on _BYTE_ORDER.  */
> > >> +#if _BYTE_ORDER == _LITTLE_ENDIAN
> > >
> > > So most likely _BYTE_ORDER and _LITTLE_ENDIAN macros will not be defined.
> > > Which means this will be handled as #if 0 == 0 and override the
> > >> +#define PLUGIN_LITTLE_ENDIAN 1
> > >
> > > will define also PLUGIN_LITTLE_ENDIAN.
> >
> > Ok, for being sure, I've wrapped all equality comparison with corresponding
> > check of the LHS is defined.
>
>  This change, when merged into binutils, caused BFD to fail building in
> one of my configurations:
>
> In file included from .../bfd/elflink.c:31:
> .../bfd/../include/plugin-api.h:162:2: error: #error "Could not detect 
> architecture endianess"
> make[4]: *** [elflink.lo] Error 1
>
> This is due to a missing underscore in the:
>
> #ifdef _BYTE_ORDER
>
> check.
>
>  OK to apply this hopefully obvious fix to GCC and then merge to binutils?

OK.

>  NB if posting as an attachment please try matching the message subject
> with the change heading as otherwise it takes a lot of effort to track the
> patch submission corresponding to a given commit.
>
>   Maciej
> ---
>  include/plugin-api.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> binutils-include-plugin-api-byte-order.diff
> Index: binutils/include/plugin-api.h
> ===
> --- binutils.orig/include/plugin-api.h
> +++ binutils/include/plugin-api.h
> @@ -51,7 +51,7 @@
>  /* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
>  #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__)
>  #include 
> -#ifdef _BYTE_ORDER
> +#ifdef __BYTE_ORDER
>  #if __BYTE_ORDER == __LITTLE_ENDIAN
>  #define PLUGIN_LITTLE_ENDIAN 1
>  #elif __BYTE_ORDER == __BIG_ENDIAN

[committed] wwwdocs: Follow redirect for Thread Building Blocks on GitHub.

[Gerald Pfeifer]

Pushed.

---
 htdocs/gcc-9/changes.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html
index d5469ec4..74c7cde7 100644
--- a/htdocs/gcc-9/changes.html
+++ b/htdocs/gcc-9/changes.html
@@ -675,7 +675,7 @@ $ g++ typo.cc
The C++17 implementation is no longer experimental. 
   
 Parallel algorithms and 
-(requires https://github.com/intel/tbb";>Thread
+(requires https://github.com/oneapi-src/oneTBB";>Thread
 Building Blocks 2018 or newer).
   
. 
-- 
2.26.0

[PATH] Enable GCC support for SERIALIZE

[Hongtao Liu via Gcc-patches]

Hi:
  This patch is about to enable GCC support for SERIALIZE which would
be in GLC. There's only 1 instruction: SERIALIZE, more details please
refer to 
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
  I know it's stage4 right now, and patches are approved only for bug
fixed, but since many users prefer to use release version other than
build from trunk, i'd like to see this patch landed on GCC10, after
all it's only 1 instruction, without any significant changes.

  Bootstrap ok, regression test on i386/x86 backend is ok.

gcc/Changelog:
* gcc/common/config/i386/i386-common.c (OPTION_MASK_ISA2_SERIALIZE_SET,
OPTION_MASK_ISA2_SERIALIZE_UNSET): New macros.
(ix86_handle_option): Handle -mserialize.
* gcc/config.gcc (serializeintrin.h): New header file.
* gcc/config/i386/cpuid.h (bit_SERIALIZE): New bit.
* gcc/config/i386/driver-i386.c (host_detect_local_cpu): Detect
-mserialize.
* gcc/config/i386/i386-builtin.def: Add new builtin.
* gcc/config/i386/i386-c.c (__SERIALIZE__): New macro.
* gcc/config/i386/i386-options.c (ix86_target_opts_isa2_opts):
  Add -mserialize.
* (ix86_valid_target_attribute_inner_p): Add target attribute
* for serialize.
* gcc/config/i386/i386.h (TARGET_SERIALIZE, TARGET_SERIALIZE_P):
  New macros.
* gcc/config/i386/i386.md (UNSPECV_SERIALIZE): New unspec.
  (serialize): New define_insn.
* gcc/config/i386/i386.opt (mserialize): New option
* gcc/config/i386/immintrin.h: Include serailizeintrin.h.
* gcc/config/i386/serializeintrin.h: New header file.
* gcc/doc/invoke.texi: Add documents for -mserialize.

gcc/testsuite/Changelog
* gcc/testsuite/gcc.target/i386/serialize-1.c: New test.
* gcc/testsuite/g++.dg/other/i386-2.C: Add -mserialize.
* gcc/testsuite/g++.dg/other/i386-3.C: Ditto.
* gcc/testsuite/gcc.target/i386/sse-12.c: Ditto.
* gcc/testsuite/gcc.target/i386/sse-13.c: Ditto.
* gcc/testsuite/gcc.target/i386/sse-14.c: Ditto.
* gcc/testsuite/gcc.target/i386/sse-22.c: Ditto.
* gcc/testsuite/gcc.target/i386/sse-23.c: Ditto.



-- 
BR,
Hongtao
From b61dd0f3a503acb73b17e91cd55d3ef7d477 Mon Sep 17 00:00:00 2001
From: liuhongt 
Date: Wed, 4 Mar 2020 14:08:40 +0800
Subject: [PATCH] Enable GCC support for SERIALIZE

2020-03-04  Hongtao Liu  
2020-03-04  Wei Xiao  

gcc/Changelog:
	* gcc/common/config/i386/i386-common.c (OPTION_MASK_ISA2_SERIALIZE_SET,
	OPTION_MASK_ISA2_SERIALIZE_UNSET): New macros.
	(ix86_handle_option): Handle -mserialize.
	* gcc/config.gcc (serializeintrin.h): New header file.
	* gcc/config/i386/cpuid.h (bit_SERIALIZE): New bit.
	* gcc/config/i386/driver-i386.c (host_detect_local_cpu): Detect
	-mserialize.
	* gcc/config/i386/i386-builtin.def: Add new builtin.
	* gcc/config/i386/i386-c.c (__SERIALIZE__): New macro.
	* gcc/config/i386/i386-options.c (ix86_target_opts_isa2_opts):
	  Add -mserialize.
	* (ix86_valid_target_attribute_inner_p): Add target attribute
	* for serialize.
	* gcc/config/i386/i386.h (TARGET_SERIALIZE, TARGET_SERIALIZE_P):
	  New macros.
	* gcc/config/i386/i386.md (UNSPECV_SERIALIZE): New unspec.
	  (serialize): New define_insn.
	* gcc/config/i386/i386.opt (mserialize): New option
	* gcc/config/i386/immintrin.h: Include serailizeintrin.h.
	* gcc/config/i386/serializeintrin.h: New header file.
	* gcc/doc/invoke.texi: Add documents for -mserialize.

gcc/testsuite/Changelog
	* gcc/testsuite/gcc.target/i386/serialize-1.c: New test.
	* gcc/testsuite/g++.dg/other/i386-2.C: Add -mserialize.
	* gcc/testsuite/g++.dg/other/i386-3.C: Ditto.
	* gcc/testsuite/gcc.target/i386/sse-12.c: Ditto.
	* gcc/testsuite/gcc.target/i386/sse-13.c: Ditto.
	* gcc/testsuite/gcc.target/i386/sse-14.c: Ditto.
	* gcc/testsuite/gcc.target/i386/sse-22.c: Ditto.
	* gcc/testsuite/gcc.target/i386/sse-23.c: Ditto.
---
 gcc/common/config/i386/i386-common.c| 15 +++
 gcc/config.gcc  | 10 +++--
 gcc/config/i386/cpuid.h |  1 +
 gcc/config/i386/driver-i386.c   |  5 ++-
 gcc/config/i386/i386-builtin.def|  3 ++
 gcc/config/i386/i386-c.c|  2 +
 gcc/config/i386/i386-options.c  |  4 +-
 gcc/config/i386/i386.h  |  2 +
 gcc/config/i386/i386.md | 10 +
 gcc/config/i386/i386.opt|  4 ++
 gcc/config/i386/immintrin.h |  2 +
 gcc/config/i386/serializeintrin.h   | 49 +
 gcc/doc/invoke.texi | 11 +++--
 gcc/testsuite/g++.dg/other/i386-2.C |  2 +-
 gcc/testsuite/g++.dg/other/i386-3.C |  2 +-
 gcc/testsuite/gcc.target/i386/serialize-1.c | 12 +
 gcc/testsuite/gcc.target/i386/sse-12.c  |  2 +-
 gcc/testsuite/gcc.target/i386/sse-13.c  |  2 +-

[committed] Move pspace.org to https.

[Gerald Pfeifer]

Pushed.
---
 htdocs/readings.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/htdocs/readings.html b/htdocs/readings.html
index 40ad4d62..84fc0404 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@ -27,7 +27,7 @@
 
   https://en.wikibooks.org/wiki/GNU_C_Compiler_Internals";>GNU C 
Compiler Internals (Wikibook), numerous contributors.
 
-  http://www.pspace.org/a/thesis/";>Compilation
+  https://www.pspace.org/a/thesis/";>Compilation
   of Functional Programming Languages using GCC -- Tail Calls
   by Andreas Bauer.
 

[PATCH] Enable GCC support for TSXLDTRK

[Hongtao Liu via Gcc-patches]

Hi:
  This patch is about to enable GCC support for TSXLDTRK which would
be in GLC. There's only 2 instructions: XRESLDTRK, XSUSLDTRK, more
details please
refer to 
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
  I know it's stage4 right now, and patches are approved only for bug
fixed, but since many users prefer to use release version other than
build from trunk, i'd like to see this patch land on GCC10, after
all it's only 2 instructions, without any significant changes.

  Bootstrap ok, regression test on i386/x86 backend is ok.

gcc/Changelog
* common/config/i386/i386-common.c (OPTION_MASK_ISA2_TSXLDTRK_SET,
OPTION_MASK_ISA2_TSXLDTRK_UNSET): New macros.
* config.gcc: Add tsxldtrkintrin.h to extra_headers.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect
TSXLDTRK.
* config/i386/i386-builtin.def: Add new builtins.
* config/i386/i386-c.c (ix86_target_macros_internal): Define
__TSXLDTRK__.
* config/i386/i386-options.c (ix86_target_string): Add
-mtsxldtrk.
* config/i386/i386.h (TARGET_TSXLDTRK, TARGET_TSXLDTRK_P):
New.
* config/i386/i386.md (define_c_enum "unspec"): Add
UNSPECV_SUSLDTRK, UNSPECV_RESLDTRK.
(TSXLDTRK): New define_int_iterator.
(""): New define_insn.
* config/i386/i386.opt: Add -mtsxldtrk.
* config/i386/immintrin.h: Include tsxldtrkintrin.h.
* config/i386/tsxldtrkintrin.h: New.
* doc/invoke.texi: Document -mtsxldtrk.

gcc/testsuite/Changelog
* g++.dg/other/i386-2.c: Add -mtsxldtrk.
* g++.dg/other/i386-3.c: Likewise.
* gcc.target/i386/sse-12.c: Likewise.
* gcc.target/i386/sse-13.c: Likewise.
* gcc.target/i386/sse-14.c: Likewise.
* gcc.target/i386/sse-22.c: Likewsie.
* gcc.target/i386/sse-23.c: Likewise.
* gcc.target/i386/tsxldtrk-1.c: New test.

-- 
BR,
Hongtao

Re: [PATCH] Enable GCC support for TSXLDTRK

[Hongtao Liu via Gcc-patches]

On Wed, Apr 1, 2020 at 3:32 PM Hongtao Liu  wrote:
>
> Hi:
>   This patch is about to enable GCC support for TSXLDTRK which would
> be in GLC. There's only 2 instructions: XRESLDTRK, XSUSLDTRK, more
> details please
> refer to 
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
>   I know it's stage4 right now, and patches are approved only for bug
> fixed, but since many users prefer to use release version other than
> build from trunk, i'd like to see this patch land on GCC10, after
> all it's only 2 instructions, without any significant changes.
>
>   Bootstrap ok, regression test on i386/x86 backend is ok.
>
> gcc/Changelog
> * common/config/i386/i386-common.c (OPTION_MASK_ISA2_TSXLDTRK_SET,
> OPTION_MASK_ISA2_TSXLDTRK_UNSET): New macros.
> * config.gcc: Add tsxldtrkintrin.h to extra_headers.
> * config/i386/driver-i386.c (host_detect_local_cpu): Detect
> TSXLDTRK.
> * config/i386/i386-builtin.def: Add new builtins.
> * config/i386/i386-c.c (ix86_target_macros_internal): Define
> __TSXLDTRK__.
> * config/i386/i386-options.c (ix86_target_string): Add
> -mtsxldtrk.
> * config/i386/i386.h (TARGET_TSXLDTRK, TARGET_TSXLDTRK_P):
> New.
> * config/i386/i386.md (define_c_enum "unspec"): Add
> UNSPECV_SUSLDTRK, UNSPECV_RESLDTRK.
> (TSXLDTRK): New define_int_iterator.
> (""): New define_insn.
> * config/i386/i386.opt: Add -mtsxldtrk.
> * config/i386/immintrin.h: Include tsxldtrkintrin.h.
> * config/i386/tsxldtrkintrin.h: New.
> * doc/invoke.texi: Document -mtsxldtrk.
>
> gcc/testsuite/Changelog
> * g++.dg/other/i386-2.c: Add -mtsxldtrk.
> * g++.dg/other/i386-3.c: Likewise.
> * gcc.target/i386/sse-12.c: Likewise.
> * gcc.target/i386/sse-13.c: Likewise.
> * gcc.target/i386/sse-14.c: Likewise.
> * gcc.target/i386/sse-22.c: Likewsie.
> * gcc.target/i386/sse-23.c: Likewise.
> * gcc.target/i386/tsxldtrk-1.c: New test.
>
> --
> BR,
> Hongtao

Add patch.

-- 
BR,
Hongtao
From a52500df4a1e6cdbf8d44a59fdf9c03183b0ce96 Mon Sep 17 00:00:00 2001
From: liuhongt 
Date: Fri, 14 Feb 2020 15:40:46 +0800
Subject: [PATCH] Enable TARGET_TSXLDTRK for GCC support.

gcc/
	* common/config/i386/i386-common.c (OPTION_MASK_ISA2_TSXLDTRK_SET,
	OPTION_MASK_ISA2_TSXLDTRK_UNSET): New macros.
	* config.gcc: Add tsxldtrkintrin.h to extra_headers.
	* config/i386/driver-i386.c (host_detect_local_cpu): Detect
	TSXLDTRK.
	* config/i386/i386-builtin.def: Add new builtins.
	* config/i386/i386-c.c (ix86_target_macros_internal): Define
	__TSXLDTRK__.
	* config/i386/i386-options.c (ix86_target_string): Add
	-mtsxldtrk.
	* config/i386/i386.h (TARGET_TSXLDTRK, TARGET_TSXLDTRK_P):
	New.
	* config/i386/i386.md (define_c_enum "unspec"): Add
	UNSPECV_SUSLDTRK, UNSPECV_RESLDTRK.
	(TSXLDTRK): New define_int_iterator.
	(""): New define_insn.
	* config/i386/i386.opt: Add -mtsxldtrk.
	* config/i386/immintrin.h: Include tsxldtrkintrin.h.
	* config/i386/tsxldtrkintrin.h: New.
	* doc/invoke.texi: Document -mtsxldtrk.

gcc/testsuite/
	* g++.dg/other/i386-2.c: Add -mtsxldtrk.
	* g++.dg/other/i386-3.c: Likewise.
	* gcc.target/i386/sse-12.c: Likewise.
	* gcc.target/i386/sse-13.c: Likewise.
	* gcc.target/i386/sse-14.c: Likewise.
	* gcc.target/i386/sse-22.c: Likewsie.
	* gcc.target/i386/sse-23.c: Likewise.
	* gcc.target/i386/tsxldtrk-1.c: New test.
---
 gcc/common/config/i386/i386-common.c   | 15 ++
 gcc/config.gcc |  6 ++--
 gcc/config/i386/cpuid.h|  2 ++
 gcc/config/i386/driver-i386.c  |  4 +++
 gcc/config/i386/i386-builtin.def   |  4 +++
 gcc/config/i386/i386-c.c   |  2 ++
 gcc/config/i386/i386-options.c |  4 ++-
 gcc/config/i386/i386.h |  2 ++
 gcc/config/i386/i386.md| 15 ++
 gcc/config/i386/i386.opt   |  4 +++
 gcc/config/i386/immintrin.h|  2 ++
 gcc/config/i386/tsxldtrkintrin.h   | 33 ++
 gcc/doc/invoke.texi|  5 +++-
 gcc/testsuite/g++.dg/other/i386-2.C|  4 +--
 gcc/testsuite/g++.dg/other/i386-3.C|  4 +--
 gcc/testsuite/gcc.target/i386/sse-12.c |  2 +-
 gcc/testsuite/gcc.target/i386/sse-13.c |  2 +-
 gcc/testsuite/gcc.target/i386/sse-14.c |  2 +-
 gcc/testsuite/gcc.target/i386/sse-22.c |  6 ++--
 gcc/testsuite/gcc.target/i386/sse-23.c |  4 +--
 gcc/testsuite/gcc.target/i386/tsxldtrk-1.c | 13 +
 21 files changed, 119 insertions(+), 16 deletions(-)
 create mode 100644 gcc/config/i386/tsxldtrkintrin.h
 create mode 100644 gcc/testsuite/gcc.target/i386/tsxldtrk-1.c

diff --git a/gcc/common/config/i386/i386-common.c b/gcc/common/config/i386/i386-common.c
index 02b19f1bb54..207651c3222 100644
--- a/g

Re: [PATCH] objsz: Don't call replace_uses_by on SSA_NAME_OCCURS_IN_ABNORMAL_PHI [PR94423]

[Richard Biener]

On Wed, 1 Apr 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following testcase ICEs because the objsz pass calls replace_uses_by
> on SSA_NAME_OCCURS_IN_ABNORMAL_PHI SSA_NAME.  The following patch instead
> of that calls replace_call_with_value, which will turn it into
>   xyz_123(ab) = 234;
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2020-04-01  Jakub Jelinek  
> 
>   PR middle-end/94423
>   * tree-object-size.c (pass_object_sizes::execute): Don't call
>   replace_uses_by for SSA_NAME_OCCURS_IN_ABNORMAL_PHI lhs, instead
>   call replace_call_with_value.
> 
>   * gcc.dg/ubsan/pr94423.c: New test.
> 
> --- gcc/tree-object-size.c.jj 2020-01-12 11:54:38.498381952 +0100
> +++ gcc/tree-object-size.c2020-03-31 14:35:34.956831791 +0200
> @@ -1393,7 +1393,10 @@ pass_object_sizes::execute (function *fu
>   }
>  
> /* Propagate into all uses and fold those stmts.  */
> -   replace_uses_by (lhs, result);
> +   if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs))
> + replace_uses_by (lhs, result);
> +   else
> + replace_call_with_value (&i, result);
>   }
>  }
>  
> --- gcc/testsuite/gcc.dg/ubsan/pr94423.c.jj   2020-03-31 14:38:15.101423280 
> +0200
> +++ gcc/testsuite/gcc.dg/ubsan/pr94423.c  2020-03-31 14:32:31.562589949 
> +0200
> @@ -0,0 +1,17 @@
> +/* PR middle-end/94423 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fsanitize=object-size" } */
> +
> +void foo (void);
> +typedef struct { long buf[22]; } jmp_buf[1];
> +extern int sigsetjmp (jmp_buf, int) __attribute__ ((__nothrow__));
> +jmp_buf buf;
> +
> +void
> +bar (int *c)
> +{
> +  while (*c)
> +foo ();
> +  while (*c)
> +sigsetjmp (buf, 0);
> +}
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATH] Enable GCC support for SERIALIZE

[Uros Bizjak via Gcc-patches]

On Wed, Apr 1, 2020 at 9:23 AM Hongtao Liu  wrote:
>
> Hi:
>   This patch is about to enable GCC support for SERIALIZE which would
> be in GLC. There's only 1 instruction: SERIALIZE, more details please
> refer to 
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
>   I know it's stage4 right now, and patches are approved only for bug
> fixed, but since many users prefer to use release version other than
> build from trunk, i'd like to see this patch landed on GCC10, after
> all it's only 1 instruction, without any significant changes.
>
>   Bootstrap ok, regression test on i386/x86 backend is ok.

No, this should wait for gcc-11.

Uros.

> gcc/Changelog:
> * gcc/common/config/i386/i386-common.c 
> (OPTION_MASK_ISA2_SERIALIZE_SET,
> OPTION_MASK_ISA2_SERIALIZE_UNSET): New macros.
> (ix86_handle_option): Handle -mserialize.
> * gcc/config.gcc (serializeintrin.h): New header file.
> * gcc/config/i386/cpuid.h (bit_SERIALIZE): New bit.
> * gcc/config/i386/driver-i386.c (host_detect_local_cpu): Detect
> -mserialize.
> * gcc/config/i386/i386-builtin.def: Add new builtin.
> * gcc/config/i386/i386-c.c (__SERIALIZE__): New macro.
> * gcc/config/i386/i386-options.c (ix86_target_opts_isa2_opts):
>   Add -mserialize.
> * (ix86_valid_target_attribute_inner_p): Add target attribute
> * for serialize.
> * gcc/config/i386/i386.h (TARGET_SERIALIZE, TARGET_SERIALIZE_P):
>   New macros.
> * gcc/config/i386/i386.md (UNSPECV_SERIALIZE): New unspec.
>   (serialize): New define_insn.
> * gcc/config/i386/i386.opt (mserialize): New option
> * gcc/config/i386/immintrin.h: Include serailizeintrin.h.
> * gcc/config/i386/serializeintrin.h: New header file.
> * gcc/doc/invoke.texi: Add documents for -mserialize.
>
> gcc/testsuite/Changelog
> * gcc/testsuite/gcc.target/i386/serialize-1.c: New test.
> * gcc/testsuite/g++.dg/other/i386-2.C: Add -mserialize.
> * gcc/testsuite/g++.dg/other/i386-3.C: Ditto.
> * gcc/testsuite/gcc.target/i386/sse-12.c: Ditto.
> * gcc/testsuite/gcc.target/i386/sse-13.c: Ditto.
> * gcc/testsuite/gcc.target/i386/sse-14.c: Ditto.
> * gcc/testsuite/gcc.target/i386/sse-22.c: Ditto.
> * gcc/testsuite/gcc.target/i386/sse-23.c: Ditto.
>
>
>
> --
> BR,
> Hongtao

Re: [PATCH] Enable GCC support for TSXLDTRK

[Uros Bizjak via Gcc-patches]

On Wed, Apr 1, 2020 at 9:28 AM Hongtao Liu  wrote:
>
> On Wed, Apr 1, 2020 at 3:32 PM Hongtao Liu  wrote:
> >
> > Hi:
> >   This patch is about to enable GCC support for TSXLDTRK which would
> > be in GLC. There's only 2 instructions: XRESLDTRK, XSUSLDTRK, more
> > details please
> > refer to 
> > https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
> >   I know it's stage4 right now, and patches are approved only for bug
> > fixed, but since many users prefer to use release version other than
> > build from trunk, i'd like to see this patch land on GCC10, after
> > all it's only 2 instructions, without any significant changes.
> >
> >   Bootstrap ok, regression test on i386/x86 backend is ok.

No, this should wait for gcc-11.

Uros.

> > gcc/Changelog
> > * common/config/i386/i386-common.c (OPTION_MASK_ISA2_TSXLDTRK_SET,
> > OPTION_MASK_ISA2_TSXLDTRK_UNSET): New macros.
> > * config.gcc: Add tsxldtrkintrin.h to extra_headers.
> > * config/i386/driver-i386.c (host_detect_local_cpu): Detect
> > TSXLDTRK.
> > * config/i386/i386-builtin.def: Add new builtins.
> > * config/i386/i386-c.c (ix86_target_macros_internal): Define
> > __TSXLDTRK__.
> > * config/i386/i386-options.c (ix86_target_string): Add
> > -mtsxldtrk.
> > * config/i386/i386.h (TARGET_TSXLDTRK, TARGET_TSXLDTRK_P):
> > New.
> > * config/i386/i386.md (define_c_enum "unspec"): Add
> > UNSPECV_SUSLDTRK, UNSPECV_RESLDTRK.
> > (TSXLDTRK): New define_int_iterator.
> > (""): New define_insn.
> > * config/i386/i386.opt: Add -mtsxldtrk.
> > * config/i386/immintrin.h: Include tsxldtrkintrin.h.
> > * config/i386/tsxldtrkintrin.h: New.
> > * doc/invoke.texi: Document -mtsxldtrk.
> >
> > gcc/testsuite/Changelog
> > * g++.dg/other/i386-2.c: Add -mtsxldtrk.
> > * g++.dg/other/i386-3.c: Likewise.
> > * gcc.target/i386/sse-12.c: Likewise.
> > * gcc.target/i386/sse-13.c: Likewise.
> > * gcc.target/i386/sse-14.c: Likewise.
> > * gcc.target/i386/sse-22.c: Likewsie.
> > * gcc.target/i386/sse-23.c: Likewise.
> > * gcc.target/i386/tsxldtrk-1.c: New test.
> >
> > --
> > BR,
> > Hongtao
>
> Add patch.
>
> --
> BR,
> Hongtao

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Martin Liška]

On 3/31/20 3:27 PM, Maciej W. Rozycki wrote:

Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
detection.") and fix a typo in the __BYTE_ORDER fallback macro check
that causes compilation errors like:

.../include/plugin-api.h:162:2: error: #error "Could not detect architecture 
endianess"

on systems that do not provide the __BYTE_ORDER__ macro.


Hello.

Nice catch!



include/
PR lto/94249
* plugin-api.h: Fix a typo in the __BYTE_ORDER macro check.
---
On Tue, 24 Mar 2020, Martin Liška wrote:


+/* Detect endianess based on _BYTE_ORDER.  */
+#if _BYTE_ORDER == _LITTLE_ENDIAN


So most likely _BYTE_ORDER and _LITTLE_ENDIAN macros will not be defined.
Which means this will be handled as #if 0 == 0 and override the

+#define PLUGIN_LITTLE_ENDIAN 1


will define also PLUGIN_LITTLE_ENDIAN.


Ok, for being sure, I've wrapped all equality comparison with corresponding
check of the LHS is defined.


  This change, when merged into binutils, caused BFD to fail building in
one of my configurations:

In file included from .../bfd/elflink.c:31:
.../bfd/../include/plugin-api.h:162:2: error: #error "Could not detect architecture 
endianess"
make[4]: *** [elflink.lo] Error 1

This is due to a missing underscore in the:

#ifdef _BYTE_ORDER

check.

  OK to apply this hopefully obvious fix to GCC and then merge to binutils?


I've just installed the patch.
@H.J. Can you please pull it to bintuils?



  NB if posting as an attachment please try matching the message subject
with the change heading as otherwise it takes a lot of effort to track the
patch submission corresponding to a given commit.


I see your point, but note that sometimes a direction of a patch changes during
the mailing list discussion. And so that we end up with a commit message that
has a different name.

Anyway, thank you for your help.
Martin



   Maciej
---
  include/plugin-api.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

binutils-include-plugin-api-byte-order.diff
Index: binutils/include/plugin-api.h
===
--- binutils.orig/include/plugin-api.h
+++ binutils/include/plugin-api.h
@@ -51,7 +51,7 @@
  /* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
  #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__)
  #include 
-#ifdef _BYTE_ORDER
+#ifdef __BYTE_ORDER
  #if __BYTE_ORDER == __LITTLE_ENDIAN
  #define PLUGIN_LITTLE_ENDIAN 1
  #elif __BYTE_ORDER == __BIG_ENDIAN

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Martin Liška]

On 4/1/20 7:01 AM, Hans-Peter Nilsson wrote:

On Tue, 31 Mar 2020, Maciej W. Rozycki wrote:

Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
detection.") and fix a typo in the __BYTE_ORDER fallback macro check
that causes compilation errors like:

.../include/plugin-api.h:162:2: error: #error "Could not detect architecture 
endianess"

on systems that do not provide the __BYTE_ORDER__ macro.



Index: binutils/include/plugin-api.h
===
--- binutils.orig/include/plugin-api.h
+++ binutils/include/plugin-api.h
@@ -51,7 +51,7 @@
  /* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
  #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) || defined(__ANDROID__)
  #include 
-#ifdef _BYTE_ORDER
+#ifdef __BYTE_ORDER
  #if __BYTE_ORDER == __LITTLE_ENDIAN
  #define PLUGIN_LITTLE_ENDIAN 1
  #elif __BYTE_ORDER == __BIG_ENDIAN


FWIW, I was about to commit that as obvious, also the bignum.h
inclusion thing!

The only question being, how the typo passed any kind of testing
in the first place...


Because I don't have a legacy system with an ancient glibc version.
Note that testing matrix for such a change is massive, including such
exotic targets like SUN, minix, Windows, ...


 No actually, there's also the question
why the plugin-API needs to bother with host endianness.  It's
not like endians are going to be different between plugins and
gcc on host.


No, the plugin endianess matches with a host compiler endianess.
Martin



brgds, H-P

Re: [committed] wwwdocs: ada: Tweak link to GNAT: The GNU Ada Compiler.

[Arnaud Charlet]

> I spoke too fast, that was a 404 page.
> 
> > -   https://www2.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
> > +   https://www.adacore.com/gap-static/GNAT_Book/html/";>GNAT:
> 
> Arnaud, Eric, Pierre-Marie, what do you recommend?
> 
> https://www.adacore.com/books/gnat-the-gnu-ada-compiler only appears
> to have a PDF.  Is there still HTML up somewhere?  (Should we remove
> the link - in readings.html - maybe in favor of something else?)

We're investigating at Adacore whether the HTML version can be restored.

In the mean time, pointing to 
https://www.adacore.com/books/gnat-the-gnu-ada-compiler is indeed the way to go.

Arno

GCC 10.0 Status Report (2020-04-01)

[Richard Biener]

Status
==

GCC trunk is in regression and documentation fixing mode, stage 4.
There's still quite some work to do before we reach the zero-P1
milestone and thus qualify for a first release candidate of GCC 10.
Please help in making this happen soon, historical data would
predict a RC to be available in about two to three weeks from now.


Quality Data


Priority  #   Change from last report
---   ---
P1   21   +   1
P2  222   +  26
P3   15   - 148
P4  178   +  27
P5   23
---   ---
Total P1-P3 258   - 121
Total   459   -  94


Previous Report
===

https://gcc.gnu.org/legacy-ml/gcc/2020-01/msg00199.html

[patch, 10 Regression] FAIL: gfortran.dg/pr93365.f90 PR94386

[Mark Eggleston]

Please find attached a patch to fix test case failures of pr93365.f90, 
pr93600_1.f90 and pr93600_2.f90.


OK to commit?

gcc/fortran/ChangeLog:

    Mark Eggleston  

    PR fortran/04386
    expr.c (simplify_parameter_variable):  Restore code deleted
    in PR94246.

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

>From 0825e19558b2243a3300fc4d468665cd6adecbe3 Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Tue, 31 Mar 2020 15:54:10 +0100
Subject: [PATCH] fortran :  [10 Regression] FAIL: gfortran.dg/pr93365.f90
 PR94386

Failures of pr93365.f90,  pr93600_1.f90 and pr93600_2.f90.
Changes made by PR94246 delete and changed code from expr.c
introduced by PR93600, the deleted code.  This broke the PR93600
test cases.  Restoring the deleted code and leaving the changed
code alone allows the cases for PR93600 and PR94246 to pass.

gcc/fortran/ChangeLog:

	PR fortran/04386
	expr.c (simplify_parameter_variable):  Restore code deleted
	in PR94246.
---
 gcc/fortran/expr.c | 33 ++---
 1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 1106341df91..a9fa03ad153 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -2057,6 +2057,18 @@ simplify_parameter_variable (gfc_expr *p, int type)
 }
   gfc_expression_rank (p);
 
+  /* Is this an inquiry?  */
+  bool inquiry = false;
+  gfc_ref* ref = p->ref;
+  while (ref)
+{
+  if (ref->type == REF_INQUIRY)
+	break;
+  ref = ref->next;
+}
+  if (ref && ref->type == REF_INQUIRY)
+inquiry = ref->u.i == INQUIRY_LEN || ref->u.i == INQUIRY_KIND;
+
   if (gfc_is_size_zero_array (p))
 {
   if (p->expr_type == EXPR_ARRAY)
@@ -2069,15 +2081,22 @@ simplify_parameter_variable (gfc_expr *p, int type)
   e->value.constructor = NULL;
   e->shape = gfc_copy_shape (p->shape, p->rank);
   e->where = p->where;
-  gfc_replace_expr (p, e);
-  return true;
+  /* If %kind and %len are not used then we're done, otherwise
+	 drop through for simplification.  */
+  if (!inquiry)
+	{
+	  gfc_replace_expr (p, e);
+	  return true;
+	}
 }
+  else
+{
+  e = gfc_copy_expr (p->symtree->n.sym->value);
+  if (e == NULL)
+	return false;
 
-  e = gfc_copy_expr (p->symtree->n.sym->value);
-  if (e == NULL)
-return false;
-
-  e->rank = p->rank;
+  e->rank = p->rank;
+}
 
   if (e->ts.type == BT_CHARACTER && e->ts.u.cl == NULL)
 e->ts.u.cl = gfc_new_charlen (gfc_current_ns, p->ts.u.cl);
-- 
2.11.0

Re: [patch, 10 Regression] FAIL: gfortran.dg/pr93365.f90 PR94386

[H.J. Lu via Gcc-patches]

On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
 wrote:
>
> Please find attached a patch to fix test case failures of pr93365.f90,
> pr93600_1.f90 and pr93600_2.f90.
>
> OK to commit?
>
> gcc/fortran/ChangeLog:
>
>  Mark Eggleston  
>
>  PR fortran/04386
 ^^^ Wrong PR #.
>  expr.c (simplify_parameter_variable):  Restore code deleted
>  in PR94246.
>
> --
> https://www.codethink.co.uk/privacy.html
>


-- 
H.J.

Re: [patch, 10 Regression] FAIL: gfortran.dg/pr93365.f90 PR94386

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 01, 2020 at 02:43:46AM -0700, H.J. Lu via Gcc-patches wrote:
> On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
>  wrote:
> >
> > Please find attached a patch to fix test case failures of pr93365.f90,
> > pr93600_1.f90 and pr93600_2.f90.
> >
> > OK to commit?
> >
> > gcc/fortran/ChangeLog:
> >
> >  Mark Eggleston  
> >
> >  PR fortran/04386
>  ^^^ Wrong PR #.
> >  expr.c (simplify_parameter_variable):  Restore code deleted

And just one space after :, not two.

> >  in PR94246.

Jakub

Re: [patch, 10 Regression] FAIL: gfortran.dg/pr93365.f90 PR94386

[Mark Eggleston]

On 01/04/2020 10:43, H.J. Lu wrote:

On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
 wrote:

Please find attached a patch to fix test case failures of pr93365.f90,
pr93600_1.f90 and pr93600_2.f90.

OK to commit?

gcc/fortran/ChangeLog:

  Mark Eggleston  

  PR fortran/04386

  ^^^ Wrong PR #.

Fixed, thanks.

  expr.c (simplify_parameter_variable):  Restore code deleted
  in PR94246.

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




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

Re: [patch, 10 Regression] FAIL: gfortran.dg/pr93365.f90 PR94386

[Tobias Burnus]

LGTM with the PR/spacing fixed as noted by HJ and Jakub.

Thanks for the patch!

Tobias

On 4/1/20 11:31 AM, Mark Eggleston wrote:

Please find attached a patch to fix test case failures of pr93365.f90,
pr93600_1.f90 and pr93600_2.f90.

OK to commit?

gcc/fortran/ChangeLog:

Mark Eggleston  

PR fortran/04386
expr.c (simplify_parameter_variable):  Restore code deleted
in PR94246.


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: [patch, 10 Regression] FAIL: gfortran.dg/pr93365.f90 PR94386

[Mark Eggleston]

On 01/04/2020 10:46, Jakub Jelinek wrote:

On Wed, Apr 01, 2020 at 02:43:46AM -0700, H.J. Lu via Gcc-patches wrote:

On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
 wrote:

Please find attached a patch to fix test case failures of pr93365.f90,
pr93600_1.f90 and pr93600_2.f90.

OK to commit?

gcc/fortran/ChangeLog:

  Mark Eggleston  

  PR fortran/04386

  ^^^ Wrong PR #.

  expr.c (simplify_parameter_variable):  Restore code deleted

And just one space after :, not two.

OK.



  in PR94246.

Jakub



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

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Maciej W. Rozycki]

On Wed, 1 Apr 2020, Martin Liška wrote:

> >   OK to apply this hopefully obvious fix to GCC and then merge to binutils?
> 
> I've just installed the patch.
> @H.J. Can you please pull it to bintuils?

 Why didn't you use the commit as I published it and also assumed 
authorship of my change?  I feel insulted.

  Maciej

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Martin Liška]

On 4/1/20 11:55 AM, Maciej W. Rozycki wrote:

On Wed, 1 Apr 2020, Martin Liška wrote:


   OK to apply this hopefully obvious fix to GCC and then merge to binutils?


I've just installed the patch.
@H.J. Can you please pull it to bintuils?


  Why didn't you use the commit as I published it


Because it didn't fit my script that takes changelog entries
and moves that to the corresponding ChangeLog files.
Next time, you will install the patch by your own.


and also assumed
authorship of my change?  I feel insulted.


I removed myself from the ownership of the patch here:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d3ee88fdb4e0f718aaba050a3eb7174b8934a29d

Martin



   Maciej

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Maciej W. Rozycki]

On Wed, 1 Apr 2020, Martin Liška wrote:

> >   NB if posting as an attachment please try matching the message subject
> > with the change heading as otherwise it takes a lot of effort to track the
> > patch submission corresponding to a given commit.
> 
> I see your point, but note that sometimes a direction of a patch changes
> during
> the mailing list discussion. And so that we end up with a commit message that
> has a different name.

 What's the problem with changing the message subject at the point the 
final change is posted, just as I did with the change I submitted (where 
you chose to actually ignore what I posted and gratuitously changed the 
commit heading from one I used anyway)?

  Maciej

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Martin Liška]

On 4/1/20 12:04 PM, Maciej W. Rozycki wrote:

On Wed, 1 Apr 2020, Martin Liška wrote:


   NB if posting as an attachment please try matching the message subject
with the change heading as otherwise it takes a lot of effort to track the
patch submission corresponding to a given commit.


I see your point, but note that sometimes a direction of a patch changes
during
the mailing list discussion. And so that we end up with a commit message that
has a different name.


  What's the problem with changing the message subject at the point the
final change is posted, just as I did with the change I submitted (where
you chose to actually ignore what I posted and gratuitously changed the
commit heading from one I used anyway)?


Yes, that was a mistake, sorry for that.

Martin



   Maciej

[stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

[Martin Liška]

Hello.

This is second attempt to get rid of tcc_comparison GENERIC trees
to be used as the first argument of VEC_COND_EXPR.

The patch attempts achieves that in the following steps:
1) veclower pass expands all tcc_comparison expression into a SSA_NAME
2) since that tcc_comparsion can't be used as the first argument of 
VEC_COND_EXPR
   (done in GIMPLE verifier)
3) I exposed new internal functions with:
DEF_INTERNAL_OPTAB_FN (VCOND, 0, vcond, vec_cond)
DEF_INTERNAL_OPTAB_FN (VCONDU, 0, vcondu, vec_condu)
DEF_INTERNAL_OPTAB_FN (VCONDEQ, 0, vcondeq, vec_condeq)
DEF_INTERNAL_OPTAB_FN (VCOND_MASK, 0, vcond_mask, vec_cond_mask)

4) logic of expand_vec_cond_expr is moved into the new pass_gimple_isel pass
5) the pass expands VEC_COND_EXPR into one of the internal functions defined in 
3)
6) moreover, I've added a new logic that prefers expand_vec_cmp_expr_p when
   a SSA_NAME is being used in multiple (2+) VEC_COND_EXPR statements

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Moreover, I run SPEC2006 and SPEC2017 benchmarks on znver1, znver2 and skylake
target and I don't see any reasonable change.

Achieved benefits of the patch:
- removal of a GENERIC expression being used in GIMPLE statements
- extraction into SSA_NAMEs can enable proper tree optimizer (FRE, DOM, PRE)
- possibility to expand smarter based on number of uses (expand_vec_cmp_expr_p)

Future plans:
- tcc_comparison removal just during gimplification
- removal of a code where these expressions are handled for VEC_COND_EXPR
- do the similar thing for COND_EXPR?

The task was guided by Richi (Biener) and I bet he can help with both further 
questions
and reasoning.

Thanks,
Martin

>From 4a6f4aa3cdef7a032a4ad442e6cd5ec2e706144d Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 9 Mar 2020 13:23:03 +0100
Subject: [PATCH] Lower VEC_COND_EXPR into internal functions.

gcc/ChangeLog:

2020-03-30  Martin Liska  

	* expr.c (expand_expr_real_2): Put gcc_unreachable, we should reach
	this path.
	(do_store_flag): Likewise here.
	* internal-fn.c (vec_cond_mask_direct): New.
	(vec_cond_direct): Likewise.
	(vec_condu_direct): Likewise.
	(vec_condeq_direct): Likewise.
	(expand_vect_cond_optab_fn): Move from optabs.c.
	(expand_vec_cond_optab_fn): New alias.
	(expand_vec_condu_optab_fn): Likewise.
	(expand_vec_condeq_optab_fn): Likewise.
	(expand_vect_cond_mask_optab_fn): Moved from optabs.c.
	(expand_vec_cond_mask_optab_fn): New alias.
	(direct_vec_cond_mask_optab_supported_p): New.
	(direct_vec_cond_optab_supported_p): Likewise.
	(direct_vec_condu_optab_supported_p): Likewise.
	(direct_vec_condeq_optab_supported_p): Likewise.
	* internal-fn.def (VCOND): New new internal optab
	function.
	(VCONDU): Likewise.
	(VCONDEQ): Likewise.
	(VCOND_MASK): Likewise.
	* optabs.c (expand_vec_cond_mask_expr): Removed.
	(expand_vec_cond_expr): Likewise.
	* optabs.h (expand_vec_cond_expr): Likewise.
	(vector_compare_rtx): Likewise.
	* passes.def: Add pass_gimple_isel.
	* tree-cfg.c (verify_gimple_assign_ternary): Add new
	GIMPLE check.
	* tree-pass.h (make_pass_gimple_isel): New.
	* tree-ssa-forwprop.c (pass_forwprop::execute): Do not forward
	to already lowered VEC_COND_EXPR.
	* tree-vect-generic.c (expand_vector_divmod): Expand to SSA_NAME.
	(expand_vector_condition): Expand tcc_comparison of a VEC_COND_EXPR
	into a SSA_NAME.
	(gimple_expand_vec_cond_expr): New.
	(gimple_expand_vec_cond_exprs): New.
	(class pass_gimple_isel): New.
	(make_pass_gimple_isel): New.
---
 gcc/expr.c  |  25 +
 gcc/internal-fn.c   |  89 
 gcc/internal-fn.def |   5 +
 gcc/optabs.c| 124 +-
 gcc/optabs.h|   7 +-
 gcc/passes.def  |   1 +
 gcc/tree-cfg.c  |   8 ++
 gcc/tree-pass.h |   1 +
 gcc/tree-ssa-forwprop.c |   6 ++
 gcc/tree-vect-generic.c | 226 ++--
 10 files changed, 338 insertions(+), 154 deletions(-)

diff --git a/gcc/expr.c b/gcc/expr.c
index b97c217e86d..d6cecd0f251 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -9200,17 +9200,8 @@ expand_expr_real_2 (sepops ops, rtx target, machine_mode tmode,
   if (temp != 0)
 	return temp;
 
-  /* For vector MIN , expand it a VEC_COND_EXPR 
-	 and similarly for MAX .  */
   if (VECTOR_TYPE_P (type))
-	{
-	  tree t0 = make_tree (type, op0);
-	  tree t1 = make_tree (type, op1);
-	  tree comparison = build2 (code == MIN_EXPR ? LE_EXPR : GE_EXPR,
-type, t0, t1);
-	  return expand_vec_cond_expr (type, comparison, t0, t1,
-   original_target);
-	}
+	gcc_unreachable ();
 
   /* At this point, a MEM target is no longer useful; we will get better
 	 code without it.  */
@@ -9799,10 +9790,6 @@ expand_expr_real_2 (sepops ops, rtx target, machine_mode tmode,
 	return temp;
   }
 
-case VEC_COND_EXPR:
-  target = expand_vec_cond_expr (type, treeop0, treeop1, treeop2, target);
-  return target;
-
 case VEC_DUPLICATE_EXPR:
   op0 = expand_expr (

Re: [PATCH] S/390: Fix PR91628

[Iain Buclaw via Gcc-patches]

On 01/04/2020 08:28, Stefan Liebler wrote:
> ping
> 

Hi Stefan,

As I've already said, I think that the name should be __ibmz_get_tls_offset to 
make clear that it is an internal function.

Other than that, looks good to me.

Iain.

Re: [PATCH] S/390: Fix layout of struct sigaction_t

[Iain Buclaw via Gcc-patches]

On 01/04/2020 08:28, Stefan Liebler wrote:
> ping
> 

Thanks, I'll send the patch upstream, as it's the same there.

Looks OK to me.

Regards
Iain.

Re: [PATCH v3 4/4] libgomp/test: Remove a build sysroot fix regression

[Maciej W. Rozycki via Gcc-patches]

On Thu, 26 Mar 2020, Chung-Lin Tang wrote:

> > Changes from v2:
> > 
> > - Do not use `--tool_exec' with AM_RUNTESTFLAGS.
> > 
> > - Move the definition of GCC_UNDER_TEST from
> >testsuite/libgomp-test-support.exp to
> >testsuite/libgomp-site-extra.exp.
> 
> Hi Maciej,
> sorry, I didn't notice you were blocked on input from us.

 No worries; I'm glad you are all right!

> I tested our testing with this patch and can confirm it works for us; 
> didn't notice any breakage.

 Thank you!  I'll be posting a revised series shortly for a libffi update; 
no change to the libgomp part on this occasion now that it works for you.

  Maciej

[PATCH] testsuite: Add testcase for already fixed PR [PR94436]

[Jakub Jelinek via Gcc-patches]

Hi!

This PR has been fixed by r10-7237-g4e3d3e40726e1b68bf52fa205c68495124ea60b8
already but we didn't have a comparable testcase.

Tested on x86_64-linux -m32/-m64, committed to trunk as obvious.

2020-04-01  Jakub Jelinek  

PR middle-end/94436
* gcc.dg/pr94436.c: New test.

--- gcc/testsuite/gcc.dg/pr94436.c.jj
+++ gcc/testsuite/gcc.dg/pr94436.c
@@ -0,0 +1,13 @@
+/* PR middle-end/94436 */
+/* { dg-do compile } */
+/* { dg-options "-Wincompatible-pointer-types" } */
+
+struct S { int s; };
+int foo (struct S *);
+
+int
+bar (void)
+{
+  int s = 0;
+  return foo ((struct S *) ((char *) &s - (char *) &((struct S *) 0)->s)); 
/* { dg-bogus "from incompatible pointer type" } */
+}

Jakub

Re: [PATCH v2 3/9] aarch64: Add cmp_*_carryinC patterns

[Segher Boessenkool]

On Tue, Mar 31, 2020 at 03:44:51PM -0700, Richard Henderson wrote:
> If we add more CC modes, does that mean that we have to improve SELECT_CC_MODE
> to match those patterns?  Or do we add new CC modes just so that combine's use
> of SELECT_CC_MODE *cannot* match them?

Adding new CC modes isn't helpful if nothing ever generates them.  To
have combine decide to use a different CC mode for a combined insn, you
need SELECT_CC_MODE.

The result of a combination is always valid (as RTL) with the original
CC mode, but such an insn might not exist, and perhaps it does exist
with some weaker CC mode (or more general CC mode, in some cases).


Segher

Re: [committed] testsuite: Split up gdc-test.exp into each subdirectory

[Rainer Orth]

Hi Iain,

> This patch splits up gdc-test.exp into multiple test scipts, one for
> each subdirectory containing test files, instead of having one test
> script to manage them all.
>
> This allows removing some workarounds, such as the need to create
> symlinks in the test run directory.

unfortunately this caused the gdc.test test names to lose their subdir
prefix again: instead of

-FAIL: gdc.test/runnable/eh.d -fPIC -shared-libphobos   execution test

you now have

+FAIL: runnable/eh.d -fPIC -shared-libphobos   execution test

without the gdc.test.  Since testnames are supposed to be relative to
gcc/testsuite, this needs to be fixed.

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

[PATCH][RFC] c/94392 - only enable -ffinite-loops for C++

[Richard Biener]

This does away with enabling -ffinite-loops at -O2+ for all languages
and instead enables it selectively for C++ only.

Jason, I didn't find a reference as to when the forward progress
guarantee was introduced to C++ so I randomly chose C++11, is that
correct?

Joseph, this simply never enables -ffinite-loops for C by default
also based on the fact this was added in the first place for C++
standard library abstraction removal thus without any real-world
C testcases.

Bootstrap / regtest in progress - I expect I need to add explicit
-ffinite-loops to a few testcases (and fixup the changelog).

I did not look whether other languages guarantee forward progress
but the feature is new in GCC 10 and restricting it to C++ is
sensible I think.

Any further comments?

Writing a runtime testcase is hard since by definition it would
not finish.  I'll construct a scan-tree-dump one.

Thanks,
Richard.

2020-04-01  Richard Biener  

PR c/94392
* c-opts.c (): Enable -ffinite-loops for -O2 and C++11.

* common.opt (ffinite-loops): Initialize to zero.
* opts.c (default_options_table): Remove OPT_ffinite_loops
entry.
* ipa-inline.c (): Match up -ffinite-loops.
* doc/invoke.texi (ffinite-loops): Adjust documentation of
default setting.
---
 gcc/c-family/c-opts.c | 4 
 gcc/common.opt| 2 +-
 gcc/doc/invoke.texi   | 3 ++-
 gcc/ipa-inline.c  | 5 -
 gcc/opts.c| 1 -
 5 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 6b6c754ad86..58ba0948e79 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -989,6 +989,10 @@ c_common_post_options (const char **pfilename)
   SET_OPTION_IF_UNSET (&global_options, &global_options_set, flag_new_ttp,
   cxx_dialect >= cxx17);
 
+  /* C++11 guarantees forward progress.  */
+  SET_OPTION_IF_UNSET (&global_options, &global_options_set, flag_finite_loops,
+  optimize >= 2 && cxx_dialect >= cxx11);
+
   if (cxx_dialect >= cxx11)
 {
   /* If we're allowing C++0x constructs, don't warn about C++98
diff --git a/gcc/common.opt b/gcc/common.opt
index 4368910cb54..bb2ea4c905d 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1490,7 +1490,7 @@ Common Report Var(flag_finite_math_only) Optimization 
SetByCombined
 Assume no NaNs or infinities are generated.
 
 ffinite-loops
-Common Report Var(flag_finite_loops) Optimization
+Common Report Var(flag_finite_loops) Optimization Init(0)
 Assume that loops with an exit will terminate and not loop indefinitely.
 
 ffixed-
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 412750c1fc9..142bfeacead 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10432,7 +10432,8 @@ Assume that a loop with an exit will eventually take 
the exit and not loop
 indefinitely.  This allows the compiler to remove loops that otherwise have
 no side-effects, not considering eventual endless looping as such.
 
-This option is enabled by default at @option{-O2}.
+This option is enabled by default at @option{-O2} for C++ with -std=c++11
+or higher.
 
 @item -ftree-dominator-opts
 @opindex ftree-dominator-opts
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 302ce16a646..d0e59d431ca 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge *e, bool 
report,
  /* When devirtualization is disabled for callee, it is not safe
 to inline it as we possibly mangled the type info.
 Allow early inlining of always inlines.  */
- || (!early && check_maybe_down (flag_devirtualize)))
+ || (!early && check_maybe_down (flag_devirtualize))
+ /* It's not safe to inline a function where loops maybe
+infinite into a function where we assume the reverse.  */
+ || check_maybe_down (flag_finite_loops))
{
  e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
  inlinable = false;
diff --git a/gcc/opts.c b/gcc/opts.c
index 5dc7d65dedd..d4df8627bf7 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -478,7 +478,6 @@ static const struct default_options default_options_table[] 
=
 { OPT_LEVELS_2_PLUS, OPT_fdevirtualize, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_fdevirtualize_speculatively, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_fexpensive_optimizations, NULL, 1 },
-{ OPT_LEVELS_2_PLUS, OPT_ffinite_loops, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_fgcse, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_fhoist_adjacent_loads, NULL, 1 },
 { OPT_LEVELS_2_PLUS, OPT_findirect_inlining, NULL, 1 },
-- 
2.25.1

Re: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 01, 2020 at 03:36:30PM +0200, Richard Biener wrote:
> @@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge *e, bool 
> report,
> /* When devirtualization is disabled for callee, it is not safe
>to inline it as we possibly mangled the type info.
>Allow early inlining of always inlines.  */
> -   || (!early && check_maybe_down (flag_devirtualize)))
> +   || (!early && check_maybe_down (flag_devirtualize))
> +   /* It's not safe to inline a function where loops maybe
> +  infinite into a function where we assume the reverse.  */
> +   || check_maybe_down (flag_finite_loops))
>   {
> e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
> inlinable = false;

Couldn't the above care only if the function has any loops?
Otherwise, won't it prevent cross-language LTO inlining too much?
Or instead of disabling inlining arrange for a safe flag_finite_loops value
for the resulting function (set some flag in cfun of the function that would
be considered together with flag_finite_loops (so that we don't have to
create further OPTIMIZATION_NODEs) and disable finite loops opts if we've
inlined !flag_finite_loops function into flag_finite_loops one)?

Jakub

Re: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++

[Richard Biener]

On Wed, 1 Apr 2020, Jakub Jelinek wrote:

> On Wed, Apr 01, 2020 at 03:36:30PM +0200, Richard Biener wrote:
> > @@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge *e, 
> > bool report,
> >   /* When devirtualization is disabled for callee, it is not safe
> >  to inline it as we possibly mangled the type info.
> >  Allow early inlining of always inlines.  */
> > - || (!early && check_maybe_down (flag_devirtualize)))
> > + || (!early && check_maybe_down (flag_devirtualize))
> > + /* It's not safe to inline a function where loops maybe
> > +infinite into a function where we assume the reverse.  */
> > + || check_maybe_down (flag_finite_loops))
> > {
> >   e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
> >   inlinable = false;
> 
> Couldn't the above care only if the function has any loops?
> Otherwise, won't it prevent cross-language LTO inlining too much?
> Or instead of disabling inlining arrange for a safe flag_finite_loops value
> for the resulting function (set some flag in cfun of the function that would
> be considered together with flag_finite_loops (so that we don't have to
> create further OPTIMIZATION_NODEs) and disable finite loops opts if we've
> inlined !flag_finite_loops function into flag_finite_loops one)?

I guess I can split out this hunk from the patch - it's a separate
issue affecting also C++ with mixed option CUs.  Yes, ideally we'd
simply initialize loop->finite_p from flag_finite_loops at CFG
construction time and then only ever check the flag on the loop
structure.  That would leave us with infinite loops for loops
we only discover later though.  It also opens up the possibility
of a per-loop #pragma.

Richard.

Re: rs6000 - allow builtin initialization regardless of mask

[will schmidt via Gcc-patches]

On Thu, 2020-03-26 at 14:23 -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Mar 23, 2020 at 03:18:25PM -0500, will schmidt wrote:
> >   Disable the code that limits initialization of builtins based
> > on the rs6000_builtin_mask.  This allows all built-ins to be
> > properly referenced when building code using #pragma for cpu
> > targets newer than what was specified by the -mcpu default.
> > The use of built-ins is still properly limited by logic within
> > altivec_resolve_overloaded_builtin().
> > 
> > I'm still reviewing test results for any regressions.
> > 
> > OK for master?
> 
> Okay (if those tests pass ;-) ), thanks!  Just a few nits:

They did.  :-)  I committed this on Monday.

Is this one also OK for backports?   (after a week or so to let it bake
a bit more). 

Thanks
-Will

> 
> 
> > * config/rs6000/rs6000-call.c
> > altivec_init_builtins():  Remove code
> > to skip defining builtins based on builtin_mask.
> 
>   * config/rs6000/rs6000-call.c (altivec_init_builtins): Remove
> code
>   to skip defining builtins based on builtin_mask.
> 
> 
> > testsuite/
> 
> gcc/testsuite/
> 
> 
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/pragma_misc9.c
> > @@ -0,0 +1,47 @@
> > +/* { dg-do compile { target { powerpc*-*-* } } } */
> 
> This is the default for anything in gcc.target/powerpc?  { dg-do
> compile }
> can be useful (for a reader; for the test itself it is default as
> well),
> but drop the target selector please?
> 
> 
> Segher

RE: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Kyrylo Tkachov]

Adding gcc-patches as I had somehow deleted it from the addresses...

> -Original Message-
> From: Kyrylo Tkachov
> Sent: 01 April 2020 15:23
> To: Pop, Sebastian 
> Cc: Wilco Dijkstra ; richard.hender...@linaro.org
> Subject: RE: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x
> 
> Hi Sebastian,
> 
> > -Original Message-
> > From: Gcc-patches  On Behalf Of Pop,
> > Sebastian via Gcc-patches
> > Sent: 31 March 2020 16:47
> > To: Kyrill Tkachov ;
> > gcc-patches@gcc.gnu.org
> > Cc: Wilco Dijkstra ;
> > richard.hender...@linaro.org
> > Subject: Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and
> > 8.x
> >
> > Ping, can we have the -moutline-atomics patches committed to the gcc-9
> > branch?
> 
> Thanks for testing the patches.
> 
> >
> > Thanks,
> > Sebastian
> >
> > On 3/24/20, 7:24 PM, "Pop, Sebastian"  wrote:
> >
> > Hi Kyrill,
> >
> > Thanks for pointing out the two missing bug fixes.
> > Please see attached all the back-ported patches.
> > All the patches from trunk applied cleanly with no conflicts
> > (except for the ChangeLog files) to the gcc-9 branch.
> > An up to date gcc-9 branch on which I applied the attached patches
> > has passed bootstrap on aarch64-linux (Graviton2 with 64 N1 cores) and
> > make check with no extra fails.
> > Kyrill, could you please commit the attached patches to the gcc-9 
> > branch?
> 
> This series also needs Jakub's recent fix: https://gcc.gnu.org/pipermail/gcc-
> patches/2020-March/542952.html
> I've tested this together with the rest and committed the whole series to the
> gcc-9 branch.
> 
> >
> > As we still don't have a copyright assignment on file, would it be
> > possible for ARM to finish the backport to the gcc-8 branch of these
> > patches and the atomics cleanup patches mentioned below?
> 
> I can help with that, but any help with testing the patch set would be
> appreciated.
> Thanks,
> Kyrill
> 
> >
> > I did a `git log config/aarch64/atomics.md` and there is a
> > follow-up patch to the atomics cleanup patches:
> >
> > commit e21679a8bb17aac603b8704891e60ac502200629
> > Author: Jakub Jelinek 
> > Date:   Wed Nov 21 17:41:03 2018 +0100
> >
> > re PR target/87839 (ICE in final_scan_insn_1, at final.c:3070)
> >
> > PR target/87839
> > * config/aarch64/atomics.md
> > (@aarch64_compare_and_swap): Use
> > rIJ constraint for aarch64_plus_operand rather than rn.
> >
> > * gcc.target/aarch64/pr87839.c: New test.
> >
> > From-SVN: r266346
> >
> > That is fixing code modified in this cleanup patch:
> >
> > commit d400fda3a8c3330f77eb9d51874f5482d3819a9f
> > Author: Richard Henderson 
> > Date:   Wed Oct 31 09:42:39 2018 +
> >
> > aarch64: Improve cas generation
> >
> >
> > Thanks,
> > Sebastian
> >
> >
> > On 3/11/20, 5:11 AM, "Kyrill Tkachov"
> > 
> > wrote:
> >
> > CAUTION: This email originated from outside of the
> > organization. Do not click links or open attachments unless you can
> > confirm the sender and know the content is safe.
> >
> >
> >
> > Hi Sebastian,
> >
> > On 3/9/20 9:47 PM, Pop, Sebastian wrote:
> > > Hi,
> > >
> > > Please see attached the patches to add -moutline-atomics to
> > the gcc-9 branch.
> > > Tested on graviton2 aarch64-linux with bootstrap and
> > > `make check` passes with no new fails.
> > > Tested `make check` on glibc built with gcc-9 with and
> > without "- moutline-atomics"
> > > and CFLAGS=" -O2 -g -fno-stack-protector -U_FORTIFY_SOURCE".
> > >
> > > Ok to commit to gcc-9 branch?
> >
> > Since this feature enables backwards-compatible deployment of LSE
> > atomics, I'd support that.
> >
> > That is okay with me in principle after GCC 9.3 is released (the 
> > branch
> > is currently frozen).
> >
> > However, there have been a few follow-up patches to fix some bugs
> > revealed by testing.
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833
> >
> > and
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834
> >
> > come to mind.
> >
> > Can you please make sure the fixes for those are included as well?
> >
> >
> > >
> > > Does this mechanical `git am *.patch` require a copyright 
> > assignment?
> > > I am still working with my employer on getting the FSF
> > assignment signed.
> > >
> > > Thanks,
> > > Sebastian
> > >
> > > PS: For gcc-8 backports there are 5 cleanup and improvement
> patches
> > > that are needed for -moutline-atomics patches to apply cleanly.
> > > Should these patches be back-ported in the same time as the
> > flag patches,
> > > or should I update the patches to apply to the older code base?
> >
> > Hmm... normally I'd be f

Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Pop, Sebastian via Gcc-patches]

Thanks Kyrill!  I will be happy to test the gcc-8 back-port of the patches.

We would also need to back-port the patches to gcc-7.
I hope it is ok to commit the changes to the gcc-7 branch even if it is not a 
maintained branch.

Sebastian

On 4/1/20, 9:27 AM, "Kyrylo Tkachov"  wrote:

CAUTION: This email originated from outside of the organization. Do not 
click links or open attachments unless you can confirm the sender and know the 
content is safe.



Adding gcc-patches as I had somehow deleted it from the addresses...

> -Original Message-
> From: Kyrylo Tkachov
> Sent: 01 April 2020 15:23
> To: Pop, Sebastian 
> Cc: Wilco Dijkstra ; richard.hender...@linaro.org
> Subject: RE: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x
>
> Hi Sebastian,
>
> > -Original Message-
> > From: Gcc-patches  On Behalf Of Pop,
> > Sebastian via Gcc-patches
> > Sent: 31 March 2020 16:47
> > To: Kyrill Tkachov ;
> > gcc-patches@gcc.gnu.org
> > Cc: Wilco Dijkstra ;
> > richard.hender...@linaro.org
> > Subject: Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and
> > 8.x
> >
> > Ping, can we have the -moutline-atomics patches committed to the gcc-9
> > branch?
>
> Thanks for testing the patches.
>
> >
> > Thanks,
> > Sebastian
> >
> > On 3/24/20, 7:24 PM, "Pop, Sebastian"  wrote:
> >
> > Hi Kyrill,
> >
> > Thanks for pointing out the two missing bug fixes.
> > Please see attached all the back-ported patches.
> > All the patches from trunk applied cleanly with no conflicts
> > (except for the ChangeLog files) to the gcc-9 branch.
> > An up to date gcc-9 branch on which I applied the attached patches
> > has passed bootstrap on aarch64-linux (Graviton2 with 64 N1 cores) and
> > make check with no extra fails.
> > Kyrill, could you please commit the attached patches to the gcc-9 
branch?
>
> This series also needs Jakub's recent fix: 
https://gcc.gnu.org/pipermail/gcc-
> patches/2020-March/542952.html
> I've tested this together with the rest and committed the whole series to 
the
> gcc-9 branch.
>
> >
> > As we still don't have a copyright assignment on file, would it be
> > possible for ARM to finish the backport to the gcc-8 branch of these
> > patches and the atomics cleanup patches mentioned below?
>
> I can help with that, but any help with testing the patch set would be
> appreciated.
> Thanks,
> Kyrill
>
> >
> > I did a `git log config/aarch64/atomics.md` and there is a
> > follow-up patch to the atomics cleanup patches:
> >
> > commit e21679a8bb17aac603b8704891e60ac502200629
> > Author: Jakub Jelinek 
> > Date:   Wed Nov 21 17:41:03 2018 +0100
> >
> > re PR target/87839 (ICE in final_scan_insn_1, at final.c:3070)
> >
> > PR target/87839
> > * config/aarch64/atomics.md
> > (@aarch64_compare_and_swap): Use
> > rIJ constraint for aarch64_plus_operand rather than rn.
> >
> > * gcc.target/aarch64/pr87839.c: New test.
> >
> > From-SVN: r266346
> >
> > That is fixing code modified in this cleanup patch:
> >
> > commit d400fda3a8c3330f77eb9d51874f5482d3819a9f
> > Author: Richard Henderson 
> > Date:   Wed Oct 31 09:42:39 2018 +
> >
> > aarch64: Improve cas generation
> >
> >
> > Thanks,
> > Sebastian
> >
> >
> > On 3/11/20, 5:11 AM, "Kyrill Tkachov"
> > 
> > wrote:
> >
> > CAUTION: This email originated from outside of the
> > organization. Do not click links or open attachments unless you can
> > confirm the sender and know the content is safe.
> >
> >
> >
> > Hi Sebastian,
> >
> > On 3/9/20 9:47 PM, Pop, Sebastian wrote:
> > > Hi,
> > >
> > > Please see attached the patches to add -moutline-atomics to
> > the gcc-9 branch.
> > > Tested on graviton2 aarch64-linux with bootstrap and
> > > `make check` passes with no new fails.
> > > Tested `make check` on glibc built with gcc-9 with and
> > without "- moutline-atomics"
> > > and CFLAGS=" -O2 -g -fno-stack-protector -U_FORTIFY_SOURCE".
> > >
> > > Ok to commit to gcc-9 branch?
> >
> > Since this feature enables backwards-compatible deployment of 
LSE
> > atomics, I'd support that.
> >
> > That is okay with me in principle after GCC 9.3 is released 
(the branch
> > is currently frozen).
> >
> > However, there have been a few follow-up patches to fix some

RE: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Kyrylo Tkachov]

Hi Sebastian,

> -Original Message-
> From: Pop, Sebastian 
> Sent: 01 April 2020 15:32
> To: Kyrylo Tkachov 
> Cc: Wilco Dijkstra ; richard.hender...@linaro.org;
> gcc-patches@gcc.gnu.org
> Subject: Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x
> 
> Thanks Kyrill!  I will be happy to test the gcc-8 back-port of the patches.
> 
> We would also need to back-port the patches to gcc-7.
> I hope it is ok to commit the changes to the gcc-7 branch even if it is not a
> maintained branch.

I don't think that will work. Given that the branch is not maintained there 
won't be any more point releases off of it.
Of course, if you have your own gcc-7-based vendor branch that's another 
matter...
Thanks,
Kyrill

> 
> Sebastian
> 
> On 4/1/20, 9:27 AM, "Kyrylo Tkachov"  wrote:
> 
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
> 
> 
> 
> Adding gcc-patches as I had somehow deleted it from the addresses...
> 
> > -Original Message-
> > From: Kyrylo Tkachov
> > Sent: 01 April 2020 15:23
> > To: Pop, Sebastian 
> > Cc: Wilco Dijkstra ;
> richard.hender...@linaro.org
> > Subject: RE: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x
> >
> > Hi Sebastian,
> >
> > > -Original Message-
> > > From: Gcc-patches  On Behalf Of
> Pop,
> > > Sebastian via Gcc-patches
> > > Sent: 31 March 2020 16:47
> > > To: Kyrill Tkachov ;
> > > gcc-patches@gcc.gnu.org
> > > Cc: Wilco Dijkstra ;
> > > richard.hender...@linaro.org
> > > Subject: Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and
> > > 8.x
> > >
> > > Ping, can we have the -moutline-atomics patches committed to the gcc-
> 9
> > > branch?
> >
> > Thanks for testing the patches.
> >
> > >
> > > Thanks,
> > > Sebastian
> > >
> > > On 3/24/20, 7:24 PM, "Pop, Sebastian"  wrote:
> > >
> > > Hi Kyrill,
> > >
> > > Thanks for pointing out the two missing bug fixes.
> > > Please see attached all the back-ported patches.
> > > All the patches from trunk applied cleanly with no conflicts
> > > (except for the ChangeLog files) to the gcc-9 branch.
> > > An up to date gcc-9 branch on which I applied the attached patches
> > > has passed bootstrap on aarch64-linux (Graviton2 with 64 N1 cores)
> and
> > > make check with no extra fails.
> > > Kyrill, could you please commit the attached patches to the gcc-9
> branch?
> >
> > This series also needs Jakub's recent fix:
> https://gcc.gnu.org/pipermail/gcc-
> > patches/2020-March/542952.html
> > I've tested this together with the rest and committed the whole series 
> to
> the
> > gcc-9 branch.
> >
> > >
> > > As we still don't have a copyright assignment on file, would it be
> > > possible for ARM to finish the backport to the gcc-8 branch of these
> > > patches and the atomics cleanup patches mentioned below?
> >
> > I can help with that, but any help with testing the patch set would be
> > appreciated.
> > Thanks,
> > Kyrill
> >
> > >
> > > I did a `git log config/aarch64/atomics.md` and there is a
> > > follow-up patch to the atomics cleanup patches:
> > >
> > > commit e21679a8bb17aac603b8704891e60ac502200629
> > > Author: Jakub Jelinek 
> > > Date:   Wed Nov 21 17:41:03 2018 +0100
> > >
> > > re PR target/87839 (ICE in final_scan_insn_1, at final.c:3070)
> > >
> > > PR target/87839
> > > * config/aarch64/atomics.md
> > > (@aarch64_compare_and_swap): Use
> > > rIJ constraint for aarch64_plus_operand rather than 
> rn.
> > >
> > > * gcc.target/aarch64/pr87839.c: New test.
> > >
> > > From-SVN: r266346
> > >
> > > That is fixing code modified in this cleanup patch:
> > >
> > > commit d400fda3a8c3330f77eb9d51874f5482d3819a9f
> > > Author: Richard Henderson 
> > > Date:   Wed Oct 31 09:42:39 2018 +
> > >
> > > aarch64: Improve cas generation
> > >
> > >
> > > Thanks,
> > > Sebastian
> > >
> > >
> > > On 3/11/20, 5:11 AM, "Kyrill Tkachov"
> > > 
> > > wrote:
> > >
> > > CAUTION: This email originated from outside of the
> > > organization. Do not click links or open attachments unless you can
> > > confirm the sender and know the content is safe.
> > >
> > >
> > >
> > > Hi Sebastian,
> > >
> > > On 3/9/20 9:47 PM, Pop, Sebastian wrote:
> > > > Hi,
> > > >
> > > > Please see attached the patches to add -moutline-atomics to
> > > the gcc-9 b

Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 01, 2020 at 02:32:03PM +, Pop, Sebastian via Gcc-patches wrote:
> Thanks Kyrill!  I will be happy to test the gcc-8 back-port of the patches.

Note, I have another fix, PR94435, that I've already bootstrapped and am
regtesting ATM, that will need to be included in any backports too (if acked
for trunk).
> 
> We would also need to back-port the patches to gcc-7.
> I hope it is ok to commit the changes to the gcc-7 branch even if it is not a 
> maintained branch.

No, that is not ok, the branch is closed and shouldn't have any changes.
You can create some vendor or devel or user branch for it though, merge
there the releases/gcc-7 and add whatever backports you want.

Jakub

Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Pop, Sebastian via Gcc-patches]

Thanks Jakub and Kyrill to point that out.
We will create a new branch called gcc-7-aarch64-outline-atomics or so with the 
back-ported patches.

Sebastian

On 4/1/20, 9:36 AM, "Jakub Jelinek"  wrote:

CAUTION: This email originated from outside of the organization. Do not 
click links or open attachments unless you can confirm the sender and know the 
content is safe.



On Wed, Apr 01, 2020 at 02:32:03PM +, Pop, Sebastian via Gcc-patches 
wrote:
> Thanks Kyrill!  I will be happy to test the gcc-8 back-port of the 
patches.

Note, I have another fix, PR94435, that I've already bootstrapped and am
regtesting ATM, that will need to be included in any backports too (if acked
for trunk).
>
> We would also need to back-port the patches to gcc-7.
> I hope it is ok to commit the changes to the gcc-7 branch even if it is 
not a maintained branch.

No, that is not ok, the branch is closed and shouldn't have any changes.
You can create some vendor or devel or user branch for it though, merge
there the releases/gcc-7 and add whatever backports you want.

Jakub

Re: [pushed] c++: Fix DMI with lambda 'this' capture [PR94205]

[Patrick Palka via Gcc-patches]

On Wed, 1 Apr 2020, Jason Merrill wrote:

> We represent 'this' in a default member initializer with a PLACEHOLDER_EXPR.
> Normally in constexpr evaluation when we encounter one it refers to
> ctx->ctor, but when we're creating a temporary of class type, that replaces
> ctx->ctor, so a PLACEHOLDER_EXPR that refers to the type of the member being
> initialized needs to be replaced before that happens.
> 
> This patch fixes the testcase below, but not the original testcase from the 
> PR,
> which is still broken due to PR94219.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk and 9.
> 
> gcc/cp/ChangeLog
> 2020-03-31  Jason Merrill  
> 
>   PR c++/94205
>   * constexpr.c (cxx_eval_constant_expression) [TARGET_EXPR]: Call
>   replace_placeholders.
>   * typeck2.c (store_init_value): Fix arguments to
>   fold_non_dependent_expr.
> ---
>  gcc/cp/constexpr.c|  6 ++
>  gcc/cp/tree.c |  2 +-
>  gcc/cp/typeck2.c  |  2 +-
>  gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C | 20 +++
>  gcc/testsuite/g++.dg/cpp1z/lambda-this4.C | 13 
>  5 files changed, 41 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
>  create mode 100644 gcc/testsuite/g++.dg/cpp1z/lambda-this4.C
> 
> diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> index e85b3c113f0..91f0c3ba269 100644
> --- a/gcc/cp/constexpr.c
> +++ b/gcc/cp/constexpr.c
> @@ -5553,6 +5553,12 @@ cxx_eval_constant_expression (const constexpr_ctx 
> *ctx, tree t,
>   tree init = TARGET_EXPR_INITIAL (t);
>   if ((AGGREGATE_TYPE_P (type) || VECTOR_TYPE_P (type)))
> {
> + if (ctx->object)
> +   /* If the initializer contains any PLACEHOLDER_EXPR, we need to
> +  resolve them before we create a new CONSTRUCTOR for the
> +  temporary.  */
> +   init = replace_placeholders (init, ctx->object);

I think I'm running into an issue due to this call to replace_placeholders.
After this change, the following (compiled with -std=c++17) ICEs

struct S
{
  int a = [this] { return 6; } ();
};

S
foo()
{
  return {};
}

with

internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2830

Unsharing 'init' before before doing replace_placeholders seems to fix
this ICE.

(This came up while working on PR94034, which seems like it may admit a
fix that's similar to this one for PR94205.)

> +
>   /* We're being expanded without an explicit target, so start
>  initializing a new object; expansion with an explicit target
>  strips the TARGET_EXPR before we get here.  */
> diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
> index a2172dea0d8..5eb0dcd717a 100644
> --- a/gcc/cp/tree.c
> +++ b/gcc/cp/tree.c
> @@ -3239,7 +3239,7 @@ replace_placeholders_r (tree* t, int* walk_subtrees, 
> void* data_)
> a PLACEHOLDER_EXPR has been encountered.  */
>  
>  tree
> -replace_placeholders (tree exp, tree obj, bool *seen_p)
> +replace_placeholders (tree exp, tree obj, bool *seen_p /*= NULL*/)
>  {
>/* This is only relevant for C++14.  */
>if (cxx_dialect < cxx14)
> diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
> index bff4ddbcf81..cf1cb5ace66 100644
> --- a/gcc/cp/typeck2.c
> +++ b/gcc/cp/typeck2.c
> @@ -871,7 +871,7 @@ store_init_value (tree decl, tree init, vec va_gc>** cleanups, int flags)
>  {
>bool const_init;
>tree oldval = value;
> -  value = fold_non_dependent_expr (value);
> +  value = fold_non_dependent_expr (value, tf_warning_or_error, true, 
> decl);
>if (DECL_DECLARED_CONSTEXPR_P (decl)
> || (DECL_IN_AGGR_P (decl)
> && DECL_INITIALIZED_IN_CLASS_P (decl)))
> diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C 
> b/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
> new file mode 100644
> index 000..c51f734a134
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
> @@ -0,0 +1,20 @@
> +// PR c++/94205
> +// { dg-do compile { target c++14 } }
> +
> +struct S
> +{
> +  struct A
> +  {
> +S *p;
> +constexpr A(S* p): p(p) {}
> +constexpr operator int() { p->i = 5; return 6; }
> +  };
> +  int i;
> +  int a = A(this);
> +};
> +
> +
> +constexpr S s = {};
> +
> +#define SA(X) static_assert((X),#X)
> +SA(s.i == 5 && s.a == 6);
> diff --git a/gcc/testsuite/g++.dg/cpp1z/lambda-this4.C 
> b/gcc/testsuite/g++.dg/cpp1z/lambda-this4.C
> new file mode 100644
> index 000..5d968791491
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp1z/lambda-this4.C
> @@ -0,0 +1,13 @@
> +// PR c++/94205
> +// { dg-do compile { target c++17 } }
> +
> +struct S
> +{
> +  int i;
> +  int a = [this] { this->i = 5; return 6; } ();
> +};
> +
> +
> +constexpr S s = {};
> +
> +static_assert (s.i == 5 && s.a == 6);
> 
> base-commit: f14b41d27124601284347a10d496362c8b4b8e1c
> -- 
> 2.18.1
> 
> 

[PATCH]libstdc++-v3/test: Skip "use_service.cc" for aarch64 baremetal

[Andrea Corallo]

Hi all,

"use_service.cc" libstdc++ test does not compile for baremetal,
unfortunately AFAIK we don't have an appropriate selector to skip
these.

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

https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg01089.html

While the full issue is tackled would be possible to install this
patch to have it disabled on aarch64 baremetal where it is known to
be failing?

Thanks

  Andrea

libstdc++-v3/ChangeLog
2020-??-??  Andrea Corallo  

* testsuite/experimental/net/execution_context/use_service.cc:
Skip on aarch64-none-elf.
>From 23a0b92477b976a5f9e9df20fdaac90c943ba840 Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Wed, 1 Apr 2020 10:19:04 +0100
Subject: [PATCH] testsuite: disabled use_service on aarch64 bare metal

---
 .../testsuite/experimental/net/execution_context/use_service.cc  | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libstdc++-v3/testsuite/experimental/net/execution_context/use_service.cc b/libstdc++-v3/testsuite/experimental/net/execution_context/use_service.cc
index 8a2d03fb1bb8..9cf97618e64b 100644
--- a/libstdc++-v3/testsuite/experimental/net/execution_context/use_service.cc
+++ b/libstdc++-v3/testsuite/experimental/net/execution_context/use_service.cc
@@ -16,6 +16,7 @@
 // .
 
 // { dg-do run { target c++14 } }
+// { dg-skip-if "Disable on aarch64 bare metal" { aarch64*-*-elf } }
 
 #include 
 #include 
-- 
2.17.1

Re: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++

[Jan Hubicka]

> On Wed, 1 Apr 2020, Jakub Jelinek wrote:
> 
> > On Wed, Apr 01, 2020 at 03:36:30PM +0200, Richard Biener wrote:
> > > @@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge *e, 
> > > bool report,
> > > /* When devirtualization is disabled for callee, it is not safe
> > >to inline it as we possibly mangled the type info.
> > >Allow early inlining of always inlines.  */
> > > -   || (!early && check_maybe_down (flag_devirtualize)))
> > > +   || (!early && check_maybe_down (flag_devirtualize))
> > > +   /* It's not safe to inline a function where loops maybe
> > > +  infinite into a function where we assume the reverse.  */
> > > +   || check_maybe_down (flag_finite_loops))
> > >   {
> > > e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
> > > inlinable = false;
> > 
> > Couldn't the above care only if the function has any loops?
> > Otherwise, won't it prevent cross-language LTO inlining too much?
> > Or instead of disabling inlining arrange for a safe flag_finite_loops value
> > for the resulting function (set some flag in cfun of the function that would
> > be considered together with flag_finite_loops (so that we don't have to
> > create further OPTIMIZATION_NODEs) and disable finite loops opts if we've
> > inlined !flag_finite_loops function into flag_finite_loops one)?
> 
> I guess I can split out this hunk from the patch - it's a separate
> issue affecting also C++ with mixed option CUs.  Yes, ideally we'd
> simply initialize loop->finite_p from flag_finite_loops at CFG
> construction time and then only ever check the flag on the loop
> structure.  That would leave us with infinite loops for loops
> we only discover later though.  It also opens up the possibility
> of a per-loop #pragma.

We do want to preserve cross-module inlining between C and C++, so we
really should go with marking the loops pre-inline about finiteness and
try to preserve the info, otherwise we are going to lose quite some
optimizations.

Honza
> 
> Richard.

Re: [PATCH]libstdc++-v3/test: Skip "use_service.cc" for aarch64 baremetal

[Jonathan Wakely via Gcc-patches]

On 01/04/20 17:28 +0200, Andrea Corallo wrote:

Hi all,

"use_service.cc" libstdc++ test does not compile for baremetal,
unfortunately AFAIK we don't have an appropriate selector to skip
these.

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

https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg01089.html

While the full issue is tackled would be possible to install this
patch to have it disabled on aarch64 baremetal where it is known to
be failing?


No, I don't want to paper over the problem on every individual target
where they fail.

The correct fix is either to mark the tests as requiring gthreads (as
most tests under libstdc++-v3/testsuite/30_threads/ do) or to modify
the library code to work without mutexes for targets without thread
support.

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Maciej W. Rozycki]

On Wed, 1 Apr 2020, Martin Liška wrote:

> >> I've just installed the patch.
> >> @H.J. Can you please pull it to bintuils?
> > 
> >   Why didn't you use the commit as I published it
> 
> Because it didn't fit my script that takes changelog entries
> and moves that to the corresponding ChangeLog files.
> Next time, you will install the patch by your own.

 That was the intent: I asked for approval to commit, which is the usual 
practice for people who have write access to the repo, and not to commit 
on my behalf.

> > and also assumed
> > authorship of my change?  I feel insulted.
> 
> I removed myself from the ownership of the patch here:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d3ee88fdb4e0f718aaba050a3eb7174b8934a29d

 I don't think it has changed anything:

commit 142d68f50b48309f48e34fc1d9d6dbbeecfde684
Author: Martin Liska 
AuthorDate: Wed Apr 1 09:37:37 2020 +0200
Commit: Martin Liska 
CommitDate: Wed Apr 1 09:37:37 2020 +0200

You're still listed as the author of the change in question.

  Maciej

Re: [PATCH]libstdc++-v3/test: Skip "use_service.cc" for aarch64 baremetal

[Jonathan Wakely via Gcc-patches]

On 01/04/20 16:56 +0100, Jonathan Wakely wrote:

On 01/04/20 17:28 +0200, Andrea Corallo wrote:

Hi all,

"use_service.cc" libstdc++ test does not compile for baremetal,
unfortunately AFAIK we don't have an appropriate selector to skip
these.

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

https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg01089.html

While the full issue is tackled would be possible to install this
patch to have it disabled on aarch64 baremetal where it is known to
be failing?


No, I don't want to paper over the problem on every individual target
where they fail.

The correct fix is either to mark the tests as requiring gthreads (as
most tests under libstdc++-v3/testsuite/30_threads/ do) or to modify


e.g. something like:

// { dg-do run }
// { dg-options "-pthread"  }
// { dg-require-effective-target c++14 }
// { dg-require-effective-target pthread }
// { dg-require-gthreads "" }

Does that help, or does it still fail for other reasons?



the library code to work without mutexes for targets without thread
support.

Re: [PATCH] S/390: Fix layout of struct sigaction_t

[Stefan Liebler via Gcc-patches]

On 4/1/20 12:54 PM, Iain Buclaw wrote:

On 01/04/2020 08:28, Stefan Liebler wrote:

ping



Thanks, I'll send the patch upstream, as it's the same there.

Looks OK to me.

Regards
Iain.



Thanks for committing the patch upstream

Re: [PATCH] S/390: Fix PR91628

[Stefan Liebler via Gcc-patches]

On 4/1/20 12:50 PM, Iain Buclaw wrote:



On 01/04/2020 08:28, Stefan Liebler wrote:

ping



Hi Stefan,

As I've already said, I think that the name should be __ibmz_get_tls_offset to 
make clear that it is an internal function.

Other than that, looks good to me.

Iain.



Hi Iain,

Sorry. I've missed your comment in the bugzilla.
I've updated the name to __ibmz_get_this_offset.
Nothing else is changed in the attached patch.

Please commit the patch upstream.
Do you also close the bugzilla as soon as committed?

Regarding the mentioned musl-patch in your bugzilla comment:
Yes, the diff looks like not conflicting.

Thanks,
Stefan
commit 98dd0351159449228df6069c8b9a9c2b1e31d683
Author: Stefan Liebler 
Date:   Mon Mar 16 15:06:08 2020 +0100

S/390: Fix PR91628

This patch picks up Robin Dapps patch __tls_get_offset-in-separate.S.
See "Bugzilla 91628 - libdruntime uses glibc internal symbol on s390"
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628)

The patch has not applied as is, therefore I've just regenerated the
configure and Makefiles.

Furthermore if build with multilib, the file
gcc/libphobos/libdruntime/config/systemz/get_tls_offset.S is used
for both configurations: systemz and s390.
Therefore both implementations are now in the systemz file which
uses an "#ifdef __s390x__" in order to distinguish both cases.
The s390 file is just including the systemz one.

libphobos/ChangeLog:

2019-11-27  Robin Dapp  
2020-04-01  Stefan Liebler  

* configure: Regenerate.
* libdruntime/Makefile.am: Add s390x and s390.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/s390/get_tls_offset.S: New file.
* libdruntime/config/systemz/get_tls_offset.S: New file.
* libdruntime/gcc/sections/elf_shared.d: Use __ibmz_get_tls_offset.
* m4/druntime/cpu.m4: Add s390x and s390.

diff --git a/libphobos/configure b/libphobos/configure
index 9cad270b2eb..04a6e6aeb0f 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -683,6 +683,10 @@ DRUNTIME_OS_AIX_FALSE
 DRUNTIME_OS_AIX_TRUE
 DRUNTIME_OS_UNIX_FALSE
 DRUNTIME_OS_UNIX_TRUE
+DRUNTIME_CPU_S390_FALSE
+DRUNTIME_CPU_S390_TRUE
+DRUNTIME_CPU_SYSTEMZ_FALSE
+DRUNTIME_CPU_SYSTEMZ_TRUE
 DRUNTIME_CPU_X86_FALSE
 DRUNTIME_CPU_X86_TRUE
 DRUNTIME_CPU_POWERPC64_FALSE
@@ -11644,7 +11648,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11647 "configure"
+#line 11651 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -11750,7 +11754,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 11753 "configure"
+#line 11757 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -14012,6 +14016,12 @@ fi
   i[34567]86|x86_64)
druntime_target_cpu_parsed="x86"
;;
+  s390x)
+   druntime_target_cpu_parsed="s390x"
+   ;;
+  s390)
+   druntime_target_cpu_parsed="s390"
+   ;;
   esac
if test "$druntime_target_cpu_parsed" = "aarch64"; then
   DRUNTIME_CPU_AARCH64_TRUE=
@@ -14061,6 +14071,22 @@ else
   DRUNTIME_CPU_X86_FALSE=
 fi
 
+   if test "$druntime_target_cpu_parsed" = "s390x"; then
+  DRUNTIME_CPU_SYSTEMZ_TRUE=
+  DRUNTIME_CPU_SYSTEMZ_FALSE='#'
+else
+  DRUNTIME_CPU_SYSTEMZ_TRUE='#'
+  DRUNTIME_CPU_SYSTEMZ_FALSE=
+fi
+
+   if test "$druntime_target_cpu_parsed" = "s390"; then
+  DRUNTIME_CPU_S390_TRUE=
+  DRUNTIME_CPU_S390_FALSE='#'
+else
+  DRUNTIME_CPU_S390_TRUE='#'
+  DRUNTIME_CPU_S390_FALSE=
+fi
+
 
 
   { $as_echo "$as_me:${as_lineno-$LINENO}: checking for target OS" >&5
@@ -15561,6 +15587,14 @@ if test -z "${DRUNTIME_CPU_X86_TRUE}" && test -z "${DRUNTIME_CPU_X86_FALSE}"; th
   as_fn_error $? "conditional \"DRUNTIME_CPU_X86\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
 fi
+if test -z "${DRUNTIME_CPU_SYSTEMZ_TRUE}" && test -z "${DRUNTIME_CPU_SYSTEMZ_FALSE}"; then
+  as_fn_error $? "conditional \"DRUNTIME_CPU_SYSTEMZ\" was never defined.
+Usually this means the macro was only invoked conditionally." "$LINENO" 5
+fi
+if test -z "${DRUNTIME_CPU_S390_TRUE}" && test -z "${DRUNTIME_CPU_S390_FALSE}"; then
+  as_fn_error $? "conditional \"DRUNTIME_CPU_S390\" was never defined.
+Usually this means the macro was only invoked conditionally." "$LINENO" 5
+fi
 if test -z "${DRUNTIME_OS_UNIX_TRUE}" && test -z "${DRUNTIME_OS_UNIX_FALSE}"; then
   as_fn_error $? "conditional \"DRUNTIME_OS_UNIX\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
diff --git a/libphobos/libdruntime/Makefile.am b/libphobos/libdruntime/Makefile.am
index ef18fb14d0e..b6f43299064 100644
--- a/libphobos/libdruntime/Makefile.am
+++ b/libphobos/libdruntime/Makefile.am
@@ -98,6 +98,12 @@ else
 D

Re: [PATCH v2 3/9] aarch64: Add cmp_*_carryinC patterns

[Richard Sandiford]

Richard Henderson  writes:
> On 3/31/20 11:34 AM, Richard Sandiford wrote:
>>> +(define_insn "*cmp3_carryinC"
>>> +  [(set (reg:CC CC_REGNUM)
>>> +   (compare:CC
>>> + (ANY_EXTEND:
>>> +   (match_operand:GPI 0 "register_operand" "r"))
>>> + (plus:
>>> +   (ANY_EXTEND:
>>> + (match_operand:GPI 1 "register_operand" "r"))
>>> +   (match_operand: 2 "aarch64_borrow_operation" ""]
>>> +   ""
>>> +   "sbcs\\tzr, %0, %1"
>>> +  [(set_attr "type" "adc_reg")]
>>> +)
>> 
>> I guess this feeds into your reply to Segher's comment for 7/9,
>> but I think:
>> 
>>(compare:CC X Y)
>> 
>> is always supposed to be the NZCV flags result of X - Y, as computed in
>> the mode of X and Y.  If so, it seems like the type of extension should
>> matter.  E.g. the N flag ought to be set for:
>> 
>>   (compare:CC
>> (sign_extend 0xf...)
>> (plus (sign_extend 0x7...)
>>   (ltu ...)))
>> 
>> but ought to be clear for:
>> 
>>   (compare:CC
>> (zero_extend 0xf...)
>> (plus (zero_extend 0x7...)
>>   (ltu ...)))
>> 
>> If so, I guess this is a bug in the existing code...
>
> The subject of CCmodes is a sticky one.  It mostly all depends on what combine
> is able to do with the patterns.
>
> For instance, your choice of example above, even for signed, the N bit cannot
> be examined by itself, because that would only be valid for a comparison
> against zero, like
>
> (compare (plus (reg) (reg))
>  (const_int 0))
>
> For this particular bit of rtl, the only valid comparison is N == V,
> i.e. GE/LT.
>
> If we add a new CC mode for this, what would you call it?  Probably not
> CC_NVmode, because to me that implies you can use either N or V, but it 
> doesn't
> imply you must examine both.
>
> If we add more CC modes, does that mean that we have to improve SELECT_CC_MODE
> to match those patterns?  Or do we add new CC modes just so that combine's use
> of SELECT_CC_MODE *cannot* match them?

Yeah, looks awkward.  There isn't AFAICT any way to describe the full
NZCV result of SBCS as a compare, in the case where C is possibly zero.
So I guess if we're going to continue using compare then we need to cook
up a new mode like you say.

How important is it to describe the flags operation as a compare though?
Could we instead use an unspec with three inputs, and keep it as :CC?
That would still allow special-case matching for zero operands.

Thanks,
Richard

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Martin Liška]

On 4/1/20 5:59 PM, Maciej W. Rozycki wrote:

On Wed, 1 Apr 2020, Martin Liška wrote:


I've just installed the patch.
@H.J. Can you please pull it to bintuils?


   Why didn't you use the commit as I published it


Because it didn't fit my script that takes changelog entries
and moves that to the corresponding ChangeLog files.
Next time, you will install the patch by your own.


  That was the intent: I asked for approval to commit, which is the usual
practice for people who have write access to the repo, and not to commit
on my behalf.


I've got it.




and also assumed
authorship of my change?  I feel insulted.


I removed myself from the ownership of the patch here:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d3ee88fdb4e0f718aaba050a3eb7174b8934a29d


  I don't think it has changed anything:

commit 142d68f50b48309f48e34fc1d9d6dbbeecfde684
Author: Martin Liska 
AuthorDate: Wed Apr 1 09:37:37 2020 +0200
Commit: Martin Liska 
CommitDate: Wed Apr 1 09:37:37 2020 +0200

You're still listed as the author of the change in question.


It's the first time anybody is asking me for that. I considered the ChangeLog
entry as sufficient. Anyway, next time please send a patch with git format-patch
so that one can apply it with git am. That will preserve you as the author.
Or ideally, feel free to fulfil copyright assignment and install commits
by your own.

Martin



   Maciej

Re: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++

[Richard Biener]

On Wed, 1 Apr 2020, Jan Hubicka wrote:

> > On Wed, 1 Apr 2020, Jakub Jelinek wrote:
> > 
> > > On Wed, Apr 01, 2020 at 03:36:30PM +0200, Richard Biener wrote:
> > > > @@ -512,7 +512,10 @@ can_inline_edge_by_limits_p (struct cgraph_edge 
> > > > *e, bool report,
> > > >   /* When devirtualization is disabled for callee, it is 
> > > > not safe
> > > >  to inline it as we possibly mangled the type info.
> > > >  Allow early inlining of always inlines.  */
> > > > - || (!early && check_maybe_down (flag_devirtualize)))
> > > > + || (!early && check_maybe_down (flag_devirtualize))
> > > > + /* It's not safe to inline a function where loops maybe
> > > > +infinite into a function where we assume the reverse.  
> > > > */
> > > > + || check_maybe_down (flag_finite_loops))
> > > > {
> > > >   e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
> > > >   inlinable = false;
> > > 
> > > Couldn't the above care only if the function has any loops?
> > > Otherwise, won't it prevent cross-language LTO inlining too much?
> > > Or instead of disabling inlining arrange for a safe flag_finite_loops 
> > > value
> > > for the resulting function (set some flag in cfun of the function that 
> > > would
> > > be considered together with flag_finite_loops (so that we don't have to
> > > create further OPTIMIZATION_NODEs) and disable finite loops opts if we've
> > > inlined !flag_finite_loops function into flag_finite_loops one)?
> > 
> > I guess I can split out this hunk from the patch - it's a separate
> > issue affecting also C++ with mixed option CUs.  Yes, ideally we'd
> > simply initialize loop->finite_p from flag_finite_loops at CFG
> > construction time and then only ever check the flag on the loop
> > structure.  That would leave us with infinite loops for loops
> > we only discover later though.  It also opens up the possibility
> > of a per-loop #pragma.
> 
> We do want to preserve cross-module inlining between C and C++, so we
> really should go with marking the loops pre-inline about finiteness and
> try to preserve the info, otherwise we are going to lose quite some
> optimizations.

OK, I'll update the patch accordingly.

Richard.

[PATCH] rs6000: Make code questionably using r2 not ICE (PR94420)

[Segher Boessenkool]

The example code in the PR uses r2 (the TOC register) directly.  In the
RTL generated for that, r2 is copied to some pseudo, and then cprop
propagates that into a "*tocref" insn, because nothing is
preventing it from doing that.

So, put the same condition in the insn condition for this as we will
later encounter in the constraint anyway, fixing this.

Tested on powerpc64-linux {-m32,-m64}.  Committed to master.


2020-04-01  Segher Boessenkool  

PR target/94420
* config/rs6000/rs6000.md (*tocref for P): Add insn condition
on operands[1].
---
 gcc/config/rs6000/rs6000.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index dcccb03..11ab745 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -10311,7 +10311,8 @@ (define_insn "*largetoc_low_aix"
 (define_insn_and_split "*tocref"
   [(set (match_operand:P 0 "gpc_reg_operand" "=b")
(match_operand:P 1 "small_toc_ref" "R"))]
-   "TARGET_TOC"
+   "TARGET_TOC
+&& legitimate_constant_pool_address_p (operands[1], QImode, false)"
"la %0,%a1"
"&& TARGET_CMODEL != CMODEL_SMALL && reload_completed"
   [(set (match_dup 0) (high:P (match_dup 1)))
-- 
1.8.3.1

Re: [Patch, fortran] PR93833 - [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

[Fritz Reese via Gcc-patches]

Unfortunately the mailing list stripped off this attachment so we do
not have a chance to review. As attachments appear to be working
lately, please resubmit this patch.

Fritz

On Sun, Mar 8, 2020 at 8:58 AM Paul Richard Thomas
 wrote:
>
> This is yet another case, where a deferred character length variable
> loses the character length backend_decl. As previously, converting the
> expression and using the string_length recovers it successfully.
>
> Regtested on FC31/x86_64 - OK for trunk, followed by 8- and 9-branches
> after a week or two?
>
> Paul
>
> 2020-03-08  Paul Thomas  
>
> PR fortran/93833
> * trans-array.c (get_array_ctor_var_strlen): If the character
> length backend_decl cannot be found, convert the expression and
> use the string length. Clear up some minor white space issues in
> the rest of the file.
>
> 2020-03-08  Paul Thomas  
>
> PR fortran/93833
> * gfortran.dg/deferred_character_36.f90 : New test.

Re: [PATCH] Fix an error in extend.texi

[Richard Sandiford]

Zackery Spytz via Gcc-patches  writes:
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index e0e7f540c219..f1f2064df459 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -2817,7 +2817,7 @@ the same type as the target function.  As a result of
> the @code{copy}
>  attribute the alias also shares the same attributes as the target.
>
>  @smallexample
> -#define StrongAlias(TagetFunc, AliasDecl)   \
> +#define StrongAlias(TargetFunc, AliasDecl)  \
>extern __typeof__ (TargetFunc) AliasDecl  \
>  __attribute__ ((alias (#TargetFunc), copy (TargetFunc)));

Thanks for the patch.  Pushed to master and gcc-9 branch.

Richard

Re: [PATCH v2 3/9] aarch64: Add cmp_*_carryinC patterns

[Richard Henderson via Gcc-patches]

On 4/1/20 9:28 AM, Richard Sandiford wrote:
> How important is it to describe the flags operation as a compare though?
> Could we instead use an unspec with three inputs, and keep it as :CC?
> That would still allow special-case matching for zero operands.

I'm not sure.

My guess is that the only interesting optimization for ADC/SBC is when
optimization determines that the low-part of op2 is zero, so that we can fold

  [(set (reg cc) (compare ...))
   (set (reg t0) (sub (reg a0) (reg b0))]

  [(set (reg cc) (compare ...))
   (set (reg t1) (sub (reg a1)
   (sub (reg b1)
 (geu (reg cc) (const 0)]

to

  [(set (reg t0) (reg a0)]

  [(set (reg cc) (compare ...))
   (set (reg t1) (sub (reg a1) (reg b1))]

which combine should be able to do by propagating zeros across the compare+geu.

Though I suppose it's still possible to handle this with unspecs and
define_split, so that

  [(set (reg cc)
(unspec [(reg a1) (reg b2) (geu ...)]
UNSPEC_SBCS)
   (set (reg t1) ...)]

when the geu folds to (const_int 0), we can split this to a plain sub.

I'll see if I can make this work with a minimum of effort.


r~

PING -- [PATCH, fortran] PR 85982 -- ICE in resolve_component

[Fritz Reese via Gcc-patches]

This simple patch was submitted some time ago (over 1 year), but got
lost without review. I have lately rebased and tested, and the patch
is still good. Is this OK to commit to trunk and for backport? I'd
like to port as far back as 7.

---
Fritz Reese

gcc/ChangeLog:
2020-04-01  Fritz Reese  

   PR fortran/85982
   * fortran/decl.c (match_attr_spec): Lump COMP_STRUCTURE/COMP_MAP into
   attribute checking used by TYPE.

gcc/testsuite/ChangeLog:
2020-04-01  Fritz Reese  

   PR fortran/85982
   * gfortran.dg/dec_structure_28.f90: New test.
commit 03ade661deaa606b005304814be9f723158ed55f
Author: Fritz Reese 
Date:   Fri Mar 20 13:03:42 2020 -0400

Fix for fortran/85982

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 2f458c4faac..05503b2d3c7 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -5408,15 +5408,18 @@ match_attr_spec (void)
   if (d == DECL_STATIC && seen[DECL_SAVE])
 	continue;
 
-  if (gfc_current_state () == COMP_DERIVED
+  if (gfc_comp_struct (gfc_current_state ())
 	  && d != DECL_DIMENSION && d != DECL_CODIMENSION
 	  && d != DECL_POINTER   && d != DECL_PRIVATE
 	  && d != DECL_PUBLIC && d != DECL_CONTIGUOUS && d != DECL_NONE)
 	{
+	  const char* const state_name = (gfc_current_state () == COMP_DERIVED
+	  ? "TYPE" : "STRUCTURE");
 	  if (d == DECL_ALLOCATABLE)
 	{
 	  if (!gfc_notify_std (GFC_STD_F2003, "ALLOCATABLE "
-   "attribute at %C in a TYPE definition"))
+   "attribute at %C in a %s definition",
+   state_name))
 		{
 		  m = MATCH_ERROR;
 		  goto cleanup;
@@ -5425,7 +5428,8 @@ match_attr_spec (void)
 	  else if (d == DECL_KIND)
 	{
 	  if (!gfc_notify_std (GFC_STD_F2003, "KIND "
-   "attribute at %C in a TYPE definition"))
+   "attribute at %C in a %s definition",
+   state_name))
 		{
 		  m = MATCH_ERROR;
 		  goto cleanup;
@@ -5449,7 +5453,8 @@ match_attr_spec (void)
 	  else if (d == DECL_LEN)
 	{
 	  if (!gfc_notify_std (GFC_STD_F2003, "LEN "
-   "attribute at %C in a TYPE definition"))
+   "attribute at %C in a %s definition",
+   state_name))
 		{
 		  m = MATCH_ERROR;
 		  goto cleanup;
@@ -5472,8 +5477,8 @@ match_attr_spec (void)
 	}
 	  else
 	{
-	  gfc_error ("Attribute at %L is not allowed in a TYPE definition",
-			 &seen_at[d]);
+	  gfc_error ("Attribute at %L is not allowed in a %s definition",
+			 &seen_at[d], state_name);
 	  m = MATCH_ERROR;
 	  goto cleanup;
 	}

[PATCH] doc: Fix typo

[Segher Boessenkool]

From: Joerg Sonnenberger 

I committed this patch for a typo spotted by Joerg Sonnenbecker:

2020-04-01  Joerg Sonnenberger  

* doc/extend.texi (Common Function Attributes): Fix typo.
---
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index f1f2064..bde3748 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2545,7 +2545,7 @@ __attribute__ ((access (read_write, 1), access 
(read_only, 2))) char* strcat (ch
 The @code{write_only} access mode applies to arguments of pointer types
 without the @code{const} qualifier.  It specifies that the pointer to which
 it applies is used to write to the referenced object but not read from it.
-The object refrenced by the pointer need not be initialized.  An example
+The object referenced by the pointer need not be initialized.  An example
 of the use of the @code{write_only} access mode is the first argument to
 the @code{strcpy} function, or the first two arguments to the @code{fgets}
 function.
-- 
1.8.3.1

Re: [PATCH] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Maciej W. Rozycki]

On Wed, 1 Apr 2020, Martin Liška wrote:

> > commit 142d68f50b48309f48e34fc1d9d6dbbeecfde684
> > Author: Martin Liska 
> > AuthorDate: Wed Apr 1 09:37:37 2020 +0200
> > Commit: Martin Liska 
> > CommitDate: Wed Apr 1 09:37:37 2020 +0200
> > 
> > You're still listed as the author of the change in question.
> 
> It's the first time anybody is asking me for that. I considered the ChangeLog
> entry as sufficient. Anyway, next time please send a patch with git
> format-patch
> so that one can apply it with git am. That will preserve you as the author.

 Of course it was formatted for `git am', I've been doing that for many 
years now for all the pieces of the toolchain (even with GCC while it was 
still on SVN).  Had you fed the message to `git am', it would have done 
the right thing.

> Or ideally, feel free to fulfil copyright assignment and install commits
> by your own.

 I've had it for some 20 years now for GCC and other pieces of the GNU
toolchain.  Otherwise I couldn't have been listed in MAINTAINERS.

 Why did you come up with an idea that I haven't?

  Maciej

issue with behavior change of gcc -r between gcc-8 and gcc-9

[Olivier Hainque]

Hello,

While working on the migration of our production
ports to gcc-9, we stumbled on a problem with the
behavioral changed introduced by

  commit 0b7fb27b698da38fd13108ecc914613f85f66f9d
  Author: Allan Sandfeld Jensen 
  Date:   Fri Sep 21 01:38:24 2018 +0600

Fix and document -r option

The option has existed and been working for years,
make sure it implies the right extra options, and list
it in the documentation.

The core of the change is summarized by:

* gcc.c (LINK_COMMAND_SPEC): Handle -r like -nostdlib.

The change is problematic for VxWorks. We initially thought we
could get around it, but our ideas unfortunately didn't work out.

VxWorks offers various ways to get executable code on a target,
one of which consists in downloading a so called "Downloadable Kernel
Module", essentially a partially linked blob, then letting the
runtime environment finalize the link and prepare the module to run.

Preparing the module to run involves running global constructors,
for c++ and eh table registration purposes in particular.

For this to work, we have sets of crtstuff startfiles and a variety
of inclusion policies.

The bottom line is that we really rely on the possibility to
have startfiles included as part of partial links, which the
change above forbids in a pretty irreversible manner (as far
as I can see).

I'm not entirely clear on the problem the change was trying
to solve.  IIUC, the essential goal was to remove the need to
pass particular options in addition to -r to remove bits
from a link closure.

Personally, I don't think that need was problematic. As
the commit log says, the option has existed and been working
for years.

-r 's business was to arrange for the linker not to
complain because the closure is incomplete, leaving us
with complete control of the closure.

It doesn't seem to me there was a really strong motivation
to suddenly have -r influence the closure the way it now does.

Would it be possible to revert to the previous behavior
and document it ?

Or maybe allow it to be controllable by the target ports ?

Or provide something to bring back the flexibility we had
if we really believe the default should change ? (I'm not
convinced)

Thanks in advance for your feedback!

With Kind Regards,

Olivier

Re: [PATCH] lower-subreg: PR94123, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail

[Peter Bergner via Gcc-patches]

On 3/30/20 3:50 AM, Richard Sandiford wrote:
> Peter Bergner via Gcc-patches  writes:
>>  * lower-subreg.c (pass_lower_subreg3::gate): Remove test for
>>  flag_split_wide_types_early.
>>
>> diff --git a/gcc/lower-subreg.c b/gcc/lower-subreg.c
>> index 4c8bc835f93..807ad398b64 100644
>> --- a/gcc/lower-subreg.c
>> +++ b/gcc/lower-subreg.c
>> @@ -1844,8 +1844,7 @@ public:
>>{}
>>  
>>/* opt_pass methods: */
>> -  virtual bool gate (function *) { return flag_split_wide_types
>> -  && !flag_split_wide_types_early; }
>> +  virtual bool gate (function *) { return flag_split_wide_types != 0; }
>>virtual unsigned int execute (function *)
>>  {
>>decompose_multiword_subregs (true);
> 
> Looks good to me with the s/ != 0// that Segher mentioned.
> 
> With this change, the only remaining function of -fsplit-wide-types-early
> is to act as a double lock on one pass.  IMO it'd make more sense to remove
> that double lock and make -fsplit-wide-types-early and -fsplit-wide-types
> act as independent options, a bit like -fschedule-insns{,2}.

Have we come to consensus on whether to split the options or not?
I think Segher is against it given we actually have 3 passes of
lower-subreg and -fsplit-wide-types would control the 1st and 3rd
passes and -fsplit-wide-types-early would control the second.
That does seem strange to me too.

Peter

Re: PING -- [PATCH, fortran] PR 85982 -- ICE in resolve_component

[Fritz Reese via Gcc-patches]

On Wed, Apr 1, 2020 at 1:19 PM Fritz Reese  wrote:
[...]
> is still good. Is this OK to commit to trunk and for backport? I'd
> like to port as far back as 7.

I realized 7 branch is closed. I would backport to 8.

> gcc/testsuite/ChangeLog:
> 2020-04-01  Fritz Reese  
>
>PR fortran/85982
>* gfortran.dg/dec_structure_28.f90: New test.

Forgot to include the testcase in the patch. Testcase is attached.
! { dg-do compile }
! { dg-options "-fdec-structure -fdec-static" }
!
! PR fortran/85982
!
! Test a regression wherein some component attributes were erroneously accepted
! within a DEC structure.
!

structure /s/
  integer :: a
  integer, intent(in) :: b ! { dg-error "is not allowed" }
  integer, intent(out) :: c ! { dg-error "is not allowed" }
  integer, intent(inout) :: d ! { dg-error "is not allowed" }
  integer, dimension(1,1) :: e ! OK
  integer, external, pointer :: f ! { dg-error "is not allowed" }
  integer, intrinsic :: f ! { dg-error "is not allowed" }
  integer, optional :: g ! { dg-error "is not allowed" }
  integer, parameter :: h ! { dg-error "is not allowed" }
  integer, protected :: i ! { dg-error "is not allowed" }
  integer, private :: j ! { dg-error "is not allowed" }
  integer, static :: k ! { dg-error "is not allowed" }
  integer, automatic :: l ! { dg-error "is not allowed" }
  integer, public :: m ! { dg-error "is not allowed" }
  integer, save :: n ! { dg-error "is not allowed" }
  integer, target :: o ! { dg-error "is not allowed" }
  integer, value :: p ! { dg-error "is not allowed" }
  integer, volatile :: q ! { dg-error "is not allowed" }
  integer, bind(c) :: r ! { dg-error "is not allowed" }
  integer, asynchronous :: t ! { dg-error "is not allowed" }
  character(len=3) :: v ! OK
  integer(kind=4) :: w ! OK
end structure

end

Re: [PATCH] lower-subreg: PR94123, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail

[Richard Sandiford]

Peter Bergner  writes:
> On 3/30/20 3:50 AM, Richard Sandiford wrote:
>> Peter Bergner via Gcc-patches  writes:
>>> * lower-subreg.c (pass_lower_subreg3::gate): Remove test for
>>> flag_split_wide_types_early.
>>>
>>> diff --git a/gcc/lower-subreg.c b/gcc/lower-subreg.c
>>> index 4c8bc835f93..807ad398b64 100644
>>> --- a/gcc/lower-subreg.c
>>> +++ b/gcc/lower-subreg.c
>>> @@ -1844,8 +1844,7 @@ public:
>>>{}
>>>  
>>>/* opt_pass methods: */
>>> -  virtual bool gate (function *) { return flag_split_wide_types
>>> - && !flag_split_wide_types_early; }
>>> +  virtual bool gate (function *) { return flag_split_wide_types != 0; }
>>>virtual unsigned int execute (function *)
>>>  {
>>>decompose_multiword_subregs (true);
>> 
>> Looks good to me with the s/ != 0// that Segher mentioned.
>> 
>> With this change, the only remaining function of -fsplit-wide-types-early
>> is to act as a double lock on one pass.  IMO it'd make more sense to remove
>> that double lock and make -fsplit-wide-types-early and -fsplit-wide-types
>> act as independent options, a bit like -fschedule-insns{,2}.
>
> Have we come to consensus on whether to split the options or not?
> I think Segher is against it given we actually have 3 passes of
> lower-subreg and -fsplit-wide-types would control the 1st and 3rd
> passes and -fsplit-wide-types-early would control the second.
> That does seem strange to me too.

I guess the name of the option is a bit weird, since it'll control
the middle pass of three.  That's going to be true either way though.

We're talking about having independent options controlling independent
passes, which seems like a Good Thing in general and doesn't seem that
strange to me in this case.  But I'm certainly happy to yield given the
strong opinions the other way.

Thanks,
Richard

linkage of lambda types

[Nathan Sidwell]

Jason,

This is from pr94426, which is fallout from my pr94147 fix.

You added the following to no_linkage_check as part of

 2018-11-12  Jason Merrill  
Implement P0315R4, Lambdas in unevaluated contexts.

  /* Lambda types that don't have mangling scope have no linkage.  We
 check CLASSTYPE_LAMBDA_EXPR for error_mark_node because
 when we get here from pushtag none of the lambda information is
 set up yet, so we want to assume that the lambda has linkage and
 fix it up later if not.  We need to check this even in templates so
 that we properly handle a lambda-expression in the signature.  */
  if (LAMBDA_TYPE_P (t)
  && CLASSTYPE_LAMBDA_EXPR (t) != error_mark_node
  && LAMBDA_TYPE_EXTRA_SCOPE (t) == NULL_TREE)
return t;

The comment suggests that those with a mangling scope do (sometimes?) 
have linkage.  Under what circumstances does the std give lambdas 
linkage?  They are 'unique, unnamed non-union class type[s]' 7.5.5.1/1


The wording in 6.3/14 suggests that even in:
   inline auto var = []{};
the multiple definitions of 'var' in different TUs could have different 
types.


'In particular, lambda-expressions (7.5.5) appearing in the type of D 
may result in the different declarations having distinct types,'


so they can be ODR-same, but not TYPE-same.  Comparing 'typeid (var)' 
acrosss TU boundaries gives an unspecified result.


I can see why implementationwise we might want the above to have a 
pseudo-external linkage -- IIRC we don't correctly give templates 
instantiated from non-external types internal linkage, so we have to 
either guarantee unique mangling or guarantee same typeness.


What am I missing?

nathan

--
Nathan Sidwell

Re: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++

[Jason Merrill via Gcc-patches]

On 4/1/20 9:36 AM, Richard Biener wrote:

This does away with enabling -ffinite-loops at -O2+ for all languages
and instead enables it selectively for C++ only.

Jason, I didn't find a reference as to when the forward progress
guarantee was introduced to C++ so I randomly chose C++11, is that
correct?


C++11 says "Implementations should ensure that all unblocked threads 
eventually make progress."


C++17 adds the "Forward progress" section that says

"The implementation may assume that any thread will eventually do one of 
the following:

 — terminate,
 — make a call to a library I/O function,
 — perform an access through a volatile glvalue, or
 — perform a synchronization operation or an atomic operation.
[Note: This is intended to allow compiler transformations such as 
removal of empty loops, even when termination cannot be proven. — end note]"


Jason

Re: [PATCH], Make PowerPC -mcpu=future enable -mpcrel on linux ELFv2

[Michael Meissner via Gcc-patches]

On Mon, Mar 30, 2020 at 05:51:49PM -0500, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Mar 30, 2020 at 12:50:43PM -0500, will schmidt wrote:
> > On Fri, 2020-03-27 at 21:31 -0400, Michael Meissner via Gcc-patches
> > >   * config/rs6000/rs6000.c (PCREL_SUPPORTED_BY_OS): New macro.
> > >   (rs6000_option_override_internal): Set the -mprefixed and
> > > -mpcrel
> > >   options for -mcpu=future if these options can be used.
> > > 
> > s/can be used/are supported by the platform/ ? 
> 
> The code says
>   /* Enable -mprefixed by default on 64-bit 'future' systems.  */
>   /* If the OS has support for PC-relative relocations, enable it now.  */
> and something like that should go in the changelog as well (two lines in
> changelog is fine -- they are two hunks of patch as well, anyway!)

Ok.

> > > +/* Enable default support for PC-relative addressing on the 'future'
> > > system if
> > > +   we can use the PC-relative instructions.  Currently this support
> > > only exits
> > 
> > exists
> > 
> > > +   for the ELF v2 object file format using the medium code
> > > model.  */
> > 
> > should that be "s/object file format/ABI/" ? 
> 
> Yes.

Ok.

> > > -/* Support for a future processor's features.  Do not enable -mpcrel
> > > until it
> > > -   is fully functional.  */
> > > +/* Support for a future processor's features.  We do not set -mpcrel
> > > or
> > > +   -mprefixed here.  These bits are set in rs6000_option_override if
> > > the system
> > > +   supports those options. */
> > 
> > I'm still not sure the comment here is actually necessary, there are
> > many other places where we also do not set -mpcrel or -mprefixed.  If
> > history of the code here requires a hint to point at those options
> > being set in rs6000_option_override, then it's fine.
> 
> If you really need to say you do *not* do something, you should say why
> not.  Without that it only leaves more questions to the reader :-)
> 
> Hopefully that then also explains why the reader should care about this.

Given this comment is against Will's comment, and not the original code, is
there anything I need to do to the code (other than the ChangeLog and adjusting
object file format to ABI?

-- 
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

[committed] analyzer: handle compound assignments [PR94378]

[David Malcolm via Gcc-patches]

PR analyzer/94378 reports a false -Wanalyzer-malloc-leak
when returning a struct containing a malloc-ed pointer.

The issue is that the assignment code was not handling
compound copies, only copying top-level values from region to region,
and not copying child values.

This patch introduces a region_model::copy_region function, using
it for assignments and when analyzing function return values.
It recursively copies nested values within structs, unions, and
arrays, fixing the bug.

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

gcc/analyzer/ChangeLog:
PR analyzer/94378
* checker-path.cc: Include "bitmap.h".
* constraint-manager.cc: Likewise.
* diagnostic-manager.cc: Likewise.
* engine.cc: Likewise.
(exploded_node::detect_leaks): Pass null region_id to pop_frame.
* program-point.cc: Include "bitmap.h".
* program-state.cc: Likewise.
* region-model.cc (id_set::id_set): Convert to...
(region_id_set::region_id_set): ...this.
(svalue_id_set::svalue_id_set): New ctor.
(region_model::copy_region): New function.
(region_model::copy_struct_region): New function.
(region_model::copy_union_region): New function.
(region_model::copy_array_region): New function.
(stack_region::pop_frame): Drop return value.  Add
"result_dst_rid" param; if it is non-null, use copy_region to copy
the result to it.  Rather than capture and pass a single "known
used" return value to be used by purge_unused_values, instead
gather and pass a set of known used return values.
(root_region::pop_frame): Drop return value.  Add "result_dst_rid"
param.
(region_model::on_assignment): Use copy_region.
(region_model::on_return): Likewise for the result.
(region_model::on_longjmp): Pass null for pop_frame's
result_dst_rid.
(region_model::update_for_return_superedge): Pass the region for the
return value of the call, if any, to pop_frame, rather than setting
the lvalue for the lhs of the result.
(region_model::pop_frame): Drop return value.  Add
"result_dst_rid" param.
(region_model::purge_unused_svalues): Convert third param from an
svalue_id * to an svalue_id_set *, updating the initial populating
of the "used" bitmap accordingly.  Don't remap it when done.
(struct selftest::coord_test): New selftest fixture, extracted from...
(selftest::test_dump_2): ...here.
(selftest::test_compound_assignment): New selftest.
(selftest::test_stack_frames): Pass null to new param of pop_frame.
(selftest::analyzer_region_model_cc_tests): Call the new selftest.
* region-model.h (class id_set): Delete template.
(class region_id_set): Reimplement, using old id_set implementation.
(class svalue_id_set): Likewise.  Convert from auto_sbitmap to
auto_bitmap.
(region::get_active_view): New accessor.
(stack_region::pop_frame): Drop return value.  Add
"result_dst_rid" param.
(root_region::pop_frame): Likewise.
(region_model::pop_frame): Likewise.
(region_model::copy_region): New decl.
(region_model::purge_unused_svalues): Convert third param from an
svalue_id * to an svalue_id_set *.
(region_model::copy_struct_region): New decl.
(region_model::copy_union_region): New decl.
(region_model::copy_array_region): New decl.

gcc/testsuite/ChangeLog:
PR analyzer/94378
* gcc.dg/analyzer/compound-assignment-1.c: New test.
* gcc.dg/analyzer/compound-assignment-2.c: New test.
* gcc.dg/analyzer/compound-assignment-3.c: New test.
---
 gcc/analyzer/checker-path.cc  |   1 +
 gcc/analyzer/constraint-manager.cc|   1 +
 gcc/analyzer/diagnostic-manager.cc|   1 +
 gcc/analyzer/engine.cc|   4 +-
 gcc/analyzer/program-point.cc |   1 +
 gcc/analyzer/program-state.cc |   1 +
 gcc/analyzer/region-model.cc  | 342 ++
 gcc/analyzer/region-model.h   |  71 +++-
 .../gcc.dg/analyzer/compound-assignment-1.c   |  71 
 .../gcc.dg/analyzer/compound-assignment-2.c   |  24 ++
 .../gcc.dg/analyzer/compound-assignment-3.c   |  25 ++
 11 files changed, 458 insertions(+), 84 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/compound-assignment-1.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/compound-assignment-2.c
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/compound-assignment-3.c

diff --git a/gcc/analyzer/checker-path.cc b/gcc/analyzer/checker-path.cc
index c781cd8dbeb..c07273460d5 100644
--- a/gcc/analyzer/checker-path.cc
+++ b/gcc/analyzer/checker-path.cc
@@ -42,6 +42,7 @@ along with GCC; see the file C

Re: [PATCH] lower-subreg: PR94123, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail

[Peter Bergner via Gcc-patches]

On 4/1/20 1:32 PM, Richard Sandiford wrote:
> Peter Bergner  writes:
>> Have we come to consensus on whether to split the options or not?
>> I think Segher is against it given we actually have 3 passes of
>> lower-subreg and -fsplit-wide-types would control the 1st and 3rd
>> passes and -fsplit-wide-types-early would control the second.
>> That does seem strange to me too.
> 
> I guess the name of the option is a bit weird, since it'll control
> the middle pass of three.  That's going to be true either way though.
> 
> We're talking about having independent options controlling independent
> passes, which seems like a Good Thing in general and doesn't seem that
> strange to me in this case.  But I'm certainly happy to yield given the
> strong opinions the other way.

Ok, I pushed the patch without breaking them apart.  We can maybe revisit
the issue in stage1, when I'll start testing the first patch that allows
hard registers to be decomposed.

Thanks!

Peter

Re: issue with behavior change of gcc -r between gcc-8 and gcc-9

[Olivier Hainque]

Hello again,

> On 01 Apr 2020, at 19:48, Olivier Hainque  wrote:
> 
>* gcc.c (LINK_COMMAND_SPEC): Handle -r like -nostdlib.
> 
> Would it be possible to revert to the previous behavior
> and document it ?
> 
> Or maybe allow it to be controllable by the target ports ?
> 
> Or provide something to bring back the flexibility we had
> if we really believe the default should change ? (I'm not
> convinced)

I realize we could resort to -Wl,-r instead and I was
convinced there are contexts where we don't have the opportunity
to control the arguments as freely as we'd like, which
would actually restrict our adjustment options.

I can triple check on that.

Olivier

[PATCH] deferred-shape vs assumed-shape

[Steve Kargl via Gcc-patches]

See 
https://stackoverflow.com/questions/60972134/whats-wrong-with-the-following-fortran-code-gfortran-dtio-dummy-argument-at

Is A(:) a deferred-shape array or an assumed-shape array?  The
answer of course depends on context.

This patch fixes the issue found at the above URL.

Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 280157)
+++ gcc/fortran/interface.c (working copy)
@@ -4916,10 +4916,15 @@ check_dtio_arg_TKR_intent (gfc_symbol *fsym, bool type
  || ((type != BT_CLASS) && fsym->attr.dimension)))
 gfc_error ("DTIO dummy argument at %L must be a scalar",
   &fsym->declared_at);
-  else if (rank == 1
-  && (fsym->as == NULL || fsym->as->type != AS_ASSUMED_SHAPE))
-gfc_error ("DTIO dummy argument at %L must be an "
-  "ASSUMED SHAPE ARRAY", &fsym->declared_at);
+  else if (rank == 1)
+{
+  if (fsym->as == NULL
+ || !(fsym->as->type == AS_ASSUMED_SHAPE
+   || (fsym->as->type == AS_DEFERRED && fsym->attr.dummy
+   && !fsym->attr.allocatable && !fsym->attr.pointer)))
+   gfc_error ("DTIO dummy argument at %L must be an "
+  "ASSUMED-SHAPE ARRAY", &fsym->declared_at);
+}
 
   if (type == BT_CHARACTER && fsym->ts.u.cl->length != NULL)
 gfc_error ("DTIO character argument at %L must have assumed length",

-- 
Steve

[PATCH] doc: RISC-V: Update binutils requirement to 2.30

[Maciej W. Rozycki via Gcc-patches]

Complement commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather 
than fmv.x.s/fmv.s.x") and document a binutils 2.30 requirement in the 
installation manual, matching the addition of fmv.x.w/fmv.w.x mnemonics 
to GAS.

gcc/
* doc/install.texi (Specific) 
: Update binutils requirement to 
2.30.
---
On Wed, 18 Mar 2020, Maciej W. Rozycki wrote:

> > >  At the very least I think we ought to document the minimum version of
> > > binutils now required by GCC for RISC-V support.
> > 
> > The new opcodes were added to gas in 2017-09-27, and I can't recommend
> > using any binutils or gcc release that predates 2018-01-01 because
> > they are all known to be buggy, or incompatible with the current ISA
> > definition.  So I don't see any need for a configure test for this
> > change.  Anyone missing the new instructions in gas has bigger
> > problems to worry about.
[...]
>  Our installation instructions state binutils 2.28 as the requirement for 
> all the RISC-V targets, however the change for fmv.x.w/fmv.w.x instruction 
> support was only added in the binutils 2.30 development cycle.

 Here's the resulting change.  Verified with `make info' and `make check'.
OK to apply?

  Maciej
---
 gcc/doc/install.texi |   12 
 1 file changed, 4 insertions(+), 8 deletions(-)

gcc-riscv-binutils-version.diff
Index: gcc/gcc/doc/install.texi
===
--- gcc.orig/gcc/doc/install.texi
+++ gcc/gcc/doc/install.texi
@@ -4545,8 +4545,7 @@ This configuration is intended for embed
 @heading riscv32-*-elf
 The RISC-V RV32 instruction set.
 This configuration is intended for embedded systems.
-This (and all other RISC-V) targets are supported upstream as of the
-binutils 2.28 release.
+This (and all other RISC-V) targets require the binutils 2.30 release.
 
 @html
 
@@ -4554,8 +4553,7 @@ binutils 2.28 release.
 @anchor{riscv32-x-linux}
 @heading riscv32-*-linux
 The RISC-V RV32 instruction set running GNU/Linux.
-This (and all other RISC-V) targets are supported upstream as of the
-binutils 2.28 release.
+This (and all other RISC-V) targets require the binutils 2.30 release.
 
 @html
 
@@ -4564,8 +4562,7 @@ binutils 2.28 release.
 @heading riscv64-*-elf
 The RISC-V RV64 instruction set.
 This configuration is intended for embedded systems.
-This (and all other RISC-V) targets are supported upstream as of the
-binutils 2.28 release.
+This (and all other RISC-V) targets require the binutils 2.30 release.
 
 @html
 
@@ -4573,8 +4570,7 @@ binutils 2.28 release.
 @anchor{riscv64-x-linux}
 @heading riscv64-*-linux
 The RISC-V RV64 instruction set running GNU/Linux.
-This (and all other RISC-V) targets are supported upstream as of the
-binutils 2.28 release.
+This (and all other RISC-V) targets require the binutils 2.30 release.
 
 @html
 

Re: rs6000 - allow builtin initialization regardless of mask

[Segher Boessenkool]

On Wed, Apr 01, 2020 at 09:20:31AM -0500, will schmidt wrote:
> On Thu, 2020-03-26 at 14:23 -0500, Segher Boessenkool wrote:
> > On Mon, Mar 23, 2020 at 03:18:25PM -0500, will schmidt wrote:
> > >   Disable the code that limits initialization of builtins based
> > > on the rs6000_builtin_mask.  This allows all built-ins to be
> > > properly referenced when building code using #pragma for cpu
> > > targets newer than what was specified by the -mcpu default.
> > > The use of built-ins is still properly limited by logic within
> > > altivec_resolve_overloaded_builtin().
> > > 
> > > I'm still reviewing test results for any regressions.
> > > 
> > > OK for master?
> > 
> > Okay (if those tests pass ;-) ), thanks!  Just a few nits:
> 
> They did.  :-)  I committed this on Monday.
> 
> Is this one also OK for backports?   (after a week or so to let it bake
> a bit more). 

Sure, thanks!


Segher

Re: issue with behavior change of gcc -r between gcc-8 and gcc-9

[Iain Sandoe]

Olivier Hainque  wrote:


Hello again,


On 01 Apr 2020, at 19:48, Olivier Hainque  wrote:

  * gcc.c (LINK_COMMAND_SPEC): Handle -r like -nostdlib.

Would it be possible to revert to the previous behavior
and document it ?

Or maybe allow it to be controllable by the target ports ?


perhaps I’m missing something here, but it is quite possible for a target
to override and provide a customised version of LINK_COMMAND_SPEC.

Darwin does this: see config/darwin.h

So, AFAIU, a port owner has the last call on how such things are handled
since the port header is typically included after the generic ones.


Or provide something to bring back the flexibility we had
if we really believe the default should change ? (I'm not
convinced)


I realize we could resort to -Wl,-r instead and I was
convinced there are contexts where we don't have the opportunity
to control the arguments as freely as we'd like, which
would actually restrict our adjustment options.



cheers
Iain

[committed] libstdc++: Move "free books" list from fsf.org to gnu.org

[Gerald Pfeifer]

The fsf.org server now has a redirect to the gnu.org server; let's
follow that.

This is my first commit to libstdc++ using git, my first squashing
(since I had a follow tweak to the ChangeLog), and my first --amend.

Please advise if I can/should do something better.

Thank you,
Gerald


* doc/xml/manual/appendix_free.xml: Move "free books" list from
fsf.org to gnu.org.
* doc/html/manual/appendix_free.html: Regenerate.
---
 libstdc++-v3/ChangeLog  | 6 ++
 libstdc++-v3/doc/html/manual/appendix_free.html | 2 +-
 libstdc++-v3/doc/xml/manual/appendix_free.xml   | 2 +-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index beaf61b9d2b..ed2c4b77ac1 100644
--- a/libstdc++-v3/ChangeLog
+++ b/libstdc++-v3/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-01  Gerald Pfeifer  
+
+   * doc/xml/manual/appendix_free.xml: Move "free books" list from
+   fsf.org to gnu.org.
+   * doc/html/manual/appendix_free.html: Regenerate.
+
 2020-03-31  Ville Voutilainen  
 
Library-side tests for parenthesized aggregate init
diff --git a/libstdc++-v3/doc/html/manual/appendix_free.html 
b/libstdc++-v3/doc/html/manual/appendix_free.html
index b10283f78a2..9493373e9ef 100644
--- a/libstdc++-v3/doc/html/manual/appendix_free.html
+++ b/libstdc++-v3/doc/html/manual/appendix_free.html
@@ -116,7 +116,7 @@ manuals instead of proprietary ones.  One way you can help 
this is to
 check the distribution terms of a manual before you buy it, and
 prefer copylefted manuals to non-copylefted ones.
 
-[Note: We now maintain a https://www.fsf.org/licensing/doc/other-free-books.html"; 
target="_top">web page
+[Note: We now maintain a https://www.gnu.org/doc/other-free-books.html"; target="_top">web page
 that lists free books available from other publishers].
 Copyright ?? 2004, 2005, 2006, 2007 Free Software Foundation, Inc., 51 
Franklin Street, Fifth Floor, Boston, MA 02110-1301, USAVerbatim copying 
and distribution of this entire article are
 permitted worldwide, without royalty, in any medium, provided this
diff --git a/libstdc++-v3/doc/xml/manual/appendix_free.xml 
b/libstdc++-v3/doc/xml/manual/appendix_free.xml
index 7d682bbe039..dd51eae8afc 100644
--- a/libstdc++-v3/doc/xml/manual/appendix_free.xml
+++ b/libstdc++-v3/doc/xml/manual/appendix_free.xml
@@ -159,7 +159,7 @@ check the distribution terms of a manual before you buy it, 
and
 prefer copylefted manuals to non-copylefted ones.
 
 
-[Note: We now maintain a http://www.w3.org/1999/xlink"; 
xlink:href="https://www.fsf.org/licensing/doc/other-free-books.html";>web page
+[Note: We now maintain a http://www.w3.org/1999/xlink"; 
xlink:href="https://www.gnu.org/doc/other-free-books.html";>web page
 that lists free books available from other publishers].
 
 
-- 
2.26.0

Re: issue with behavior change of gcc -r between gcc-8 and gcc-9

[Olivier Hainque]

Hello Iain,

> On 1 Apr 2020, at 22:42, Iain Sandoe  wrote:
> 
> perhaps I’m missing something here, but it is quite possible for a target
> to override and provide a customised version of LINK_COMMAND_SPEC.
> 
> Darwin does this: see config/darwin.h
> 
> So, AFAIU, a port owner has the last call on how such things are handled
> since the port header is typically included after the generic ones.

Sure. I was hoping we could avoid that and maybe have a more
specialized control on just that aspect that has changed.

There are quite a few things in the default LINK_COMMAND_SPEC and
I thought we'd better not start replicating all that logic for just
that tiny bit which I wasn't 100% convinced really needed to change.

Olivier

[PATCH] aarch64: Fix ICE due to aarch64_gen_compare_reg_maybe_ze [PR94435]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase ICEs, because aarch64_gen_compare_reg_maybe_ze emits
invalid RTL.
For y_mode [QH]Imode it expects y to be of that mode (or CONST_INT that fits
into that mode) and x being SImode; for non-CONST_INT y it zero extends y
into SImode and compares that against x, for CONST_INT y it zero extends y
into SImode.  The problem is that when the zero extended constant isn't
usable directly, it forces it into a REG, but with y_mode mode, and then
compares against y.  That is wrong, because it should force it into a SImode
REG and compare that way.

The following patch fixes that, bootstrapped/regtested on aarch64-linux, ok
for trunk?

2020-04-01  Jakub Jelinek  

PR target/94435
* config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): For
y_mode E_[QH]Imode and y being a CONST_INT, change y_mode to SImode.

* gcc.target/aarch64/pr94435.c: New test.

--- gcc/config/aarch64/aarch64.c.jj 2020-03-30 17:02:28.0 +0200
+++ gcc/config/aarch64/aarch64.c2020-04-01 11:32:48.877900235 +0200
@@ -2371,7 +2371,10 @@ aarch64_gen_compare_reg_maybe_ze (RTX_CO
   if (y_mode == E_QImode || y_mode == E_HImode)
 {
   if (CONST_INT_P (y))
-   y = GEN_INT (INTVAL (y) & GET_MODE_MASK (y_mode));
+   {
+ y = GEN_INT (INTVAL (y) & GET_MODE_MASK (y_mode));
+ y_mode = SImode;
+   }
   else
{
  rtx t, cc_reg;
--- gcc/testsuite/gcc.target/aarch64/pr94435.c.jj   2020-04-01 
11:36:21.172797217 +0200
+++ gcc/testsuite/gcc.target/aarch64/pr94435.c  2020-04-01 11:36:36.493573280 
+0200
@@ -0,0 +1,25 @@
+/* PR target/94435 */
+/* { dg-do compile } */
+/* { dg-options "-march=armv8-a+nolse -moutline-atomics" } */
+
+int b, c, d, e, f, h;
+short g;
+int foo (int) __attribute__ ((__const__));
+
+void
+bar (void)
+{
+  while (1)
+{
+  while (1)
+   {
+ __atomic_load_n (&e, 0);
+ if (foo (2))
+   __sync_val_compare_and_swap (&c, 0, f);
+ b = 1;
+ if (h == e)
+   break;
+   }
+  __sync_val_compare_and_swap (&g, -1, f);
+}
+}

Jakub

[committed] d: Fix gdc.dg/pr92216.d FAILs on 32-bit targets

[Iain Buclaw via Gcc-patches]

Hi,

This patch fixes the test for PR92216 to also succeed on 16 and 32-bit
targets.  The symbol being scanned for only matched on 64-bit targets
where the this pointer offset is 16.

Tested on x86_64-linux-gnu with -m32 and -mx32.  Also checked avr-gcc
for what output comes from a 16-bit compiler.

Committed to mainline.

Regards
Iain.
---

gcc/testsuite/ChangeLog:

PR d/94321
* gdc.dg/pr92216.d: Update to work on targets with 16 or 32-bit
pointers.

---
 gcc/testsuite/gdc.dg/pr92216.d | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gdc.dg/pr92216.d b/gcc/testsuite/gdc.dg/pr92216.d
index 330604c9c89..6a87025a7d0 100644
--- a/gcc/testsuite/gdc.dg/pr92216.d
+++ b/gcc/testsuite/gdc.dg/pr92216.d
@@ -1,8 +1,8 @@
 // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92216
 // { dg-options "-I $srcdir/gdc.dg" }
 // { dg-do compile }
-// { dg-final { scan-assembler 
"_DT16_D7imports7pr922161B8__mixin24getSMFZPv\[: \t\n\]" } }
-// { dg-final { scan-assembler-not "(.globl|.global)\[ 
\]+_DT16_D7imports7pr922161B8__mixin24getSMFZPv" } }
+// { dg-final { scan-assembler 
"_DT(4|8|16)_D7imports7pr922161B8__mixin24getSMFZPv\[: \t\n\]" } }
+// { dg-final { scan-assembler-not "(.globl|.global)\[ 
\]+_DT(4|8|16)_D7imports7pr922161B8__mixin24getSMFZPv" } }
 module pr92216;
 
 private import imports.pr92216;
-- 
2.20.1

Re: [PATCH], Make PowerPC -mcpu=future enable -mpcrel on linux ELFv2

[Segher Boessenkool]

On Wed, Apr 01, 2020 at 03:16:52PM -0400, Michael Meissner wrote:
> > > > -/* Support for a future processor's features.  Do not enable -mpcrel
> > > > until it
> > > > -   is fully functional.  */
> > > > +/* Support for a future processor's features.  We do not set -mpcrel
> > > > or
> > > > +   -mprefixed here.  These bits are set in rs6000_option_override if
> > > > the system
> > > > +   supports those options. */
> > > 
> > > I'm still not sure the comment here is actually necessary, there are
> > > many other places where we also do not set -mpcrel or -mprefixed.  If
> > > history of the code here requires a hint to point at those options
> > > being set in rs6000_option_override, then it's fine.
> > 
> > If you really need to say you do *not* do something, you should say why
> > not.  Without that it only leaves more questions to the reader :-)
> > 
> > Hopefully that then also explains why the reader should care about this.
> 
> Given this comment is against Will's comment, and not the original code, is
> there anything I need to do to the code (other than the ChangeLog and 
> adjusting
> object file format to ABI?

I am agreeing with Will's comment here, just expanding on it.  This
comment isn't helpful (maybe it would be with more provided context,
but as it is, it is not).


Segher

[committed] d: Fix new tests gdc.dg/pr93038.d and gdc.dg/pr93038b.d in r10-7320 fail

[Iain Buclaw via Gcc-patches]

Hi,

This patch adjusts another test in gdc.dg that was reported to be
failing in PR94315.

The scan-file match is likely too strict to always succeed, so instead
have split it up into a set of smaller matches.

Tested on x86_64-linux-gnu and committed to mainline.

Regards
Iain. 
---

gcc/testsuite/ChangeLog:

PR d/94315
* gdc.dg/pr93038.d: Split dg-final into multiple tests.
* gdc.dg/pr93038b.d: Likewise.

---
 gcc/testsuite/gdc.dg/pr93038.d  | 4 +++-
 gcc/testsuite/gdc.dg/pr93038b.d | 5 -
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gdc.dg/pr93038.d b/gcc/testsuite/gdc.dg/pr93038.d
index 4e09690a473..79d30a85380 100644
--- a/gcc/testsuite/gdc.dg/pr93038.d
+++ b/gcc/testsuite/gdc.dg/pr93038.d
@@ -1,7 +1,9 @@
 // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93038
 // { dg-options "-J $srcdir/gdc.dg/fileimports -MMD" }
 // { dg-do compile }
-// { dg-final { scan-file pr93038.deps "pr93038.o: \[^\n\]*/pr93038.d \[ 
\n\]*\[^\n\]*/fileimports/pr93038.txt" } }
+// { dg-final { scan-file pr93038.deps "(^|\\n)pr93038.o:" } }
+// { dg-final { scan-file pr93038.deps "pr93038.d" } }
+// { dg-final { scan-file pr93038.deps "pr93038.txt" } }
 // { dg-final { file delete pr93038.deps } }
 module pr93038;
 
diff --git a/gcc/testsuite/gdc.dg/pr93038b.d b/gcc/testsuite/gdc.dg/pr93038b.d
index 04177a7e01a..18649b8636a 100644
--- a/gcc/testsuite/gdc.dg/pr93038b.d
+++ b/gcc/testsuite/gdc.dg/pr93038b.d
@@ -1,7 +1,10 @@
 // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93038
 // { dg-options "-J $srcdir/gdc.dg/fileimports -MMD -MP" }
 // { dg-do compile }
-// { dg-final { scan-file pr93038b.deps "pr93038b.o: \[^\n\]*/pr93038b.d \[ 
\n\]*\[^\n\]*/fileimports/pr93038.txt\n\n\[^\n\]*/fileimports/pr93038.txt:" 
} }
+// { dg-final { scan-file pr93038b.deps "(^|\\n)pr93038b.o:" } }
+// { dg-final { scan-file pr93038b.deps "pr93038b.d" } }
+// { dg-final { scan-file pr93038b.deps "pr93038.txt" } }
+// { dg-final { scan-file pr93038b.deps "(^|\\n)\[^\n\]*pr93038.txt:" } }
 // { dg-final { file delete pr93038b.deps } }
 module pr93038b;
 
-- 
2.20.1

Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Christophe Lyon via Gcc-patches]

On Wed, 25 Mar 2020 at 01:24, Pop, Sebastian via Gcc-patches
 wrote:
>
> Hi Kyrill,
>
> Thanks for pointing out the two missing bug fixes.
> Please see attached all the back-ported patches.
> All the patches from trunk applied cleanly with no conflicts (except for the 
> ChangeLog files) to the gcc-9 branch.
> An up to date gcc-9 branch on which I applied the attached patches has passed 
> bootstrap on aarch64-linux (Graviton2 with 64 N1 cores) and make check with 
> no extra fails.
> Kyrill, could you please commit the attached patches to the gcc-9 branch?
>

Hi,

I'm seeing a GCC build failure after "aarch64: Implement TImode
compare-and-swap"
was backported to gcc-9 (commit 53c1356515ac1357c341b594326967ac4677d891)

The build log has:
0x14a1660 gen_split_100(rtx_insn*, rtx_def**)

/tmp/6477245_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/atomics.md:110
0xa81076 try_split(rtx_def*, rtx_insn*, int)

/tmp/6477245_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/emit-rtl.c:3851
0xda2b0d split_insn

/tmp/6477245_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/recog.c:2901
0xda7057 split_all_insns()

/tmp/6477245_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/recog.c:3005
0xda7118 execute

/tmp/6477245_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/recog.c:3957
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [Makefile:659: tsan_interface_atomic.lo] Error 1

Maybe that problem is fixed by a patch later in the series? (I have
validations running after every patch on the release branches, so it
may take a while until I have the results for the end of the series)

Thanks,

Christophe

> As we still don't have a copyright assignment on file, would it be possible 
> for ARM to finish the backport to the gcc-8 branch of these patches and the 
> atomics cleanup patches mentioned below?
>
> I did a `git log config/aarch64/atomics.md` and there is a follow-up patch to 
> the atomics cleanup patches:
>
> commit e21679a8bb17aac603b8704891e60ac502200629
> Author: Jakub Jelinek 
> Date:   Wed Nov 21 17:41:03 2018 +0100
>
> re PR target/87839 (ICE in final_scan_insn_1, at final.c:3070)
>
> PR target/87839
> * config/aarch64/atomics.md (@aarch64_compare_and_swap): Use
> rIJ constraint for aarch64_plus_operand rather than rn.
>
> * gcc.target/aarch64/pr87839.c: New test.
>
> From-SVN: r266346
>
> That is fixing code modified in this cleanup patch:
>
> commit d400fda3a8c3330f77eb9d51874f5482d3819a9f
> Author: Richard Henderson 
> Date:   Wed Oct 31 09:42:39 2018 +
>
> aarch64: Improve cas generation
>
>
> Thanks,
> Sebastian
>
>
> On 3/11/20, 5:11 AM, "Kyrill Tkachov"  wrote:
>
> CAUTION: This email originated from outside of the organization. Do not 
> click links or open attachments unless you can confirm the sender and know 
> the content is safe.
>
>
>
> Hi Sebastian,
>
> On 3/9/20 9:47 PM, Pop, Sebastian wrote:
> > Hi,
> >
> > Please see attached the patches to add -moutline-atomics to the gcc-9 
> branch.
> > Tested on graviton2 aarch64-linux with bootstrap and
> > `make check` passes with no new fails.
> > Tested `make check` on glibc built with gcc-9 with and without 
> "-moutline-atomics"
> > and CFLAGS=" -O2 -g -fno-stack-protector -U_FORTIFY_SOURCE".
> >
> > Ok to commit to gcc-9 branch?
>
> Since this feature enables backwards-compatible deployment of LSE
> atomics, I'd support that.
>
> That is okay with me in principle after GCC 9.3 is released (the branch
> is currently frozen).
>
> However, there have been a few follow-up patches to fix some bugs
> revealed by testing.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833
>
> and
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834
>
> come to mind.
>
> Can you please make sure the fixes for those are included as well?
>
>
> >
> > Does this mechanical `git am *.patch` require a copyright assignment?
> > I am still working with my employer on getting the FSF assignment 
> signed.
> >
> > Thanks,
> > Sebastian
> >
> > PS: For gcc-8 backports there are 5 cleanup and improvement patches
> > that are needed for -moutline-atomics patches to apply cleanly.
> > Should these patches be back-ported in the same time as the flag 
> patches,
> > or should I update the patches to apply to the older code base?
>
> Hmm... normally I'd be for them. In this case I'd want to make sure that
> there aren't any fallout fixes that we're missing.
>
> Did these patches have any bug reports against them?
>
> Thanks,
>
> Kyrill
>
>
> > Here is the list of the extra patches:
> >
> >  From 77f33f44baf24c22848197aa80962c003dd7b3e2 Mon Sep 17 00:00:00 2001

Re: [PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]

[Jason Merrill via Gcc-patches]

On 3/31/20 3:50 PM, Patrick Palka wrote:

On Tue, 31 Mar 2020, Jason Merrill wrote:


On 3/30/20 6:46 PM, Patrick Palka wrote:

On Mon, 30 Mar 2020, Jason Merrill wrote:

On 3/30/20 3:58 PM, Patrick Palka wrote:

On Thu, 26 Mar 2020, Jason Merrill wrote:


On 3/22/20 9:21 PM, Patrick Palka wrote:

This patch relaxes an assertion in tsubst_default_argument that
exposes
a
latent
bug in how we substitute an array type into a cv-qualified wildcard
function
parameter type.  Concretely, the latent bug is that given the
function
template

  template void foo(const T t);

one would expect the type of foo to be void(const int*), but
we
(seemingly prematurely) strip function parameter types of their
top-level
cv-qualifiers when building the function's TYPE_ARG_TYPES, and
instead
end
up
obtaining void(int*) as the type of foo after substitution
and
decaying.

We still however correctly substitute into and decay the formal
parameter
type,
obtaining const int* as the type of t after substitution.  But this
then
leads
to us tripping over the assert in tsubst_default_argument that
verifies
the
formal parameter type and the function type are consistent.

Assuming it's too late at this stage to fix the substitution bug, we
can
still
relax the assertion like so.  Tested on x86_64-pc-linux-gnu, does
this
look
OK?


This is core issues 1001/1322, which have not been resolved.  Clang
does
the
substitution the way you suggest; EDG rejects the testcase because the
two
substitutions produce different results.  I think it would make sense
to
follow the EDG behavior until this issue is actually resolved.


Here is what I have so far towards that end.  When substituting into the
PARM_DECLs of a function decl, we now additionally check if the
aforementioned Core issues are relevant and issue a (fatal) diagnostic
if so.  This patch checks this in tsubst_decl  rather
than in tsubst_function_decl for efficiency reasons, so that we don't
have to perform another traversal over the DECL_ARGUMENTS /
TYPE_ARG_TYPES just to implement this check.


Hmm, this seems like writing more complicated code for a very marginal
optimization; how many function templates have so many parameters that
walking
over them once to compare types will have any effect on compile time?


Good point... though I just tried implementing this check in
tsubst_function_decl, and it seems it might be just as complicated to
implement it there instead, at least if we want to handle function
parameter packs correctly.

If we were to implement this check in tsubst_function_decl, then since
we have access to the instantiated function, it would presumably suffice
to compare its substituted DECL_ARGUMENTS with its substituted
TYPE_ARG_TYPES to see if they're consistent.  Doing so would certainly
catch the original testcase, i.e.

template
  void foo(const T);
int main() { foo(0); }

because the DECL_ARGUMENTS of foo would be {const int*} and its
TYPE_ARG_TYPES would be {int*}.  But apparently it doesn't catch the
corresponding testcase that uses a function parameter pack, i.e.

template
  void foo(const Ts...);
int main() { foo(0); }

because it turns out we don't strip top-level cv-qualifiers from
function parameter packs from TYPE_ARG_TYPES at declaration time, as we
do with regular function parameters.  So in this second testcase both
DECL_ARGUMENTS and TYPE_ARG_TYPES of foo would be {const int*},
and yet we would (presumably) want to reject this instantiation too.

So it seems comparing TYPE_ARG_TYPES and DECL_ARGUMENTS from
tsubst_function_decl would not suffice, and we would still need to do a
variant of the trick that's done in this patch, i.e. substitute into
each dependent parameter type stripped of its top-level cv-qualifiers,
to see if these cv-qualifiers make a material difference in the
resulting function type.  Or maybe there's yet another way to detect
this?


I think let's go ahead with comparing TYPE_ARG_TYPES and DECL_ARGUMENTS; the
problem comes when they disagree.  If we're handling pack expansions wrong,
that's a separate issue.


Hm, comparing TYPE_ARG_TYPES and DECL_ARGUMENTS for compatibility seems
to be exposing a latent bug with how we handle lambdas that appear in
function parameter types.  Take g++.dg/cpp2a/lambda-uneval3.C for
example:

 template  void spam(decltype([]{}) (*s)[sizeof(T)]) {}
 int main() { spam(nullptr); }

According to tsubst_function_decl in current trunk, the type of the
function paremeter 's' of spam according to its TYPE_ARG_TYPES is
 struct ._anon_4[1] *
and according to its DECL_ARGUMENTS the type of 's' is
 struct ._anon_5[1] *

The disagreement happens because we call tsubst_lambda_expr twice during
substitution and thereby generate two distinct lambda types, one when
substituting into the TYPE_ARG_TYPES and another when substituting into
the DECL_ARGUMENTS.  I'm not sure how to work around this
bug/false-positive..


Oof.

I think probably the right answer is to rebuild TYPE_ARG_T

Re: [PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]

[Jason Merrill via Gcc-patches]

On 4/1/20 6:29 PM, Jason Merrill wrote:

On 3/31/20 3:50 PM, Patrick Palka wrote:

On Tue, 31 Mar 2020, Jason Merrill wrote:


On 3/30/20 6:46 PM, Patrick Palka wrote:

On Mon, 30 Mar 2020, Jason Merrill wrote:

On 3/30/20 3:58 PM, Patrick Palka wrote:

On Thu, 26 Mar 2020, Jason Merrill wrote:


On 3/22/20 9:21 PM, Patrick Palka wrote:

This patch relaxes an assertion in tsubst_default_argument that
exposes
a
latent
bug in how we substitute an array type into a cv-qualified wildcard
function
parameter type.  Concretely, the latent bug is that given the
function
template

  template void foo(const T t);

one would expect the type of foo to be void(const int*), but
we
(seemingly prematurely) strip function parameter types of their
top-level
cv-qualifiers when building the function's TYPE_ARG_TYPES, and
instead
end
up
obtaining void(int*) as the type of foo after substitution
and
decaying.

We still however correctly substitute into and decay the formal
parameter
type,
obtaining const int* as the type of t after substitution.  But this
then
leads
to us tripping over the assert in tsubst_default_argument that
verifies
the
formal parameter type and the function type are consistent.

Assuming it's too late at this stage to fix the substitution 
bug, we

can
still
relax the assertion like so.  Tested on x86_64-pc-linux-gnu, does
this
look
OK?


This is core issues 1001/1322, which have not been resolved.  Clang
does
the
substitution the way you suggest; EDG rejects the testcase 
because the

two
substitutions produce different results.  I think it would make 
sense

to
follow the EDG behavior until this issue is actually resolved.


Here is what I have so far towards that end.  When substituting 
into the

PARM_DECLs of a function decl, we now additionally check if the
aforementioned Core issues are relevant and issue a (fatal) 
diagnostic

if so.  This patch checks this in tsubst_decl  rather
than in tsubst_function_decl for efficiency reasons, so that we don't
have to perform another traversal over the DECL_ARGUMENTS /
TYPE_ARG_TYPES just to implement this check.


Hmm, this seems like writing more complicated code for a very marginal
optimization; how many function templates have so many parameters that
walking
over them once to compare types will have any effect on compile time?


Good point... though I just tried implementing this check in
tsubst_function_decl, and it seems it might be just as complicated to
implement it there instead, at least if we want to handle function
parameter packs correctly.

If we were to implement this check in tsubst_function_decl, then since
we have access to the instantiated function, it would presumably 
suffice

to compare its substituted DECL_ARGUMENTS with its substituted
TYPE_ARG_TYPES to see if they're consistent.  Doing so would certainly
catch the original testcase, i.e.

    template
  void foo(const T);
    int main() { foo(0); }

because the DECL_ARGUMENTS of foo would be {const int*} and its
TYPE_ARG_TYPES would be {int*}.  But apparently it doesn't catch the
corresponding testcase that uses a function parameter pack, i.e.

    template
  void foo(const Ts...);
    int main() { foo(0); }

because it turns out we don't strip top-level cv-qualifiers from
function parameter packs from TYPE_ARG_TYPES at declaration time, as we
do with regular function parameters.  So in this second testcase both
DECL_ARGUMENTS and TYPE_ARG_TYPES of foo would be {const int*},
and yet we would (presumably) want to reject this instantiation too.

So it seems comparing TYPE_ARG_TYPES and DECL_ARGUMENTS from
tsubst_function_decl would not suffice, and we would still need to do a
variant of the trick that's done in this patch, i.e. substitute into
each dependent parameter type stripped of its top-level cv-qualifiers,
to see if these cv-qualifiers make a material difference in the
resulting function type.  Or maybe there's yet another way to detect
this?


I think let's go ahead with comparing TYPE_ARG_TYPES and 
DECL_ARGUMENTS; the
problem comes when they disagree.  If we're handling pack expansions 
wrong,

that's a separate issue.


Hm, comparing TYPE_ARG_TYPES and DECL_ARGUMENTS for compatibility seems
to be exposing a latent bug with how we handle lambdas that appear in
function parameter types.  Take g++.dg/cpp2a/lambda-uneval3.C for
example:

 template  void spam(decltype([]{}) (*s)[sizeof(T)]) {}
 int main() { spam(nullptr); }

According to tsubst_function_decl in current trunk, the type of the
function paremeter 's' of spam according to its TYPE_ARG_TYPES is
 struct ._anon_4[1] *
and according to its DECL_ARGUMENTS the type of 's' is
 struct ._anon_5[1] *

The disagreement happens because we call tsubst_lambda_expr twice during
substitution and thereby generate two distinct lambda types, one when
substituting into the TYPE_ARG_TYPES and another when substituting into
the DECL_ARGUMENTS.  I'm not sure how to work around this
bug/false-positive..


Oof.

I 

Re: [PATCH] Fix PR94043 by making vect_live_op generate lc-phi

[H.J. Lu via Gcc-patches]

On Mon, Mar 30, 2020 at 4:09 AM Richard Biener via Gcc-patches
 wrote:
>
> On Mon, Mar 30, 2020 at 12:24 PM Kewen.Lin  wrote:
> >
> > Hi,
> >
> > As PR94043 shows, my commit r10-4524 exposed one issue in
> > vectorizable_live_operation, which inserts one extra BB
> > before the single exit, leading unexpected operand expansion
> > and unexpected loop depth assertion.  As Richi suggested,
> > this patch is to teach vectorizable_live_operation to
> > generate loop closed phi for vec_lhs, it looks like:
> >  loop;
> >  # lhs' = PHI 
> > =>
> >  loop;
> >  # vec_lhs' = PHI 
> >  new_tree = BIT_FIELD_REF ;
> >  lhs' = new_tree;
> >
> > I noticed that there are some SLP cases that have same lhs
> > and vec_lhs but different offsets, which can make us have
> > more PHIs for the same vec_lhs there.  But I think it would
> > be fine since only one of them is actually live, the others
> > should be eliminated by the following dce.  So the patch
> > doesn't check whether there is one phi for vec_lhs, just
> > create one directly instead.
> >
> > Bootstrapped/regtested on powerpc64le-linux-gnu (LE) P8.
> >
> > Is it ok for trunk?
>
> OK.
>
> Thanks,
> Richard.
>
> > BR,
> > Kewen
> > ---
> >
> > gcc/ChangeLog
> >
> > 2020-MM-DD  Kewen Lin  
> >
> > PR tree-optimization/94043
> > * tree-vect-loop.c (vectorizable_live_operation): Generate 
> > loop-closed
> > phi for vec_lhs and use it for lane extraction.
> >
> > gcc/testsuite/ChangeLog
> >
> > 2020-MM-DD  Kewen Lin  
> >
> > PR tree-optimization/94043
> > * gfortran.dg/graphite/vect-pr94043.f90: New test.
> >

This caused:

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

-- 
H.J.

Re: [PATCH], Make PowerPC -mcpu=future enable -mpcrel on linux ELFv2

[Michael Meissner via Gcc-patches]

On Wed, Apr 01, 2020 at 04:36:05PM -0500, Segher Boessenkool wrote:
> On Wed, Apr 01, 2020 at 03:16:52PM -0400, Michael Meissner wrote:
> > > > > -/* Support for a future processor's features.  Do not enable -mpcrel
> > > > > until it
> > > > > -   is fully functional.  */
> > > > > +/* Support for a future processor's features.  We do not set -mpcrel
> > > > > or
> > > > > +   -mprefixed here.  These bits are set in rs6000_option_override if
> > > > > the system
> > > > > +   supports those options. */
> > > > 
> > > > I'm still not sure the comment here is actually necessary, there are
> > > > many other places where we also do not set -mpcrel or -mprefixed.  If
> > > > history of the code here requires a hint to point at those options
> > > > being set in rs6000_option_override, then it's fine.
> > > 
> > > If you really need to say you do *not* do something, you should say why
> > > not.  Without that it only leaves more questions to the reader :-)
> > > 
> > > Hopefully that then also explains why the reader should care about this.
> > 
> > Given this comment is against Will's comment, and not the original code, is
> > there anything I need to do to the code (other than the ChangeLog and 
> > adjusting
> > object file format to ABI?
> 
> I am agreeing with Will's comment here, just expanding on it.  This
> comment isn't helpful (maybe it would be with more provided context,
> but as it is, it is not).

Ok, I will revist the comment.

-- 
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] PR lto/94249: Correct endianness detection with the __BYTE_ORDER macro

[Hans-Peter Nilsson]

On Wed, 1 Apr 2020, Martin Li?ka wrote:

> On 4/1/20 7:01 AM, Hans-Peter Nilsson wrote:
> > On Tue, 31 Mar 2020, Maciej W. Rozycki wrote:
> > > Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
> > > detection.") and fix a typo in the __BYTE_ORDER fallback macro check
> > > that causes compilation errors like:
> > >
> > > .../include/plugin-api.h:162:2: error: #error "Could not detect
> > > architecture endianess"
> > >
> > > on systems that do not provide the __BYTE_ORDER__ macro.
> >
> > > Index: binutils/include/plugin-api.h
> > > ===
> > > --- binutils.orig/include/plugin-api.h
> > > +++ binutils/include/plugin-api.h
> > > @@ -51,7 +51,7 @@
> > >   /* Older GCC releases (<4.6.0) can make detection from glibc macros.  */
> > >   #if defined(__GLIBC__) || defined(__GNU_LIBRARY__) ||
> > > defined(__ANDROID__)
> > >   #include 
> > > -#ifdef _BYTE_ORDER
> > > +#ifdef __BYTE_ORDER
> > >   #if __BYTE_ORDER == __LITTLE_ENDIAN
> > >   #define PLUGIN_LITTLE_ENDIAN 1
> > >   #elif __BYTE_ORDER == __BIG_ENDIAN
> >
> > FWIW, I was about to commit that as obvious, also the bignum.h
> > inclusion thing!
> >
> > The only question being, how the typo passed any kind of testing
> > in the first place...
>
> Because I don't have a legacy system with an ancient glibc version.

Before anyone starts doing this too: NO.  That's just not valid
procedure and not a valid excuse.  Please test your patches more
carefully.

*Ask* for it to be tested if you can't find a way to test it on
your own.  I see you didn't even say that you didn't test those
lines, when the patch was submitted.

> Note that testing matrix for such a change is massive, including such
> exotic targets like SUN, minix, Windows, ...

Not necessary, you just have to cover those lines for *one*
host system.

Such situations can usually even be worked around to make sure
those lines are tested at least once, something like "to test
this on my current glibc system, I temporarily edited
plugins-api.h, putting an #undef __BYTE_ORDER" just after the
'Older GCC' comment".

Another solution would be to disable plugins for such legacy
systems.

> >  No actually, there's also the question
> > why the plugin-API needs to bother with host endianness.  It's
> > not like endians are going to be different between plugins and
> > gcc on host.
>
> No, the plugin endianess matches with a host compiler endianess.

If that's true then it could be just written and read as-is,
unless you do different pickling on the way in, but if so, that
could be fixed cleaner than writing differently than reading.
...oh, I see there's a hack; there's an assumption that there
was padding with the "old" API and abusing that to add fields
for a "new" API, and using the endianness to indicate the
location of the padding.  Ew.  I'm not going to step closer than
that.

BTW, was this old/new plugin-API support tested
*cross*-versions?

brgds, H-P

Re: [AArch64] Backporting -moutline-atomics to gcc 9.x and 8.x

[Pop, Sebastian via Gcc-patches]

I have also seen this error in tsan.
The fix is 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ea376dd471a3b006bc48945c1d9a29408ab17a04
"Fix shrinkwrapping interactions with atomics (PR92692)".
This fix got committed as the last patch in the series.

Sebastian

On 4/1/20, 5:13 PM, "Christophe Lyon"  wrote:

CAUTION: This email originated from outside of the organization. Do not 
click links or open attachments unless you can confirm the sender and know the 
content is safe.



On Wed, 25 Mar 2020 at 01:24, Pop, Sebastian via Gcc-patches
 wrote:
>
> Hi Kyrill,
>
> Thanks for pointing out the two missing bug fixes.
> Please see attached all the back-ported patches.
> All the patches from trunk applied cleanly with no conflicts (except for 
the ChangeLog files) to the gcc-9 branch.
> An up to date gcc-9 branch on which I applied the attached patches has 
passed bootstrap on aarch64-linux (Graviton2 with 64 N1 cores) and make check 
with no extra fails.
> Kyrill, could you please commit the attached patches to the gcc-9 branch?
>

Hi,

I'm seeing a GCC build failure after "aarch64: Implement TImode
compare-and-swap"
was backported to gcc-9 (commit 53c1356515ac1357c341b594326967ac4677d891)

The build log has:
0x14a1660 gen_split_100(rtx_insn*, rtx_def**)

/tmp/6477245_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/config/aarch64/atomics.md:110
0xa81076 try_split(rtx_def*, rtx_insn*, int)

/tmp/6477245_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/emit-rtl.c:3851
0xda2b0d split_insn

/tmp/6477245_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/recog.c:2901
0xda7057 split_all_insns()

/tmp/6477245_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/recog.c:3005
0xda7118 execute

/tmp/6477245_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/recog.c:3957
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [Makefile:659: tsan_interface_atomic.lo] Error 1

Maybe that problem is fixed by a patch later in the series? (I have
validations running after every patch on the release branches, so it
may take a while until I have the results for the end of the series)

Thanks,

Christophe

> As we still don't have a copyright assignment on file, would it be 
possible for ARM to finish the backport to the gcc-8 branch of these patches 
and the atomics cleanup patches mentioned below?
>
> I did a `git log config/aarch64/atomics.md` and there is a follow-up 
patch to the atomics cleanup patches:
>
> commit e21679a8bb17aac603b8704891e60ac502200629
> Author: Jakub Jelinek 
> Date:   Wed Nov 21 17:41:03 2018 +0100
>
> re PR target/87839 (ICE in final_scan_insn_1, at final.c:3070)
>
> PR target/87839
> * config/aarch64/atomics.md 
(@aarch64_compare_and_swap): Use
> rIJ constraint for aarch64_plus_operand rather than rn.
>
> * gcc.target/aarch64/pr87839.c: New test.
>
> From-SVN: r266346
>
> That is fixing code modified in this cleanup patch:
>
> commit d400fda3a8c3330f77eb9d51874f5482d3819a9f
> Author: Richard Henderson 
> Date:   Wed Oct 31 09:42:39 2018 +
>
> aarch64: Improve cas generation
>
>
> Thanks,
> Sebastian
>
>
> On 3/11/20, 5:11 AM, "Kyrill Tkachov"  wrote:
>
> CAUTION: This email originated from outside of the organization. Do 
not click links or open attachments unless you can confirm the sender and know 
the content is safe.
>
>
>
> Hi Sebastian,
>
> On 3/9/20 9:47 PM, Pop, Sebastian wrote:
> > Hi,
> >
> > Please see attached the patches to add -moutline-atomics to the 
gcc-9 branch.
> > Tested on graviton2 aarch64-linux with bootstrap and
> > `make check` passes with no new fails.
> > Tested `make check` on glibc built with gcc-9 with and without 
"-moutline-atomics"
> > and CFLAGS=" -O2 -g -fno-stack-protector -U_FORTIFY_SOURCE".
> >
> > Ok to commit to gcc-9 branch?
>
> Since this feature enables backwards-compatible deployment of LSE
> atomics, I'd support that.
>
> That is okay with me in principle after GCC 9.3 is released (the 
branch
> is currently frozen).
>
> However, there have been a few follow-up patches to fix some bugs
> revealed by testing.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91833
>
> and
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91834
>
> come to mind.
>
> Can you please make sure the fixes for tho

[AArch64][SVE][IPA] ICE caused by incompatibility of SRA and svst builtin-function

[bule]

Hello,

An Internal Compiler Error(ICE) is found in ipa-sra optimization pass when it 
handle the argument of internal call svst3 for SVE.

The problem comes from gcc/testsuite/gcc.target/aarch64/sve/acle/asm/st2_bf16.c 
in the test suit, which can be reduced to flowing code:

#include 
#include
void st2_bf16_base (svbfloat16x3_t z1, svbool_t p0, bfloat16_t *x0, intptr_t 
x1) { 
svst3 (p0, x0, z1);
}

Compiled with -march=armv8.2-a+sve -msve-vector-bits=256 -O2, it will result in 
a segment fault in IPA-SRA: 

> [bule@localhost gcc10_fail]$ gcc st2_bf16.i -o st2_bf16.s -S 
> -march=armv8.2-a+sve -msve-vector-bits=256 -O2 
> during IPA pass: sra
> st2_bf16.c: In function ‘st2_bf16_base’:
> st2_bf16.c:10:1: internal compiler error: Segmentation fault
>   .. /* omit some stack info here.  */ ..
> 0xa34f68 call_summary::get_create(cgraph_edge*)
> ../.././gcc/symbol-summary.h:642
> 0xa34f68 record_nonregister_call_use
> ../.././gcc/ipa-sra.c:1613
> 0xa34f68 scan_expr_access
> ../.././gcc/ipa-sra.c:1781
>   .. /* omit some stack info here.  */ ..
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.

Details can be found in PR 94398.
Similar problem can be found in svst2、svst4 and other functions of this kind.

This problem is cause by "record_nonregister_call_use" function trying to 
access the call graph edge of an internal call, .MASK_STORE_LANE, which is a 
NULL pointer.

The reason of stepping into "record_nonregister_call_use" function is that the 
upper level function "scan_expr_access" considered the "svbfloat16x3_t z1"
argument as a valid candidate for further optimization.

A simple solution here is to disqualify the candidate at "scan_expr_access" 
level when the call graph edge is null, which indicates the call is either an 
internal call or a call with no references. For both case, the further 
optimization process should stop before it reference a NULL pointer.

A proposed patch is attached.

Any suggestions?

Thanks,
Bu Le


ips-sra-sve-fix.patch
Description: ips-sra-sve-fix.patch

Re: [pushed] c++: Fix DMI with lambda 'this' capture [PR94205]

[Jason Merrill via Gcc-patches]

On 4/1/20 10:47 AM, Patrick Palka wrote:

On Wed, 1 Apr 2020, Jason Merrill wrote:


We represent 'this' in a default member initializer with a PLACEHOLDER_EXPR.
Normally in constexpr evaluation when we encounter one it refers to
ctx->ctor, but when we're creating a temporary of class type, that replaces
ctx->ctor, so a PLACEHOLDER_EXPR that refers to the type of the member being
initialized needs to be replaced before that happens.

This patch fixes the testcase below, but not the original testcase from the PR,
which is still broken due to PR94219.

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

gcc/cp/ChangeLog
2020-03-31  Jason Merrill  

PR c++/94205
* constexpr.c (cxx_eval_constant_expression) [TARGET_EXPR]: Call
replace_placeholders.
* typeck2.c (store_init_value): Fix arguments to
fold_non_dependent_expr.
---
  gcc/cp/constexpr.c|  6 ++
  gcc/cp/tree.c |  2 +-
  gcc/cp/typeck2.c  |  2 +-
  gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C | 20 +++
  gcc/testsuite/g++.dg/cpp1z/lambda-this4.C | 13 
  5 files changed, 41 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi2.C
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/lambda-this4.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index e85b3c113f0..91f0c3ba269 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -5553,6 +5553,12 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx, 
tree t,
tree init = TARGET_EXPR_INITIAL (t);
if ((AGGREGATE_TYPE_P (type) || VECTOR_TYPE_P (type)))
  {
+   if (ctx->object)
+ /* If the initializer contains any PLACEHOLDER_EXPR, we need to
+resolve them before we create a new CONSTRUCTOR for the
+temporary.  */
+ init = replace_placeholders (init, ctx->object);


I think I'm running into an issue due to this call to replace_placeholders.
After this change, the following (compiled with -std=c++17) ICEs

 struct S
 {
   int a = [this] { return 6; } ();
 };

 S
 foo()
 {
   return {};
 }

with

 internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2830

Unsharing 'init' before before doing replace_placeholders seems to fix
this ICE.


That sounds good, thanks.

Jason

[PATCH PR94442] [AArch64] Redundant ldp/stp instructions emitted at -O3

[xiezhiheng]

Hi,
  I've created a bug for this issue: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94442

  And I'm going to solve this problem by propagating def's insn to its use
  when they are at the same loop in fwprop pass.
  I mean something like:
diff --git a/gcc/fwprop.c b/gcc/fwprop.c
index 705d2885aae..0edbbc65047 100644
--- a/gcc/fwprop.c
+++ b/gcc/fwprop.c
@@ -416,7 +416,7 @@ should_replace_address (rtx old_rtx, rtx new_rtx, 
machine_mode mode,
 gain = (set_src_cost (new_rtx, VOIDmode, speed)
- set_src_cost (old_rtx, VOIDmode, speed));

-  return (gain > 0);
+  return (gain >= 0);
 }


@@ -1573,10 +1573,14 @@ fwprop (bool fwprop_addr_p)
   df_ref use = DF_USES_GET (i);
   if (use)
{
+ df_ref def = get_def_for_use (use);
  if (DF_REF_TYPE (use) == DF_REF_REG_USE
  || DF_REF_BB (use)->loop_father == NULL
  /* The outer most loop is not really a loop.  */
- || loop_outer (DF_REF_BB (use)->loop_father) == NULL)
+ || loop_outer (DF_REF_BB (use)->loop_father) == NULL
+ || (def && (DF_REF_BB (def)->loop_father == DF_REF_BB 
(use)->loop_father
+ || flow_loop_nested_p (DF_REF_BB(use)->loop_father,
+DF_REF_BB(def)->loop_father
forward_propagate_into (use, fwprop_addr_p);

  else if (fwprop_addr_p)

Any suggestions?

Best regards
Xie Zhiheng