[PATCH] contrib/vimrc: Reduce textwidth for commit messages

[Patrick Palka via Gcc-patches]

The bundled vimrc script, when enabled, currently sets the text width to
80 characters for all files within the source directory.  Unfortunately
this means the setting also applies when editing .git/COMMIT_EDITMSG,
overriding the default and standard text width of 72 for Git commit
messages.  (A text width of 80 is too much for commit messages because
Git indents commit messages by four spaces when displaying them via e.g.
git log, leading to a total displayed width of 84 characters.)

This patch explicitly sets the text width of Git commit messages to 72
characters in accordance with standard practice.  (Alternatively we
could avoid setting textwidth at all in this case and let the defaults
kick in, but maybe it's better to be explicit?)

Tested by writing up this commit message :)  Is this OK to commit?

contrib/ChangeLog:

* vimrc: Reduce textwidth to 72 for Git commit messages.
---
 contrib/vimrc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/contrib/vimrc b/contrib/vimrc
index fa0208d5beb..c207eead2e4 100644
--- a/contrib/vimrc
+++ b/contrib/vimrc
@@ -39,7 +39,11 @@ function! SetStyle()
 setlocal shiftwidth=2
 setlocal noexpandtab
   endif
-  setlocal textwidth=80
+  if  == "gitcommit"
+setlocal textwidth=72
+  else
+setlocal textwidth=80
+  endif
   setlocal formatoptions-=ro formatoptions+=cqlt
   if index(l:c_exts, l:ext) != -1
 setlocal cindent
-- 
2.26.2.266.ge870325ee8

Re: [rs6000] fix mffsl emulation

[Alexandre Oliva]

On Apr 24, 2020, Segher Boessenkool  wrote:

>> > since all the top bits are zeros always, it will always be a subnormal
>> > number, so all comparisons will work as expected / wanted.
>> 
>> *nod*, as long as there's no trapping on subnormals.

> There isn't :-)  I did say this isn't clean at all, just *happens* to
> work, right?  :-)

I hope you don't mind my using the union in the testcase, that was
otherwise unused, to IMHO improve on that, then ;-)

>> Erhm, what I posted had TABs there.  Did it get mangled? :-(

> Yes, to eight spaces, so that aligned "output" under "gcc".

Aah, found them in lines other than the ones I'd verified.  Fixed.

> Sure, that looks fine.  Maybe tmp1, tmp2, etc. woukld be clearer here?

That works for me.

> Could you open one?

Sure, PR94812

Tested test_mffsl.c with and without -mpower9-misc.
Regstrapping on ppc64le-linux-gnu.  Ok to install?



[rs6000] fix mffsl emulation

From: Alexandre Oliva 

The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going
through the motions, but not storing the result in the given
operands[0]; it rather modifies operands[0] without effect.  It also
creates a DImode pseudo that it doesn't use, overwriting subregs
instead.

The patch below fixes all of these, the indentation and a typo.


I'm concerned about several issues in the mffsl testcase.  First, I
don't see that comparing the values as doubles rather than as long
longs is desirable.  These are FPSCR bitfields, not FP numbers.  I
understand mffs et al use double because they output to FP registers,
and the bit patterns are subnormal FP numbers, so it works, but given
the need for bit masking of at least one side, I'm changing the
compare to long longs.

Another issue with the test is that, if the compare fails, it calls
mffsl again to print the value, as if it would yield the same result.
But part of the FPSCR that mffsl (emulated with mmfl or not) copies to
the output FP register is the FPCC, so the fcmpu used to compare the
result of the first mmfsl will modify FPSCR and thus the result of the
second mmfsl call.  After changing the compare, this is no longer the
case, but I still think it's better to make absolutely sure what we
print is what we compared: the least desirable thing during debugging
is to find out, after hours of investigation, that you were led down
the wrong path by incorrect information.

Yet another issue is that the test assumed the mmfs bits that are not
to be extracted by mffsl to be already zero, instead of masking them
out explicitly.  This is not about the mffs emulation in the mffsl
implementation, but about the mffs use in the test proper.  The bits
appear to be zero indeed, as the bits left out are for sticky
exceptions, but there are reserved parts of FPSCR that might turn out
to be set in the future, so we're better off masking them out
explicitly, otherwise those bits could cause the compare to fail.

If some future mffsl is changed so that it copies additional nonzero
bits, the test will fail, and then we'll have a chance to adjust it
and the emulation.


for  gcc/ChangeLog

PR target/94812
* gcc/config/rs6000/rs6000.md (rs6000_mffsl): Copy result to
output operand in emulation.  Don't overwrite pseudos.

for  gcc/testsuite/ChangeLog

PR target/94812
* gcc.target/powerpc/test_mffsl.c: Call mffsl only once.
Reinterpret the doubles as long longs for compares.  Mask out
mffs bits that are not expected from mffsl.
---
 gcc/config/rs6000/rs6000.md   |   26 +
 gcc/testsuite/gcc.target/powerpc/test_mffsl.c |   12 
 2 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 11ab745..86a16dd 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -13620,18 +13620,20 @@
 
   if (!TARGET_P9_MISC)
 {
-   rtx tmp_di = gen_reg_rtx (DImode);
-   rtx tmp_df = gen_reg_rtx (DFmode);
-
-   /* The mffs instruction reads the entire FPSCR.  Emulate the mffsl
-  instruction using the mffs instruction and masking off the bits
-  the mmsl instruciton actually reads.  */
-   emit_insn (gen_rs6000_mffs (tmp_df));
-   tmp_di = simplify_gen_subreg (DImode, tmp_df, DFmode, 0);
-   emit_insn (gen_anddi3 (tmp_di, tmp_di, GEN_INT (0x70007f0ffLL)));
-
-   operands[0] = simplify_gen_subreg (DFmode, tmp_di, DImode, 0);
-   DONE;
+  rtx tmp1 = gen_reg_rtx (DFmode);
+
+  /* The mffs instruction reads the entire FPSCR.  Emulate the mffsl
+instruction using the mffs instruction and masking off the bits
+the mmsl instruction actually reads.  */
+  emit_insn (gen_rs6000_mffs (tmp1));
+
+  rtx tmp1di = simplify_gen_subreg (DImode, tmp1, DFmode, 0);
+  rtx tmp2 = gen_reg_rtx (DImode);
+  emit_insn (gen_anddi3 (tmp2, tmp1di, GEN_INT (0x70007f0ffLL)));
+
+  rtx tmp2df = simplify_gen_subreg 

[PATCH] wwwdocs: Add D front-end section for GCC 10 changes

[Iain Buclaw via Gcc-patches]

Hi,

This patch adds a section on the D front-end about all changes that have
gone into the GCC 10 release.  W3 validator reports there are no errors
or warnings to show.

Any comments or clarifications required on what's written up?  Or is it
OK to commit to the website?

Regards
Iain.

---
 htdocs/gcc-10/changes.html | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 41c2dc0d..af8c72eb 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -432,6 +432,37 @@ a work-in-progress.
   
 
 
+D
+
+  Support for static foreach has been implemented.
+  Aliases can now be created directly from any __trait that
+  return symbols or tuples.  Previously, an AliasSeq was
+  necessary in order to alias their return.
+  
+  Optional parentheses in asm operands are now deprecated and
+  will be removed in a future release.
+  
+  All content imported files are now included in the make dependency list
+  when compiling with -M.
+  
+  User-defined attributes exposed by the gcc.attribute module,
+  to which are attached against prototypes of declarations are now also
+  applied to other matching prototypes and definitions.
+  
+  Support for core.math.toPrec intrinsics has been added.
+  These intrinsics guarantee the rounding to specific floating-point
+  precisions at required points in the code.
+  
+  Support for pragma(inline) has been implemented.
+  Added --enable-libphobos-checking configure option to
+  control whether run-time checks are compiled into the D runtime library.
+  
+  Added --with-libphobos-druntime-only configure option to
+  allow specifying whether to build only the core D runtime library, or
+  both the core and standard libraries into libphobos.
+  
+
+
 Fortran
 
   use_device_addr of version 5.0 of the
-- 
2.20.1

[PATCH] rtl cse: Fix PR94740, ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1

[Peter Bergner via Gcc-patches]

rtl-optimization: ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel 
-O1 [PR94740]

We ICE on the test case below because decompose_normal_address()  doesn't
expect to see memory operands with constant addresses like below without
a (const:DI ...) wrapped around the PLUS:

(mem/c:SI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
   (const_int 4 [0x4])) [1 array+4 S4 A32])

What we expect to see is:

(mem/c:SI (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 
0x182])
 (const_int 4 [0x4]))) [1 arrayD.2903+4 S4 
A32])

Sometimes, combine adds the (const: ...) for us via simplify_binary_operand
call, but that only happens when combine actually does something with this
insn.  The bad address from the test case actually comes from CSE, so the
fix here is to make CSE add the (const: ...) whenever it creates a MEM with
a constant address.

This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for trunk?

Peter


gcc/
PR rtl-optimization/94740
* cse.c (cse_process_notes):

gcc/testsuite/
PR rtl-optimization/94740
* gcc.target/powerpc/pr94740.c: New test.

diff --git a/gcc/cse.c b/gcc/cse.c
index 5aaba8d80e0..cbe9e0a0692 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -6328,6 +6328,14 @@ cse_process_notes (rtx x, rtx object, bool *changed)
   rtx new_rtx = cse_process_notes_1 (x, object, changed);
   if (new_rtx != x)
 *changed = true;
+  if (*changed && object != NULL_RTX && MEM_P (object))
+{
+  /* Call simplify_rtx on the updated address in case it is now
+a constant and needs to be wrapped with a (const: ...).  */
+  rtx simplified_rtx = simplify_rtx (new_rtx);
+  if (simplified_rtx)
+   new_rtx = simplified_rtx;
+}
   return new_rtx;
 }
 
diff --git a/gcc/testsuite/gcc.target/powerpc/pr94740.c 
b/gcc/testsuite/gcc.target/powerpc/pr94740.c
new file mode 100644
index 000..78e40fc84da
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr94740.c
@@ -0,0 +1,11 @@
+/* PR rtl-optimization/94740 */
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_future_ok } */
+/* { dg-options "-O2 -mdejagnu-cpu=future -mpcrel" } */
+
+int array[8];
+int
+foo (void)
+{
+  return __builtin_bswap32 (array[1]);
+}

Re: [PATCH] PowerPC -mcpu=future Patch 7 of 7, Add test for stack checking and large stack frames

[will schmidt via Gcc-patches]

On Mon, 2020-04-27 at 16:04 -0400, Michael Meissner via Gcc-patches wrote:
> This patch adds a test for the case where we have prefixed load/store
> instructions, a large stack frame, and stack checking is enabled.
> 
> This is patch #7 of 7.  I have checked this patch on a little endian power8
> system running Linux, and the test passed.  Can I check this into the GCC 10
> trunk?
> 
> 2020-04-27  Michael Meissner  
> 
>   * gcc.target/powerpc/prefix-stack-protect.c: New test to make sure
>   -fstack-protect-strong works with prefixed addressing.
> 
> --- /tmp/OxuBEg_prefix-stack-protect.c2020-04-27 14:12:53.883004507 
> -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-stack-protect.c   2020-04-27 
> 14:12:53.706006931 -0400
> @@ -0,0 +1,20 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future -fstack-protector-strong" } */
> +
> +/* Test that we can handle large stack frames with -fstack-protector-strong 
> and
> +   prefixed addressing.  This was originally discovered in trying to build

s/in/when/

> +   glibc with -mcpu=future, and vfwprintf.c failed because it used
> +   -fstack-protector-strong.  */
> +
> +extern long foo (char *);
> +
> +long
> +bar (void)
> +{
> +  char buffer[0x2];
> +  return foo (buffer) + 1;
> +}
> +
> +/* { dg-final { scan-assembler {\mpld\M}  } } */
> +/* { dg-final { scan-assembler {\mpstd\M} } } */
> 

lgtm,
thanks,
-Will

Re: [PATCH] PowerPC -mcpu=future Patch 6 of 7, add PC-relative tests

[will schmidt via Gcc-patches]

On Mon, 2020-04-27 at 16:01 -0400, Michael Meissner via Gcc-patches wrote:
> This patch adds PC-relative tests for -mcpu=future.
> 
> This is patch #6 of 7.  I have checked this on a little endian power8 system
> running Linux, and all tests passed.  Can I check this into the GCC 10 trunk?
> 
> 2020-04-27  Michael Meissner  
> 
>   * gcc.target/powerpc/prefix-pcrel.h: New set of tests to test
>   prefixed addressing on 'future' system with PC-relative addresses
>   for various types.
>   * gcc.target/powerpc/prefix-pcrel-dd.c: New test for prefixed
>   loads/stores with PC-relative addresses for the _Decimal64 type.
>   * gcc.target/powerpc/prefix-pcrel-df.c: New test for prefixed
>   loads/stores with PC-relative addresses for the double type.
>   * gcc.target/powerpc/prefix-pcrel-di.c: New test for prefixed
>   loads/stores with PC-relative addresses for the long type.
>   * gcc.target/powerpc/prefix-pcrel-hi.c: New test for prefixed
>   loads/stores with PC-relative addresses for the short type.
>   * gcc.target/powerpc/prefix-pcrel-kf.c: New test for prefixed
>   loads/stores with PC-relative addresses for the __float128 type.
>   * gcc.target/powerpc/prefix-pcrel-qi.c: New test for prefixed
>   loads/stores with PC-relative addresses for the signed char type.
>   * gcc.target/powerpc/prefix-pcrel-sd.c: New test for prefixed
>   loads/stores with PC-relative addresses for the _Decimal32 type.
>   * gcc.target/powerpc/prefix-pcrel-sf.c: New test for prefixed
>   loads/stores with PC-relative addresses for the float type.
>   * gcc.target/powerpc/prefix-pcrel-si.c: New test for prefixed
>   loads/stores with PC-relative addresses for the int type.
>   * gcc.target/powerpc/prefix-pcrel-udi.c: New test for prefixed
>   loads/stores with PC-relative addresses for the unsigned long
>   type.
>   * gcc.target/powerpc/prefix-pcrel-uhi.c: New test for prefixed
>   loads/stores with PC-relative addresses for the unsigned short
>   type.
>   * gcc.target/powerpc/prefix-pcrel-uqi.c: New test for prefixed
>   loads/stores with PC-relative addresses for the unsigned char
>   type.
>   * gcc.target/powerpc/prefix-pcrel-usi.c: New test for prefixed
>   loads/stores with PC-relative addresses for the unsigned int
>   type.
>   * gcc.target/powerpc/prefix-pcrel-v2df.c: New test for prefixed
>   loads/stores with PC-relative addresses for the vector double
>   type.
> 
> --- /tmp/61oqzU_prefix-pcrel-dd.c 2020-04-27 14:11:22.981249397 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c2020-04-27 
> 14:11:22.751252547 -0400
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_pcrel } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Tests for prefixed instructions testing whether pc-relative prefixed
> +   instructions are generated for the _Decimal64 type.  */


Too many test references?
Should that be simply "Test whether pc-relative prefixed instructions
are generated for the _Decimal64 type." 

(Same repeated later in the patch).


> +
> +#define TYPE _Decimal64
> +
> +#include "prefix-pcrel.h"
> +
> +/* { dg-final { scan-assembler-times {[@]pcrel}  4 } } */
> +/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
> +/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
> --- /tmp/w5tyiy_prefix-pcrel-df.c 2020-04-27 14:11:22.990249274 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c2020-04-27 
> 14:11:22.755252492 -0400
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_pcrel } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Tests for prefixed instructions testing whether pc-relative prefixed
> +   instructions are generated for the double type.  */
> +
> +#define TYPE double
> +
> +#include "prefix-pcrel.h"
> +
> +/* { dg-final { scan-assembler-times {[@]pcrel}  4 } } */
> +/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
> +/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
> --- /tmp/uE672b_prefix-pcrel-di.c 2020-04-27 14:11:22.998249164 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c2020-04-27 
> 14:11:22.759252437 -0400
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_pcrel } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Tests for prefixed instructions testing whether pc-relative prefixed
> +   instructions are generated for the long type.  */
> +
> +#define TYPE long
> +
> +#include "prefix-pcrel.h"
> +
> +/* { dg-final { scan-assembler-times {[@]pcrel} 4 } } */
> +/* { dg-final { scan-assembler-times {\mpld\M}  2 } } */
> +/* { dg-final { scan-assembler-times {\mpstd\M} 2 } } */
> --- /tmp/UHt8OP_prefix-pcrel-hi.c 2020-04-27 14:11:23.005249069 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c  

Re: [PATCH] PowerPC -mcpu=future Patch 5 of 7, Add prefixed load/store tests with large numeric offsets

[will schmidt via Gcc-patches]

On Mon, 2020-04-27 at 16:00 -0400, Michael Meissner via Gcc-patches
wrote:
> This patch adds tests for -mcpu=future generating prefixed load/store
> instructions with large numeric offsets.
> 
> This is patch #5 of 7.  This patch was tested on a little endian power8 system
> running Linux, and the tests passed.  Can I check this into GCC 10?
> 
> 2020-04-27  Michael Meissner  
> 
>   * gcc.target/powerpc/prefix-large.h: New set of tests to test
>   prefixed addressing on 'future' system with large numeric offsets
>   for various types.
>   * gcc.target/powerpc/prefix-large-dd.c: New test for prefixed
>   loads/stores with large offsets for the _Decimal64 type.
>   * gcc.target/powerpc/prefix-large-df.c: New test for prefixed
>   loads/stores with large offsets for the double type.
>   * gcc.target/powerpc/prefix-large-di.c: New test for prefixed
>   loads/stores with large offsets for the long type.
>   * gcc.target/powerpc/prefix-large-hi.c: New test for prefixed
>   loads/stores with large offsets for the short type.
>   * gcc.target/powerpc/prefix-large-kf.c: New test for prefixed
>   loads/stores with large offsets for the __float128 type.
>   * gcc.target/powerpc/prefix-large-qi.c: New test for prefixed
>   loads/stores with large offsets for the signed char type.
>   * gcc.target/powerpc/prefix-large-sd.c: New test for prefixed
>   loads/stores with large offsets for the _Decimal32 type.
>   * gcc.target/powerpc/prefix-large-sf.c: New test for prefixed
>   loads/stores with large offsets for the float type.
>   * gcc.target/powerpc/prefix-large-si.c: New test for prefixed
>   loads/stores with large offsets for the int type.
>   * gcc.target/powerpc/prefix-large-udi.c: New test for prefixed
>   loads/stores with large offsets for the unsigned long type.
>   * gcc.target/powerpc/prefix-large-uhi.c: New test for prefixed
>   loads/stores with large offsets for the unsigned short type.
>   * gcc.target/powerpc/prefix-large-uqi.c: New test for prefixed
>   loads/stores with large offsets for the unsigned char type.
>   * gcc.target/powerpc/prefix-large-usi.c: New test for prefixed
>   loads/stores with large offsets for the unsigned int type.
>   * gcc.target/powerpc/prefix-large-v2df.c: New test for prefixed
>   loads/stores with large offsets for the vector double type.

I'd probably drop "New" from those.  Aside from that nit, the
descriptions are good.

> 
> --- /tmp/ky2ZAZ_prefix-large-dd.c 2020-04-27 14:05:05.638417056 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c2020-04-27 
> 14:05:05.406420175 -0400
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Tests for prefixed instructions testing whether we can generate a prefixed
> +   load/store instruction that has a 34-bit offset for _Decimal64 objects.  
> */
> +
> +#define TYPE _Decimal64
> +
> +#include "prefix-large.h"
> +
> +/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
> +/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
> --- /tmp/HDrUG4_prefix-large-df.c 2020-04-27 14:05:05.647416935 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-large-df.c2020-04-27 
> 14:05:05.411420108 -0400
> @@ -0,0 +1,13 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Tests for prefixed instructions testing whether we can generate a prefixed
> +   load/store instruction that has a 34-bit offset for double objects.  */
> +
> +#define TYPE double
> +
> +#include "prefix-large.h"
> +
> +/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
> +/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
> 


> --- /tmp/1H98Oa_prefix-large.h2020-04-27 14:05:05.737415712 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-large.h   2020-04-27 
> 14:05:05.461419436 -0400
> @@ -0,0 +1,59 @@
> +/* Common tests for prefixed instructions testing whether we can generate a
> +   34-bit offset using 1 instruction.  */
> +
> +typedef signed char  schar;
> +typedef unsigned charuchar;
> +typedef unsigned short   ushort;
> +typedef unsigned int uint;
> +typedef unsigned longulong;
> +typedef long double  ldouble;
> +typedef vector doublev2df;
> +typedef vector long  v2di;
> +typedef vector float v4sf;
> +typedef vector int   v4si;
> +
> +#ifndef TYPE
> +#define TYPE ulong
> +#endif
> +
> +#ifndef ITYPE
> +#define ITYPE TYPE
> +#endif
> +
> +#ifndef OTYPE
> +#define OTYPE TYPE
> +#endif
> +

I don't seee any users of ITYPE or OTYPE below.Those could be
culled.   (if this is likely to be adapted in the future to include
those, probably OK?)


I didn't cross-count the scan-assembler-times stanzas, but being that
the tests are broken up into 

Re: [PATCH] PowerPC -mcpu=future Patch 4 of 7, Make sure an invalid instruction is not generated

[will schmidt via Gcc-patches]

On Mon, 2020-04-27 at 15:57 -0400, Michael Meissner via Gcc-patches
wrote:
> This test validates that the compiler does not generate a prefixed
> load/store
> instruction with an update form.  The prefixed load/store
> instructions do not
> have an update form.
> 
> This is patch #4 of 7.  This patch was run on a little endian power8
> system
> running Linux, and the tests passed.  Can I check this into the
> trunk?

Hi,


> 2020-04-27  Michael Meissner  
> 
>   * gcc.target/powerpc/prefix-no-premodify.c: Make sure we do not
>   generate the non-existent PLWZU instruction if -mcpu=future.

Should "premodify" instead be "no-update" or "no-update-forms" ?   I
don't immediately see why "modify" is referenced.


> 
> --- /tmp/zijQUT_prefix-no-premodify.c 2020-04-27 14:01:44.465121833
> -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-no-premodify.c2020-
> 04-27 14:01:44.288124213 -0400
> @@ -0,0 +1,50 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Make sure that we don't generate a prefixed form of the load and
> store with
> +   update instructions (i.e. instead of generating LWZU we have to
> generate
> +   PLWZ plus a PADDI).  */
> +
> +#ifndef SIZE
> +#define SIZE 5
> +#endif
> +
> +struct foo {
> +  unsigned int field;
> +  char pad[SIZE];
> +};
> +
> +struct foo *inc_load (struct foo *p, unsigned int *q)
> +{
> +  *q = (++p)->field; /* PLWZ, PADDI, STW.  */
> +  return p;
> +}
> +
> +struct foo *dec_load (struct foo *p, unsigned int *q)
> +{
> +  *q = (--p)->field; /* PLWZ, PADDI, STW.  */
> +  return p;
> +}
> +
> +struct foo *inc_store (struct foo *p, unsigned int *q)
> +{
> +  (++p)->field = *q; /* LWZ, PADDI, PSTW.  */
> +  return p;
> +}
> +
> +struct foo *dec_store (struct foo *p, unsigned int *q)
> +{
> +  (--p)->field = *q; /* LWZ, PADDI, PSTW.  */
> +  return p;
> +}
> +
> +/* { dg-final { scan-assembler-times {\mlwz\M}2 } } */
> +/* { dg-final { scan-assembler-times {\mstw\M}2 } } */
> +/* { dg-final { scan-assembler-times {\mpaddi\M}  4 } } */
> +/* { dg-final { scan-assembler-times {\mplwz\M}   2 } } */
> +/* { dg-final { scan-assembler-times {\mpstw\M}   2 } } */

Numbers line up with comments above.

> +/* { dg-final { scan-assembler-not   {\mplwzu\M}} } */
> +/* { dg-final { scan-assembler-not   {\mpstwu\M}} } */
> +/* { dg-final { scan-assembler-not   {\maddis\M}} } */
> +/* { dg-final { scan-assembler-not   {\maddi\M} } } */

Ok.

lgtm.
thanks,
-Will



> 

Re: [PATCH] PowerPC -mcpu=future Patch 3 of 7, Add test for generating prefixed load/store

[will schmidt via Gcc-patches]

On Mon, 2020-04-27 at 15:53 -0400, Michael Meissner via Gcc-patches wrote:
> This patch adds a test that verifies that the compiler generates a prefixed
> load/store instruction where the compiler cannot generate the instruction
> directly because the offset is not a valid DS or DQ offset.  A DS offset must
> have the bottom 2 bits clear.  A DQ offset must have the bottom 4 bits clear.
> Due to the way PowerPC instructions are encoded, some instructions use the DS
> format and some use the DQ format.
> 
> This is patch #3 of 7.  The tests in this patch run on a little endian power8
> system running Linux.
> 
> 2020-04-27  Michael Meissner  
> 
>   * gcc.target/powerpc/prefix-ds-dq.c: New test to verify that we
>   generate the prefix load/store instructions for traditional
>   instructions with an offset that doesn't match DS/DQ
>   requirements.

Can probably safely be shortened to end at "... for traditional
instructions."   if not even just "New test".  



> 
> --- /tmp/dtFbYL_prefix-ds-dq.c2020-04-27 13:54:38.350850944 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c   2020-04-27 
> 13:54:15.301160847 -0400
> @@ -0,0 +1,156 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Tests whether we generate a prefixed load/store operation for addresses 
> that
> +   don't meet DS/DQ offset constraints.  */
> +
> +unsigned long
> +load_uc_offset1 (unsigned char *p)
> +{
> +  return p[1];   /* should generate LBZ.  */
> +}
> +
> +long
> +load_sc_offset1 (signed char *p)
> +{
> +  return p[1];   /* should generate LBZ + EXTSB. 
>  */
> +}

OCD kicks in and says the above two (and a couple below) have an extra
tab.  nbd. :-)


> +
> +unsigned long
> +load_us_offset1 (unsigned char *p)
> +{
> +  return *(unsigned short *)(p + 1); /* should generate LHZ.  */
> +}
> +
> +long
> +load_ss_offset1 (unsigned char *p)
> +{
> +  return *(short *)(p + 1);  /* should generate LHA.  */
> +}
> +
> +unsigned long
> +load_ui_offset1 (unsigned char *p)
> +{
> +  return *(unsigned int *)(p + 1);   /* should generate LWZ.  */
> +}
> +
> +long
> +load_si_offset1 (unsigned char *p)
> +{
> +  return *(int *)(p + 1);/* should generate PLWA.  */
> +}
> +
> +unsigned long
> +load_ul_offset1 (unsigned char *p)
> +{
> +  return *(unsigned long *)(p + 1);  /* should generate PLD.  */
> +}
> +
> +long
> +load_sl_offset1 (unsigned char *p)
> +{
> +  return *(long *)(p + 1);   /* should generate PLD.  */
> +}
> +
> +float
> +load_float_offset1 (unsigned char *p)
> +{
> +  return *(float *)(p + 1);  /* should generate LFS.  */
> +}
> +
> +double
> +load_double_offset1 (unsigned char *p)
> +{
> +  return *(double *)(p + 1); /* should generate LFD.  */
> +}
> +
> +__float128
> +load_float128_offset1 (unsigned char *p)
> +{
> +  return *(__float128 *)(p + 1); /* should generate PLXV.  */
> +}
> +
> +void
> +store_uc_offset1 (unsigned char uc, unsigned char *p)
> +{
> +  p[1] = uc; /* should generate STB.  */
> +}
> +
> +void
> +store_sc_offset1 (signed char sc, signed char *p)
> +{
> +  p[1] = sc; /* should generate STB.  */
> +}
> +
> +void
> +store_us_offset1 (unsigned short us, unsigned char *p)
> +{
> +  *(unsigned short *)(p + 1) = us;   /* should generate STH.  */
> +}
> +
> +void
> +store_ss_offset1 (signed short ss, unsigned char *p)
> +{
> +  *(signed short *)(p + 1) = ss; /* should generate STH.  */
> +}
> +
> +void
> +store_ui_offset1 (unsigned int ui, unsigned char *p)
> +{
> +  *(unsigned int *)(p + 1) = ui; /* should generate STW.  */
> +}
> +
> +void
> +store_si_offset1 (signed int si, unsigned char *p)
> +{
> +  *(signed int *)(p + 1) = si;   /* should generate STW.  */
> +}
> +
> +void
> +store_ul_offset1 (unsigned long ul, unsigned char *p)
> +{
> +  *(unsigned long *)(p + 1) = ul;/* should generate PSTD.  */
> +}
> +
> +void
> +store_sl_offset1 (signed long sl, unsigned char *p)
> +{
> +  *(signed long *)(p + 1) = sl;  /* should generate PSTD.  */
> +}
> +
> +void
> +store_float_offset1 (float f, unsigned char *p)
> +{
> +  *(float *)(p + 1) = f; /* should generate STF.  */

Comment should be STFD ?

> +}
> +
> +void
> +store_double_offset1 (double d, unsigned char *p)
> +{
> +  *(double *)(p + 1) = d;/* should generate STD.  */

Comment should be STFS ? 

> +}
> +
> +void
> +store_float128_offset1 (__float128 f128, unsigned char *p)
> +{
> +  *(__float128 *)(p + 1) = f128; /* should generate PSTXV.  */
> +}
> +
> +/* { dg-final { scan-assembler-times {\mextsb\M} 1 } } */
> +/* { dg-final { scan-assembler-times {\mlbz\M}   2 } } */
> +/* { dg-final { scan-assembler-times {\mlfd\M}   1 } } */
> +/* { dg-final { scan-assembler-times {\mlfs\M}   1 } } */
> +/* { dg-final { 

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

[Thomas Koenig via Gcc-patches]

Am 21.04.20 um 23:55 schrieb Thomas Koenig:

Hello world,

this one took a bit of detective work.


... and also caused a regression, see PR 94788.

Reverted on trunk so far, so the upcoming release is OK.
This will still take some more work, I suppose...

Regards

Thomas

Re: [PATCH] PowerPC -mcpu=future Patch 2 of 7, Add PLI/PADDI tests

[will schmidt via Gcc-patches]

On Mon, 2020-04-27 at 15:48 -0400, Michael Meissner via Gcc-patches
wrote:
> Add tests for generating PLI/PADDI with -mcpu=future.
> 
> This is patch #2 of 7.  This patch was run on a little endian power8
> system
> running Linux and the patches succeeded.
> 
> 2020-04-27  Michael Meissner  
> 
>   * gcc.target/powerpc/prefix-add.c: New test for -mcpu=future
>   generating PADDI for large constant adds.
>   * gcc.target/powerpc/prefix-di-constant.c: New test for
>   -mcpu=future generating PLI to load up large DImode constants.
>   * gcc.target/powerpc/prefix-si-constant.c: New test for
>   -mcpu=future generating PLI to load up large SImode constants.
> 
> --- /tmp/V53gPm_prefix-add.c  2020-04-27 13:51:49.231124761 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-add.c 2020-04-27 
> 13:51:38.392270487 -0400
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Test that PADDI is generated to add a large constant.  */
> +unsigned long

Just 'long' or should that be 'long long' ? 

otherwise, seems straightforward.

lgtm.

thanks,
-Will



> +add (unsigned long a)
> +{
> +  return a + 0x12345678UL;
> +}
> +
> +/* { dg-final { scan-assembler {\mpaddi\M} } } */
> --- /tmp/5x1erh_prefix-di-constant.c  2020-04-27 13:51:49.239124653 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-di-constant.c 2020-04-27 
> 13:51:38.396270434 -0400
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Test that PLI (PADDI) is generated to load a large constant.  */
> +unsigned long
> +large (void)
> +{
> +  return 0x12345678UL;
> +}
> +
> +/* { dg-final { scan-assembler {\mpli\M} } } */
> --- /tmp/NGLE4b_prefix-si-constant.c  2020-04-27 13:51:49.246124559 -0400
> +++ gcc/testsuite/gcc.target/powerpc/prefix-si-constant.c 2020-04-27 
> 13:51:38.400270380 -0400
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target powerpc_prefixed_addr } */
> +/* { dg-options "-O2 -mdejagnu-cpu=future" } */
> +
> +/* Test that PLI (PADDI) is generated to load a large constant for SImode.  
> */
> +void
> +large_si (unsigned int *p)
> +{
> +  *p = 0x12345U;
> +}
> +
> +/* { dg-final { scan-assembler {\mpli\M} } } */
> 

Re: [PATCH] PowerPC -mcpu=future Patch 1 of 7, add target supports for -mpcrel and -mprefixed

[will schmidt via Gcc-patches]

On Mon, 2020-04-27 at 15:46 -0400, Michael Meissner via Gcc-patches
wrote:
> This patch adds supports in target-supports.exp for -mpcrel and
> -mprefixed.
> 
> Patch #1 of 7.


Hi

Subject: Re: [PATCH] PowerPC -mcpu=future Patch 1 of 7, add target
supports for -mpcrel and -mprefixed

Squish that subject line down a bit if possible. stl

Re: [PATCH 1/7] PowerPC add target supports for -mpcrel and -mprefixed

Can include the "for -mcpu=future" blurb as part of the inline
description if so warranted.

> 
> 2020-04-27  Michael Meissner  
> 
>   * lib/target-supports.exp
> (check_effective_target_powerpc_pcrel):
>   New target for PowerPC -mcpu=future support.
>   (check_effective_target_powerpc_prefixed_addr): New target for
>   PowerPC -mcpu=future support.
> 
> This patch is needed by some of the following patches.
> 
> --- /tmp/ulXyBK_target-supports.exp   2020-04-27 13:45:24.507304508
> -0400
> +++ gcc/testsuite/lib/target-supports.exp 2020-04-27
> 13:45:10.164498029 -0400
> @@ -2189,6 +2189,23 @@ proc check_p9modulo_hw_available { } {
>  }]
>  }
> 
> +# Return 1 if the target generates PC-relative instructions
> automatically
> +proc check_effective_target_powerpc_pcrel { } {
> +return [check_no_messages_and_pattern powerpc_pcrel \
> + {\mpld\M.*[@]pcrel} assembly {
> + static long s;
> + long *p = 
> + long foo (void) { return s; }
> + } {-O2 -mcpu=future}]
> +}
> +
> +# Return 1 if the target generates prefixed instructions
> automatically
> +proc check_effective_target_powerpc_prefixed_addr { } {
> +return [check_no_messages_and_pattern powerpc_prefixed_addr \
> + {\mpld\M} assembly {
> + long foo (long *p) { return p[0x12345]; }
> + } {-O2 -mcpu=future}]
> +}

The syntax matches existing check_effective_target_powerpc test
stanzas.

lgtm.

thanks,
-Will

>  # Return 1 if the target supports executing FUTURE instructions, 0
> otherwise.
>  # Cache the result.  It is assumed that if a simulator does not
> support the
> 

[committed] libphobos: Backport extern(C) bindings from druntime 2.091

[Iain Buclaw via Gcc-patches]

Hi,

This patch merges the D runtime library with upstream druntime 47688279.
Backports latest extern(C) bindings from druntime, fixing PR90718 and
PR90719.  Both of which should be cherry-picked into the gcc-9 branch.

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

Regards
Iain.

---
libphobos/ChangeLog:

* libdruntime/Makefile.am (DRUNTIME_DSOURCES_LINUX): Remove
core/sys/linux/sys/netinet/tcp.d.
* libdruntime/Makefile.in: Regenerate.
---
 libphobos/libdruntime/MERGE   |   2 +-
 libphobos/libdruntime/Makefile.am |  12 +-
 libphobos/libdruntime/Makefile.in |  34 ++--
 libphobos/libdruntime/core/math.d |  52 --
 libphobos/libdruntime/core/stdc/assert_.d |  13 +-
 libphobos/libdruntime/core/stdc/errno.d   |  44 +
 libphobos/libdruntime/core/stdc/stdint.d  |  19 ++-
 libphobos/libdruntime/core/stdc/string.d  |  47 ++---
 .../libdruntime/core/sys/darwin/mach/port.d   |  11 +-
 .../core/sys/darwin/mach/thread_act.d | 100 +++
 .../libdruntime/core/sys/freebsd/dlfcn.d  |  15 +-
 .../libdruntime/core/sys/freebsd/execinfo.d   |   2 +
 libphobos/libdruntime/core/sys/linux/config.d |   3 -
 libphobos/libdruntime/core/sys/linux/link.d   |  10 +-
 .../core/sys/linux/sys/netinet/tcp.d  |   9 -
 .../libdruntime/core/sys/linux/sys/socket.d   |  18 ++
 .../libdruntime/core/sys/linux/timerfd.d  |   1 +
 libphobos/libdruntime/core/sys/posix/config.d |  16 +-
 libphobos/libdruntime/core/sys/posix/dlfcn.d  |  14 --
 .../libdruntime/core/sys/posix/inttypes.d |   4 +-
 libphobos/libdruntime/core/sys/posix/netdb.d  |   4 +-
 libphobos/libdruntime/core/sys/posix/signal.d |  18 +-
 libphobos/libdruntime/core/sys/posix/stdio.d  |  58 +++
 libphobos/libdruntime/core/sys/posix/stdlib.d |  38 -
 .../libdruntime/core/sys/posix/sys/filio.d|  11 +-
 .../libdruntime/core/sys/posix/sys/ioccom.d   |  11 +-
 .../libdruntime/core/sys/posix/sys/resource.d |   1 +
 .../libdruntime/core/sys/posix/sys/select.d   |   3 +-
 .../libdruntime/core/sys/posix/sys/socket.d   |  84 -
 .../libdruntime/core/sys/posix/sys/stat.d |   1 -
 .../libdruntime/core/sys/posix/sys/ttycom.d   |  11 +-
 .../libdruntime/core/sys/posix/sys/types.d|   4 +-
 .../libdruntime/core/sys/posix/sys/uio.d  |   4 +-
 libphobos/libdruntime/core/sys/posix/syslog.d |  60 +++
 libphobos/libdruntime/core/sys/posix/time.d   |   3 +
 libphobos/libdruntime/core/sys/posix/unistd.d | 161 +-
 36 files changed, 691 insertions(+), 207 deletions(-)
 delete mode 100644 libphobos/libdruntime/core/sys/linux/sys/netinet/tcp.d

diff --git a/libphobos/libdruntime/MERGE b/libphobos/libdruntime/MERGE
index e3763485adf..c6357317ddc 100644
--- a/libphobos/libdruntime/MERGE
+++ b/libphobos/libdruntime/MERGE
@@ -1,4 +1,4 @@
-2b5c0b2766949e788e4929c5fb0e2ba698ff79a3
+476882795473a884f837bea6da850ac5181868d1
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/druntime repository.
diff --git a/libphobos/libdruntime/Makefile.am 
b/libphobos/libdruntime/Makefile.am
index e1a38153de0..e1f47d36f90 100644
--- a/libphobos/libdruntime/Makefile.am
+++ b/libphobos/libdruntime/Makefile.am
@@ -255,12 +255,12 @@ DRUNTIME_DSOURCES_LINUX = core/sys/linux/config.d \
core/sys/linux/sched.d core/sys/linux/stdio.d core/sys/linux/string.d \
core/sys/linux/sys/auxv.d core/sys/linux/sys/eventfd.d \
core/sys/linux/sys/file.d core/sys/linux/sys/inotify.d \
-   core/sys/linux/sys/mman.d core/sys/linux/sys/netinet/tcp.d \
-   core/sys/linux/sys/prctl.d core/sys/linux/sys/signalfd.d \
-   core/sys/linux/sys/socket.d core/sys/linux/sys/sysinfo.d \
-   core/sys/linux/sys/time.d core/sys/linux/sys/xattr.d \
-   core/sys/linux/termios.d core/sys/linux/time.d \
-   core/sys/linux/timerfd.d core/sys/linux/tipc.d core/sys/linux/unistd.d
+   core/sys/linux/sys/mman.d core/sys/linux/sys/prctl.d \
+   core/sys/linux/sys/signalfd.d core/sys/linux/sys/socket.d \
+   core/sys/linux/sys/sysinfo.d core/sys/linux/sys/time.d \
+   core/sys/linux/sys/xattr.d core/sys/linux/termios.d \
+   core/sys/linux/time.d core/sys/linux/timerfd.d core/sys/linux/tipc.d \
+   core/sys/linux/unistd.d
 
 DRUNTIME_DSOURCES_NETBSD = core/sys/netbsd/dlfcn.d \
core/sys/netbsd/execinfo.d core/sys/netbsd/string.d \
diff --git a/libphobos/libdruntime/Makefile.in 
b/libphobos/libdruntime/Makefile.in
index 4130e96d7be..53402842cb4 100644
--- a/libphobos/libdruntime/Makefile.in
+++ b/libphobos/libdruntime/Makefile.in
@@ -334,13 +334,12 @@ am__objects_17 = core/sys/linux/config.lo 
core/sys/linux/dlfcn.lo \
core/sys/linux/stdio.lo core/sys/linux/string.lo \
core/sys/linux/sys/auxv.lo core/sys/linux/sys/eventfd.lo \
core/sys/linux/sys/file.lo core/sys/linux/sys/inotify.lo \
-   core/sys/linux/sys/mman.lo 

[PATCH] libstdc++: Fix subrange::advance and subrange::prev (LWG 3433)

[Patrick Palka via Gcc-patches]

This implements the proposed resolution of LWG 3433, which fixes
subrange::advance when called with a negative argument.

Tested on x86_64-pc-linux-gnu, does this look OK to commit?

libstdc++-v3/ChangeLog:

LWG 3433 subrange::advance(n) has UB when n < 0
* include/std/ranges (subrange::prev): Fix typo.
(subrange::advance): Handle a negative argument as per the proposed
resolution of LWG 3433.
* testsuite/std/ranges/subrange/lwg3433.cc: New test.
---
 libstdc++-v3/include/std/ranges   | 25 +++--
 .../testsuite/std/ranges/subrange/lwg3433.cc  | 96 +++
 2 files changed, 111 insertions(+), 10 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/ranges/subrange/lwg3433.cc

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 8f91598c26e..565366a8d2f 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -353,23 +353,28 @@ namespace ranges
requires bidirectional_iterator<_It>
   {
auto __tmp = *this;
-   __tmp.advance(--__n);
+   __tmp.advance(-__n);
return __tmp;
   }
 
   constexpr subrange&
   advance(iter_difference_t<_It> __n)
   {
+   // We incorporate the proposed resolution of LWG 3433 here,
+   // avoiding undefined behavior when __n < 0.
+   if constexpr (bidirectional_iterator<_It>)
+ if (__n < 0)
+   {
+ ranges::advance(_M_begin, __n);
+ if constexpr (_S_store_size)
+   _M_size._M_size += __detail::__to_unsigned_like(-__n);
+ return *this;
+   }
+
+   __glibcxx_assert(__n >= 0);
+   auto __d = __n - ranges::advance(_M_begin, __n, _M_end);
if constexpr (_S_store_size)
- {
-   auto __d = __n - ranges::advance(_M_begin, __n, _M_end);
-   if (__d >= 0)
- _M_size._M_size -= __detail::__to_unsigned_like(__d);
-   else
- _M_size._M_size += __detail::__to_unsigned_like(-__d);
- }
-   else
- ranges::advance(_M_begin, __n, _M_end);
+ _M_size._M_size -= __detail::__to_unsigned_like(__d);
return *this;
   }
 };
diff --git a/libstdc++-v3/testsuite/std/ranges/subrange/lwg3433.cc 
b/libstdc++-v3/testsuite/std/ranges/subrange/lwg3433.cc
new file mode 100644
index 000..2b01729b40f
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/ranges/subrange/lwg3433.cc
@@ -0,0 +1,96 @@
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++2a" }
+// { dg-do run { target c++2a } }
+
+#include 
+#include 
+#include 
+#include 
+
+using __gnu_test::bidirectional_iterator_wrapper;
+using __gnu_test::forward_iterator_wrapper;
+using __gnu_test::test_range;
+using __gnu_test::test_sized_range;
+using __gnu_test::test_sized_range_sized_sent;
+
+namespace ranges = std::ranges;
+
+template
+void
+test01()
+{
+  int x[] = {1,2,3,4,5};
+  Container r{x};
+  ranges::subrange sr = r;
+  constexpr bool sized_range_p = ranges::sized_range;
+  constexpr bool bidirectional_p = ranges::bidirectional_range;
+  VERIFY( ranges::equal(sr, (int[]){1,2,3,4,5}) );
+  if constexpr (sized_range_p)
+VERIFY( sr.size() == 5 );
+
+  sr = sr.next();
+  VERIFY( ranges::equal(sr, (int[]){2,3,4,5}) );
+  if constexpr (sized_range_p)
+VERIFY( sr.size() == 4 );
+
+  sr = std::move(sr.next(2));
+  VERIFY( ranges::equal(sr, (int[]){4,5}) );
+  if constexpr (sized_range_p)
+VERIFY( sr.size() == 2 );
+
+  if constexpr (bidirectional_p)
+{
+  sr = sr.prev(2);
+  VERIFY( ranges::equal(sr, (int[]){2,3,4,5}) );
+  if constexpr (sized_range_p)
+   VERIFY( sr.size() == 4 );
+
+  sr = sr.prev(1);
+  VERIFY( ranges::equal(sr, (int[]){1,2,3,4,5}) );
+  if constexpr (sized_range_p)
+   VERIFY( sr.size() == 5 );
+}
+  else
+sr = r;
+
+  sr.advance(1);
+  VERIFY( ranges::equal(sr, (int[]){2,3,4,5}) );
+  if constexpr (sized_range_p)
+VERIFY( sr.size() == 4 );
+
+  if constexpr (bidirectional_p)
+{
+  sr.advance(-1);
+  VERIFY( ranges::equal(sr, (int[]){1,2,3,4,5}) );
+  if constexpr (sized_range_p)
+   VERIFY( sr.size() == 5 );
+}
+}
+
+int
+main()
+{
+  test01>();
+  

Re: [RFC] Clarify -ffinite-math-only documentation

[Matthias Kretz]

On Montag, 27. April 2020 21:39:17 CEST Richard Sandiford wrote:
> "Dr. Matthias Kretz"  writes:
> > On Montag, 27. April 2020 18:59:08 CEST Richard Sandiford wrote:
> >> Richard Biener via Gcc-patches  writes:
> >> > On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz  wrote:
> >> >> Hi,
> >> >> 
> >> >> This documentation change clarifies the effect of -ffinite-math-only.
> >> >> With the current documentation, it is unclear what the presence of NaN
> >> >> and Inf representations means if (arithmetic) operations on such
> >> >> values
> >> >> are unspecified and even classification functions like isnan are
> >> >> unreliable. If the hardware thinks a certain bit pattern is a NaN, but
> >> >> the software assumes a NaN value cannot ever exist, it is questionable
> >> >> whether, from a language viewpoint, a representation for NaNs really
> >> >> exists. Because, a NaN is defined by its behavior. This change also
> >> >> clarifies that isnan(nan) returning false is fine.
> >> >> 
> >> >> This relates to PR84949.
> >> >> 
> >> >> * doc/invoke.texi: Clarify the effects of -ffinite-math-only.
> >> >> 
> >> >> ---
> >> >> 
> >> >>  gcc/doc/invoke.texi | 6 --
> >> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >> >> 
> >> >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> >> >> index a37a2ee9c19..9e76ab057a9 100644
> >> >> --- a/gcc/doc/invoke.texi
> >> >> +++ b/gcc/doc/invoke.texi
> >> >> @@ -11619,8 +11619,10 @@ The default is @option{-fno-reciprocal-math}.
> >> >> 
> >> >>  @item -ffinite-math-only
> >> >>  @opindex ffinite-math-only
> >> >> 
> >> >> -Allow optimizations for floating-point arithmetic that assume
> >> >> -that arguments and results are not NaNs or +-Infs.
> >> >> +Assume that floating-point types in the language do not have
> >> >> representations for
> >> >> +NaNs and +-Inf. Whether floating-point hardware supports and acts on
> >> >> NaNs and ++-Inf is not affected. The behavior of a program that uses a
> >> >> NaN or +-Inf value
> >> >> +as function argument, macro argument, or operand is undefined.
> >> > 
> >> > Minor nit here - I'd avoid the 'undefined' word which has bad
> >> > connotation
> >> > and use 'unspecified'.  Maybe we can even use ISO C language
> >> > specification
> >> > terms but I'm not sure which one is most appropriate here.
> > 
> > I'm an ISO C++ person, and unspecified sounds too reliable to me:
> > https://wg21.link/intro.defs#defns.unspecified.
> > 
> >> > Curiously __builtin_nan ("nan") still gets you a NaN representation
> >> > but isnan(__builtin_nan("nan")) is resolved to false.
> > 
> > Right, that's because only the hardware thinks __builtin_nan ("nan") is a
> > NaN representation. With -ffinite-math-only, the double data type in
> > C/C++ can either hold a finite real value, or an invalid value (i.e. a
> > value that the optimizer unconditionally excludes as a possible value for
> > any object of floating-point type). FWIW, with -ffinite-math-only, ubsan
> > should flag isnan(__builtin_nan("nan")) or any f(constexpr nan).
> > 
> > With the above documentation change, it is clear that with
> > https://wg21.link/ P1841 std::numbers::quiet_NaN would be
> > ill-formed under -ffinite-math- only. Without the documentation change,
> > it can be argued either way.
> > 
> > There's another interesting observation resulting from the above: double
> > and double under -ffinite-math-only are different types. Any function
> > call from one world to the other is dangerous. Inline functions
> > translated in different TUs compiled with different math flags violate
> > the ODR. But that's all the more reason to have a very precise
> > documentation/understanding of what -ffinite-math-only does. Because this
> > gotcha is already the status quo.> 
> >> Yeah, for that and other reasons, I think it would be good to avoid
> >> giving the impression that -ffinite-math-only can be relied on to make
> >> the assumption above.  Wouldn't it be more accurate to say that the
> >> compiler is allowed to make the assumption, at any point that it seems
> >> convenient?
> > 
> > I think undefined behavior does what you're asking for while unspecified
> > behavior does what you want to avoid. I.e. its an undocumented behavior,
> > but it can be relied on with a given implementation (compiler).
> 
> Although it wasn't obvious from my quoting, I was worried more about
> the wording of the first "Assume X" sentence than the unspecified vs.
> undefined thing.  I think saying "Assume X" loses an important but
> correct nuance of the original wording: that completely ignoring the
> option would be a valid (if not very useful) implementation.  "Assume X"
> instead makes it sound like the compiler is required to do something
> (at least to me).

Fair point. However, I want to make it clear what value to expect from 
std::numeric_limits::has_quiet_NaN. Currently that's up for 
interpretation. Reading C17 5.2.4.2.2/4, which defines quiet NaNs to have a 
certain behavior, I 

Re: [PATCH] c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

[Jakub Jelinek via Gcc-patches]

On Mon, Apr 27, 2020 at 05:11:38PM -0400, Jason Merrill wrote:
> > struct empty { };
> > struct X { [[no_unique_address]] empty e; };
> > 
> > and have them be layout compatible, otherwise the attribute is useless
> > to the standard library.
> 
> Why are zero-size fields changing layout/parameter passing in these ABIs,
> anyway?

There are many affected ABIs and they have different rules.
Some are e.g. looking for homogenous aggregates, say
struct S { float a, b, c, d, e; };
contains just float fields and is passed in floating point registers in some
ABIs, and that is how C++14 represented even
struct empty {};
struct S : public empty { float a, b, c, d, e; };
and with the changes from last week also the C++17.  Thus, I guess
we want to handle
struct T { [[no_unique_address]] empty x; float a, b, c, d, e; };
that way too.  The question is shall that be only when it is the first
field, or at any position as long as it is [[no_unique_address]] FIELD_DECL
with DECL_SIZE of bitsize_zero?  Or do we have to further check that it
really doesn't contain any fields other than empty classes?
E.g. some of the ABIs pass differently:
struct A {};
struct B { A a; float b, c, d; };
struct C { int : 0; };
struct D { C a; float b, c, d; };
because the zero sized bitfield is spelled in the ABI as causing different
behavior.
Other ABIs look for first field and do something if it is of some kind (or
if it is the first and only say float or vector field).
E.g. the powerpc-darwin or powerpc*-aix* ABIs do different alignment
depending on if it is:
struct E {};
struct F { double d; };
or
struct G { E e; double d; };

One can just grep the backends for TYPE_FIELDS walks...

Jakub

[pushed] c++: Avoid ICE with dependent attribute on type.

[Jason Merrill via Gcc-patches]

We previously happened to accept this testcase, but never actually did
anything useful with the attribute.  The patch for PR86379 stopped using
TREE_TYPE as USING_DECL_SCOPE, so 'using A::b' no longer had TREE_TYPE set,
so the language-independent decl_attributes started crashing on it.

GNU attributes are more flexible in their placement than C++11 attributes,
so if we encounter a dependent GNU attribute that syntactically appertains
to a type rather than the declaration as a whole, move it to the
declaration; that's almost certainly what the user meant, anyway.

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

gcc/cp/ChangeLog
2020-01-27  Jason Merrill  

PR c++/90750
PR c++/79585
* decl.c (grokdeclarator): Move dependent attribute to decl.
* decl2.c (splice_template_attributes): No longer static.
---
 gcc/cp/cp-tree.h   |  1 +
 gcc/cp/decl.c  |  4 
 gcc/cp/decl2.c |  2 +-
 gcc/testsuite/g++.dg/ext/attr-type1.C  | 19 +++
 gcc/testsuite/g++.dg/warn/Wunused-var-26.C |  4 ++--
 5 files changed, 27 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/ext/attr-type1.C

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 924c0b9c790..fff0016b3aa 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6626,6 +6626,7 @@ extern tree grokfield (const cp_declarator *, 
cp_decl_specifier_seq *,
   tree, bool, tree, tree);
 extern tree grokbitfield (const cp_declarator *, cp_decl_specifier_seq *,
  tree, tree, tree);
+extern tree splice_template_attributes (tree *, tree);
 extern bool any_dependent_type_attributes_p(tree);
 extern tree cp_reconstruct_complex_type(tree, tree);
 extern bool attributes_naming_typedef_ok   (tree);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 31b5884ca3a..cf855dae909 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -11937,9 +11937,13 @@ grokdeclarator (const cp_declarator *declarator,
attr_flags |= (int) ATTR_FLAG_FUNCTION_NEXT;
  if (declarator->kind == cdk_array)
attr_flags |= (int) ATTR_FLAG_ARRAY_NEXT;
+ /* Assume that any attributes that get applied late to templates will
+DTRT when applied to the declaration as a whole.  */
+ tree late_attrs = splice_template_attributes (, type);
  returned_attrs = decl_attributes (,
chainon (returned_attrs, attrs),
attr_flags);
+ returned_attrs = chainon (late_attrs, returned_attrs);
}
 
   inner_declarator = declarator->declarator;
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 293df990435..ac65529a01d 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -1228,7 +1228,7 @@ is_late_template_attribute (tree attr, tree decl)
the declaration itself is dependent, so all attributes should be applied
at instantiation time.  */
 
-static tree
+tree
 splice_template_attributes (tree *attr_p, tree decl)
 {
   tree *p = attr_p;
diff --git a/gcc/testsuite/g++.dg/ext/attr-type1.C 
b/gcc/testsuite/g++.dg/ext/attr-type1.C
new file mode 100644
index 000..6e84cccea1f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/attr-type1.C
@@ -0,0 +1,19 @@
+// PR c++/90750
+// { dg-do compile { target c++11 } }
+
+template  struct S
+{
+  static const int b = 64;
+};
+
+template  struct T: S
+{
+  using A = S;
+  using A::b;
+  char* __attribute__((aligned(b))) c;
+};
+
+T t;
+
+#define SA(X) static_assert (X,#X)
+SA (alignof(T) == S::b);
diff --git a/gcc/testsuite/g++.dg/warn/Wunused-var-26.C 
b/gcc/testsuite/g++.dg/warn/Wunused-var-26.C
index b3e020b6007..89c53de88a4 100644
--- a/gcc/testsuite/g++.dg/warn/Wunused-var-26.C
+++ b/gcc/testsuite/g++.dg/warn/Wunused-var-26.C
@@ -47,10 +47,10 @@ template 
 void f_var_type_unused ()
 {
   // The variable's type is marked unused.
-  T* UNUSED t = new T;   // { dg-bogus "unused variable" "bug 79585" { xfail 
*-*-* } }
+  T* UNUSED t = new T;   // { dg-bogus "unused variable" "bug 79585" }
 
   typedef T U;
-  U* UNUSED u = new U;   // { dg-bogus "unused variable" "bug 79585" { xfail 
*-*-* } }
+  U* UNUSED u = new U;   // { dg-bogus "unused variable" "bug 79585" }
 
   typedef T UNUSED U;
   U v = U ();   // { dg-bogus "unused variable" "bug 79585" }

base-commit: acdf733634745548c0167c40bad80e6140ac2eeb
-- 
2.18.1

Re: [PATCH] c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

[Jason Merrill via Gcc-patches]

On 4/27/20 3:53 PM, Jonathan Wakely wrote:

On 27/04/20 21:47 +0200, Jakub Jelinek wrote:

On Mon, Apr 27, 2020 at 03:32:29PM -0400, Jason Merrill wrote:

Note that C++20 adds empty non-static data members with the
[[no_unique_address]] attribute.  How will that fit into these ABIs 
and the

others that had issues with parameter passing?


Are they also represented in the trees handed over to the middle-end
as FIELD_DECLs with bitsize_zero DECL_SIZE and TREE_TYPE that contains
padding (like the empty base field does)?


Yes.


Or are they just like say C empty structs in other structs (bitsize_zero
DECL_SIZE and TYPE_SIZE of TREE_TYPE)?



I bet they aren't DECL_ARTIFICIAL, but should have the no_unique_address
attribute on them, so the backends or some helper function in calls.c
could again catch them and decide what to do.


Yes.


I guess at least we don't have an ABI incompatibility between different
-std=* versions,


We kind of do, because the intention of the attribute is to match the
behaviour of the empty base-class optimization.

I need it to be possible to replace this:

struct empty { };
struct X : empty { };

with this:

struct empty { };
struct X { [[no_unique_address]] empty e; };

and have them be layout compatible, otherwise the attribute is useless
to the standard library.


Why are zero-size fields changing layout/parameter passing in these 
ABIs, anyway?


Jason

Re: [PATCH 1/8] testsuite: Fix -mfloat-abi order in arm_v8_2a_bf16_neon_ok and arm_v8_2a_i8mm_ok_nocache

[Mike Stump via Gcc-patches]

On Apr 27, 2020, at 12:43 PM, Christophe Lyon via Gcc-patches 
 wrote:
> It seems it's not possible to write these tests so that they works in
> all combinations of toolchain configuration and options used for testing :-(

So, generally, you can have each change in configuration reflected in a 
preprocessor symbol and each command line change also reflected.  Then, in the 
test case you merely interrogate all the state as necessary to decide.  If that 
weren't enough, then, we'd have some other mechanism that we could interrogate 
with if, and then you'd be off and running.

[ ducks ]

Think

if (__builtin_arm_have_featurea())
  // test case for featurea.
else ...

I can appreciate if the support necessary for the if or the #ifdef is missing, 
but, it could be added.

Re: [PATCH] coroutines: Pass class ref to traits lookup and promise allocator [PR94760]

[Nathan Sidwell]

On 4/27/20 2:41 PM, Iain Sandoe wrote:

Nathan Sidwell  wrote:


On 4/25/20 11:08 AM, Iain Sandoe wrote:



+  tree arg = DECL_ARGUMENTS (fndecl);
+  bool lambda_p = LAMBDA_TYPE_P (DECL_CONTEXT (fndecl));


I think LAMBDA_FUNCTION_P (fndecl) expresses intent better.

done in both places.


+
  parm.this_ptr = is_this_parameter (arg);
+ if (lambda_p)
+   {
+ parm.lambda_cobj = parm.this_ptr
+|| (DECL_NAME (arg) == closure_identifier);


i'm confused by the need for || here.  Why isn't just the DECL_NAME test 
needed?  The parser appears to give the object parameter that name.  (If you do 
need the parm.this_ptr piece, it suggests somewhere else outside of coro is not 
being consistent, but ICBW.)


It seems that, when a lambda is part of a class, the closure object gets the 
name ‘this’.
When a lambda is defined outside a class context, the closure object is named 
__closure.

I added a comment as to why we make the two checks (also, why we can’t just use
is_this_parameter() as the test elsewhere)


+   vec_safe_push (args, arg);
+ else if (0 && parm_i->this_ptr)


^^ looks like now-disabled experimental code?

well caught, now enabled as intended.

thanks for the review is the revised below OK (testing now)

thanks
iain

===

We changed the argument passed to the promise parameter preview
to match a reference to *this.  However to be consistent with the
other ports, we do need to match the reference transformation in
the traits lookup and the promise allocator lookup.

gcc/cp/ChangeLog:

2020-04-27  Iain Sandoe  

PR c++/94760
* coroutines.cc (instantiate_coro_traits): Pass a reference to
object type rather than a pointer type for 'this', for method
coroutines.
(struct param_info): Add a field to hold that the parm is a lambda
closure pointer.
(morph_fn_to_coro): Check for lambda closure pointers in the
args.  Use a reference to *this when building the args list for the
promise allocator lookup.

gcc/testsuite/ChangeLog:

2020-04-27  Iain Sandoe  

PR c++/94760
* g++.dg/coroutines/pr94760-mismatched-traits-and-promise-prev.C: New 
test.
---
  gcc/cp/coroutines.cc  | 54 +--
  ...9-mismatched-traits-and-promise-prev.C | 29 ++
  2 files changed, 79 insertions(+), 4 deletions(-)
  create mode 100644 
gcc/testsuite/g++.dg/coroutines/pr9-mismatched-traits-and-promise-prev.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 0a5a0c9b1d2..cfaa018c551 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -296,14 +296,25 @@ instantiate_coro_traits (tree fndecl, location_t kw)
   type.  */
  
tree functyp = TREE_TYPE (fndecl);

+  tree arg = DECL_ARGUMENTS (fndecl);
+  bool lambda_p = LAMBDA_FUNCTION_P (fndecl);
tree arg_node = TYPE_ARG_TYPES (functyp);
tree argtypes = make_tree_vec (list_length (arg_node)-1);
unsigned p = 0;
  
while (arg_node != NULL_TREE && !VOID_TYPE_P (TREE_VALUE (arg_node)))

  {
-  TREE_VEC_ELT (argtypes, p++) = TREE_VALUE (arg_node);
+  if (is_this_parameter (arg) && !lambda_p)
+   {
+ /* We pass a reference to *this to the param preview.  */
+ tree ct = TREE_TYPE (TREE_TYPE (arg));
+ TREE_VEC_ELT (argtypes, p++) = cp_build_reference_type (ct, false);
+   }
+  else
+   TREE_VEC_ELT (argtypes, p++) = TREE_VALUE (arg_node);
+
arg_node = TREE_CHAIN (arg_node);
+  arg = DECL_CHAIN (arg);
  }
  
tree argtypepack = cxx_make_type (TYPE_ARGUMENT_PACK);

@@ -1766,6 +1777,7 @@ struct param_info
bool pt_ref;   /* Was a pointer to object.  */
bool trivial_dtor; /* The frame type has a trivial DTOR.  */
bool this_ptr; /* Is 'this' */
+  bool lambda_cobj;  /* Lambda capture object */
  };
  
  struct local_var_info

@@ -3652,6 +3664,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
  The second two entries start out empty - and only get populated
  when we see uses.  */
param_uses = new hash_map;
+  bool lambda_p = LAMBDA_FUNCTION_P (orig);
  
unsigned no_name_parm = 0;

for (tree arg = DECL_ARGUMENTS (orig); arg != NULL;
@@ -3692,7 +3705,19 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
}
  else
parm.frame_type = actual_type;
+
+ /* The closure object pointer is called 'this' when a lambda is
+part of a class, and __closure when it is not.  */


It turns out this occurs when tsubsting a lambda.  I.e. whenever the 
lambda is inside a templated function (real or pseudo).  IMHO that;s a 
bug in the template machinery, but let's not fix that right now, I have 
filed 94807.  Just update the comment to describe this as occurring 
during instantiation.


your patch is ok otherwise, thanks.

nathan

--
Nathan Sidwell

[PATCH] PowerPC -mcpu=future Patch 7 of 7, Add test for stack checking and large stack frames

[Michael Meissner via Gcc-patches]

This patch adds a test for the case where we have prefixed load/store
instructions, a large stack frame, and stack checking is enabled.

This is patch #7 of 7.  I have checked this patch on a little endian power8
system running Linux, and the test passed.  Can I check this into the GCC 10
trunk?

2020-04-27  Michael Meissner  

* gcc.target/powerpc/prefix-stack-protect.c: New test to make sure
-fstack-protect-strong works with prefixed addressing.

--- /tmp/OxuBEg_prefix-stack-protect.c  2020-04-27 14:12:53.883004507 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-stack-protect.c 2020-04-27 
14:12:53.706006931 -0400
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future -fstack-protector-strong" } */
+
+/* Test that we can handle large stack frames with -fstack-protector-strong and
+   prefixed addressing.  This was originally discovered in trying to build
+   glibc with -mcpu=future, and vfwprintf.c failed because it used
+   -fstack-protector-strong.  */
+
+extern long foo (char *);
+
+long
+bar (void)
+{
+  char buffer[0x2];
+  return foo (buffer) + 1;
+}
+
+/* { dg-final { scan-assembler {\mpld\M}  } } */
+/* { dg-final { scan-assembler {\mpstd\M} } } */

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

[PATCH] PowerPC -mcpu=future Patch 6 of 7, add PC-relative tests

[Michael Meissner via Gcc-patches]

This patch adds PC-relative tests for -mcpu=future.

This is patch #6 of 7.  I have checked this on a little endian power8 system
running Linux, and all tests passed.  Can I check this into the GCC 10 trunk?

2020-04-27  Michael Meissner  

* gcc.target/powerpc/prefix-pcrel.h: New set of tests to test
prefixed addressing on 'future' system with PC-relative addresses
for various types.
* gcc.target/powerpc/prefix-pcrel-dd.c: New test for prefixed
loads/stores with PC-relative addresses for the _Decimal64 type.
* gcc.target/powerpc/prefix-pcrel-df.c: New test for prefixed
loads/stores with PC-relative addresses for the double type.
* gcc.target/powerpc/prefix-pcrel-di.c: New test for prefixed
loads/stores with PC-relative addresses for the long type.
* gcc.target/powerpc/prefix-pcrel-hi.c: New test for prefixed
loads/stores with PC-relative addresses for the short type.
* gcc.target/powerpc/prefix-pcrel-kf.c: New test for prefixed
loads/stores with PC-relative addresses for the __float128 type.
* gcc.target/powerpc/prefix-pcrel-qi.c: New test for prefixed
loads/stores with PC-relative addresses for the signed char type.
* gcc.target/powerpc/prefix-pcrel-sd.c: New test for prefixed
loads/stores with PC-relative addresses for the _Decimal32 type.
* gcc.target/powerpc/prefix-pcrel-sf.c: New test for prefixed
loads/stores with PC-relative addresses for the float type.
* gcc.target/powerpc/prefix-pcrel-si.c: New test for prefixed
loads/stores with PC-relative addresses for the int type.
* gcc.target/powerpc/prefix-pcrel-udi.c: New test for prefixed
loads/stores with PC-relative addresses for the unsigned long
type.
* gcc.target/powerpc/prefix-pcrel-uhi.c: New test for prefixed
loads/stores with PC-relative addresses for the unsigned short
type.
* gcc.target/powerpc/prefix-pcrel-uqi.c: New test for prefixed
loads/stores with PC-relative addresses for the unsigned char
type.
* gcc.target/powerpc/prefix-pcrel-usi.c: New test for prefixed
loads/stores with PC-relative addresses for the unsigned int
type.
* gcc.target/powerpc/prefix-pcrel-v2df.c: New test for prefixed
loads/stores with PC-relative addresses for the vector double
type.

--- /tmp/61oqzU_prefix-pcrel-dd.c   2020-04-27 14:11:22.981249397 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-dd.c  2020-04-27 
14:11:22.751252547 -0400
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for the _Decimal64 type.  */
+
+#define TYPE _Decimal64
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {[@]pcrel}  4 } } */
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
--- /tmp/w5tyiy_prefix-pcrel-df.c   2020-04-27 14:11:22.990249274 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-df.c  2020-04-27 
14:11:22.755252492 -0400
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for the double type.  */
+
+#define TYPE double
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {[@]pcrel}  4 } } */
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
--- /tmp/uE672b_prefix-pcrel-di.c   2020-04-27 14:11:22.998249164 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-di.c  2020-04-27 
14:11:22.759252437 -0400
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for the long type.  */
+
+#define TYPE long
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { scan-assembler-times {[@]pcrel} 4 } } */
+/* { dg-final { scan-assembler-times {\mpld\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstd\M} 2 } } */
--- /tmp/UHt8OP_prefix-pcrel-hi.c   2020-04-27 14:11:23.005249069 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-pcrel-hi.c  2020-04-27 
14:11:22.763252383 -0400
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_pcrel } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether pc-relative prefixed
+   instructions are generated for the short type.  */
+
+#define TYPE short
+
+#include "prefix-pcrel.h"
+
+/* { dg-final { 

[PATCH] PowerPC -mcpu=future Patch 5 of 7, Add prefixed load/store tests with large numeric offsets

[Michael Meissner via Gcc-patches]

This patch adds tests for -mcpu=future generating prefixed load/store
instructions with large numeric offsets.

This is patch #5 of 7.  This patch was tested on a little endian power8 system
running Linux, and the tests passed.  Can I check this into GCC 10?

2020-04-27  Michael Meissner  

* gcc.target/powerpc/prefix-large.h: New set of tests to test
prefixed addressing on 'future' system with large numeric offsets
for various types.
* gcc.target/powerpc/prefix-large-dd.c: New test for prefixed
loads/stores with large offsets for the _Decimal64 type.
* gcc.target/powerpc/prefix-large-df.c: New test for prefixed
loads/stores with large offsets for the double type.
* gcc.target/powerpc/prefix-large-di.c: New test for prefixed
loads/stores with large offsets for the long type.
* gcc.target/powerpc/prefix-large-hi.c: New test for prefixed
loads/stores with large offsets for the short type.
* gcc.target/powerpc/prefix-large-kf.c: New test for prefixed
loads/stores with large offsets for the __float128 type.
* gcc.target/powerpc/prefix-large-qi.c: New test for prefixed
loads/stores with large offsets for the signed char type.
* gcc.target/powerpc/prefix-large-sd.c: New test for prefixed
loads/stores with large offsets for the _Decimal32 type.
* gcc.target/powerpc/prefix-large-sf.c: New test for prefixed
loads/stores with large offsets for the float type.
* gcc.target/powerpc/prefix-large-si.c: New test for prefixed
loads/stores with large offsets for the int type.
* gcc.target/powerpc/prefix-large-udi.c: New test for prefixed
loads/stores with large offsets for the unsigned long type.
* gcc.target/powerpc/prefix-large-uhi.c: New test for prefixed
loads/stores with large offsets for the unsigned short type.
* gcc.target/powerpc/prefix-large-uqi.c: New test for prefixed
loads/stores with large offsets for the unsigned char type.
* gcc.target/powerpc/prefix-large-usi.c: New test for prefixed
loads/stores with large offsets for the unsigned int type.
* gcc.target/powerpc/prefix-large-v2df.c: New test for prefixed
loads/stores with large offsets for the vector double type.

--- /tmp/ky2ZAZ_prefix-large-dd.c   2020-04-27 14:05:05.638417056 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-dd.c  2020-04-27 
14:05:05.406420175 -0400
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset for _Decimal64 objects.  */
+
+#define TYPE _Decimal64
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
--- /tmp/HDrUG4_prefix-large-df.c   2020-04-27 14:05:05.647416935 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-df.c  2020-04-27 
14:05:05.411420108 -0400
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset for double objects.  */
+
+#define TYPE double
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mplfd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstfd\M} 2 } } */
--- /tmp/eqa8N9_prefix-large-di.c   2020-04-27 14:05:05.654416841 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-di.c  2020-04-27 
14:05:05.415420054 -0400
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset for long objects.  */
+
+#define TYPE long
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mpld\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstd\M} 2 } } */
--- /tmp/jLewWe_prefix-large-hi.c   2020-04-27 14:05:05.660416760 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-large-hi.c  2020-04-27 
14:05:05.41942 -0400
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests for prefixed instructions testing whether we can generate a prefixed
+   load/store instruction that has a 34-bit offset for short objects.  */
+
+#define TYPE short
+
+#include "prefix-large.h"
+
+/* { dg-final { scan-assembler-times {\mplh[az]\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpsth\M} 2 } } */
--- /tmp/ea0a6j_prefix-large-kf.c   

[PATCH] PowerPC -mcpu=future Patch 4 of 7, Make sure an invalid instruction is not generated

[Michael Meissner via Gcc-patches]

This test validates that the compiler does not generate a prefixed load/store
instruction with an update form.  The prefixed load/store instructions do not
have an update form.

This is patch #4 of 7.  This patch was run on a little endian power8 system
running Linux, and the tests passed.  Can I check this into the trunk?

2020-04-27  Michael Meissner  

* gcc.target/powerpc/prefix-no-premodify.c: Make sure we do not
generate the non-existent PLWZU instruction if -mcpu=future.

--- /tmp/zijQUT_prefix-no-premodify.c   2020-04-27 14:01:44.465121833 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-no-premodify.c  2020-04-27 
14:01:44.288124213 -0400
@@ -0,0 +1,50 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Make sure that we don't generate a prefixed form of the load and store with
+   update instructions (i.e. instead of generating LWZU we have to generate
+   PLWZ plus a PADDI).  */
+
+#ifndef SIZE
+#define SIZE 5
+#endif
+
+struct foo {
+  unsigned int field;
+  char pad[SIZE];
+};
+
+struct foo *inc_load (struct foo *p, unsigned int *q)
+{
+  *q = (++p)->field;   /* PLWZ, PADDI, STW.  */
+  return p;
+}
+
+struct foo *dec_load (struct foo *p, unsigned int *q)
+{
+  *q = (--p)->field;   /* PLWZ, PADDI, STW.  */
+  return p;
+}
+
+struct foo *inc_store (struct foo *p, unsigned int *q)
+{
+  (++p)->field = *q;   /* LWZ, PADDI, PSTW.  */
+  return p;
+}
+
+struct foo *dec_store (struct foo *p, unsigned int *q)
+{
+  (--p)->field = *q;   /* LWZ, PADDI, PSTW.  */
+  return p;
+}
+
+/* { dg-final { scan-assembler-times {\mlwz\M}2 } } */
+/* { dg-final { scan-assembler-times {\mstw\M}2 } } */
+/* { dg-final { scan-assembler-times {\mpaddi\M}  4 } } */
+/* { dg-final { scan-assembler-times {\mplwz\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mpstw\M}   2 } } */
+/* { dg-final { scan-assembler-not   {\mplwzu\M}} } */
+/* { dg-final { scan-assembler-not   {\mpstwu\M}} } */
+/* { dg-final { scan-assembler-not   {\maddis\M}} } */
+/* { dg-final { scan-assembler-not   {\maddi\M} } } */

-- 
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++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

[Jonathan Wakely via Gcc-patches]

On 27/04/20 21:47 +0200, Jakub Jelinek wrote:

On Mon, Apr 27, 2020 at 03:32:29PM -0400, Jason Merrill wrote:

Note that C++20 adds empty non-static data members with the
[[no_unique_address]] attribute.  How will that fit into these ABIs and the
others that had issues with parameter passing?


Are they also represented in the trees handed over to the middle-end
as FIELD_DECLs with bitsize_zero DECL_SIZE and TREE_TYPE that contains
padding (like the empty base field does)?
Or are they just like say C empty structs in other structs (bitsize_zero
DECL_SIZE and TYPE_SIZE of TREE_TYPE)?
I bet they aren't DECL_ARTIFICIAL, but should have the no_unique_address
attribute on them, so the backends or some helper function in calls.c
could again catch them and decide what to do.

I guess at least we don't have an ABI incompatibility between different
-std=* versions,


We kind of do, because the intention of the attribute is to match the
behaviour of the empty base-class optimization.

I need it to be possible to replace this:

struct empty { };
struct X : empty { };

with this:

struct empty { };
struct X { [[no_unique_address]] empty e; };

and have them be layout compatible, otherwise the attribute is useless
to the standard library.


and given that it seems clang++ also implements it,
it will be worth checking the passing against it.


Yes that's a good idea.

[PATCH] PowerPC -mcpu=future Patch 3 of 7, Add test for generating prefixed load/store

[Michael Meissner via Gcc-patches]

This patch adds a test that verifies that the compiler generates a prefixed
load/store instruction where the compiler cannot generate the instruction
directly because the offset is not a valid DS or DQ offset.  A DS offset must
have the bottom 2 bits clear.  A DQ offset must have the bottom 4 bits clear.
Due to the way PowerPC instructions are encoded, some instructions use the DS
format and some use the DQ format.

This is patch #3 of 7.  The tests in this patch run on a little endian power8
system running Linux.

2020-04-27  Michael Meissner  

* gcc.target/powerpc/prefix-ds-dq.c: New test to verify that we
generate the prefix load/store instructions for traditional
instructions with an offset that doesn't match DS/DQ
requirements.

--- /tmp/dtFbYL_prefix-ds-dq.c  2020-04-27 13:54:38.350850944 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-ds-dq.c 2020-04-27 
13:54:15.301160847 -0400
@@ -0,0 +1,156 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Tests whether we generate a prefixed load/store operation for addresses that
+   don't meet DS/DQ offset constraints.  */
+
+unsigned long
+load_uc_offset1 (unsigned char *p)
+{
+  return p[1]; /* should generate LBZ.  */
+}
+
+long
+load_sc_offset1 (signed char *p)
+{
+  return p[1]; /* should generate LBZ + EXTSB.  */
+}
+
+unsigned long
+load_us_offset1 (unsigned char *p)
+{
+  return *(unsigned short *)(p + 1);   /* should generate LHZ.  */
+}
+
+long
+load_ss_offset1 (unsigned char *p)
+{
+  return *(short *)(p + 1);/* should generate LHA.  */
+}
+
+unsigned long
+load_ui_offset1 (unsigned char *p)
+{
+  return *(unsigned int *)(p + 1); /* should generate LWZ.  */
+}
+
+long
+load_si_offset1 (unsigned char *p)
+{
+  return *(int *)(p + 1);  /* should generate PLWA.  */
+}
+
+unsigned long
+load_ul_offset1 (unsigned char *p)
+{
+  return *(unsigned long *)(p + 1);/* should generate PLD.  */
+}
+
+long
+load_sl_offset1 (unsigned char *p)
+{
+  return *(long *)(p + 1); /* should generate PLD.  */
+}
+
+float
+load_float_offset1 (unsigned char *p)
+{
+  return *(float *)(p + 1);/* should generate LFS.  */
+}
+
+double
+load_double_offset1 (unsigned char *p)
+{
+  return *(double *)(p + 1);   /* should generate LFD.  */
+}
+
+__float128
+load_float128_offset1 (unsigned char *p)
+{
+  return *(__float128 *)(p + 1);   /* should generate PLXV.  */
+}
+
+void
+store_uc_offset1 (unsigned char uc, unsigned char *p)
+{
+  p[1] = uc;   /* should generate STB.  */
+}
+
+void
+store_sc_offset1 (signed char sc, signed char *p)
+{
+  p[1] = sc;   /* should generate STB.  */
+}
+
+void
+store_us_offset1 (unsigned short us, unsigned char *p)
+{
+  *(unsigned short *)(p + 1) = us; /* should generate STH.  */
+}
+
+void
+store_ss_offset1 (signed short ss, unsigned char *p)
+{
+  *(signed short *)(p + 1) = ss;   /* should generate STH.  */
+}
+
+void
+store_ui_offset1 (unsigned int ui, unsigned char *p)
+{
+  *(unsigned int *)(p + 1) = ui;   /* should generate STW.  */
+}
+
+void
+store_si_offset1 (signed int si, unsigned char *p)
+{
+  *(signed int *)(p + 1) = si; /* should generate STW.  */
+}
+
+void
+store_ul_offset1 (unsigned long ul, unsigned char *p)
+{
+  *(unsigned long *)(p + 1) = ul;  /* should generate PSTD.  */
+}
+
+void
+store_sl_offset1 (signed long sl, unsigned char *p)
+{
+  *(signed long *)(p + 1) = sl;/* should generate PSTD.  */
+}
+
+void
+store_float_offset1 (float f, unsigned char *p)
+{
+  *(float *)(p + 1) = f;   /* should generate STF.  */
+}
+
+void
+store_double_offset1 (double d, unsigned char *p)
+{
+  *(double *)(p + 1) = d;  /* should generate STD.  */
+}
+
+void
+store_float128_offset1 (__float128 f128, unsigned char *p)
+{
+  *(__float128 *)(p + 1) = f128;   /* should generate PSTXV.  */
+}
+
+/* { dg-final { scan-assembler-times {\mextsb\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mlbz\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mlfd\M}   1 } } */
+/* { dg-final { scan-assembler-times {\mlfs\M}   1 } } */
+/* { dg-final { scan-assembler-times {\mlha\M}   1 } } */
+/* { dg-final { scan-assembler-times {\mlhz\M}   1 } } */
+/* { dg-final { scan-assembler-times {\mlwz\M}   1 } } */
+/* { dg-final { scan-assembler-times {\mpld\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mplwa\M}  1 } } */
+/* { dg-final { scan-assembler-times {\mplxv\M}  1 } } */
+/* { dg-final { scan-assembler-times {\mpstd\M}  2 } } */
+/* { dg-final { scan-assembler-times {\mpstxv\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mstb\M}   2 } } */
+/* { dg-final { scan-assembler-times {\mstfd\M}  1 } } */
+/* { dg-final { scan-assembler-times {\mstfs\M}  1 } } */
+/* { dg-final { 

[PATCH] PowerPC -mcpu=future Patch 2 of 7, Add PLI/PADDI tests

[Michael Meissner via Gcc-patches]

Add tests for generating PLI/PADDI with -mcpu=future.

This is patch #2 of 7.  This patch was run on a little endian power8 system
running Linux and the patches succeeded.

2020-04-27  Michael Meissner  

* gcc.target/powerpc/prefix-add.c: New test for -mcpu=future
generating PADDI for large constant adds.
* gcc.target/powerpc/prefix-di-constant.c: New test for
-mcpu=future generating PLI to load up large DImode constants.
* gcc.target/powerpc/prefix-si-constant.c: New test for
-mcpu=future generating PLI to load up large SImode constants.

--- /tmp/V53gPm_prefix-add.c2020-04-27 13:51:49.231124761 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-add.c   2020-04-27 
13:51:38.392270487 -0400
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test that PADDI is generated to add a large constant.  */
+unsigned long
+add (unsigned long a)
+{
+  return a + 0x12345678UL;
+}
+
+/* { dg-final { scan-assembler {\mpaddi\M} } } */
--- /tmp/5x1erh_prefix-di-constant.c2020-04-27 13:51:49.239124653 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-di-constant.c   2020-04-27 
13:51:38.396270434 -0400
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test that PLI (PADDI) is generated to load a large constant.  */
+unsigned long
+large (void)
+{
+  return 0x12345678UL;
+}
+
+/* { dg-final { scan-assembler {\mpli\M} } } */
--- /tmp/NGLE4b_prefix-si-constant.c2020-04-27 13:51:49.246124559 -0400
+++ gcc/testsuite/gcc.target/powerpc/prefix-si-constant.c   2020-04-27 
13:51:38.400270380 -0400
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_prefixed_addr } */
+/* { dg-options "-O2 -mdejagnu-cpu=future" } */
+
+/* Test that PLI (PADDI) is generated to load a large constant for SImode.  */
+void
+large_si (unsigned int *p)
+{
+  *p = 0x12345U;
+}
+
+/* { dg-final { scan-assembler {\mpli\M} } } */

-- 
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++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

[Jakub Jelinek via Gcc-patches]

On Mon, Apr 27, 2020 at 03:32:29PM -0400, Jason Merrill wrote:
> Note that C++20 adds empty non-static data members with the
> [[no_unique_address]] attribute.  How will that fit into these ABIs and the
> others that had issues with parameter passing?

Are they also represented in the trees handed over to the middle-end
as FIELD_DECLs with bitsize_zero DECL_SIZE and TREE_TYPE that contains
padding (like the empty base field does)?
Or are they just like say C empty structs in other structs (bitsize_zero
DECL_SIZE and TYPE_SIZE of TREE_TYPE)?
I bet they aren't DECL_ARTIFICIAL, but should have the no_unique_address
attribute on them, so the backends or some helper function in calls.c
could again catch them and decide what to do.

I guess at least we don't have an ABI incompatibility between different
-std=* versions, and given that it seems clang++ also implements it,
it will be worth checking the passing against it.

Jakub

Re: [PATCH] PowerPC -mcpu=future Patch 1 of 7, add target supports for -mpcrel and -mprefixed

[Michael Meissner via Gcc-patches]

This patch adds supports in target-supports.exp for -mpcrel and -mprefixed.

Patch #1 of 7.

2020-04-27  Michael Meissner  

* lib/target-supports.exp (check_effective_target_powerpc_pcrel):
New target for PowerPC -mcpu=future support.
(check_effective_target_powerpc_prefixed_addr): New target for
PowerPC -mcpu=future support.

This patch is needed by some of the following patches.

--- /tmp/ulXyBK_target-supports.exp 2020-04-27 13:45:24.507304508 -0400
+++ gcc/testsuite/lib/target-supports.exp   2020-04-27 13:45:10.164498029 
-0400
@@ -2189,6 +2189,23 @@ proc check_p9modulo_hw_available { } {
 }]
 }
 
+# Return 1 if the target generates PC-relative instructions automatically
+proc check_effective_target_powerpc_pcrel { } {
+return [check_no_messages_and_pattern powerpc_pcrel \
+   {\mpld\M.*[@]pcrel} assembly {
+   static long s;
+   long *p = 
+   long foo (void) { return s; }
+   } {-O2 -mcpu=future}]
+}
+
+# Return 1 if the target generates prefixed instructions automatically
+proc check_effective_target_powerpc_prefixed_addr { } {
+return [check_no_messages_and_pattern powerpc_prefixed_addr \
+   {\mpld\M} assembly {
+   long foo (long *p) { return p[0x12345]; }
+   } {-O2 -mcpu=future}]
+}
 
 # Return 1 if the target supports executing FUTURE instructions, 0 otherwise.
 # Cache the result.  It is assumed that if a simulator does not support the

-- 
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 1/8] testsuite: Fix -mfloat-abi order in arm_v8_2a_bf16_neon_ok and arm_v8_2a_i8mm_ok_nocache

[Christophe Lyon via Gcc-patches]

On Thu, 23 Apr 2020 at 15:55, Christophe Lyon
 wrote:
>
> Make the order in which we try -mfloat-abi options consistent with the
> other similar effective targets: try softfp first, then hard.
>
> We have new failures on arm-eabi:
> FAIL: gcc.target/arm/bfloat16_scalar_1_1.c check-function-bodies stacktest1
> FAIL: gcc.target/arm/bfloat16_simd_1_1.c check-function-bodies stacktest1
> FAIL: gcc.target/arm/bfloat16_simd_1_1.c check-function-bodies stacktest2
> FAIL: gcc.target/arm/bfloat16_simd_1_1.c check-function-bodies stacktest3
> FAIL: gcc.target/arm/simd/bf16_ma_1.c check-function-bodies test_vfmabq_f32
> FAIL: gcc.target/arm/simd/bf16_ma_1.c check-function-bodies 
> test_vfmabq_lane_f32
> FAIL: gcc.target/arm/simd/bf16_ma_1.c check-function-bodies 
> test_vfmabq_laneq_f32
> FAIL: gcc.target/arm/simd/bf16_ma_1.c check-function-bodies test_vfmatq_f32
> FAIL: gcc.target/arm/simd/bf16_ma_1.c check-function-bodies 
> test_vfmatq_lane_f32
> FAIL: gcc.target/arm/simd/bf16_ma_1.c check-function-bodies 
> test_vfmatq_laneq_f32
> FAIL: gcc.target/arm/simd/bf16_mmla_1.c check-function-bodies test_vmmlaq_f32
> FAIL: gcc.target/arm/simd/vdot-2-1.c check-function-bodies sfoo_lane
> FAIL: gcc.target/arm/simd/vdot-2-1.c check-function-bodies sfooq_lane
> FAIL: gcc.target/arm/simd/vdot-2-1.c check-function-bodies usfoo
> FAIL: gcc.target/arm/simd/vdot-2-1.c check-function-bodies usfoo_lane
> FAIL: gcc.target/arm/simd/vdot-2-1.c check-function-bodies usfoo_lane_untied
> FAIL: gcc.target/arm/simd/vdot-2-1.c check-function-bodies usfoo_untied
> FAIL: gcc.target/arm/simd/vdot-2-1.c check-function-bodies usfooq_lane
> FAIL: gcc.target/arm/simd/vdot-2-2.c check-function-bodies sfoo_lane
> FAIL: gcc.target/arm/simd/vdot-2-2.c check-function-bodies sfooq_lane
> FAIL: gcc.target/arm/simd/vdot-2-2.c check-function-bodies usfoo
> FAIL: gcc.target/arm/simd/vdot-2-2.c check-function-bodies usfoo_lane
> FAIL: gcc.target/arm/simd/vdot-2-2.c check-function-bodies usfoo_lane_untied
> FAIL: gcc.target/arm/simd/vdot-2-2.c check-function-bodies usfoo_untied
> FAIL: gcc.target/arm/simd/vdot-2-2.c check-function-bodies usfooq_lane
>
> are these tests supposed to require -float-abi=hard?
>

Hmm, actually they do because the check-funciton-bodies are tailored
to float-abi=hard prologue/epilogue.

It's tricky to make it work, as the result depends on how the
toolchain is configured.
For instance on arm-eabi with the default cpu/fpu,
dg-require-effective-target arm_hard_ok fails because:
cc1: error: '-mfloat-abi=hard': selected processor lacks an FPU

but the other effective-target used by these tests (eg
arm_v8_2a_fp16_scalar_ok force an FPU, so then it's OK to force
-mfloat-abi=hard.
However this really works only if the target supports that multlib,
which may not be the case.

It seems it's not possible to write these tests so that they works in
all combinations of
toolchain configuration and options used for testing :-(


> 2020-04-21  Christophe Lyon  
>
> gcc/testsuite/
> * lib/target-supports.exp
> (check_effective_target_arm_v8_2a_i8mm_ok_nocache): Fix
> -mfloat-abi= options order.
> (check_effective_target_arm_v8_2a_bf16_neon_ok_nocache): Likewise.
> ---
>  gcc/testsuite/lib/target-supports.exp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index a667ddf..53ff2f6 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -5017,7 +5017,7 @@ proc check_effective_target_arm_v8_2a_i8mm_ok_nocache { 
> } {
>
>  # Iterate through sets of options to find the compiler flags that
>  # need to be added to the -march option.
> -foreach flags {"" "-mfloat-abi=hard -mfpu=neon-fp-armv8" 
> "-mfloat-abi=softfp -mfpu=neon-fp-armv8" } {
> +foreach flags {"" "-mfloat-abi=softfp -mfpu=neon-fp-armv8" 
> "-mfloat-abi=hard -mfpu=neon-fp-armv8" } {
>  if { [check_no_compiler_messages_nocache \
>arm_v8_2a_i8mm_ok object {
>  #include 
> @@ -5102,7 +5102,7 @@ proc 
> check_effective_target_arm_v8_2a_bf16_neon_ok_nocache { } {
>  return 0;
>  }
>
> -foreach flags {"" "-mfloat-abi=hard -mfpu=neon-fp-armv8" 
> "-mfloat-abi=softfp -mfpu=neon-fp-armv8" } {
> +foreach flags {"" "-mfloat-abi=softfp -mfpu=neon-fp-armv8" 
> "-mfloat-abi=hard -mfpu=neon-fp-armv8" } {
>  if { [check_no_compiler_messages_nocache arm_v8_2a_bf16_neon_ok 
> object {
>  #include 
>  #if !defined (__ARM_FEATURE_BF16_VECTOR_ARITHMETIC)
> --
> 2.7.4
>

[PATCH] PowerPC -mcpu=future tests, Introduction

[Michael Meissner via Gcc-patches]

This patch will allow me to group the 7 patches I have for GCC 10 to test the
various -mcpu=future features.

There are 7 patches in this patch set:

Patch #1: Add target support for -mpcrel and -mprefixed.

Patch #2: Test that PLI/PADDI is generated to load or add large constants.

Patch #3: Add a test to make sure a prefixed load/store is generated in the
case where an offset is invalid for a DS/DQ memory instruction.

Patch #4: Add a test to make sure we do not generate the invalid prefixed
load/store instruction with update.

Patch #5: Add tests to insure prefixed loads or stores are generated when the
offset is a numeric value larger than 16 bits.

Patch #6: Add tests to insure that the PC-relative instructions are generated
to access static data items.

Patch #7: Add a test to check that we generate appropriate code when stack
checking is on and we have a large stack frame.

Versions of all of these patches have been submitted before, but some of them
neeed the -mpcrel support to be enabled before the test would succeed.  All of
these patches run on a little endian power8 computer running Linux.

-- 
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++: Delegating constructor in constexpr init [PR94772]

[Jason Merrill via Gcc-patches]

On 4/27/20 3:33 PM, Patrick Palka wrote:

On Mon, 27 Apr 2020, Jason Merrill wrote:


On 4/27/20 10:45 AM, Patrick Palka wrote:

On Mon, 27 Apr 2020, Patrick Palka wrote:


On Mon, 27 Apr 2020, Jason Merrill wrote:


On 4/26/20 6:48 PM, Patrick Palka wrote:

In the testcase below, the call to the target constructor foo{} from
foo's
delegating constructor is encoded as the INIT_EXPR

 *(struct foo *) this = AGGR_INIT_EXPR <4, __ct_comp, D.2140, ...>;

During initialization of the variable 'bar', we prematurely set
TREE_READONLY on
bar's CONSTRUCTOR in two places before the outer delegating
constructor has
returned: first, at the end of cxx_eval_call_expression after
evaluating the
RHS
of the above INIT_EXPR, and second, at the end of
cxx_eval_store_expression
after having finished evaluating the above INIT_EXPR.  This then
prevents
the
rest of the outer delegating constructor from mutating 'bar'.

This (hopefully minimally risky) patch makes cxx_eval_call_expression
refrain
from setting TREE_READONLY when evaluating the target constructor of a
delegating constructor.  It also makes cxx_eval_store_expression
refrain
from
setting TREE_READONLY when the object being initialized is "*this', on
the
basis
that it should be the responsibility of the routine that set 'this' in
the
first
place to set the object's TREE_READONLY appropriately.

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

gcc/cp/ChangeLog:

PR c++/94772
* constexpr.c (cxx_eval_call_expression): Don't set new_obj if
we're
evaluating the target constructor of a delegating constructor.
(cxx_eval_store_expression): Don't set TREE_READONLY if the
LHS of the
INIT_EXPR is '*this'.

gcc/testsuite/ChangeLog:

PR c++/94772
* g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
---
gcc/cp/constexpr.c| 29
+++
.../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 ++
2 files changed, 45 insertions(+), 5 deletions(-)
create mode 100644
gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 6b3e514398b..a9ddd861195 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2367,10 +2367,20 @@ cxx_eval_call_expression (const constexpr_ctx
*ctx,
tree t,
  /* In a constructor, it should be the first `this' argument.
 At this point it has already been evaluated in the call
 to cxx_bind_parameters_in_call.  */
-  new_obj = TREE_VEC_ELT (new_call.bindings, 0);
-  STRIP_NOPS (new_obj);
-  if (TREE_CODE (new_obj) == ADDR_EXPR)
-   new_obj = TREE_OPERAND (new_obj, 0);
+
+  if (ctx->call && ctx->call->fundef
+ && DECL_CONSTRUCTOR_P (ctx->call->fundef->decl)
+ && (TREE_VEC_ELT (ctx->call->bindings, 0)
+ == TREE_VEC_ELT (new_call.bindings, 0)))
+   /* We're calling the target constructor of a delegating
constructor,
so
+  there is no new object.  */;
+  else
+   {
+ new_obj = TREE_VEC_ELT (new_call.bindings, 0);
+ STRIP_NOPS (new_obj);
+ if (TREE_CODE (new_obj) == ADDR_EXPR)
+   new_obj = TREE_OPERAND (new_obj, 0);
+   }
}
tree result = NULL_TREE;
@@ -4950,7 +4960,16 @@ cxx_eval_store_expression (const constexpr_ctx
*ctx,
tree t,
  if (TREE_CODE (t) == INIT_EXPR
  && TREE_CODE (*valp) == CONSTRUCTOR
  && TYPE_READONLY (type))
-TREE_READONLY (*valp) = true;
+{
+  if (INDIRECT_REF_P (target)
+ && (is_this_parameter
+ (tree_strip_nop_conversions (TREE_OPERAND (target,
0)
+   /* We've just initialized '*this' (perhaps via the target
constructor
of
+  a delegating constructor).  Leave it up to the caller that
set
'this'
+  to set TREE_READONLY appropriately.  */;


Let's checking_assert that target and *this are
same_type_ignoring_top_level_qualifiers_p.


Like this?  Bootstrap and regtest in progress.

-- >8 --

gcc/cp/ChangeLog:

PR c++/94772
* constexpr.c (cxx_eval_call_expression): Don't set new_obj if we're
evaluating the target constructor of a delegating constructor.
(cxx_eval_store_expression): Don't set TREE_READONLY if the LHS of the
INIT_EXPR is '*this'.

gcc/testsuite/ChangeLog:

PR c++/94772
* g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
---
   gcc/cp/constexpr.c| 31 ---
   .../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 +
   2 files changed, 47 insertions(+), 5 deletions(-)
   create mode 100644
gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 6b3e514398b..c7923897e23 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2367,10 +2367,20 @@ cxx_eval_call_expression (const constexpr_ctx
*ctx, tree t,
 /* In a constructor, it 

Re: [RFC] Clarify -ffinite-math-only documentation

[Richard Sandiford]

"Dr. Matthias Kretz"  writes:
> On Montag, 27. April 2020 18:59:08 CEST Richard Sandiford wrote:
>> Richard Biener via Gcc-patches  writes:
>> > On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz  wrote:
>> >> Hi,
>> >> 
>> >> This documentation change clarifies the effect of -ffinite-math-only.
>> >> With the current documentation, it is unclear what the presence of NaN
>> >> and Inf representations means if (arithmetic) operations on such values
>> >> are unspecified and even classification functions like isnan are
>> >> unreliable. If the hardware thinks a certain bit pattern is a NaN, but
>> >> the software assumes a NaN value cannot ever exist, it is questionable
>> >> whether, from a language viewpoint, a representation for NaNs really
>> >> exists. Because, a NaN is defined by its behavior. This change also
>> >> clarifies that isnan(nan) returning false is fine.
>> >> 
>> >> This relates to PR84949.
>> >> 
>> >> * doc/invoke.texi: Clarify the effects of -ffinite-math-only.
>> >> 
>> >> ---
>> >> 
>> >>  gcc/doc/invoke.texi | 6 --
>> >>  1 file changed, 4 insertions(+), 2 deletions(-)
>> >> 
>> >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> >> index a37a2ee9c19..9e76ab057a9 100644
>> >> --- a/gcc/doc/invoke.texi
>> >> +++ b/gcc/doc/invoke.texi
>> >> @@ -11619,8 +11619,10 @@ The default is @option{-fno-reciprocal-math}.
>> >> 
>> >>  @item -ffinite-math-only
>> >>  @opindex ffinite-math-only
>> >> 
>> >> -Allow optimizations for floating-point arithmetic that assume
>> >> -that arguments and results are not NaNs or +-Infs.
>> >> +Assume that floating-point types in the language do not have
>> >> representations for
>> >> +NaNs and +-Inf. Whether floating-point hardware supports and acts on
>> >> NaNs and ++-Inf is not affected. The behavior of a program that uses a
>> >> NaN or +-Inf value
>> >> +as function argument, macro argument, or operand is undefined.
>> > 
>> > Minor nit here - I'd avoid the 'undefined' word which has bad connotation
>> > and use 'unspecified'.  Maybe we can even use ISO C language specification
>> > terms but I'm not sure which one is most appropriate here.
>
> I'm an ISO C++ person, and unspecified sounds too reliable to me:
> https://wg21.link/intro.defs#defns.unspecified.
>
>> > Curiously __builtin_nan ("nan") still gets you a NaN representation
>> > but isnan(__builtin_nan("nan")) is resolved to false.
>
> Right, that's because only the hardware thinks __builtin_nan ("nan") is a NaN 
> representation. With -ffinite-math-only, the double data type in C/C++ can 
> either hold a finite real value, or an invalid value (i.e. a value that the 
> optimizer unconditionally excludes as a possible value for any object of 
> floating-point type). FWIW, with -ffinite-math-only, ubsan should flag 
> isnan(__builtin_nan("nan")) or any f(constexpr nan).
>
> With the above documentation change, it is clear that with https://wg21.link/
> P1841 std::numbers::quiet_NaN would be ill-formed under -ffinite-math-
> only. Without the documentation change, it can be argued either way.
>
> There's another interesting observation resulting from the above: double and 
> double under -ffinite-math-only are different types. Any function call from 
> one world to the other is dangerous. Inline functions translated in different 
> TUs compiled with different math flags violate the ODR. But that's all the 
> more reason to have a very precise documentation/understanding of what 
> -ffinite-math-only does. Because this gotcha is already the status quo.
>  
>> Yeah, for that and other reasons, I think it would be good to avoid
>> giving the impression that -ffinite-math-only can be relied on to make
>> the assumption above.  Wouldn't it be more accurate to say that the
>> compiler is allowed to make the assumption, at any point that it seems
>> convenient?
>
> I think undefined behavior does what you're asking for while unspecified 
> behavior does what you want to avoid. I.e. its an undocumented behavior, but 
> it can be relied on with a given implementation (compiler).

Although it wasn't obvious from my quoting, I was worried more about
the wording of the first "Assume X" sentence than the unspecified vs.
undefined thing.  I think saying "Assume X" loses an important but
correct nuance of the original wording: that completely ignoring the
option would be a valid (if not very useful) implementation.  "Assume X"
instead makes it sound like the compiler is required to do something
(at least to me).

E.g., does making it undefined behaviour mean that:

  constexpr bool e = __builtin_isnan(__builtin_nan("nan"));

must be rejected for -ffinite-math-only, since AIUI constexprs aren't
allowed to invoke UB?  (Sorry if this has already been covered in the
earlier conversation.)

Thanks,
Richard

Re: [PATCH] c++: Delegating constructor in constexpr init [PR94772]

[Patrick Palka via Gcc-patches]

On Mon, 27 Apr 2020, Jason Merrill wrote:

> On 4/27/20 10:45 AM, Patrick Palka wrote:
> > On Mon, 27 Apr 2020, Patrick Palka wrote:
> > 
> > > On Mon, 27 Apr 2020, Jason Merrill wrote:
> > > 
> > > > On 4/26/20 6:48 PM, Patrick Palka wrote:
> > > > > In the testcase below, the call to the target constructor foo{} from
> > > > > foo's
> > > > > delegating constructor is encoded as the INIT_EXPR
> > > > > 
> > > > > *(struct foo *) this = AGGR_INIT_EXPR <4, __ct_comp, D.2140, ...>;
> > > > > 
> > > > > During initialization of the variable 'bar', we prematurely set
> > > > > TREE_READONLY on
> > > > > bar's CONSTRUCTOR in two places before the outer delegating
> > > > > constructor has
> > > > > returned: first, at the end of cxx_eval_call_expression after
> > > > > evaluating the
> > > > > RHS
> > > > > of the above INIT_EXPR, and second, at the end of
> > > > > cxx_eval_store_expression
> > > > > after having finished evaluating the above INIT_EXPR.  This then
> > > > > prevents
> > > > > the
> > > > > rest of the outer delegating constructor from mutating 'bar'.
> > > > > 
> > > > > This (hopefully minimally risky) patch makes cxx_eval_call_expression
> > > > > refrain
> > > > > from setting TREE_READONLY when evaluating the target constructor of a
> > > > > delegating constructor.  It also makes cxx_eval_store_expression
> > > > > refrain
> > > > > from
> > > > > setting TREE_READONLY when the object being initialized is "*this', on
> > > > > the
> > > > > basis
> > > > > that it should be the responsibility of the routine that set 'this' in
> > > > > the
> > > > > first
> > > > > place to set the object's TREE_READONLY appropriately.
> > > > > 
> > > > > Passes 'make check-c++', does this look OK to commit after full
> > > > > bootstrap/regtest?
> > > > > 
> > > > > gcc/cp/ChangeLog:
> > > > > 
> > > > >   PR c++/94772
> > > > >   * constexpr.c (cxx_eval_call_expression): Don't set new_obj if
> > > > > we're
> > > > >   evaluating the target constructor of a delegating constructor.
> > > > >   (cxx_eval_store_expression): Don't set TREE_READONLY if the
> > > > > LHS of the
> > > > >   INIT_EXPR is '*this'.
> > > > > 
> > > > > gcc/testsuite/ChangeLog:
> > > > > 
> > > > >   PR c++/94772
> > > > >   * g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
> > > > > ---
> > > > >gcc/cp/constexpr.c| 29
> > > > > +++
> > > > >.../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 ++
> > > > >2 files changed, 45 insertions(+), 5 deletions(-)
> > > > >create mode 100644
> > > > > gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C
> > > > > 
> > > > > diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> > > > > index 6b3e514398b..a9ddd861195 100644
> > > > > --- a/gcc/cp/constexpr.c
> > > > > +++ b/gcc/cp/constexpr.c
> > > > > @@ -2367,10 +2367,20 @@ cxx_eval_call_expression (const constexpr_ctx
> > > > > *ctx,
> > > > > tree t,
> > > > >  /* In a constructor, it should be the first `this' argument.
> > > > >At this point it has already been evaluated in the call
> > > > >to cxx_bind_parameters_in_call.  */
> > > > > -  new_obj = TREE_VEC_ELT (new_call.bindings, 0);
> > > > > -  STRIP_NOPS (new_obj);
> > > > > -  if (TREE_CODE (new_obj) == ADDR_EXPR)
> > > > > - new_obj = TREE_OPERAND (new_obj, 0);
> > > > > +
> > > > > +  if (ctx->call && ctx->call->fundef
> > > > > +   && DECL_CONSTRUCTOR_P (ctx->call->fundef->decl)
> > > > > +   && (TREE_VEC_ELT (ctx->call->bindings, 0)
> > > > > +   == TREE_VEC_ELT (new_call.bindings, 0)))
> > > > > + /* We're calling the target constructor of a delegating
> > > > > constructor,
> > > > > so
> > > > > +there is no new object.  */;
> > > > > +  else
> > > > > + {
> > > > > +   new_obj = TREE_VEC_ELT (new_call.bindings, 0);
> > > > > +   STRIP_NOPS (new_obj);
> > > > > +   if (TREE_CODE (new_obj) == ADDR_EXPR)
> > > > > + new_obj = TREE_OPERAND (new_obj, 0);
> > > > > + }
> > > > >}
> > > > >tree result = NULL_TREE;
> > > > > @@ -4950,7 +4960,16 @@ cxx_eval_store_expression (const constexpr_ctx
> > > > > *ctx,
> > > > > tree t,
> > > > >  if (TREE_CODE (t) == INIT_EXPR
> > > > >  && TREE_CODE (*valp) == CONSTRUCTOR
> > > > >  && TYPE_READONLY (type))
> > > > > -TREE_READONLY (*valp) = true;
> > > > > +{
> > > > > +  if (INDIRECT_REF_P (target)
> > > > > +   && (is_this_parameter
> > > > > +   (tree_strip_nop_conversions (TREE_OPERAND (target,
> > > > > 0)
> > > > > + /* We've just initialized '*this' (perhaps via the target
> > > > > constructor
> > > > > of
> > > > > +a delegating constructor).  Leave it up to the caller that
> > > > > set
> > > > > 'this'
> > > > > +to set TREE_READONLY appropriately.  */;
> > > > 
> > > > Let's checking_assert that target and *this are
> > > > 

Re: [PATCH] c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout [PR94707]

[Jason Merrill via Gcc-patches]

On 4/25/20 6:03 AM, Jakub Jelinek wrote:

As reported by Iain and David, powerpc-darwin and powerpc-aix* have C++14
vs. C++17 ABI incompatibilities which are not fixed by mere adding of
cxx17_empty_base_field_p calls.  Unlike the issues that were seen on other
targets where the artificial empty base field affected function argument
passing or returning of values, on these two targets the difference is
during class layout, not afterwards (e.g.
struct empty_base {};
struct S : public empty_base { unsigned long long l[2]; };
will have different __alignof__ (S) between C++14 and C++17 (or possibly
with double instead of unsigned long long too)).

The aim of the calls.c (cxx17_empty_base_field_p) was not to match random
artificial fields with zero size, because they could be created by something
else for some other reason, thus the DECL_SIZE is bitsize_zero but TYPE_SIZE
is non-zero check.  Unfortunately, during the class layout, the empty base
fields have a different type, one which has zero size, so the predicate only
works after the class is laid out completely.

This patch adds a langhook, which will return true for those cases.  It
shouldn't be problematic with LTO, because lto1 should see only
structures/classes that are already laid out, or if it does some structure
layout, it won't be something that has C++17 empty base artificial fields.


Note that C++20 adds empty non-static data members with the 
[[no_unique_address]] attribute.  How will that fit into these ABIs and 
the others that had issues with parameter passing?



Tested with cross to powerpc-darwin12 on a simple testcase given from Iain,
but otherwise untested.
Iain/David, could you please test this on your targets?
Ok for trunk?

2020-04-25  Jakub Jelinek  

PR target/94707
* langhooks.h (struct lang_hooks_for_decls): Add
cxx17_empty_base_field_p member.
* langhooks-def.h (LANG_HOOKS_CXX17_EMPTY_BASE_FIELD_P): Define.
(LANG_HOOKS_DECLS): Use it.
* calls.c (cxx17_empty_base_field_p): Use
langhooks.decls.cxx17_empty_base_field_p.
* config/rs6000/rs6000.c (rs6000_special_round_type_align,
darwin_rs6000_special_round_type_align): Skip cxx17_empty_base_field_p
fields.
cp/
* cp-objcp-common.h (cp_cxx17_empty_base_field_p): Declare.
(LANG_HOOKS_CXX17_EMPTY_BASE_FIELD_P): Redefine.
* class.c (cp_cxx17_empty_base_field_p): New function.

--- gcc/langhooks.h.jj  2020-03-17 13:50:52.262943386 +0100
+++ gcc/langhooks.h 2020-04-25 11:06:11.921931710 +0200
@@ -226,6 +226,9 @@ struct lang_hooks_for_decls
/* True if this decl may be called via a sibcall.  */
bool (*ok_for_sibcall) (const_tree);
  
+  /* True if this FIELD_DECL is C++17 empty base field.  */

+  bool (*cxx17_empty_base_field_p) (const_tree);
+
/* Return a tree for the actual data of an array descriptor - or NULL_TREE
   if original tree is not an array descriptor.  If the second argument
   is true, only the TREE_TYPE is returned without generating a new tree.  
*/
--- gcc/langhooks-def.h.jj  2020-01-12 11:54:36.670409531 +0100
+++ gcc/langhooks-def.h 2020-04-25 11:06:03.300061347 +0200
@@ -241,6 +241,7 @@ extern tree lhd_unit_size_without_reusab
  #define LANG_HOOKS_WARN_UNUSED_GLOBAL_DECL lhd_warn_unused_global_decl
  #define LANG_HOOKS_POST_COMPILATION_PARSING_CLEANUPS NULL
  #define LANG_HOOKS_DECL_OK_FOR_SIBCALLlhd_decl_ok_for_sibcall
+#define LANG_HOOKS_CXX17_EMPTY_BASE_FIELD_Phook_bool_const_tree_false
  #define LANG_HOOKS_OMP_ARRAY_DATA hook_tree_tree_bool_null
  #define LANG_HOOKS_OMP_IS_ALLOCATABLE_OR_PTR hook_bool_const_tree_false
  #define LANG_HOOKS_OMP_CHECK_OPTIONAL_ARGUMENT hook_tree_tree_bool_null
@@ -269,6 +270,7 @@ extern tree lhd_unit_size_without_reusab
LANG_HOOKS_WARN_UNUSED_GLOBAL_DECL, \
LANG_HOOKS_POST_COMPILATION_PARSING_CLEANUPS, \
LANG_HOOKS_DECL_OK_FOR_SIBCALL, \
+  LANG_HOOKS_CXX17_EMPTY_BASE_FIELD_P, \
LANG_HOOKS_OMP_ARRAY_DATA, \
LANG_HOOKS_OMP_IS_ALLOCATABLE_OR_PTR, \
LANG_HOOKS_OMP_CHECK_OPTIONAL_ARGUMENT, \
--- gcc/calls.c.jj  2020-04-22 16:44:30.765946555 +0200
+++ gcc/calls.c 2020-04-25 11:14:45.038217088 +0200
@@ -6275,8 +6275,9 @@ cxx17_empty_base_field_p (const_tree fie
  && RECORD_OR_UNION_TYPE_P (TREE_TYPE (field))
  && DECL_SIZE (field)
  && integer_zerop (DECL_SIZE (field))
- && TYPE_SIZE (TREE_TYPE (field))
- && !integer_zerop (TYPE_SIZE (TREE_TYPE (field;
+ && ((TYPE_SIZE (TREE_TYPE (field))
+  && !integer_zerop (TYPE_SIZE (TREE_TYPE (field
+ || lang_hooks.decls.cxx17_empty_base_field_p (field)));
  }
  
  /* Tell the garbage collector about GTY markers in this source file.  */

--- gcc/config/rs6000/rs6000.c.jj   2020-04-22 16:43:14.913087731 +0200
+++ gcc/config/rs6000/rs6000.c  2020-04-25 11:16:01.536067016 +0200
@@ -7192,7 +7192,9 @@ rs6000_special_round_type_align (tree ty
tree 

Re: [PATCH] x86: Fix up ix86_atomic_assign_expand_fenv [PR94780]

[Uros Bizjak via Gcc-patches]

On Mon, Apr 27, 2020 at 8:26 PM Jakub Jelinek  wrote:
>
> Hi!
>
> This function, because it is sometimes called even outside of function
> bodies, uses create_tmp_var_raw rather than create_tmp_var.  But in order
> for that to work, when first referenced, the VAR_DECLs need to appear in a
> TARGET_EXPR so that during gimplification the var gets the right
> DECL_CONTEXT and is added to local decls.  Without that, e.g. tree-nested.c
> ICEs on those.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> 2020-04-27  Jakub Jelinek  
>
> PR target/94780
> * config/i386/i386.c (ix86_atomic_assign_expand_fenv): Use
> TARGET_EXPR instead of MODIFY_EXPR for first assignment to
> sw_var, exceptions_var, mxcsr_orig_var and mxcsr_mod_var.
>
> * gcc.dg/pr94780.c: New test.

I don't know much about this part, but rubber-stamped OK.

Thanks,
Uros.

> --- gcc/config/i386/i386.c.jj   2020-04-27 14:31:09.126020786 +0200
> +++ gcc/config/i386/i386.c  2020-04-27 15:10:39.514407179 +0200
> @@ -22390,11 +22390,12 @@ ix86_atomic_assign_expand_fenv (tree *ho
>*clear = build_call_expr (fnclex, 0);
>tree sw_var = create_tmp_var_raw (short_unsigned_type_node);
>tree fnstsw_call = build_call_expr (fnstsw, 0);
> -  tree sw_mod = build2 (MODIFY_EXPR, short_unsigned_type_node,
> -   sw_var, fnstsw_call);
> +  tree sw_mod = build4 (TARGET_EXPR, short_unsigned_type_node, sw_var,
> +   fnstsw_call, NULL_TREE, NULL_TREE);
>tree exceptions_x87 = fold_convert (integer_type_node, sw_var);
> -  tree update_mod = build2 (MODIFY_EXPR, integer_type_node,
> -   exceptions_var, exceptions_x87);
> +  tree update_mod = build4 (TARGET_EXPR, integer_type_node,
> +   exceptions_var, exceptions_x87,
> +   NULL_TREE, NULL_TREE);
>*update = build2 (COMPOUND_EXPR, integer_type_node,
> sw_mod, update_mod);
>tree update_fldenv = build_call_expr (fldenv, 1, fenv_addr);
> @@ -22407,15 +22408,17 @@ ix86_atomic_assign_expand_fenv (tree *ho
>tree stmxcsr = get_ix86_builtin (IX86_BUILTIN_STMXCSR);
>tree ldmxcsr = get_ix86_builtin (IX86_BUILTIN_LDMXCSR);
>tree stmxcsr_hold_call = build_call_expr (stmxcsr, 0);
> -  tree hold_assign_orig = build2 (MODIFY_EXPR, unsigned_type_node,
> - mxcsr_orig_var, stmxcsr_hold_call);
> +  tree hold_assign_orig = build4 (TARGET_EXPR, unsigned_type_node,
> + mxcsr_orig_var, stmxcsr_hold_call,
> + NULL_TREE, NULL_TREE);
>tree hold_mod_val = build2 (BIT_IOR_EXPR, unsigned_type_node,
>   mxcsr_orig_var,
>   build_int_cst (unsigned_type_node, 0x1f80));
>hold_mod_val = build2 (BIT_AND_EXPR, unsigned_type_node, hold_mod_val,
>  build_int_cst (unsigned_type_node, 0xffc0));
> -  tree hold_assign_mod = build2 (MODIFY_EXPR, unsigned_type_node,
> -mxcsr_mod_var, hold_mod_val);
> +  tree hold_assign_mod = build4 (TARGET_EXPR, unsigned_type_node,
> +mxcsr_mod_var, hold_mod_val,
> +NULL_TREE, NULL_TREE);
>tree ldmxcsr_hold_call = build_call_expr (ldmxcsr, 1, mxcsr_mod_var);
>tree hold_all = build2 (COMPOUND_EXPR, unsigned_type_node,
>   hold_assign_orig, hold_assign_mod);
> @@ -22444,8 +22447,8 @@ ix86_atomic_assign_expand_fenv (tree *ho
> exceptions_assign);
> }
>else
> -   *update = build2 (MODIFY_EXPR, integer_type_node,
> - exceptions_var, exceptions_sse);
> +   *update = build4 (TARGET_EXPR, integer_type_node, exceptions_var,
> + exceptions_sse, NULL_TREE, NULL_TREE);
>tree ldmxcsr_update_call = build_call_expr (ldmxcsr, 1, 
> mxcsr_orig_var);
>*update = build2 (COMPOUND_EXPR, void_type_node, *update,
> ldmxcsr_update_call);
> --- gcc/testsuite/gcc.dg/pr94780.c.jj   2020-04-27 15:25:48.916854107 +0200
> +++ gcc/testsuite/gcc.dg/pr94780.c  2020-04-27 15:25:05.921501837 +0200
> @@ -0,0 +1,13 @@
> +/* PR target/94780 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +_Atomic double x;
> +
> +double
> +foo (void)
> +{
> +  double bar () { return x; }
> +  x /= 3;
> +  return bar ();
> +}
>
> Jakub
>

[committed] Fix warning URLs for Fortran and analyzer [PR 92830]

[David Malcolm via Gcc-patches]

PR 92830 reports that we always use "gcc/Warning-Options.html" when we
emit escaped documentation URLs when printing "[-Wname-of-option]" for
a warning.
 
This page is wrong for most Fortran warnings, and for analyzer warnings.

I considered various schemes involving adding extra tags to the .opt
format to capture where options are documented, but for now this patch
fixes the issue by introducing some special-casing logic.
It only fixes the URLs for warning options, not for other command-line
options, but those are the only options for which get_option_url is
currently called.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu with all
languages enabled; I also verified that it builds for the case when
fortran is not enabled.

Pushed to master as r10-7994-gfa29cf0c3f19b648e30b16fd2485c3c17a528a6e.

gcc/ChangeLog:
PR 92830
* configure.ac (DOCUMENTATION_ROOT_URL): Drop trailing "gcc/" from
default value, so that it can by supplied by get_option_html_page.
* configure: Regenerate.
* opts.c: Include "selftest.h".
(get_option_html_page): New function.
(get_option_url): Use it.  Reformat to place comments next to the
expressions they refer to.
(selftest::test_get_option_html_page): New.
(selftest::opts_c_tests): New.
* selftest-run-tests.c (selftest::run_tests): Call
selftest::opts_c_tests.
* selftest.h (selftest::opts_c_tests): New decl.
---
 gcc/configure.ac |  2 +-
 gcc/opts.c   | 87 
 gcc/selftest-run-tests.c |  1 +
 gcc/selftest.h   |  1 +
 4 files changed, 82 insertions(+), 9 deletions(-)

diff --git a/gcc/configure.ac b/gcc/configure.ac
index fdee9ea587c..cd62312b813 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -982,7 +982,7 @@ AC_ARG_WITH(documentation-root-url,
   *)   DOCUMENTATION_ROOT_URL="$withval"
   ;;
  esac],
- DOCUMENTATION_ROOT_URL="https://gcc.gnu.org/onlinedocs/gcc/;
+ DOCUMENTATION_ROOT_URL="https://gcc.gnu.org/onlinedocs/;
 )
 AC_SUBST(DOCUMENTATION_ROOT_URL)
 
diff --git a/gcc/opts.c b/gcc/opts.c
index d4df8627bf7..c212a1a57dc 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -32,6 +32,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "spellcheck.h"
 #include "opt-suggestions.h"
 #include "diagnostic-color.h"
+#include "selftest.h"
 
 static void set_Wstrict_aliasing (struct gcc_options *opts, int onoff);
 
@@ -3128,6 +3129,42 @@ option_name (diagnostic_context *context, int 
option_index,
 return NULL;
 }
 
+/* Get the page within the documentation for this option.  */
+
+static const char *
+get_option_html_page (int option_index)
+{
+  const cl_option *cl_opt = _options[option_index];
+
+  /* Analyzer options are on their own page.  */
+  if (strstr(cl_opt->opt_text, "analyzer-"))
+return "gcc/Static-Analyzer-Options.html";
+
+#ifdef CL_Fortran
+  if (cl_opt->flags & CL_Fortran)
+{
+  switch (option_index)
+   {
+   default:
+ /* Most Fortran warnings are documented on this page.  */
+ return "gfortran/Error-and-Warning-Options.html";
+
+   case OPT_Wdate_time:
+   case OPT_Wconversion:
+   case OPT_Wconversion_extra:
+   case OPT_Wmissing_include_dirs:
+   case OPT_Wopenmp_simd:
+ /* These warnings are marked in fortran/lang.opt as
+"Documented in C" and thus use the common
+Warning-Options page below.  */
+ break;
+   }
+}
+#endif
+
+  return "gcc/Warning-Options.html";
+}
+
 /* Return malloced memory for a URL describing the option OPTION_INDEX
which enabled a diagnostic (context CONTEXT).  */
 
@@ -3135,16 +3172,50 @@ char *
 get_option_url (diagnostic_context *, int option_index)
 {
   if (option_index)
-/* DOCUMENTATION_ROOT_URL should be supplied via -D by the Makefile
-   (see --with-documentation-root-url).
-
-   Expect an anchor of the form "index-Wfoo" e.g.
-   , and thus an id within
-   the URL of "#index-Wformat".  */
-return concat (DOCUMENTATION_ROOT_URL,
-  "Warning-Options.html",
+return concat (/* DOCUMENTATION_ROOT_URL should be supplied via -D by
+ the Makefile (see --with-documentation-root-url), and
+ should have a trailing slash.  */
+  DOCUMENTATION_ROOT_URL,
+
+  /* get_option_html_page will return something like
+ "gcc/Warning-Options.html".  */
+  get_option_html_page (option_index),
+
+  /* Expect an anchor of the form "index-Wfoo" e.g.
+ , and thus an id within
+ the URL of "#index-Wformat".  */
   "#index", cl_options[option_index].opt_text,
   NULL);
   else
 return NULL;
 }
+
+#if CHECKING_P
+
+namespace selftest {
+
+/* Verify that get_option_html_page works as expected.  */
+

Re: [PATCH] demangler: Handle <=> operator in the demangler [PR94797]

[Jason Merrill via Gcc-patches]

On 4/27/20 2:28 PM, Jakub Jelinek wrote:

Hi!

The demangler didn't handle spaceship operator.

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


OK.


2020-04-27  Jakub Jelinek  

PR demangler/94797
* cp-demangle.c (cplus_demangle_operators): Add ss <=> operator.
* testsuite/demangle-expected: Add operator<=> test.

--- libiberty/cp-demangle.c.jj  2020-01-18 13:47:09.549357226 +0100
+++ libiberty/cp-demangle.c 2020-04-27 18:36:18.309537085 +0200
@@ -1860,6 +1860,7 @@ const struct demangle_operator_info cplu
{ "sP", NL ("sizeof..."), 1 },
{ "sZ", NL ("sizeof..."), 1 },
{ "sc", NL ("static_cast"), 2 },
+  { "ss", NL ("<=>"),   2 },
{ "st", NL ("sizeof "),   1 },
{ "sz", NL ("sizeof "),   1 },
{ "tr", NL ("throw"), 0 },
--- libiberty/testsuite/demangle-expected.jj2020-03-02 13:33:10.999493843 
+0100
+++ libiberty/testsuite/demangle-expected   2020-04-27 18:37:06.245822623 
+0200
@@ -1453,3 +1453,6 @@ void foo<(void*)0>(enable_if<((void*)0)=
  
  _ZNK5coro15emptyawEv

  coro1::empty::operator co_await() const
+
+_ZNK3FoossERKS_
+Foo::operator<=>(Foo const&) const

Jakub

Re: [PATCH] coroutines: Pass class ref to traits lookup and promise allocator [PR94760]

[Iain Sandoe]

Nathan Sidwell  wrote:

> On 4/25/20 11:08 AM, Iain Sandoe wrote:

>> +  tree arg = DECL_ARGUMENTS (fndecl);
>> +  bool lambda_p = LAMBDA_TYPE_P (DECL_CONTEXT (fndecl));
> 
> I think LAMBDA_FUNCTION_P (fndecl) expresses intent better.
done in both places.

>> +
>>parm.this_ptr = is_this_parameter (arg);
>> +  if (lambda_p)
>> +{
>> +  parm.lambda_cobj = parm.this_ptr
>> + || (DECL_NAME (arg) == closure_identifier);
> 
> i'm confused by the need for || here.  Why isn't just the DECL_NAME test 
> needed?  The parser appears to give the object parameter that name.  (If you 
> do need the parm.this_ptr piece, it suggests somewhere else outside of coro 
> is not being consistent, but ICBW.)

It seems that, when a lambda is part of a class, the closure object gets the 
name ‘this’.
When a lambda is defined outside a class context, the closure object is named 
__closure.

I added a comment as to why we make the two checks (also, why we can’t just use
is_this_parameter() as the test elsewhere)

>> +vec_safe_push (args, arg);
>> +  else if (0 && parm_i->this_ptr)
> 
> ^^ looks like now-disabled experimental code?
well caught, now enabled as intended.

thanks for the review is the revised below OK (testing now)

thanks
iain

===

We changed the argument passed to the promise parameter preview
to match a reference to *this.  However to be consistent with the
other ports, we do need to match the reference transformation in
the traits lookup and the promise allocator lookup.

gcc/cp/ChangeLog:

2020-04-27  Iain Sandoe  

PR c++/94760
* coroutines.cc (instantiate_coro_traits): Pass a reference to
object type rather than a pointer type for 'this', for method
coroutines.
(struct param_info): Add a field to hold that the parm is a lambda
closure pointer.
(morph_fn_to_coro): Check for lambda closure pointers in the
args.  Use a reference to *this when building the args list for the
promise allocator lookup.

gcc/testsuite/ChangeLog:

2020-04-27  Iain Sandoe  

PR c++/94760
* g++.dg/coroutines/pr94760-mismatched-traits-and-promise-prev.C: New 
test.
---
 gcc/cp/coroutines.cc  | 54 +--
 ...9-mismatched-traits-and-promise-prev.C | 29 ++
 2 files changed, 79 insertions(+), 4 deletions(-)
 create mode 100644 
gcc/testsuite/g++.dg/coroutines/pr9-mismatched-traits-and-promise-prev.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 0a5a0c9b1d2..cfaa018c551 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -296,14 +296,25 @@ instantiate_coro_traits (tree fndecl, location_t kw)
  type.  */
 
   tree functyp = TREE_TYPE (fndecl);
+  tree arg = DECL_ARGUMENTS (fndecl);
+  bool lambda_p = LAMBDA_FUNCTION_P (fndecl);
   tree arg_node = TYPE_ARG_TYPES (functyp);
   tree argtypes = make_tree_vec (list_length (arg_node)-1);
   unsigned p = 0;
 
   while (arg_node != NULL_TREE && !VOID_TYPE_P (TREE_VALUE (arg_node)))
 {
-  TREE_VEC_ELT (argtypes, p++) = TREE_VALUE (arg_node);
+  if (is_this_parameter (arg) && !lambda_p)
+   {
+ /* We pass a reference to *this to the param preview.  */
+ tree ct = TREE_TYPE (TREE_TYPE (arg));
+ TREE_VEC_ELT (argtypes, p++) = cp_build_reference_type (ct, false);
+   }
+  else
+   TREE_VEC_ELT (argtypes, p++) = TREE_VALUE (arg_node);
+
   arg_node = TREE_CHAIN (arg_node);
+  arg = DECL_CHAIN (arg);
 }
 
   tree argtypepack = cxx_make_type (TYPE_ARGUMENT_PACK);
@@ -1766,6 +1777,7 @@ struct param_info
   bool pt_ref;   /* Was a pointer to object.  */
   bool trivial_dtor; /* The frame type has a trivial DTOR.  */
   bool this_ptr; /* Is 'this' */
+  bool lambda_cobj;  /* Lambda capture object */
 };
 
 struct local_var_info
@@ -3652,6 +3664,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
  The second two entries start out empty - and only get populated
  when we see uses.  */
   param_uses = new hash_map;
+  bool lambda_p = LAMBDA_FUNCTION_P (orig);
 
   unsigned no_name_parm = 0;
   for (tree arg = DECL_ARGUMENTS (orig); arg != NULL;
@@ -3692,7 +3705,19 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
}
  else
parm.frame_type = actual_type;
+
+ /* The closure object pointer is called 'this' when a lambda is
+part of a class, and __closure when it is not.  */
  parm.this_ptr = is_this_parameter (arg);
+ if (lambda_p)
+   {
+ parm.lambda_cobj = parm.this_ptr
+|| (DECL_NAME (arg) == closure_identifier);
+ parm.this_ptr = false;
+   }
+ else
+   parm.lambda_cobj = false;
+
  parm.trivial_dtor = TYPE_HAS_TRIVIAL_DESTRUCTOR (parm.frame_type);
  char *buf;
  if 

[PATCH] match.pd: Decrease number of nop conversions around bitwise ops [PR94718]

[Jakub Jelinek via Gcc-patches]

Hi!

On the following testcase, there are in *.optimized dump 14 nop conversions
(from signed to unsigned and back), while this patch decreases that number
to just 4; for bitwise ops it really doesn't matter if they are performed in
signed or unsigned, so the patch (in GIMPLE only, there are some comments
about it being undesirable during GENERIC earlier), if it sees both
bitop operands nop converted from the same types performs the bitop in their
non-converted type and converts the result (i.e. 2 conversions into 1),
similarly, if a bitop has one operand nop converted from something, the
other not and the result is converted back to the type of the nop converted
operand before conversion, it is possible to replace those 2 conversions
with just a single conversion of the other operand.

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

2020-04-27  Jakub Jelinek  

PR tree-optimization/94718
* match.pd (bitop (convert @0) (convert? @1)): For GIMPLE, if we can,
replace two nop conversions on bit_{and,ior,xor} argument
and result with just one conversion on the result or another argument.

* gcc.dg/tree-ssa/pr94718-3.c: New test.

--- gcc/match.pd.jj 2020-04-24 19:12:56.969197128 +0200
+++ gcc/match.pd2020-04-27 16:54:48.340656033 +0200
@@ -1311,7 +1311,7 @@ (define_operator_list COND_TERNARY
We combine the above two cases by using a conditional convert.  */
 (for bitop (bit_and bit_ior bit_xor)
  (simplify
-  (bitop (convert @0) (convert? @1))
+  (bitop (convert@2 @0) (convert?@3 @1))
   (if (((TREE_CODE (@1) == INTEGER_CST
 && INTEGRAL_TYPE_P (TREE_TYPE (@0))
 && int_fits_type_p (@1, TREE_TYPE (@0)))
@@ -1330,8 +1330,24 @@ (define_operator_list COND_TERNARY
   || GET_MODE_CLASS (TYPE_MODE (type)) != MODE_INT
   /* Or if the precision of TO is not the same as the precision
  of its mode.  */
-  || !type_has_mode_precision_p (type)))
-   (convert (bitop @0 (convert @1))
+  || !type_has_mode_precision_p (type)
+  /* In GIMPLE, getting rid of 2 conversions for one new results
+ in smaller IL.  */
+  || (GIMPLE
+  && TREE_CODE (@1) != INTEGER_CST
+  && tree_nop_conversion_p (type, TREE_TYPE (@0))
+  && single_use (@2)
+  && single_use (@3
+   (convert (bitop @0 (convert @1)
+ /* In GIMPLE, getting rid of 2 conversions for one new results
+in smaller IL.  */
+ (simplify
+  (convert (bitop:cs@2 (nop_convert:s @0) @1))
+  (if (GIMPLE
+   && TREE_CODE (@1) != INTEGER_CST
+   && tree_nop_conversion_p (type, TREE_TYPE (@2))
+   && types_match (type, @0))
+   (bitop @0 (convert @1)
 
 (for bitop (bit_and bit_ior)
  rbitop (bit_ior bit_and)
--- gcc/testsuite/gcc.dg/tree-ssa/pr94718-3.c.jj2020-04-27 
16:59:33.650366084 +0200
+++ gcc/testsuite/gcc.dg/tree-ssa/pr94718-3.c   2020-04-27 16:58:46.634073029 
+0200
@@ -0,0 +1,45 @@
+/* PR tree-optimization/94718 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-ipa-icf -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-times " \\\(int\\\) " 2 "optimized" } } */
+/* { dg-final { scan-tree-dump-times " \\\(unsigned int\\\) " 2 "optimized" } 
} */
+
+int
+f1 (int x, int y)
+{
+  return (int) ((unsigned) x | (unsigned) y);
+}
+
+int
+f2 (int x, int y)
+{
+  unsigned a = x;
+  unsigned b = y;
+  return a | b;
+}
+
+int
+f3 (int x, unsigned y)
+{
+  return (int) ((unsigned) x | y);
+}
+
+int
+f4 (int x, unsigned y)
+{
+  unsigned a = x;
+  return a | y;
+}
+
+unsigned
+f5 (int x, unsigned y)
+{
+  return (unsigned) (x | (int) y);
+}
+
+unsigned
+f6 (int x, unsigned y)
+{
+  int a = y;
+  return x | a;
+}

Jakub

[PATCH] demangler: Handle <=> operator in the demangler [PR94797]

[Jakub Jelinek via Gcc-patches]

Hi!

The demangler didn't handle spaceship operator.

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

2020-04-27  Jakub Jelinek  

PR demangler/94797
* cp-demangle.c (cplus_demangle_operators): Add ss <=> operator.
* testsuite/demangle-expected: Add operator<=> test.

--- libiberty/cp-demangle.c.jj  2020-01-18 13:47:09.549357226 +0100
+++ libiberty/cp-demangle.c 2020-04-27 18:36:18.309537085 +0200
@@ -1860,6 +1860,7 @@ const struct demangle_operator_info cplu
   { "sP", NL ("sizeof..."), 1 },
   { "sZ", NL ("sizeof..."), 1 },
   { "sc", NL ("static_cast"), 2 },
+  { "ss", NL ("<=>"),   2 },
   { "st", NL ("sizeof "),   1 },
   { "sz", NL ("sizeof "),   1 },
   { "tr", NL ("throw"), 0 },
--- libiberty/testsuite/demangle-expected.jj2020-03-02 13:33:10.999493843 
+0100
+++ libiberty/testsuite/demangle-expected   2020-04-27 18:37:06.245822623 
+0200
@@ -1453,3 +1453,6 @@ void foo<(void*)0>(enable_if<((void*)0)=
 
 _ZNK5coro15emptyawEv
 coro1::empty::operator co_await() const
+
+_ZNK3FoossERKS_
+Foo::operator<=>(Foo const&) const

Jakub

[PATCH] x86: Fix up ix86_atomic_assign_expand_fenv [PR94780]

[Jakub Jelinek via Gcc-patches]

Hi!

This function, because it is sometimes called even outside of function
bodies, uses create_tmp_var_raw rather than create_tmp_var.  But in order
for that to work, when first referenced, the VAR_DECLs need to appear in a
TARGET_EXPR so that during gimplification the var gets the right
DECL_CONTEXT and is added to local decls.  Without that, e.g. tree-nested.c
ICEs on those.

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

2020-04-27  Jakub Jelinek  

PR target/94780
* config/i386/i386.c (ix86_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR for first assignment to
sw_var, exceptions_var, mxcsr_orig_var and mxcsr_mod_var.

* gcc.dg/pr94780.c: New test.

--- gcc/config/i386/i386.c.jj   2020-04-27 14:31:09.126020786 +0200
+++ gcc/config/i386/i386.c  2020-04-27 15:10:39.514407179 +0200
@@ -22390,11 +22390,12 @@ ix86_atomic_assign_expand_fenv (tree *ho
   *clear = build_call_expr (fnclex, 0);
   tree sw_var = create_tmp_var_raw (short_unsigned_type_node);
   tree fnstsw_call = build_call_expr (fnstsw, 0);
-  tree sw_mod = build2 (MODIFY_EXPR, short_unsigned_type_node,
-   sw_var, fnstsw_call);
+  tree sw_mod = build4 (TARGET_EXPR, short_unsigned_type_node, sw_var,
+   fnstsw_call, NULL_TREE, NULL_TREE);
   tree exceptions_x87 = fold_convert (integer_type_node, sw_var);
-  tree update_mod = build2 (MODIFY_EXPR, integer_type_node,
-   exceptions_var, exceptions_x87);
+  tree update_mod = build4 (TARGET_EXPR, integer_type_node,
+   exceptions_var, exceptions_x87,
+   NULL_TREE, NULL_TREE);
   *update = build2 (COMPOUND_EXPR, integer_type_node,
sw_mod, update_mod);
   tree update_fldenv = build_call_expr (fldenv, 1, fenv_addr);
@@ -22407,15 +22408,17 @@ ix86_atomic_assign_expand_fenv (tree *ho
   tree stmxcsr = get_ix86_builtin (IX86_BUILTIN_STMXCSR);
   tree ldmxcsr = get_ix86_builtin (IX86_BUILTIN_LDMXCSR);
   tree stmxcsr_hold_call = build_call_expr (stmxcsr, 0);
-  tree hold_assign_orig = build2 (MODIFY_EXPR, unsigned_type_node,
- mxcsr_orig_var, stmxcsr_hold_call);
+  tree hold_assign_orig = build4 (TARGET_EXPR, unsigned_type_node,
+ mxcsr_orig_var, stmxcsr_hold_call,
+ NULL_TREE, NULL_TREE);
   tree hold_mod_val = build2 (BIT_IOR_EXPR, unsigned_type_node,
  mxcsr_orig_var,
  build_int_cst (unsigned_type_node, 0x1f80));
   hold_mod_val = build2 (BIT_AND_EXPR, unsigned_type_node, hold_mod_val,
 build_int_cst (unsigned_type_node, 0xffc0));
-  tree hold_assign_mod = build2 (MODIFY_EXPR, unsigned_type_node,
-mxcsr_mod_var, hold_mod_val);
+  tree hold_assign_mod = build4 (TARGET_EXPR, unsigned_type_node,
+mxcsr_mod_var, hold_mod_val,
+NULL_TREE, NULL_TREE);
   tree ldmxcsr_hold_call = build_call_expr (ldmxcsr, 1, mxcsr_mod_var);
   tree hold_all = build2 (COMPOUND_EXPR, unsigned_type_node,
  hold_assign_orig, hold_assign_mod);
@@ -22444,8 +22447,8 @@ ix86_atomic_assign_expand_fenv (tree *ho
exceptions_assign);
}
   else
-   *update = build2 (MODIFY_EXPR, integer_type_node,
- exceptions_var, exceptions_sse);
+   *update = build4 (TARGET_EXPR, integer_type_node, exceptions_var,
+ exceptions_sse, NULL_TREE, NULL_TREE);
   tree ldmxcsr_update_call = build_call_expr (ldmxcsr, 1, mxcsr_orig_var);
   *update = build2 (COMPOUND_EXPR, void_type_node, *update,
ldmxcsr_update_call);
--- gcc/testsuite/gcc.dg/pr94780.c.jj   2020-04-27 15:25:48.916854107 +0200
+++ gcc/testsuite/gcc.dg/pr94780.c  2020-04-27 15:25:05.921501837 +0200
@@ -0,0 +1,13 @@
+/* PR target/94780 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+_Atomic double x;
+
+double
+foo (void)
+{
+  double bar () { return x; }
+  x /= 3;
+  return bar ();
+}

Jakub

Re: [RFC] Clarify -ffinite-math-only documentation

[Dr. Matthias Kretz]

On Montag, 27. April 2020 18:59:08 CEST Richard Sandiford wrote:
> Richard Biener via Gcc-patches  writes:
> > On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz  wrote:
> >> Hi,
> >> 
> >> This documentation change clarifies the effect of -ffinite-math-only.
> >> With the current documentation, it is unclear what the presence of NaN
> >> and Inf representations means if (arithmetic) operations on such values
> >> are unspecified and even classification functions like isnan are
> >> unreliable. If the hardware thinks a certain bit pattern is a NaN, but
> >> the software assumes a NaN value cannot ever exist, it is questionable
> >> whether, from a language viewpoint, a representation for NaNs really
> >> exists. Because, a NaN is defined by its behavior. This change also
> >> clarifies that isnan(nan) returning false is fine.
> >> 
> >> This relates to PR84949.
> >> 
> >> * doc/invoke.texi: Clarify the effects of -ffinite-math-only.
> >> 
> >> ---
> >> 
> >>  gcc/doc/invoke.texi | 6 --
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >> 
> >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> >> index a37a2ee9c19..9e76ab057a9 100644
> >> --- a/gcc/doc/invoke.texi
> >> +++ b/gcc/doc/invoke.texi
> >> @@ -11619,8 +11619,10 @@ The default is @option{-fno-reciprocal-math}.
> >> 
> >>  @item -ffinite-math-only
> >>  @opindex ffinite-math-only
> >> 
> >> -Allow optimizations for floating-point arithmetic that assume
> >> -that arguments and results are not NaNs or +-Infs.
> >> +Assume that floating-point types in the language do not have
> >> representations for
> >> +NaNs and +-Inf. Whether floating-point hardware supports and acts on
> >> NaNs and ++-Inf is not affected. The behavior of a program that uses a
> >> NaN or +-Inf value
> >> +as function argument, macro argument, or operand is undefined.
> > 
> > Minor nit here - I'd avoid the 'undefined' word which has bad connotation
> > and use 'unspecified'.  Maybe we can even use ISO C language specification
> > terms but I'm not sure which one is most appropriate here.

I'm an ISO C++ person, and unspecified sounds too reliable to me:
https://wg21.link/intro.defs#defns.unspecified.

> > Curiously __builtin_nan ("nan") still gets you a NaN representation
> > but isnan(__builtin_nan("nan")) is resolved to false.

Right, that's because only the hardware thinks __builtin_nan ("nan") is a NaN 
representation. With -ffinite-math-only, the double data type in C/C++ can 
either hold a finite real value, or an invalid value (i.e. a value that the 
optimizer unconditionally excludes as a possible value for any object of 
floating-point type). FWIW, with -ffinite-math-only, ubsan should flag 
isnan(__builtin_nan("nan")) or any f(constexpr nan).

With the above documentation change, it is clear that with https://wg21.link/
P1841 std::numbers::quiet_NaN would be ill-formed under -ffinite-math-
only. Without the documentation change, it can be argued either way.

There's another interesting observation resulting from the above: double and 
double under -ffinite-math-only are different types. Any function call from 
one world to the other is dangerous. Inline functions translated in different 
TUs compiled with different math flags violate the ODR. But that's all the 
more reason to have a very precise documentation/understanding of what 
-ffinite-math-only does. Because this gotcha is already the status quo.
 
> Yeah, for that and other reasons, I think it would be good to avoid
> giving the impression that -ffinite-math-only can be relied on to make
> the assumption above.  Wouldn't it be more accurate to say that the
> compiler is allowed to make the assumption, at any point that it seems
> convenient?

I think undefined behavior does what you're asking for while unspecified 
behavior does what you want to avoid. I.e. its an undocumented behavior, but 
it can be relied on with a given implementation (compiler).

-Matthias

-- 
──┬
 Dr. Matthias Kretz   │ SDE — Software Development for Experiments
 Senior Software Engineer,│  +49 6159 713084
 SIMD Expert, │  m.kr...@gsi.de
 ISO C++ Committee Member │  mattkretz.github.io
──┴

GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1, 64291 Darmstadt, Germany, www.gsi.de

Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528
Managing Directors / Geschäftsführung:
Professor Dr. Paolo Giubellino, Jörg Blaurock
Chairman of the Supervisory Board / Vorsitzender des GSI-Aufsichtsrats:
State Secretary / Staatssekretär Dr. Georg Schütte

Re: [PATCH] c++: Delegating constructor in constexpr init [PR94772]

[Jason Merrill via Gcc-patches]

On 4/27/20 10:45 AM, Patrick Palka wrote:

On Mon, 27 Apr 2020, Patrick Palka wrote:


On Mon, 27 Apr 2020, Jason Merrill wrote:


On 4/26/20 6:48 PM, Patrick Palka wrote:

In the testcase below, the call to the target constructor foo{} from foo's
delegating constructor is encoded as the INIT_EXPR

*(struct foo *) this = AGGR_INIT_EXPR <4, __ct_comp, D.2140, ...>;

During initialization of the variable 'bar', we prematurely set
TREE_READONLY on
bar's CONSTRUCTOR in two places before the outer delegating constructor has
returned: first, at the end of cxx_eval_call_expression after evaluating the
RHS
of the above INIT_EXPR, and second, at the end of cxx_eval_store_expression
after having finished evaluating the above INIT_EXPR.  This then prevents
the
rest of the outer delegating constructor from mutating 'bar'.

This (hopefully minimally risky) patch makes cxx_eval_call_expression
refrain
from setting TREE_READONLY when evaluating the target constructor of a
delegating constructor.  It also makes cxx_eval_store_expression refrain
from
setting TREE_READONLY when the object being initialized is "*this', on the
basis
that it should be the responsibility of the routine that set 'this' in the
first
place to set the object's TREE_READONLY appropriately.

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

gcc/cp/ChangeLog:

PR c++/94772
* constexpr.c (cxx_eval_call_expression): Don't set new_obj if we're
evaluating the target constructor of a delegating constructor.
(cxx_eval_store_expression): Don't set TREE_READONLY if the LHS of the
INIT_EXPR is '*this'.

gcc/testsuite/ChangeLog:

PR c++/94772
* g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
---
   gcc/cp/constexpr.c| 29 +++
   .../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 ++
   2 files changed, 45 insertions(+), 5 deletions(-)
   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 6b3e514398b..a9ddd861195 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2367,10 +2367,20 @@ cxx_eval_call_expression (const constexpr_ctx *ctx,
tree t,
 /* In a constructor, it should be the first `this' argument.
 At this point it has already been evaluated in the call
 to cxx_bind_parameters_in_call.  */
-  new_obj = TREE_VEC_ELT (new_call.bindings, 0);
-  STRIP_NOPS (new_obj);
-  if (TREE_CODE (new_obj) == ADDR_EXPR)
-   new_obj = TREE_OPERAND (new_obj, 0);
+
+  if (ctx->call && ctx->call->fundef
+ && DECL_CONSTRUCTOR_P (ctx->call->fundef->decl)
+ && (TREE_VEC_ELT (ctx->call->bindings, 0)
+ == TREE_VEC_ELT (new_call.bindings, 0)))
+   /* We're calling the target constructor of a delegating constructor,
so
+  there is no new object.  */;
+  else
+   {
+ new_obj = TREE_VEC_ELT (new_call.bindings, 0);
+ STRIP_NOPS (new_obj);
+ if (TREE_CODE (new_obj) == ADDR_EXPR)
+   new_obj = TREE_OPERAND (new_obj, 0);
+   }
   }
   tree result = NULL_TREE;
@@ -4950,7 +4960,16 @@ cxx_eval_store_expression (const constexpr_ctx *ctx,
tree t,
 if (TREE_CODE (t) == INIT_EXPR
 && TREE_CODE (*valp) == CONSTRUCTOR
 && TYPE_READONLY (type))
-TREE_READONLY (*valp) = true;
+{
+  if (INDIRECT_REF_P (target)
+ && (is_this_parameter
+ (tree_strip_nop_conversions (TREE_OPERAND (target, 0)
+   /* We've just initialized '*this' (perhaps via the target constructor
of
+  a delegating constructor).  Leave it up to the caller that set
'this'
+  to set TREE_READONLY appropriately.  */;


Let's checking_assert that target and *this are
same_type_ignoring_top_level_qualifiers_p.


Like this?  Bootstrap and regtest in progress.

-- >8 --

gcc/cp/ChangeLog:

PR c++/94772
* constexpr.c (cxx_eval_call_expression): Don't set new_obj if we're
evaluating the target constructor of a delegating constructor.
(cxx_eval_store_expression): Don't set TREE_READONLY if the LHS of the
INIT_EXPR is '*this'.

gcc/testsuite/ChangeLog:

PR c++/94772
* g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
---
  gcc/cp/constexpr.c| 31 ---
  .../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 +
  2 files changed, 47 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 6b3e514398b..c7923897e23 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2367,10 +2367,20 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, 
tree t,
/* In a constructor, it should be the first `this' argument.
 At this point it has already been evaluated in the call

Re: [PATCH v5] aarch64: Add TX3 machine model

[Anton Youdkevitch]

On Mon, Apr 27, 2020 at 04:34:49PM +, Kyrylo Tkachov wrote:
> Hi Anton,
> 
> > -Original Message-
> > From: Anton Youdkevitch 
> > Sent: 27 April 2020 11:24
> > To: gcc-patches@gcc.gnu.org
> > Cc: Richard Earnshaw ; Kyrylo Tkachov
> > ; James Greenhalgh
> > ; Richard Sandiford
> > ; jjo...@marvell.com
> > Subject: [PATCH v5] aarch64: Add TX3 machine model
> > 
> > Here is the patch introducing thunderx3t110 machine model
> > for the scheduler. A name for the new chip was added to the
> > list of the names to be recognized as a valid parameter for
> > mcpu and mtune flags. Added the TX3 tuning table and cost
> > model tables.
> > 
> > Added the new chip name to the documentation. Fixed copyright
> > names and dates.
> > 
> > Lowering the chip capabilities to v8.3 to be on the safe side.
> > 
> > Bootstrapped on AArch64.
> > 
> > 2020-04-27 Anton Youdkevitch 
> > 
> > * config/aarch64/aarch64-cores.def: Add the chip name.
> > * config/aarch64/aarch64-tune.md: Regenerated.
> > * config/aarch64/aarch64.c: Add tuning table for the chip.
> > * gcc/config/aarch64/aarch64-cost-tables.h: Add cost tables.
> > * config/aarch64/thunderx3t110.md: New file: add the new
> > machine model for the scheduler
> > * config/aarch64/aarch64.md: Include the new model.
> > * doc/invoke.texi: Add the new name to the list
> > 
> > 
> > ---
> >  gcc/config/aarch64/aarch64-cores.def |   3 +
> >  gcc/config/aarch64/aarch64-cost-tables.h | 103 +++
> >  gcc/config/aarch64/aarch64-tune.md   |   2 +-
> >  gcc/config/aarch64/aarch64.c |  83 ++
> >  gcc/config/aarch64/aarch64.md|   1 +
> >  gcc/config/aarch64/thunderx3t110.md  | 686 +++
> >  gcc/doc/invoke.texi  |   2 +-
> >  7 files changed, 878 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/config/aarch64/aarch64-cores.def 
> b/gcc/config/aarch64/aarch64-cores.def
> index ea9b98b..4d8605a 100644
> --- a/gcc/config/aarch64/aarch64-cores.def
> +++ b/gcc/config/aarch64/aarch64-cores.def
> @@ -95,6 +95,9 @@ AARCH64_CORE("vulcan",  vulcan, thunderx2t99, 8_1A,  
> AARCH64_FL_FOR_ARCH8_1 | AA
>  /* Cavium ('C') cores. */
>  AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  
> AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x43, 0x0af, -1)
>  
> +/* Marvell cores (TX3). */
> +AARCH64_CORE("thunderx3t110",  thunderx3t110,  thunderx3t110, 8_3A,  
> AARCH64_FL_FOR_ARCH8_3 | AARCH64_FL_CRYPTO | AARCH64_FL_RCPC | AARCH64_FL_SM4 
> | AARCH64_FL_SHA3 | AARCH64_FL_F16FML | AARCH64_FL_RCPC8_4, thunderx3t110, 
> 0x43, 0x0b8, 0x0a)
> +
> 
> Please move this to a new section with a  comment /* ARMv8.3-A Architecture 
> processors*/
> So that we're consistent with the format of the file.
Fixed.

> 
> Ok with that change.
> Kyrill
> 
>  /* ARMv8.2-A Architecture Processors.  */
>From a71d57dc10b34a49a0f51fac47d2881793eaf7e8 Mon Sep 17 00:00:00 2001
From: Anton Youdkevitch 
Date: Mon, 23 Mar 2020 13:22:35 -0700
Subject: [PATCH] TX3 scheduling and tuning implementation

Added the scheduler descriptions for TX3. Also
added the tuning table and the cost tables for
TX3.

2020-04-27 Anton Youdkevitch 

* config/aarch64/aarch64-cores.def: Add the chip name.
* config/aarch64/aarch64-tune.md: Regenerated.
* config/aarch64/aarch64.c: Add tuning table for the chip.
* gcc/config/aarch64/aarch64-cost-tables.h: Add cost tables.
* config/aarch64/thunderx3t11.md: New file: add the new
machine model for the scheduler
* config/aarch64/aarch64.md: Include the new model.
* doc/invoke.texi: Add the new name to the list
---
 gcc/config/aarch64/aarch64-cores.def |   5 +
 gcc/config/aarch64/aarch64-cost-tables.h | 103 +
 gcc/config/aarch64/aarch64-tune.md   |   2 +-
 gcc/config/aarch64/aarch64.c |  83 
 gcc/config/aarch64/aarch64.md|   1 +
 gcc/config/aarch64/thunderx3t110.md  | 686 +++
 gcc/doc/invoke.texi  |   2 +-
 7 files changed, 880 insertions(+), 2 deletions(-)
 create mode 100644 gcc/config/aarch64/thunderx3t110.md

diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index ea9b98b..31da488 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -122,6 +122,11 @@ AARCH64_CORE("octeontx2f95mm", octeontx2f95mm, cortexa57, 8_2A,  AARCH64_FL_FOR_
 /* HiSilicon ('H') cores. */
 AARCH64_CORE("tsv110",  tsv110, tsv110, 8_2A,  AARCH64_FL_FOR_ARCH8_2 | AARCH64_FL_CRYPTO | AARCH64_FL_F16 | AARCH64_FL_AES | AARCH64_FL_SHA2, tsv110,   0x48, 0xd01, -1)
 
+/* ARMv8.3-A Architecture Processors.  */
+
+/* Marvell cores (TX3). */
+AARCH64_CORE("thunderx3t110",  thunderx3t110,  thunderx3t110, 8_3A,  AARCH64_FL_FOR_ARCH8_3 | AARCH64_FL_CRYPTO | AARCH64_FL_RCPC | AARCH64_FL_SM4 | AARCH64_FL_SHA3 | AARCH64_FL_F16FML | AARCH64_FL_RCPC8_4, 

[committed] aarch64: disable test on ilp32 [PR94697]

[Szabolcs Nagy]

branch-protection=pac-ret is not supported on ilp32 now and
the test requires it via branch-protection=standard.

committed as obvious.

gcc/testsuite/ChangeLog:

PR target/94697
* gcc.target/aarch64/pr94697.c: Require lp64.
---
 gcc/testsuite/ChangeLog| 5 +
 gcc/testsuite/gcc.target/aarch64/pr94697.c | 1 +
 2 files changed, 6 insertions(+)

diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 5a85af479c8..8b23374c591 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-27  Szabolcs Nagy  
+
+   PR target/94697
+   * gcc.target/aarch64/pr94697.c: Require lp64.
+
 2020-04-27  Jakub Jelinek  
 
PR c/94755
diff --git a/gcc/testsuite/gcc.target/aarch64/pr94697.c 
b/gcc/testsuite/gcc.target/aarch64/pr94697.c
index e6069d22ece..fcc9ab87f15 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr94697.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr94697.c
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-require-effective-target lp64 } */
 /* { dg-options "-O2 -mbranch-protection=standard" } */
 /* { dg-final { check-function-bodies "**" "" } } */
 
-- 
2.17.1

Re: [PATCH v5] aarch64: Add TX3 machine model

[Anton Youdkevitch]

On 27.4.2020 19:34 , Kyrylo Tkachov wrote:

Hi Anton,


-Original Message-
From: Anton Youdkevitch 
Sent: 27 April 2020 11:24
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw ; Kyrylo Tkachov
; James Greenhalgh
; Richard Sandiford
; jjo...@marvell.com
Subject: [PATCH v5] aarch64: Add TX3 machine model

Here is the patch introducing thunderx3t110 machine model
for the scheduler. A name for the new chip was added to the
list of the names to be recognized as a valid parameter for
mcpu and mtune flags. Added the TX3 tuning table and cost
model tables.

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

Lowering the chip capabilities to v8.3 to be on the safe side.

Bootstrapped on AArch64.

2020-04-27 Anton Youdkevitch 

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


---
  gcc/config/aarch64/aarch64-cores.def |   3 +
  gcc/config/aarch64/aarch64-cost-tables.h | 103 +++
  gcc/config/aarch64/aarch64-tune.md   |   2 +-
  gcc/config/aarch64/aarch64.c |  83 ++
  gcc/config/aarch64/aarch64.md|   1 +
  gcc/config/aarch64/thunderx3t110.md  | 686 +++
  gcc/doc/invoke.texi  |   2 +-
  7 files changed, 878 insertions(+), 2 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-cores.def 
b/gcc/config/aarch64/aarch64-cores.def
index ea9b98b..4d8605a 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -95,6 +95,9 @@ AARCH64_CORE("vulcan",  vulcan, thunderx2t99, 8_1A,  
AARCH64_FL_FOR_ARCH8_1 | AA
  /* Cavium ('C') cores. */
  AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  
AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x43, 0x0af, -1)
  
+/* Marvell cores (TX3). */

+AARCH64_CORE("thunderx3t110",  thunderx3t110,  thunderx3t110, 8_3A,  
AARCH64_FL_FOR_ARCH8_3 | AARCH64_FL_CRYPTO | AARCH64_FL_RCPC | AARCH64_FL_SM4 | 
AARCH64_FL_SHA3 | AARCH64_FL_F16FML | AARCH64_FL_RCPC8_4, thunderx3t110, 0x43, 0x0b8, 
0x0a)
+

Please move this to a new section with a  comment /* ARMv8.3-A Architecture 
processors*/
So that we're consistent with the format of the file.

Will do. Thanks,



Ok with that change.
Kyrill

  /* ARMv8.2-A Architecture Processors.  */

Re: [PATCH v2 1/2] RISC-V: Add shorten_memrefs pass

[Craig Blackmore]

On 08/04/2020 17:04, Jim Wilson wrote:

> On Wed, Feb 19, 2020 at 3:40 AM Craig Blackmore
>  wrote:
>> On 10/12/2019 18:28, Craig Blackmore wrote:
>> Thank you for your review. I have posted an updated patch below which I think
>> addresses your comments.
>>
>> Ping
>>
>> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00712.html
> This looks OK.  There are some minor issues.
>
> (riscv_new_address_profitable_p): New function.
> (TARGET_NEW_ADDRESS_PROFITABLE_P): Define.
>
> These are actually in part2, and part2 already has changelog entries
> for them, so these can just be dropped.
>
> +  /* When optimizing for size, make uncompressible 32-bit addresses more
> +   * expensive so that compressible 32-bit addresses are preferred.  */
> +  if (!speed && riscv_mshorten_memrefs && mode == SImode
> +  && !riscv_compressed_lw_address_p (addr))
> +return riscv_address_insns (addr, mode, false) + 1;
>
> I think that there should be a TARGET_RVC check here, just like in the gate
> function for the new pass.  But I also suspect that this probably
> doesn't matter much.

Hi Jim,

Thanks for the review. I have updated the following patch with those changes.

Craig

---

gcc/ChangeLog:

* config.gcc:  Add riscv-shorten-memrefs.o to extra_objs for riscv.
* config/riscv/riscv-passes.def: New file.
* config/riscv/riscv-protos.h (make_pass_shorten_memrefs): Declare.
* config/riscv/riscv-shorten-memrefs.c: New file.
* config/riscv/riscv.c (tree-pass.h): New include.
(riscv_compressed_reg_p): New Function
(riscv_compressed_lw_offset_p): Likewise.
(riscv_compressed_lw_address_p): Likewise.
(riscv_shorten_lw_offset): Likewise.
(riscv_legitimize_address): Attempt to convert base + large_offset
to compressible new_base + small_offset.
(riscv_address_cost): Make anticipated compressed load/stores
cheaper for code size than uncompressed load/stores.
(riscv_register_priority): Move compressed register check to
riscv_compressed_reg_p.
* config/riscv/riscv.h (C_S_BITS): Define.
(CSW_MAX_OFFSET): Define.
* config/riscv/riscv.opt (mshorten-memefs): New option.
* config/riscv/t-riscv (riscv-shorten-memrefs.o): New rule.
(PASSES_EXTRA): Add riscv-passes.def.
* doc/invoke.texi: Document -mshorten-memrefs.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/shorten-memrefs-1.c: New test.
* gcc.target/riscv/shorten-memrefs-2.c: New test.
* gcc.target/riscv/shorten-memrefs-3.c: New test.
* gcc.target/riscv/shorten-memrefs-4.c: New test.
* gcc.target/riscv/shorten-memrefs-5.c: New test.
* gcc.target/riscv/shorten-memrefs-6.c: New test.
* gcc.target/riscv/shorten-memrefs-7.c: New test.
---
 gcc/config.gcc|   2 +-
 gcc/config/riscv/riscv-passes.def |  20 ++
 gcc/config/riscv/riscv-protos.h   |   2 +
 gcc/config/riscv/riscv-shorten-memrefs.c  | 200 ++
 gcc/config/riscv/riscv.c  |  88 +++-
 gcc/config/riscv/riscv.h  |   5 +
 gcc/config/riscv/riscv.opt|   6 +
 gcc/config/riscv/t-riscv  |   5 +
 gcc/doc/invoke.texi   |  10 +
 .../gcc.target/riscv/shorten-memrefs-1.c  |  26 +++
 .../gcc.target/riscv/shorten-memrefs-2.c  |  51 +
 .../gcc.target/riscv/shorten-memrefs-3.c  |  39 
 .../gcc.target/riscv/shorten-memrefs-4.c  |  26 +++
 .../gcc.target/riscv/shorten-memrefs-5.c  |  53 +
 .../gcc.target/riscv/shorten-memrefs-6.c  |  39 
 .../gcc.target/riscv/shorten-memrefs-7.c  |  46 
 16 files changed, 612 insertions(+), 6 deletions(-)
 create mode 100644 gcc/config/riscv/riscv-passes.def
 create mode 100644 gcc/config/riscv/riscv-shorten-memrefs.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shorten-memrefs-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shorten-memrefs-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shorten-memrefs-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shorten-memrefs-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shorten-memrefs-5.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shorten-memrefs-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/shorten-memrefs-7.c

diff --git a/gcc/config.gcc b/gcc/config.gcc
index cf1a87e2efd..3c2a0389b98 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -525,7 +525,7 @@ pru-*-*)
;;
 riscv*)
cpu_type=riscv
-   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o"
+   extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o 
riscv-shorten-memrefs.o"
d_target_objs="riscv-d.o"
;;
 rs6000*-*-*)
diff --git a/gcc/config/riscv/riscv-passes.def 
b/gcc/config/riscv/riscv-passes.def
new file mode 100644
index 000..8a4ea0918db
--- /dev/null
+++ 

[PATCH] Check whether -fcf-protection=none -Wl, -z, ibt, -z, shstk work first

[H.J. Lu via Gcc-patches]

GCC_CET_HOST_FLAGS uses -Wl,-z,ibt,-z,shstk to check if Linux/x86 host
has Intel CET enabled by introducing an Intel CET violation on purpose.
To avoid false positive, check whether -Wl,-z,ibt,-z,shstk works first.
-fcf-protection=none is added to avoid false negative when -fcf-protection
is enabled by default.

OK for master?

H.J.
---
config/

PR bootstrap/94739
* cet.m4 (GCC_CET_HOST_FLAGS): Add -fcf-protection=none to
-Wl,-z,ibt,-z,shstk.  Check whether -fcf-protection=none
-Wl,-z,ibt,-z,shstk works first.

libiberty/

PR bootstrap/94739
* configure: Regenerated.

lto-plugin/

PR bootstrap/94739
* configure: Regenerated.
---
 config/cet.m4|  17 --
 libiberty/configure  | 126 ++-
 lto-plugin/configure |  35 ++--
 3 files changed, 121 insertions(+), 57 deletions(-)

diff --git a/config/cet.m4 b/config/cet.m4
index 8b9e01fd492..ea616b728a9 100644
--- a/config/cet.m4
+++ b/config/cet.m4
@@ -98,9 +98,19 @@ asm ("setssbsy");
 ;;
 esac
 
+save_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -fcf-protection=none"
+save_LDFLAGS="$LDFLAGS"
+LDFLAGS="$LDFLAGS -Wl,-z,ibt,-z,shstk"
+if test x$may_have_cet = xyes; then
+  # Check whether -fcf-protection=none -Wl,-z,ibt,-z,shstk work.
+  AC_TRY_LINK(
+[],[return 0;],
+[may_have_cet=yes],
+[may_have_cet=no])
+fi
+
 if test x$may_have_cet = xyes; then
-  save_LDFLAGS="$LDFLAGS"
-  LDFLAGS="$LDFLAGS -Wl,-z,ibt,-z,shstk"
   AC_TRY_RUN([
 static void
 foo (void)
@@ -130,7 +140,6 @@ main ()
   ],
   [have_cet=no],
   [have_cet=yes])
-  LDFLAGS="$save_LDFLAGS"
   if test x$enable_cet = xno -a x$have_cet = xyes; then
 AC_MSG_ERROR([Intel CET must be enabled on Intel CET enabled host])
   fi
@@ -141,4 +150,6 @@ if test x$enable_cet = xyes; then
 else
   AC_MSG_RESULT([no])
 fi
+CFLAGS="$save_CFLAGS"
+LDFLAGS="$save_LDFLAGS"
 ])
diff --git a/libiberty/configure b/libiberty/configure
index 2b52ce86c89..bb76cf1b823 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -1674,6 +1674,52 @@ $as_echo "$ac_res" >&6; }
 
 } # ac_fn_c_check_header_compile
 
+# ac_fn_c_try_link LINENO
+# ---
+# Try to link conftest.$ac_ext, and return whether this succeeded.
+ac_fn_c_try_link ()
+{
+  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
+  rm -f conftest.$ac_objext conftest$ac_exeext
+  if { { ac_try="$ac_link"
+case "(($ac_try" in
+  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
+  *) ac_try_echo=$ac_try;;
+esac
+eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
+$as_echo "$ac_try_echo"; } >&5
+  (eval "$ac_link") 2>conftest.err
+  ac_status=$?
+  if test -s conftest.err; then
+grep -v '^ *+' conftest.err >conftest.er1
+cat conftest.er1 >&5
+mv -f conftest.er1 conftest.err
+  fi
+  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
+  test $ac_status = 0; } && {
+test -z "$ac_c_werror_flag" ||
+test ! -s conftest.err
+   } && test -s conftest$ac_exeext && {
+test "$cross_compiling" = yes ||
+test -x conftest$ac_exeext
+   }; then :
+  ac_retval=0
+else
+  $as_echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+   ac_retval=1
+fi
+  # Delete the IPA/IPO (Inter Procedural Analysis/Optimization) information
+  # created by the PGI compiler (conftest_ipa8_conftest.oo), as it would
+  # interfere with the next link command; also delete a directory that is
+  # left behind by Apple's compiler.  We do this before executing the actions.
+  rm -rf conftest.dSYM conftest_ipa8_conftest.oo
+  eval $as_lineno_stack; ${as_lineno_stack:+:} unset as_lineno
+  as_fn_set_status $ac_retval
+
+} # ac_fn_c_try_link
+
 # ac_fn_c_check_header_preproc LINENO HEADER VAR
 # --
 # Tests whether HEADER is present, setting the cache variable VAR accordingly.
@@ -1940,52 +1986,6 @@ $as_echo "$ac_res" >&6; }
 
 } # ac_fn_c_check_type
 
-# ac_fn_c_try_link LINENO
-# ---
-# Try to link conftest.$ac_ext, and return whether this succeeded.
-ac_fn_c_try_link ()
-{
-  as_lineno=${as_lineno-"$1"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
-  rm -f conftest.$ac_objext conftest$ac_exeext
-  if { { ac_try="$ac_link"
-case "(($ac_try" in
-  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
-  *) ac_try_echo=$ac_try;;
-esac
-eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
-$as_echo "$ac_try_echo"; } >&5
-  (eval "$ac_link") 2>conftest.err
-  ac_status=$?
-  if test -s conftest.err; then
-grep -v '^ *+' conftest.err >conftest.er1
-cat conftest.er1 >&5
-mv -f conftest.er1 conftest.err
-  fi
-  $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
-  test $ac_status = 0; } && {
-test -z "$ac_c_werror_flag" ||
-test ! -s conftest.err
-   } && test -s conftest$ac_exeext && {
-test "$cross_compiling" = yes ||
-test -x 

[PATCH, PR94774] tree-optimization: Fix use of uninitialized variable

[Stefan Schulze Frielinghaus via Gcc-patches]

Array retval is not necessarily initialized by function is_call_safe and
may be used afterwards.  Thus, initialize it explicitly.

Ok for master?

gcc/ChangeLog:

2020-04-27  Stefan Schulze Frielinghaus  

PR tree-optimization/94774
* gimple-ssa-sprintf.c (try_substitute_return_value): Initialize
variable retval.
---
 gcc/gimple-ssa-sprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 1879686ce0a..011c3e21e63 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -4120,7 +4120,7 @@ try_substitute_return_value (gimple_stmt_iterator *gsi,
   bool removed = false;
 
   /* The minimum and maximum return value.  */
-  unsigned HOST_WIDE_INT retval[2];
+  unsigned HOST_WIDE_INT retval[2] = {0};
   bool safe = is_call_safe (info, res, true, retval);
 
   if (safe
-- 
2.25.3

Re: [RFC] Clarify -ffinite-math-only documentation

[Richard Sandiford]

Richard Biener via Gcc-patches  writes:
> On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz  wrote:
>>
>> Hi,
>>
>> This documentation change clarifies the effect of -ffinite-math-only. With 
>> the
>> current documentation, it is unclear what the presence of NaN and Inf
>> representations means if (arithmetic) operations on such values are
>> unspecified and even classification functions like isnan are unreliable. If
>> the hardware thinks a certain bit pattern is a NaN, but the software assumes 
>> a
>> NaN value cannot ever exist, it is questionable whether, from a language
>> viewpoint, a representation for NaNs really exists. Because, a NaN is defined
>> by its behavior. This change also clarifies that isnan(nan) returning false 
>> is
>> fine.
>>
>> This relates to PR84949.
>>
>> * doc/invoke.texi: Clarify the effects of -ffinite-math-only.
>> ---
>>  gcc/doc/invoke.texi | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index a37a2ee9c19..9e76ab057a9 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -11619,8 +11619,10 @@ The default is @option{-fno-reciprocal-math}.
>>
>>  @item -ffinite-math-only
>>  @opindex ffinite-math-only
>> -Allow optimizations for floating-point arithmetic that assume
>> -that arguments and results are not NaNs or +-Infs.
>> +Assume that floating-point types in the language do not have representations
>> for
>> +NaNs and +-Inf. Whether floating-point hardware supports and acts on NaNs 
>> and
>> ++-Inf is not affected. The behavior of a program that uses a NaN or +-Inf
>> value
>> +as function argument, macro argument, or operand is undefined.
>
> Minor nit here - I'd avoid the 'undefined' word which has bad connotation
> and use 'unspecified'.  Maybe we can even use ISO C language specification
> terms but I'm not sure which one is most appropriate here.
>
> Curiously __builtin_nan ("nan") still gets you a NaN representation
> but isnan(__builtin_nan("nan")) is resolved to false.

Yeah, for that and other reasons, I think it would be good to avoid
giving the impression that -ffinite-math-only can be relied on to make
the assumption above.  Wouldn't it be more accurate to say that the
compiler is allowed to make the assumption, at any point that it seems
convenient?

Thanks,
Richard

RE: [PATCH v5] aarch64: Add TX3 machine model

[Kyrylo Tkachov]

Hi Anton,

> -Original Message-
> From: Anton Youdkevitch 
> Sent: 27 April 2020 11:24
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
> ; James Greenhalgh
> ; Richard Sandiford
> ; jjo...@marvell.com
> Subject: [PATCH v5] aarch64: Add TX3 machine model
> 
> Here is the patch introducing thunderx3t110 machine model
> for the scheduler. A name for the new chip was added to the
> list of the names to be recognized as a valid parameter for
> mcpu and mtune flags. Added the TX3 tuning table and cost
> model tables.
> 
> Added the new chip name to the documentation. Fixed copyright
> names and dates.
> 
> Lowering the chip capabilities to v8.3 to be on the safe side.
> 
> Bootstrapped on AArch64.
> 
> 2020-04-27 Anton Youdkevitch 
> 
> * config/aarch64/aarch64-cores.def: Add the chip name.
> * config/aarch64/aarch64-tune.md: Regenerated.
> * config/aarch64/aarch64.c: Add tuning table for the chip.
> * gcc/config/aarch64/aarch64-cost-tables.h: Add cost tables.
> * config/aarch64/thunderx3t110.md: New file: add the new
> machine model for the scheduler
> * config/aarch64/aarch64.md: Include the new model.
> * doc/invoke.texi: Add the new name to the list
> 
> 
> ---
>  gcc/config/aarch64/aarch64-cores.def |   3 +
>  gcc/config/aarch64/aarch64-cost-tables.h | 103 +++
>  gcc/config/aarch64/aarch64-tune.md   |   2 +-
>  gcc/config/aarch64/aarch64.c |  83 ++
>  gcc/config/aarch64/aarch64.md|   1 +
>  gcc/config/aarch64/thunderx3t110.md  | 686 +++
>  gcc/doc/invoke.texi  |   2 +-
>  7 files changed, 878 insertions(+), 2 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-cores.def 
b/gcc/config/aarch64/aarch64-cores.def
index ea9b98b..4d8605a 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -95,6 +95,9 @@ AARCH64_CORE("vulcan",  vulcan, thunderx2t99, 8_1A,  
AARCH64_FL_FOR_ARCH8_1 | AA
 /* Cavium ('C') cores. */
 AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  
AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x43, 0x0af, -1)
 
+/* Marvell cores (TX3). */
+AARCH64_CORE("thunderx3t110",  thunderx3t110,  thunderx3t110, 8_3A,  
AARCH64_FL_FOR_ARCH8_3 | AARCH64_FL_CRYPTO | AARCH64_FL_RCPC | AARCH64_FL_SM4 | 
AARCH64_FL_SHA3 | AARCH64_FL_F16FML | AARCH64_FL_RCPC8_4, thunderx3t110, 0x43, 
0x0b8, 0x0a)
+

Please move this to a new section with a  comment /* ARMv8.3-A Architecture 
processors*/
So that we're consistent with the format of the file.

Ok with that change.
Kyrill

 /* ARMv8.2-A Architecture Processors.  */

Re: [RFC] Clarify -ffinite-math-only documentation

[Richard Biener via Gcc-patches]

On Mon, Apr 27, 2020 at 6:09 PM Matthias Kretz  wrote:
>
> Hi,
>
> This documentation change clarifies the effect of -ffinite-math-only. With the
> current documentation, it is unclear what the presence of NaN and Inf
> representations means if (arithmetic) operations on such values are
> unspecified and even classification functions like isnan are unreliable. If
> the hardware thinks a certain bit pattern is a NaN, but the software assumes a
> NaN value cannot ever exist, it is questionable whether, from a language
> viewpoint, a representation for NaNs really exists. Because, a NaN is defined
> by its behavior. This change also clarifies that isnan(nan) returning false is
> fine.
>
> This relates to PR84949.
>
> * doc/invoke.texi: Clarify the effects of -ffinite-math-only.
> ---
>  gcc/doc/invoke.texi | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index a37a2ee9c19..9e76ab057a9 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -11619,8 +11619,10 @@ The default is @option{-fno-reciprocal-math}.
>
>  @item -ffinite-math-only
>  @opindex ffinite-math-only
> -Allow optimizations for floating-point arithmetic that assume
> -that arguments and results are not NaNs or +-Infs.
> +Assume that floating-point types in the language do not have representations
> for
> +NaNs and +-Inf. Whether floating-point hardware supports and acts on NaNs and
> ++-Inf is not affected. The behavior of a program that uses a NaN or +-Inf
> value
> +as function argument, macro argument, or operand is undefined.

Minor nit here - I'd avoid the 'undefined' word which has bad connotation
and use 'unspecified'.  Maybe we can even use ISO C language specification
terms but I'm not sure which one is most appropriate here.

Curiously __builtin_nan ("nan") still gets you a NaN representation
but isnan(__builtin_nan("nan")) is resolved to false.

>  This option is not turned on by any @option{-O} option since
>  it can result in incorrect output for programs that depend on
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  std::experimental::simd  https://github.com/VcDevel/std-simd
> ──
>

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

[Martin Sebor via Gcc-patches]

On 4/22/20 12:39 PM, Giuliano Belinassi via Gcc-patches wrote:

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


Just a few comments on this nice cleanup:

It looks to me like class build_virtual_operands isn't safe to copy
or assign due its vec member.  If that's correct, can you please
either disable copying and assignments for such classes or make sure
they can be?  (The macro DISABLE_COPY_AND_ASSIGN will do the former.)

I would also suggest to avoid declaring member functions inline.
It serves no purpose if the function is also defined inline later
on and  causes problems when it isn't (e.g., when the definition
is moved to a .cc file).

Finally, as a purely cosmetic improvement, although it's benign
the void parameter in a parameter list can be omitted in C++.

Martin



Just sending this for when Stage1 is back again.

I ran the testsuite and bootstraped in a x86_64 linux machine and
found no issues.

gcc/ChangeLog:
2020-04-22  Giuliano Belinassi  

* tree-ssa-operands.c (build_virtual_operands): New class.
(operands_bitmap_obstack): Remove.
(n_initialized): Remove.
(build_uses): Move to build_virtual_operands class.
(build_vuse): Same as above.
(build_vdef): Same as above.
(verify_ssa_operands): Same as above.
(finalize_ssa_uses): Same as above.
(cleanup_build_arrays): Same as above.
(finalize_ssa_stmt_operands): Same as above.
(start_ssa_stmt_operands): Same as above.
(append_use): Same as above.
(append_vdef): Same as above.
(add_virtual_operand): Same as above.
(add_stmt_operand): Same as above.
(get_mem_ref_operands): Same as above.
(get_tmr_operands): Same as above.
(maybe_add_call_vops): Same as above.
(get_asm_stmt_operands): Same as above.
(get_expr_operands): Same as above.
(parse_ssa_operands): Same as above.
(finalize_ssa_defs): Same as above.
(build_ssa_operands): Same as above, plus create a C-like wrapper.
(update_stmt_operands): Create an instance of build_virtual_operands.

RE: [PATCH] arm: Fix an rtl checking failure in cde-errors.c

[Kyrylo Tkachov]

> -Original Message-
> From: Richard Sandiford 
> Sent: 27 April 2020 17:14
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov 
> Subject: [PATCH] arm: Fix an rtl checking failure in cde-errors.c
> 
> cde-errors.c and cde-mve-error-2.c were failing with an rtl checking
> failure because we applied UINTVAL to a nonconstant argument
> (specifically a REG).
> 
> Tested on arm-linux-gnueabihf.  OK to install?

Ok.
Thanks,
Kyrill

> 
> Richard
> 
> 
> 2020-04-27  Richard Sandiford  
> 
> gcc/
>   * config/arm/arm-builtins.c (arm_expand_builtin_args): Only apply
>   UINTVAL to CONST_INTs.
> ---
>  gcc/config/arm/arm-builtins.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
> index 16d2fb0b3f0..aee3fd6e2ff 100644
> --- a/gcc/config/arm/arm-builtins.c
> +++ b/gcc/config/arm/arm-builtins.c
> @@ -3081,7 +3081,8 @@ constant_arg:
>   {
> if (argc == 0)
>   {
> -   unsigned int cp_bit = UINTVAL (op[argc]);
> +   unsigned int cp_bit = (CONST_INT_P (op[argc])
> +  ? UINTVAL (op[argc]) : -1);
> if (IN_RANGE (cp_bit, 0,
> ARM_CDE_CONST_COPROC))
>   error ("%Kcoprocessor %d is not enabled "
>  "with +cdecp%d", exp, cp_bit, cp_bit);

[PATCH] arm: Fix an rtl checking failure in cde-errors.c

[Richard Sandiford]

cde-errors.c and cde-mve-error-2.c were failing with an rtl checking
failure because we applied UINTVAL to a nonconstant argument
(specifically a REG).

Tested on arm-linux-gnueabihf.  OK to install?

Richard


2020-04-27  Richard Sandiford  

gcc/
* config/arm/arm-builtins.c (arm_expand_builtin_args): Only apply
UINTVAL to CONST_INTs.
---
 gcc/config/arm/arm-builtins.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index 16d2fb0b3f0..aee3fd6e2ff 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -3081,7 +3081,8 @@ constant_arg:
{
  if (argc == 0)
{
- unsigned int cp_bit = UINTVAL (op[argc]);
+ unsigned int cp_bit = (CONST_INT_P (op[argc])
+? UINTVAL (op[argc]) : -1);
  if (IN_RANGE (cp_bit, 0, ARM_CDE_CONST_COPROC))
error ("%Kcoprocessor %d is not enabled "
   "with +cdecp%d", exp, cp_bit, cp_bit);

[PATCH] vect: Fix COND_EXPRs involving variant booleans [PR94727]

[Richard Sandiford]

Christophe Lyon  writes:
>> This PR was caused by mismatched expectations between
>> vectorizable_comparison and SLP.  We had a "<" comparison
>> between two booleans that were leaves of the SLP tree, so
>> vectorizable_comparison fell back on:
>>
>>   /* Invariant comparison.  */
>>   if (!vectype)
>> {
>>   vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (rhs1),
>>  slp_node);
>>   if (maybe_ne (TYPE_VECTOR_SUBPARTS (vectype), nunits))
>> return false;
>> }
>>
>> rhs1 and rhs2 were *unsigned* boolean types, so we got back a vector
>> of unsigned integers.  This in itself was OK, and meant that "<"
>> worked as expected without the need for the boolean fix-ups:
>>
>>   /* Boolean values may have another representation in vectors
>>  and therefore we prefer bit operations over comparison for
>>  them (which also works for scalar masks).  We store opcodes
>>  to use in bitop1 and bitop2.  Statement is vectorized as
>>BITOP2 (rhs1 BITOP1 rhs2) or
>>rhs1 BITOP2 (BITOP1 rhs2)
>>  depending on bitop1 and bitop2 arity.  */
>>   bool swap_p = false;
>>   if (VECTOR_BOOLEAN_TYPE_P (vectype))
>> {
>>
>> However, vectorizable_comparison then used vect_get_slp_defs to get
>> the actual operands.  The request went to vect_get_constant_vectors,
>> which also has logic to calculate the vector type.  The problem was
>> that this type was different from the one chosen above:
>>
>>   if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op))
>>   && vect_mask_constant_operand_p (stmt_vinfo))
>> vector_type = truth_type_for (stmt_vectype);
>>   else
>> vector_type = get_vectype_for_scalar_type (vinfo, TREE_TYPE (op), 
>> op_node);
>>
>> So the function gave back a vector of mask types, which here are vectors
>> of *signed* booleans.  This meant that "<" gave:
>>
>>   true (-1) < false (0)
>>
>> and so the boolean fixup above was needed after all.
>>
>> Fixed by making vectorizable_comparison also pick a mask type in this case.
>>
>> Tested on aarch64-linux-gnu (with and without SVE) and x86_64-linux-gnu.
>> Approved by Richard in the PR.
>>
>> Richard
>>
>>
>> 2020-04-23  Richard Sandiford  
>>
>> gcc/
>> PR tree-optimization/94727
>> * tree-vect-stmts.c (vectorizable_comparison): Use mask_type when
>> comparing invariant scalar booleans.
>>
>> gcc/testsuite/
>> PR tree-optimization/94727
>> * gcc.dg/vect/pr94727.c: New test.
>
> Hi Richard,
>
> The new testcase fails at execution on arm (and s390 according to
> gcc-testresults).
>
> Can you check?

Thanks for the heads-up.  Looks like we need the same fix when
handling comparisons embedded in a VEC_COND_EXPR.

Here too, the problem is that vect_get_constant_vectors will
calculate its own vector type, using truth_type_for on the
STMT_VINFO_VECTYPE, and the vectoriable_* routines need to be
consistent with that.

Tested on arm-linux-gnueabihf and x86_64-linux-gnu.  OK to install?

Richard


2020-04-27  Richard Sandiford  

gcc/
PR tree-optimization/94727
* tree-vect-stmts.c (vect_is_simple_cond): If both comparison
operands are invariant booleans, use the mask type associated with the
STMT_VINFO_VECTYPE.  Use !slp_node instead of !vectype to exclude SLP.
(vectorizable_condition): Pass vectype unconditionally to
vect_is_simple_cond.
---
 gcc/tree-vect-stmts.c | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 88a1e2c51d2..1984787bac4 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -9942,16 +9942,21 @@ vect_is_simple_cond (tree cond, vec_info *vinfo, 
slp_tree slp_node,
   if (! *comp_vectype)
 {
   tree scalar_type = TREE_TYPE (lhs);
-  /* If we can widen the comparison to match vectype do so.  */
-  if (INTEGRAL_TYPE_P (scalar_type)
- && vectype
- && tree_int_cst_lt (TYPE_SIZE (scalar_type),
- TYPE_SIZE (TREE_TYPE (vectype
-   scalar_type = build_nonstandard_integer_type
- (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (vectype))),
-  TYPE_UNSIGNED (scalar_type));
-  *comp_vectype = get_vectype_for_scalar_type (vinfo, scalar_type,
-  slp_node);
+  if (VECT_SCALAR_BOOLEAN_TYPE_P (scalar_type))
+   *comp_vectype = truth_type_for (vectype);
+  else
+   {
+ /* If we can widen the comparison to match vectype do so.  */
+ if (INTEGRAL_TYPE_P (scalar_type)
+ && !slp_node
+ && tree_int_cst_lt (TYPE_SIZE (scalar_type),
+ TYPE_SIZE (TREE_TYPE (vectype
+   scalar_type = build_nonstandard_integer_type
+ (tree_to_uhwi (TYPE_SIZE (TREE_TYPE (vectype))),
+  TYPE_UNSIGNED (scalar_type));
+ *comp_vectype = 

[committed] wwwdocs: Correct two validation errors.

[Iain Sandoe]

Hi,
This corrects two errors picked up by the validator.
(one in the patch I just applied, one pre-existing).
thanks
iain

---
 htdocs/projects/cxx-status.html | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index 6a715058..1a2633ef 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -278,6 +278,7 @@
 
   https://wg21.link/p2095r0;>P2095R0
   10
+   
 
 
Proposed wording for likely and unlikely attributes 
@@ -444,7 +445,7 @@
 
 
Coroutines 
-  https://wg21.link/p0912r5;>P0912R5
+  https://wg21.link/p0912r5;>P0912R5
   as applied to http://wg21.link/n4861;>n4861
10 
(requires -fcoroutines)
-- 
2.14.3

[Arm] Account for C++17 artificial field determining Homogeneous Aggregates

[Matthew Malcomson]

NOTE:
  There is another patch in the making to handle the APCS abi (selected with
  `-mabi=apcs-gnu`).  That patch has a very different change in behaviour and
  is in a different part of the code so I'm keeping it in a different patch.

In C++14, an empty class deriving from an empty base is not an
aggregate, while in C++17 it is.  In order to implement this, GCC adds
an artificial field to such classes.

This artificial field has no mapping to Fundamental Data Types in the
Arm PCS ABI and hence should not count towards determining whether an
object can be passed using the vector registers as per section
"7.1.2 Procedure Calling" in the arm PCS
https://developer.arm.com/docs/ihi0042/latest?_ga=2.60211309.1506853196.1533541889-405231439.1528186050

This patch avoids counting this artificial field in
aapcs_vfp_sub_candidate, and hence calculates whether such objects
should be passed in vector registers in the same manner as C++14 (where
the artificial field does not exist).

Before this change, the test below would pass the arguments to `f` in
general registers.  After this change, the test passes the arguments to
`f` using the vector registers.

The new behaviour matches the behaviour of `armclang`, and also matches
the GCC behaviour when run with `-std=gnu++14`.

> gcc -std=gnu++17 -march=armv8-a+simd -mfloat-abi=hard test.cpp

``` test.cpp
struct base {};

struct pair : base
{
  float first;
  float second;
  pair (float f, float s) : first(f), second(s) {}
};

void f (pair);
int main()
{
  f({3.14, 666});
  return 1;
}
```

We add a `-Wpsabi` warning to catch cases where this fix has changed the ABI for
some functions.  Unfortunately this warning is not emitted twice for multiple
calls to the same function, but I feel this is not much of a problem and can be
fixed later if needs be.

(i.e. if `main` called `f` twice in a row we only emit a diagnostic for the
first).

Testing:
Bootstrapped and regression tested on arm-linux.
This change fixes the struct-layout-1 tests Jakub added
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544204.html
Regression tested on arm-none-eabi.

gcc/ChangeLog:

2020-04-27  Matthew Malcomson  
Jakub Jelinek  

PR target/94383
* config/arm/arm.c (aapcs_vfp_sub_candidate): Account for C++17 empty
base class artificial fields.
(aapcs_vfp_is_call_or_return_candidate): Warn when PCS ABI
decision is different after this fix.



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


diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
0151bda90d961ae1a001c61cd5e94d6ec67e3aea..0db444c3fdb2ba6fb7ebad410310fb5b1bc0e304
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -6139,9 +6139,19 @@ aapcs_vfp_cum_init (CUMULATIVE_ARGS *pcum  
ATTRIBUTE_UNUSED,
If *MODEP is VOIDmode, then set it to the first valid floating point
type.  If a non-floating point type is found, or if a floating point
type that doesn't match a non-VOIDmode *MODEP is found, then return -1,
-   otherwise return the count in the sub-tree.  */
+   otherwise return the count in the sub-tree.
+
+   The AVOID_CXX17_EMPTY_BASE argument is to allow the caller to check whether
+   this function has changed its behavior after the fix for PR94384 -- this fix
+   is to avoid artificial fields in empty base classes.
+   When called with this argument as a NULL pointer this function does not
+   avoid the artificial fields -- this is useful to check whether the function
+   returns something different after the fix.
+   When called pointing at a value, this function avoids such artificial fields
+   and sets the value to TRUE when one of these fields has been set.  */
 static int
-aapcs_vfp_sub_candidate (const_tree type, machine_mode *modep)
+aapcs_vfp_sub_candidate (const_tree type, machine_mode *modep,
+bool *avoid_cxx17_empty_base)
 {
   machine_mode mode;
   HOST_WIDE_INT size;
@@ -6213,7 +6223,8 @@ aapcs_vfp_sub_candidate (const_tree type, machine_mode 
*modep)
|| TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST)
  return -1;
 
-   count = aapcs_vfp_sub_candidate (TREE_TYPE (type), modep);
+   count = aapcs_vfp_sub_candidate (TREE_TYPE (type), modep,
+avoid_cxx17_empty_base);
if (count == -1
|| !index
|| !TYPE_MAX_VALUE (index)
@@ -6251,7 +6262,18 @@ aapcs_vfp_sub_candidate (const_tree type, machine_mode 
*modep)
if (TREE_CODE (field) != FIELD_DECL)
  continue;
 
-   sub_count = aapcs_vfp_sub_candidate (TREE_TYPE (field), modep);
+   /* Ignore C++17 empty base fields, while their type indicates
+  they do contain padding, they have zero size and thus don't
+  contain any padding.  */
+   if (cxx17_empty_base_field_p (field)
+   && avoid_cxx17_empty_base)
+ {
+   

Re: [PATCH v2] wwdocs: Update coroutines status.

[Nathan Sidwell]

On 4/27/20 11:04 AM, Iain Sandoe wrote:

Nathan Sidwell  wrote:


On 4/27/20 3:56 AM, Iain Sandoe wrote:

hi,
This makes minor adjustments  to the coroutines status reflecting the changes in
n4861, the C++20 standard DIS.
OK to apply?
thanks
Iain
—
  htdocs/gcc-10/changes.html  | 1 +
  htdocs/projects/cxx-status.html | 9 +
  2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 3c1046bf..593bcfc7 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -318,6 +318,7 @@ a work-in-progress.
  P0960R3, Parenthesized initialization of aggregates
  P1331R2, Allow trivial default initialization in constexpr 
contexts
  P1327R1, Allowing dynamic_cast and polymorphic typeid in constexpr 
contexts
+Coroutines, P0912R5 as applied to n4861 (requires 
-fcoroutines)


I think the same form as the other bullets?
   P09125r5, Coroutines, (requires ...)

I think the 'as applied to n$currentdraft' is implicit? Especially as you make 
it explicit below.


Like so?


LGTM, is that sufficient?


thanks
Iain

This makes minor adjustments to the coroutines status  reflecting the changes in
n4861, the C++20 standard DIS.
---
  htdocs/gcc-10/changes.html  | 1 +
  htdocs/projects/cxx-status.html | 9 +
  2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 3c1046bf..41c2dc0d 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -318,6 +318,7 @@ a work-in-progress.
  P0960R3, Parenthesized initialization of aggregates
  P1331R2, Allow trivial default initialization in constexpr 
contexts
  P1327R1, Allowing dynamic_cast and polymorphic typeid in constexpr 
contexts
+P0912R5, Coroutines (requires -fcoroutines)


Several C++ Defect Reports have been resolved, e.g.:
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index dd2683dc..6a715058 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -444,10 +444,11 @@
  
  
 Coroutines 
-  https://wg21.link/p0912r5;>P0912R5
-   10
-   (Coroutines Wiki) 
-   
+  https://wg21.link/p0912r5;>P0912R5
+  as applied to http://wg21.link/n4861;>n4861
+   10 
+   (requires -fcoroutines)
+   __cpp_impl_coroutine = 201902
  
  
 Parenthesized initialization of aggregates 




--
Nathan Sidwell

[PATCH] Let numeric_limits::is_iec559 reflect -ffast-math

[Matthias Kretz]

From: Matthias Kretz 

PR libstdc++/84949
* include/std/limits: Let is_iec559 reflect whether
__GCC_IEC_559 says float and double support IEEE 754-2008.
* testsuite/18_support/numeric_limits/is_iec559.cc: Test IEC559
mandated behavior if is_iec559 is true.
* testsuite/18_support/numeric_limits/infinity.cc: Only test inf
behavior if is_iec559 is true, otherwise there is no guarantee
how arithmetic on inf behaves.
* testsuite/18_support/numeric_limits/quiet_NaN.cc: ditto for
NaN.
* testsuite/18_support/numeric_limits/denorm_min-1.cc: Compile
with -ffast-math.
* testsuite/18_support/numeric_limits/epsilon-1.cc: ditto.
* testsuite/18_support/numeric_limits/infinity-1.cc: ditto.
* testsuite/18_support/numeric_limits/is_iec559-1.cc: ditto.
* testsuite/18_support/numeric_limits/quiet_NaN-1.cc: ditto.
---
 libstdc++-v3/include/std/limits   |  9 ++--
 .../18_support/numeric_limits/denorm_min-1.cc |  2 +
 .../18_support/numeric_limits/epsilon-1.cc|  2 +
 .../18_support/numeric_limits/infinity-1.cc   |  2 +
 .../18_support/numeric_limits/infinity.cc |  4 +-
 .../18_support/numeric_limits/is_iec559-1.cc  |  2 +
 .../18_support/numeric_limits/is_iec559.cc| 44 ++-
 .../18_support/numeric_limits/quiet_NaN-1.cc  |  2 +
 .../18_support/numeric_limits/quiet_NaN.cc|  5 ++-
 9 files changed, 51 insertions(+), 21 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/18_support/numeric_limits/
denorm_min-1.cc
 create mode 100644 libstdc++-v3/testsuite/18_support/numeric_limits/
epsilon-1.cc
 create mode 100644 libstdc++-v3/testsuite/18_support/numeric_limits/
infinity-1.cc
 create mode 100644 libstdc++-v3/testsuite/18_support/numeric_limits/
is_iec559-1.cc
 create mode 100644 libstdc++-v3/testsuite/18_support/numeric_limits/
quiet_NaN-1.cc

diff --git a/libstdc++-v3/include/std/limits b/libstdc++-v3/include/std/limits
index 898406f91ee..c27350c9ec4 100644
--- a/libstdc++-v3/include/std/limits
+++ b/libstdc++-v3/include/std/limits
@@ -1714,8 +1714,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static _GLIBCXX_CONSTEXPR float
   denorm_min() _GLIBCXX_USE_NOEXCEPT { return __FLT_DENORM_MIN__; }
 
-  static _GLIBCXX_USE_CONSTEXPR bool is_iec559
-	= has_infinity && has_quiet_NaN && has_denorm == denorm_present;
+  static _GLIBCXX_USE_CONSTEXPR bool is_iec559 = __GCC_IEC_559 >= 2;
   static _GLIBCXX_USE_CONSTEXPR bool is_bounded = true;
   static _GLIBCXX_USE_CONSTEXPR bool is_modulo = false;
 
@@ -1789,8 +1788,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static _GLIBCXX_CONSTEXPR double
   denorm_min() _GLIBCXX_USE_NOEXCEPT { return __DBL_DENORM_MIN__; }
 
-  static _GLIBCXX_USE_CONSTEXPR bool is_iec559
-	= has_infinity && has_quiet_NaN && has_denorm == denorm_present;
+  static _GLIBCXX_USE_CONSTEXPR bool is_iec559 = __GCC_IEC_559 >= 2;
   static _GLIBCXX_USE_CONSTEXPR bool is_bounded = true;
   static _GLIBCXX_USE_CONSTEXPR bool is_modulo = false;
 
@@ -1864,8 +1862,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   static _GLIBCXX_CONSTEXPR long double
   denorm_min() _GLIBCXX_USE_NOEXCEPT { return __LDBL_DENORM_MIN__; }
 
-  static _GLIBCXX_USE_CONSTEXPR bool is_iec559
-	= has_infinity && has_quiet_NaN && has_denorm == denorm_present;
+  static _GLIBCXX_USE_CONSTEXPR bool is_iec559 = __GCC_IEC_559 >= 2;
   static _GLIBCXX_USE_CONSTEXPR bool is_bounded = true;
   static _GLIBCXX_USE_CONSTEXPR bool is_modulo = false;
 
diff --git a/libstdc++-v3/testsuite/18_support/numeric_limits/denorm_min-1.cc b/libstdc++-v3/testsuite/18_support/numeric_limits/denorm_min-1.cc
new file mode 100644
index 000..8ff2950d77e
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/numeric_limits/denorm_min-1.cc
@@ -0,0 +1,2 @@
+// { dg-options "-ffast-math" }
+#include "denorm_min.cc"
diff --git a/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon-1.cc b/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon-1.cc
new file mode 100644
index 000..34548976bea
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon-1.cc
@@ -0,0 +1,2 @@
+// { dg-options "-ffast-math" }
+#include "epsilon.cc"
diff --git a/libstdc++-v3/testsuite/18_support/numeric_limits/infinity-1.cc b/libstdc++-v3/testsuite/18_support/numeric_limits/infinity-1.cc
new file mode 100644
index 000..7ff8ea81242
--- /dev/null
+++ b/libstdc++-v3/testsuite/18_support/numeric_limits/infinity-1.cc
@@ -0,0 +1,2 @@
+// { dg-options "-ffast-math" }
+#include "infinity.cc"
diff --git a/libstdc++-v3/testsuite/18_support/numeric_limits/infinity.cc b/libstdc++-v3/testsuite/18_support/numeric_limits/infinity.cc
index 3a5bce57c35..9585ab38216 100644
--- a/libstdc++-v3/testsuite/18_support/numeric_limits/infinity.cc
+++ b/libstdc++-v3/testsuite/18_support/numeric_limits/infinity.cc
@@ -33,10 +33,10 @@ test_infinity()
 {
   bool test;
 

[RFC] Clarify -ffinite-math-only documentation

[Matthias Kretz]

Hi,

This documentation change clarifies the effect of -ffinite-math-only. With the 
current documentation, it is unclear what the presence of NaN and Inf 
representations means if (arithmetic) operations on such values are 
unspecified and even classification functions like isnan are unreliable. If 
the hardware thinks a certain bit pattern is a NaN, but the software assumes a 
NaN value cannot ever exist, it is questionable whether, from a language 
viewpoint, a representation for NaNs really exists. Because, a NaN is defined 
by its behavior. This change also clarifies that isnan(nan) returning false is 
fine.

This relates to PR84949.

* doc/invoke.texi: Clarify the effects of -ffinite-math-only.
---
 gcc/doc/invoke.texi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index a37a2ee9c19..9e76ab057a9 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -11619,8 +11619,10 @@ The default is @option{-fno-reciprocal-math}.
 
 @item -ffinite-math-only
 @opindex ffinite-math-only
-Allow optimizations for floating-point arithmetic that assume
-that arguments and results are not NaNs or +-Infs.
+Assume that floating-point types in the language do not have representations 
for
+NaNs and +-Inf. Whether floating-point hardware supports and acts on NaNs and
++-Inf is not affected. The behavior of a program that uses a NaN or +-Inf 
value
+as function argument, macro argument, or operand is undefined.
 
 This option is not turned on by any @option{-O} option since
 it can result in incorrect output for programs that depend on
-- 
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 std::experimental::simd  https://github.com/VcDevel/std-simd
──

[PATCH v2] wwdocs: Update coroutines status.

[Iain Sandoe]

Nathan Sidwell  wrote:

> On 4/27/20 3:56 AM, Iain Sandoe wrote:
>> hi,
>> This makes minor adjustments  to the coroutines status reflecting the 
>> changes in
>> n4861, the C++20 standard DIS.
>> OK to apply?
>> thanks
>> Iain
>> —
>>  htdocs/gcc-10/changes.html  | 1 +
>>  htdocs/projects/cxx-status.html | 9 +
>>  2 files changed, 6 insertions(+), 4 deletions(-)
>> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
>> index 3c1046bf..593bcfc7 100644
>> --- a/htdocs/gcc-10/changes.html
>> +++ b/htdocs/gcc-10/changes.html
>> @@ -318,6 +318,7 @@ a work-in-progress.
>>  P0960R3, Parenthesized initialization of aggregates
>>  P1331R2, Allow trivial default initialization in constexpr 
>> contexts
>>  P1327R1, Allowing dynamic_cast and polymorphic typeid in constexpr 
>> contexts
>> +Coroutines, P0912R5 as applied to n4861 (requires 
>> -fcoroutines)
> 
> I think the same form as the other bullets?
>   P09125r5, Coroutines, (requires ...)
> 
> I think the 'as applied to n$currentdraft' is implicit? Especially as you 
> make it explicit below.

Like so?
thanks
Iain

This makes minor adjustments to the coroutines status  reflecting the changes in
n4861, the C++20 standard DIS.
---
 htdocs/gcc-10/changes.html  | 1 +
 htdocs/projects/cxx-status.html | 9 +
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 3c1046bf..41c2dc0d 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -318,6 +318,7 @@ a work-in-progress.
 P0960R3, Parenthesized initialization of aggregates
 P1331R2, Allow trivial default initialization in constexpr 
contexts
 P1327R1, Allowing dynamic_cast and polymorphic typeid in constexpr 
contexts
+P0912R5, Coroutines (requires -fcoroutines)
 
   
   Several C++ Defect Reports have been resolved, e.g.:
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index dd2683dc..6a715058 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -444,10 +444,11 @@
 
 
Coroutines 
-  https://wg21.link/p0912r5;>P0912R5
-   10
-   (Coroutines Wiki) 
-   
+  https://wg21.link/p0912r5;>P0912R5
+  as applied to http://wg21.link/n4861;>n4861
+   10 
+   (requires -fcoroutines)
+   __cpp_impl_coroutine = 201902
 
 
Parenthesized initialization of aggregates 
-- 
2.14.3

Re: [PATCH] c++: Delegating constructor in constexpr init [PR94772]

[Patrick Palka via Gcc-patches]

On Mon, 27 Apr 2020, Patrick Palka wrote:

> On Mon, 27 Apr 2020, Jason Merrill wrote:
> 
> > On 4/26/20 6:48 PM, Patrick Palka wrote:
> > > In the testcase below, the call to the target constructor foo{} from foo's
> > > delegating constructor is encoded as the INIT_EXPR
> > > 
> > >*(struct foo *) this = AGGR_INIT_EXPR <4, __ct_comp, D.2140, ...>;
> > > 
> > > During initialization of the variable 'bar', we prematurely set
> > > TREE_READONLY on
> > > bar's CONSTRUCTOR in two places before the outer delegating constructor 
> > > has
> > > returned: first, at the end of cxx_eval_call_expression after evaluating 
> > > the
> > > RHS
> > > of the above INIT_EXPR, and second, at the end of 
> > > cxx_eval_store_expression
> > > after having finished evaluating the above INIT_EXPR.  This then prevents
> > > the
> > > rest of the outer delegating constructor from mutating 'bar'.
> > > 
> > > This (hopefully minimally risky) patch makes cxx_eval_call_expression
> > > refrain
> > > from setting TREE_READONLY when evaluating the target constructor of a
> > > delegating constructor.  It also makes cxx_eval_store_expression refrain
> > > from
> > > setting TREE_READONLY when the object being initialized is "*this', on the
> > > basis
> > > that it should be the responsibility of the routine that set 'this' in the
> > > first
> > > place to set the object's TREE_READONLY appropriately.
> > > 
> > > Passes 'make check-c++', does this look OK to commit after full
> > > bootstrap/regtest?
> > > 
> > > gcc/cp/ChangeLog:
> > > 
> > >   PR c++/94772
> > >   * constexpr.c (cxx_eval_call_expression): Don't set new_obj if we're
> > >   evaluating the target constructor of a delegating constructor.
> > >   (cxx_eval_store_expression): Don't set TREE_READONLY if the LHS of the
> > >   INIT_EXPR is '*this'.
> > > 
> > > gcc/testsuite/ChangeLog:
> > > 
> > >   PR c++/94772
> > >   * g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
> > > ---
> > >   gcc/cp/constexpr.c| 29 +++
> > >   .../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 ++
> > >   2 files changed, 45 insertions(+), 5 deletions(-)
> > >   create mode 100644 
> > > gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C
> > > 
> > > diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> > > index 6b3e514398b..a9ddd861195 100644
> > > --- a/gcc/cp/constexpr.c
> > > +++ b/gcc/cp/constexpr.c
> > > @@ -2367,10 +2367,20 @@ cxx_eval_call_expression (const constexpr_ctx 
> > > *ctx,
> > > tree t,
> > > /* In a constructor, it should be the first `this' argument.
> > >At this point it has already been evaluated in the call
> > >to cxx_bind_parameters_in_call.  */
> > > -  new_obj = TREE_VEC_ELT (new_call.bindings, 0);
> > > -  STRIP_NOPS (new_obj);
> > > -  if (TREE_CODE (new_obj) == ADDR_EXPR)
> > > - new_obj = TREE_OPERAND (new_obj, 0);
> > > +
> > > +  if (ctx->call && ctx->call->fundef
> > > +   && DECL_CONSTRUCTOR_P (ctx->call->fundef->decl)
> > > +   && (TREE_VEC_ELT (ctx->call->bindings, 0)
> > > +   == TREE_VEC_ELT (new_call.bindings, 0)))
> > > + /* We're calling the target constructor of a delegating constructor,
> > > so
> > > +there is no new object.  */;
> > > +  else
> > > + {
> > > +   new_obj = TREE_VEC_ELT (new_call.bindings, 0);
> > > +   STRIP_NOPS (new_obj);
> > > +   if (TREE_CODE (new_obj) == ADDR_EXPR)
> > > + new_obj = TREE_OPERAND (new_obj, 0);
> > > + }
> > >   }
> > >   tree result = NULL_TREE;
> > > @@ -4950,7 +4960,16 @@ cxx_eval_store_expression (const constexpr_ctx 
> > > *ctx,
> > > tree t,
> > > if (TREE_CODE (t) == INIT_EXPR
> > > && TREE_CODE (*valp) == CONSTRUCTOR
> > > && TYPE_READONLY (type))
> > > -TREE_READONLY (*valp) = true;
> > > +{
> > > +  if (INDIRECT_REF_P (target)
> > > +   && (is_this_parameter
> > > +   (tree_strip_nop_conversions (TREE_OPERAND (target, 0)
> > > + /* We've just initialized '*this' (perhaps via the target constructor
> > > of
> > > +a delegating constructor).  Leave it up to the caller that set
> > > 'this'
> > > +to set TREE_READONLY appropriately.  */;
> > 
> > Let's checking_assert that target and *this are
> > same_type_ignoring_top_level_qualifiers_p.
> 
> Like this?  Bootstrap and regtest in progress.
> 
> -- >8 --
> 
> gcc/cp/ChangeLog:
> 
>   PR c++/94772
>   * constexpr.c (cxx_eval_call_expression): Don't set new_obj if we're
>   evaluating the target constructor of a delegating constructor.
>   (cxx_eval_store_expression): Don't set TREE_READONLY if the LHS of the
>   INIT_EXPR is '*this'.
> 
> gcc/testsuite/ChangeLog:
> 
>   PR c++/94772
>   * g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
> ---
>  gcc/cp/constexpr.c| 31 ---
>  .../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 +
>  2 files changed, 47 insertions(+), 5 

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

[Qing Zhao via Gcc-patches]

Hi, David,

> On Apr 24, 2020, at 5:36 PM, David Malcolm  wrote:
> 
> On Fri, 2020-04-24 at 17:22 -0500, Qing Zhao wrote:
>> Hi, Dave,
>> 
>> Thanks a lot for the review and comments.
>> I just updated the patch with all your suggestions, bootstrapped it
>> and run regression test, no any issue.
>> 
>> The newest patch is attached with this email.
>> 
>> Richard/Jakub, please advise on whether I can commit this patch to
>> Gcc10?
>> 
>> Thanks a lot.
>> 
>> Qing
>> 
> 
> Thanks Qing.  One more wording nit (sorry!)
> 
>> +  if (!flag_large_source_files)
>> +inform (loc,
>> +"adding %<-flarge-source-files%> will allow for more" 
>> +" column-tracking support, at the expense of compilation"
>> +" and memory");
>^
> Please add "time" here i.e.
>" time and memory”);

Added it in my local directory. (And attached).

Thanks.

Qing


PR94230.patch
Description: Binary data



> 
> 
> Dave
> 

Re: [PATCH] coroutines: Fix for uses of structured binding [PR94701]

[Nathan Sidwell]

On 4/21/20 4:33 PM, Iain Sandoe wrote:

Hi,

As reported by Michał Dominiak, we are generating incorrect code
for structured binding of local vars.  Somewhere in the machinations
associated with lambda captures, I messed up the code handling
DECL_VALUE_EXPRs.

tested so far on x86_64-darwin16,
OK for master if it passes regstrap on x86-64-Linux?
thanks
Iain



Structured binding makes use of the DECL_VALUE_EXPR fields
in local variables.  We need to recognise these and only amend
the expression values, retaining the 'alias' value intact.

gcc/cp/ChangeLog:

2020-04-21  Iain Sandoe  

PR c++/94701
* coroutines.cc (struct local_var_info): Add fields for static
variables and those with DECL_VALUE_EXPR redirection.
(transform_local_var_uses):  Skip past typedefs and static vars
and then account for redirected variables.
(register_local_var_uses): Likewise.



ok





--
Nathan Sidwell

Re: [PATCH] wwdocs: Update coroutines status.

[Nathan Sidwell]

On 4/27/20 3:56 AM, Iain Sandoe wrote:

hi,

This makes minor adjustments  to the coroutines status reflecting the changes in
n4861, the C++20 standard DIS.

OK to apply?
thanks
Iain

—

  htdocs/gcc-10/changes.html  | 1 +
  htdocs/projects/cxx-status.html | 9 +
  2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 3c1046bf..593bcfc7 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -318,6 +318,7 @@ a work-in-progress.
  P0960R3, Parenthesized initialization of aggregates
  P1331R2, Allow trivial default initialization in constexpr 
contexts
  P1327R1, Allowing dynamic_cast and polymorphic typeid in constexpr 
contexts
+Coroutines, P0912R5 as applied to n4861 (requires 
-fcoroutines)


I think the same form as the other bullets?
   P09125r5, Coroutines, (requires ...)

I think the 'as applied to n$currentdraft' is implicit? Especially as 
you make it explicit below.



 Coroutines 
-  https://wg21.link/p0912r5;>P0912R5
-   10
-   (Coroutines Wiki) 
-   
+  https://wg21.link/p0912r5;>P0912R5
+  as applied to http://wg21.link/n4861;>n4861
+   10 
+   (requires -fcoroutines)
+   __cpp_impl_coroutine = 201902
  
  
 Parenthesized initialization of aggregates 




--
Nathan Sidwell

Re: [PATCH] coroutines: Pass class ref to traits lookup and promise allocator [PR94760]

[Nathan Sidwell]

On 4/25/20 11:08 AM, Iain Sandoe wrote:

(WAS  [PATCH] coroutines: Handle lambda capture objects in the way as clang.)

I am sorry to mess you around on this.


It wasn't you who wasn't focussing :)


We changed the argument passed to the promise parameter preview
to match a reference to *this.  However to be consistent with the
other ports, we do need to match the reference transformation in
the traits lookup and the promise allocator lookup.


A few comments ...



gcc/cp/ChangeLog:

2020-04-25  Iain Sandoe  

PR c++/94760
* coroutines.cc (instantiate_coro_traits): Pass a reference to
object type rather than a pointer type for 'this', for method
coroutines.
(struct param_info): Add a field to hold that the parm is a lambda
closure pointer.
(morph_fn_to_coro): Check for lambda closure pointers in the
args.  Use a reference to *this when building the args list for the
promise allocator lookup.

gcc/testsuite/ChangeLog:

2020-04-25  Iain Sandoe  

PR c++/94760
* g++.dg/coroutines/pr94760-mismatched-traits-and-promise-prev.C: New 
test.
---
  gcc/cp/coroutines.cc  | 52 +--
  ...9-mismatched-traits-and-promise-prev.C | 29 +++
  2 files changed, 77 insertions(+), 4 deletions(-)
  create mode 100644 
gcc/testsuite/g++.dg/coroutines/pr9-mismatched-traits-and-promise-prev.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 4f254b7fd10..c80a3b716b2 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -296,14 +296,25 @@ instantiate_coro_traits (tree fndecl, location_t kw)
   type.  */
  
tree functyp = TREE_TYPE (fndecl);

+  tree arg = DECL_ARGUMENTS (fndecl);
+  bool lambda_p = LAMBDA_TYPE_P (DECL_CONTEXT (fndecl));


I think LAMBDA_FUNCTION_P (fndecl) expresses intent better.


@@ -3652,6 +3664,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
  The second two entries start out empty - and only get populated
  when we see uses.  */
param_uses = new hash_map;
+  bool lambda_p = LAMBDA_TYPE_P (DECL_CONTEXT (orig));


Likewise.

  
for (tree arg = DECL_ARGUMENTS (orig); arg != NULL;

   arg = DECL_CHAIN (arg))
@@ -3691,7 +3704,17 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
}
  else
parm.frame_type = actual_type;
+
  parm.this_ptr = is_this_parameter (arg);
+ if (lambda_p)
+   {
+ parm.lambda_cobj = parm.this_ptr
+|| (DECL_NAME (arg) == closure_identifier);


i'm confused by the need for || here.  Why isn't just the DECL_NAME test 
needed?  The parser appears to give the object parameter that name.  (If 
you do need the parm.this_ptr piece, it suggests somewhere else outside 
of coro is not being consistent, but ICBW.)



@@ -3831,9 +3854,28 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
those of the original function.  */
vec *args = make_tree_vector ();
vec_safe_push (args, resizeable); /* Space needed.  */
+
for (tree arg = DECL_ARGUMENTS (orig); arg != NULL;
   arg = DECL_CHAIN (arg))
-   vec_safe_push (args, arg);
+   {
+ param_info *parm_i = param_uses->get (arg);
+ gcc_checking_assert (parm_i);
+ if (parm_i->lambda_cobj)
+   vec_safe_push (args, arg);
+ else if (0 && parm_i->this_ptr)


^^ looks like now-disabled experimental code?


--
Nathan Sidwell

Re: [PATCH] coroutines: Fix handling of non-class coroutine returns [PR94759]

[Nathan Sidwell]

On 4/25/20 9:49 AM, Iain Sandoe wrote:

Hi




tested on x86_64-darwin,
OK for master if the testing passes regstrap on x86-64-linux?
thanks
Iain

gcc/cp/ChangeLog:

2020-04-23  Iain Sandoe  

PR c++/94759
* coroutines.cc (coro_promise_type_found_p): Do not
exclude non-classes here (this needs to be handled in the
coroutine header).
(morph_fn_to_coro):  Allow for the case where the coroutine
returns void.


Ok, A nit ..


@@ -4197,16 +4183,24 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
/* The ramp is done, we just need the return value.  */
if (!same_type_p (TREE_TYPE (get_ro), fn_return_type))
  {
-  /* construct the return value with a single GRO param.  */



r = build_cplus_new (fn_return_type, r, tf_warning_or_error);
  }
-  else
+  else if (!gro_is_void_p)
  r = rvalue (gro); /* The GRO is the return value.  */
+  else r = NULL_TREE;


^^ missing line break

I see Jonathan approved the library bit, with a nit too.

nathan

--
Nathan Sidwell

Re: [PATCH] c-family: Fix ICE on __builtin_speculation_safe_value () [PR94755]

[Nathan Sidwell]

On 4/26/20 10:59 AM, Jakub Jelinek wrote:

On Sun, Apr 26, 2020 at 09:58:16AM -0400, Nathan Sidwell wrote:



first_param = (*params)[0];
-   if (fncode == BUILT_IN_NONE
-   || !speculation_safe_value_resolve_params (loc, function, params))
+   if (!speculation_safe_value_resolve_params (loc, function, params))
  return error_mark_node;


first_param isn't used in that conditional, can't you just move its
assinment afterwards?


I think I can't, because speculation_safe_value_resolve_params
can modify the (*params)[0] and if there wasn't a reason to remember
(*params)[0] before the call, why would the patch author add first_param
var at all when it could just use (*params)[0]; it does use (*params)[1]...
So my assumption is that where first_param is used, the code wants the
value before promotions/conversions.


Makes sense, lgtm,

nathan


--
Nathan Sidwell

libgomp: Allow overriding via 'GOMP_OFFLOAD_PLUGINS' the configured set of libgomp plugins

[Thomas Schwinge]

Hi!

Is the attached patch for "libgomp: Allow overriding via
'GOMP_OFFLOAD_PLUGINS' the configured set of libgomp plugins" OK for
master and release branches?  If approving this patch, please respond
with "Reviewed-by: NAME " so that your effort will be recorded in
the commit log, see .


Grüße
 Thomas


-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter
>From 13f04e776c803766140b0b657dad15029e2b65be Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 27 Apr 2020 14:01:50 +0200
Subject: [PATCH] libgomp: Allow overriding via 'GOMP_OFFLOAD_PLUGINS' the
 configured set of libgomp plugins

This can be useful for testing the same libgomp build on several machines, with
different offload capabilities/configurations.

This is subject to change, and thus intentionally not documented.

	libgomp/
	* target.c [PLUGIN_SUPPORT] (gomp_target_init): Allow overriding
	via 'GOMP_OFFLOAD_PLUGINS' the configured set of libgomp plugins.
---
 libgomp/target.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libgomp/target.c b/libgomp/target.c
index 36425477dcb..d1de7fab87c 100644
--- a/libgomp/target.c
+++ b/libgomp/target.c
@@ -25,6 +25,7 @@
 
 /* This file contains the support of offloading.  */
 
+#define _GNU_SOURCE
 #include "libgomp.h"
 #include "oacc-plugin.h"
 #include "oacc-int.h"
@@ -42,6 +43,7 @@
 #ifdef PLUGIN_SUPPORT
 #include 
 #include "plugin-suffix.h"
+#include "secure_getenv.h"
 #endif
 
 #define FIELD_TGT_EMPTY (~(size_t) 0)
@@ -3163,7 +3165,10 @@ gomp_target_init (void)
   num_devices = 0;
   devices = NULL;
 
-  cur = OFFLOAD_PLUGINS;
+  /* This is subject to change, and thus intentionally not documented.  */
+  cur = secure_getenv ("GOMP_OFFLOAD_PLUGINS");
+  if (!cur)
+cur = OFFLOAD_PLUGINS;
   if (*cur)
 do
   {
-- 
2.17.1

RE: [GCC][PATCH][ARM]: Change arm constraint name from "e" to "Te".

[Kyrylo Tkachov]

> -Original Message-
> From: Srinath Parvathaneni 
> Sent: 24 April 2020 15:25
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov 
> Subject: [GCC][PATCH][ARM]: Change arm constraint name from "e" to "Te".
> 
> Hello,
> 
> This patches changes the constraint "e" to "Te".
> 
> Regression tested on arm-none-eabi and found no regressions.
> 
> Ok for trunk?

Ok.
Thanks,
Kyrill

> 
> Thanks,
> Srinath.
> 
> gcc/ChangeLog:
> 
> 2020-04-24  Srinath Parvathaneni  
> 
>   * config/arm/constraints.md (e): Remove constraint.
>   (Te): Define constraint.
>   * config/arm/mve.md (vaddvq_): Modify constraint in
>   operand 0 from "e" to "Te".
>   (vaddvaq_): Likewise.
>   (vaddvq_p_): Likewise.
>   (vmladavq_): Likewise.
>   (vmladavxq_s): Likewise.
>   (vmlsdavq_s): Likewise.
>   (vmlsdavxq_s): Likewise.
>   (vaddvaq_p_): Likewise.
>   (vmladavaq_): Likewise.
>   (vmladavq_p_): Likewise.
>   (vmladavxq_p_s): Likewise.
>   (vmlsdavq_p_s): Likewise.
>   (vmlsdavxq_p_s): Likewise.
>   (vmlsdavaxq_s): Likewise.
>   (vmlsdavaq_s): Likewise.
>   (vmladavaxq_s): Likewise.
>   (vmladavaq_p_): Likewise.
>   (vmladavaxq_p_s): Likewise.
>   (vmlsdavaq_p_s): Likewise.
>   (vmlsdavaxq_p_s): Likewise.
> 
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/config/arm/constraints.md b/gcc/config/arm/constraints.md
> index
> 41a85e2713b59f75f0b191b6be03a7ac8f6e321e..fed6c7c84032dd8aba45142b
> 59b980b4a6240d6d 100644
> --- a/gcc/config/arm/constraints.md
> +++ b/gcc/config/arm/constraints.md
> @@ -32,7 +32,7 @@
> 
>  ;; The following multi-letter normal constraints have been used:
>  ;; in ARM/Thumb-2 state: Da, Db, Dc, Dd, Dn, DN, Dm, Dl, DL, Do, Dv, Dy, Di,
> -;;Dt, Dp, Dz, Tu
> +;;Dt, Dp, Dz, Tu, Te
>  ;; in Thumb-1 state: Pa, Pb, Pc, Pd, Pe
>  ;; in Thumb-2 state: Ha, Pj, PJ, Ps, Pt, Pu, Pv, Pw, Px, Py, Pz, Rd, Rf, Rb, 
> Ra,
>  ;;Rg, Ri
> @@ -50,8 +50,8 @@
>  (define_register_constraint "Uf" "TARGET_HAVE_MVE ? VFPCC_REG :
> NO_REGS"
>"MVE FPCCR register")
> 
> -(define_register_constraint "e" "TARGET_HAVE_MVE ? EVEN_REG :
> NO_REGS"
> -  "MVE EVEN registers @code{r0}, @code{r2}, @code{r4}, @code{r6},
> @code{r8},
> +(define_register_constraint "Te" "TARGET_HAVE_MVE ? EVEN_REG :
> NO_REGS"
> +  "EVEN core registers @code{r0}, @code{r2}, @code{r4}, @code{r6},
> @code{r8},
> @code{r10}, @code{r12}, @code{r14}")
> 
>  (define_constraint "Rd"
> diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
> index
> 9cb18ef50e8320b2d7160346361343c4ab1685b9..f43dabbfd4f15b602f0627a9
> b0ea423064501e51 100644
> --- a/gcc/config/arm/mve.md
> +++ b/gcc/config/arm/mve.md
> @@ -1102,7 +1102,7 @@
>  ;;
>  (define_insn "mve_vaddvq_"
>[
> -   (set (match_operand:SI 0 "s_register_operand" "=e")
> +   (set (match_operand:SI 0 "s_register_operand" "=Te")
>   (unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")]
>VADDVQ))
>]
> @@ -1477,7 +1477,7 @@
>  ;;
>  (define_insn "mve_vaddvaq_"
>[
> -   (set (match_operand:SI 0 "s_register_operand" "=e")
> +   (set (match_operand:SI 0 "s_register_operand" "=Te")
>   (unspec:SI [(match_operand:SI 1 "s_register_operand" "0")
>   (match_operand:MVE_2 2 "s_register_operand" "w")]
>VADDVAQ))
> @@ -1492,7 +1492,7 @@
>  ;;
>  (define_insn "mve_vaddvq_p_"
>[
> -   (set (match_operand:SI 0 "s_register_operand" "=e")
> +   (set (match_operand:SI 0 "s_register_operand" "=Te")
>   (unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
>   (match_operand:HI 2 "vpr_register_operand" "Up")]
>VADDVQ_P))
> @@ -2032,7 +2032,7 @@
>  ;;
>  (define_insn "mve_vmladavq_"
>[
> -   (set (match_operand:SI 0 "s_register_operand" "=e")
> +   (set (match_operand:SI 0 "s_register_operand" "=Te")
>   (unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
>   (match_operand:MVE_2 2 "s_register_operand" "w")]
>VMLADAVQ))
> @@ -2047,7 +2047,7 @@
>  ;;
>  (define_insn "mve_vmladavxq_s"
>[
> -   (set (match_operand:SI 0 "s_register_operand" "=e")
> +   (set (match_operand:SI 0 "s_register_operand" "=Te")
>   (unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
>   (match_operand:MVE_2 2 "s_register_operand" "w")]
>VMLADAVXQ_S))
> @@ -2062,7 +2062,7 @@
>  ;;
>  (define_insn "mve_vmlsdavq_s"
>[
> -   (set (match_operand:SI 0 "s_register_operand" "=e")
> +   (set (match_operand:SI 0 "s_register_operand" "=Te")
>   (unspec:SI [(match_operand:MVE_2 1 "s_register_operand" "w")
>   (match_operand:MVE_2 2 "s_register_operand" "w")]
>VMLSDAVQ_S))
> @@ -2077,7 +2077,7 @@
>  ;;
>  (define_insn "mve_vmlsdavxq_s"
>[
> -   (set (match_operand:SI 0 "s_register_operand" "=e")
> +   (set (match_operand:SI 0 "s_register_operand" 

RE: [PATCH][GCC][Arm]: Fix bootstrap failure with rtl-checking

[Kyrylo Tkachov]

> -Original Message-
> From: Andre Vieira (lists) 
> Sent: 27 April 2020 14:22
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov 
> Subject: [PATCH][GCC][Arm]: Fix bootstrap failure with rtl-checking
> 
> Hi,
> 
> The code change that caused this regression was not meant to affect neon
> code-gen, however I missed the REG fall through.  This patch makes sure
> we only get the left-hand of the PLUS if it is indeed a PLUS expr.
> 
> I suggest that in gcc-11 this code is cleaned up, as I do not think we
> even need the overlap checks, NEON only loads from or stores to FP
> registers and these can't be used in its addressing modes.
> 
> Bootstrapped arm-linux-gnueabihf with '--enable-checking=yes,rtl' for
> armv7-a and amrv8-a.
> 
> Is this OK for trunk?

Ok.
Thanks,
Kyrill

> 
> gcc/ChangeLog:
> 2020-04-27  Andre Vieira  
> 
>      * config/arm/arm.c (output_move_neon): Only get the first operand,
>      if addr is PLUS.

[PATCH][GCC][Arm]: Fix bootstrap failure with rtl-checking

[Andre Vieira (lists)]

Hi,

The code change that caused this regression was not meant to affect neon 
code-gen, however I missed the REG fall through.  This patch makes sure 
we only get the left-hand of the PLUS if it is indeed a PLUS expr.


I suggest that in gcc-11 this code is cleaned up, as I do not think we 
even need the overlap checks, NEON only loads from or stores to FP 
registers and these can't be used in its addressing modes.


Bootstrapped arm-linux-gnueabihf with '--enable-checking=yes,rtl' for 
armv7-a and amrv8-a.


Is this OK for trunk?

gcc/ChangeLog:
2020-04-27  Andre Vieira  

    * config/arm/arm.c (output_move_neon): Only get the first operand,
    if addr is PLUS.

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 
0151bda90d961ae1a001c61cd5e94d6ec67e3aea..74454dddbb948a5d37f502e8e2146a81cb83d58b
 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -20145,7 +20145,8 @@ output_move_neon (rtx *operands)
}
   /* Fall through.  */
 case PLUS:
-  addr = XEXP (addr, 0);
+  if (GET_CODE (addr) == PLUS)
+   addr = XEXP (addr, 0);
   /* Fall through.  */
 case LABEL_REF:
   {

Re: [PATCH] c++: Delegating constructor in constexpr init [PR94772]

[Patrick Palka via Gcc-patches]

On Mon, 27 Apr 2020, Jason Merrill wrote:

> On 4/26/20 6:48 PM, Patrick Palka wrote:
> > In the testcase below, the call to the target constructor foo{} from foo's
> > delegating constructor is encoded as the INIT_EXPR
> > 
> >*(struct foo *) this = AGGR_INIT_EXPR <4, __ct_comp, D.2140, ...>;
> > 
> > During initialization of the variable 'bar', we prematurely set
> > TREE_READONLY on
> > bar's CONSTRUCTOR in two places before the outer delegating constructor has
> > returned: first, at the end of cxx_eval_call_expression after evaluating the
> > RHS
> > of the above INIT_EXPR, and second, at the end of cxx_eval_store_expression
> > after having finished evaluating the above INIT_EXPR.  This then prevents
> > the
> > rest of the outer delegating constructor from mutating 'bar'.
> > 
> > This (hopefully minimally risky) patch makes cxx_eval_call_expression
> > refrain
> > from setting TREE_READONLY when evaluating the target constructor of a
> > delegating constructor.  It also makes cxx_eval_store_expression refrain
> > from
> > setting TREE_READONLY when the object being initialized is "*this', on the
> > basis
> > that it should be the responsibility of the routine that set 'this' in the
> > first
> > place to set the object's TREE_READONLY appropriately.
> > 
> > Passes 'make check-c++', does this look OK to commit after full
> > bootstrap/regtest?
> > 
> > gcc/cp/ChangeLog:
> > 
> > PR c++/94772
> > * constexpr.c (cxx_eval_call_expression): Don't set new_obj if we're
> > evaluating the target constructor of a delegating constructor.
> > (cxx_eval_store_expression): Don't set TREE_READONLY if the LHS of the
> > INIT_EXPR is '*this'.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > PR c++/94772
> > * g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
> > ---
> >   gcc/cp/constexpr.c| 29 +++
> >   .../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 ++
> >   2 files changed, 45 insertions(+), 5 deletions(-)
> >   create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C
> > 
> > diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> > index 6b3e514398b..a9ddd861195 100644
> > --- a/gcc/cp/constexpr.c
> > +++ b/gcc/cp/constexpr.c
> > @@ -2367,10 +2367,20 @@ cxx_eval_call_expression (const constexpr_ctx *ctx,
> > tree t,
> > /* In a constructor, it should be the first `this' argument.
> >  At this point it has already been evaluated in the call
> >  to cxx_bind_parameters_in_call.  */
> > -  new_obj = TREE_VEC_ELT (new_call.bindings, 0);
> > -  STRIP_NOPS (new_obj);
> > -  if (TREE_CODE (new_obj) == ADDR_EXPR)
> > -   new_obj = TREE_OPERAND (new_obj, 0);
> > +
> > +  if (ctx->call && ctx->call->fundef
> > + && DECL_CONSTRUCTOR_P (ctx->call->fundef->decl)
> > + && (TREE_VEC_ELT (ctx->call->bindings, 0)
> > + == TREE_VEC_ELT (new_call.bindings, 0)))
> > +   /* We're calling the target constructor of a delegating constructor,
> > so
> > +  there is no new object.  */;
> > +  else
> > +   {
> > + new_obj = TREE_VEC_ELT (new_call.bindings, 0);
> > + STRIP_NOPS (new_obj);
> > + if (TREE_CODE (new_obj) == ADDR_EXPR)
> > +   new_obj = TREE_OPERAND (new_obj, 0);
> > +   }
> >   }
> >   tree result = NULL_TREE;
> > @@ -4950,7 +4960,16 @@ cxx_eval_store_expression (const constexpr_ctx *ctx,
> > tree t,
> > if (TREE_CODE (t) == INIT_EXPR
> > && TREE_CODE (*valp) == CONSTRUCTOR
> > && TYPE_READONLY (type))
> > -TREE_READONLY (*valp) = true;
> > +{
> > +  if (INDIRECT_REF_P (target)
> > + && (is_this_parameter
> > + (tree_strip_nop_conversions (TREE_OPERAND (target, 0)
> > +   /* We've just initialized '*this' (perhaps via the target constructor
> > of
> > +  a delegating constructor).  Leave it up to the caller that set
> > 'this'
> > +  to set TREE_READONLY appropriately.  */;
> 
> Let's checking_assert that target and *this are
> same_type_ignoring_top_level_qualifiers_p.

Like this?  Bootstrap and regtest in progress.

-- >8 --

gcc/cp/ChangeLog:

PR c++/94772
* constexpr.c (cxx_eval_call_expression): Don't set new_obj if we're
evaluating the target constructor of a delegating constructor.
(cxx_eval_store_expression): Don't set TREE_READONLY if the LHS of the
INIT_EXPR is '*this'.

gcc/testsuite/ChangeLog:

PR c++/94772
* g++.dg/cpp1y/constexpr-tracking-const23.C: New test.
---
 gcc/cp/constexpr.c| 31 ---
 .../g++.dg/cpp1y/constexpr-tracking-const23.C | 21 +
 2 files changed, 47 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const23.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 6b3e514398b..c7923897e23 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2367,10 +2367,20 @@ cxx_eval_call_expression 

RE: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-ssa-forwprop.c:2482

[Yangfei (Felix)]

> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Monday, April 27, 2020 6:10 PM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-
> ssa-forwprop.c:2482
> 
> > Good suggestion.  Modified accordingly.
> >
> >> LGTM otherwise, and sorry for the breakage.
> >
> > Does the v2 patch look better?
> >
> > Manually run the following three tests with runtest:
> > gcc.target/aarch64/sve/acle/general/pr94683.c
> > gcc.target/aarch64/sve/acle/general/pr94700.c
> > gcc.dg/pr94784.c
> 
> Thanks, pushed to master after testing on aarch64-linux-gnu.

My local bootstrap and regression tests for the v2 patch have just finished.  
The results looks good too.  Thanks for the efforts : - )

Best regards,
Felix
 

[PATCH v5] aarch64: Add TX3 machine model

[Anton Youdkevitch]

Here is the patch introducing thunderx3t110 machine model
for the scheduler. A name for the new chip was added to the
list of the names to be recognized as a valid parameter for
mcpu and mtune flags. Added the TX3 tuning table and cost
model tables.

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

Lowering the chip capabilities to v8.3 to be on the safe side.

Bootstrapped on AArch64.

2020-04-27 Anton Youdkevitch 

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


---
 gcc/config/aarch64/aarch64-cores.def |   3 +
 gcc/config/aarch64/aarch64-cost-tables.h | 103 +++
 gcc/config/aarch64/aarch64-tune.md   |   2 +-
 gcc/config/aarch64/aarch64.c |  83 ++
 gcc/config/aarch64/aarch64.md|   1 +
 gcc/config/aarch64/thunderx3t110.md  | 686 +++
 gcc/doc/invoke.texi  |   2 +-
 7 files changed, 878 insertions(+), 2 deletions(-)
>From 0e6e706bb6a031f3a8180059349c7fe5ea769e30 Mon Sep 17 00:00:00 2001
From: Anton Youdkevitch 
Date: Mon, 23 Mar 2020 13:22:35 -0700
Subject: [PATCH] TX3 scheduling and tuning implementation

Added the scheduler descriptions for TX3. Also
added the tuning table and the cost tables for
TX3.

2020-04-27 Anton Youdkevitch 

* config/aarch64/aarch64-cores.def: Add the chip name.
* config/aarch64/aarch64-tune.md: Regenerated.
* config/aarch64/aarch64.c: Add tuning table for the chip.
* gcc/config/aarch64/aarch64-cost-tables.h: Add cost tables.
* config/aarch64/thunderx3t110.md: New file: add the new
machine model for the scheduler
* config/aarch64/aarch64.md: Include the new model.
* doc/invoke.texi: Add the new name to the list
---
 gcc/config/aarch64/aarch64-cores.def |   3 +
 gcc/config/aarch64/aarch64-cost-tables.h | 103 +
 gcc/config/aarch64/aarch64-tune.md   |   2 +-
 gcc/config/aarch64/aarch64.c |  83 
 gcc/config/aarch64/aarch64.md|   1 +
 gcc/config/aarch64/thunderx3t110.md  | 686 +++
 gcc/doc/invoke.texi  |   2 +-
 7 files changed, 878 insertions(+), 2 deletions(-)
 create mode 100644 gcc/config/aarch64/thunderx3t110.md

diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index ea9b98b..4d8605a 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -95,6 +95,9 @@ AARCH64_CORE("vulcan",  vulcan, thunderx2t99, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | AA
 /* Cavium ('C') cores. */
 AARCH64_CORE("thunderx2t99",  thunderx2t99,  thunderx2t99, 8_1A,  AARCH64_FL_FOR_ARCH8_1 | AARCH64_FL_CRYPTO, thunderx2t99, 0x43, 0x0af, -1)
 
+/* Marvell cores (TX3). */
+AARCH64_CORE("thunderx3t110",  thunderx3t110,  thunderx3t110, 8_3A,  AARCH64_FL_FOR_ARCH8_3 | AARCH64_FL_CRYPTO | AARCH64_FL_RCPC | AARCH64_FL_SM4 | AARCH64_FL_SHA3 | AARCH64_FL_F16FML | AARCH64_FL_RCPC8_4, thunderx3t110, 0x43, 0x0b8, 0x0a)
+
 /* ARMv8.2-A Architecture Processors.  */
 
 /* ARM ('A') cores. */
diff --git a/gcc/config/aarch64/aarch64-cost-tables.h b/gcc/config/aarch64/aarch64-cost-tables.h
index 65df55e..8a98bf4 100644
--- a/gcc/config/aarch64/aarch64-cost-tables.h
+++ b/gcc/config/aarch64/aarch64-cost-tables.h
@@ -334,6 +334,109 @@ const struct cpu_cost_table thunderx2t99_extra_costs =
   }
 };
 
+const struct cpu_cost_table thunderx3t110_extra_costs = 
+{
+  /* ALU */
+  {
+0,			/* Arith.  */
+0,			/* Logical.  */
+0,			/* Shift.  */
+0,			/* Shift_reg.  */
+COSTS_N_INSNS (1),	/* Arith_shift.  */
+COSTS_N_INSNS (1),	/* Arith_shift_reg.  */
+COSTS_N_INSNS (1),	/* Log_shift.  */
+COSTS_N_INSNS (1),	/* Log_shift_reg.  */
+0,			/* Extend.  */
+COSTS_N_INSNS (1),	/* Extend_arith.  */
+0,			/* Bfi.  */
+0,			/* Bfx.  */
+COSTS_N_INSNS (3),	/* Clz.  */
+0,			/* Rev.  */
+0,			/* Non_exec.  */
+true		/* Non_exec_costs_exec.  */
+  },
+  {
+/* MULT SImode */
+{
+  COSTS_N_INSNS (4),	/* Simple.  */
+  COSTS_N_INSNS (4),	/* Flag_setting.  */
+  COSTS_N_INSNS (4),	/* Extend.  */
+  COSTS_N_INSNS (5),	/* Add.  */
+  COSTS_N_INSNS (5),	/* Extend_add.  */
+  COSTS_N_INSNS (18)	/* Idiv.  */
+},
+/* MULT DImode */
+{
+  COSTS_N_INSNS (4),   /* Simple.  */
+  0,   /* Flag_setting.  */
+  COSTS_N_INSNS (4),   /* Extend.  */
+  COSTS_N_INSNS (5),   /* Add.  */
+  COSTS_N_INSNS (5),   /* Extend_add.  */
+  COSTS_N_INSNS (26)   /* Idiv.  */
+ 

Re: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-ssa-forwprop.c:2482

[Richard Sandiford]

"Yangfei (Felix)"  writes:
>> We don't need to fall back to constant comparisons here.
>> We should assert for known_eq between the TYPE_VECTOR_SUBPARTS
>> instead.
>> 
>> Same for the other assert.
>
> Good suggestion.  Modified accordingly.
>
>> LGTM otherwise, and sorry for the breakage.
>
> Does the v2 patch look better?
>
> Manually run the following three tests with runtest:
> gcc.target/aarch64/sve/acle/general/pr94683.c
> gcc.target/aarch64/sve/acle/general/pr94700.c
> gcc.dg/pr94784.c

Thanks, pushed to master after testing on aarch64-linux-gnu.

Richard

Re: [committed] vect: Fix comparisons between invariant booleans [PR94727]

[Christophe Lyon via Gcc-patches]

On Thu, 23 Apr 2020 at 16:48, Richard Sandiford
 wrote:
>
> This PR was caused by mismatched expectations between
> vectorizable_comparison and SLP.  We had a "<" comparison
> between two booleans that were leaves of the SLP tree, so
> vectorizable_comparison fell back on:
>
>   /* Invariant comparison.  */
>   if (!vectype)
> {
>   vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (rhs1),
>  slp_node);
>   if (maybe_ne (TYPE_VECTOR_SUBPARTS (vectype), nunits))
> return false;
> }
>
> rhs1 and rhs2 were *unsigned* boolean types, so we got back a vector
> of unsigned integers.  This in itself was OK, and meant that "<"
> worked as expected without the need for the boolean fix-ups:
>
>   /* Boolean values may have another representation in vectors
>  and therefore we prefer bit operations over comparison for
>  them (which also works for scalar masks).  We store opcodes
>  to use in bitop1 and bitop2.  Statement is vectorized as
>BITOP2 (rhs1 BITOP1 rhs2) or
>rhs1 BITOP2 (BITOP1 rhs2)
>  depending on bitop1 and bitop2 arity.  */
>   bool swap_p = false;
>   if (VECTOR_BOOLEAN_TYPE_P (vectype))
> {
>
> However, vectorizable_comparison then used vect_get_slp_defs to get
> the actual operands.  The request went to vect_get_constant_vectors,
> which also has logic to calculate the vector type.  The problem was
> that this type was different from the one chosen above:
>
>   if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op))
>   && vect_mask_constant_operand_p (stmt_vinfo))
> vector_type = truth_type_for (stmt_vectype);
>   else
> vector_type = get_vectype_for_scalar_type (vinfo, TREE_TYPE (op), 
> op_node);
>
> So the function gave back a vector of mask types, which here are vectors
> of *signed* booleans.  This meant that "<" gave:
>
>   true (-1) < false (0)
>
> and so the boolean fixup above was needed after all.
>
> Fixed by making vectorizable_comparison also pick a mask type in this case.
>
> Tested on aarch64-linux-gnu (with and without SVE) and x86_64-linux-gnu.
> Approved by Richard in the PR.
>
> Richard
>
>
> 2020-04-23  Richard Sandiford  
>
> gcc/
> PR tree-optimization/94727
> * tree-vect-stmts.c (vectorizable_comparison): Use mask_type when
> comparing invariant scalar booleans.
>
> gcc/testsuite/
> PR tree-optimization/94727
> * gcc.dg/vect/pr94727.c: New test.

Hi Richard,

The new testcase fails at execution on arm (and s390 according to
gcc-testresults).

Can you check?

Thanks
Christophe


> ---
>  gcc/testsuite/gcc.dg/vect/pr94727.c | 24 
>  gcc/tree-vect-stmts.c   |  7 +--
>  2 files changed, 29 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/vect/pr94727.c
>
> diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> index 7f3a9fb5fb3..88a1e2c51d2 100644
> --- a/gcc/tree-vect-stmts.c
> +++ b/gcc/tree-vect-stmts.c
> @@ -10566,8 +10566,11 @@ vectorizable_comparison (stmt_vec_info stmt_info, 
> gimple_stmt_iterator *gsi,
>/* Invariant comparison.  */
>if (!vectype)
>  {
> -  vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (rhs1),
> -slp_node);
> +  if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (rhs1)))
> +   vectype = mask_type;
> +  else
> +   vectype = get_vectype_for_scalar_type (vinfo, TREE_TYPE (rhs1),
> +  slp_node);
>if (!vectype || maybe_ne (TYPE_VECTOR_SUBPARTS (vectype), nunits))
> return false;
>  }
> diff --git a/gcc/testsuite/gcc.dg/vect/pr94727.c 
> b/gcc/testsuite/gcc.dg/vect/pr94727.c
> new file mode 100644
> index 000..38408711345
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/pr94727.c
> @@ -0,0 +1,24 @@
> +/* { dg-additional-options "-O3" } */
> +
> +unsigned char a[16][32];
> +long b[16][32];
> +unsigned long c;
> +_Bool d;
> +
> +void __attribute__((noipa))
> +foo (void)
> +{
> +  for (int j = 0; j < 8; j++)
> +for (int i = 0; i < 17; ++i)
> +  b[j][i] = (a[j][i] < c) > d;
> +}
> +
> +int
> +main (void)
> +{
> +  c = 1;
> +  foo ();
> +  if (!b[0][0])
> +__builtin_abort ();
> +  return 0;
> +}

Re: [patch, fortran][8/9/10 Regression] PR59107 Fortran : Spurious warning message with -Wsurprising

[Mark Eggleston]

On 27/04/2020 09:56, Thomas Koenig wrote:

Am 27.04.20 um 09:51 schrieb Mark Eggleston:
Please find attached three slightly different patches based on a 
patch for PR59107 originally developed by Janus Weil 
 and Dominique d'Humieres  for 
gcc-5. The last comment regarding the patch was on 2015-03-21 
consequently the code has moved on somewhat and some additional 
changes where required resulting in 3 slightly different patches.


Tested on x86_64 using make check-fortran.

OK to commit?


Hi Mark,

OK. I just have one request: Could you specify (in a comment in the
header) what the different values mean?
Unfortunately I don't know, they were used by Dominique d'Humieres 
.


Regards

Thomas


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

Re: Return slot optimization for stack protector strong

[Stefan Schulze Frielinghaus via Gcc-patches]

On Mon, Jan 27, 2020 at 06:53:51PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 27, 2020 at 06:49:23PM +0100, Stefan Schulze Frielinghaus wrote:
> > some function calls trigger the stack-protector-strong although such
> > calls are later on implemented via calls to internal functions.
> > Consider the following example:
> > 
> > long double
> > rintl_wrapper (long double x)
> > {
> >   return rintl (x);
> > }
> > 
> > On s390x a return value of type `long double` is passed via a return
> > slot.  Thus according to function `stack_protect_return_slot_p` a
> > function call like `rintl (x)` triggers the stack-protector-strong since
> > rintl is not an internal function.  However, in a later stage, during
> > `expand_call_stmt`, such a call is implemented via a call to an internal
> > function.  This means in the example, the call `rintl (x)` is expanded
> > into an assembler instruction with register operands only.  Thus this
> > late time decision renders the usage of the stack protector superfluous.
> 
> I doubt your predicate gives any guarantees that the builtin will be
> expanded inline rather than a library call.  Some builtins might be expanded
> inline or as a library call depending on various options, or depending on
> particular arguments etc.

I'm performing the very same check in stack_protect_return_slot_p as
done in expand_call_stmt.  In the latter we check whether a call to a
builtin function can be realized as a call to an internal function.  My
understanding of internal functions is that they have no linkage and are
therefore guaranteed to be inlined.  Do I miss something, or where do you
see a potential problem which I could try to investigate?

Cheers,
Stefan

Re: [patch, fortran][8/9/10 Regression] PR59107 Fortran : Spurious warning message with -Wsurprising

[Thomas Koenig via Gcc-patches]

Am 27.04.20 um 09:51 schrieb Mark Eggleston:
Please find attached three slightly different patches based on a patch 
for PR59107 originally developed by Janus Weil  and 
Dominique d'Humieres  for gcc-5. The last comment 
regarding the patch was on 2015-03-21 consequently the code has moved on 
somewhat and some additional changes where required resulting in 3 
slightly different patches.


Tested on x86_64 using make check-fortran.

OK to commit?


Hi Mark,

OK. I just have one request: Could you specify (in a comment in the
header) what the different values mean?

Regards

Thomas

RE: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-ssa-forwprop.c:2482

[Yangfei (Felix)]

> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Monday, April 27, 2020 3:51 PM
> To: Yangfei (Felix) 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-
> ssa-forwprop.c:2482
> 
> "Yangfei (Felix)"  writes:
> > Hi,
> >
> > PR tree-optimization/94269
> > * tree-ssa-math-opts.c (convert_plusminus_to_widen): Restrict
> > -   this
> > -   operation to single basic block.
> > +   this operation to single basic block.
> 
> Not wrong, but might as well leave the entry as-is.

OK.  Leave it there.

> >
> We don't need to fall back to constant comparisons here.
> We should assert for known_eq between the TYPE_VECTOR_SUBPARTS
> instead.
> 
> Same for the other assert.

Good suggestion.  Modified accordingly.

> LGTM otherwise, and sorry for the breakage.

Does the v2 patch look better?

Manually run the following three tests with runtest:
gcc.target/aarch64/sve/acle/general/pr94683.c
gcc.target/aarch64/sve/acle/general/pr94700.c
gcc.dg/pr94784.c

Thanks for your help,
Felix


pr94784-v2.diff
Description: pr94784-v2.diff

[PATCH] wwdocs: Update coroutines status.

[Iain Sandoe]

hi,

This makes minor adjustments  to the coroutines status reflecting the changes in
n4861, the C++20 standard DIS.

OK to apply?
thanks
Iain

—

 htdocs/gcc-10/changes.html  | 1 +
 htdocs/projects/cxx-status.html | 9 +
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 3c1046bf..593bcfc7 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -318,6 +318,7 @@ a work-in-progress.
 P0960R3, Parenthesized initialization of aggregates
 P1331R2, Allow trivial default initialization in constexpr 
contexts
 P1327R1, Allowing dynamic_cast and polymorphic typeid in constexpr 
contexts
+Coroutines, P0912R5 as applied to n4861 (requires 
-fcoroutines)
 
   
   Several C++ Defect Reports have been resolved, e.g.:
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index dd2683dc..6a715058 100644
--- a/htdocs/projects/cxx-status.html
+++ b/htdocs/projects/cxx-status.html
@@ -444,10 +444,11 @@
 
 
Coroutines 
-  https://wg21.link/p0912r5;>P0912R5
-   10
-   (Coroutines Wiki) 
-   
+  https://wg21.link/p0912r5;>P0912R5
+  as applied to http://wg21.link/n4861;>n4861
+   10 
+   (requires -fcoroutines)
+   __cpp_impl_coroutine = 201902
 
 
Parenthesized initialization of aggregates 
-- 
2.14.3

[patch, fortran][8/9/10 Regression] PR59107 Fortran : Spurious warning message with -Wsurprising

[Mark Eggleston]

Please find attached three slightly different patches based on a patch 
for PR59107 originally developed by Janus Weil  and 
Dominique d'Humieres  for gcc-5. The last comment 
regarding the patch was on 2015-03-21 consequently the code has moved on 
somewhat and some additional changes where required resulting in 3 
slightly different patches.


Tested on x86_64 using make check-fortran.

OK to commit?

Change logs for master:

fortran/ChangeLog:

    Janus Weil  and
    Dominique d'Humieres  
    Mark Eggleston  

    PR59107
    * gfortran.h: Rename field resolved as resolve_symbol_called
    and assign two 2 bits instead of 1.
    * interface.c (check_dtio_interface1): Use new field name.
    (gfc_find_typebound_dtio_proc): Use new field name.
    * resolve.c (gfc_resolve_intrinsic): Replace check of the formal
    field with resolve_symbol_called is at least 2, if it is not
    set the field to 2.  (resolve_typebound_procedure): Use new field
    name.  (resolve_symbol): Use new field name and check whether it
    is at least 1, if it is not set the field to 1.

testsuite/gfortran.dg/ChangeLog:

    Mark Eggleston 

    PR59107
    * gfortran.dg/pr59107.f90: New test.

The change logs for the back ports for gcc-8 and gcc-9 are included as 
part of the proposed commit messages at the beginning of the patch 
files. The back port dates will be updated when known.


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

>From 5a79cef24594bf8ebfe69394efd382a61f55b0f2 Mon Sep 17 00:00:00 2001
From: Mark Eggleston 
Date: Thu, 23 Apr 2020 10:33:14 +0100
Subject: [PATCH] Fortran : Spurious warning message with -Wsurprising PR59107

This change is from a patch developed by

Janus Weil   and
Dominique d'Humieres  

for gcc-5. The code has moved on since then requiring a change to
interface.c

gcc/fortran/ChangeLog:

	* gfortran.h: Rename field resolved as resolve_symbol_called
	and assign two 2 bits instead of 1.
	* interface.c (check_dtio_interface1): Use new field name.
	(gfc_find_typebound_dtio_proc): Use new field name.
	* resolve.c (gfc_resolve_intrinsic): Replace check of the formal
	field with resolve_symbol_called is at least 2, if it is not
	set the field to 2.  (resolve_typebound_procedure): Use new field
	name.  (resolve_symbol): Use new field name and check whether it
	is at least 1, if it is not set the field to 1.

gcc/testsuite/ChangeLog:

	* gfortran.dg/pr59107.f90: New test.
---
 gcc/fortran/gfortran.h|  2 +-
 gcc/fortran/interface.c   |  5 +++--
 gcc/fortran/resolve.c | 10 ++
 gcc/testsuite/gfortran.dg/pr59107.f90 | 11 +++
 4 files changed, 21 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr59107.f90

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 4e1da8c88a0..ab9c325a28c 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1621,7 +1621,7 @@ typedef struct gfc_symbol
   /* Set if the symbol is used in a function result specification .  */
   unsigned fn_result_spec:1;
   /* Used to avoid multiple resolutions of a single symbol.  */
-  unsigned resolved:1;
+  unsigned resolve_symbol_called:2;
   /* Set if this is a module function or subroutine with the
  abreviated declaration in a submodule.  */
   unsigned abr_modproc_decl:1;
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index ba1c8bc322e..f33c6632b45 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -5015,7 +5015,7 @@ check_dtio_interface1 (gfc_symbol *derived, gfc_symtree *tb_io_st,
 gfc_error ("DTIO procedure %qs at %L must be a subroutine",
 	   dtio_sub->name, _sub->declared_at);
 
-  if (!dtio_sub->resolved)
+  if (!dtio_sub->resolve_symbol_called)
 gfc_resolve_formal_arglist (dtio_sub);
 
   arg_num = 0;
@@ -5149,7 +5149,8 @@ gfc_find_typebound_dtio_proc (gfc_symbol *derived, bool write, bool formatted)
   gfc_symtree *tb_io_st = NULL;
   bool t = false;
 
-  if (!derived || !derived->resolved || derived->attr.flavor != FL_DERIVED)
+  if (!derived || !derived->resolve_symbol_called
+  || derived->attr.flavor != FL_DERIVED)
 return NULL;
 
   /* Try to find a typebound DTIO binding.  */
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index fd3b025a84f..88ba88d8bf3 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -1753,9 +1753,11 @@ gfc_resolve_intrinsic (gfc_symbol *sym, locus *loc)
   gfc_intrinsic_sym* isym = NULL;
   const char* symstd;
 
-  if (sym->formal)
+  if (sym->resolve_symbol_called >= 2)
 return true;
 
+  sym->resolve_symbol_called = 2;
+
   /* Already resolved.  */
   if (sym->from_intmod && sym->ts.type != BT_UNKNOWN)
 return true;
@@ -13909,7 +13911,7 @@ resolve_typebound_procedure (gfc_symtree* stree)
 {
   /* If proc has not been resolved at this point, proc->name may
 	 actually be a USE associated entity. See PR fortran/89647. */
-  if (!proc->resolved
+  if (!proc->resolve_symbol_called
 	  

Re: [PATCH PR94784] ICE: in simplify_vector_constructor, at tree-ssa-forwprop.c:2482

[Richard Sandiford]

"Yangfei (Felix)"  writes:
> Hi,
>
>   I see one gcc_assert was introduce in:  
> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544271.html
>   This is causing an ICE for certain cases.  I have created a PR for this: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784
>   I did some check and it looks like everything works fine before the ICE.  
> In the testcase we have two vectors with the same ABI identity but with 
> different TYPE_MODEs.
>   The proposed patch flips the assert around so that it checks that the two 
> vectors have equal TYPE_VECTOR_SUBPARTS and that converting the corresponding 
> element types is a useless_type_conversion_p.
>
>   Bootstrap and tested on aarch64-linux-gnu.  OK?
>
> Thanks,
> Felix
>
> From 518b0cf9433914f437631f16816cfb564fcce285 Mon Sep 17 00:00:00 2001
> From: Fei Yang 
> Date: Mon, 27 Apr 2020 15:04:57 +0800
> Subject: [PATCH] forwprop: Fix ICE when building an identity constructor
>  [PR94784]
>
> In the testcase for PR94784, we have two vectors with the same ABI identity
> but with different TYPE_MODEs. It would be better to flip the assert around
> so that it checks that the two vectors have equal TYPE_VECTOR_SUBPARTS and
> that converting the corresponding element types is a 
> useless_type_conversion_p.
>
> 2020-04-27  Felix Yang  
>
> gcc/
> PR tree-optimization/94784
> * tree-ssa-forwprop.c (simplify_vector_constructor): Flip the
> assert around so that it checks that the two vectors have equal
> TYPE_VECTOR_SUBPARTS and that converting the corresponding element
> types is a useless_type_conversion_p.
>
> gcc/testsuite/
> PR tree-optimization/94784
> * gcc.dg/pr94784.c: New test.
> ---
>  gcc/ChangeLog  | 11 +--
>  gcc/testsuite/ChangeLog|  5 +
>  gcc/testsuite/gcc.dg/pr94784.c | 16 
>  gcc/tree-ssa-forwprop.c| 14 --
>  4 files changed, 42 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/pr94784.c
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 38dd5837e20..03f73c736ff 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,11 @@
> +2020-04-27  Felix Yang  
> +
> + PR tree-optimization/94784
> + * tree-ssa-forwprop.c (simplify_vector_constructor): Flip the
> + assert around so that it checks that the two vectors have equal
> + TYPE_VECTOR_SUBPARTS and that converting the corresponding element
> + types is a useless_type_conversion_p.
> +
>  2020-04-25  David Edelsohn  
>  
>   * config/rs6000/rs6000-logue.c (rs6000_stack_info): Don't push a
> @@ -1790,8 +1798,7 @@
>  
>   PR tree-optimization/94269
>   * tree-ssa-math-opts.c (convert_plusminus_to_widen): Restrict
> - this
> - operation to single basic block.
> + this operation to single basic block.

Not wrong, but might as well leave the entry as-is.

>  
>  2020-03-25  Jeff Law  
>  
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 07fe8a68598..cfc7b13985d 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2020-04-27  Felix Yang  
> +
> + PR tree-optimization/94784
> + * gcc.dg/pr94784.c: New test.
> +
>  2020-04-26  Iain Sandoe  
>  
>   PR c++/94752
> diff --git a/gcc/testsuite/gcc.dg/pr94784.c b/gcc/testsuite/gcc.dg/pr94784.c
> new file mode 100644
> index 000..df6972f64aa
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/pr94784.c
> @@ -0,0 +1,16 @@
> +/* { dg-do compile { target aarch64*-*-* } } */
> +/* { dg-options "-O2 -ftree-slp-vectorize -march=armv8.2-a+sve 
> -msve-vector-bits=256" } */
> +
> +typedef short __attribute__((vector_size (8))) v4hi;
> +
> +typedef union U4HI { v4hi v; short a[4]; } u4hi;
> +
> +short a[4];
> +
> +void pass_v4hi (v4hi v) {
> +int j;
> +u4hi u;
> +u.v = v;
> +for (j = 0; j < 4; j++)
> +  a[j] = u.a[j];
> +};
> diff --git a/gcc/tree-ssa-forwprop.c b/gcc/tree-ssa-forwprop.c
> index 8ee5450b94c..7cfb18bd618 100644
> --- a/gcc/tree-ssa-forwprop.c
> +++ b/gcc/tree-ssa-forwprop.c
> @@ -2479,7 +2479,12 @@ simplify_vector_constructor (gimple_stmt_iterator *gsi)
> tree src_type = TREE_TYPE (orig[0]);
> if (!useless_type_conversion_p (type, src_type))
>   {
> -   gcc_assert (!targetm.compatible_vector_types_p (type, src_type));
> +   gcc_assert (TYPE_VECTOR_SUBPARTS (type).is_constant ()
> +   && TYPE_VECTOR_SUBPARTS (src_type).is_constant ()
> +   && (TYPE_VECTOR_SUBPARTS (type).to_constant ()
> +   == TYPE_VECTOR_SUBPARTS (src_type).to_constant ())

We don't need to fall back to constant comparisons here.
We should assert for known_eq between the TYPE_VECTOR_SUBPARTS instead.

Same for the other assert.

LGTM otherwise, and sorry for the breakage.

Thanks,
Richard

Re: [PATCH] s390: Fix C++14 vs. C++17 ABI incompatibility on s390{, x} [PR94704]

[Andreas Krebbel via Gcc-patches]

On 27.04.20 09:36, Jakub Jelinek wrote:
> On Mon, Apr 27, 2020 at 08:41:32AM +0200, Andreas Krebbel wrote:
>> Ok. Thanks for doing this!
> 
> Thanks, committed.
> 
>> We probably have to look into providing a -Wpsabi warning as well.
> 
> So like this?  Untested except on a small testcase.
> 
> 2020-04-27  Jakub Jelinek  
> 
>   PR target/94704
>   * config/s390/s390.c (s390_function_arg_vector,
>   s390_function_arg_float): Emit -Wpsabi diagnostics if the ABI changed.

Wow, that was quick. I just started to have a look at it.

Ok. Thanks!

Andreas

> 
> --- gcc/config/s390/s390.c.jj 2020-04-27 09:11:47.600095196 +0200
> +++ gcc/config/s390/s390.c2020-04-27 09:24:53.583055720 +0200
> @@ -11911,16 +11911,22 @@ s390_function_arg_vector (machine_mode m
>  
>/* The ABI says that record types with a single member are treated
>   just like that member would be.  */
> +  bool cxx17_empty_base_seen = false;
>while (TREE_CODE (type) == RECORD_TYPE)
>  {
>tree field, single = NULL_TREE;
>  
>for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
>   {
> -   if (TREE_CODE (field) != FIELD_DECL
> -   || cxx17_empty_base_field_p (field))
> +   if (TREE_CODE (field) != FIELD_DECL)
>   continue;
>  
> +   if (cxx17_empty_base_field_p (field))
> + {
> +   cxx17_empty_base_seen = true;
> +   continue;
> + }
> +
> if (single == NULL_TREE)
>   single = TREE_TYPE (field);
> else
> @@ -11940,7 +11946,22 @@ s390_function_arg_vector (machine_mode m
>   }
>  }
>  
> -  return VECTOR_TYPE_P (type);
> +  if (!VECTOR_TYPE_P (type))
> +return false;
> +
> +  if (warn_psabi && cxx17_empty_base_seen)
> +{
> +  static unsigned last_reported_type_uid;
> +  unsigned uid = TYPE_UID (TYPE_MAIN_VARIANT (type));
> +  if (uid != last_reported_type_uid)
> + {
> +   last_reported_type_uid = uid;
> +   inform (input_location, "parameter passing for argument of type "
> +   "%qT when C++17 is enabled changed to match "
> +   "C++14 in GCC 10.1", type);
> + }
> +}
> +  return true;
>  }
>  
>  /* Return true if a function argument of type TYPE and mode MODE
> @@ -11962,15 +11983,20 @@ s390_function_arg_float (machine_mode mo
>  
>/* The ABI says that record types with a single member are treated
>   just like that member would be.  */
> +  bool cxx17_empty_base_seen = false;
>while (TREE_CODE (type) == RECORD_TYPE)
>  {
>tree field, single = NULL_TREE;
>  
>for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
>   {
> -   if (TREE_CODE (field) != FIELD_DECL
> -   || cxx17_empty_base_field_p (field))
> +   if (TREE_CODE (field) != FIELD_DECL)
>   continue;
> +   if (cxx17_empty_base_field_p (field))
> + {
> +   cxx17_empty_base_seen = true;
> +   continue;
> + }
>  
> if (single == NULL_TREE)
>   single = TREE_TYPE (field);
> @@ -11984,7 +12010,23 @@ s390_function_arg_float (machine_mode mo
>   type = single;
>  }
>  
> -  return TREE_CODE (type) == REAL_TYPE;
> +  if (TREE_CODE (type) != REAL_TYPE)
> +return false;
> +
> +  if (warn_psabi && cxx17_empty_base_seen)
> +{
> +  static unsigned last_reported_type_uid;
> +  unsigned uid = TYPE_UID (TYPE_MAIN_VARIANT (type));
> +  if (uid != last_reported_type_uid)
> + {
> +   last_reported_type_uid = uid;
> +   inform (input_location, "parameter passing for argument of type "
> +   "%qT when C++17 is enabled changed to match "
> +   "C++14 in GCC 10.1", type);
> + }
> +}
> +
> +  return true;
>  }
>  
>  /* Return true if a function argument of type TYPE and mode MODE
> 
> 
>   Jakub
> 

Re: [PATCH] s390: Fix C++14 vs. C++17 ABI incompatibility on s390{,x} [PR94704]

[Jakub Jelinek via Gcc-patches]

On Mon, Apr 27, 2020 at 08:41:32AM +0200, Andreas Krebbel wrote:
> Ok. Thanks for doing this!

Thanks, committed.

> We probably have to look into providing a -Wpsabi warning as well.

So like this?  Untested except on a small testcase.

2020-04-27  Jakub Jelinek  

PR target/94704
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Emit -Wpsabi diagnostics if the ABI changed.

--- gcc/config/s390/s390.c.jj   2020-04-27 09:11:47.600095196 +0200
+++ gcc/config/s390/s390.c  2020-04-27 09:24:53.583055720 +0200
@@ -11911,16 +11911,22 @@ s390_function_arg_vector (machine_mode m
 
   /* The ABI says that record types with a single member are treated
  just like that member would be.  */
+  bool cxx17_empty_base_seen = false;
   while (TREE_CODE (type) == RECORD_TYPE)
 {
   tree field, single = NULL_TREE;
 
   for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
{
- if (TREE_CODE (field) != FIELD_DECL
- || cxx17_empty_base_field_p (field))
+ if (TREE_CODE (field) != FIELD_DECL)
continue;
 
+ if (cxx17_empty_base_field_p (field))
+   {
+ cxx17_empty_base_seen = true;
+ continue;
+   }
+
  if (single == NULL_TREE)
single = TREE_TYPE (field);
  else
@@ -11940,7 +11946,22 @@ s390_function_arg_vector (machine_mode m
}
 }
 
-  return VECTOR_TYPE_P (type);
+  if (!VECTOR_TYPE_P (type))
+return false;
+
+  if (warn_psabi && cxx17_empty_base_seen)
+{
+  static unsigned last_reported_type_uid;
+  unsigned uid = TYPE_UID (TYPE_MAIN_VARIANT (type));
+  if (uid != last_reported_type_uid)
+   {
+ last_reported_type_uid = uid;
+ inform (input_location, "parameter passing for argument of type "
+ "%qT when C++17 is enabled changed to match "
+ "C++14 in GCC 10.1", type);
+   }
+}
+  return true;
 }
 
 /* Return true if a function argument of type TYPE and mode MODE
@@ -11962,15 +11983,20 @@ s390_function_arg_float (machine_mode mo
 
   /* The ABI says that record types with a single member are treated
  just like that member would be.  */
+  bool cxx17_empty_base_seen = false;
   while (TREE_CODE (type) == RECORD_TYPE)
 {
   tree field, single = NULL_TREE;
 
   for (field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
{
- if (TREE_CODE (field) != FIELD_DECL
- || cxx17_empty_base_field_p (field))
+ if (TREE_CODE (field) != FIELD_DECL)
continue;
+ if (cxx17_empty_base_field_p (field))
+   {
+ cxx17_empty_base_seen = true;
+ continue;
+   }
 
  if (single == NULL_TREE)
single = TREE_TYPE (field);
@@ -11984,7 +12010,23 @@ s390_function_arg_float (machine_mode mo
type = single;
 }
 
-  return TREE_CODE (type) == REAL_TYPE;
+  if (TREE_CODE (type) != REAL_TYPE)
+return false;
+
+  if (warn_psabi && cxx17_empty_base_seen)
+{
+  static unsigned last_reported_type_uid;
+  unsigned uid = TYPE_UID (TYPE_MAIN_VARIANT (type));
+  if (uid != last_reported_type_uid)
+   {
+ last_reported_type_uid = uid;
+ inform (input_location, "parameter passing for argument of type "
+ "%qT when C++17 is enabled changed to match "
+ "C++14 in GCC 10.1", type);
+   }
+}
+
+  return true;
 }
 
 /* Return true if a function argument of type TYPE and mode MODE


Jakub

[PATCH PR94784] ICE: in simplify_vector_constructor, at tree-ssa-forwprop.c:2482

[Yangfei (Felix)]

Hi,

  I see one gcc_assert was introduce in:  
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544271.html
  This is causing an ICE for certain cases.  I have created a PR for this: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784
  I did some check and it looks like everything works fine before the ICE.  In 
the testcase we have two vectors with the same ABI identity but with different 
TYPE_MODEs.
  The proposed patch flips the assert around so that it checks that the two 
vectors have equal TYPE_VECTOR_SUBPARTS and that converting the corresponding 
element types is a useless_type_conversion_p.

  Bootstrap and tested on aarch64-linux-gnu.  OK?

Thanks,
Felix


pr94784-v1.diff
Description: pr94784-v1.diff

Re: [PATCH] s390: Fix C++14 vs. C++17 ABI incompatibility on s390{, x} [PR94704]

[Andreas Krebbel via Gcc-patches]

On 26.04.20 14:20, Jakub Jelinek wrote:
> Hi!
> 
> The following patch fixes the C++14 vs. C++17 ABI passing incompatibility
> on s390x-linux.
> 
> Bootstrapped/regtested on s390x-linux without and with the patch, the
> difference being:
> -FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_alt.o-cp_compat_y_alt.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_alt.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_alt.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t057 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_alt.o-cp_compat_y_alt.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_alt.o-cp_compat_y_alt.o 
> execute 
>  FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_alt.o-cp_compat_y_tst.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_alt.o 
> execute 
> -FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_tst.o 
> execute 
> when performing ALT_CXX_UNDER_TEST=g++ testing with a system GCC 10 compiler
> from a week ago.  So, the alt vs. alt FAILs are all expected (we know before
> this patch there is an ABI incompatibility) and some alt vs. tst (or tst vs.
> alt) FAILs too - that depends on if the particular x or y test is compiled
> with -std=c++14 or -std=c++17 - if x_tst is compiled with -std=c++14 and
> y_alt is compiled with -std=c++17, then it should FAIL, similarly if x_alt
> is compiled with -std=c++17 and y_tst is compiled with -std=c++14.
> 
> Ok for trunk?  Or do you want -Wpsabi warning too (seems s390 backend
> doesn't have any -Wpsabi warnings or informs yet)?
> 
> 2020-04-22  Jakub Jelinek  
> 
>   PR target/94704
>   * config/s390/s390.c (s390_function_arg_vector,
>   s390_function_arg_float): Ignore cxx17_empty_base_field_p fields.

Ok. Thanks for doing this!

We probably have to look into providing a -Wpsabi warning as well.

Andreas