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

[Jiufu Guo via Gcc-patches]

Segher Boessenkool  writes:

> Hi Jiufu,
>
> Just reviewing random things as I see them...
>
> On Wed, Apr 15, 2020 at 09:56:00AM +0800, Jiufu Guo wrote:
>> This patch only supports simple loops: one exit edge with one major basic 
>> block.
>
> That is fine for a proof-of-concept, but will need fixing perhaps.
Hi Segher,

Thanks so much.  You are always point out things to improve! 
>
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -2526,6 +2526,10 @@ fvariable-expansion-in-unroller
>>  Common Report Var(flag_variable_expansion_in_unroller) Optimization
>>  Apply variable expansion when loops are unrolled.
>>  
>> +fassin-new-operand-in-unroller
>
> Typo ("assign").  But, is there ever any reason to disable this?  (You
> want an option for it during development, of course, but all public
> options cost something).
Helpful question, development is one reason for now to test benefits and
lost, and incase some one want to disable it.
Your question let me think if it really need to disable it.  In theory,
this behavior is correct and not harmful. 


>
>> +struct def_to_split
>> +{
>> +  rtx_insn *insn;   /* The insn in that the assigment occurs.  */
>> +  rtx reg;   /* The def/set pseudo.  */
>> +  vec defs; /* The copies of the defs which is split to.  */
>> +  struct def_to_split *next; /* Next entry in walking order.  */
>> +  int count; /* Number of DEFS.  */
>> +  int use_before_def;   /* The pseudo is used before re-defined.  */
>> +  rtx_insn *last_insn;
>> +};
>
> Three different kinds of indentation here.
>
> It might work better to explain it all in a bigger comment before this
> struct definition.  It also would help to have better, more obvious
> names?  Not "reg" but "orig_reg", not "defs" but "regs", not "count"
> but "nregs"?
Style, I may enhance it through tools.
Thanks for comments about naming :)
>
>> +/* Return a hash for VES.  */
>> +
>> +inline hashval_t
>> +def_split_hasher::hash (const def_to_split *i)
>> +{
>> +  return (hashval_t) INSN_UID (i->insn);
>> +}
>
> What does "VES" mean?  Something from an older version of the patch?
it is typo :(
>
>
> Segher

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

[Jiufu Guo via Gcc-patches]

Segher Boessenkool  writes:

Hi,

Thanks for all your comments!

> Hi!
>
> On Wed, Apr 15, 2020 at 08:21:03AM +0200, Richard Biener wrote:
>> On Wed, Apr 15, 2020 at 3:56 AM Jiufu Guo via Gcc-patches
>>  wrote:
>> > As you may know, we have loop unroll pass in RTL which was introduced a few
>> > years ago, and works for a long time.  Currently, this unroller is using 
>> > the
>> > pseudos in the original body, and then the pseudos are written multiple 
>> > times.
>> >
>> > It would be a good idea to create new pseudos for those duplicated 
>> > instructions
>> > during loop unrolling.  This would relax reg dependence, and then provide 
>> > more
>> > freedom/opportunity for other optimizations, like scheduling, RA...
>> 
>> I think there's a separate pass to do something like this, conveniently
>> placed after unrolling.  -fweb, IIRC enabled by default for -funroll-loops
>> unless explicitly disabled.  Related is regrename which is also
>> enabled then.
web/rnreg have some help for some cases, while they does not know much
information about loop, and do not care if a BB/pseudo/reg is generated
during unrolling. Unroller know these information, and it maybe accurate
to create new pseudos and relax depences between insns in unroller. 
For the example of preview RTL sequences, using new pseudo in unroller
is better than web/rnreg.

>> 
>> So where does your patch make a difference?  Is the webizers dataflow 
>> analysis
>> maybe confused by backedges?
>
> Does -fweb handle things set by the last unrolled iteration, used by the
> first unrolled iteration?
>
> On a general note, we shouldn't depend on some pass that may or may not
> clean up the mess we make, when we could just avoid making a mess in the
> first place.
Yes, this is a reason that I also think it maybe good to do it during
unroller.

>
> The web pass belongs immediately after expand; but ideally, even expand
> would not reuse pseudos anyway.
Currently, web runs after loop done now. 

Jiufu

>
> Maybe it would be better as some utility routines, not a pass?
>
>
> Segher

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

[Kewen.Lin via Gcc-patches]

on 2020/4/15 下午2:21, Richard Biener via Gcc-patches wrote:
> On Wed, Apr 15, 2020 at 3:56 AM Jiufu Guo via Gcc-patches
>  wrote:
>>
>> Hi,
>>
>> As you may know, we have loop unroll pass in RTL which was introduced a few
>> years ago, and works for a long time.  Currently, this unroller is using the
>> pseudos in the original body, and then the pseudos are written multiple 
>> times.
>>
>> It would be a good idea to create new pseudos for those duplicated 
>> instructions
>> during loop unrolling.  This would relax reg dependence, and then provide 
>> more
>> freedom/opportunity for other optimizations, like scheduling, RA...
> 
> I think there's a separate pass to do something like this, conveniently
> placed after unrolling.  -fweb, IIRC enabled by default for -funroll-loops
> unless explicitly disabled.  Related is regrename which is also enabled then.
> 
> So where does your patch make a difference?  Is the webizers dataflow analysis
> maybe confused by backedges?
> 

Juofu can help to confirm, it looks we disabled them on rs6000 by default and 
don't
enable them for unroll_only_small_loops but just enable for explicit unroll 
options.
If it's proved that web can cover what we want here, one option sounds to bring 
it/them back even for unroll_only_small_loops?

BR,
Kewen

[PATCH], PR target/94557, V2, Fix GCC 9.x PowerPC regression due to PR target/93932 back port.

[Michael Meissner via Gcc-patches]

Fix regression caused by PR target/93932 backport.

When I back ported the fix for PR target/93932 to the GCC 9 branch, I put in an
unintended regression when the GCC compiler is optimizing the vec_extract
built-in function, and the vector element is in memory, and the index is
variable.  This patch masks the vector index so that it does not go out of
bounds.

2020-04-15  Michael Meissner  

PR target/94557
* config/rs6000/rs6000.c (rs6000_adjust_vec_address): Fix
regression caused by PR target/93932 backport.  Mask variable
vector extract index so it does not go beyond the vector when
extracting a vector element from memory.

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

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

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

Re: [PATCH] c++: Error recovery with errenous DECL_INITIAL [PR94475]

[Jason Merrill via Gcc-patches]

On 4/15/20 4:43 PM, Patrick Palka wrote:

Oops, consider the typo in the subject line fixed.  Also ...

On Wed, 15 Apr 2020, Patrick Palka wrote:


Here we're ICE'ing in do_narrow during error-recovery, because ocp_convert
returns error_mark_node after it attempts to reduce a const decl to its
erroneous DECL_INITIAL via scalar_constant_value, and we later pass this
error_mark_node to fold_build2 which isn't prepared to handle error_mark_nodes.

We could fix this ICE in do_narrow by checking if ocp_convert returns
error_mark_node, but for the sake of consistency and for better error recovery
it seems it'd be better if ocp_convert didn't care that a const decl's
initializer is erroneous and would instead proceed as if the decl was not const,
which is the approach that this patch takes.

Passes 'make check-c++', does this look OK to commit after full bootstrap and
regtest?

gcc/cp/ChangeLog:

PR c++/94475
* cvt.c (ocp_convert): If the result of scalar_constant_value is
erroneous, discard it and carry on with the original expression.

gcc/testsuite/ChangeLog:

PR c++/94475
* g++.dg/conversion/err-recover2.C: New test.
* g++.dg/diagnostic/pr84138.C: Remove now-bogus warning.
* g++.dg/warn/Wsign-compare-8.C: Remove now-bogus warning.
---
  gcc/cp/cvt.c   |  6 +++---
  gcc/testsuite/g++.dg/conversion/err-recover2.C | 10 ++
  gcc/testsuite/g++.dg/diagnostic/pr84138.C  |  2 +-
  gcc/testsuite/g++.dg/warn/Wsign-compare-8.C|  2 +-
  4 files changed, 15 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/conversion/err-recover2.C

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index a3b80968b33..b94231a6d08 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -723,10 +723,10 @@ ocp_convert (tree type, tree expr, int convtype, int 
flags,
if (!CLASS_TYPE_P (type))
  {
e = mark_rvalue_use (e);
-  e = scalar_constant_value (e);
+  tree v = scalar_constant_value (e);
+  if (!error_operand_p (v))
+   e = v;
  }
-  if (error_operand_p (e))
-return error_mark_node;


Removing this error_operand_p check might make an error_mark_node slip
through and get processed by the rest of ocp_convert, if the call to
mark_rvalue_use above returns error_mark_node.

In light of that, please consider this patch instead which restores that
error_operand_p check:


OK.  I wonder if we want to drop the call to scalar_constant_value 
entirely in GCC 11, and expect that the expression will be folded 
properly later.



-- >8 --

Subject: [PATCH] c++: Error recovery with erroneous DECL_INITIAL [PR94475]

gcc/cp/ChangeLog:

PR c++/94475
* cvt.c (ocp_convert): If the result of scalar_constant_value is
erroneous, ignore it and use the original expression.

gcc/testsuite/ChangeLog:

PR c++/94475
* g++.dg/conversion/err-recover2.C: New test.
* g++.dg/diagnostic/pr84138.C: Remove now-bogus warning.
* g++.dg/warn/Wsign-compare-8.C: Remove now-bogus warning.
---
  gcc/cp/cvt.c   |  4 +++-
  gcc/testsuite/g++.dg/conversion/err-recover2.C | 10 ++
  gcc/testsuite/g++.dg/diagnostic/pr84138.C  |  2 +-
  gcc/testsuite/g++.dg/warn/Wsign-compare-8.C|  2 +-
  4 files changed, 15 insertions(+), 3 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/conversion/err-recover2.C

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index a3b80968b33..656e7fd3ec0 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -723,7 +723,9 @@ ocp_convert (tree type, tree expr, int convtype, int flags,
if (!CLASS_TYPE_P (type))
  {
e = mark_rvalue_use (e);
-  e = scalar_constant_value (e);
+  tree v = scalar_constant_value (e);
+  if (!error_operand_p (v))
+   e = v;
  }
if (error_operand_p (e))
  return error_mark_node;
diff --git a/gcc/testsuite/g++.dg/conversion/err-recover2.C 
b/gcc/testsuite/g++.dg/conversion/err-recover2.C
new file mode 100644
index 000..437e1a919ea
--- /dev/null
+++ b/gcc/testsuite/g++.dg/conversion/err-recover2.C
@@ -0,0 +1,10 @@
+// PR c++/94475
+// { dg-do compile }
+
+unsigned char
+sr ()
+{
+  const unsigned char xz = EI; // { dg-error "not declared" }
+
+  return xz - (xz >> 1);
+}
diff --git a/gcc/testsuite/g++.dg/diagnostic/pr84138.C 
b/gcc/testsuite/g++.dg/diagnostic/pr84138.C
index 5c48b9b164a..00352306a56 100644
--- a/gcc/testsuite/g++.dg/diagnostic/pr84138.C
+++ b/gcc/testsuite/g++.dg/diagnostic/pr84138.C
@@ -5,4 +5,4 @@ foo()
  {
const int i = 0 = 0; // { dg-error "lvalue required as left operand" }
return 1 ? 0 : (char)i;
-} // { dg-warning "control reaches" }
+}
diff --git a/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C 
b/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
index 237ba84d526..4d2688157fc 100644
--- a/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
+++ b/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
@@ -5,4 +5,4 @@ bool foo (char c)
  {

Re: [PATCH] c++: Fix pasto in structured binding diagnostics [PR94571]

[Jason Merrill via Gcc-patches]

On 4/15/20 4:12 AM, Jakub Jelinek wrote:

Hi!

This snippet has been copied from the non-structured binding declaration
parsing later in the function, and while for non-structured bindings
it can be followed by comma or semicolon, structured bindings may be
only followed by semicolon.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?


OK.


Or, do we want to have a different message for the case when there is
a comma (and keep this corrected one only if there is something else)
that would explain better what is the bug (or add a fix-it hint)?


That might be an improvement, sure.


Marek said in the PR that clang++ reports
error: decomposition declaration must be the only declaration in its group

There is another thing Marek noted (though, something for different spot),
that diagnostic for auto x(1), [e,f] = test2; could also use a clearer
wording like the above (or a fix-it hint), but the question is if we should
assume [ after , as a structured binding or if we should do some tentative
parsing first to figure out if it looks like a structured binding.


Would it make sense to parse it normally and just give a pedwarn if it 
happens to be in a list with other declarators?



2020-04-15  Jakub Jelinek  

PR c++/94571
* parser.c (cp_parser_simple_declaration): Fix up a pasto in
diagnostics.

* g++.dg/cpp1z/decomp51.C: New test.

--- gcc/cp/parser.c.jj  2020-04-08 11:59:23.772460767 +0200
+++ gcc/cp/parser.c 2020-04-14 10:15:54.824034781 +0200
@@ -13675,7 +13675,7 @@ cp_parser_simple_declaration (cp_parser*
if ((decl != error_mark_node
 && DECL_INITIAL (decl) != error_mark_node)
|| cp_parser_uncommitted_to_tentative_parse_p (parser))
- cp_parser_error (parser, "expected %<,%> or %<;%>");
+ cp_parser_error (parser, "expected %<;%>");
/* Skip tokens until we reach the end of the statement.  */
cp_parser_skip_to_end_of_statement (parser);
/* If the next token is now a `;', consume it.  */
--- gcc/testsuite/g++.dg/cpp1z/decomp51.C.jj2020-04-14 10:18:58.318313777 
+0200
+++ gcc/testsuite/g++.dg/cpp1z/decomp51.C   2020-04-14 10:19:31.347823985 
+0200
@@ -0,0 +1,16 @@
+// PR c++/94571
+// { dg-do compile { target c++17 } }
+
+void
+foo ()
+{
+  int e[2], f[2];
+  auto [a,b] = e, [c,d] = f;   // { dg-error "expected ';' before ',' token" }
+}
+
+void
+bar ()
+{
+  int e[2];
+  auto [a, b] = e );   // { dg-error "expected ';' before '\\\)' 
token" }
+}

Jakub

libgo patch committed: Use 64 bits of hash seed on arm64

[Ian Lance Taylor via Gcc-patches]

This libgo patch by Eric Fang fixes the Aarch64 implementation of
aeshashbody to use all 64 bits of the hash seed.  This is the gccgo
fix for https://golang.org/issue/33960.  Committed to mainline.

Ian
4312e0f1391133d6bcd617bb5a81c7caaf6faf99
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 138425a19d2..7b382cf47b8 100644
--- a/gcc/go/gofrontend/MERGE
+++ b/gcc/go/gofrontend/MERGE
@@ -1,4 +1,4 @@
-89fbf55a409d37ae898e5c4ea4250035f86bed1b
+0fe7a277c5d22265a73a4d216bd5d81799634453
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
diff --git a/libgo/runtime/aeshash.c b/libgo/runtime/aeshash.c
index 00658d7a896..93f28fd6125 100644
--- a/libgo/runtime/aeshash.c
+++ b/libgo/runtime/aeshash.c
@@ -596,7 +596,7 @@ uintptr aeshashbody(void* p, uintptr seed, uintptr size, 
Slice aeskeysched) {
 
 uintptr aeshashbody(void* p, uintptr seed, uintptr size, Slice aeskeysched) {
uint8x16_t *pseed;
-   uint32x4_t vinit32;
+   uint64x2_t vinit64;
uint8x16_t vinit;
uint8x16_t vseed, vseed2, vseed3, vseed4;
uint8x16_t vseed5, vseed6, vseed7, vseed8;
@@ -610,10 +610,10 @@ uintptr aeshashbody(void* p, uintptr seed, uintptr size, 
Slice aeskeysched) {
pseed = (uint8x16_t*)(aeskeysched.__values);
 
// Combined hash seed and length.
-   vinit32 = vdupq_n_u32(0);
-   vinit32[0] = (uint32)seed;
-   vinit32[1] = (uint32)size;
-   vinit = vreinterpretq_u8_u32(vinit32);
+   vinit64 = vdupq_n_u64(0);
+   vinit64[0] = (uint64)seed;
+   vinit64[1] = (uint64)size;
+   vinit = vreinterpretq_u8_u64(vinit64);
 
// Mix in per-process seed.
vseed = vaeseq_u8(*pseed, vinit);
@@ -626,7 +626,7 @@ uintptr aeshashbody(void* p, uintptr seed, uintptr size, 
Slice aeskeysched) {
// Return 64 bits of scrambled input seed.
return vreinterpretq_u64_u8(vseed)[0];
} else if (size < 16) {
-   vval = vreinterpretq_u8_u32(vdupq_n_u32(0));
+   vval = vreinterpretq_u8_u64(vdupq_n_u64(0));
if ((size & 8) != 0) {
vval = 
vreinterpretq_u8_u64(vld1q_lane_u64((uint64_t*)(p), vreinterpretq_u64_u8(vval), 
0));
p = (void*)((uint64_t*)(p) + 1);

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

[Segher Boessenkool]

Hi!

On Wed, Apr 15, 2020 at 08:21:03AM +0200, Richard Biener wrote:
> On Wed, Apr 15, 2020 at 3:56 AM Jiufu Guo via Gcc-patches
>  wrote:
> > As you may know, we have loop unroll pass in RTL which was introduced a few
> > years ago, and works for a long time.  Currently, this unroller is using the
> > pseudos in the original body, and then the pseudos are written multiple 
> > times.
> >
> > It would be a good idea to create new pseudos for those duplicated 
> > instructions
> > during loop unrolling.  This would relax reg dependence, and then provide 
> > more
> > freedom/opportunity for other optimizations, like scheduling, RA...
> 
> I think there's a separate pass to do something like this, conveniently
> placed after unrolling.  -fweb, IIRC enabled by default for -funroll-loops
> unless explicitly disabled.  Related is regrename which is also enabled then.
> 
> So where does your patch make a difference?  Is the webizers dataflow analysis
> maybe confused by backedges?

Does -fweb handle things set by the last unrolled iteration, used by the
first unrolled iteration?

On a general note, we shouldn't depend on some pass that may or may not
clean up the mess we make, when we could just avoid making a mess in the
first place.

The web pass belongs immediately after expand; but ideally, even expand
would not reuse pseudos anyway.

Maybe it would be better as some utility routines, not a pass?


Segher

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

[Segher Boessenkool]

Hi Jiufu,

Just reviewing random things as I see them...

On Wed, Apr 15, 2020 at 09:56:00AM +0800, Jiufu Guo wrote:
> This patch only supports simple loops: one exit edge with one major basic 
> block.

That is fine for a proof-of-concept, but will need fixing perhaps.

> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -2526,6 +2526,10 @@ fvariable-expansion-in-unroller
>  Common Report Var(flag_variable_expansion_in_unroller) Optimization
>  Apply variable expansion when loops are unrolled.
>  
> +fassin-new-operand-in-unroller

Typo ("assign").  But, is there ever any reason to disable this?  (You
want an option for it during development, of course, but all public
options cost something).

> +struct def_to_split
> +{
> +  rtx_insn *insn;/* The insn in that the assigment occurs.  */
> +  rtx reg;/* The def/set pseudo.  */
> +  vec defs;  /* The copies of the defs which is split to.  */
> +  struct def_to_split *next; /* Next entry in walking order.  */
> +  int count;  /* Number of DEFS.  */
> +  int use_before_def;/* The pseudo is used before re-defined.  */
> +  rtx_insn *last_insn;
> +};

Three different kinds of indentation here.

It might work better to explain it all in a bigger comment before this
struct definition.  It also would help to have better, more obvious
names?  Not "reg" but "orig_reg", not "defs" but "regs", not "count"
but "nregs"?

> +/* Return a hash for VES.  */
> +
> +inline hashval_t
> +def_split_hasher::hash (const def_to_split *i)
> +{
> +  return (hashval_t) INSN_UID (i->insn);
> +}

What does "VES" mean?  Something from an older version of the patch?


Segher

Re: [PATCH] c++: Error recovery with errenous DECL_INITIAL [PR94475]

[Patrick Palka via Gcc-patches]

Oops, consider the typo in the subject line fixed.  Also ...

On Wed, 15 Apr 2020, Patrick Palka wrote:

> Here we're ICE'ing in do_narrow during error-recovery, because ocp_convert
> returns error_mark_node after it attempts to reduce a const decl to its
> erroneous DECL_INITIAL via scalar_constant_value, and we later pass this
> error_mark_node to fold_build2 which isn't prepared to handle 
> error_mark_nodes.
> 
> We could fix this ICE in do_narrow by checking if ocp_convert returns
> error_mark_node, but for the sake of consistency and for better error recovery
> it seems it'd be better if ocp_convert didn't care that a const decl's
> initializer is erroneous and would instead proceed as if the decl was not 
> const,
> which is the approach that this patch takes.
> 
> Passes 'make check-c++', does this look OK to commit after full bootstrap and
> regtest?
> 
> gcc/cp/ChangeLog:
> 
>   PR c++/94475
>   * cvt.c (ocp_convert): If the result of scalar_constant_value is
>   erroneous, discard it and carry on with the original expression.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c++/94475
>   * g++.dg/conversion/err-recover2.C: New test.
>   * g++.dg/diagnostic/pr84138.C: Remove now-bogus warning.
>   * g++.dg/warn/Wsign-compare-8.C: Remove now-bogus warning.
> ---
>  gcc/cp/cvt.c   |  6 +++---
>  gcc/testsuite/g++.dg/conversion/err-recover2.C | 10 ++
>  gcc/testsuite/g++.dg/diagnostic/pr84138.C  |  2 +-
>  gcc/testsuite/g++.dg/warn/Wsign-compare-8.C|  2 +-
>  4 files changed, 15 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/conversion/err-recover2.C
> 
> diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
> index a3b80968b33..b94231a6d08 100644
> --- a/gcc/cp/cvt.c
> +++ b/gcc/cp/cvt.c
> @@ -723,10 +723,10 @@ ocp_convert (tree type, tree expr, int convtype, int 
> flags,
>if (!CLASS_TYPE_P (type))
>  {
>e = mark_rvalue_use (e);
> -  e = scalar_constant_value (e);
> +  tree v = scalar_constant_value (e);
> +  if (!error_operand_p (v))
> + e = v;
>  }
> -  if (error_operand_p (e))
> -return error_mark_node;

Removing this error_operand_p check might make an error_mark_node slip
through and get processed by the rest of ocp_convert, if the call to
mark_rvalue_use above returns error_mark_node.

In light of that, please consider this patch instead which restores that
error_operand_p check:

-- >8 --

Subject: [PATCH] c++: Error recovery with erroneous DECL_INITIAL [PR94475]

gcc/cp/ChangeLog:

PR c++/94475
* cvt.c (ocp_convert): If the result of scalar_constant_value is
erroneous, ignore it and use the original expression.

gcc/testsuite/ChangeLog:

PR c++/94475
* g++.dg/conversion/err-recover2.C: New test.
* g++.dg/diagnostic/pr84138.C: Remove now-bogus warning.
* g++.dg/warn/Wsign-compare-8.C: Remove now-bogus warning.
---
 gcc/cp/cvt.c   |  4 +++-
 gcc/testsuite/g++.dg/conversion/err-recover2.C | 10 ++
 gcc/testsuite/g++.dg/diagnostic/pr84138.C  |  2 +-
 gcc/testsuite/g++.dg/warn/Wsign-compare-8.C|  2 +-
 4 files changed, 15 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/conversion/err-recover2.C

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index a3b80968b33..656e7fd3ec0 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -723,7 +723,9 @@ ocp_convert (tree type, tree expr, int convtype, int flags,
   if (!CLASS_TYPE_P (type))
 {
   e = mark_rvalue_use (e);
-  e = scalar_constant_value (e);
+  tree v = scalar_constant_value (e);
+  if (!error_operand_p (v))
+   e = v;
 }
   if (error_operand_p (e))
 return error_mark_node;
diff --git a/gcc/testsuite/g++.dg/conversion/err-recover2.C 
b/gcc/testsuite/g++.dg/conversion/err-recover2.C
new file mode 100644
index 000..437e1a919ea
--- /dev/null
+++ b/gcc/testsuite/g++.dg/conversion/err-recover2.C
@@ -0,0 +1,10 @@
+// PR c++/94475
+// { dg-do compile }
+
+unsigned char
+sr ()
+{
+  const unsigned char xz = EI; // { dg-error "not declared" }
+
+  return xz - (xz >> 1);
+}
diff --git a/gcc/testsuite/g++.dg/diagnostic/pr84138.C 
b/gcc/testsuite/g++.dg/diagnostic/pr84138.C
index 5c48b9b164a..00352306a56 100644
--- a/gcc/testsuite/g++.dg/diagnostic/pr84138.C
+++ b/gcc/testsuite/g++.dg/diagnostic/pr84138.C
@@ -5,4 +5,4 @@ foo()
 {
   const int i = 0 = 0; // { dg-error "lvalue required as left operand" }
   return 1 ? 0 : (char)i;
-} // { dg-warning "control reaches" }
+}
diff --git a/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C 
b/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
index 237ba84d526..4d2688157fc 100644
--- a/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
+++ b/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
@@ -5,4 +5,4 @@ bool foo (char c)
 {
   const int i = 0 = 0; // { dg-error "lvalue" }
   return c = i;
-} // { dg-warning "control reaches" }
+}
-- 
2.26.1.107.gefe3874640

Fwd: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

[Qing Zhao via Gcc-patches]

Ping.

We need this patch for our product building.

thanks.

Qing

> Begin forwarded message:
> 
> From: Qing Zhao via Gcc-patches 
> Subject: PING [PATCH][gcc][PR94230]provide an option to change the size 
> limitation for -Wmisleading-indent 
> Date: April 8, 2020 at 2:39:22 PM CDT
> To: dmalc...@redhat.com, ja...@redhat.com
> Cc: gcc-patches@gcc.gnu.org
> Reply-To: Qing Zhao 
> 
> Hi,
> 
> Please take a look at the attached patch and let me know your comments.
> 
> Thanks.
> 
> Qing
> 
> gcc/ChangeLog:
> 
> 2020-04-03  qing zhao  
> 
>   * common.opt: Add -flocation-ranges.
>   * doc/invoke.texi: Document it.
>   * toplev.c (process_options): set line_table->default_range_bits
>   to 0 when flag_location_ranges is false. 
> 
> 
> 
>> Begin forwarded message:
>> 
>> From: Qing Zhao via Gcc-patches 
>> Subject: [PATCH][gcc][PR94230]provide an option to change the size 
>> limitation for -Wmisleading-indent 
>> Date: April 3, 2020 at 2:55:53 PM CDT
>> To: dmalc...@redhat.com, ja...@redhat.com
>> Cc: gcc-patches@gcc.gnu.org
>> Reply-To: Qing Zhao 
>> 
>> Hi, David and Jakub,
>> 
>> Per the discussion we had for PR94230: provide an option to change the size 
>> limitation for -Wmisleading-indent
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 
>> 
>> 
>> I come up with the following simple patch per David’s suggestion:
>> 
>> Provide a new first class option -flocation-ranges to control 
>> enabling/disablng range tracking when recording source locations.
>> The default value for this option is enabling the range tracking.
>> 
>> When specify -fno-location-ranges, disable the range tracking to save space 
>> for column tracking. 
>> 
>> I have tested this GCC to build our huge application by adding 
>> -fno-location-ranges, the whole build completed without any issue. and
>> -Wmisleading-indent also emitted several helpful warning message during 
>> building.
>> 
>> I am running bootstrap right now.
>> 
>> Could you please take a look at the attached patch?
>> 
>> thanks.
>> 
>> Qing
>> 
>> 
>> 
>> 
> 

Thoughts on applying a short diagnostics patch for GCC 10

[Lewis Hyatt via Gcc-patches]

Hello David-

I would appreciate hearing your thoughts please on the following
(relatively minor) issue... There is a little bug with colorization in
diagnostics: in case a location only points to the first byte of a
multibyte sequence, the colorization produces corrupted output as it
interrupts the UTF-8 sequence. This seems to happen with errors that come
out of cpplib for instance. A test case is:

---
int ٩x;
---

compiled with -x c -std=c99.

The fix for this issue is essentially two lines plus a test + comments,
and I had originally submitted it here:

https://gcc.gnu.org/legacy-ml/gcc-patches/2019-12/msg00915.html

Subsequent to that, I also submitted patches to implement tab expansion in
diagnostics. Those patches naturally fixed the colorization issue already
in a different way, because they rewrote this whole function, so I
indicated we might as well forget the simpler older patch. But then we
decided to hold off on the tab expansion feature until GCC 11. That makes
sense for sure, but then I think regarding the two-line fix for the
colorization bug, there is still potentially a good case to push it now?
It is not strictly a regression, but because we added support for UTF-8
identifiers in GCC 10, it is going to be more apparent now than it was
before. Given that and the fact that it's a pretty small change, would it
make sense to go ahead and get this in?

For reference I attached the patch and ChangeLog again here as
well. Bootstrap all languages on x86-64 linux looks good with all reg
tests the same before + after:

FAIL 94 94
PASS 473413 473413
UNSUPPORTED 11503 11503
UNTESTED 195 195
XFAIL 1818 1818
XPASS 36 36

Thanks!

-Lewis
gcc/ChangeLog:

2020-04-15  Lewis Hyatt  

* diagnostic-show-locus.c (layout::print_source_line): Do not emit
colorization codes in the middle of a UTF-8 sequence.
(test_one_liner_colorized_utf8): New test.
(test_diagnostic_show_locus_one_liner_utf8): Call the new test.
commit 5e2f6ec837fdf808ba20096bd632be9025f7526c
Author: Lewis Hyatt 
Date:   Wed Apr 15 11:17:33 2020 -0400

diagnostics: Fix colorization interrupting UTF-8 sequences

diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c
index 4618b4edb7d..0aa42e236ee 100644
--- a/gcc/diagnostic-show-locus.c
+++ b/gcc/diagnostic-show-locus.c
@@ -1494,6 +1494,8 @@ layout::print_source_line (linenum_type row, const char 
*line, int line_bytes,
   int last_non_ws = 0;
   for (int col_byte = 1 + x_offset_bytes; col_byte <= line_bytes; col_byte++)
 {
+  char c = *line;
+
   /* Assuming colorization is enabled for the caret and underline
 characters, we may also colorize the associated characters
 within the source line.
@@ -1505,8 +1507,13 @@ layout::print_source_line (linenum_type row, const char 
*line, int line_bytes,
 
 For frontends that only generate carets, we don't colorize the
 characters above them, since this would look strange (e.g.
-colorizing just the first character in a token).  */
-  if (m_colorize_source_p)
+colorizing just the first character in a token).
+
+We need to avoid inserting color codes ahead of UTF-8 continuation
+bytes to avoid corrupting the output, in case the location range
+points only to the first byte of a multibyte sequence.  */
+
+  if (m_colorize_source_p && (((unsigned int) c) & 0xC0) != 0x80)
{
  bool in_range_p;
  point_state state;
@@ -1519,7 +1526,6 @@ layout::print_source_line (linenum_type row, const char 
*line, int line_bytes,
  else
m_colorizer.set_normal_text ();
}
-  char c = *line;
   if (c == '\0' || c == '\t' || c == '\r')
c = ' ';
   if (c != ' ')
@@ -3854,6 +3860,27 @@ test_one_liner_labels_utf8 ()
   }
 }
 
+/* Make sure that colorization codes don't interrupt a multibyte
+   sequence, which would corrupt it.  */
+static void
+test_one_liner_colorized_utf8 ()
+{
+  test_diagnostic_context dc;
+  dc.colorize_source_p = true;
+  diagnostic_color_init (, DIAGNOSTICS_COLOR_YES);
+  const location_t pi = linemap_position_for_column (line_table, 12);
+  rich_location richloc (line_table, pi);
+  diagnostic_show_locus (, , DK_ERROR);
+
+  /* In order to avoid having the test depend on exactly how the colorization
+ was effected, just confirm there are two pi characters in the output.  */
+  const char *result = pp_formatted_text (dc.printer);
+  const char *null_term = result + strlen (result);
+  const char *first_pi = strstr (result, "\xcf\x80");
+  ASSERT_TRUE (first_pi && first_pi <= null_term - 2);
+  ASSERT_STR_CONTAINS (first_pi + 2, "\xcf\x80");
+}
+
 /* Run the various one-liner tests.  */
 
 static void
@@ -3900,6 +3927,7 @@ test_diagnostic_show_locus_one_liner_utf8 (const 
line_table_case _)
   test_one_liner_many_fixits_1_utf8 ();
   test_one_liner_many_fixits_2_utf8 ();
   test_one_liner_labels_utf8 ();
+  

Re: [PATCH] testsuite: Add check_effective_target_d_runtime_has_std_library procedure

[Iain Buclaw via Gcc-patches]

On 15/04/2020 17:17, Richard Sandiford wrote:
> Iain Buclaw via Gcc-patches  writes:
>> Hi,
>>
>> This patch adds an effect target d_runtime_has_std_library to
>> target-supports.exp, and some preliminary uses of it.
>>
>> The current check_effective_target_d_runtime procedure returns false if
>> the target is without any core runtime library for D.  This additional
>> procedure is for targets where the core runtime library exists, but is
>> without the higher level standard D library.
>>
>> OK for master?
> 
> OK.  FAOD though, D-related effective-target keywords are covered by the
> D frontend maintainership.
> 

Ah, thanks for clarifying that, I wasn't sure, but thought it best to pass it 
by for review just in case.

Iain.

[committed] libstdc++: Add comparison operators to std::filesystem types

[Jonathan Wakely via Gcc-patches]

Some more C++20 changes from P1614R2, "The Mothership has Landed".

* include/bits/fs_dir.h (file_status): Define operator== for C++20.
(directory_entry): Define operator<=> and remove redundant comparison
operators for C++20.
* include/bits/fs_fwd.h (space_info): Define operator== for C++20.
* include/bits/fs_path.h (path): Define operator<=> and remove
redundant comparison operators for C++20.
* testsuite/27_io/filesystem/path/compare/compare.cc: Fix comment.
* testsuite/27_io/filesystem/path/compare/lwg2936.cc: Likewise.
* testsuite/27_io/filesystem/path/compare/path.cc: Likewise.
* testsuite/27_io/filesystem/path/compare/strings.cc: Likewise.

Tested powerpc64le-linux, committed to master.


commit d43919bf887530dfcbf85a76d60f1a698641731d
Author: Jonathan Wakely 
Date:   Wed Apr 15 21:01:42 2020 +0100

libstdc++: Add comparison operators to std::filesystem types

Some more C++20 changes from P1614R2, "The Mothership has Landed".

* include/bits/fs_dir.h (file_status): Define operator== for C++20.
(directory_entry): Define operator<=> and remove redundant 
comparison
operators for C++20.
* include/bits/fs_fwd.h (space_info): Define operator== for C++20.
* include/bits/fs_path.h (path): Define operator<=> and remove
redundant comparison operators for C++20.
* testsuite/27_io/filesystem/path/compare/compare.cc: Fix comment.
* testsuite/27_io/filesystem/path/compare/lwg2936.cc: Likewise.
* testsuite/27_io/filesystem/path/compare/path.cc: Likewise.
* testsuite/27_io/filesystem/path/compare/strings.cc: Likewise.

diff --git a/libstdc++-v3/include/bits/fs_dir.h 
b/libstdc++-v3/include/bits/fs_dir.h
index df03f892f60..686dfce6e5f 100644
--- a/libstdc++-v3/include/bits/fs_dir.h
+++ b/libstdc++-v3/include/bits/fs_dir.h
@@ -36,6 +36,10 @@
 # include 
 # include 
 
+#if __cplusplus > 201703L
+# include // std::strong_ordering
+#endif
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -72,6 +76,11 @@ namespace filesystem
 void   type(file_type __ft) noexcept { _M_type = __ft; }
 void   permissions(perms __prms) noexcept { _M_perms = __prms; }
 
+#if __cpp_lib_three_way_comparison
+friend bool
+operator==(const file_status&, const file_status&) noexcept = default;
+#endif
+
   private:
 file_type  _M_type;
 perms  _M_perms;
@@ -272,18 +281,23 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 symlink_status(error_code& __ec) const noexcept
 { return filesystem::symlink_status(_M_path, __ec); }
 
-bool
-operator< (const directory_entry& __rhs) const noexcept
-{ return _M_path < __rhs._M_path; }
-
 bool
 operator==(const directory_entry& __rhs) const noexcept
 { return _M_path == __rhs._M_path; }
 
+#if __cpp_lib_three_way_comparison
+strong_ordering
+operator<=>(const directory_entry& __rhs) const noexcept
+{ return _M_path <=> __rhs._M_path; }
+#else
 bool
 operator!=(const directory_entry& __rhs) const noexcept
 { return _M_path != __rhs._M_path; }
 
+bool
+operator< (const directory_entry& __rhs) const noexcept
+{ return _M_path < __rhs._M_path; }
+
 bool
 operator<=(const directory_entry& __rhs) const noexcept
 { return _M_path <= __rhs._M_path; }
@@ -295,6 +309,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 bool
 operator>=(const directory_entry& __rhs) const noexcept
 { return _M_path >= __rhs._M_path; }
+#endif
 
   private:
 friend class _Dir;
diff --git a/libstdc++-v3/include/bits/fs_fwd.h 
b/libstdc++-v3/include/bits/fs_fwd.h
index 6363eca867c..d94cc414906 100644
--- a/libstdc++-v3/include/bits/fs_fwd.h
+++ b/libstdc++-v3/include/bits/fs_fwd.h
@@ -66,6 +66,10 @@ _GLIBCXX_END_NAMESPACE_CXX11
 uintmax_t capacity;
 uintmax_t free;
 uintmax_t available;
+
+#if __cpp_impl_three_way_comparison >= 201907L
+friend bool operator==(const space_info&, const space_info&) = default;
+#endif
   };
 
   enum class file_type : signed char {
diff --git a/libstdc++-v3/include/bits/fs_path.h 
b/libstdc++-v3/include/bits/fs_path.h
index fb6e8a5247f..ee6ab15cc4c 100644
--- a/libstdc++-v3/include/bits/fs_path.h
+++ b/libstdc++-v3/include/bits/fs_path.h
@@ -46,6 +46,10 @@
 #include 
 #include 
 
+#if __cplusplus > 201703L
+# include 
+#endif
+
 #if defined(_WIN32) && !defined(__CYGWIN__)
 # define _GLIBCXX_FILESYSTEM_IS_WINDOWS 1
 # include 
@@ -451,6 +455,20 @@ namespace __detail
 
 // non-member operators
 
+/// Compare paths
+friend bool operator==(const path& __lhs, const path& __rhs) noexcept
+{ return __lhs.compare(__rhs) == 0; }
+
+#if __cpp_lib_three_way_comparison
+/// Compare paths
+friend strong_ordering
+operator<=>(const path& __lhs, const path& __rhs) noexcept
+{ return __lhs.compare(__rhs) <=> 0; }
+#else
+

Go patch committed: Mark builtin_prefetch as novops

[Ian Lance Taylor via Gcc-patches]

This patch to the Go frontend marks builtin_prefetch as novops.  This
corresponds to how it is defined in builtins.def.  This fixes GCC PR
94607.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.

Ian

2020-04-15  Ian Lance Taylor  

PR go/94607
* go-gcc.cc (class Gcc_backend): Define builtin_const,
builtin_noreturn, builtin_novops.
(Gcc_backend::define_builtin): Change const_p and noreturn_p
parameters to a single flags parameter.  Change all callers.
(Gcc_backend::Gcc_backend): Pass novops for prefetch.

[PATCH] c++: Error recovery with errenous DECL_INITIAL [PR94475]

[Patrick Palka via Gcc-patches]

Here we're ICE'ing in do_narrow during error-recovery, because ocp_convert
returns error_mark_node after it attempts to reduce a const decl to its
erroneous DECL_INITIAL via scalar_constant_value, and we later pass this
error_mark_node to fold_build2 which isn't prepared to handle error_mark_nodes.

We could fix this ICE in do_narrow by checking if ocp_convert returns
error_mark_node, but for the sake of consistency and for better error recovery
it seems it'd be better if ocp_convert didn't care that a const decl's
initializer is erroneous and would instead proceed as if the decl was not const,
which is the approach that this patch takes.

Passes 'make check-c++', does this look OK to commit after full bootstrap and
regtest?

gcc/cp/ChangeLog:

PR c++/94475
* cvt.c (ocp_convert): If the result of scalar_constant_value is
erroneous, discard it and carry on with the original expression.

gcc/testsuite/ChangeLog:

PR c++/94475
* g++.dg/conversion/err-recover2.C: New test.
* g++.dg/diagnostic/pr84138.C: Remove now-bogus warning.
* g++.dg/warn/Wsign-compare-8.C: Remove now-bogus warning.
---
 gcc/cp/cvt.c   |  6 +++---
 gcc/testsuite/g++.dg/conversion/err-recover2.C | 10 ++
 gcc/testsuite/g++.dg/diagnostic/pr84138.C  |  2 +-
 gcc/testsuite/g++.dg/warn/Wsign-compare-8.C|  2 +-
 4 files changed, 15 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/conversion/err-recover2.C

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index a3b80968b33..b94231a6d08 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -723,10 +723,10 @@ ocp_convert (tree type, tree expr, int convtype, int 
flags,
   if (!CLASS_TYPE_P (type))
 {
   e = mark_rvalue_use (e);
-  e = scalar_constant_value (e);
+  tree v = scalar_constant_value (e);
+  if (!error_operand_p (v))
+   e = v;
 }
-  if (error_operand_p (e))
-return error_mark_node;
 
   if (NULLPTR_TYPE_P (type) && null_ptr_cst_p (e))
 {
diff --git a/gcc/testsuite/g++.dg/conversion/err-recover2.C 
b/gcc/testsuite/g++.dg/conversion/err-recover2.C
new file mode 100644
index 000..437e1a919ea
--- /dev/null
+++ b/gcc/testsuite/g++.dg/conversion/err-recover2.C
@@ -0,0 +1,10 @@
+// PR c++/94475
+// { dg-do compile }
+
+unsigned char
+sr ()
+{
+  const unsigned char xz = EI; // { dg-error "not declared" }
+
+  return xz - (xz >> 1);
+}
diff --git a/gcc/testsuite/g++.dg/diagnostic/pr84138.C 
b/gcc/testsuite/g++.dg/diagnostic/pr84138.C
index 5c48b9b164a..00352306a56 100644
--- a/gcc/testsuite/g++.dg/diagnostic/pr84138.C
+++ b/gcc/testsuite/g++.dg/diagnostic/pr84138.C
@@ -5,4 +5,4 @@ foo()
 {
   const int i = 0 = 0; // { dg-error "lvalue required as left operand" }
   return 1 ? 0 : (char)i;
-} // { dg-warning "control reaches" }
+}
diff --git a/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C 
b/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
index 237ba84d526..4d2688157fc 100644
--- a/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
+++ b/gcc/testsuite/g++.dg/warn/Wsign-compare-8.C
@@ -5,4 +5,4 @@ bool foo (char c)
 {
   const int i = 0 = 0; // { dg-error "lvalue" }
   return c = i;
-} // { dg-warning "control reaches" }
+}
-- 
2.26.1.107.gefe3874640

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

[Patrick Palka via Gcc-patches]

On Wed, 15 Apr 2020, Martin Sebor via Gcc-patches wrote:
> On 4/13/20 8:43 PM, Jason Merrill wrote:
> > On 4/12/20 5:49 PM, Martin Sebor wrote:
> > > On 4/10/20 8:52 AM, Jason Merrill wrote:
> > > > On 4/9/20 4:23 PM, Martin Sebor wrote:
> > > > > On 4/9/20 1:32 PM, Jason Merrill wrote:
> > > > > > On 4/9/20 3:24 PM, Martin Sebor wrote:
> > > > > > > On 4/9/20 1:03 PM, Jason Merrill wrote:
> > > > > > > > On 4/8/20 1:23 PM, Martin Sebor wrote:
> > > > > > > > > On 4/7/20 3:36 PM, Marek Polacek wrote:
> > > > > > > > > > On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor
> > > > > > > > > > wrote:
> > > > > > > > > > > On 4/7/20 1:50 PM, Marek Polacek wrote:
> > > > > > > > > > > > On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor
> > > > > > > > > > > > via Gcc-patches wrote:
> > > > > > > > > > > > > Among the numerous regressions introduced by the
> > > > > > > > > > > > > change committed
> > > > > > > > > > > > > to GCC 9 to allow string literals as template
> > > > > > > > > > > > > arguments is a failure
> > > > > > > > > > > > > to recognize the C++ nullptr and GCC's __null
> > > > > > > > > > > > > constants as pointers.
> > > > > > > > > > > > > For one, I didn't realize that nullptr, being a null
> > > > > > > > > > > > > pointer constant,
> > > > > > > > > > > > > doesn't have a pointer type, and two, I didn't think
> > > > > > > > > > > > > of __null (which
> > > > > > > > > > > > > is a special integer constant that NULL sometimes
> > > > > > > > > > > > > expands to).
> > > > > > > > > > > > > 
> > > > > > > > > > > > > The attached patch adjusts the special handling of
> > > > > > > > > > > > > trailing zero
> > > > > > > > > > > > > initializers in reshape_init_array_1 to recognize both
> > > > > > > > > > > > > kinds of
> > > > > > > > > > > > > constants and avoid treating them as zeros of the
> > > > > > > > > > > > > array integer
> > > > > > > > > > > > > element type.  This restores the expected diagnostics
> > > > > > > > > > > > > when either
> > > > > > > > > > > > > constant is used in the initializer list.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Martin
> > > > > > > > > > > > 
> > > > > > > > > > > > > PR c++/94510 - nullptr_t implicitly cast to zero twice
> > > > > > > > > > > > > in std::array
> > > > > > > > > > > > > 
> > > > > > > > > > > > > gcc/cp/ChangeLog:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > PR c++/94510
> > > > > > > > > > > > > * decl.c (reshape_init_array_1): Exclude
> > > > > > > > > > > > > mismatches with all kinds
> > > > > > > > > > > > > of pointers.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > gcc/testsuite/ChangeLog:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > PR c++/94510
> > > > > > > > > > > > > * g++.dg/init/array57.C: New test.
> > > > > > > > > > > > > * g++.dg/init/array58.C: New test.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> > > > > > > > > > > > > index a127734af69..692c8ed73f4 100644
> > > > > > > > > > > > > --- a/gcc/cp/decl.c
> > > > > > > > > > > > > +++ b/gcc/cp/decl.c
> > > > > > > > > > > > > @@ -6041,9 +6041,14 @@ reshape_init_array_1 (tree
> > > > > > > > > > > > > elt_type, tree max_index, reshape_iter *d,
> > > > > > > > > > > > >    TREE_CONSTANT (new_init) = false;
> > > > > > > > > > > > >  /* Pointers initialized to strings must be
> > > > > > > > > > > > > treated as non-zero
> > > > > > > > > > > > > - even if the string is empty.  */
> > > > > > > > > > > > > + even if the string is empty.  Handle all kinds
> > > > > > > > > > > > > of pointers,
> > > > > > > > > > > > > + including std::nullptr and GCC's __nullptr,
> > > > > > > > > > > > > neither of which
> > > > > > > > > > > > > + has a pointer type.  */
> > > > > > > > > > > > >  tree init_type = TREE_TYPE (elt_init);
> > > > > > > > > > > > > -  if (POINTER_TYPE_P (elt_type) != POINTER_TYPE_P
> > > > > > > > > > > > > (init_type)
> > > > > > > > > > > > > +  bool init_is_ptr = (POINTER_TYPE_P (init_type)
> > > > > > > > > > > > > +  || NULLPTR_TYPE_P (init_type)
> > > > > > > > > > > > > +  || null_node_p (elt_init));
> > > > > > > > > > > > > +  if (POINTER_TYPE_P (elt_type) != init_is_ptr
> > > > > > > > > > > > >  || !type_initializer_zero_p (elt_type,
> > > > > > > > > > > > > elt_init))
> > > > > > > > > > > > >    last_nonzero = index;
> > > > > > > > > > > > 
> > > > > > > > > > > > It looks like this still won't handle e.g. pointers to
> > > > > > > > > > > > member functions,
> > > > > > > > > > > > e.g.
> > > > > > > > > > > > 
> > > > > > > > > > > > struct S { };
> > > > > > > > > > > > int arr[3] = { (void (S::*) ()) 0, 0, 0 };
> > > > > > > > > > > > 
> > > > > > > > > > > > would still be accepted.  You could use
> > > > > > > > > > > > TYPE_PTR_OR_PTRMEM_P instead of
> > > > > > > > > > > > POINTER_TYPE_P to catch this case.
> > > > > > > > > 

[committed] libstdc++: Add comparison operators to types from Utilities clause

[Jonathan Wakely via Gcc-patches]

Some more C++20 changes from P1614R2, "The Mothership has Landed".

This removes all redundant equality and inequality operators in the
Utilities clause, as they can be synthesized from the remaining equality
operators.

It also removes the single redundant operator in the Localization
clause, because it didn't seem worth doing in a separate commit.

* include/bits/allocator.h (operator!=): Do not define for C++20.
* include/bits/locale_classes.h (operator!=): Likewise.
* include/bits/std_function.h (operator==(nullptr_t, const function&))
(operator!=(const function&, nullptr_t))
(operator!=(nullptr_t, const function&)): Likewise.
* include/ext/bitmap_allocator.h (operator!=): Likewise.
* include/ext/debug_allocator.h (operator!=): Likewise.
* include/ext/extptr_allocator.h (operator!=): Likewise.
* include/ext/malloc_allocator.h (operator!=): Likewise.
* include/ext/mt_allocator.h (operator!=): Likewise.
* include/ext/new_allocator.h (operator!=): Likewise.
* include/ext/pool_allocator.h (operator!=): Likewise.
* include/ext/throw_allocator.h (operator!=): Likewise.
* include/std/bitset (bitset::operator!=): Likewise.
* include/std/memory_resource (operator!=): Likewise.
* include/std/scoped_allocator (operator!=): Likewise.

Tested powerpc64le-linux, committed to master.

commit 596676d66cab21e5ed85669e737af5b62f067d57
Author: Jonathan Wakely 
Date:   Wed Apr 15 19:47:48 2020 +0100

libstdc++: Add comparison operators to types from Utilities clause

Some more C++20 changes from P1614R2, "The Mothership has Landed".

This removes all redundant equality and inequality operators in the
Utilities clause, as they can be synthesized from the remaining equality
operators.

It also removes the single redundant operator in the Localization
clause, because it didn't seem worth doing in a separate commit.

* include/bits/allocator.h (operator!=): Do not define for C++20.
* include/bits/locale_classes.h (operator!=): Likewise.
* include/bits/std_function.h (operator==(nullptr_t, const 
function&))
(operator!=(const function&, nullptr_t))
(operator!=(nullptr_t, const function&)): Likewise.
* include/ext/bitmap_allocator.h (operator!=): Likewise.
* include/ext/debug_allocator.h (operator!=): Likewise.
* include/ext/extptr_allocator.h (operator!=): Likewise.
* include/ext/malloc_allocator.h (operator!=): Likewise.
* include/ext/mt_allocator.h (operator!=): Likewise.
* include/ext/new_allocator.h (operator!=): Likewise.
* include/ext/pool_allocator.h (operator!=): Likewise.
* include/ext/throw_allocator.h (operator!=): Likewise.
* include/std/bitset (bitset::operator!=): Likewise.
* include/std/memory_resource (operator!=): Likewise.
* include/std/scoped_allocator (operator!=): Likewise.

diff --git a/libstdc++-v3/include/bits/allocator.h 
b/libstdc++-v3/include/bits/allocator.h
index 3e0d608aa6b..ee564791dfa 100644
--- a/libstdc++-v3/include/bits/allocator.h
+++ b/libstdc++-v3/include/bits/allocator.h
@@ -196,9 +196,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   operator==(const allocator&, const allocator&) _GLIBCXX_NOTHROW
   { return true; }
 
+#if __cpp_impl_three_way_comparison < 201907L
   friend _GLIBCXX20_CONSTEXPR bool
   operator!=(const allocator&, const allocator&) _GLIBCXX_NOTHROW
   { return false; }
+#endif
 
   // Inherit everything else.
 };
@@ -209,11 +211,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 _GLIBCXX_NOTHROW
 { return true; }
 
+#if __cpp_impl_three_way_comparison < 201907L
   template
 inline _GLIBCXX20_CONSTEXPR bool
 operator!=(const allocator<_T1>&, const allocator<_T2>&)
 _GLIBCXX_NOTHROW
 { return false; }
+#endif
 
   // Invalid allocator partial specializations.
   // allocator_traits::rebind_alloc can be used to form a valid allocator type.
diff --git a/libstdc++-v3/include/bits/locale_classes.h 
b/libstdc++-v3/include/bits/locale_classes.h
index 11b3dcd..ab90682cde2 100644
--- a/libstdc++-v3/include/bits/locale_classes.h
+++ b/libstdc++-v3/include/bits/locale_classes.h
@@ -254,6 +254,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 bool
 operator==(const locale& __other) const throw();
 
+#if __cpp_impl_three_way_comparison < 201907L
 /**
  *  @brief  Locale inequality.
  *
@@ -263,6 +264,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 bool
 operator!=(const locale& __other) const throw()
 { return !(this->operator==(__other)); }
+#endif
 
 /**
  *  @brief  Compare two strings according to collate.
diff --git a/libstdc++-v3/include/bits/std_function.h 
b/libstdc++-v3/include/bits/std_function.h
index 57375b5de0c..e2bf9b91850 100644
--- 

[committed] libstdc++: Add spaceship operator to std::type_index

[Jonathan Wakely via Gcc-patches]

Another C++20 change from P1614R2, "The Mothership has Landed".

* include/std/typeindex (operator<=>): Define for C++20.
* testsuite/20_util/typeindex/comparison_operators_c++20.cc: New test.

Tested powerpc64le-linux, committed to master.


commit 4714fd14afadbfdab0cc76a8b3fdf7a8161e0ebe
Author: Jonathan Wakely 
Date:   Wed Apr 15 19:47:47 2020 +0100

libstdc++: Add spaceship operator to std::type_index

Another C++20 change from P1614R2, "The Mothership has Landed".

* include/std/typeindex (operator<=>): Define for C++20.
* testsuite/20_util/typeindex/comparison_operators_c++20.cc: New 
test.

diff --git a/libstdc++-v3/include/std/typeindex 
b/libstdc++-v3/include/std/typeindex
index 8582c50b954..b4539f18ca0 100644
--- a/libstdc++-v3/include/std/typeindex
+++ b/libstdc++-v3/include/std/typeindex
@@ -36,6 +36,9 @@
 #else
 
 #include 
+#if __cplusplus > 201703L
+# include 
+#endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -58,9 +61,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 operator==(const type_index& __rhs) const noexcept
 { return *_M_target == *__rhs._M_target; }
 
+#if ! __cpp_lib_three_way_comparison
 bool
 operator!=(const type_index& __rhs) const noexcept
 { return *_M_target != *__rhs._M_target; }
+#endif
 
 bool
 operator<(const type_index& __rhs) const noexcept
@@ -78,6 +83,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 operator>=(const type_index& __rhs) const noexcept
 { return !_M_target->before(*__rhs._M_target); }
 
+#if __cpp_lib_three_way_comparison
+strong_ordering
+operator<=>(const type_index& __rhs) const noexcept
+{
+  if (*_M_target == *__rhs._M_target)
+   return strong_ordering::equal;
+  if (_M_target->before(*__rhs._M_target))
+   return strong_ordering::less;
+  return strong_ordering::greater;
+}
+#endif
+
 size_t
 hash_code() const noexcept
 { return _M_target->hash_code(); }
diff --git 
a/libstdc++-v3/testsuite/20_util/typeindex/comparison_operators_c++20.cc 
b/libstdc++-v3/testsuite/20_util/typeindex/comparison_operators_c++20.cc
new file mode 100644
index 000..27598c690c5
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/typeindex/comparison_operators_c++20.cc
@@ -0,0 +1,50 @@
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+
+void test01()
+{
+  class Abraca { };
+  Abraca a1, a2_;
+  const Abraca a2 = a2_;
+
+  const std::type_index arr[] = {
+typeid(int), typeid(double), typeid(Abraca), typeid(const Abraca),
+typeid(const Abraca&), typeid(a1), typeid(a2)
+  };
+
+  for (const std::type_index& t1 : arr)
+for (const std::type_index& t2 : arr)
+{
+  VERIFY( (t1 == t2) == std::is_eq(t1 <=> t2) );
+  VERIFY( (t1 != t2) == std::is_neq(t1 <=> t2) );
+  VERIFY( (t1 < t2) == std::is_lt(t1 <=> t2) );
+  VERIFY( (t1 > t2) == std::is_gt(t1 <=> t2) );
+  VERIFY( (t1 <= t2) == std::is_lteq(t1 <=> t2) );
+  VERIFY( (t1 >= t2) == std::is_gteq(t1 <=> t2) );
+}
+}
+
+int main()
+{
+  test01();
+}

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

[Fritz Reese via Gcc-patches]

On Wed, Apr 15, 2020 at 1:47 PM Thomas Koenig  wrote:
>
> Hi Fritz,
>
> > While you're touching the code anyway, how would you feel about
> > replacing the nearby "goto done"s with a chain of "else if"? There's
> > really no reason I can see for goto here, since the block following
> > the conditions is already "done".
>
> I think this would really be pushing things at stage 4.  Theoretically,
> we are expected to do regression and documentation fixes only.
> Since Fortran is not release critical, we are welcome to break
> our compiler if we want to :-) but we should really try to
> restrict outselves at least a little. The little cleanup that I proposed
> is also borderline (but maybe a little less so), so I'd rather commit
> as I proposed.
>
> Any other comments?  If not, I'll commit in a couple of days.
[...]

Fair enough. No further comments, that patch looks good. Thanks!

---
Fritz

Re: [PATCH] sra: Fix access verification (PR 94598)

[Richard Biener]

On Wed, 15 Apr 2020, Martin Jambor wrote:

> Hi,
> 
> get_ref_base_and_extent recognizes ARRAY_REFs with variable index but
> into arrays of length one as constant offset accesses.  However,
> max_size in such cases is extended to span the whole element.

You mean f[d] gets offset zero and max_size == sizeof (struct a)?
Or f[d].b doing this, thus size != max_size?

> This confuses SRA verification when SRA also builds its (total
> scalarization) access structures to describe fields under such array -
> get_ref_base_and_extent returns different size and max_size for them.
> 
> Fixed by not performing the check for total scalarization accesses.
> The subsequent check then had to be changed to use size and not
> max_size too, which meant it has to be skipped when the access
> structure describes a genuine variable array access.
> 
> Bootstrapped and tested on x86_64-linux.
> 
> OK for trunk?

OK.

Richard.

> Thanks,
> 
> Martin
> 
> 
> 2020-04-15  Martin Jambor  
> 
>   PR tree-optimization/94598
>   * tree-sra.c (verify_sra_access_forest): Fix verification of total
>   scalarization accesses under access to one-element arrays.
> 
>   testsuite/
>   * gcc.dg/tree-ssa/pr94598.c: New test.
> ---
>  gcc/ChangeLog   |  6 ++
>  gcc/testsuite/ChangeLog |  5 +
>  gcc/testsuite/gcc.dg/tree-ssa/pr94598.c | 26 +
>  gcc/tree-sra.c  |  6 --
>  4 files changed, 41 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr94598.c
> 
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr94598.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr94598.c
> new file mode 100644
> index 000..a18a796aa0a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr94598.c
> @@ -0,0 +1,26 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O1" } */
> +
> +struct a {
> +  int b;
> +  short c;
> +};
> +int d;
> +void e() {
> +  struct a f[1];
> +  f[d] = f[d];
> +}
> +
> +struct S {
> +  int a[30];
> +  int c;
> +};
> +
> +int get_int (void);
> +
> +int foo(struct S p)
> +{
> +  p.c = get_int ();
> +  p.a[get_int()] = get_int()+1;
> +  return p.c;
> +}
> diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
> index 84c113c403c..227bde06257 100644
> --- a/gcc/tree-sra.c
> +++ b/gcc/tree-sra.c
> @@ -2357,9 +2357,11 @@ verify_sra_access_forest (struct access *root)
>gcc_assert (base == first_base);
>gcc_assert (offset == access->offset);
>gcc_assert (access->grp_unscalarizable_region
> +   || access->grp_total_scalarization
> || size == max_size);
> -  gcc_assert (!is_gimple_reg_type (access->type)
> -   || max_size == access->size);
> +  gcc_assert (access->grp_unscalarizable_region
> +   || !is_gimple_reg_type (access->type)
> +   || size == access->size);
>gcc_assert (reverse == access->reverse);
>  
>if (access->first_child)
> 

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

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

[Thomas Koenig via Gcc-patches]

Hi Fritz,


While you're touching the code anyway, how would you feel about
replacing the nearby "goto done"s with a chain of "else if"? There's
really no reason I can see for goto here, since the block following
the conditions is already "done".


I think this would really be pushing things at stage 4.  Theoretically,
we are expected to do regression and documentation fixes only.
Since Fortran is not release critical, we are welcome to break
our compiler if we want to :-) but we should really try to
restrict outselves at least a little. The little cleanup that I proposed
is also borderline (but maybe a little less so), so I'd rather commit
as I proposed.

Any other comments?  If not, I'll commit in a couple of days.

(At least one thing that came out of this whole virus affair -
instead of walking in the Highlands, I now have more time stuff
hacking gfortran).

Regards

Thomas

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

[Martin Sebor via Gcc-patches]

On 4/13/20 8:43 PM, Jason Merrill wrote:

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

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

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

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

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

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

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

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

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

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

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

The attached patch adjusts the special handling of trailing 
zero

initializers in reshape_init_array_1 to recognize both kinds of
constants and avoid treating them as zeros of the array integer
element type.  This restores the expected diagnostics when 
either

constant is used in the initializer list.

Martin


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


gcc/cp/ChangeLog:

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

of pointers.

gcc/testsuite/ChangeLog:

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

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

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

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

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

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


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

e.g.

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

would still be accepted.  You could use TYPE_PTR_OR_PTRMEM_P 
instead of

POINTER_TYPE_P to catch this case.


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

as a zero.

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

or should I add one like in the attached update?

Martin


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


gcc/cp/ChangeLog:

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

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


(Drop the gcc/cp/.)

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

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


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

not just a pointer?


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

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

of IMO unintuitive conditions:

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

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

come close to it.

Since null_pointer_constant_p already exists (but isn't suitable 
here

because it returns true for plain literal zeros)


Why is that unsuitable?  A literal zero is a perfectly good 

Re: ICE on wrong code [PR94192] commit

[Fritz Reese via Gcc-patches]

On Tue, Apr 14, 2020 at 7:54 AM Linus König  wrote:
>
> Hi all,
>
> the PR has just recently been committed. Paul gave his offline approval.
> I only realized recently, that the NULL pointer check can actually be
> ommitted if the check is moved in the code. In the commit however, it is
> still right below the declaration. I believe both ways work fine. It is
> still possible to change it.
>
> Best regards,
>
> Linus König
>

I committed the simplified check. Thanks for your work, Linus.

---
Fritz

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

[Fritz Reese via Gcc-patches]

> Yes.  Looking back at the code, I think it can also be cleaned up
> a little - turning the error to warnings is only needed on that
> particular branch, and resetting it to the default can also
> happen there, and at the target of a goto statement.
>
> So, here's an updated patch.  OK for trunk?
>
> Regards
>
> Thomas

Looks great, thank you for the cleanup!

While you're touching the code anyway, how would you feel about
replacing the nearby "goto done"s with a chain of "else if"? There's
really no reason I can see for goto here, since the block following
the conditions is already "done". Here (and attached) is a diff on top
of your latest changes, in case you think it's appropriate:

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 2371ab23645..617e8d01a59 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -2511,6 +2511,7 @@ resolve_global_procedure (gfc_symbol *sym, locus
*where, int sub)
   gfc_namespace *ns;
   enum gfc_symbol_type type;
   char reason[200];
+  bool bad_result_characteristics;

   type = sub ? GSYM_SUBROUTINE : GSYM_FUNCTION;

@@ -2586,23 +2587,16 @@ resolve_global_procedure (gfc_symbol *sym,
locus *where, int sub)
 }

   if (sym->attr.function && !gfc_compare_types (>ts, _sym->ts))
-{
-  gfc_error ("Return type mismatch of function %qs at %L (%s/%s)",
- sym->name, >declared_at, gfc_typename (>ts),
- gfc_typename (_sym->ts));
-  goto done;
-}
+gfc_error ("Return type mismatch of function %qs at %L (%s/%s)",
+   sym->name, >declared_at, gfc_typename (>ts),
+   gfc_typename (_sym->ts));

-  if (sym->attr.if_source == IFSRC_UNKNOWN
+  else if (sym->attr.if_source == IFSRC_UNKNOWN
   && gfc_explicit_interface_required (def_sym, reason, sizeof(reason)))
-{
-  gfc_error ("Explicit interface required for %qs at %L: %s",
- sym->name, >declared_at, reason);
-  goto done;
-}
+gfc_error ("Explicit interface required for %qs at %L: %s",
+   sym->name, >declared_at, reason);

-  bool bad_result_characteristics;
-  if (!gfc_compare_interfaces (sym, def_sym, sym->name, 0, 1,
+  else if (!gfc_compare_interfaces (sym, def_sym, sym->name, 0, 1,
reason, sizeof(reason), NULL, NULL,
_result_characteristics))
 {
@@ -2617,12 +2611,9 @@ resolve_global_procedure (gfc_symbol *sym,
locus *where, int sub)
   gfc_error ("Interface mismatch in global procedure %qs at %L: %s",
  sym->name, >declared_at, reason);
   gfc_errors_to_warnings (false);
-  goto done;
 }
 }

-done:
-
   if (gsym->type == GSYM_UNKNOWN)
 {
   gsym->type = type;
---

Even if you don't want to include this, your patch LGTM. Thanks again.

---
Fritz Reese
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 2371ab23645..617e8d01a59 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -2511,6 +2511,7 @@ resolve_global_procedure (gfc_symbol *sym, locus *where, 
int sub)
   gfc_namespace *ns;
   enum gfc_symbol_type type;
   char reason[200];
+  bool bad_result_characteristics;
 
   type = sub ? GSYM_SUBROUTINE : GSYM_FUNCTION;
 
@@ -2586,23 +2587,16 @@ resolve_global_procedure (gfc_symbol *sym, locus 
*where, int sub)
}
 
   if (sym->attr.function && !gfc_compare_types (>ts, _sym->ts))
-   {
- gfc_error ("Return type mismatch of function %qs at %L (%s/%s)",
-sym->name, >declared_at, gfc_typename (>ts),
-gfc_typename (_sym->ts));
- goto done;
-   }
+   gfc_error ("Return type mismatch of function %qs at %L (%s/%s)",
+  sym->name, >declared_at, gfc_typename (>ts),
+  gfc_typename (_sym->ts));
 
-  if (sym->attr.if_source == IFSRC_UNKNOWN
+  else if (sym->attr.if_source == IFSRC_UNKNOWN
  && gfc_explicit_interface_required (def_sym, reason, sizeof(reason)))
-   {
- gfc_error ("Explicit interface required for %qs at %L: %s",
-sym->name, >declared_at, reason);
- goto done;
-   }
+   gfc_error ("Explicit interface required for %qs at %L: %s",
+  sym->name, >declared_at, reason);
 
-  bool bad_result_characteristics;
-  if (!gfc_compare_interfaces (sym, def_sym, sym->name, 0, 1,
+  else if (!gfc_compare_interfaces (sym, def_sym, sym->name, 0, 1,
   reason, sizeof(reason), NULL, NULL,
   _result_characteristics))
{
@@ -2617,12 +2611,9 @@ resolve_global_procedure (gfc_symbol *sym, locus *where, 
int sub)
  gfc_error ("Interface mismatch in global procedure %qs at %L: %s",
 sym->name, >declared_at, reason);
  gfc_errors_to_warnings (false);
- goto done;
}
 }
 
-done:
-
   if (gsym->type == GSYM_UNKNOWN)
 {
   gsym->type = type;

[PATCH] sra: Fix access verification (PR 94598)

[Martin Jambor]

Hi,

get_ref_base_and_extent recognizes ARRAY_REFs with variable index but
into arrays of length one as constant offset accesses.  However,
max_size in such cases is extended to span the whole element.  This
confuses SRA verification when SRA also builds its (total
scalarization) access structures to describe fields under such array -
get_ref_base_and_extent returns different size and max_size for them.

Fixed by not performing the check for total scalarization accesses.
The subsequent check then had to be changed to use size and not
max_size too, which meant it has to be skipped when the access
structure describes a genuine variable array access.

Bootstrapped and tested on x86_64-linux.

OK for trunk?

Thanks,

Martin


2020-04-15  Martin Jambor  

PR tree-optimization/94598
* tree-sra.c (verify_sra_access_forest): Fix verification of total
scalarization accesses under access to one-element arrays.

testsuite/
* gcc.dg/tree-ssa/pr94598.c: New test.
---
 gcc/ChangeLog   |  6 ++
 gcc/testsuite/ChangeLog |  5 +
 gcc/testsuite/gcc.dg/tree-ssa/pr94598.c | 26 +
 gcc/tree-sra.c  |  6 --
 4 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr94598.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr94598.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr94598.c
new file mode 100644
index 000..a18a796aa0a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr94598.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-O1" } */
+
+struct a {
+  int b;
+  short c;
+};
+int d;
+void e() {
+  struct a f[1];
+  f[d] = f[d];
+}
+
+struct S {
+  int a[30];
+  int c;
+};
+
+int get_int (void);
+
+int foo(struct S p)
+{
+  p.c = get_int ();
+  p.a[get_int()] = get_int()+1;
+  return p.c;
+}
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index 84c113c403c..227bde06257 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2357,9 +2357,11 @@ verify_sra_access_forest (struct access *root)
   gcc_assert (base == first_base);
   gcc_assert (offset == access->offset);
   gcc_assert (access->grp_unscalarizable_region
+ || access->grp_total_scalarization
  || size == max_size);
-  gcc_assert (!is_gimple_reg_type (access->type)
- || max_size == access->size);
+  gcc_assert (access->grp_unscalarizable_region
+ || !is_gimple_reg_type (access->type)
+ || size == access->size);
   gcc_assert (reverse == access->reverse);
 
   if (access->first_child)
-- 
2.26.0

Re: [PATCH] testsuite: Add check_effective_target_d_runtime_has_std_library procedure

[Rainer Orth]

Hi Richard,

> Iain Buclaw via Gcc-patches  writes:
>> Hi,
>>
>> This patch adds an effect target d_runtime_has_std_library to
>> target-supports.exp, and some preliminary uses of it.
>>
>> The current check_effective_target_d_runtime procedure returns false if
>> the target is without any core runtime library for D.  This additional
>> procedure is for targets where the core runtime library exists, but is
>> without the higher level standard D library.
>>
>> OK for master?
>
> OK.  FAOD though, D-related effective-target keywords are covered by the
> D frontend maintainership.

indeed.  However, they still need documenting in sourcebuild.texi.  Iain,
please do so before committing.

Thanks.
Rainer

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

Re: [PATCH] RTEMS: Improve GCC specification

[Jeff Law via Gcc-patches]

On Tue, 2020-04-14 at 17:26 +0200, Sebastian Huber wrote:
> Hello Jeff,
> 
> On 08/04/2020 22:24, Jeff Law wrote:
> 
> > On Wed, 2020-04-08 at 19:47 +0200, Sebastian Huber wrote:
> > > Add a start/end file specification if the -qrtems option is present.
> > > Allow targets to customize it.
> > > 
> > > Support the standard -nodefaultlibs option.
> > > 
> > > gcc/
> > > 
> > >   * config/rtems.h (RTEMS_STARTFILE_SPEC): Define if undefined.
> > >   (RTEMS_ENDFILE_SPEC): Likewise.
> > >   (STARTFILE_SPEC): Update comment.  Add RTEMS_STARTFILE_SPEC.
> > >   (ENDFILE_SPEC): Add RTEMS_ENDFILE_SPEC.
> > >   (LIB_SPECS): Support -nodefaultlibs option.
> > >   * config/or1k/rtems.h (RTEMS_STARTFILE_SPEC): Define.
> > >   (RTEMS_ENDFILE_SPEC): Likewise.
> > >   * config/rs6000/rtems.h (RTEMS_STARTFILE_SPEC): Likewise.
> > >   (RTEMS_ENDFILE_SPEC): Likewise.
> > >   * config/v850/rtems.h (RTEMS_STARTFILE_SPEC): Likewise.
> > >   (RTEMS_ENDFILE_SPEC): Likewise.
> > How important is it to get this into gcc-10?  We're well into stage4 at this
> > point and while we do have leeway with a patch like this we do want to be
> > selective about what we accept.
> > 
> > If it's important, then OK, otherwise please defer it to gcc-11, where it's
> > pre-
> > approved.
> would it be all right to commit it to the trunk once the GCC 11 
> development starts and then back port it for GCC 10.2 after a while?
That works for me.  It's not technically a regression, but I think some leeway 
is
reasonable.

jeff

Re: [PATCH] testsuite: Add check_effective_target_d_runtime_has_std_library procedure

[Richard Sandiford]

Iain Buclaw via Gcc-patches  writes:
> Hi,
>
> This patch adds an effect target d_runtime_has_std_library to
> target-supports.exp, and some preliminary uses of it.
>
> The current check_effective_target_d_runtime procedure returns false if
> the target is without any core runtime library for D.  This additional
> procedure is for targets where the core runtime library exists, but is
> without the higher level standard D library.
>
> OK for master?

OK.  FAOD though, D-related effective-target keywords are covered by the
D frontend maintainership.

Thanks,
Richard


>
> Regards
> Iain.
>
> ---
> gcc/testsuite/ChangeLog:
>
>   * gdc.dg/link.d: Use d_runtime_has_std_library effective target.
>   * gdc.dg/runnable.d: Move phobos tests to...
>   * gdc.dg/runnable2.d: ...here.  New test.
>   * lib/target-supports.exp
>   (check_effective_target_d_runtime_has_std_library): New.
>
> libphobos/ChangeLog:
>
>   * testsuite/libphobos.phobos/phobos.exp: Skip if effective target is
>   not d_runtime_has_std_library.
>   * testsuite/libphobos.phobos_shared/phobos_shared.exp: Likewise.
> ---
>  gcc/testsuite/gdc.dg/link.d   |   2 +-
>  gcc/testsuite/gdc.dg/runnable.d   | 229 
>  gcc/testsuite/gdc.dg/runnable2.d  | 244 ++
>  gcc/testsuite/lib/target-supports.exp |  15 ++
>  .../testsuite/libphobos.phobos/phobos.exp |   5 +
>  .../libphobos.phobos_shared/phobos_shared.exp |   5 +
>  6 files changed, 270 insertions(+), 230 deletions(-)
>  create mode 100644 gcc/testsuite/gdc.dg/runnable2.d
>
> diff --git a/gcc/testsuite/gdc.dg/link.d b/gcc/testsuite/gdc.dg/link.d
> index a8ca4ed5cb6..5efd0ad347f 100644
> --- a/gcc/testsuite/gdc.dg/link.d
> +++ b/gcc/testsuite/gdc.dg/link.d
> @@ -1,4 +1,4 @@
> -// { dg-do link { target d_runtime } }
> +// { dg-do link { target d_runtime_has_std_library } }
>  
>  /**/
>  
> diff --git a/gcc/testsuite/gdc.dg/runnable.d b/gcc/testsuite/gdc.dg/runnable.d
> index 484a9709bf3..7307e09a645 100644
> --- a/gcc/testsuite/gdc.dg/runnable.d
> +++ b/gcc/testsuite/gdc.dg/runnable.d
> @@ -9,20 +9,6 @@ import core.stdc.stdio;
>  import gcc.attribute;
>  
>  
> -/**/
> -// https://bugzilla.gdcproject.org/show_bug.cgi?id=2
> -
> -struct S
> -{
> -string toString() { return "foo"; }
> -}
> -
> -void test2()
> -{
> -import std.string : format;
> -assert(format("%s", S()) == "foo");
> -}
> -
>  /**/
>  // https://bugzilla.gdcproject.org/show_bug.cgi?id=4
>  
> @@ -33,35 +19,6 @@ void test4()
>  static assert(!__traits(compiles, str.sort));
>  }
>  
> -/**/
> -// https://bugzilla.gdcproject.org/show_bug.cgi?id=15
> -
> -class B
> -{
> -class A { }
> -A a;
> -}
> -
> -class C
> -{
> -void visit(B b)
> -{
> -import std.algorithm : map;
> -auto as = [b.a];
> -as.map!(d => d);
> -}
> -}
> -
> -/**/
> -// https://bugzilla.gdcproject.org/show_bug.cgi?id=16
> -
> -void test16()
> -{
> -import std.parallelism : taskPool;
> -
> -taskPool.reduce!"a+b"([0, 1, 2, 3]);
> -}
> -
>  /**/
>  // https://bugzilla.gdcproject.org/show_bug.cgi?id=17
>  
> @@ -99,59 +56,6 @@ void test17()
>(new ModuleWriter()).save ("test.0.mci");
>  }
>  
> -/**/
> -// https://bugzilla.gdcproject.org/show_bug.cgi?id=18
> -
> -class C18
> -{
> -struct Link
> -{
> -int x;
> -int y;
> -}
> -
> -void sort_links()
> -{
> -import std.algorithm : sort;
> -import std.array : empty;
> -import std.exception : enforce;
> -
> -enforce(!_link.empty);
> -
> -bool lt(Link a, Link b)
> -{
> -if(a.x > b.x)
> -return false;
> -if(a.x < b.x)
> -return true;
> -if(a.y >= b.y)
> -return false;
> -else
> -return true;
> -}
> -sort!(lt)(_link);
> -}
> -
> -this()
> -{
> -_link ~= Link(8, 3);
> -_link ~= Link(4, 7);
> -_link ~= Link(4, 6);
> -_link ~= Link(3, 7);
> -_link ~= Link(2, 7);
> -_link ~= Link(2, 2);
> -_link ~= Link(4, 1);
> -}
> -
> -Link[] _link;
> -}
> -
> -void test18()
> -{
> -C18 foo = new C18;
> -foo.sort_links();
> -}
> -
>  /**/
>  // https://bugzilla.gdcproject.org/show_bug.cgi?id=19
>  
> @@ -177,22 +81,6 @@ void test24()
>  return;
>  }
>  
> -/**/
> -// https://bugzilla.gdcproject.org/show_bug.cgi?id=29
> -
> -void test29()
> -{
> -import std.string : format;
> -import std.conv : text;
> -
> -string 

i386: Require OPTION_MASK_ISA_SSE2 for __builtin_ia32_movq128 [PR94603]

[Uros Bizjak via Gcc-patches]

2020-04-15  Uroš Bizjak  

PR target/94603
* config/i386/i386-builtin.def (__builtin_ia32_movq128):
Require OPTION_MASK_ISA_SSE2.

testsuite/ChangeLog:

2020-04-15  Uroš Bizjak  

PR target/94603
* gcc.target/i386/pr94603.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline, will be backported to release branches.

Uros.
diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index bae561bc7f4..4d5863ce0aa 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -811,7 +811,7 @@ BDESC (OPTION_MASK_ISA_SSE2, 0, CODE_FOR_sse2_pshufhw, 
"__builtin_ia32_pshufhw",
 
 BDESC (OPTION_MASK_ISA_SSE2, 0, CODE_FOR_sse2_vmsqrtv2df2, 
"__builtin_ia32_sqrtsd", IX86_BUILTIN_SQRTSD, UNKNOWN, (int) 
V2DF_FTYPE_V2DF_VEC_MERGE)
 
-BDESC (OPTION_MASK_ISA_SSE, 0, CODE_FOR_sse2_movq128, 
"__builtin_ia32_movq128", IX86_BUILTIN_MOVQ128, UNKNOWN, (int) V2DI_FTYPE_V2DI)
+BDESC (OPTION_MASK_ISA_SSE2, 0, CODE_FOR_sse2_movq128, 
"__builtin_ia32_movq128", IX86_BUILTIN_MOVQ128, UNKNOWN, (int) V2DI_FTYPE_V2DI)
 
 /* SSE2 MMX */
 BDESC (OPTION_MASK_ISA_SSE2 | OPTION_MASK_ISA_MMX, 0, CODE_FOR_mmx_addv1di3, 
"__builtin_ia32_paddq", IX86_BUILTIN_PADDQ, UNKNOWN, (int) V1DI_FTYPE_V1DI_V1DI)
diff --git a/gcc/testsuite/gcc.target/i386/pr94603.c 
b/gcc/testsuite/gcc.target/i386/pr94603.c
new file mode 100644
index 000..34a1e069eac
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr94603.c
@@ -0,0 +1,11 @@
+/* PR target/94603 */
+/* { dg-do compile } */
+/* { dg-options "-Wno-implicit-function-declaration -msse -mno-sse2" } */
+
+typedef long long __attribute__ ((__vector_size__ (16))) V;
+
+V
+foo (V v)
+{
+  return __builtin_ia32_movq128 (v);  /* { dg-error "" } */
+}

Re: [PATCH] pretty-print SSA names

[David Malcolm via Gcc-patches]

On Wed, 2020-04-15 at 14:52 +0200, Richard Biener wrote:
> This adds the SSA name version to the gdb pretty-printing of SSA
> names.
> 
> (gdb) p (tree)$1
> $5 = 
> 
> Tested (see above...).
> 
> OK?

> Thanks,
> Richard.
> 
> 2020-04-15  Richard Biener  
> 
>   * gdbhooks.py (TreePrinter): Print SSA_NAME_VERSION of SSA_NAME
>   nodes.
> ---
>  gcc/gdbhooks.py | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
> index e9acc373126..f6aef9ceae8 100644
> --- a/gcc/gdbhooks.py
> +++ b/gcc/gdbhooks.py
> @@ -154,6 +154,7 @@ tree_code_dict =
> gdb.types.make_enum_dict(gdb.lookup_type('enum tree_code'))
>  # ...and look up specific values for use later:
>  IDENTIFIER_NODE = tree_code_dict['IDENTIFIER_NODE']
>  TYPE_DECL = tree_code_dict['TYPE_DECL']
> +SSA_NAME = tree_code_dict['SSA_NAME']
>  
>  # Similarly for "enum tree_code_class" (tree.h):
>  tree_code_class_dict =
> gdb.types.make_enum_dict(gdb.lookup_type('enum tree_code_class'))
> @@ -252,6 +253,8 @@ class TreePrinter:
>  result += ' %s' %
> tree_TYPE_NAME.DECL_NAME().IDENTIFIER_POINTER()
>  if self.node.TREE_CODE() == IDENTIFIER_NODE:
>  result += ' %s' % self.node.IDENTIFIER_POINTER()
> + if self.node.TREE_CODE() == SSA_NAME:
> + result += ' %u' % self.gdbval['base']['u']['version']

Make it an "elif" rather than a plain "if" as the TREE_CODEs are
mutually exclusive (and the language doesn't have switch statements).

Is something up with the indentation?  The "if" ("elif") for SSA_NAME
should have the same indentation as the "if" for IDENTIFIER_NODE.  Is
there a stray tab or similar?

Otherwise, LGTM.


>  # etc
>  result += '>'
>  return result

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

[Jakub Jelinek via Gcc-patches]

On Tue, Apr 07, 2020 at 11:12:48PM -0400, Gustavo Romero via Gcc-patches wrote:
> Currently an use of get() method of dump_context singleton in optinfo
> framework causes a new class to be instantiated and when its dtor
> is called it calls delete on uninitialized data, causing an ICE.

To be precise, there is nothing wrong in the code, dump_context ()
is value initialization which should zero initialize the whole temporary.
It is only because GCC 4.2 is buggy, see PR33916, that it doesn't do that.

There is no reason to value-initialize anything in this case though, so
your patch works around the GCC 4.2 bug by doing the right thing.

I've fixed your ChangeLog entry (both that there is no : in between filename
and ( and to adjust the comment on what changed, because Fix ctor implies
that there was a bug in the code, which is not the case here
and committed to trunk for you.

Thanks.

Jakub

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

[Richard Earnshaw]

On 13/04/2020 21:40, Wilco Dijkstra wrote:
> Hi Duanbo,
> 
>> This is a simple fix for pr94577.
>> The option -mabi=ilp32 should not be used in large code model. Like x86, 
>> using -mx32 and -mcmodel=large together will result in an error message.
>> On aarch64, there is no error message for this option conflict.
>> A solution to this problem can be found in the attached patch.
>> Bootstrap and tested on aarch64 Linux platform. No new regression witnessed.
>> Any suggestion?  
> 
> Thanks for your patch, more than 4GB doesn't make any sense with ILP32 indeed.
> A few suggestions:
> 
> It would be good to also update the documentation for -mcmodel=large to state 
> it is
> incompatible with -fpic, -fPIC and -mabi=ilp32.
> 
> The patch adds a another switch statement on mcmodel that ignores the previous
> processing done (which may changes the selected mcmodel). It would be safer 
> and
> more concise to use one switch at the top level and in each case use an if 
> statement
> to handle the special cases.
> 
> A few minor nitpics:
> 
> +   PR  target/94577
> +   * gcc.target/aarch64/pr94577.c : New test
> 
> Just like comments, there should be a '.' at the end of changelog entries.
> 
> AFAICT the format isn't exactly specified, but the email header should be 
> like:
> 
> [PATCH][AArch64] PR94577: Add an error message in large code model for ilp32

No.  See https://gcc.gnu.org/contribute.html#patches.  Specifically the
section on email subject lines.

R.

> 
> Sometimes the PR number is also placed in brackets.
> 
> Cheers,
> Wilco
> 
> 

Re: [PATCH V2]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

[Andrea Corallo]

Kyrylo Tkachov  writes:

> Hi Andrea,
>
>> -Original Message-
>> From: Andrea Corallo 
>> Sent: 15 April 2020 09:47
>> To: Kyrylo Tkachov 
>> Cc: nd ; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH V2]aarch64: falkor-tag-collision-avoidance.c fix
>> valid_src_p for use of uninitialized value
>>
>> Hi all,
>>
>> Second version of this addressing comments.
>>
>> Bootstraped on aarch64 and regressioned.  Okay for trunk?
>
> Ok.
> Thanks,
> Kyrill

Thanks pushed as 8a4436d89bfa.

Preparing the backport for gcc-9.

  Andrea

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

[duanbo (C)]

Thank you for your suggestions.
I have modified accordingly and a full test has been carried, no new failure 
witnessed.  
Attached please find the new patch which has been adjusted to be suitable for 
git am. 
Does the v2 patch look better ?

Thanks,
Duan bo

-Original Message-
From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com] 
Sent: Tuesday, April 14, 2020 4:40 AM
To: GCC Patches ; duanbo (C) 
Subject: Re: [PATCH PR2] aarch64：Add an error message in large code model 
for ilp32

Hi Duanbo,

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

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

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

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

A few minor nitpics:

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

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

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

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

Sometimes the PR number is also placed in brackets.

Cheers,
Wilco




pr94577-v2.patch
Description: pr94577-v2.patch

[PATCH] pretty-print SSA names

[Richard Biener]

This adds the SSA name version to the gdb pretty-printing of SSA names.

(gdb) p (tree)$1
$5 = 

Tested (see above...).

OK?

Thanks,
Richard.

2020-04-15  Richard Biener  

* gdbhooks.py (TreePrinter): Print SSA_NAME_VERSION of SSA_NAME
nodes.
---
 gcc/gdbhooks.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
index e9acc373126..f6aef9ceae8 100644
--- a/gcc/gdbhooks.py
+++ b/gcc/gdbhooks.py
@@ -154,6 +154,7 @@ tree_code_dict = 
gdb.types.make_enum_dict(gdb.lookup_type('enum tree_code'))
 # ...and look up specific values for use later:
 IDENTIFIER_NODE = tree_code_dict['IDENTIFIER_NODE']
 TYPE_DECL = tree_code_dict['TYPE_DECL']
+SSA_NAME = tree_code_dict['SSA_NAME']
 
 # Similarly for "enum tree_code_class" (tree.h):
 tree_code_class_dict = gdb.types.make_enum_dict(gdb.lookup_type('enum 
tree_code_class'))
@@ -252,6 +253,8 @@ class TreePrinter:
 result += ' %s' % 
tree_TYPE_NAME.DECL_NAME().IDENTIFIER_POINTER()
 if self.node.TREE_CODE() == IDENTIFIER_NODE:
 result += ' %s' % self.node.IDENTIFIER_POINTER()
+   if self.node.TREE_CODE() == SSA_NAME:
+   result += ' %u' % self.gdbval['base']['u']['version']
 # etc
 result += '>'
 return result
-- 
2.13.7

RE: [PATCH V2]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

[Kyrylo Tkachov]

Hi Andrea,

> -Original Message-
> From: Andrea Corallo 
> Sent: 15 April 2020 09:47
> To: Kyrylo Tkachov 
> Cc: nd ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH V2]aarch64: falkor-tag-collision-avoidance.c fix
> valid_src_p for use of uninitialized value
> 
> Hi all,
> 
> Second version of this addressing comments.
> 
> Bootstraped on aarch64 and regressioned.  Okay for trunk?

Ok.
Thanks,
Kyrill

> 
> Andrea
> 
> gcc/ChangeLog
> 
> 2020-??-??  Andrea Corallo  
> 
>   * config/aarch64/falkor-tag-collision-avoidance.c
>   (valid_src_p): Check for aarch64_address_info type before
>   accessing base field.

RE: [Arm] Disallow arm_movdi when targetting MVE

[Kyrylo Tkachov]

> -Original Message-
> From: Matthew Malcomson 
> Sent: 15 April 2020 11:23
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; nd 
> Subject: [Arm] Disallow arm_movdi when targetting MVE
> 
> Without disabling this, the pattern can try and move DImode values
> between floating point registers and general registers.
> The constraints on this pattern can't handle that, and reload goes into
> an infinite loop.
> 
> This was the cause of a testsuite failure in cde_v_1_mve.c, which is now
> gone.
> 
> A DImode move for MVE now uses the `movdi_vfp` pattern, which is the
> same
> pattern used for such a move when MVE is not available but the target has
> TARGET_HARD_FLOAT.
> 

Ok.
Thanks,
Kyrill

> Testing done:
> Bootstrapped and regtested on arm-none-linux-gnueabihf
> regtested on arm-none-eabi
> 
> gcc/ChangeLog:
> 
> 2020-04-15  Matthew Malcomson  
> 
>   * config/arm/arm.md (arm_movdi): Disallow for MVE.
> 
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
> index
> 7bc55cce61b2e45e5875a233dd4546d59399d749..a6a31f8f4ef8d3c8c96c61b4
> 50dbd7c28d08b55c 100644
> --- a/gcc/config/arm/arm.md
> +++ b/gcc/config/arm/arm.md
> @@ -6233,6 +6233,7 @@
>   (match_operand:DI 1 "di_operand"  "rDa,Db,Dc,mi,r"))]
>"TARGET_32BIT
> && !(TARGET_HARD_FLOAT)
> +   && !(TARGET_HAVE_MVE || TARGET_HAVE_MVE_FLOAT)
> && !TARGET_IWMMXT
> && (   register_operand (operands[0], DImode)
> || register_operand (operands[1], DImode))"

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

[Thomas Koenig via Gcc-patches]

Am 15.04.20 um 12:33 schrieb Tobias Burnus:

On 4/15/20 12:26 PM, Thomas Koenig via Fortran wrote:

+   /* Turn erros into warnings with -std=gnu and -std=legacy,


Only glanced at it – but can you also fix the old* typo "erro(r)s"?


Yes, I think I can manage that :-)

Regards

Thomas

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

[Tobias Burnus]

On 4/15/20 12:26 PM, Thomas Koenig via Fortran wrote:

+   /* Turn erros into warnings with -std=gnu and -std=legacy,


Only glanced at it – but can you also fix the old* typo "erro(r)s"?

Tobias

(*old as the comment block has been moved around)

-
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, fortran] Fix ICE on invalid, PR 94090

[Thomas Koenig via Gcc-patches]

Hi Fritz,


I wonder: could you simply replace the gfc_error_opt(0, ...) call with
gfc_error?


Yes.  Looking back at the code, I think it can also be cleaned up
a little - turning the error to warnings is only needed on that
particular branch, and resetting it to the default can also
happen there, and at the target of a goto statement.

So, here's an updated patch.  OK for trunk?

Regards

Thomas

2020-04-13  Thomas Koenig  

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

2020-04-13  Thomas Koenig  

PR fortran/94090
* gfortran.dg/interface_46.f90: New test.
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 0d77386ddae..4e1da8c88a0 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3445,7 +3445,8 @@ bool gfc_check_dummy_characteristics (gfc_symbol *, 
gfc_symbol *,
 bool gfc_check_result_characteristics (gfc_symbol *, gfc_symbol *,
   char *, int);
 bool gfc_compare_interfaces (gfc_symbol*, gfc_symbol*, const char *, int, int,
-char *, int, const char *, const char *);
+char *, int, const char *, const char *,
+bool *bad_result_characteristics = NULL);
 void gfc_check_interfaces (gfc_namespace *);
 bool gfc_procedure_use (gfc_symbol *, gfc_actual_arglist **, locus *);
 void gfc_ppc_use (gfc_component *, gfc_actual_arglist **, locus *);
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 8f041f0a0a8..ba1c8bc322e 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -1529,7 +1529,7 @@ gfc_check_dummy_characteristics (gfc_symbol *s1, 
gfc_symbol *s2,
 
 bool
 gfc_check_result_characteristics (gfc_symbol *s1, gfc_symbol *s2,
- char *errmsg, int err_len)
+ char *errmsg, int err_len)
 {
   gfc_symbol *r1, *r2;
 
@@ -1695,12 +1695,16 @@ bool
 gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol *s2, const char *name2,
int generic_flag, int strict_flag,
char *errmsg, int err_len,
-   const char *p1, const char *p2)
+   const char *p1, const char *p2,
+   bool *bad_result_characteristics)
 {
   gfc_formal_arglist *f1, *f2;
 
   gcc_assert (name2 != NULL);
 
+  if (bad_result_characteristics)
+*bad_result_characteristics = false;
+
   if (s1->attr.function && (s2->attr.subroutine
   || (!s2->attr.function && s2->ts.type == BT_UNKNOWN
  && gfc_get_default_type (name2, s2->ns)->type == BT_UNKNOWN)))
@@ -1726,7 +1730,11 @@ gfc_compare_interfaces (gfc_symbol *s1, gfc_symbol *s2, 
const char *name2,
  /* If both are functions, check result characteristics.  */
  if (!gfc_check_result_characteristics (s1, s2, errmsg, err_len)
  || !gfc_check_result_characteristics (s2, s1, errmsg, err_len))
-   return false;
+   {
+ if (bad_result_characteristics)
+   *bad_result_characteristics = true;
+ return false;
+   }
}
 
   if (s1->attr.pure && !s2->attr.pure)
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 9b95200c241..2371ab23645 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -2601,21 +2601,27 @@ resolve_global_procedure (gfc_symbol *sym, locus 
*where, int sub)
  goto done;
}
 
-  if (!pedantic && (gfc_option.allow_std & GFC_STD_GNU))
-   /* Turn erros into warnings with -std=gnu and -std=legacy.  */
-   gfc_errors_to_warnings (true);
-
+  bool bad_result_characteristics;
   if (!gfc_compare_interfaces (sym, def_sym, sym->name, 0, 1,
-  reason, sizeof(reason), NULL, NULL))
+  reason, sizeof(reason), NULL, NULL,
+  _result_characteristics))
{
- gfc_error_opt (0, "Interface mismatch in global procedure %qs at %L:"
-" %s", sym->name, >declared_at, reason);
+ /* Turn erros into warnings with -std=gnu and -std=legacy,
+unless a function returns a wrong type, which can lead
+to all kinds of ICEs and wrong code.  */
+
+ if (!pedantic && (gfc_option.allow_std & GFC_STD_GNU)
+ && !bad_result_characteristics)
+   gfc_errors_to_warnings (true);
+
+ gfc_error ("Interface mismatch in global procedure %qs at %L: %s",
+sym->name, >declared_at, reason);
+ 

[Arm] Disallow arm_movdi when targetting MVE

[Matthew Malcomson]

Without disabling this, the pattern can try and move DImode values
between floating point registers and general registers.
The constraints on this pattern can't handle that, and reload goes into
an infinite loop.

This was the cause of a testsuite failure in cde_v_1_mve.c, which is now
gone.

A DImode move for MVE now uses the `movdi_vfp` pattern, which is the same
pattern used for such a move when MVE is not available but the target has
TARGET_HARD_FLOAT.

Testing done:
Bootstrapped and regtested on arm-none-linux-gnueabihf
regtested on arm-none-eabi

gcc/ChangeLog:

2020-04-15  Matthew Malcomson  

* config/arm/arm.md (arm_movdi): Disallow for MVE.



### Attachment also inlined for ease of reply###


diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 
7bc55cce61b2e45e5875a233dd4546d59399d749..a6a31f8f4ef8d3c8c96c61b450dbd7c28d08b55c
 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -6233,6 +6233,7 @@
(match_operand:DI 1 "di_operand"  "rDa,Db,Dc,mi,r"))]
   "TARGET_32BIT
&& !(TARGET_HARD_FLOAT)
+   && !(TARGET_HAVE_MVE || TARGET_HAVE_MVE_FLOAT)
&& !TARGET_IWMMXT
&& (   register_operand (operands[0], DImode)
|| register_operand (operands[1], DImode))"

diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 
7bc55cce61b2e45e5875a233dd4546d59399d749..a6a31f8f4ef8d3c8c96c61b450dbd7c28d08b55c
 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -6233,6 +6233,7 @@
(match_operand:DI 1 "di_operand"  "rDa,Db,Dc,mi,r"))]
   "TARGET_32BIT
&& !(TARGET_HARD_FLOAT)
+   && !(TARGET_HAVE_MVE || TARGET_HAVE_MVE_FLOAT)
&& !TARGET_IWMMXT
&& (   register_operand (operands[0], DImode)
|| register_operand (operands[1], DImode))"

Re: [PATCH] libiberty: Update D symbol demangling for latest ABI spec.

[Iain Buclaw via Gcc-patches]

Ping.

On 04/04/2020 13:33, Iain Buclaw wrote:
> Hi,
> 
> Some small improvements and clarifications have been done in the D ABI
> specification to remove all ambiguities found in the current grammar,
> this implementation now more closely resembles the spec, whilst
> maintaining compatibility with the old ABI.
> 
> Three new rules have been added to the ABI.
> 
> 1. Back references using 'Q', analogous to C++ substitutions, compresses
>repeated identifiers, types, and template symbol and value parameters.
> 
> 2. Template aliases to externally mangled symbols are prefixed with 'X'.
>This includes any symbol that isn't extern(D), or has its name
>overriden with pragma(mangle).  This fixes an ambiguity where it was
>not clear whether 'V' was an encoded calling convention, or the next
>template value parameter.
> 
> 3. Alias parameters, templates, and tuple symbols no longer encode the
>symbol length of its subpart.  Tuples are now terminated with 'Z'.
>This fixes another ambiguity where the first character of the mangled
>name can be a digit as well, so the demangler had to figure out where
>to split the two adjacent numbers by trying out each combination.
> 
> This patch was originally written by Rainer Schuetze, with clean-ups and
> backwards compatibility added by myself.
> 
> Bootstrapped and regression tested on x86_linux-gnu, OK for mainline?
> 
> Regards
> Iain.
> 
> ---
> 
> libiberty/ChangeLog:
> 
> 2019-04-04  Rainer Schuetze  
> Iain Buclaw  
> 
>   * d-demangle.c (enum dlang_symbol_kinds): Remove enum.
>   (struct dlang_info): New struct
>   (dlang_decode_backref): New function.
>   (dlang_backref): New function.
>   (dlang_symbol_backref): New function.
>   (dlang_type_backref): New function.
>   (dlang_symbol_name_p): New function.
>   (dlang_function_type_noreturn): New function.
>   (dlang_function_type): Add 'info' parameter.  Decode function type
>   with dlang_function_type_noreturn.
>   (dlang_function_args): Add 'info' parameter.
>   (dlang_type): Add 'info' parameter.  Handle back referenced types.
>   (dlang_identifier): Replace 'kind' parameter with 'info'.  Handle back
>   referenced symbols.  Split off decoding of plain identifiers to...
>   (dlang_lname): ...here.
>   (dlang_parse_mangle): Replace 'kind' parameter with 'info'.  Decode
>   function type and return with dlang_type.
>   (dlang_parse_qualified): Replace 'kind' parameter with 'info', add
>   'suffix_modifier' parameter.  Decode function type with
>   dlang_function_type_noreturn.
>   (dlang_parse_tuple): Add 'info' parameter.
>   (dlang_template_symbol_param): New function.
>   (dlang_template_args): Add 'info' parameter.  Decode symbol parameter
>   with dlang_template_symbol_param.  Handle back referenced values, and
>   externally mangled parameters.
>   (dlang_parse_template): Add 'info' parameter.
>   (dlang_demangle_init_info): New function.
>   (dlang_demangle): Initialize and pass 'info' parameter.
>   * testsuite/d-demangle-expected: Add new tests.
> 
> ---
>  libiberty/d-demangle.c  | 769 
>  libiberty/testsuite/d-demangle-expected |  72 +++
>  2 files changed, 580 insertions(+), 261 deletions(-)
> 
> diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
> index a9702858a6e..5856bc2930f 100644
> --- a/libiberty/d-demangle.c
> +++ b/libiberty/d-demangle.c
> @@ -160,37 +160,42 @@ string_prepend (string *p, const char *s)
>  }
>  }
>  
> -/* What kinds of symbol we could be parsing.  */
> -enum dlang_symbol_kinds
> +/* Demangle information structure we pass around.  */
> +struct dlang_info
>  {
> -  /* Top-level symbol, needs it's type checked.  */
> -  dlang_top_level,
> -  /* Function symbol, needs it's type checked.   */
> -  dlang_function,
> -  /* Strongly typed name, such as for classes, structs and enums.  */
> -  dlang_type_name,
> -  /* Template identifier.  */
> -  dlang_template_ident,
> -  /* Template symbol parameter.  */
> -  dlang_template_param
> +  /* The string we are demangling.  */
> +  const char *s;
> +  /* The index of the last back reference.  */
> +  int last_backref;
>  };
>  
> +/* Pass as the LEN to dlang_parse_template if symbol length is not known.  */
> +enum { TEMPLATE_LENGTH_UNKNOWN = -1 };
> +
>  /* Prototypes for forward referenced functions */
> -static const char *dlang_function_args (string *, const char *);
> +static const char *dlang_function_type (string *, const char *,
> + struct dlang_info *);
>  
> -static const char *dlang_type (string *, const char *);
> +static const char *dlang_function_args (string *, const char *,
> + struct dlang_info *);
> +
> +static const char *dlang_type (string *, const char *, struct dlang_info *);
>  
>  static const char *dlang_value (string *, const 

Re: [PATCH] gcc/gcc.c: add outfiles spec

[Rasmus Villemoes]

On 15/04/2020 10.52, Olivier Hainque wrote:
> Hi Rasmus,
> 
> Thanks for your proposal.
> 
> This is an issue we discussed a bit very recently
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543073.html
> 
> and it's nice to see a proposal not requiring
> the replication of all the link spec logic.
> 
> 
> I had mixed feelings about a change to get gcc -r behave
> differently on VxWorks, but on second thoughts ISTM there
> is sufficient variability in the linkage possibilities on
> that OS to justify some differences. 
> 
> As a side question to your proposal, have you considered
> the alternative which consists in using gcc -Wl,-r instead
> of gcc -r to build your modules ?
> 
> It would be interesting to know if that somehow wouldn't
> work for you.

I'll have to try it, but it sounds like it might work. We still need to
use a custom spec file to specify crtbegin.o/crtend.o as
startfile/endfile, so in that sense it was a bit easier to just also
include the extra logic for sandwiching the objects in that spec file as
well. As you also mention in the thread above, we really want to avoid
duplicating all of LINK_COMMAND_SPEC. Also, using the linker directly is
quite cumbersome, as one would first have to ask gcc via 'gcc
-print-file-name=crtbegin.o' where that file is - it's much neater when
the startfile spec just does its magic.


On a somewhat related note, we're currently carrying this locally in
order to build (link) the vxworks kernel image itself using gcc:

diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
index 0f604f1bcc4..06b4e2e6870 100644
--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -112,7 +112,7 @@ along with GCC; see the file COPYING3.  If not see
will treat it as an unrecognized option.  */
 #undef VXWORKS_LINK_SPEC
 #define VXWORKS_LINK_SPEC  \
-"%{!mrtp:-r}   \
+"  \
  %{!shared:\
%{mrtp:-q %{h*} \
   %{R*} %{!T*: %(link_start) } \

and then module builds must pass -r [or perhaps -Wl,-r depending on how
the above gets solved] explicitly. From the link above, it sounds like
you are already passing -r explicitly and not relying on lack of -mrtp
implying it, so would the above be acceptable for upstream (with proper
changelog and whitespace cleanup of course)?

Rasmus

Re: [PATCH] Fold (add -1; zero_ext; add +1) operations to zero_ext when not zero (PR37451, PR61837)

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 15, 2020 at 03:47:55AM -0500, luoxhu--- via Gcc-patches wrote:
>   2020-04-15  Xiong Hu Luo  
> 
>   PR rtl-optimization/37451, PR target/61837
>   loop-doloop.c (doloop_modify): Simplify (add -1; zero_ext; add +1)

"* " missing before loop-doloop.c

>   to zero_ext.
> ---
>  gcc/loop-doloop.c | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/loop-doloop.c b/gcc/loop-doloop.c
> index db6a014e43d..9f967fa3a0b 100644
> --- a/gcc/loop-doloop.c
> +++ b/gcc/loop-doloop.c
> @@ -477,7 +477,31 @@ doloop_modify (class loop *loop, class niter_desc *desc,
>  }
>  
>if (increment_count)
> -count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
> +{
> +  /* Fold (add -1; zero_ext; add +1) operations to zero_ext based on 
> addop0
> +  is never zero, as gimple pass loop ch will do optimization to simplify
> +  the loop to NO loop for loop condition is false.  */

There is no guarantee the loop ch pass was run, one can do
-fno-tree-loop-ch, -fdisable-tree-ch, -fdisable-tree-ch=foobar or
perhaps the zext(x-1)+1 has been introduced after it (either the loop
appeared post that at GIMPLE or later)?
IMHO if you want something like that, you need to prove at the RTL level
that addop0 must be non-zero, perhaps using saved VRP info from the GIMPLE
stuff if there is REG_EXPR mapping it to a SSA_NAME with one (though even
that might not be safe if things changed during RTL opts).

> +  bool simplify_zext = false;
> +  rtx extop0 = XEXP (count, 0);
> +  if (mode == E_DImode

Why hardcode DImode and SImode?  In generic code, shouldn't it work with
something more generic, like word_mode and MODE_INT mode twice as big as
the word_mode (or do you want MODE_INT mode with half the size of word_mode
and word_mode)?

> +   && GET_CODE (count) == ZERO_EXTEND
> +   && GET_CODE (extop0) == PLUS)
> + {
> +   rtx addop0 = XEXP (extop0, 0);
> +   rtx addop1 = XEXP (extop0, 1);
> +   if (CONST_SCALAR_INT_P (addop1)
> +   && GET_MODE (addop0) == E_SImode
> +   && addop1 == GEN_INT (-1))
> + {
> +   count = simplify_gen_unary (ZERO_EXTEND, mode, addop0,
> +   GET_MODE (addop0));
> +   simplify_zext = true;
> + }
> + }
> +
> +  if (!simplify_zext)
> + count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
> +}

Jakub

Re: [PATCH] Fold (add -1; zero_ext; add +1) operations to zero_ext when not zero (PR37451, PR61837)

[Richard Sandiford]

luoxhu--- via Gcc-patches  writes:
> From: Xionghu Luo 
>
> This "subtract/extend/add" existed for a long time and still annoying us
> (PR37451, PR61837) when converting from 32bits to 64bits, as the ctr
> register is used as 64bits on powerpc64, Andraw Pinski had a patch but
> caused some issue and reverted by Joseph S. Myers(PR37451, PR37782).
>
> Andraw:
> http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01070.html
> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01321.html
> Joseph:
> https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg02405.html
>
> However, the doloop code improved a lot since so many years passed,
> gcc.c-torture/execute/doloop-1.c is no longer a simple loop with constant
> desc->niter_expr since r125:SI#0 is not SImode, so it is not a valid doloop
> and no transform done in doloop again.  Thus we can do the simplification
> from "subtract/extend/add" to only extend as the condition in doloop will
> never be false based on loop ch's optimization.
> What's more, this patch is slightly different with Andrw's implementation,
> the check of ZERO_EXT and SImode will guard the count won't be changed
> from char/short caused cases not time out on slow platforms before.
> Any comments?  Thanks.
>
> doloop-1.c.257r.loop2_doloop
> ...
> 12: [r129:DI]=r123:SI
>   REG_DEAD r129:DI
>   REG_DEAD r123:SI
> 13: r125:SI=r120:DI#0-0x1
>   REG_DEAD r120:DI
> 14: r120:DI=zero_extend(r125:SI#0)
>   REG_DEAD r125:SI
> 16: r126:CC=cmp(r120:DI,0)
> 17: pc={(r126:CC!=0)?L43:pc}
>   REG_DEAD r126:CC
> ...
>
> Bootstrap and regression tested pass on Power8-LE.
>
> gcc/ChangeLog
>
>   2020-04-15  Xiong Hu Luo  
>
>   PR rtl-optimization/37451, PR target/61837
>   loop-doloop.c (doloop_modify): Simplify (add -1; zero_ext; add +1)
>   to zero_ext.
> ---
>  gcc/loop-doloop.c | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/loop-doloop.c b/gcc/loop-doloop.c
> index db6a014e43d..9f967fa3a0b 100644
> --- a/gcc/loop-doloop.c
> +++ b/gcc/loop-doloop.c
> @@ -477,7 +477,31 @@ doloop_modify (class loop *loop, class niter_desc *desc,
>  }
>  
>if (increment_count)
> -count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
> +{
> +  /* Fold (add -1; zero_ext; add +1) operations to zero_ext based on 
> addop0
> +  is never zero, as gimple pass loop ch will do optimization to simplify
> +  the loop to NO loop for loop condition is false.  */

IMO the code needs to prove this, rather than just assume that previous
passes have made it so.

Thanks,
Richard

> +  bool simplify_zext = false;
> +  rtx extop0 = XEXP (count, 0);
> +  if (mode == E_DImode
> +   && GET_CODE (count) == ZERO_EXTEND
> +   && GET_CODE (extop0) == PLUS)
> + {
> +   rtx addop0 = XEXP (extop0, 0);
> +   rtx addop1 = XEXP (extop0, 1);
> +   if (CONST_SCALAR_INT_P (addop1)
> +   && GET_MODE (addop0) == E_SImode
> +   && addop1 == GEN_INT (-1))
> + {
> +   count = simplify_gen_unary (ZERO_EXTEND, mode, addop0,
> +   GET_MODE (addop0));
> +   simplify_zext = true;
> + }
> + }
> +
> +  if (!simplify_zext)
> + count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
> +}
>  
>/* Insert initialization of the count register into the loop header.  */
>start_sequence ();

Re: [PATCH] gcc/gcc.c: add outfiles spec

[Olivier Hainque]

Hi Rasmus,

Thanks for your proposal.

This is an issue we discussed a bit very recently
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543073.html

and it's nice to see a proposal not requiring
the replication of all the link spec logic.


I had mixed feelings about a change to get gcc -r behave
differently on VxWorks, but on second thoughts ISTM there
is sufficient variability in the linkage possibilities on
that OS to justify some differences. 

As a side question to your proposal, have you considered
the alternative which consists in using gcc -Wl,-r instead
of gcc -r to build your modules ?

It would be interesting to know if that somehow wouldn't
work for you.

Regards,

Olivier

[PATCH] Fold (add -1; zero_ext; add +1) operations to zero_ext when not zero (PR37451, PR61837)

[luoxhu--- via Gcc-patches]

From: Xionghu Luo 

This "subtract/extend/add" existed for a long time and still annoying us
(PR37451, PR61837) when converting from 32bits to 64bits, as the ctr
register is used as 64bits on powerpc64, Andraw Pinski had a patch but
caused some issue and reverted by Joseph S. Myers(PR37451, PR37782).

Andraw:
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01070.html
http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01321.html
Joseph:
https://gcc.gnu.org/legacy-ml/gcc-patches/2011-11/msg02405.html

However, the doloop code improved a lot since so many years passed,
gcc.c-torture/execute/doloop-1.c is no longer a simple loop with constant
desc->niter_expr since r125:SI#0 is not SImode, so it is not a valid doloop
and no transform done in doloop again.  Thus we can do the simplification
from "subtract/extend/add" to only extend as the condition in doloop will
never be false based on loop ch's optimization.
What's more, this patch is slightly different with Andrw's implementation,
the check of ZERO_EXT and SImode will guard the count won't be changed
from char/short caused cases not time out on slow platforms before.
Any comments?  Thanks.

doloop-1.c.257r.loop2_doloop
...
12: [r129:DI]=r123:SI
  REG_DEAD r129:DI
  REG_DEAD r123:SI
13: r125:SI=r120:DI#0-0x1
  REG_DEAD r120:DI
14: r120:DI=zero_extend(r125:SI#0)
  REG_DEAD r125:SI
16: r126:CC=cmp(r120:DI,0)
17: pc={(r126:CC!=0)?L43:pc}
  REG_DEAD r126:CC
...

Bootstrap and regression tested pass on Power8-LE.

gcc/ChangeLog

2020-04-15  Xiong Hu Luo  

PR rtl-optimization/37451, PR target/61837
loop-doloop.c (doloop_modify): Simplify (add -1; zero_ext; add +1)
to zero_ext.
---
 gcc/loop-doloop.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/gcc/loop-doloop.c b/gcc/loop-doloop.c
index db6a014e43d..9f967fa3a0b 100644
--- a/gcc/loop-doloop.c
+++ b/gcc/loop-doloop.c
@@ -477,7 +477,31 @@ doloop_modify (class loop *loop, class niter_desc *desc,
 }
 
   if (increment_count)
-count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
+{
+  /* Fold (add -1; zero_ext; add +1) operations to zero_ext based on addop0
+is never zero, as gimple pass loop ch will do optimization to simplify
+the loop to NO loop for loop condition is false.  */
+  bool simplify_zext = false;
+  rtx extop0 = XEXP (count, 0);
+  if (mode == E_DImode
+ && GET_CODE (count) == ZERO_EXTEND
+ && GET_CODE (extop0) == PLUS)
+   {
+ rtx addop0 = XEXP (extop0, 0);
+ rtx addop1 = XEXP (extop0, 1);
+ if (CONST_SCALAR_INT_P (addop1)
+ && GET_MODE (addop0) == E_SImode
+ && addop1 == GEN_INT (-1))
+   {
+ count = simplify_gen_unary (ZERO_EXTEND, mode, addop0,
+ GET_MODE (addop0));
+ simplify_zext = true;
+   }
+   }
+
+  if (!simplify_zext)
+   count = simplify_gen_binary (PLUS, mode, count, const1_rtx);
+}
 
   /* Insert initialization of the count register into the loop header.  */
   start_sequence ();
-- 
2.21.0.777.g83232e3864

Re: [PATCH V2]aarch64: falkor-tag-collision-avoidance.c fix valid_src_p for use of uninitialized value

[Andrea Corallo]

Hi all,

Second version of this addressing comments.

Bootstraped on aarch64 and regressioned.  Okay for trunk?

Andrea

gcc/ChangeLog

2020-??-??  Andrea Corallo  

* config/aarch64/falkor-tag-collision-avoidance.c
(valid_src_p): Check for aarch64_address_info type before
accessing base field.
diff --git a/gcc/config/aarch64/falkor-tag-collision-avoidance.c b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
index f850153fae02..a96a3320e8fc 100644
--- a/gcc/config/aarch64/falkor-tag-collision-avoidance.c
+++ b/gcc/config/aarch64/falkor-tag-collision-avoidance.c
@@ -538,7 +538,11 @@ valid_src_p (rtx src, rtx_insn *insn, struct loop *loop, bool *pre_post,
   if (!aarch64_classify_address (, XEXP (x, 0), mode, true))
 return false;
 
-  if (!REG_P (addr.base))
+  if (addr.type != ADDRESS_REG_IMM
+  && addr.type != ADDRESS_REG_WB
+  && addr.type != ADDRESS_REG_REG
+  && addr.type != ADDRESS_REG_UXTW
+  && addr.type != ADDRESS_REG_SXTW)
 return false;
 
   unsigned regno = REGNO (addr.base);

Re: [PATCH] aarch64: Fix bootstrap with old binutils [PR93053]

[Jakub Jelinek via Gcc-patches]

On Wed, Apr 15, 2020 at 08:27:43AM +, Kyrylo Tkachov wrote:
> > I've been testing this in distro scratch builds, so I don't really have
> > there the old assembler, but bootstrapped/regtested 5 times, for each of the
> > two patches once as is and once with s/cas/caszz/ in the configure{.ac,} to
> > simulate missing support of LSE (and verified that as is the build logs
> > contain checking...supports LSE yes and with the tweaked ...supports LSE no)
> > and once vanilla trunk, and aarch64-linux-gnu-objdump -dr libgcc.a is
> > identical from all 5 builds.

FYI, I've now also tested on gcc115 in GCCFarm which has the 2013-ish gas
and without the patch it indeed fails to build and with the patch it builds
fine.

> Eventually non-LSE assemblers will be unsuitable for various reasons and I
> expect we'll enforce a minimum required binutils version, at which point I
> expect we can revert this patch.  Is there an effective way of making sure
> we don't forget to do that?  (A bugzilla entry?)

We can file a bugzilla bug, but whether anybody will remember it when bumping 
the
binutils requirement, no idea.

Jakub

RE: [PATCH] aarch64: Fix bootstrap with old binutils [PR93053]

[Kyrylo Tkachov]

Hi Jakub,

> -Original Message-
> From: Jakub Jelinek 
> Sent: 15 April 2020 08:28
> To: Richard Earnshaw ; Richard Sandiford
> ; Kyrylo Tkachov ;
> Richard Henderson 
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] aarch64: Fix bootstrap with old binutils [PR93053]
> 
> Hi!
> 
> As reported in the PR, GCC 10 (and also 9.3.1 but not 9.3.0) fails to build
> when using older binutils which lack LSE support, because those instructions
> are used in libgcc.
> Thanks to Kyrylo's hint, the following patches (hopefully) allow it to build
> even with older binutils by using .inst directive if LSE support isn't
> available in the assembler.
> 
> There are two versions of the patch, one is using .macro to ignore the
> operands when emitting .inst, the other moves the operands for the
> HAVE_AS_LSE case into the macro.  My slight preference is the latter,
> because for maintanance it makes it clear that if one wants to use different
> operands, one needs to use a different macro and different .inst
> constant(s).

I'm not too worried about the difference really. Let's go with the second 
version for the sake of making a decision.

> 
> I've been testing this in distro scratch builds, so I don't really have
> there the old assembler, but bootstrapped/regtested 5 times, for each of the
> two patches once as is and once with s/cas/caszz/ in the configure{.ac,} to
> simulate missing support of LSE (and verified that as is the build logs
> contain checking...supports LSE yes and with the tweaked ...supports LSE no)
> and once vanilla trunk, and aarch64-linux-gnu-objdump -dr libgcc.a is
> identical from all 5 builds.
> 
> Ok for trunk (which version), or do we want to instead document a newer
> binutils requirement?  Yet another option is to go with the patch for a
> while and later bump the requirement and revert the patch.

I'd definitely like the patch to go in as we've gotten requests to backport the 
OOL feature to GCC 8 as well...
Eventually non-LSE assemblers will be unsuitable for various reasons and I 
expect we'll enforce a minimum required binutils version, at which point I 
expect we can revert this patch. Is there an effective way of making sure we 
don't forget to do that? (A bugzilla entry?)

Thanks for working on this,
Kyrill

> 
>   Jakub

[PATCH] c++: Fix pasto in structured binding diagnostics [PR94571]

[Jakub Jelinek via Gcc-patches]

Hi!

This snippet has been copied from the non-structured binding declaration
parsing later in the function, and while for non-structured bindings
it can be followed by comma or semicolon, structured bindings may be
only followed by semicolon.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?

Or, do we want to have a different message for the case when there is
a comma (and keep this corrected one only if there is something else)
that would explain better what is the bug (or add a fix-it hint)?
Marek said in the PR that clang++ reports
error: decomposition declaration must be the only declaration in its group

There is another thing Marek noted (though, something for different spot),
that diagnostic for auto x(1), [e,f] = test2; could also use a clearer
wording like the above (or a fix-it hint), but the question is if we should
assume [ after , as a structured binding or if we should do some tentative
parsing first to figure out if it looks like a structured binding.

2020-04-15  Jakub Jelinek  

PR c++/94571
* parser.c (cp_parser_simple_declaration): Fix up a pasto in
diagnostics.

* g++.dg/cpp1z/decomp51.C: New test.

--- gcc/cp/parser.c.jj  2020-04-08 11:59:23.772460767 +0200
+++ gcc/cp/parser.c 2020-04-14 10:15:54.824034781 +0200
@@ -13675,7 +13675,7 @@ cp_parser_simple_declaration (cp_parser*
if ((decl != error_mark_node
 && DECL_INITIAL (decl) != error_mark_node)
|| cp_parser_uncommitted_to_tentative_parse_p (parser))
- cp_parser_error (parser, "expected %<,%> or %<;%>");
+ cp_parser_error (parser, "expected %<;%>");
/* Skip tokens until we reach the end of the statement.  */
cp_parser_skip_to_end_of_statement (parser);
/* If the next token is now a `;', consume it.  */
--- gcc/testsuite/g++.dg/cpp1z/decomp51.C.jj2020-04-14 10:18:58.318313777 
+0200
+++ gcc/testsuite/g++.dg/cpp1z/decomp51.C   2020-04-14 10:19:31.347823985 
+0200
@@ -0,0 +1,16 @@
+// PR c++/94571
+// { dg-do compile { target c++17 } }
+
+void
+foo ()
+{
+  int e[2], f[2];
+  auto [a,b] = e, [c,d] = f;   // { dg-error "expected ';' before ',' token" }
+}
+
+void
+bar ()
+{
+  int e[2];
+  auto [a, b] = e );   // { dg-error "expected ';' before '\\\)' 
token" }
+}

Jakub

[committed] openmp: Reject requires directives not at file or namespace scope [PR94593]

[Jakub Jelinek via Gcc-patches]

Hi!

This change started with a bugreport about a typo in one requires testcase
(diagnosed with -Wunknown-pragmas only), but following discussion lead to
noting that we do not diagnose restriction that requires directives in
C/C++ may only appear at file or namespace scope; and several our tests
violated that.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
As it is accepts-invalid, won't backport it to 9.

2020-04-15  Jakub Jelinek  

PR c/94593
* c-parser.c (c_parser_pragma) : Reject
requires directive when not at file scope.

* parser.c (cp_parser_pragma) : Reject
requires directive when not at file or namespace scope.

* c-c++-common/gomp/requires-1.c: Fix a typo, requries -> requires.
Move directives to file scope.
(i): Remove.
* c-c++-common/gomp/requires-2.c: Move directives to file scope.
(i, foo): Remove.
* c-c++-common/gomp/requires-4.c: Move directives to file scope.
* c-c++-common/gomp/atomic-19.c: Move requires directive to file scope.
* c-c++-common/gomp/atomic-20.c: Likewise.
* c-c++-common/gomp/atomic-21.c: Likewise.
* c-c++-common/gomp/atomic-22.c: Likewise.
* gcc.dg/gomp/requires-1.c: New test.
* g++.dg/gomp/requires-1.C: New test.
* g++.dg/gomp/requires-2.C: New test.
* g++.dg/gomp/atomic-18.C: Move requires directive to file scope.

--- gcc/c/c-parser.c.jj 2020-04-15 09:39:16.593895441 +0200
+++ gcc/c/c-parser.c2020-04-15 09:41:26.387958378 +0200
@@ -12402,6 +12402,13 @@ c_parser_pragma (c_parser *parser, enum
   return false;
 
 case PRAGMA_OMP_REQUIRES:
+  if (context != pragma_external)
+   {
+ error_at (c_parser_peek_token (parser)->location,
+   "%<#pragma omp requires%> may only be used at file scope");
+ c_parser_skip_until_found (parser, CPP_PRAGMA_EOL, NULL);
+ return false;
+   }
   c_parser_omp_requires (parser);
   return false;
 
--- gcc/cp/parser.c.jj  2020-04-15 09:39:16.646894650 +0200
+++ gcc/cp/parser.c 2020-04-15 09:41:26.392958303 +0200
@@ -43801,6 +43801,13 @@ cp_parser_pragma (cp_parser *parser, enu
   return true;
 
 case PRAGMA_OMP_REQUIRES:
+  if (context != pragma_external)
+   {
+ error_at (pragma_tok->location,
+   "%<#pragma omp requires%> may only be used at file or "
+   "namespace scope");
+ break;
+   }
   return cp_parser_omp_requires (parser, pragma_tok);
 
 case PRAGMA_OMP_ORDERED:
--- gcc/testsuite/c-c++-common/gomp/requires-1.c.jj 2020-04-15 
09:39:16.736893307 +0200
+++ gcc/testsuite/c-c++-common/gomp/requires-1.c2020-04-15 
09:41:26.392958303 +0200
@@ -3,15 +3,12 @@
 #pragma omp requires unified_shared_memory unified_address
 #pragma omp requires dynamic_allocators,reverse_offload
 
-int i;
-
 void
 foo ()
 {
-  if (0)
-#pragma omp requires unified_shared_memory unified_address
-i++;
-  #pragma omp requries atomic_default_mem_order(seq_cst)
 }
 
+#pragma omp requires unified_shared_memory unified_address
+#pragma omp requires atomic_default_mem_order(seq_cst)
+
 /* { dg-prune-output "not supported yet" } */
--- gcc/testsuite/c-c++-common/gomp/requires-2.c.jj 2020-04-15 
09:39:16.751893083 +0200
+++ gcc/testsuite/c-c++-common/gomp/requires-2.c2020-04-15 
09:41:26.392958303 +0200
@@ -3,18 +3,8 @@
 #pragma omp requires unified_address   unified_address /* { dg-error "too many 
'unified_address' clauses" } */
 #pragma omp requires reverse_offload reverse_offload   /* { dg-error "too many 
'reverse_offload' clauses" } */
 #pragma omp requires foobarbaz /* { dg-error "expected 'unified_address', 
'unified_shared_memory', 'dynamic_allocators', 'reverse_offload' or 
'atomic_default_mem_order' clause" } */
-
-int i;
-
-void
-foo ()
-{
-  #pragma omp requires dynamic_allocators , dynamic_allocators /* { dg-error 
"too many 'dynamic_allocators' clauses" } */
-  if (0)
-#pragma omp requires atomic_default_mem_order(seq_cst) 
atomic_default_mem_order(seq_cst)   /* { dg-error "too many 
'atomic_default_mem_order' clauses" } */
-i++;
-}
-
+#pragma omp requires dynamic_allocators , dynamic_allocators   /* { dg-error 
"too many 'dynamic_allocators' clauses" } */
+#pragma omp requires atomic_default_mem_order(seq_cst) 
atomic_default_mem_order(seq_cst)   /* { dg-error "too many 
'atomic_default_mem_order' clauses" } */
 #pragma omp requires atomic_default_mem_order (seq_cst)/* { dg-error 
"more than one 'atomic_default_mem_order' clause in a single compilation unit" 
} */
 
 /* { dg-prune-output "not supported yet" } */
--- gcc/testsuite/c-c++-common/gomp/requires-4.c.jj 2020-04-15 
09:39:16.765892874 +0200
+++ gcc/testsuite/c-c++-common/gomp/requires-4.c2020-04-15 
09:41:26.392958303 +0200
@@ -4,9 +4,9 @@ foo (void)
 {
   #pragma omp target
   ;
-  #pragma omp requires 

RE: [PATCH][GCC][Arm]: MVE: Add mve vec_duplicate pattern

[Kyrylo Tkachov]

> -Original Message-
> From: Andre Vieira (lists) 
> Sent: 15 April 2020 08:43
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov 
> Subject: [PATCH][GCC][Arm]: MVE: Add mve vec_duplicate pattern
> 
> Hi,
> 
> This patch fixes an ICE we were seeing due to a missing vec_duplicate
> pattern.
> 
> Regression tested on arm-none-eabi.
> 
> Is this OK for trunk?

Ok.
Thanks,
Kyrill

> 
> gcc/ChangeLog:
> 2020-04-15  Andre Vieira  
> 
>      * config/arm/mve.md (mve_vec_duplicate): New pattern.
>      (V_sz_elem2): Remove unused mode attribute.
> 
> gcc/testsuite/ChangeLog:
> 2020-04-15  Andre Vieira 
>      Srinath Parvathaneni 
> 
>      * gcc.target/arm/mve/intrinsics/mve_vec_duplicate.c: New test.

[PATCH][GCC][Arm]: MVE: Add mve vec_duplicate pattern

[Andre Vieira (lists)]

Hi,

This patch fixes an ICE we were seeing due to a missing vec_duplicate 
pattern.


Regression tested on arm-none-eabi.

Is this OK for trunk?

gcc/ChangeLog:
2020-04-15  Andre Vieira  

    * config/arm/mve.md (mve_vec_duplicate): New pattern.
    (V_sz_elem2): Remove unused mode attribute.

gcc/testsuite/ChangeLog:
2020-04-15  Andre Vieira 
    Srinath Parvathaneni 

    * gcc.target/arm/mve/intrinsics/mve_vec_duplicate.c: New test.

diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index 
c49c14c4240838ce086f424f58726e2e94cf190e..047b4769a28daebdc0175804c578a0d11830a291
 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -17,8 +17,6 @@
 ;; along with GCC; see the file COPYING3.  If not see
 ;; .
 
-(define_mode_attr V_sz_elem2 [(V16QI "s8") (V8HI "u16") (V4SI "u32")
- (V2DI "u64")])
 (define_mode_iterator MVE_types [V16QI V8HI V4SI V2DI TI V8HF V4SF V2DF])
 (define_mode_iterator MVE_VLD_ST [V16QI V8HI V4SI V8HF V4SF])
 (define_mode_iterator MVE_0 [V8HF V4SF])
@@ -11301,3 +11299,10 @@ (define_insn "mve_vshlcq_m_"
  "vpst\;vshlct\t%q0, %1, %4"
  [(set_attr "type" "mve_move")
   (set_attr "length" "8")])
+
+(define_insn "*mve_vec_duplicate"
+ [(set (match_operand:MVE_VLD_ST 0 "s_register_operand" "=w")
+   (vec_duplicate:MVE_VLD_ST (match_operand: 1 "general_operand" 
"r")))]
+ "TARGET_HAVE_MVE || TARGET_HAVE_MVE_FLOAT"
+ "vdup.\t%q0, %1"
+ [(set_attr "type" "mve_move")])
diff --git a/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vec_duplicate.c 
b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vec_duplicate.c
new file mode 100644
index 
..eda836151b3a16eb54ddebabf185be3cd8980acc
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vec_duplicate.c
@@ -0,0 +1,13 @@
+/* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
+/* { dg-additional-options "-O2" } */
+
+#include "arm_mve.h"
+
+float32x4_t a;
+
+void foo (void)
+{
+  a = 1.41176471f - 0.47058824f * a;
+}
+

Re: Make it possible to have different instrumented and feedback builds without copying gcda files around [pr93401]

[Martin Liška]

On 4/9/20 2:44 PM, Jan Hubicka wrote:

Hi,
in GCC 8 we changed -fprofile-generate= to use mangled absolute paths in
the  directory. This was necessary to avoid clashes of files when gcc is
executed from different directories to build different sources of same
filename.

However this made it difficult to build projects on setups where instrumented
build is done in one directory, feedback build in different and possibly
training happens in yet another directory structure.  This happens i.e. for
Firefox builds for month or two.

This patch adds -fprofile-prefix-path that can be used to inform gcc where the
root of build directory is and strip it form the gcda filenames.
This is similar to exisitng debug-prefix-map but without the map feature since
it seems useless for profile data.

We spent quite some time with Maritn Liska discussing options and found no
better solution.  I was looking how this work on LLVM and they produce single
profdata file which is then transformed into kind of simple database by
llvmprofdata tool.  This database keys functions by filename and symbol name.
If you arrane two files with same name define static variable with same symbol
name this gets messedup and result in wrong info. So I think this is not very
good solution and preffer the extra option.


Hello.

I welcome the patch. There are 2 small formatting corrections:

diff --git a/gcc/common.opt b/gcc/common.opt
index 5662d46630a..1e604ba9bb6 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2198,7 +2198,7 @@ Enum(profile_update) String(prefer-atomic) 
Value(PROFILE_UPDATE_PREFER_ATOMIC)
 
 fprofile-prefix-path=

 Common Joined RejectNegative Var(profile_prefix_path)
-remove prefix from absolute path before manging name for -fprofile-generate= 
and -fprofile-use=.
+Remove prefix from absolute path before manging name for -fprofile-generate= 
and -fprofile-use=.
 
 fprofile-generate

 Common
diff --git a/gcc/coverage.c b/gcc/coverage.c
index d09a5749fbd..45c0278f44f 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -1232,8 +1232,8 @@ coverage_init (const char *filename)
filename++;
}
  else
-   warning (0, "filename %s does not start with profile prefix %s",
-filename, profile_prefix_path);
+   warning (0, "filename %qs does not start with profile "
+"prefix %qs", filename, profile_prefix_path);
}
  filename = mangle_path (filename);
  len = strlen (filename);



Bootstrapped/regtested x86_64-linux. I plan to commit it later today if there
are no complains.

I suppose our manual could have some central section on profile feedback
explaining the whole setup at one place.


Yes, we have it spread in various places. The option can be mentioned in:
10.4 Brief Description of gcov Data Files

And can you please add the option to GCC 10 changes please?

Thanks,
Martin



Honza

* common.opt (profile-prefix-path): New option.
* coverae.c: Include diagnostics.h.
(coverage_init): Strip profile prefix path.
* doc/invoke.texi (-fprofile-prefix-path): Document.
diff --git a/gcc/common.opt b/gcc/common.opt
index bb2ea4c905d..5662d46630a 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2196,6 +2196,10 @@ Enum(profile_update) String(atomic) 
Value(PROFILE_UPDATE_ATOMIC)
  EnumValue
  Enum(profile_update) String(prefer-atomic) Value(PROFILE_UPDATE_PREFER_ATOMIC)
  
+fprofile-prefix-path=

+Common Joined RejectNegative Var(profile_prefix_path)
+remove prefix from absolute path before manging name for -fprofile-generate= 
and -fprofile-use=.
+
  fprofile-generate
  Common
  Enable common options for generating profile info for profile feedback 
directed optimizations.
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 30ae84df90f..d09a5749fbd 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
@@ -49,6 +49,7 @@ along with GCC; see the file COPYING3.  If not see
  #include "intl.h"
  #include "auto-profile.h"
  #include "profile.h"
+#include "diagnostic.h"
  
  #include "gcov-io.c"
  
@@ -1221,6 +1222,19 @@ coverage_init (const char *filename)

  const char *separator = "/";
  #endif
  filename = concat (getpwd (), separator, filename, NULL);
+ if (profile_prefix_path)
+   {
+ if (!strncmp (filename, profile_prefix_path,
+   strlen (profile_prefix_path)))
+   {
+ filename += strlen (profile_prefix_path);
+ while (*filename == *separator)
+   filename++;
+   }
+ else
+   warning (0, "filename %s does not start with profile prefix %s",
+filename, profile_prefix_path);
+   }
  filename = mangle_path (filename);
  len = strlen (filename);
}
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index be7b5bb7d71..afd8a6dbc03 100644
--- 

[PATCH] aarch64: Fix bootstrap with old binutils [PR93053]

[Jakub Jelinek via Gcc-patches]

Hi!

As reported in the PR, GCC 10 (and also 9.3.1 but not 9.3.0) fails to build
when using older binutils which lack LSE support, because those instructions
are used in libgcc.
Thanks to Kyrylo's hint, the following patches (hopefully) allow it to build
even with older binutils by using .inst directive if LSE support isn't
available in the assembler.

There are two versions of the patch, one is using .macro to ignore the
operands when emitting .inst, the other moves the operands for the
HAVE_AS_LSE case into the macro.  My slight preference is the latter,
because for maintanance it makes it clear that if one wants to use different
operands, one needs to use a different macro and different .inst
constant(s).

I've been testing this in distro scratch builds, so I don't really have
there the old assembler, but bootstrapped/regtested 5 times, for each of the
two patches once as is and once with s/cas/caszz/ in the configure{.ac,} to
simulate missing support of LSE (and verified that as is the build logs
contain checking...supports LSE yes and with the tweaked ...supports LSE no)
and once vanilla trunk, and aarch64-linux-gnu-objdump -dr libgcc.a is
identical from all 5 builds.

Ok for trunk (which version), or do we want to instead document a newer
binutils requirement?  Yet another option is to go with the patch for a
while and later bump the requirement and revert the patch.

Jakub
2020-04-15  Jakub Jelinek  

PR target/93053
* configure.ac (LIBGCC_CHECK_AS_LSE): Add HAVE_AS_LSE checking.
* config/aarch64/lse.S: Include auto-target.h, if HAVE_AS_LSE
is not defined, use just .arch armv8-a.
(B, M, N, OPN): Define.
(COMMENT): New .macro.
(CAS, CASP, SWP, LDOP): Use .inst directive if HAVE_AS_LSE is not
defined.
* configure: Regenerated.
* config.in: Regenerated.

--- libgcc/configure.ac.jj  2020-01-24 22:34:36.301641823 +0100
+++ libgcc/configure.ac 2020-04-14 13:48:48.771866654 +0200
@@ -599,6 +599,25 @@ i[[34567]]86-*-* | x86_64-*-*)
 esac])
 LIBGCC_CHECK_AS_AVX
 
+dnl Check if as supports LSE instructions.
+AC_DEFUN([LIBGCC_CHECK_AS_LSE], [
+case "${target}" in
+aarch64*-*-*)
+  AC_CACHE_CHECK([if the assembler supports LSE], libgcc_cv_as_lse, [
+AC_TRY_COMPILE([],
+changequote(,)dnl
+   asm(".arch armv8-a+lse\n\tcas w0, w1, [x2]");
+changequote([,])dnl
+  ,
+  [libgcc_cv_as_lse=yes], [libgcc_cv_as_lse=no])
+  ])
+  if test x$libgcc_cv_as_lse = xyes; then
+AC_DEFINE(HAVE_AS_LSE, 1, [Define to 1 if the assembler supports LSE.])
+  fi
+  ;;
+esac])
+LIBGCC_CHECK_AS_LSE
+
 dnl Check if as supports RTM instructions.
 AC_CACHE_CHECK(for init priority support, libgcc_cv_init_priority, [
 AC_COMPILE_IFELSE([AC_LANG_PROGRAM(,
--- libgcc/config/aarch64/lse.S.jj  2020-01-12 11:54:38.610380262 +0100
+++ libgcc/config/aarch64/lse.S 2020-04-14 13:44:57.403253956 +0200
@@ -48,8 +48,14 @@ see the files COPYING3 and COPYING.RUNTI
  * separately to minimize code size.
  */
 
+#include "auto-target.h"
+
 /* Tell the assembler to accept LSE instructions.  */
+#ifdef HAVE_AS_LSE
.arch armv8-a+lse
+#else
+   .arch armv8-a
+#endif
 
 /* Declare the symbol gating the LSE implementations.  */
.hidden __aarch64_have_lse_atomics
@@ -58,12 +64,19 @@ see the files COPYING3 and COPYING.RUNTI
 #if SIZE == 1
 # define S b
 # define UXT   uxtb
+# define B 0x
 #elif SIZE == 2
 # define S h
 # define UXT   uxth
+# define B 0x4000
 #elif SIZE == 4 || SIZE == 8 || SIZE == 16
 # define S
 # define UXT   mov
+# if SIZE == 4
+#  define B0x8000
+# elif SIZE == 8
+#  define B0xc000
+# endif
 #else
 # error
 #endif
@@ -72,18 +85,26 @@ see the files COPYING3 and COPYING.RUNTI
 # define SUFF  _relax
 # define A
 # define L
+# define M 0x00
+# define N 0x00
 #elif MODEL == 2
 # define SUFF  _acq
 # define A a
 # define L
+# define M 0x40
+# define N 0x80
 #elif MODEL == 3
 # define SUFF  _rel
 # define A
 # define L l
+# define M 0x008000
+# define N 0x40
 #elif MODEL == 4
 # define SUFF  _acq_rel
 # define A a
 # define L l
+# define M 0x408000
+# define N 0xc0
 #else
 # error
 #endif
@@ -138,13 +159,23 @@ see the files COPYING3 and COPYING.RUNTI
cbz w(tmp0), \label
 .endm
 
+#ifndef HAVE_AS_LSE
+/* Throw away all arguments.  */
+.macro COMMENT args:vararg
+.endm
+#endif
+
 #ifdef L_cas
 
 STARTFNNAME(cas)
JUMP_IF_NOT_LSE 8f
 
 #if SIZE < 16
-#define CASglue4(cas, A, L, S)
+#ifdef HAVE_AS_LSE
+# define CAS   glue4(cas, A, L, S)
+#else
+# define CAS   .inst 0x08a07c41 + B + M; COMMENT
+#endif
 
CAS s(0), s(1), [x2]
ret
@@ -160,7 +191,11 @@ STARTFNNAME(cas)
 #else
 #define LDXP   glue3(ld, A, xp)
 #define STXP   glue3(st, L, xp)
-#define CASP   glue3(casp, A, L)
+#ifdef HAVE_AS_LSE
+# define CASP  

Re: [PATCH] middle-end/94539 - void * aliases every other pointer

[Richard Biener]

On Tue, 14 Apr 2020, Jan Hubicka wrote:

> > 
> > But we're using it in indirect_ref_may_alias_decl_p as
> > 
> >   /* If second reference is view-converted, give up now.  */
> >   if (same_type_for_tbaa (TREE_TYPE (dbase2), TREE_TYPE (ptrtype2)) != 
> > 1)
> > return true;
> > 
> > and clearly if TREE_TYPE (ptrtype2) is void * while TREE_TYPE (dbase2)
> > is T * we've "view-converted" things.
> > 
> > Not sure what the consequence is when we fall through here since those
> > checks may be redundant now(?)  But given we're late for GCC 10 I'd
> > rather be safe than sorry ;)
> 
> I think this check is about part of access path missing (i.e. we have
> access path like a.b.c.d.e.f while mem-ref took part of it away
> so we have a.b.c...f).
> So here c and f should not be both pointers.
> > 
> > > For ICF checking we need to be more careful anyway (in particular we do
> > > not want all those -1s on arrays), so I would worry about that next
> > > stage1.
> > > 
> > > With 1 we will probably save some work since the code will not continue
> > > looking for must aliases.
> > 
> > I think we have still quite some cleanup to do for the path-based
> > disambiguations.
> 
> Yep, one issue at a time

I've now pushed the last version, let's improve things in GCC 11.

Richard.

> Honza
> > 
> > Richard.
> > 
> > > Honza
> > > 
> > > > 
> > > > So, like the following.
> > > > 
> > > > Richard.
> > > > 
> > > > 
> > > > middle-end/94539 - void * aliases every other pointer
> > > > 
> > > > This makes same_type_for_tbaa_p conservative in the same way
> > > > get_alias_set is about void * which we allow to alias all other
> > > > pointers.
> > > > 
> > > > 2020-04-14  Richard Biener  
> > > > 
> > > > PR middle-end/94539
> > > > * tree-ssa-alias.c (same_type_for_tbaa): Defer to
> > > > alias_sets_conflict_p for pointers.
> > > > 
> > > > * gcc.dg/alias-14.c: Make dg-do run.
> > > > ---
> > > >  gcc/testsuite/gcc.dg/alias-14.c |  2 +-
> > > >  gcc/tree-ssa-alias.c| 11 ++-
> > > >  2 files changed, 11 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/gcc/testsuite/gcc.dg/alias-14.c 
> > > > b/gcc/testsuite/gcc.dg/alias-14.c
> > > > index 1ca1c09d5e3..24f0d1c1168 100644
> > > > --- a/gcc/testsuite/gcc.dg/alias-14.c
> > > > +++ b/gcc/testsuite/gcc.dg/alias-14.c
> > > > @@ -1,4 +1,4 @@
> > > > -/* { dg-do compile } */
> > > > +/* { dg-do run } */
> > > >  /* { dg-options "-O2" } */
> > > >  #include 
> > > >  void *a;
> > > > diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
> > > > index df9ba0de0d6..ede4f198342 100644
> > > > --- a/gcc/tree-ssa-alias.c
> > > > +++ b/gcc/tree-ssa-alias.c
> > > > @@ -839,7 +839,16 @@ same_type_for_tbaa (tree type1, tree type2)
> > > >   would mean that conversions between them are useless, whereas 
> > > > they are
> > > >   not (e.g. type and subtypes can have different modes).  So, in 
> > > > the end,
> > > >   they are only guaranteed to have the same alias set.  */
> > > > -  if (get_alias_set (type1) == get_alias_set (type2))
> > > > +  alias_set_type set1 = get_alias_set (type1);
> > > > +  alias_set_type set2 = get_alias_set (type2);
> > > > +  if (set1 == set2)
> > > > +return -1;
> > > > +
> > > > +  /* Pointers to void are considered compatible with all other 
> > > > pointers,
> > > > + so for two pointers see what the alias set resolution thinks.  */
> > > > +  if (POINTER_TYPE_P (type1)
> > > > +  && POINTER_TYPE_P (type2)
> > > > +  && alias_sets_conflict_p (set1, set2))
> > > >  return -1;
> > > >  
> > > >/* The types are known to be not equal.  */
> > > > -- 
> > > > 2.13.7
> > > > 
> > > 
> > 
> > -- 
> > Richard Biener 
> > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
> > Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
> 

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

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

[Richard Biener via Gcc-patches]

On Wed, Apr 15, 2020 at 3:56 AM Jiufu Guo via Gcc-patches
 wrote:
>
> Hi,
>
> As you may know, we have loop unroll pass in RTL which was introduced a few
> years ago, and works for a long time.  Currently, this unroller is using the
> pseudos in the original body, and then the pseudos are written multiple times.
>
> It would be a good idea to create new pseudos for those duplicated 
> instructions
> during loop unrolling.  This would relax reg dependence, and then provide more
> freedom/opportunity for other optimizations, like scheduling, RA...

I think there's a separate pass to do something like this, conveniently
placed after unrolling.  -fweb, IIRC enabled by default for -funroll-loops
unless explicitly disabled.  Related is regrename which is also enabled then.

So where does your patch make a difference?  Is the webizers dataflow analysis
maybe confused by backedges?

> As below example:
>
> Original loop:
> ```
>26: L26:
>17: NOTE_INSN_BASIC_BLOCK 4
>18: r130:SF=[r125:DI+r122:DI]
>19: r131:SF=[r126:DI+r122:DI]
>20: r129:SF=r130:SF*r131:SF
>21: r132:DF=float_extend(r129:SF)
>22: r121:DF=r121:DF+r132:DF
>23: r133:SI=r123:DI#0-0x1
>24: r123:DI=zero_extend(r133:SI)
>25: r122:DI=r122:DI+0x4
>27: r134:CC=cmp(r123:DI,0)
>28: pc={(r134:CC!=0)?L49:pc}
>   ; pc falls through to BB 5
>49: L49:
>48: NOTE_INSN_BASIC_BLOCK 8
>   ; pc falls through to BB 4
> ```
> It was unrolled to:
> ```
>26: L26:
>17: NOTE_INSN_BASIC_BLOCK 4
>18: r130:SF=[r125:DI+r122:DI]
>19: r131:SF=[r126:DI+r122:DI]
>20: r129:SF=r130:SF*r131:SF
>21: r132:DF=float_extend(r129:SF)
>93: r145:DF=r121:DF+r132:DF
>23: r133:SI=r123:DI#0-0x1
>95: r148:DI=zero_extend(r133:SI)
>91: r140:DI=r122:DI+0x4
>25: r122:DI=r140:DI
>97: r134:CC=cmp(r148:DI,0)
>
>87: NOTE_INSN_BASIC_BLOCK 16
>77: r130:SF=[r125:DI+r122:DI]
>78: r131:SF=[r126:DI+r122:DI]
>79: r129:SF=r130:SF*r131:SF
>80: r132:DF=float_extend(r129:SF)
>81: r121:DF=r121:DF+r132:DF
>82: r133:SI=r123:DI#0-0x1
>83: r123:DI=zero_extend(r133:SI)
>84: r122:DI=r140:DI+0x4
>85: r134:CC=cmp(r123:DI,0)
>86: pc={(r134:CC!=0)?L90:pc}
>
> ```
> We can see, the original loop is using r130,r131,r129,r132,r121...
> For the unrolled sequence BB 16, they are still using them.
>
> We could use new pseudos for duplicate body, like below:
> ```
>26: L26:
>17: NOTE_INSN_BASIC_BLOCK 4
>18: r130:SF=[r125:DI+r122:DI]
>19: r131:SF=[r126:DI+r122:DI]
>20: r129:SF=r130:SF*r131:SF
>21: r132:DF=float_extend(r129:SF)
>93: r145:DF=r121:DF+r132:DF
>23: r133:SI=r123:DI#0-0x1
>95: r148:DI=zero_extend(r133:SI)
>91: r140:DI=r122:DI+0x4
>25: r122:DI=r140:DI
>97: r134:CC=cmp(r148:DI,0)
>
>87: NOTE_INSN_BASIC_BLOCK 16
>77: r141:SF=[r125:DI+r122:DI]
>78: r142:SF=[r126:DI+r122:DI]
>79: r143:SF=r141:SF*r142:SF
>80: r144:DF=float_extend(r143:SF)
>81: r146:DF=r145:DF+r144:DF
>82: r147:SI=r148:DI#0-0x1
>83: r149:DI=zero_extend(r147:SI)
>84: r122:DI=r140:DI+0x4
>85: r150:CC=cmp(r149:DI,0)
>98: r130:SF=r141:SF
>99: r131:SF=r142:SF
>   100: r129:SF=r143:SF
>   101: r132:DF=r144:DF
>   102: r121:DF=r146:DF
>   103: r133:SI=r147:SI
>   104: r123:DI=r149:DI
>   105: r134:CC=r150:CC
>86: pc={(r150:CC!=0)?L90:pc}
> ```
> In BB 16, new pseudos: r141,r142,r143... are used.
>
> For this, I drafted a prototype like the patch below.
> This patch only supports simple loops: one exit edge with one major basic 
> block.
>
> With this patch, we can see, the generated asm code uses fewer instructions 
> on PowerPC.
>
> Welcome for comments, thanks!
>
> BR.
> Jiufu Guo.
>
> ---
>  gcc/common.opt|   4 +
>  gcc/loop-unroll.c | 309 +-
>  2 files changed, 310 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index fa9da505fc2..e298ce09c82 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -2526,6 +2526,10 @@ fvariable-expansion-in-unroller
>  Common Report Var(flag_variable_expansion_in_unroller) Optimization
>  Apply variable expansion when loops are unrolled.
>
> +fassin-new-operand-in-unroller
> +Common Report Var(flag_assign_new_operand_in_unroller) Init(1) Optimization
> +Creating new pseudo for duplicated instruction when loops are unrolled.
> +
>  fstack-check=
>  Common Report RejectNegative Joined Optimization
>  -fstack-check=[no|generic|specific]Insert stack checking code into the 
> program.
> diff --git a/gcc/loop-unroll.c b/gcc/loop-unroll.c
> index 693c7768868..54a48bd9fd7 100644
> --- a/gcc/loop-unroll.c
> +++ b/gcc/loop-unroll.c
> @@ -94,6 +94,17 @@ struct var_to_expand
>var_expansions[REUSE_EXPANSION - 1].  
> */
>  };
>
> +struct def_to_split
> +{
> +  rtx_insn *insn;  /* The insn in that the assigment occurs.  */
> +  rtx reg;  /* The def/set