Re:
Please discard this one, sorry for disturbing. Obviously I'm new to git send-email. On Wed, Jun 2, 2021 at 1:40 PM liuhongt via Gcc-patches wrote: > > This is the updated patch. > > -- BR, Hongtao
[PATCH] Canonicalize (vec_duplicate (not A)) to (not (vec_duplicate A)).
For i386, it will enable below opt
from
notl%edi
vpbroadcastd%edi, %xmm0
vpand %xmm1, %xmm0, %xmm0
to
vpbroadcastd%edi, %xmm0
vpandn %xmm1, %xmm0, %xmm0
gcc/ChangeLog:
PR target/100711
* simplify-rtx.c (simplify_unary_operation_1):
Canonicalize (vec_duplicate (not A)) to
(not (vec_duplicate A)).
* doc/md.texi (Insn Canonicalizations): Document
canonicalization of vec_duplicate.
gcc/testsuite/ChangeLog:
PR target/100711
* gcc.target/i386/avx2-pr100711.c: New test.
* gcc.target/i386/avx512bw-pr100711.c: New test.
---
gcc/doc/md.texi | 5 ++
gcc/simplify-rtx.c| 6 ++
gcc/testsuite/gcc.target/i386/avx2-pr100711.c | 73 +++
.../gcc.target/i386/avx512bw-pr100711.c | 48
4 files changed, 132 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/i386/avx2-pr100711.c
create mode 100644 gcc/testsuite/gcc.target/i386/avx512bw-pr100711.c
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 0e65b3ae663..06b42901413 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -8297,6 +8297,11 @@ operand of @code{mult} is also a shift, then that is
extended also.
This transformation is only applied when it can be proven that the
original operation had sufficient precision to prevent overflow.
+@cindex @code{vec_duplicate}, canonicalization of
+@item
+@code{(vec_duplicate (not @var{a}))} is converted to
+@code{(not (vec_duplicate @var{a}))}.
+
@end itemize
Further canonicalization rules are defined in the function
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 04423bbd195..171fc447d50 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -1708,6 +1708,12 @@ simplify_context::simplify_unary_operation_1 (rtx_code
code, machine_mode mode,
#endif
break;
+ /* Canonicalize (vec_duplicate (not A)) to (not (vec_duplicate A)). */
+case VEC_DUPLICATE:
+ if (GET_CODE (op) == NOT)
+ return gen_rtx_NOT (mode, gen_rtx_VEC_DUPLICATE (mode, XEXP (op, 0)));
+ break;
+
default:
break;
}
diff --git a/gcc/testsuite/gcc.target/i386/avx2-pr100711.c
b/gcc/testsuite/gcc.target/i386/avx2-pr100711.c
new file mode 100644
index 000..5b144623873
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/avx2-pr100711.c
@@ -0,0 +1,73 @@
+/* { dg-do compile } */
+/* { dg-options "-mavx512bw -O2" } */
+/* { dg-final { scan-assembler-times "pandn" 8 } } */
+/* { dg-final { scan-assembler-not "not\[bwlq\]" } } */
+typedef char v16qi __attribute__((vector_size(16)));
+typedef char v32qi __attribute__((vector_size(32)));
+typedef short v8hi __attribute__((vector_size(16)));
+typedef short v16hi __attribute__((vector_size(32)));
+typedef int v4si __attribute__((vector_size(16)));
+typedef int v8si __attribute__((vector_size(32)));
+typedef long long v2di __attribute__((vector_size(16)));
+typedef long long v4di __attribute__((vector_size(32)));
+
+v16qi
+f1 (char a, v16qi c)
+{
+ char b = ~a;
+ return (__extension__(v16qi) {b, b, b, b, b, b, b, b,
+b, b, b, b, b, b, b, b}) & c;
+}
+
+v32qi
+f2 (char a, v32qi c)
+{
+ char b = ~a;
+ return (__extension__(v32qi) {b, b, b, b, b, b, b, b,
+b, b, b, b, b, b, b, b,
+b, b, b, b, b, b, b, b,
+b, b, b, b, b, b, b, b}) & c;
+}
+
+v8hi
+f3 (short a, v8hi c)
+{
+ short b = ~a;
+ return (__extension__(v8hi) {b, b, b, b, b, b, b, b}) & c;
+}
+
+v16hi
+f4 (short a, v16hi c)
+{
+ short b = ~a;
+ return (__extension__(v16hi) {b, b, b, b, b, b, b, b,
+b, b, b, b, b, b, b, b}) & c;
+}
+
+v4si
+f5 (int a, v4si c)
+{
+ int b = ~a;
+ return (__extension__(v4si) {b, b, b, b}) & c;
+}
+
+v8si
+f6 (int a, v8si c)
+{
+ int b = ~a;
+ return (__extension__(v8si) {b, b, b, b, b, b, b, b}) & c;
+}
+
+v2di
+f7 (long long a, v2di c)
+{
+ long long b = ~a;
+ return (__extension__(v2di) {b, b}) & c;
+}
+
+v4di
+f8 (long long a, v4di c)
+{
+ long long b = ~a;
+ return (__extension__(v4di) {b, b, b, b}) & c;
+}
diff --git a/gcc/testsuite/gcc.target/i386/avx512bw-pr100711.c
b/gcc/testsuite/gcc.target/i386/avx512bw-pr100711.c
new file mode 100644
index 000..f0a103d0bc2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/avx512bw-pr100711.c
@@ -0,0 +1,48 @@
+/* { dg-do compile } */
+/* { dg-options "-mavx512bw -O2" } */
+/* { dg-final { scan-assembler-times "pandn" 4 } } */
+/* { dg-final { scan-assembler-not "not\[bwlq\]" } } */
+
+typedef char v64qi __attribute__((vector_size(64)));
+typedef short v32hi __attribute__((vector_size(64)));
+typedef int v16si __attribute__((vector_size(64)));
+typedef long long v8di __attribute__((vector_size(64)));
+
+v64qi
+f1 (char a, v64qi c)
+{
+ char b = ~a;
+ return (__extension__(v64qi) {b, b, b, b, b, b, b, b,
+
[PATCH] Canonicalize (vec_duplicate (not A)) to (not (vec_duplicate A)).
For i386, it will enable below opt
from
notl%edi
vpbroadcastd%edi, %xmm0
vpand %xmm1, %xmm0, %xmm0
to
vpbroadcastd%edi, %xmm0
vpandn %xmm1, %xmm0, %xmm0
gcc/ChangeLog:
PR target/100711
* simplify-rtx.c (simplify_unary_operation_1):
Canonicalize (vec_duplicate (not A)) to
(not (vec_duplicate A)).
* doc/md.texi (Insn Canonicalizations): Document
canonicalization of vec_duplicate.
gcc/testsuite/ChangeLog:
PR target/100711
* gcc.target/i386/avx2-pr100711.c: New test.
* gcc.target/i386/avx512bw-pr100711.c: New test.
---
gcc/doc/md.texi | 5 ++
gcc/simplify-rtx.c| 6 ++
gcc/testsuite/gcc.target/i386/avx2-pr100711.c | 73 +++
.../gcc.target/i386/avx512bw-pr100711.c | 48
4 files changed, 132 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/i386/avx2-pr100711.c
create mode 100644 gcc/testsuite/gcc.target/i386/avx512bw-pr100711.c
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 0e65b3ae663..06b42901413 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -8297,6 +8297,11 @@ operand of @code{mult} is also a shift, then that is
extended also.
This transformation is only applied when it can be proven that the
original operation had sufficient precision to prevent overflow.
+@cindex @code{vec_duplicate}, canonicalization of
+@item
+@code{(vec_duplicate (not @var{a}))} is converted to
+@code{(not (vec_duplicate @var{a}))}.
+
@end itemize
Further canonicalization rules are defined in the function
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 04423bbd195..171fc447d50 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -1708,6 +1708,12 @@ simplify_context::simplify_unary_operation_1 (rtx_code
code, machine_mode mode,
#endif
break;
+ /* Canonicalize (vec_duplicate (not A)) to (not (vec_duplicate A)). */
+case VEC_DUPLICATE:
+ if (GET_CODE (op) == NOT)
+ return gen_rtx_NOT (mode, gen_rtx_VEC_DUPLICATE (mode, XEXP (op, 0)));
+ break;
+
default:
break;
}
diff --git a/gcc/testsuite/gcc.target/i386/avx2-pr100711.c
b/gcc/testsuite/gcc.target/i386/avx2-pr100711.c
new file mode 100644
index 000..5b144623873
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/avx2-pr100711.c
@@ -0,0 +1,73 @@
+/* { dg-do compile } */
+/* { dg-options "-mavx512bw -O2" } */
+/* { dg-final { scan-assembler-times "pandn" 8 } } */
+/* { dg-final { scan-assembler-not "not\[bwlq\]" } } */
+typedef char v16qi __attribute__((vector_size(16)));
+typedef char v32qi __attribute__((vector_size(32)));
+typedef short v8hi __attribute__((vector_size(16)));
+typedef short v16hi __attribute__((vector_size(32)));
+typedef int v4si __attribute__((vector_size(16)));
+typedef int v8si __attribute__((vector_size(32)));
+typedef long long v2di __attribute__((vector_size(16)));
+typedef long long v4di __attribute__((vector_size(32)));
+
+v16qi
+f1 (char a, v16qi c)
+{
+ char b = ~a;
+ return (__extension__(v16qi) {b, b, b, b, b, b, b, b,
+b, b, b, b, b, b, b, b}) & c;
+}
+
+v32qi
+f2 (char a, v32qi c)
+{
+ char b = ~a;
+ return (__extension__(v32qi) {b, b, b, b, b, b, b, b,
+b, b, b, b, b, b, b, b,
+b, b, b, b, b, b, b, b,
+b, b, b, b, b, b, b, b}) & c;
+}
+
+v8hi
+f3 (short a, v8hi c)
+{
+ short b = ~a;
+ return (__extension__(v8hi) {b, b, b, b, b, b, b, b}) & c;
+}
+
+v16hi
+f4 (short a, v16hi c)
+{
+ short b = ~a;
+ return (__extension__(v16hi) {b, b, b, b, b, b, b, b,
+b, b, b, b, b, b, b, b}) & c;
+}
+
+v4si
+f5 (int a, v4si c)
+{
+ int b = ~a;
+ return (__extension__(v4si) {b, b, b, b}) & c;
+}
+
+v8si
+f6 (int a, v8si c)
+{
+ int b = ~a;
+ return (__extension__(v8si) {b, b, b, b, b, b, b, b}) & c;
+}
+
+v2di
+f7 (long long a, v2di c)
+{
+ long long b = ~a;
+ return (__extension__(v2di) {b, b}) & c;
+}
+
+v4di
+f8 (long long a, v4di c)
+{
+ long long b = ~a;
+ return (__extension__(v4di) {b, b, b, b}) & c;
+}
diff --git a/gcc/testsuite/gcc.target/i386/avx512bw-pr100711.c
b/gcc/testsuite/gcc.target/i386/avx512bw-pr100711.c
new file mode 100644
index 000..f0a103d0bc2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/avx512bw-pr100711.c
@@ -0,0 +1,48 @@
+/* { dg-do compile } */
+/* { dg-options "-mavx512bw -O2" } */
+/* { dg-final { scan-assembler-times "pandn" 4 } } */
+/* { dg-final { scan-assembler-not "not\[bwlq\]" } } */
+
+typedef char v64qi __attribute__((vector_size(64)));
+typedef short v32hi __attribute__((vector_size(64)));
+typedef int v16si __attribute__((vector_size(64)));
+typedef long long v8di __attribute__((vector_size(64)));
+
+v64qi
+f1 (char a, v64qi c)
+{
+ char b = ~a;
+ return (__extension__(v64qi) {b, b, b, b, b, b, b, b,
+
[no subject]
This is the updated patch.
Re: [PATCH] IBM Z: Remove match_scratch workaround
On 6/1/2021 8:21 PM, Ilya Leoshkevich via Gcc-patches wrote:
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
Since commit dd1ef00c45ba ("Fix bug in the define_subst handling that
made match_scratch unusable for multi-alternative patterns.") the
workaround for that bug in *ashrdi3_31 is not only no
longer necessary, but actually breaks the build.
Get rid of it by using only one alternative in (match_scratch). It
will be replicated as many times as needed in order to match the
pattern with which (define_subst) is used.
gcc/ChangeLog:
* config/s390/s390.md(*ashrdi3_31): Use a single
constraint.
* config/s390/subst.md(cconly_subst): Use a single constraint
in (match_scratch).
gcc/testsuite/ChangeLog:
* gcc.target/s390/ashr.c: New test.
Presumably this fixes:
../../../gcc/gcc/config/s390/s390.md:9335:1: alternative number mismatch:
operand 0 has 4, operand 1 has 2
../../../gcc/gcc/config/s390/s390.md:9335:1: alternative number mismatch:
operand 0 has 4, operand 2 has 2
../../../gcc/gcc/config/s390/s390.md:9335:1: wrong number of alternatives in
the output template
../../../gcc/gcc/config/s390/s390.md:9349:1: alternative number mismatch:
operand 0 has 4, operand 1 has 2
../../../gcc/gcc/config/s390/s390.md:9349:1: alternative number mismatch:
operand 0 has 4, operand 2 has 2
../../../gcc/gcc/config/s390/s390.md:9349:1: wrong number of alternatives in
the output template
../../../gcc/gcc/config/s390/s390.md:9349:1: alternative number mismatch:
operand 0 has 4, operand 1 has 2
../../../gcc/gcc/config/s390/s390.md:9349:1: alternative number mismatch:
operand 0 has 4, operand 2 has 2
../../../gcc/gcc/config/s390/s390.md:9349:1: wrong number of alternatives in
the output template
The tester has been tripping over that for about a week.
I'll let the s390 maintainers chime in on the correctness of the change.
Jeff
Re: [PATCH 10/11] sh: Update unexpected empty split condition
On Wed, 2021-06-02 at 00:05 -0500, Kewen Lin wrote: > gcc/ChangeLog: > > * config/sh/sh.md (doloop_end_split): Fix empty split condition. > --- > gcc/config/sh/sh.md | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md > index e3af9ae21c1..93ee7c9a7de 100644 > --- a/gcc/config/sh/sh.md > +++ b/gcc/config/sh/sh.md > @@ -6424,7 +6424,7 @@ (define_insn_and_split "doloop_end_split" > (clobber (reg:SI T_REG))] >"TARGET_SH2" >"#" > - "" > + "&& 1" >[(parallel [(set (reg:SI T_REG) > (eq:SI (match_dup 2) (const_int 1))) > (set (match_dup 0) (plus:SI (match_dup 2) (const_int -1)))]) This is OK (obvious). Cheers, Oleg
[PATCH 04/11] cris: Update unexpected empty split condition
gcc/ChangeLog: * config/cris/cris.md (*addi_reload): Fix empty split condition. --- gcc/config/cris/cris.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/cris/cris.md b/gcc/config/cris/cris.md index 7de0ec63fcf..d5a3c703a83 100644 --- a/gcc/config/cris/cris.md +++ b/gcc/config/cris/cris.md @@ -1311,7 +1311,7 @@ (define_insn_and_split "*addi_reload" && (INTVAL (operands[3]) == 2 || INTVAL (operands[3]) == 4) && (reload_in_progress || reload_completed)" "#" - "" + "&& 1" [(set (match_dup 0) (plus:SI (ashift:SI (match_dup 2) (match_dup 3)) (match_dup 1)))] "operands[3] = operands[3] == const2_rtx ? const1_rtx : const2_rtx;") -- 2.17.1
[PATCH 11/11] sparc: Update unexpected empty split condition
gcc/ChangeLog: * config/sparc/sparc.md (*snedi_zero_vis3, *neg_snedi_zero_subxc, *plus_snedi_zero, *plus_plus_snedi_zero, *minus_snedi_zero, *minus_minus_snedi_zero): Fix empty split condition. --- gcc/config/sparc/sparc.md | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/gcc/config/sparc/sparc.md b/gcc/config/sparc/sparc.md index c5d369626cc..0f85cb192c8 100644 --- a/gcc/config/sparc/sparc.md +++ b/gcc/config/sparc/sparc.md @@ -855,7 +855,7 @@ (define_insn_and_split "*snedi_zero_vis3" (clobber (reg:CCX CC_REG))] "TARGET_ARCH64 && TARGET_VIS3" "#" - "" + "&& 1" [(set (reg:CCXC CC_REG) (compare:CCXC (not:DI (match_dup 1)) (const_int -1))) (set (match_dup 0) (ltu:W (reg:CCXC CC_REG) (const_int 0)))] "" @@ -882,7 +882,7 @@ (define_insn_and_split "*neg_snedi_zero_subxc" (clobber (reg:CCX CC_REG))] "TARGET_ARCH64 && TARGET_SUBXC" "#" - "" + "&& 1" [(set (reg:CCXC CC_REG) (compare:CCXC (not:DI (match_dup 1)) (const_int -1))) (set (match_dup 0) (neg:W (ltu:W (reg:CCXC CC_REG) (const_int 0] "" @@ -984,7 +984,7 @@ (define_insn_and_split "*plus_snedi_zero" (clobber (reg:CCX CC_REG))] "TARGET_ARCH64 && TARGET_VIS3" "#" - "" + "&& 1" [(set (reg:CCXC CC_REG) (compare:CCXC (not:DI (match_dup 1)) (const_int -1))) (set (match_dup 0) (plus:W (ltu:W (reg:CCXC CC_REG) (const_int 0)) (match_dup 2)))] @@ -1000,7 +1000,7 @@ (define_insn_and_split "*plus_plus_snedi_zero" (clobber (reg:CCX CC_REG))] "TARGET_ARCH64 && TARGET_VIS3" "#" - "" + "&& 1" [(set (reg:CCXC CC_REG) (compare:CCXC (not:DI (match_dup 1)) (const_int -1))) (set (match_dup 0) (plus:W (plus:W (ltu:W (reg:CCXC CC_REG) (const_int 0)) (match_dup 2)) @@ -1048,7 +1048,7 @@ (define_insn_and_split "*minus_snedi_zero" (clobber (reg:CCX CC_REG))] "TARGET_ARCH64 && TARGET_SUBXC" "#" - "" + "&& 1" [(set (reg:CCXC CC_REG) (compare:CCXC (not:DI (match_dup 1)) (const_int -1))) (set (match_dup 0) (minus:W (match_dup 2) (ltu:W (reg:CCXC CC_REG) (const_int 0] @@ -1064,7 +1064,7 @@ (define_insn_and_split "*minus_minus_snedi_zero" (clobber (reg:CCX CC_REG))] "TARGET_ARCH64 && TARGET_SUBXC" "#" - "" + "&& 1" [(set (reg:CCXC CC_REG) (compare:CCXC (not:DI (match_dup 1)) (const_int -1))) (set (match_dup 0) (minus:W (minus:W (match_dup 2) (ltu:W (reg:CCXC CC_REG) (const_int 0))) -- 2.17.1
[PATCH 10/11] sh: Update unexpected empty split condition
gcc/ChangeLog: * config/sh/sh.md (doloop_end_split): Fix empty split condition. --- gcc/config/sh/sh.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md index e3af9ae21c1..93ee7c9a7de 100644 --- a/gcc/config/sh/sh.md +++ b/gcc/config/sh/sh.md @@ -6424,7 +6424,7 @@ (define_insn_and_split "doloop_end_split" (clobber (reg:SI T_REG))] "TARGET_SH2" "#" - "" + "&& 1" [(parallel [(set (reg:SI T_REG) (eq:SI (match_dup 2) (const_int 1))) (set (match_dup 0) (plus:SI (match_dup 2) (const_int -1)))]) -- 2.17.1
[PATCH 09/11] or1k: Update unexpected empty split condition
gcc/ChangeLog:
* config/or1k/or1k.md (*movdi): Fix empty split condition.
---
gcc/config/or1k/or1k.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/or1k/or1k.md b/gcc/config/or1k/or1k.md
index eb94efba0e4..495b3e277ba 100644
--- a/gcc/config/or1k/or1k.md
+++ b/gcc/config/or1k/or1k.md
@@ -351,7 +351,7 @@ (define_insn_and_split "*movdi"
"register_operand (operands[0], DImode)
|| reg_or_0_operand (operands[1], DImode)"
"#"
- ""
+ "&& 1"
[(const_int 0)]
{
rtx l0 = operand_subword (operands[0], 0, 0, DImode);
--
2.17.1
[PATCH 08/11] mips: Update unexpected empty split condition
gcc/ChangeLog: * config/mips/mips.md (, bswapsi2, bswapdi2): Fix empty split condition. --- gcc/config/mips/mips.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md index eef3cfd50a8..455b9b802f6 100644 --- a/gcc/config/mips/mips.md +++ b/gcc/config/mips/mips.md @@ -5835,7 +5835,7 @@ (define_insn_and_split "" (match_operand:SI 2 "immediate_operand" "I")))] "TARGET_MIPS16" "#" - "" + "&& 1" [(set (match_dup 0) (match_dup 1)) (set (match_dup 0) (lshiftrt:SI (match_dup 0) (match_dup 2)))] "" @@ -5871,7 +5871,7 @@ (define_insn_and_split "bswapsi2" (bswap:SI (match_operand:SI 1 "register_operand" "d")))] "ISA_HAS_WSBH && ISA_HAS_ROR" "#" - "" + "&& 1" [(set (match_dup 0) (unspec:SI [(match_dup 1)] UNSPEC_WSBH)) (set (match_dup 0) (rotatert:SI (match_dup 0) (const_int 16)))] "" @@ -5882,7 +5882,7 @@ (define_insn_and_split "bswapdi2" (bswap:DI (match_operand:DI 1 "register_operand" "d")))] "TARGET_64BIT && ISA_HAS_WSBH" "#" - "" + "&& 1" [(set (match_dup 0) (unspec:DI [(match_dup 1)] UNSPEC_DSBH)) (set (match_dup 0) (unspec:DI [(match_dup 0)] UNSPEC_DSHD))] "" -- 2.17.1
[PATCH 05/11] h8300: Update unexpected empty split condition
gcc/ChangeLog: * config/h8300/combiner.md (*andsi3_lshiftrt_n_sb): Fix empty split condition. --- gcc/config/h8300/combiner.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/h8300/combiner.md b/gcc/config/h8300/combiner.md index 20e19da0419..e31bd507a6f 100644 --- a/gcc/config/h8300/combiner.md +++ b/gcc/config/h8300/combiner.md @@ -271,7 +271,7 @@ (define_insn_and_split "*andsi3_lshiftrt_n_sb" "exact_log2 (INTVAL (operands[3])) < 16 && INTVAL (operands[2]) + exact_log2 (INTVAL (operands[3])) == 31" "#" - "" + "&& 1" [(parallel [(set (match_dup 0) (and:SI (lshiftrt:SI (match_dup 1) (match_dup 2)) (match_dup 3))) -- 2.17.1
[PATCH 03/11] arm: Update unexpected empty split condition
gcc/ChangeLog:
* config/arm/vfp.md (no_literal_pool_df_immediate,
no_literal_pool_sf_immediate): Fix empty split condition.
---
gcc/config/arm/vfp.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md
index f97af92716b..55b6c1ac585 100644
--- a/gcc/config/arm/vfp.md
+++ b/gcc/config/arm/vfp.md
@@ -2129,7 +2129,7 @@ (define_insn_and_split "no_literal_pool_df_immediate"
&& !arm_const_double_rtx (operands[1])
&& !(TARGET_VFP_DOUBLE && vfp3_const_double_rtx (operands[1]))"
"#"
- ""
+ "&& 1"
[(const_int 0)]
{
long buf[2];
@@ -2154,7 +2154,7 @@ (define_insn_and_split "no_literal_pool_sf_immediate"
&& TARGET_VFP_BASE
&& !vfp3_const_double_rtx (operands[1])"
"#"
- ""
+ "&& 1"
[(const_int 0)]
{
long buf;
--
2.17.1
[PATCH 06/11] i386: Update unexpected empty split condition
gcc/ChangeLog:
* config/i386/i386.md (*load_tp_x32_zext, *add_tp_x32_zext,
*tls_dynamic_gnu2_combine_32): Fix empty split condition.
* config/i386/sse.md (*_pmovmskb_lt,
*_pmovmskb_zext_lt, *sse2_pmovmskb_ext_lt,
*_pblendvb_lt): Likewise.
---
gcc/config/i386/i386.md | 6 +++---
gcc/config/i386/sse.md | 8
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 9ff35d9a607..545d048906d 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -15712,7 +15712,7 @@ (define_insn_and_split "*load_tp_x32_zext"
(unspec:SI [(const_int 0)] UNSPEC_TP)))]
"TARGET_X32"
"#"
- ""
+ "&& 1"
[(set (match_dup 0)
(zero_extend:DI (match_dup 1)))]
{
@@ -15750,7 +15750,7 @@ (define_insn_and_split "*add_tp_x32_zext"
(clobber (reg:CC FLAGS_REG))]
"TARGET_X32"
"#"
- ""
+ "&& 1"
[(parallel
[(set (match_dup 0)
(zero_extend:DI
@@ -15841,7 +15841,7 @@ (define_insn_and_split "*tls_dynamic_gnu2_combine_32"
(clobber (reg:CC FLAGS_REG))]
"!TARGET_64BIT && TARGET_GNU2_TLS"
"#"
- ""
+ "&& 1"
[(set (match_dup 0) (match_dup 5))]
{
operands[5] = can_create_pseudo_p () ? gen_reg_rtx (Pmode) : operands[0];
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 9d3728d1cb0..a9d78030119 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -16467,7 +16467,7 @@ (define_insn_and_split "*_pmovmskb_lt"
UNSPEC_MOVMSK))]
"TARGET_SSE2"
"#"
- ""
+ "&& 1"
[(set (match_dup 0)
(unspec:SI [(match_dup 1)] UNSPEC_MOVMSK))]
""
@@ -16489,7 +16489,7 @@ (define_insn_and_split "*_pmovmskb_zext_lt"
UNSPEC_MOVMSK)))]
"TARGET_64BIT && TARGET_SSE2"
"#"
- ""
+ "&& 1"
[(set (match_dup 0)
(zero_extend:DI (unspec:SI [(match_dup 1)] UNSPEC_MOVMSK)))]
""
@@ -16511,7 +16511,7 @@ (define_insn_and_split "*sse2_pmovmskb_ext_lt"
UNSPEC_MOVMSK)))]
"TARGET_64BIT && TARGET_SSE2"
"#"
- ""
+ "&& 1"
[(set (match_dup 0)
(sign_extend:DI (unspec:SI [(match_dup 1)] UNSPEC_MOVMSK)))]
""
@@ -17769,7 +17769,7 @@ (define_insn_and_split "*_pblendvb_lt"
UNSPEC_BLENDV))]
"TARGET_SSE4_1"
"#"
- ""
+ "&& 1"
[(set (match_dup 0)
(unspec:VI1_AVX2
[(match_dup 1) (match_dup 2) (match_dup 3)] UNSPEC_BLENDV))]
--
2.17.1
[PATCH 07/11] m68k: Update unexpected empty split condition
gcc/ChangeLog: * config/m68k/m68k.md (*zero_extend_inc, *zero_extend_dec, *zero_extendsidi2): Fix empty split condition. --- gcc/config/m68k/m68k.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md index 59a456cd496..82d075e8bf0 100644 --- a/gcc/config/m68k/m68k.md +++ b/gcc/config/m68k/m68k.md @@ -1693,7 +1693,7 @@ (define_insn_and_split "*zero_extend_inc" GET_MODE_CLASS (GET_MODE (operands[1])) == MODE_INT && GET_MODE_SIZE (GET_MODE (operands[0])) == GET_MODE_SIZE (GET_MODE (operands[1])) * 2" "#" - "" + "&& 1" [(set (match_dup 0) (const_int 0)) (set (match_dup 0) @@ -1710,7 +1710,7 @@ (define_insn_and_split "*zero_extend_dec" GET_MODE_CLASS (GET_MODE (operands[1])) == MODE_INT && GET_MODE_SIZE (GET_MODE (operands[0])) == GET_MODE_SIZE (GET_MODE (operands[1])) * 2" "#" - "" + "&& 1" [(set (match_dup 0) (match_dup 1)) (set (match_dup 0) @@ -1764,7 +1764,7 @@ (define_insn_and_split "*zero_extendsidi2" (zero_extend:DI (match_operand:SI 1 "nonimmediate_src_operand" "")))] "GET_CODE (operands[0]) != MEM || GET_CODE (operands[1]) != MEM" "#" - "" + "&& 1" [(set (match_dup 2) (match_dup 1)) (set (match_dup 3) -- 2.17.1
[PATCH 02/11] arc: Update unexpected empty split condition
gcc/ChangeLog: * config/arc/arc.md (*bbit_di): Fix empty split condition. --- gcc/config/arc/arc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/arc/arc.md b/gcc/config/arc/arc.md index 7a52551eef5..a03840c4c36 100644 --- a/gcc/config/arc/arc.md +++ b/gcc/config/arc/arc.md @@ -5020,7 +5020,7 @@ (define_insn_and_split "*bbit_di" (clobber (reg:CC_ZN CC_REG))] "!CROSSING_JUMP_P (insn)" "#" - "" + "&& 1" [(parallel [(set (pc) (if_then_else (match_dup 3) (label_ref (match_dup 0)) (pc))) (clobber (reg:CC_ZN CC_REG))])] -- 2.17.1
[PATCH 01/11] gen: Emit error msg for empty split condition
As Segher suggested, this patch is to emit the error message if the split condition of define_insn_and_split is empty while the insn condition isn't. gcc/ChangeLog: * gensupport.c (process_rtx): Emit error message for empty split condition in define_insn_and_split while the insn condition isn't. --- gcc/gensupport.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/gcc/gensupport.c b/gcc/gensupport.c index 0f19bd70664..52cee120215 100644 --- a/gcc/gensupport.c +++ b/gcc/gensupport.c @@ -620,6 +620,9 @@ process_rtx (rtx desc, file_location loc) } else if (GET_CODE (desc) == DEFINE_INSN_AND_REWRITE) error_at (loc, "the rewrite condition must start with `&&'"); + else if (split_cond[0] == '\0' && strlen (XSTR (desc, 2)) != 0) + error_at (loc, "the split condition mustn't be empty if the " +"insn condition isn't empty"); XSTR (split, 1) = split_cond; if (GET_CODE (desc) == DEFINE_INSN_AND_REWRITE) XVEC (split, 2) = gen_rewrite_sequence (XVEC (desc, 1)); -- 2.17.1
[RFC/PATCH 00/11] Fix up some unexpected empty split conditions
Hi all, define_insn_and_split should avoid to use empty split condition if the condition for define_insn isn't empty, otherwise it can sometimes result in unexpected consequence, since the split will always be done even if the insn condition doesn't hold. To avoid forgetting to add "&& 1" onto split condition, as Segher suggested in thread[1], this series is to add the check and raise an error if it catches the unexpected cases. With this new check, we have to fix up some existing define_insn_and_split which are detected as error. I hope all these places are not intentional to be kept as blank. Any comments are highly appreciated. BR, Kewen [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566970.html Kewen Lin (11): gen: Emit error msg for empty split condition arc: Update unexpected empty split condition arm: Update unexpected empty split condition cris: Update unexpected empty split condition h8300: Update unexpected empty split condition i386: Update unexpected empty split condition m68k: Update unexpected empty split condition mips: Update unexpected empty split condition or1k: Update unexpected empty split condition sh: Update unexpected empty split condition sparc: Update unexpected empty split condition gcc/config/arc/arc.md| 2 +- gcc/config/arm/vfp.md| 4 ++-- gcc/config/cris/cris.md | 2 +- gcc/config/h8300/combiner.md | 2 +- gcc/config/i386/i386.md | 6 +++--- gcc/config/i386/sse.md | 8 gcc/config/m68k/m68k.md | 6 +++--- gcc/config/mips/mips.md | 6 +++--- gcc/config/or1k/or1k.md | 2 +- gcc/config/sh/sh.md | 2 +- gcc/config/sparc/sparc.md| 12 ++-- gcc/gensupport.c | 3 +++ 12 files changed, 29 insertions(+), 26 deletions(-) -- 2.17.1
[committed] Fix minor H8 bug and prepare for more redundant test/compare elimination
These are some minor changes to the H8 port to fix a latent bug and prepare for having logical operations participate in redundant test/compare elimination that I've been sitting on for a while. These have been through my tester with testing timeouts dramatically increased to give as much coverage as possible (runs are taking nearly 18 hours, even after some hacks to dramatically improve the long-running __builtin__overflow tests). Conceptually the idea here is to move away from using match_operator and instead towards an iterator for the logical ops. That allows me to use the existing define_subst to enable redundant test/compare elimination in a later patch. Along the way this also starts to consolidate the QImode logicals with the HI/SI mode logicals and consolidate AND handling with IOR/XOR. There's one bugfix buried in here. In particular the define_insn_and_split patterns were using "reload_completed" in their split condition. It should have been "&& reload_completed". I strongly suspect there's other cases of this bug lurking and fixing them is on my TODO list. Installing on the trunk, Jeff commit 40e484885c10a0c8bd994c5cf7bf247998a4ad6b Author: Jeff Law Date: Wed Jun 2 00:56:38 2021 -0400 Fix minor bugs in H8 port logical ops. Prepare for more compare/test removal gcc/ * config/h8300/h8300-protos. (compute_a_shift_length): Drop unused argument from prototype. (output_logical_op): Add rtx_code argument. (compute_logical_op_length): Likewise. * config/h8300/h8300.c (h8300_and_costs): Pass additional argument to compute_a_shift_length. (output_logical_op); New argument with the rtx code rather than extracting it from an operand. Handle QImode too. (compute_logical_op_length): Similary. (compute_a_shift_length): Drop unused argument. * config/h8300/h8300.md (logicals): New code iterator. * config/h8300/logical.md (3 expander): Combine the "and" expander with the "ior"/"xor" expander. (bclrmsx): Combine the QI/HI mode patterns. (3 insns): Use code iterator rather than match_operator. Handle QImode as well. Update call to output_logical_op and compute_logical_op_length to pass in rtx_code Fix split condition on all define_insn_and_split patterns. (one_cmpl2): Use to support both clobbering the flags and setting ZN via existing define_subst. * config/h8300/shiftrotate.md: Drop unused argument from calls to compute_a_shift_length. Signed-off-by: Jeff Law diff --git a/gcc/config/h8300/h8300-protos.h b/gcc/config/h8300/h8300-protos.h index 45e7dec3c7d..af653292a9d 100644 --- a/gcc/config/h8300/h8300-protos.h +++ b/gcc/config/h8300/h8300-protos.h @@ -29,16 +29,15 @@ extern unsigned int compute_mov_length (rtx *); extern const char *output_plussi (rtx *, bool); extern unsigned int compute_plussi_length (rtx *, bool); extern const char *output_a_shift (rtx *); -extern unsigned int compute_a_shift_length (rtx, rtx *); +extern unsigned int compute_a_shift_length (rtx *); extern const char *output_a_rotate (enum rtx_code, rtx *); extern unsigned int compute_a_rotate_length (rtx *); extern const char *output_simode_bld (int, rtx[]); extern void final_prescan_insn (rtx_insn *, rtx *, int); extern int h8300_expand_movsi (rtx[]); extern machine_mode h8300_select_cc_mode (RTX_CODE, rtx, rtx); -extern const char *output_logical_op (machine_mode, rtx *); -extern unsigned int compute_logical_op_length (machine_mode, - rtx *); +extern const char *output_logical_op (machine_mode, rtx_code code, rtx *); +extern unsigned int compute_logical_op_length (machine_mode, rtx_code, rtx *); extern int compute_logical_op_cc (machine_mode, rtx *); extern int compute_a_shift_cc (rtx, rtx *); diff --git a/gcc/config/h8300/h8300.c b/gcc/config/h8300/h8300.c index ba2b9daf487..ef947aa468a 100644 --- a/gcc/config/h8300/h8300.c +++ b/gcc/config/h8300/h8300.c @@ -1100,7 +1100,7 @@ h8300_and_costs (rtx x) operands[1] = XEXP (x, 0); operands[2] = XEXP (x, 1); operands[3] = x; - return compute_logical_op_length (GET_MODE (x), operands) / 2; + return compute_logical_op_length (GET_MODE (x), AND, operands) / 2; } /* Compute the cost of a shift insn. */ @@ -1119,7 +1119,7 @@ h8300_shift_costs (rtx x) operands[1] = NULL; operands[2] = XEXP (x, 1); operands[3] = x; - return compute_a_shift_length (NULL, operands) / 2; + return compute_a_shift_length (operands) / 2; } /* Worker function for TARGET_RTX_COSTS. */ @@ -2879,10 +2879,8 @@ compute_plussi_cc (rtx *operands) /* Output a logical insn. */ const char * -output_logical_op (machine_mode mode, rtx *operands) +output_logical_op (machine_mode mode, rtx_code code, rtx *operands)
[Bug target/100865] pass_data_constant_pool_broadcast doesn't work on TImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865 --- Comment #2 from Hongtao.liu --- > > Also should broadcast from register be used to avoid memory load? I think yes as long as memory load from constant pool.
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
--- Comment #1 from Patrick Palka ---
The problem seems to be that default initialization of an unordered_map/set
only default initializes the allocator object rather than value initializing
it. This means the allocator's state doesn't get implicitly zeroed out, which
causes the assert inside test01() to fail. A potential fix is to make
_Hashtable_alloc's default constructor value initialize the allocator object:
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -1856,7 +1856,10 @@ namespace __detail
using __buckets_alloc_traits =
std::allocator_traits<__buckets_alloc_type>;
using __buckets_ptr = __node_base_ptr*;
- _Hashtable_alloc() = default;
+ _Hashtable_alloc() noexcept(noexcept(__ebo_node_alloc()))
+ : __ebo_node_alloc()
+ { }
+
_Hashtable_alloc(const _Hashtable_alloc&) = default;
_Hashtable_alloc(_Hashtable_alloc&&) = default;
[PATCH] IBM Z: Remove match_scratch workaround
Bootstrapped and regtested on s390x-redhat-linux. Ok for master?
Since commit dd1ef00c45ba ("Fix bug in the define_subst handling that
made match_scratch unusable for multi-alternative patterns.") the
workaround for that bug in *ashrdi3_31 is not only no
longer necessary, but actually breaks the build.
Get rid of it by using only one alternative in (match_scratch). It
will be replicated as many times as needed in order to match the
pattern with which (define_subst) is used.
gcc/ChangeLog:
* config/s390/s390.md(*ashrdi3_31): Use a single
constraint.
* config/s390/subst.md(cconly_subst): Use a single constraint
in (match_scratch).
gcc/testsuite/ChangeLog:
* gcc.target/s390/ashr.c: New test.
---
gcc/config/s390/s390.md | 14 --
gcc/config/s390/subst.md | 2 +-
gcc/testsuite/gcc.target/s390/ashr.c | 11 +++
3 files changed, 16 insertions(+), 11 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/s390/ashr.c
diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 7faf775fbf2..0c5b4dc9029 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -9328,19 +9328,13 @@
""
"")
-; FIXME: The number of alternatives is doubled here to match the fix
-; number of 2 in the subst pattern for the (clobber (match_scratch...
-; The right fix should be to support match_scratch in the output
-; pattern of a define_subst.
(define_insn "*ashrdi3_31"
- [(set (match_operand:DI 0 "register_operand" "=d, d")
-(ashiftrt:DI (match_operand:DI 1 "register_operand" "0, 0")
- (match_operand:QI 2 "shift_count_operand" "jsc,jsc")))
+ [(set (match_operand:DI 0 "register_operand" "=d")
+(ashiftrt:DI (match_operand:DI 1 "register_operand" "0")
+ (match_operand:QI 2 "shift_count_operand" "jsc")))
(clobber (reg:CC CC_REGNUM))]
"!TARGET_ZARCH"
- "@
- srda\t%0,%Y2
- srda\t%0,%Y2"
+ "srda\t%0,%Y2"
[(set_attr "op_type" "RS")
(set_attr "atype" "reg")])
diff --git a/gcc/config/s390/subst.md b/gcc/config/s390/subst.md
index 384af11c198..3ea6fc40ba8 100644
--- a/gcc/config/s390/subst.md
+++ b/gcc/config/s390/subst.md
@@ -45,7 +45,7 @@
"s390_match_ccmode(insn, CCSmode)"
[(set (reg CC_REGNUM)
(compare (match_dup 1) (const_int 0)))
- (clobber (match_scratch:DSI 0 "=d,d"))])
+ (clobber (match_scratch:DSI 0 "=d"))])
(define_subst_attr "cconly" "cconly_subst" "" "_cconly")
diff --git a/gcc/testsuite/gcc.target/s390/ashr.c
b/gcc/testsuite/gcc.target/s390/ashr.c
new file mode 100644
index 000..8cffdfa9a1d
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/ashr.c
@@ -0,0 +1,11 @@
+/* Test the arithmetic shift right pattern. */
+
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int e(void);
+
+int f (long c, int b)
+{
+ return (c >> b) && e ();
+}
--
2.31.1
[Bug target/100865] pass_data_constant_pool_broadcast doesn't work on TImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865
--- Comment #1 from Hongtao.liu ---
(insn 6 5 9 2 (set (reg:V1TI 84)
(mem/u/c:V1TI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S16 A128]))
"test.c":5:3 1474 {movv1ti_internal}
(expr_list:REG_EQUAL (const_vector:V1TI [
(const_wide_int 0xc0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c)
])
For V1TImode, we don't know vec_duplicate of what, it could be (subreg:V1TI
(vec_duplicate:v4si (si)) 0) or (subreg:V1TI (vec_duplicate:v8hi (hi)) 0) or
(subreg:V1TI (vec_duplicate:v16qi (qi)) 0)
[Bug tree-optimization/100864] (a&!b) | b is not opimized to a | b for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864
--- Comment #2 from Andrew Pinski ---
I have a patch,
(for bitop (bit_and bit_ior)
rbitop (bit_ior bit_and)
/* Similar but for comparisons which have been inverted already,
Note it is hard to similulate inverted tcc_comparison due to NaNs
so a double for loop is needed and then compare the inverse code
with the result of invert_tree_comparison is needed. */
(for cmp (tcc_comparison)
(for icmp (tcc_comparison)
(simplify
(bitop:c (rbitop:c (icmp @0 @1) @2) (cmp@3 @0 @1))
(with { enum tree_code ic = invert_tree_comparison
(cmp, HONOR_NANS (@0)); }
(if (ic == icmp)
(bitop @3 @2)))
It is more complex than I had liked but it does solve the issue. There is no
way really of simplifying the pattern either, just because of the way match.pd
works :(
Re: [PATCH v2] Add vec_const_duplicate optab and TARGET_GEN_MEMSET_SCRATCH_RTX
On Tue, Jun 1, 2021 at 6:17 PM Hongtao Liu wrote:
>
> On Wed, Jun 2, 2021 at 7:07 AM H.J. Lu via Gcc-patches
> wrote:
> >
> > On Tue, Jun 1, 2021 at 7:21 AM Jeff Law wrote:
> > >
> > >
> > >
> > > On 6/1/2021 7:29 AM, H.J. Lu via Gcc-patches wrote:
> > > > On Tue, Jun 1, 2021 at 6:25 AM Richard Biener
> > > > wrote:
> > > >> On Tue, Jun 1, 2021 at 3:05 PM H.J. Lu wrote:
> > > >>> On Mon, May 31, 2021 at 11:54:53PM -0600, Jeff Law wrote:
> > >
> > > On 5/31/2021 11:50 PM, Richard Sandiford wrote:
> > > > "H.J. Lu via Gcc-patches" writes:
> > > >> On Mon, May 31, 2021 at 06:32:04AM -0700, H.J. Lu wrote:
> > > >>> On Mon, May 31, 2021 at 6:26 AM Richard Biener
> > > >>> wrote:
> > > On Mon, May 31, 2021 at 3:12 PM H.J. Lu
> > > wrote:
> > > > On Mon, May 31, 2021 at 5:46 AM Richard Biener
> > > > wrote:
> > > >> On Mon, May 31, 2021 at 2:09 PM H.J. Lu
> > > >> wrote:
> > > >>> On Wed, May 26, 2021 at 10:28:16AM +0200, Richard Biener
> > > >>> wrote:
> > > >>>-- Target Hook: rtx TARGET_GEN_MEMSET_VALUE (rtx DATA,
> > > >>> scalar_int_mode
> > > >>> MODE)
> > > >>>This function returns the RTL of a register
> > > >>> containing
> > > >>>'GET_MODE_SIZE (MODE)' consecutive copies of the
> > > >>> unsigned char
> > > >>>value given in the RTL register DATA. For
> > > >>> example, if MODE is 4
> > > >>>bytes wide, return the RTL for 0x01010101*DATA.
> > > >> For this one I wonder if it should be an optab instead.
> > > >> Couldn't you
> > > >> use the existing vec_duplicate for this by using
> > > >> (paradoxical) subregs
> > > >> like (subreg:TI (vec_duplicate:VnQI (subreg:VnQI (reg:QI
> > > >> ...)))?
> > > > I tried. It doesn't even work on x86. See:
> > > >
> > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570661.html
> > > Not sure what I should read from there...
> > >
> > > > There are special cases to subreg HI, SI and DI modes of TI
> > > > mode in
> > > > ix86_gen_memset_value_from_prev. simplify_gen_subreg
> > > > doesn't
> > > > work here. Each backend may need its own special handling.
> > > OK, I guess I'm not (RTL) qualified enough to further review
> > > these parts,
> > > sorry. Since we're doing code generation the canonical way
> > > to communicate
> > > with backends should be optabs, not some set of disconnected
> > > target hooks.
> > > But as said, I probably don't know enough of RTL to see why
> > > it's the only way.
> > >
> > > Richard.
> > > >>> Here is the patch to add optabs instead. Does it look OK?
> > > >>>
> > > >>> Thanks.
> > > >>>
> > > >>> H.J.
> > > >>> ---
> > > >>> Add 2 optabs:
> > > >>>
> > > >>> 1. integer_extract: Extract lower bit value from the integer
> > > >>> value in
> > > >>> TImode, OImode or XImode.
> > > >> That sounds very specific, esp. the restriction to
> > > >> {TI,OI,XI}mode.
> > > >> It also sounds like it matches (subreg:{TI,OI,XI} (...) 0).
> > > >> There are
> > > >> existing target hooks verifying subreg validity - why's that
> > > >> not a good
> > > >> fit here? ISTR you say gen_lowpart () doesn't work (or was it
> > > >> simplify_gen_subreg?), why's that so?
> > > > {TI,OI,XI}mode are storage only integer types. subreg doesn't
> > > > work
> > > > well on them. I got
> > > >
> > > > [hjl@gnu-cfl-2 pieces]$ cat s2.i
> > > > extern void *ops;
> > > >
> > > > void
> > > > foo (int c)
> > > > {
> > > > __builtin_memset (ops, c, 34);
> > > > }
> > > > [hjl@gnu-cfl-2 pieces]$ make s2.s
> > > > /export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
> > > > -B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/
> > > > -O2 -march=haswell -S s2.i
> > > > during RTL pass: reload
> > > > s2.i: In function ‘foo’:
> > > > s2.i:7:1: internal compiler error: maximum number of generated
> > > > reload
> > > > insns per insn achieved (90)
> > > > 7 | }
> > > > | ^
> > > > 0x1050734 lra_constraints(bool)
> > > > /export/gnu/import/git/gitlab/x86-gcc/gcc/lra-constraints.c:5091
> > > > 0x1039536 lra(_IO_FILE*)
> > > >
[Bug target/100865] New: pass_data_constant_pool_broadcast doesn't work on TImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865
Bug ID: 100865
Summary: pass_data_constant_pool_broadcast doesn't work on
TImode
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-cfl-2 gcc]$ cat /tmp/y.c
extern char *dst;
void
foo (void)
{
__builtin_memset (dst, 12, 16);
}
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2 -march=skylake-avx512 /tmp/y.c
[hjl@gnu-cfl-2 gcc]$ cat y.s
.file "y.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movqdst(%rip), %rax
vmovdqa .LC0(%rip), %xmm0
vmovdqu %xmm0, (%rax)
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.section.rodata.cst16,"aM",@progbits,16
.align 16
.LC0:
.quad 868082074056920076
.quad 868082074056920076
.ident "GCC: (GNU) 12.0.0 20210602 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 gcc]$
Also should broadcast from register be used to avoid memory load?
[Bug tree-optimization/100864] (a&!b) | b is not opimized to a | b for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2021-06-02 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Summary|(a&!b) | b is not opimized |(a&!b) | b is not opimized |to a | b for conditionals |to a | b for comparisons --- Comment #1 from Andrew Pinski --- The pattern which matches this when this is not a comparison: (for bitop (bit_and bit_ior) rbitop (bit_ior bit_and) /* (x | y) & x -> x */ /* (x & y) | x -> x */ (simplify (bitop:c (rbitop:c @0 @1) @0) @0) /* (~x | y) & x -> x & y */ /* (~x & y) | x -> x | y */ (simplify (bitop:c (rbitop:c (bit_not @0) @1) @0) (bitop @0 @1))) We should be able to add something similar for tcc_comparison/inverted_tcc_comparison_with_nans too.
Re: [PATCH v2] Add vec_const_duplicate optab and TARGET_GEN_MEMSET_SCRATCH_RTX
On Wed, Jun 2, 2021 at 7:07 AM H.J. Lu via Gcc-patches
wrote:
>
> On Tue, Jun 1, 2021 at 7:21 AM Jeff Law wrote:
> >
> >
> >
> > On 6/1/2021 7:29 AM, H.J. Lu via Gcc-patches wrote:
> > > On Tue, Jun 1, 2021 at 6:25 AM Richard Biener
> > > wrote:
> > >> On Tue, Jun 1, 2021 at 3:05 PM H.J. Lu wrote:
> > >>> On Mon, May 31, 2021 at 11:54:53PM -0600, Jeff Law wrote:
> >
> > On 5/31/2021 11:50 PM, Richard Sandiford wrote:
> > > "H.J. Lu via Gcc-patches" writes:
> > >> On Mon, May 31, 2021 at 06:32:04AM -0700, H.J. Lu wrote:
> > >>> On Mon, May 31, 2021 at 6:26 AM Richard Biener
> > >>> wrote:
> > On Mon, May 31, 2021 at 3:12 PM H.J. Lu
> > wrote:
> > > On Mon, May 31, 2021 at 5:46 AM Richard Biener
> > > wrote:
> > >> On Mon, May 31, 2021 at 2:09 PM H.J. Lu
> > >> wrote:
> > >>> On Wed, May 26, 2021 at 10:28:16AM +0200, Richard Biener wrote:
> > >>>-- Target Hook: rtx TARGET_GEN_MEMSET_VALUE (rtx DATA,
> > >>> scalar_int_mode
> > >>> MODE)
> > >>>This function returns the RTL of a register
> > >>> containing
> > >>>'GET_MODE_SIZE (MODE)' consecutive copies of the
> > >>> unsigned char
> > >>>value given in the RTL register DATA. For example,
> > >>> if MODE is 4
> > >>>bytes wide, return the RTL for 0x01010101*DATA.
> > >> For this one I wonder if it should be an optab instead.
> > >> Couldn't you
> > >> use the existing vec_duplicate for this by using
> > >> (paradoxical) subregs
> > >> like (subreg:TI (vec_duplicate:VnQI (subreg:VnQI (reg:QI
> > >> ...)))?
> > > I tried. It doesn't even work on x86. See:
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570661.html
> > Not sure what I should read from there...
> >
> > > There are special cases to subreg HI, SI and DI modes of TI
> > > mode in
> > > ix86_gen_memset_value_from_prev. simplify_gen_subreg doesn't
> > > work here. Each backend may need its own special handling.
> > OK, I guess I'm not (RTL) qualified enough to further review
> > these parts,
> > sorry. Since we're doing code generation the canonical way to
> > communicate
> > with backends should be optabs, not some set of disconnected
> > target hooks.
> > But as said, I probably don't know enough of RTL to see why
> > it's the only way.
> >
> > Richard.
> > >>> Here is the patch to add optabs instead. Does it look OK?
> > >>>
> > >>> Thanks.
> > >>>
> > >>> H.J.
> > >>> ---
> > >>> Add 2 optabs:
> > >>>
> > >>> 1. integer_extract: Extract lower bit value from the integer
> > >>> value in
> > >>> TImode, OImode or XImode.
> > >> That sounds very specific, esp. the restriction to
> > >> {TI,OI,XI}mode.
> > >> It also sounds like it matches (subreg:{TI,OI,XI} (...) 0).
> > >> There are
> > >> existing target hooks verifying subreg validity - why's that not
> > >> a good
> > >> fit here? ISTR you say gen_lowpart () doesn't work (or was it
> > >> simplify_gen_subreg?), why's that so?
> > > {TI,OI,XI}mode are storage only integer types. subreg doesn't
> > > work
> > > well on them. I got
> > >
> > > [hjl@gnu-cfl-2 pieces]$ cat s2.i
> > > extern void *ops;
> > >
> > > void
> > > foo (int c)
> > > {
> > > __builtin_memset (ops, c, 34);
> > > }
> > > [hjl@gnu-cfl-2 pieces]$ make s2.s
> > > /export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
> > > -B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/
> > > -O2 -march=haswell -S s2.i
> > > during RTL pass: reload
> > > s2.i: In function ‘foo’:
> > > s2.i:7:1: internal compiler error: maximum number of generated
> > > reload
> > > insns per insn achieved (90)
> > > 7 | }
> > > | ^
> > > 0x1050734 lra_constraints(bool)
> > > /export/gnu/import/git/gitlab/x86-gcc/gcc/lra-constraints.c:5091
> > > 0x1039536 lra(_IO_FILE*)
> > > /export/gnu/import/git/gitlab/x86-gcc/gcc/lra.c:2336
> > > 0xfe1140 do_reload
> > > /export/gnu/import/git/gitlab/x86-gcc/gcc/ira.c:5822
> > > 0xfe162e execute
> > > /export/gnu/import/git/gitlab/x86-gcc/gcc/ira.c:6008
> > > Please submit a full bug report,
> >
Re: rs6000: Require ELFv2 ABI for ROP test (PR100750)
On Tue, Jun 01, 2021 at 11:18:05AM -0500, Bill Schmidt wrote: > Hi! PR100750 reports a failure on my part to require the ELFv2 ABI for > one of the ROP tests. This fixes that. It would be nice if we had a selector for when we can use -mrop-protect, instead of assuming it is only for ELFv2. Segher
Re: Update to GCC copyright assignment policy
On 6/1/2021 5:22 PM, Eric Gallager via Gcc wrote: On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc wrote: GCC was created as part of the GNU Project but has grown to operate as an autonomous project. The GCC Steering Committee has decided to relax the requirement to assign copyright for all changes to the Free Software Foundation. GCC will continue to be developed, distributed, and licensed under the GNU General Public License v3.0. GCC will now accept contributions with or without an FSF copyright assignment. This change is consistent with the practices of many other major Free Software projects, such as the Linux kernel. Contributors who have an FSF Copyright Assignment don't need to change anything. Contributors who wish to utilize the Developer Certificate of Origin[1] should add a Signed-off-by message to their commit messages. Developers with commit access may add their name to the DCO list in the MAINTAINERS file to certify the DCO for all future commits in lieu of individual Signed-off-by messages for each commit. The GCC Steering Committee continues to affirm the principles of Free Software, and that will never change. - The GCC Steering Committee [1] https://developercertificate.org/ One thing I'm wondering about this change is if it allows certain old changes that previously couldn't be upstreamed to now be upstreamed? For example, when I have asked about trying to forward-port certain changes from Apple's old gcc-4.2 branch, I was told that one reason this couldn't happen was because Apple hadn't assigned copyright for those changes. Of course, there are still the technical difficulties of the fact that 4.2 has bitrotted considerably in the years since its last release, but regardless of those, are the legal difficulties at least now out of the way? Read the DCO. If you can satisfy the terms of the DCO, then yes it would help. But DCO still has requirements that may not be easily met unless you are the author or know the author and can communicate with them. jeff
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 Alan Modra changed: What|Removed |Added Target|powerpc |powerpc64le CC||amodra at gmail dot com --- Comment #4 from Alan Modra --- The disassembly says this is powerpc64le. Possibly interesting fact: the offsets used above the stack frame are 400, 432, 440, which all correspond to the parameter save area. I don't see any reason that DGEBAL should have a parameter save area though since all parameters can be passed in regs.
Ping #2: [PATCH] Change rs6000_const_f32_to_i32 return type.
Ping patch again. Original patch (Change rs6000_const_f32_to_i32 return type) | Date: Tue, 18 May 2021 16:39:28 -0400 | Subject: [PATCH] Change rs6000_const_f32_to_i32 return type. | Message-ID: <20210518203928.ga15...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570680.html -- 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
Ping patch #2: [PATCH 2/2] Fix tests when running on power10, PR testsuite/100166
Ping patch again. Original patch (Fix tests when running on power10, PR testsuite/100166). | Date: Tue, 18 May 2021 16:59:12 -0400 | Subject: [PATCH 2/2] Fix tests when running on power10, PR testsuite/100166 | Message-ID: <20210518205912.gb18...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570688.html -- 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
Ping #2: [PATCH 1/2] Deal with prefixed loads/stores in tests, PR testsuite/100166
Ping patch again. Original patch (Deal with prefixed loads/stores in tests, PR testsuite/100166): | Date: Tue, 18 May 2021 16:57:59 -0400 | Subject: [PATCH 1/2] Deal with prefixed loads/stores in tests, PR testsuite/100166 | Message-ID: <20210518205759.ga18...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570686.html -- 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
Ping #2: [PATCH] Fix vec-splati-runnable.c test.
Ping patch again. Original patch (Fix vec-splati-runnable.c test) | Date: Tue, 18 May 2021 16:49:58 -0400 | Subject: [PATCH] Fix vec-splati-runnable.c test. | Message-ID: <20210518204958.ga17...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570684.html Note as Will points out I need to change the check-in message to eliminate adding abort () since in the current version of the test, the abort has been changed to storing the value in a global volatile variable. -- 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 2/2] Fix xxeval predicates.
Ping patch again. Original patch (fix xxevel predicates): | Date: Tue, 18 May 2021 16:47:58 -0400 | Subject: [PATCH 2/2] Fix xxeval predicates. | Message-ID: <20210518204758.gb16...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570683.html -- 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
Ping #2: [PATCH 0/2] Move xx* builtins to vsx.md.
Ping patch again. Original patch (move xx* builtins to vsx.md) | Date: Tue, 18 May 2021 16:46:47 -0400 | Subject: [PATCH 1/2] Move xx* builtins to vsx.md. | Message-ID: <20210518204647.ga16...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570682.html -- 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
[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 Andrew Pinski changed: What|Removed |Added Depends on||100864 --- Comment #6 from Andrew Pinski --- This depends on PR 100864 if I don't want to write out the 4 patterns. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864 [Bug 100864] (a&!b) | b is not opimized to a | b for conditionals
[Bug tree-optimization/100864] New: (a&!b) | b is not opimized to a | b for conditionals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864
Bug ID: 100864
Summary: (a&!b) | b is not opimized to a | b for conditionals
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
_Bool f(int a, int b, _Bool e)
{
_Bool c = (a > b);
_Bool d = !c;
return (e & d) | c;
}
--- CUT
We get currently:
c_5 = a_3(D) > b_4(D);
_2 = a_3(D) <= b_4(D);
_1 = _2 & e_7(D);
_6 = _1 | c_5;
But this should be optimized to just:
c_5 = a_3(D) <= b_4(D);
_6 = e_7(D) | c_5;
I noticed this while fixing PR 96923.
Ping #2: [PATCH] Allow __ibm128 on older PowerPC systems.
Ping patch again: Original patch (Allow __ibm128 on older PowerPC systems): | Date: Tue, 18 May 2021 16:36:32 -0400 | Subject: [PATCH] Allow __ibm128 on older PowerPC systems. | Message-ID: <20210518203632.ga15...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570679.html -- 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
Ping #2: [PATCH] Fix long double tests when default long double is not IBM.
Ping patch again. | Date: Tue, 18 May 2021 16:32:33 -0400 | Subject: [PATCH] Fix long double tests when default long double is not IBM. | Message-ID: <20210518203233.ga15...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570678.html -- 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
Ping #2: [PATCH 2/2] Add IEEE 128-bit fp conditional move on PowerPC.
Ping patch again. Original patch (Add IEEE 128-bit fp conditional move on PowerPC): | Date: Tue, 18 May 2021 16:28:27 -0400 | Subject: [PATCH 2/2] Add IEEE 128-bit fp conditional move on PowerPC. | Message-ID: <20210518202827.gb14...@ibm-toto.the-meissners.org> -- 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
Ping #2: [PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC.
Ping again. Original patch (Add IEEE 128-bit min/max support on PowerPC): | Date: Tue, 18 May 2021 16:26:06 -0400 | Subject: [PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC. | Message-ID: <20210518202606.ga14...@ibm-toto.the-meissners.org> | https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570675.html -- 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: Update to GCC copyright assignment policy
On Tue, Jun 1, 2021 at 10:02 AM David Edelsohn via Gcc wrote: > > GCC was created as part of the GNU Project but has grown to operate as > an autonomous project. > > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software Foundation. GCC > will continue to be developed, distributed, and licensed under the GNU > General Public License v3.0. GCC will now accept contributions with or > without an FSF copyright assignment. This change is consistent with > the practices of many other major Free Software projects, such as the > Linux kernel. > > Contributors who have an FSF Copyright Assignment don't need to > change anything. Contributors who wish to utilize the Developer Certificate > of Origin[1] should add a Signed-off-by message to their commit messages. > Developers with commit access may add their name to the DCO list in the > MAINTAINERS file to certify the DCO for all future commits in lieu of > individual > Signed-off-by messages for each commit. > > The GCC Steering Committee continues to affirm the principles of Free > Software, and that will never change. > > - The GCC Steering Committee > > [1] https://developercertificate.org/ One thing I'm wondering about this change is if it allows certain old changes that previously couldn't be upstreamed to now be upstreamed? For example, when I have asked about trying to forward-port certain changes from Apple's old gcc-4.2 branch, I was told that one reason this couldn't happen was because Apple hadn't assigned copyright for those changes. Of course, there are still the technical difficulties of the fact that 4.2 has bitrotted considerably in the years since its last release, but regardless of those, are the legal difficulties at least now out of the way? Thanks, Eric Gallager
[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > Created attachment 50905 [details] > Patch which is in testing (needs testcases) > > As I said for the case in this PR, it needs > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571616.html too. > > If you change !b to b; that is "!a ? b : 0", this patch will optimize it. > The other patch is needed to allow to move !b out of the conditional. This patch has one bug in it where we need a convert added. BUT then we run into a different missed optimization issue. _51 = p2_22 <= prephitmp_122; _44 = (logical(kind=4)) _51; _37 = p2_22 > prephitmp_122; _49 = (logical(kind=4)) _37; _38 = _49 & found_p_63; _46 = _38 | _44; This is really just: _51 = p2_22 <= prephitmp_122; _44 = (logical(kind=4)) _51; _46 = found_p_63| _44; That is we don't optimize: (a & ~b) | b into a | b if ~b has been converted already. The other thing I noticed is the cast should not be really needed but nothing removes it; I will look at that later. Note I could rewrite the pattern to do the simplification of the constants manually but I want to try to avoid that.
Re: [PATCH v2] Add vec_const_duplicate optab and TARGET_GEN_MEMSET_SCRATCH_RTX
On Tue, Jun 1, 2021 at 7:21 AM Jeff Law wrote:
>
>
>
> On 6/1/2021 7:29 AM, H.J. Lu via Gcc-patches wrote:
> > On Tue, Jun 1, 2021 at 6:25 AM Richard Biener
> > wrote:
> >> On Tue, Jun 1, 2021 at 3:05 PM H.J. Lu wrote:
> >>> On Mon, May 31, 2021 at 11:54:53PM -0600, Jeff Law wrote:
>
> On 5/31/2021 11:50 PM, Richard Sandiford wrote:
> > "H.J. Lu via Gcc-patches" writes:
> >> On Mon, May 31, 2021 at 06:32:04AM -0700, H.J. Lu wrote:
> >>> On Mon, May 31, 2021 at 6:26 AM Richard Biener
> >>> wrote:
> On Mon, May 31, 2021 at 3:12 PM H.J. Lu wrote:
> > On Mon, May 31, 2021 at 5:46 AM Richard Biener
> > wrote:
> >> On Mon, May 31, 2021 at 2:09 PM H.J. Lu
> >> wrote:
> >>> On Wed, May 26, 2021 at 10:28:16AM +0200, Richard Biener wrote:
> >>>-- Target Hook: rtx TARGET_GEN_MEMSET_VALUE (rtx DATA,
> >>> scalar_int_mode
> >>> MODE)
> >>>This function returns the RTL of a register containing
> >>>'GET_MODE_SIZE (MODE)' consecutive copies of the
> >>> unsigned char
> >>>value given in the RTL register DATA. For example, if
> >>> MODE is 4
> >>>bytes wide, return the RTL for 0x01010101*DATA.
> >> For this one I wonder if it should be an optab instead.
> >> Couldn't you
> >> use the existing vec_duplicate for this by using (paradoxical)
> >> subregs
> >> like (subreg:TI (vec_duplicate:VnQI (subreg:VnQI (reg:QI
> >> ...)))?
> > I tried. It doesn't even work on x86. See:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570661.html
> Not sure what I should read from there...
>
> > There are special cases to subreg HI, SI and DI modes of TI
> > mode in
> > ix86_gen_memset_value_from_prev. simplify_gen_subreg doesn't
> > work here. Each backend may need its own special handling.
> OK, I guess I'm not (RTL) qualified enough to further review
> these parts,
> sorry. Since we're doing code generation the canonical way to
> communicate
> with backends should be optabs, not some set of disconnected
> target hooks.
> But as said, I probably don't know enough of RTL to see why it's
> the only way.
>
> Richard.
> >>> Here is the patch to add optabs instead. Does it look OK?
> >>>
> >>> Thanks.
> >>>
> >>> H.J.
> >>> ---
> >>> Add 2 optabs:
> >>>
> >>> 1. integer_extract: Extract lower bit value from the integer
> >>> value in
> >>> TImode, OImode or XImode.
> >> That sounds very specific, esp. the restriction to {TI,OI,XI}mode.
> >> It also sounds like it matches (subreg:{TI,OI,XI} (...) 0). There
> >> are
> >> existing target hooks verifying subreg validity - why's that not a
> >> good
> >> fit here? ISTR you say gen_lowpart () doesn't work (or was it
> >> simplify_gen_subreg?), why's that so?
> > {TI,OI,XI}mode are storage only integer types. subreg doesn't work
> > well on them. I got
> >
> > [hjl@gnu-cfl-2 pieces]$ cat s2.i
> > extern void *ops;
> >
> > void
> > foo (int c)
> > {
> > __builtin_memset (ops, c, 34);
> > }
> > [hjl@gnu-cfl-2 pieces]$ make s2.s
> > /export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
> > -B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/
> > -O2 -march=haswell -S s2.i
> > during RTL pass: reload
> > s2.i: In function ‘foo’:
> > s2.i:7:1: internal compiler error: maximum number of generated
> > reload
> > insns per insn achieved (90)
> > 7 | }
> > | ^
> > 0x1050734 lra_constraints(bool)
> > /export/gnu/import/git/gitlab/x86-gcc/gcc/lra-constraints.c:5091
> > 0x1039536 lra(_IO_FILE*)
> > /export/gnu/import/git/gitlab/x86-gcc/gcc/lra.c:2336
> > 0xfe1140 do_reload
> > /export/gnu/import/git/gitlab/x86-gcc/gcc/ira.c:5822
> > 0xfe162e execute
> > /export/gnu/import/git/gitlab/x86-gcc/gcc/ira.c:6008
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See
Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc
On Tue, Jun 01, 2021 at 04:35:53PM -0400, David Malcolm wrote: > [...] > Did this patch get reviewed/approved? It's still under review, but I think it's close. > Is the latest version still this one: > https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565581.html > or is there a more recent version that should be reviewed? Yup, here's the latest (v3): https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570208.html > (I don't think I'm qualified to approve the patch, I'm just a fan of > the approach. FWIW I've been experimenting with extending -fanalyzer > to detect infoleaks in the kernel, whereas AIUI this patch is about > mitigating them) Thanks for your interest! If you patch your GCC with this, it should Just Work in the kernel (i.e. you can set CONFIG_INIT_STACK_ALL_ZERO=y) > Hope this is constructive Yup! Please report back any testing; that'll help show people are interested in the feature. :) -- Kees Cook
[Bug other/44032] internals documentation is not legally safe to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032 Eric Gallager changed: What|Removed |Added CC||ams at gnu dot org --- Comment #10 from Eric Gallager --- Does the update on copyright assignment policy affect this at all? https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html My reading of this email seems to imply that it does: https://gcc.gnu.org/pipermail/gcc/2021-June/236214.html
[Bug c++/100809] PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809
--- Comment #4 from Michael Meissner ---
Note, in looking at Carl's patch, it is only for adding the built-ins. I don't
believe it adds direct support for {,u}divti3 and {,u}moddti3 to implement
these for normal __int128 variables.
[Bug c++/100809] PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809 Michael Meissner changed: What|Removed |Added Last reconfirmed||2021-06-01 Status|UNCONFIRMED |NEW CC||carll at gcc dot gnu.org, ||meissner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Michael Meissner --- Carl Love submitted a patch for this on April 26th.
[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed|2014-01-07 00:00:00 |2021-6-1
--- Comment #12 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #4)
> > Not all testcases can be handled at gimplification time IIRC. Which
> > means "testcases welcome" first, so we can look at them individually.
>
> The GCC one I saw was equivalent of:
> #include
> bool
> m_is_less_than_n (int n, int m)
> {
>return (n==m || m_is_less_than_n (n-1,m));
> }
First we cannot optimize this into a loop until tailc rather than in either
tailr1 or tailr2.
In tailr1, we have:
_2 = m_is_less_than_n (_1, m_7(D));
if (_2 != 0)
goto ; [INV]
else
goto ; [INV]
:
:
# iftmp.0_3 = PHI <1(6), 0(3), 1(2)>
_12 = (_Bool) iftmp.0_3;
While in tailr2, we have:
_18 = m_is_less_than_n (_17, m_6(D));
_4 = (int) _18;
[local count: 1073741825]:
# iftmp.0_3 = PHI <_4(6), 1(3), 1(2), 1(4), 1(5)>
_8 = (_Bool) iftmp.0_3;
It is not until PRE where we remove the casts (to/from int).
[Bug middle-end/100861] False positive -Wmismatched-new-delete with destroying operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861
--- Comment #3 from Martin Sebor ---
The virtual dtor forces an out-of-line call to the Grommet dtor which then
calls ::operator delete(), so the warning has nothing to complain about. It
sees this code (compile with -fdump-tree-optimized=/dev/stdout):
int main ()
{
void * _3;
[local count: 1073741824]:
_3 = operator new (16);
MEM[(struct Widget *)_3].Kind = 0;
MEM[(struct Grommet *)_3].D.2504._vptr.Widget = [(void
*)&_ZTV7Grommet + 16B];
Grommet::~Grommet (_3);
return 0;
}
whereas with the original test case it sees:
int main ()
{
struct destroying_delete_t D.2584;
void * _3;
[local count: 1073741824]:
_3 = operator new (4);
Widget::operator delete (_3, D.2584); <<< warning here
return 0;
}
[Bug tree-optimization/67731] Combine of OR'ed bitfields should use bit-test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67731 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Andrew Pinski --- Mine, this is bit-field lowering related. I am hoping to get the bit-field lowering into GCC 12.
[Bug middle-end/100861] False positive -Wmismatched-new-delete with destroying operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861
--- Comment #2 from Joseph C. Sible ---
Wait, if it's just checking whether the calls to operator new and operator
delete match up, then why does adding "virtual ~Widget() {}" make the warning
go away?
[wwwdocs] lists: Fix thinko
Brown paper bag time. The List-Id: should look like a hostname, not like an email address. Somehow I put in an at-sign when changing my gcc-patches example to the match-all example we have here. Note that the "." in the procmail match are RE wildcards btw. This is common practice in procmailrcs, although not necessarily a good idea :-) Thanks to Andreas Schwab for noticing. Committed. Segher --- htdocs/lists.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/htdocs/lists.html b/htdocs/lists.html index 4ac5d5a84cd1..e9636198b732 100644 --- a/htdocs/lists.html +++ b/htdocs/lists.html @@ -226,7 +226,7 @@ our lists into a single folder named INLIST.gcc: :0 -* ^List-Id: .*<.*@gcc.gnu.org>$ +* ^List-Id: .*<.*.gcc.gnu.org>$ INLIST.gcc @@ -235,7 +235,7 @@ can use the following recipe (Use at your own risk!): :0 Wh: msgid.lock -* ^List-Id: .*<.*@gcc.gnu.org>$ +* ^List-Id: .*<.*.gcc.gnu.org>$ | formail -D 8192 msgid.cache -- 1.8.3.1
[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 --- Comment #4 from Andrew Pinski --- Created attachment 50905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50905=edit Patch which is in testing (needs testcases) As I said for the case in this PR, it needs https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571616.html too. If you change !b to b; that is "!a ? b : 0", this patch will optimize it. The other patch is needed to allow to move !b out of the conditional.
Re: [PATCH] define auto_vec copy ctor and assignment (PR 90904)
On 6/1/21 3:56 PM, Martin Sebor wrote: On 5/27/21 2:53 PM, Jason Merrill wrote: On 4/27/21 11:52 AM, Martin Sebor via Gcc-patches wrote: On 4/27/21 8:04 AM, Richard Biener wrote: On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor wrote: On 4/27/21 1:58 AM, Richard Biener wrote: On Tue, Apr 27, 2021 at 2:46 AM Martin Sebor via Gcc-patches wrote: PR 90904 notes that auto_vec is unsafe to copy and assign because the class manages its own memory but doesn't define (or delete) either special function. Since I first ran into the problem, auto_vec has grown a move ctor and move assignment from a dynamically-allocated vec but still no copy ctor or copy assignment operator. The attached patch adds the two special functions to auto_vec along with a few simple tests. It makes auto_vec safe to use in containers that expect copyable and assignable element types and passes bootstrap and regression testing on x86_64-linux. The question is whether we want such uses to appear since those can be quite inefficient? Thus the option is to delete those operators? I would strongly prefer the generic vector class to have the properties expected of any other generic container: copyable and assignable. If we also want another vector type with this restriction I suggest to add another "noncopyable" type and make that property explicit in its name. I can submit one in a followup patch if you think we need one. I'm not sure (and not strictly against the copy and assign). Looking around I see that vec<> does not do deep copying. Making auto_vec<> do it might be surprising (I added the move capability to match how vec<> is used - as "reference" to a vector) The vec base classes are special: they have no ctors at all (because of their use in unions). That's something we might have to live with but it's not a model to follow in ordinary containers. I don't think we have to live with it anymore, now that we're writing C++11. The auto_vec class was introduced to fill the need for a conventional sequence container with a ctor and dtor. The missing copy ctor and assignment operators were an oversight, not a deliberate feature. This change fixes that oversight. The revised patch also adds a copy ctor/assignment to the auto_vec primary template (that's also missing it). In addition, it adds a new class called auto_vec_ncopy that disables copying and assignment as you prefer. Hmm, adding another class doesn't really help with the confusion richi mentions. And many uses of auto_vec will pass them as vec, which will still do a shallow copy. I think it's probably better to disable the copy special members for auto_vec until we fix vec<>. There are at least a couple of problems that get in the way of fixing all of vec to act like a well-behaved C++ container: 1) The embedded vec has a trailing "flexible" array member with its instances having different size. They're initialized by memset and copied by memcpy. The class can't have copy ctors or assignments but it should disable/delete them instead. 2) The heap-based vec is used throughout GCC with the assumption of shallow copy semantics (not just as function arguments but also as members of other such POD classes). This can be changed by providing copy and move ctors and assignment operators for it, and also for some of the classes in which it's a member and that are used with the same assumption. 3) The heap-based vec::block_remove() assumes its elements are PODs. That breaks in VEC_ORDERED_REMOVE_IF (used in gcc/dwarf2cfi.c:2862 and tree-vect-patterns.c). I took a stab at both and while (1) is easy, (2) is shaping up to be a big and tricky project. Tricky because it involves using std::move in places where what's moved is subsequently still used. I can keep plugging away at it but it won't change the fact that the embedded and heap-based vecs have different requirements. It doesn't seem to me that having a safely copyable auto_vec needs to be put on hold until the rats nest above is untangled. It won't make anything worse than it is. (I have a project that depends on a sane auto_vec working). A couple of alternatives to solving this are to use std::vector or write an equivalent vector class just for GCC. It occurs to me that another way to work around the issue of passing an auto_vec by value as a vec, and thus doing a shallow copy, would be to add a vec ctor taking an auto_vec, and delete that. This would mean if you want to pass an auto_vec to a vec interface, it needs to be by reference. We might as well do the same for operator=, though that isn't as important. Jason
Re: [PATCH, rs6000] Fix alias set of link reg save MEM
On Tue, Jun 01, 2021 at 03:34:50PM -0500, Pat Haugen wrote: > Make sure link reg save MEM has frame alias set, to match other link reg > save/restore code. Okay for trunk and any backports (please do at least GCC 11). Thanks! Segher
[Bug middle-end/100861] False positive -Wmismatched-new-delete with destroying operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861
Martin Sebor changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Last reconfirmed||2021-06-01
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Blocks||100406
--- Comment #1 from Martin Sebor ---
The warning doesn't do anything special with destroying operator delete or any
other kinds of the operators (other than scalar vs array). It triggers for
this test case because it sees the result of ::operator new() being passed to
Widget::operator delete (Widget*). If Widget::operator delete() is inlined
(e.g., declared with attribute always_inline) the warning goes away just as
long as the operator doesn't pass the pointer to the wrong overload of delete.
Alternatively, if Widget defines a non-inline member operator new() that also
prevents the warning because calls to both operators match.
With that, I'm not sure that suppressing the warning for a destroying operator
delete() would be a good solution. It seems to me that the right fix is to
solve the broader problem where one of the operators is inlined and the other
isn't (similar to pr100485, except with the definitions of both operators
available in the same translation unit).
Until/unless a solution is developed I would suggest to either define the
destroying operator delete inline and have it call an out-of-line function to
do the work (as shown below) or to force the inlining of the destroying delete.
struct Widget {
const WidgetKind Kind : 4;
unsigned OtherThings : 28;
Widget(WidgetKind k) : Kind(k) {}
void operator delete(Widget *widget, std::destroying_delete_t) {
destroy_delete (widget);
}
static __attribute__ ((noinline)) void destroy_delete (Widget *);
};
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406
[Bug 100406] bogus/missing -Wmismatched-new-delete
[Bug c/100854] TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100854 --- Comment #1 from joseph at codesourcery dot com --- On Tue, 1 Jun 2021, acoplan at gcc dot gnu.org via Gcc-bugs wrote: > This could be considered a bug in TS 18661-3 which stipulates that > __FLT_EVAL_METHOD__ take backwards-incompatible values. Either way, it seems TS 18661-3 only talks about FLT_EVAL_METHOD, not __FLT_EVAL_METHOD__. GCC's then uses __FLT_EVAL_METHOD__, __FLT_EVAL_METHOD_TS_18661_3__ and __STDC_WANT_IEC_60559_TYPES_EXT__ to determine the value of FLT_EVAL_METHOD, taking account of any -fpermitted-flt-eval-methods option (or other options implying it) passed.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #3 from Segher Boessenkool --- Hi Alexander, You do not say what the actual target you used is? powerpc-linux, powerpc64-linux, powerpc64le-linux, something else entirely?
[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-01 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Mine, I have a patch which implements this. It needs https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571616.html first. I will be posting this once I write some testcases and do a bootstrap/test cycle.
Re: [PATCH] Add gnu::diagnose_as attribute
On Tuesday, 1 June 2021 21:12:18 CEST Jason Merrill wrote:
> On 5/28/21 3:42 AM, Matthias Kretz wrote:
> > On Friday, 28 May 2021 05:05:52 CEST Jason Merrill wrote:
> >> I'd think you could get the same effect from a hypothetical
> >>
> >> namespace [[gnu::diagnose_as]] stdx = std::experimental;
> >>
> >> though we'll need to add support for attributes on namespace aliases to
> >> the grammar.
> >
> > Right, but then two of my design goals can't be met:
> >
> > 1. Diagnostics have an improved signal-to-noise ratio out of the box.
> >
> > 2. We can use replacement names that are not valid identifiers.
>
> This is the basic disconnect: I think that these goals are
> contradictory, and that replacement names that are not valid identifiers
> will just confuse users that don't know about them.
With signal-to-noise ratio I meant the ratio (averaged over all GCC users - so
yes, we can't give actual numbers for these):
#characters one needs to read to understand / #total diagnostic characters.
Or more specifically
1 - #characters that are distracting from understanding the issue / #total
diagnostic characters.
Consider that for the stdx::simd case I regularly hit the problem that vim's
QuickFix truncates at 4095 characters and the message basically just got
started (i.e. it's sometimes impossible to use vim's QuickFix to understand
errors involving stdx::simd). There's *a lot* of noise that must be removed
*per default*.
WRT "invalid identifiers", there are two types:
(1) string of characters that is not a valid C++ identifier
(2) valid C++ identifier, but not defined for the given TU
(2) can be confusing, I agree, but doesn't have to be. (1) provides a stronger
hint that something is either abbreviated or intentionally hidden from the
user.
If I write `std::experimental::simd` in my code and get a diagnostic
that says 'stdₓ::simd' then it's relatively easy to
make the connection what happened here: 'stdₓ' clearly must mean something
else than a literal 'stdₓ' in my code. The user knows there's no `std::simd'
so it must be `std::experimental::simd`. (Note that once
std::experimental::simd goes into the IS, I would be the first to propose a
change for 'stdₓ::simd' back to 'std::experimental::simd'.)
> If a user sees stdx::foo in a diagnostic and then tries to refer to
> stdx::foo and gets an error, the diagnostic is not more helpful than one
> that uses the fully qualified name.
Hmm, if GCC prints an actual suggestion like "write 'stdₓ::foo' here" then
yes, I agree. That should not make use of diagnose_as.
> Jonathan, David, any thoughts on this issue?
>
> > I can imagine using it to make _Internal __names more readable while at
> > the
> > same time discouraging users to utter them in their own code. Sorry for
> > the
> > bad code obfuscation example above.
> >
> > An example for consideration from stdx::simd:
> >namespace std {
> >namespace experimental {
> >namespace parallelism_v2 [[gnu::diagnose_as("stdx")]] {
> >namespace simd_abi [[gnu::diagnose_as("simd_abi")]] {
> >
> > template
> >
> >struct _VecBuiltin;
> >
> > template
> >
> >struct _VecBltnBtmsk;
> >
> >#if x86
> >
> > using __ignore_me_0 [[gnu::diagnose_as("[SSE]")]] = _VecBuiltin<16>;
> > using __ignore_me_1 [[gnu::diagnose_as("[AVX]")]] = _VecBuiltin<32>;
> > using __ignore_me_2 [[gnu::diagnose_as("[AVX512]")]] =
> > _VecBltnBtmsk<64>;
> >
> >#endif
> >
> >
> > Then diagnostics would print 'stdx::simd'
> > instead of 'stdx::simd>'. (Users utter
> > the type by saying e.g. 'stdx::native_simd', while compiling with
> > AVX512 flags.)
>
> Wouldn't it be better to print stdx::native_simd if that's how
> the users write the type?
No. For example, I might expect that native_simd maps to AVX-512 vectors but
forgot the relevant -m flag(s). If the diagnostics show 'simd' I have a good chance of catching that issue.
And the other way around: If I wrote `stdx::simd` and it happens to be
the same type as the native_simd typedef, it would show the latter in
diagnostics. Similar issue with asking for a simd ABI with
`simd_abi::deduce_t`: I typically don't want to know whether that's
also native_simd but rather what exact simd_abi I got. And no, as a
user I don't typically care about the libstdc++ implementation details but
what those details mean.
--
──
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
──
[Bug tree-optimization/97690] (cond ? 2 : 0) is not optimized to int(cond) << 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97690 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #7 from Andrew Pinski --- Fixed for GCC 11. GCC 12 moves the simplifications to match.pd too. So closing.
[Bug testsuite/100750] new test case gcc.target/powerpc/rop-5.c fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by William Schmidt : https://gcc.gnu.org/g:3d75b5cd9a362172838825c7083a3afa2403735a commit r11-8496-g3d75b5cd9a362172838825c7083a3afa2403735a Author: Bill Schmidt Date: Tue Jun 1 15:47:22 2021 -0500 PR100750: Require ELFv2 ABI for ROP test 2021-06-01 Bill Schmidt gcc/testsuite/ PR testsuite/100750 * gcc.target/powerpc/rop-5.c: Require ELFv2 ABI.
[Bug testsuite/100750] new test case gcc.target/powerpc/rop-5.c fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750 --- Comment #4 from Bill Schmidt --- I cannot reproduce failures for powerpc64le on P10 LE.
Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc
On Mon, 2021-03-15 at 12:14 -0500, Qing Zhao via Gcc-patches wrote:
> (CC’ing gcc-patch alias).
>
> Hi, Kees,
>
>
> > On Mar 12, 2021, at 3:55 PM, Kees Cook wrote:
> >
> > On Fri, Mar 12, 2021 at 03:35:28PM -0600, Qing Zhao wrote:
> > > Hi, Kees,
> > >
> > > I am looking at the structure padding initialization issue. And
> > > also have some questions:
> > >
> > >
> > > > On Feb 24, 2021, at 10:41 PM, Kees Cook
> > > > wrote:
> > > >
> > > > It looks like there is still some issues with padding and pre-
> > > > case
> > > > switch variables. Here's the test output, FWIW:
> > > >
> > > >
> > > > test_stackinit: small_hole_static_all FAIL (uninit bytes: 3)
> > > > test_stackinit: big_hole_static_all FAIL (uninit bytes: 61)
> > > > test_stackinit: trailing_hole_static_all FAIL (uninit bytes: 7)
> > > > test_stackinit: small_hole_dynamic_all FAIL (uninit bytes: 3)
> > > > test_stackinit: big_hole_dynamic_all FAIL (uninit bytes: 61)
> > > > test_stackinit: trailing_hole_dynamic_all FAIL (uninit bytes: 7)
> > > >
> > > > test_stackinit: switch_1_none FAIL (uninit bytes: 8)
> > > > test_stackinit: switch_2_none FAIL (uninit bytes: 8)
> > > > test_stackinit: failures: 8
> > > >
> > > >
> > > > /* Simple structure with padding likely to be covered by
> > > > compiler. */
> > > > struct test_small_hole {
> > > > size_t one;
> > > > char two;
> > > > /* 3 byte padding hole here. */
> > > > int three;
> > > > unsigned long four;
> > > > };
> > > >
> > > > /* Try to trigger unhandled padding in a structure. */
> > > > struct test_aligned {
> > > > u32 internal1;
> > > > u64 internal2;
> > > > } __aligned(64);
> > > >
> > > > struct test_big_hole {
> > > > u8 one;
> > > > u8 two;
> > > > u8 three;
> > > > /* 61 byte padding hole here. */
> > > > struct test_aligned four;
> > > > } __aligned(64);
> > > >
> > > > struct test_trailing_hole {
> > > > char *one;
> > > > char *two;
> > > > char *three;
> > > > char four;
> > > > /* "sizeof(unsigned long) - 1" byte padding hole here. */
> > > > };
> > > >
> > > > They fail when they're statically initialized (either fully or
> > > > partially),
> > >
> > > So, when the structure is not statically initialized, the compiler
> > > initialization is good?
> > >
> > > For the failing cases, what’s the behavior of the LLVM -ftrivial-
> > > auto-var-init?
> > >
> > > From the LLVM patch:
> > > (https://reviews.llvm.org/D54604 )
> > >
> > >
> > > To keep the patch simple, only some undef is removed for now, see
> > > replaceUndef. The padding-related infoleaks are therefore not all
> > > gone yet.
> > > This will be addressed in a follow-up, mainly because addressing
> > > padding-related
> > > leaks should be a stand-alone option which is implied by variable
> > > initialization.
> > >
> >
> > Right, padding init happened in:
> > https://github.com/llvm/llvm-project/commit/4f7bc0eee7e6099b1abd57dac3c83529944ab23c
> >
> > And was further clarified that, IIUC, padding _must be zero_
> > regardless
> > of pattern-vs-zero in:
> > https://github.com/llvm/llvm-project/commit/d39fbc7e20d84364e409ce59724ce20625637062
>
> Thanks a lot for the above information, they are very useful.
> I will take a look at the LLVM patch and try to implement this feature
> into GCC as well.
>
> >
> > > Yes, in GCC’s implementation, I think that fixing all padding-
> > > related leaks also require a
> > > separate patch.
> >
> > That's fine -- but it'll need to be tied to -ftrivial-auto-var-init,
> > since otherwise the memory isn't actually fully initialized. :)
>
> Okay, will do that.
>
> Thanks again.
>
> Qing
>
Did this patch get reviewed/approved?
Is the latest version still this one:
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565581.html
or is there a more recent version that should be reviewed?
(I don't think I'm qualified to approve the patch, I'm just a fan of
the approach. FWIW I've been experimenting with extending -fanalyzer
to detect infoleaks in the kernel, whereas AIUI this patch is about
mitigating them)
Hope this is constructive
Dave
[PATCH, rs6000] Fix alias set of link reg save MEM
Make sure link reg save MEM has frame alias set, to match other link reg
save/restore code.
Bootstrap/regtest on powerpc64/powerpc64le with no new regressions. Ok for
trunk?
-Pat
2021-06-01 Pat Haugen
gcc/ChangeLog:
* config/rs6000/rs6000-logue.c (rs6000_emit_prologue): Use
gen_frame_store.
diff --git a/gcc/config/rs6000/rs6000-logue.c b/gcc/config/rs6000/rs6000-logue.c
index 13c00e740d6..07337c4836a 100644
--- a/gcc/config/rs6000/rs6000-logue.c
+++ b/gcc/config/rs6000/rs6000-logue.c
@@ -3257,7 +3257,7 @@ rs6000_emit_prologue (void)
if (!WORLD_SAVE_P (info) && info->lr_save_p
&& !cfun->machine->lr_is_wrapped_separately)
{
- rtx addr, reg, mem;
+ rtx reg;
reg = gen_rtx_REG (Pmode, 0);
START_USE (0);
@@ -3267,13 +3267,8 @@ rs6000_emit_prologue (void)
if (!(strategy & (SAVE_NOINLINE_GPRS_SAVES_LR
| SAVE_NOINLINE_FPRS_SAVES_LR)))
{
- addr = gen_rtx_PLUS (Pmode, frame_reg_rtx,
- GEN_INT (info->lr_save_offset + frame_off));
- mem = gen_rtx_MEM (Pmode, addr);
- /* This should not be of rs6000_sr_alias_set, because of
-__builtin_return_address. */
-
- insn = emit_move_insn (mem, reg);
+ insn = emit_insn (gen_frame_store (reg, frame_reg_rtx,
+info->lr_save_offset + frame_off));
rs6000_frame_related (insn, frame_reg_rtx, sp_off - frame_off,
NULL_RTX, NULL_RTX);
END_USE (0);
[Bug libstdc++/100863] New: 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
Bug ID: 100863
Summary: 23_containers/unordered_{map,set}/allocator/default_in
it.cc still fail at runtime even after r12-1153
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
These two tests still fail at runtime even after the r12-1153 fix for PR65816.
The tests fail at runtime when compiled with Clang.
Update to GCC copyright assignment policy
> Sent: Wednesday, June 02, 2021 at 7:58 AM > From: "Thomas Rodgers" > To: "Mark Wielaard" > Cc: "GCC Development" > Subject: Re: Update to GCC copyright assignment policy > > On 2021-06-01 07:28, Mark Wielaard wrote: > > > Hi David, > > > > On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: > > > >> The GCC Steering Committee has decided to relax the requirement to > >> assign copyright for all changes to the Free Software Foundation. GCC > >> will continue to be developed, distributed, and licensed under the GNU > >> General Public License v3.0. GCC will now accept contributions with or > >> without an FSF copyright assignment. This change is consistent with > >> the practices of many other major Free Software projects, such as the > >> Linux kernel. > >> > >> Contributors who have an FSF Copyright Assignment don't need to > >> change anything. Contributors who wish to utilize the Developer > >> Certificate > >> of Origin[1] should add a Signed-off-by message to their commit > >> messages. > >> Developers with commit access may add their name to the DCO list in > >> the > >> MAINTAINERS file to certify the DCO for all future commits in lieu of > >> individual > >> Signed-off-by messages for each commit. > > > > This seems a pretty bad policy to be honest. > > Why was there no public discussion on this? > > > > I certainly understand not wanting to assign copyright to the FSF > > anymore given the recent board decisions. But changing GCC from having > > a shared copyright pool to having lots of individual (or company?) > > copyright holders seems like a regression for a strong copyleft > > project. > > > > With individual copyright holders companies no longer have clear way to > > know whether they are in compliance unless they talk to each and every > > individual copyright holder (see also the linux kernel, where there are > > some individuals who randomly sue companies just to get some money to > > drop the lawsuit). And for users it will be harder to get compliant > > sources if they can no longer simply ask the shared copyright holder, > > but instead will have to get enough individual copyright holders to get > > a distributor into compliance. > > > > If we no longer want the FSF to be the legal guardian and copyright > > holder for GCC could we please find another legal entity that performs > > that role and helps us as a project with copyleft compliance? > > Personally, this would have been my preference. One thing to consider is whether there exists any legal expertise for this. This obsession of GCC to disassociate from the FSF is unskilled and unnecessary. Much effort should rather be put upon doing real work, opposing the European Union Directive on Copyright in the Digital Single Market that came into force on 7 June 2019. > > I would be happy to setup a shared copyright pool under the Conservancy > > Copyleft Compliance project for example: > > https://sfconservancy.org/copyleft-compliance/ > > > > Thanks, > > > > Mark - Christopher Dimech Society has became too quick to pass judgement and declare someone Persona Non-Grata, the most extreme form of censure a country can bestow. In a new era of destructive authoritarianism, I support Richard Stallman. Times of great crisis are also times of great opportunity. I call upon you to make this struggle yours as well ! https://stallmansupport.org/ https://www.fsf.org/ https://www.gnu.org/
[Bug middle-end/100685] #pragma GCC push_options ineffective for optimize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100685
--- Comment #4 from Martin Sebor ---
Thanks. I belatedly realized that the test case didn't reproduce the problem I
was seeing. The one below demonstrates that the -O1 option does override the
-O2 set earlier. Sorry for the noise!
$ cat pr100685.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout
pr100685.c
#pragma GCC optimize ("2")
int f (void)
{
char s[] = "abc";
return __builtin_strlen (s); // folded to 3 (good)
}
#pragma GCC push_options
#pragma GCC optimize ("1")
int g (void)
{
char s[] = "abc";
return __builtin_strlen (s); // not folded and shouldn't be
}
;; Function f (f, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
__attribute__((optimize ("2")))
int f ()
{
[local count: 1073741824]:
return 3;
}
;; Function g (g, funcdef_no=1, decl_uid=1947, cgraph_uid=2, symbol_order=1)
__attribute__((optimize ("2", "1")))
int g ()
{
char s[4];
long unsigned int _1;
int _4;
[local count: 1073741824]:
s = "abc";
_1 = __builtin_strlen ();
_4 = (int) _1;
s ={v} {CLOBBER};
return _4;
}
[Bug c++/65816] Constructor delegation does not perform zero-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816 --- Comment #8 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ac0bc21bd634a334ba8f323c39a11f01dfdc2aae commit r12-1153-gac0bc21bd634a334ba8f323c39a11f01dfdc2aae Author: Patrick Palka Date: Tue Jun 1 12:23:49 2021 -0400 c++: value-init vs zero-init in expand_aggr_init_1 [PR65816] In the case of value-initializing an object of class type T, [dcl.init.general]/8 says: - if T has either no default constructor ([class.default.ctor]) or a default constructor that is user-provided or deleted, then the object is default-initialized; - otherwise, the object is zero-initialized and ... if T has a non-trivial default constructor, the object is default-initialized; But when determining whether to first zero-initialize the object, expand_aggr_init_1 incorrectly considers the user-providedness of _all_ constructors rather than only that of the _default_ constructors. This causes us to skip the zero-initialization step when the class type has a defaulted default constructor alongside a user-defined constructor. It seems the predicate type_has_non_user_provided_default_constructor accurately captures the above rule for when to first perform a zero-initialization during value-initialization, so this patch adjusts expand_aggr_init_1 to use this predicate instead. PR c++/65816 gcc/cp/ChangeLog: * init.c (expand_aggr_init_1): Check type_has_non_user_provided_default_constructor instead of type_has_user_provided_constructor. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-delegating3.C: New test. * g++.dg/cpp0x/dc10.C: New test. * g++.dg/cpp0x/initlist-base4.C: New test. * g++.dg/cpp2a/constexpr-init22.C: New test. libstdc++-v3/ChangeLog: * testsuite/23_containers/deque/allocator/default_init.cc, testsuite/23_containers/forward_list/allocator/default_init.cc, testsuite/23_containers/list/allocator/default_init.cc, testsuite/23_containers/map/allocator/default_init.cc, testsuite/23_containers/set/allocator/default_init.cc, testsuite/23_containers/vector/allocator/default_init.cc, testsuite/23_containers/vector/bool/allocator/default_init.cc: Remove xfail.
Re: [PATCH] Hashtable PR96088
On 01/06/21 8:10 pm, Jonathan Wakely wrote:
On 01/06/21 18:47 +0100, Jonathan Wakely wrote:
On 01/06/21 18:45 +0100, Jonathan Wakely wrote:
On 22/05/21 18:35 +0200, François Dumont wrote:
diff --git
a/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
b/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
new file mode 100644
index 000..53bb754dab6
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
@@ -0,0 +1,271 @@
+// { dg-do run { target c++11 } }
+
+// Copyright (C) 2021 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
+//
Re: Update to GCC copyright assignment policy
On 2021-06-01 07:28, Mark Wielaard wrote: Hi David, On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: The GCC Steering Committee has decided to relax the requirement to assign copyright for all changes to the Free Software Foundation. GCC will continue to be developed, distributed, and licensed under the GNU General Public License v3.0. GCC will now accept contributions with or without an FSF copyright assignment. This change is consistent with the practices of many other major Free Software projects, such as the Linux kernel. Contributors who have an FSF Copyright Assignment don't need to change anything. Contributors who wish to utilize the Developer Certificate of Origin[1] should add a Signed-off-by message to their commit messages. Developers with commit access may add their name to the DCO list in the MAINTAINERS file to certify the DCO for all future commits in lieu of individual Signed-off-by messages for each commit. This seems a pretty bad policy to be honest. Why was there no public discussion on this? I certainly understand not wanting to assign copyright to the FSF anymore given the recent board decisions. But changing GCC from having a shared copyright pool to having lots of individual (or company?) copyright holders seems like a regression for a strong copyleft project. With individual copyright holders companies no longer have clear way to know whether they are in compliance unless they talk to each and every individual copyright holder (see also the linux kernel, where there are some individuals who randomly sue companies just to get some money to drop the lawsuit). And for users it will be harder to get compliant sources if they can no longer simply ask the shared copyright holder, but instead will have to get enough individual copyright holders to get a distributor into compliance. If we no longer want the FSF to be the legal guardian and copyright holder for GCC could we please find another legal entity that performs that role and helps us as a project with copyleft compliance? Personally, this would have been my preference. I would be happy to setup a shared copyright pool under the Conservancy Copyleft Compliance project for example: https://sfconservancy.org/copyleft-compliance/ Thanks, Mark
Re: [PATCH] define auto_vec copy ctor and assignment (PR 90904)
On 5/27/21 2:53 PM, Jason Merrill wrote: On 4/27/21 11:52 AM, Martin Sebor via Gcc-patches wrote: On 4/27/21 8:04 AM, Richard Biener wrote: On Tue, Apr 27, 2021 at 3:59 PM Martin Sebor wrote: On 4/27/21 1:58 AM, Richard Biener wrote: On Tue, Apr 27, 2021 at 2:46 AM Martin Sebor via Gcc-patches wrote: PR 90904 notes that auto_vec is unsafe to copy and assign because the class manages its own memory but doesn't define (or delete) either special function. Since I first ran into the problem, auto_vec has grown a move ctor and move assignment from a dynamically-allocated vec but still no copy ctor or copy assignment operator. The attached patch adds the two special functions to auto_vec along with a few simple tests. It makes auto_vec safe to use in containers that expect copyable and assignable element types and passes bootstrap and regression testing on x86_64-linux. The question is whether we want such uses to appear since those can be quite inefficient? Thus the option is to delete those operators? I would strongly prefer the generic vector class to have the properties expected of any other generic container: copyable and assignable. If we also want another vector type with this restriction I suggest to add another "noncopyable" type and make that property explicit in its name. I can submit one in a followup patch if you think we need one. I'm not sure (and not strictly against the copy and assign). Looking around I see that vec<> does not do deep copying. Making auto_vec<> do it might be surprising (I added the move capability to match how vec<> is used - as "reference" to a vector) The vec base classes are special: they have no ctors at all (because of their use in unions). That's something we might have to live with but it's not a model to follow in ordinary containers. I don't think we have to live with it anymore, now that we're writing C++11. The auto_vec class was introduced to fill the need for a conventional sequence container with a ctor and dtor. The missing copy ctor and assignment operators were an oversight, not a deliberate feature. This change fixes that oversight. The revised patch also adds a copy ctor/assignment to the auto_vec primary template (that's also missing it). In addition, it adds a new class called auto_vec_ncopy that disables copying and assignment as you prefer. Hmm, adding another class doesn't really help with the confusion richi mentions. And many uses of auto_vec will pass them as vec, which will still do a shallow copy. I think it's probably better to disable the copy special members for auto_vec until we fix vec<>. There are at least a couple of problems that get in the way of fixing all of vec to act like a well-behaved C++ container: 1) The embedded vec has a trailing "flexible" array member with its instances having different size. They're initialized by memset and copied by memcpy. The class can't have copy ctors or assignments but it should disable/delete them instead. 2) The heap-based vec is used throughout GCC with the assumption of shallow copy semantics (not just as function arguments but also as members of other such POD classes). This can be changed by providing copy and move ctors and assignment operators for it, and also for some of the classes in which it's a member and that are used with the same assumption. 3) The heap-based vec::block_remove() assumes its elements are PODs. That breaks in VEC_ORDERED_REMOVE_IF (used in gcc/dwarf2cfi.c:2862 and tree-vect-patterns.c). I took a stab at both and while (1) is easy, (2) is shaping up to be a big and tricky project. Tricky because it involves using std::move in places where what's moved is subsequently still used. I can keep plugging away at it but it won't change the fact that the embedded and heap-based vecs have different requirements. It doesn't seem to me that having a safely copyable auto_vec needs to be put on hold until the rats nest above is untangled. It won't make anything worse than it is. (I have a project that depends on a sane auto_vec working). A couple of alternatives to solving this are to use std::vector or write an equivalent vector class just for GCC. Martin Jason
[Bug c++/100862] New: using enum member access fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100862
Bug ID: 100862
Summary: using enum member access fail
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eligorkadaf at gmail dot com
Target Milestone: ---
The following code must compile according to C++20 standard. However, gcc fails
to compile it
enum class fruit { orange, apple };
struct Working {
using enum fruit;
};
struct Broken {
using enum fruit;
private:
};
int main() {
Working::orange;
Broken::orange;
}
Link to godbolt(I don't have gcc-11 installed): https://godbolt.org/z/srYj3sMno
Link to C++-draft clause: http://eel.is/c++draft/namespace.udecl#16
[Bug c++/100861] New: False positive -Wmismatched-new-delete with destroying operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861
Bug ID: 100861
Summary: False positive -Wmismatched-new-delete with destroying
operator delete
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: josephcsible at gmail dot com
Target Milestone: ---
Currently, code like "Base *b = new Derived; delete b;" gives a
-Wmismatched-new-delete warning, unless Base has a virtual destructor. One of
the use cases for C++20's destroying operator delete is to make this safe
without needing a virtual destructor, so this warning should be suppressed if
Base has a destroying operator delete. Here's a modified version of the code at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0722r1.html that will
unnecessarily cause this warning (compile with -std=c++20 -Wall):
#include
enum class WidgetKind {
Grommet,
Wingnut
};
struct Widget {
const WidgetKind Kind : 4;
unsigned OtherThings : 28;
Widget(WidgetKind k) : Kind(k) {}
void operator delete(Widget *, std::destroying_delete_t);
};
struct Grommet : Widget {
Grommet() : Widget(WidgetKind::Grommet) {}
};
struct Wingnut : Widget {
Wingnut() : Widget(WidgetKind::Wingnut) {}
};
void Widget::operator delete(Widget *widget, std::destroying_delete_t) {
switch (widget->Kind) {
case WidgetKind::Grommet:
static_cast(widget)->~Grommet();
::operator delete(widget, sizeof(Grommet));
return;
case WidgetKind::Wingnut:
static_cast(widget)->~Wingnut();
::operator delete(widget, sizeof(Wingnut));
return;
}
}
int main() {
Widget *widget = new Grommet;
delete widget;
}
[PATCH] ARC: gcc driver default to hs38_linux
arc700 is legacy and there's no active development for it, so switch to latest hs38_linux as default Signed-off-by: Vineet Gupta --- gcc/config/arc/arc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h index bd1fe0abd7af..252241a858c9 100644 --- a/gcc/config/arc/arc.h +++ b/gcc/config/arc/arc.h @@ -34,7 +34,7 @@ along with GCC; see the file COPYING3. If not see #define SYMBOL_FLAG_CMEM (SYMBOL_FLAG_MACH_DEP << 3) #ifndef TARGET_CPU_DEFAULT -#define TARGET_CPU_DEFAULT PROCESSOR_arc700 +#define TARGET_CPU_DEFAULT PROCESSOR_hs38_linux #endif /* Check if this symbol has a long_call attribute in its declaration */ -- 2.25.1
[PATCH] rtl: constm64_rtx..const64_rtx
Since times immemorial there has been const_int_rtx for all values from
-64 to 64, but only constm1_rtx..const2_rtx have been available for
convenient use. Change this, so that we can use all values in
{-64,...,64} in RTL easily. This matters, because then we we just say
if (XEXP (x, 1) == const16_rtx)
and things like that, since all const_int in that range are unique. We
already do for -1, 0, 1, 2, but we could for everything.
2021-06-01 Segher Boessenkool
* rtl.h (constm64_rtx, ..., constm2_rtx): New.
(const3_rtx, ..., const64_rtx): New.
doc/
* rtl.texi (Constants): Document the new names.
---
Tested on powerpc64-linux {-m32,-m64}, but this of course doesn't mean
all that much until any of the new names are actually used.
Is this okay for trunk?
Segher
gcc/doc/rtl.texi | 20 +
gcc/rtl.h| 127 ++-
2 files changed, 137 insertions(+), 10 deletions(-)
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index 5af71137a878..5dbfb6028095 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -1658,19 +1658,21 @@ copies of the top bit. Note however that values are
neither
inherently signed nor inherently unsigned; where necessary, signedness
is determined by the rtl operation instead.
+@findex constm64_rtx
+@findex constm1_rtx
@findex const0_rtx
@findex const1_rtx
@findex const2_rtx
-@findex constm1_rtx
-There is only one expression object for the integer value zero; it is
+@findex const64_rtx
+There is only one expression object for the integer value zero: it is
the value of the variable @code{const0_rtx}. Likewise, the only
-expression for integer value one is found in @code{const1_rtx}, the only
-expression for integer value two is found in @code{const2_rtx}, and the
-only expression for integer value negative one is found in
-@code{constm1_rtx}. Any attempt to create an expression of code
-@code{const_int} and value zero, one, two or negative one will return
-@code{const0_rtx}, @code{const1_rtx}, @code{const2_rtx} or
-@code{constm1_rtx} as appropriate.
+expression for integer value one is found in @code{const1_rtx}, and more
+generally, the only expression for integer value @var{N} is found in
+@code{const@var{N}_rtx}, and the only expression for integer value negative
+@var{N} is found in @code{constm@var{N}_rtx}, both for any @var{N} from 1 up
+to 64 inclusive. Any attempt to create an expression of code
+@code{const_int} and value in that range will return @code{const0_rtx},
+@code{const1_rtx}, and so on, as appropriate.
@findex const_true_rtx
Similarly, there is only one object for the integer whose value is
diff --git a/gcc/rtl.h b/gcc/rtl.h
index 35178b5bfaca..5429b7a3f4ac 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -3768,10 +3768,135 @@ extern unsigned int split_all_insns_noflow (void);
#define MAX_SAVED_CONST_INT 64
extern GTY(()) rtx const_int_rtx[MAX_SAVED_CONST_INT * 2 + 1];
+#define constm64_rtx (const_int_rtx[MAX_SAVED_CONST_INT-64])
+#define constm63_rtx (const_int_rtx[MAX_SAVED_CONST_INT-63])
+#define constm62_rtx (const_int_rtx[MAX_SAVED_CONST_INT-62])
+#define constm61_rtx (const_int_rtx[MAX_SAVED_CONST_INT-61])
+#define constm60_rtx (const_int_rtx[MAX_SAVED_CONST_INT-60])
+#define constm59_rtx (const_int_rtx[MAX_SAVED_CONST_INT-59])
+#define constm58_rtx (const_int_rtx[MAX_SAVED_CONST_INT-58])
+#define constm57_rtx (const_int_rtx[MAX_SAVED_CONST_INT-57])
+#define constm56_rtx (const_int_rtx[MAX_SAVED_CONST_INT-56])
+#define constm55_rtx (const_int_rtx[MAX_SAVED_CONST_INT-55])
+#define constm54_rtx (const_int_rtx[MAX_SAVED_CONST_INT-54])
+#define constm53_rtx (const_int_rtx[MAX_SAVED_CONST_INT-53])
+#define constm52_rtx (const_int_rtx[MAX_SAVED_CONST_INT-52])
+#define constm51_rtx (const_int_rtx[MAX_SAVED_CONST_INT-51])
+#define constm50_rtx (const_int_rtx[MAX_SAVED_CONST_INT-50])
+#define constm49_rtx (const_int_rtx[MAX_SAVED_CONST_INT-49])
+#define constm48_rtx (const_int_rtx[MAX_SAVED_CONST_INT-48])
+#define constm47_rtx (const_int_rtx[MAX_SAVED_CONST_INT-47])
+#define constm46_rtx (const_int_rtx[MAX_SAVED_CONST_INT-46])
+#define constm45_rtx (const_int_rtx[MAX_SAVED_CONST_INT-45])
+#define constm44_rtx (const_int_rtx[MAX_SAVED_CONST_INT-44])
+#define constm43_rtx (const_int_rtx[MAX_SAVED_CONST_INT-43])
+#define constm42_rtx (const_int_rtx[MAX_SAVED_CONST_INT-42])
+#define constm41_rtx (const_int_rtx[MAX_SAVED_CONST_INT-41])
+#define constm40_rtx (const_int_rtx[MAX_SAVED_CONST_INT-40])
+#define constm39_rtx (const_int_rtx[MAX_SAVED_CONST_INT-39])
+#define constm38_rtx (const_int_rtx[MAX_SAVED_CONST_INT-38])
+#define constm37_rtx (const_int_rtx[MAX_SAVED_CONST_INT-37])
+#define constm36_rtx (const_int_rtx[MAX_SAVED_CONST_INT-36])
+#define constm35_rtx (const_int_rtx[MAX_SAVED_CONST_INT-35])
+#define constm34_rtx (const_int_rtx[MAX_SAVED_CONST_INT-34])
+#define constm33_rtx
[Bug c++/100847] M1 chip: many functions not declared in "std" or "::"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100847
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #2 from Andrew Pinski ---
I was able to compile and test GCC myself with the following options:
apinski@Andrews-Mac-mini ~ % ~/upstream-gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/Users/apinski/upstream-gcc/bin/gcc
COLLECT_LTO_WRAPPER=/Users/apinski/upstream-gcc/libexec/gcc/aarch64-apple-darwin20.4.0/11.0.1/lto-wrapper
Target: aarch64-apple-darwin20.4.0
Configured with: /Users/apinski/src/upstream-gcc-macosx/gcc/configure
--prefix=/Users/apinski/upstream-gcc
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210417 (experimental) (GCC)
apinski@Andrews-Mac-mini ~ % ~/upstream-gcc/bin/g++ t.c
apinski@Andrews-Mac-mini ~ % ./a.out
Hello World.
apinski@Andrews-Mac-mini ~ % cat t.c
#include
int main(void)
{
std::cout << "Hello World.\n";
}
Re: [PATCH] MAINTAINERS: create DCO section; add myself to it
On June 1, 2021 7:30:54 PM GMT+02:00, David Malcolm via Gcc wrote: >On Tue, 2021-06-01 at 10:00 -0400, David Edelsohn via Gcc wrote: >> GCC was created as part of the GNU Project but has grown to operate >> as >> an autonomous project. >> >> The GCC Steering Committee has decided to relax the requirement to >> assign copyright for all changes to the Free Software Foundation. >> GCC >> will continue to be developed, distributed, and licensed under the >> GNU >> General Public License v3.0. GCC will now accept contributions with >> or >> without an FSF copyright assignment. This change is consistent with >> the practices of many other major Free Software projects, such as the >> Linux kernel. >> >> Contributors who have an FSF Copyright Assignment don't need to >> change anything. Contributors who wish to utilize the Developer >> Certificate >> of Origin[1] should add a Signed-off-by message to their commit >> messages. >> Developers with commit access may add their name to the DCO list in >> the >> MAINTAINERS file to certify the DCO for all future commits in lieu of >> individual >> Signed-off-by messages for each commit. >> >> The GCC Steering Committee continues to affirm the principles of Free >> Software, and that will never change. >> >> - The GCC Steering Committee >> >> [1] https://developercertificate.org/ >> > >The MAINTAINERS file doesn't seem to have such a "DCO list" >yet; does the following patch look like what you had in mind? > >ChangeLog > > * MAINTAINERS: Create DCO section; add myself to it. >--- > MAINTAINERS | 12 > 1 file changed, 12 insertions(+) > >diff --git a/MAINTAINERS b/MAINTAINERS >index db25583b37b..1148e0915cf 100644 >--- a/MAINTAINERS >+++ b/MAINTAINERS >@@ -685,3 +685,15 @@ Josef Zlomek > > James Dennett > Christian Ehrhardt > Dara Hazeghi >+ >+ >+DCO >+=== >+ >+Developers with commit access may add their name to the following list >+to certify the DCO (https://developercertificate.org/) for all There should be a verbatim copy of the DCO in this file or the repository. >+future commits in lieu of individual Signed-off-by messages for each >commit. >+ >+ DCO list(last name alphabetical order) >+ >+David Malcolm
[Bug c++/100797] [10/11 Regression] using declaration causing virtual call with wrongly adjusted this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|10.4|9.4 --- Comment #10 from Jason Merrill --- Fixed for 9.4/10.4/11.2/12.
Re: [PATCH] Add gnu::diagnose_as attribute
On 5/28/21 3:42 AM, Matthias Kretz wrote:
On Friday, 28 May 2021 05:05:52 CEST Jason Merrill wrote:
On 5/27/21 6:07 PM, Matthias Kretz wrote:
On Thursday, 27 May 2021 23:15:46 CEST Jason Merrill wrote:
On 5/27/21 2:54 PM, Matthias Kretz wrote:
namespace Vir {
inline namespace foo {
struct A {};
}
struct A {};
}
using Vir::A;
:7:12: error: reference to 'A' is ambiguous
:3:12: note: candidates are: 'struct Vir::A'
:5:10: note: 'struct Vir::A'
That doesn't seem so bad.
As long as you ignore the line numbers, it's a puzzling diagnostic.
Only briefly puzzling, I think; Vir::A is a valid way of referring to
both types.
True. But that's also what lead to the error. GCC easily clears it up
nowadays, but wouldn't anymore if inline namespaces were hidden by default.
I'd think you could get the same effect from a hypothetical
namespace [[gnu::diagnose_as]] stdx = std::experimental;
though we'll need to add support for attributes on namespace aliases to
the grammar.
Right, but then two of my design goals can't be met:
1. Diagnostics have an improved signal-to-noise ratio out of the box.
2. We can use replacement names that are not valid identifiers.
This is the basic disconnect: I think that these goals are
contradictory, and that replacement names that are not valid identifiers
will just confuse users that don't know about them.
If a user sees stdx::foo in a diagnostic and then tries to refer to
stdx::foo and gets an error, the diagnostic is not more helpful than one
that uses the fully qualified name.
Jonathan, David, any thoughts on this issue?
I don't think libstdc++ would ship with a namespace alias outside of the std
namespace. So we'd place the "burden" of using diagnose_as correctly on our
users. Also as a user you'd possibly have to repeat the namespace alias in
every source file and/or place it in your applications/libraries namespace.
Here it seems like you want to say "use this typedef as the true name of
the type". Is it useful to have to repeat the name? Allowing people to
use names that don't correspond to actual declarations seems unnecessary.
Yes, but you could also use it to apply diagnose_as to a template
instantiation without introducing a name for users. E.g.
using __only_to_apply_the_attribute [[gnu::diagnose_as("intvector")]]
= std::vector;
Now all diagnostics of 'std::vector' would print 'intvector' instead.
Yes, but why would you want to? Making diagnostics print names that the
user can't use in their own code seems obfuscatory, and requiring users
to write the same names in two places seems like extra work.
I can imagine using it to make _Internal __names more readable while at the
same time discouraging users to utter them in their own code. Sorry for the
bad code obfuscation example above.
An example for consideration from stdx::simd:
namespace std {
namespace experimental {
namespace parallelism_v2 [[gnu::diagnose_as("stdx")]] {
namespace simd_abi [[gnu::diagnose_as("simd_abi")]] {
template
struct _VecBuiltin;
template
struct _VecBltnBtmsk;
#if x86
using __ignore_me_0 [[gnu::diagnose_as("[SSE]")]] = _VecBuiltin<16>;
using __ignore_me_1 [[gnu::diagnose_as("[AVX]")]] = _VecBuiltin<32>;
using __ignore_me_2 [[gnu::diagnose_as("[AVX512]")]] = _VecBltnBtmsk<64>;
#endif
Then diagnostics would print 'stdx::simd' instead
of 'stdx::simd>'. (Users utter the type by
saying e.g. 'stdx::native_simd', while compiling with AVX512 flags.)
Wouldn't it be better to print stdx::native_simd if that's how
the users write the type?
But in general, I tend to agree, for type aliases there's rarely a case
where the names wouldn't match.
However, I didn't want to special-case the attribute parameters for type
aliases (or introduce another attribute just for this case). The attribute
works consistently and with the same interface independent of where it's
used. I tried to build a generic, broad feature instead of a narrow
one-problem solution.
"Treat this declaration as the name of the type/namespace it refers to
in diagnostics" also seems consistent to me.
Sure. In general, I think
namespace foo [[gnu::this_is_the_name_I_want]] = bar;
using foo [[gnu::this_is_the_name_I_want]] = bar;
is not a terribly bad idea on its own. But it's not the solution for the
problems I set out to solve.
Still, perhaps it would be better to store these aliases in a separate hash
table instead of *_ATTRIBUTES.
Maybe. For performance reasons or for simplification of the implementation?
I was thinking for not messing with the type after it's defined, but
there are other things that do that (such as lazy declaration of
implicit constructors) so I wouldn't worry about it.
Jason
Re: [PATCH 1/2] c-family: Copy DECL_USER_ALIGN even if DECL_ALIGN is similar.
On 6/1/21 9:20 AM, Robin Dapp wrote: As you say, the logic is convoluted. Let's simplify it rather than make it more convoluted. One possibility would be to change || to | to avoid the shortcut, and then bool note = lastalign > curalign; if (note) curalign = lastalign; I went with your suggestion in the attached v2. Regtested and bootstrapped on s390x, x86 and ppc64le. OK. Jason
Re: [PATCH] c++: value init vs zero init in expand_aggr_init_1 [PR65816]
On 6/1/21 1:37 PM, Patrick Palka wrote:
In the case of value-initializing an object of class type T,
[dcl.init.general]/8 says:
- if T has either no default constructor ([class.default.ctor]) or
a default constructor that is user-provided or deleted, then the
object is default-initialized;
- otherwise, the object is zero-initialized and ... if T has a
non-trivial default constructor, the object is default-initialized;
But when determining whether to first zero-initialize the object,
expand_aggr_init_1 incorrectly looks for _any_ user provided
constructor, not just for a user-provided _default_ constructor. This
causes us to incorrectly skip the zero-initialization step when the
class type has a trivial default constructor alongside another
user-defined constructor.
It seems the predicate type_has_non_user_provided_default_constructor
accurately captures the above rule for when to first perform a
zero-initialization during value-initialization, so this patch corrects
the check in expand_aggr_init_1 using this predicate instead.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
PR c++/65816
gcc/cp/ChangeLog:
* init.c (expand_aggr_init_1): Check
type_has_non_user_provided_default_constructor instead of
type_has_user_provided_constructor.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-delegating3.C: New test.
* g++.dg/cpp0x/dc10.C: New test.
* g++.dg/cpp0x/initlist-base4.C: New test.
* g++.dg/cpp2a/constexpr-init22.C: New test.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/deque/allocator/default_init.cc,
testsuite/23_containers/forward_list/allocator/default_init.cc,
testsuite/23_containers/list/allocator/default_init.cc,
testsuite/23_containers/map/allocator/default_init.cc,
testsuite/23_containers/set/allocator/default_init.cc,
testsuite/23_containers/vector/allocator/default_init.cc,
testsuite/23_containers/vector/bool/allocator/default_init.cc:
Remove xfail.
---
gcc/cp/init.c | 4 +--
.../g++.dg/cpp0x/constexpr-delegating3.C | 10 +++
gcc/testsuite/g++.dg/cpp0x/dc10.C | 19 ++
gcc/testsuite/g++.dg/cpp0x/initlist-base4.C | 26 +++
gcc/testsuite/g++.dg/cpp2a/constexpr-init22.C | 14 ++
.../deque/allocator/default_init.cc | 1 -
.../forward_list/allocator/default_init.cc| 1 -
.../list/allocator/default_init.cc| 1 -
.../map/allocator/default_init.cc | 1 -
.../set/allocator/default_init.cc | 1 -
.../vector/allocator/default_init.cc | 1 -
.../vector/bool/allocator/default_init.cc | 1 -
12 files changed, 71 insertions(+), 9 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-delegating3.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/dc10.C
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist-base4.C
create mode 100644 gcc/testsuite/g++.dg/cpp2a/constexpr-init22.C
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index a85f4d50750..7aba5c60b32 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -2078,9 +2078,9 @@ expand_aggr_init_1 (tree binfo, tree true_exp, tree exp,
tree init, int flags,
that's value-initialization. */
if (init == void_type_node)
{
- /* If the type has data but no user-provided ctor, we need to zero
+ /* If the type has data but no user-provided default ctor, we need to
zero
out the object. */
- if (!type_has_user_provided_constructor (type)
+ if (type_has_non_user_provided_default_constructor (type)
&& !is_really_empty_class (type, /*ignore_vptr*/true))
{
tree field_size = NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-delegating3.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-delegating3.C
new file mode 100644
index 000..2263ec89488
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-delegating3.C
@@ -0,0 +1,10 @@
+// PR c++/65816
+// { dg-do compile { target c++11 } }
+
+struct test {
+ int m;
+ test() = default;
+ constexpr test(int) : test() {}
+};
+
+static_assert(test(0).m == 0, "");
diff --git a/gcc/testsuite/g++.dg/cpp0x/dc10.C
b/gcc/testsuite/g++.dg/cpp0x/dc10.C
new file mode 100644
index 000..c008a1703e8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/dc10.C
@@ -0,0 +1,19 @@
+// PR c++/65816
+// { dg-do run { target c++11 } }
+
+void* operator new(decltype(sizeof(int)), void* ptr) { return ptr; }
+
+struct test {
+ int i;
+ test() = default;
+ test(int) : test() {}
+};
+
+int main() {
+ alignas(test) unsigned char space[sizeof(test)];
+ for (auto& c : space) c = 0xff;
+
+ auto ptr = ::new() test(42);
+ int& i = static_cast(*ptr).i;
+ if (i != 0) __builtin_abort();
+}
diff --git a/gcc/testsuite/g++.dg/cpp0x/initlist-base4.C
[Bug fortran/86115] move_alloc for class(*) containing value of type character(len=*) looses data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86115 --- Comment #3 from anlauf at gcc dot gnu.org --- Looking at the dump tree, it appears that the _vptr component is properly copied, but the _len component is not. But this one is needed for unlimited polymorphics.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 Peter Bergner changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-01 --- Comment #2 from Peter Bergner --- (In reply to Alexander Grund from comment #1) > Confirmed to also break with GCC 7.3, 8.2, 8.3 but works with 6.3, 6.4, 6.5 The failure with GCC 7 and later coincides with the PPC port starting to default to LRA instead of reload. If I look at the debug dumps compiling dgebal.f, the 440 offset to the stack is created by an LRA spill. No problem there that I can see. The problem seems to come later when we generate the prologue/epilogue and we only update the stack pointer by the smaller 368 byte offset. Either LRA isn't telling us it needs that extra stack space or the ppc backend didn't notice. I'll keep digging.
[PATCH] Improve match_simplify_replacement in phi-opt
From: Andrew Pinski
This improves match_simplify_replace in phi-opt to handle the
case where there is one cheap preparation statement in the
middle basic block similar to xor_replacement and others.
This allows to remove xor_replacement too.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimization/25290
* tree-ssa-phiopt.c (xor_replacement): Delete.
(tree_ssa_phiopt_worker): Delete use of xor_replacement.
(match_simplify_replacement): Allow one cheap preparation
statement that can be moved to before the if.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr96928-1.c: Fix testcase for now that ~
happens on the outside of the bit_xor.
---
gcc/testsuite/gcc.dg/tree-ssa/pr96928-1.c | 4 +-
gcc/tree-ssa-phiopt.c | 136 +-
2 files changed, 28 insertions(+), 112 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr96928-1.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr96928-1.c
index a2770e5e896..2e86620da11 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr96928-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr96928-1.c
@@ -1,9 +1,9 @@
/* PR tree-optimization/96928 */
/* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-phiopt2" } */
+/* { dg-options "-O2 -fdump-tree-phiopt2 -fdump-tree-optimized" } */
/* { dg-final { scan-tree-dump-times " = a_\[0-9]*\\\(D\\\) >> " 5 "phiopt2" }
} */
/* { dg-final { scan-tree-dump-times " = ~c_\[0-9]*\\\(D\\\);" 1 "phiopt2" } }
*/
-/* { dg-final { scan-tree-dump-times " = ~" 1 "phiopt2" } } */
+/* { dg-final { scan-tree-dump-times " = ~" 1 "optimized" } } */
/* { dg-final { scan-tree-dump-times " = \[abc_0-9\\\(\\\)D]* \\\^ " 5
"phiopt2" } } */
/* { dg-final { scan-tree-dump-not "a < 0" "phiopt2" } } */
diff --git a/gcc/tree-ssa-phiopt.c b/gcc/tree-ssa-phiopt.c
index 969b868397e..4f98e505029 100644
--- a/gcc/tree-ssa-phiopt.c
+++ b/gcc/tree-ssa-phiopt.c
@@ -63,8 +63,6 @@ static bool minmax_replacement (basic_block, basic_block,
edge, edge, gphi *, tree, tree);
static bool abs_replacement (basic_block, basic_block,
edge, edge, gphi *, tree, tree);
-static bool xor_replacement (basic_block, basic_block,
-edge, edge, gphi *, tree, tree);
static bool spaceship_replacement (basic_block, basic_block,
edge, edge, gphi *, tree, tree);
static bool cond_removal_in_popcount_clz_ctz_pattern (basic_block, basic_block,
@@ -352,9 +350,6 @@ tree_ssa_phiopt_worker (bool do_store_elim, bool
do_hoist_loads, bool early_p)
cfgchanged = true;
else if (abs_replacement (bb, bb1, e1, e2, phi, arg0, arg1))
cfgchanged = true;
- else if (!early_p
- && xor_replacement (bb, bb1, e1, e2, phi, arg0, arg1))
- cfgchanged = true;
else if (!early_p
&& cond_removal_in_popcount_clz_ctz_pattern (bb, bb1, e1,
e2, phi, arg0,
@@ -801,9 +796,23 @@ match_simplify_replacement (basic_block cond_bb,
basic_block middle_bb,
edge true_edge, false_edge;
gimple_seq seq = NULL;
tree result;
+ gimple *stmt_to_move = NULL;
+ /* If the basic block only has a cheap preparation statement. */
if (!empty_block_p (middle_bb))
-return false;
+{
+ stmt_to_move = last_and_only_stmt (middle_bb);
+ if (!stmt_to_move)
+ return false;
+ if (gimple_could_trap_p (stmt_to_move)
+ || gimple_has_side_effects (stmt_to_move))
+ return false;
+ if ((!is_gimple_assign (stmt_to_move)
+ || TREE_CODE (gimple_assign_lhs (stmt_to_move)) != SSA_NAME)
+ && (!is_gimple_call (stmt_to_move)
+ || !gimple_inexpensive_call_p (as_a (stmt_to_move
+ return false;
+}
/* Special case A ? B : B as this will always simplify to B. */
if (operand_equal_for_phi_arg_p (arg0, arg1))
@@ -844,7 +853,17 @@ match_simplify_replacement (basic_block cond_bb,
basic_block middle_bb,
return false;
gsi = gsi_last_bb (cond_bb);
-
+ if (stmt_to_move)
+{
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ {
+ fprintf (dump_file, "statement un-sinked:\n");
+ print_gimple_stmt (dump_file, stmt_to_move, 0,
+ TDF_VOPS|TDF_MEMSYMS);
+ }
+ gimple_stmt_iterator gsi1 = gsi_for_stmt (stmt_to_move);
+ gsi_move_before (, );
+}
if (seq)
gsi_insert_seq_before (, seq, GSI_SAME_STMT);
@@ -2592,109 +2611,6 @@ abs_replacement (basic_block cond_bb, basic_block
middle_bb,
return true;
}
-/* Optimize x < 0 ? ~y : y into (x >> (prec-1)) ^ y. */
-
-static bool
-xor_replacement (basic_block cond_bb, basic_block middle_bb,
-edge e0 ATTRIBUTE_UNUSED, edge e1,
-gphi *phi, tree arg0, tree arg1)
-{
- if (!INTEGRAL_TYPE_P (TREE_TYPE
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 --- Comment #18 from Andrew Pinski --- (In reply to CVS Commits from comment #17) Note this is the only start of the patches, this is not fully fixed, it is being worked on in a series of patches rather than one big one.
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 --- Comment #17 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:9f55df63154a39d67ef5b24def7044bf87300831 commit r12-1152-g9f55df63154a39d67ef5b24def7044bf87300831 Author: Andrew Pinski Date: Tue Jun 1 01:05:09 2021 + Replace conditional_replacement with match and simplify This is the first of series of patches to simplify phi-opt to use match and simplify in many cases. This simplification will more things to optimize. This is what Richard requested in https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571197.html and I think it is the right thing to do too. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: PR tree-optimization/25290 * tree-ssa-phiopt.c (match_simplify_replacement): New function. (tree_ssa_phiopt_worker): Use match_simplify_replacement. (two_value_replacement): Change the comment about conditional_replacement. (conditional_replacement): Delete.
[Bug fortran/100860] class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 --- Comment #2 from Dominique d'Humieres --- WORKSFORME from GCC7 up to trunk.
[Bug tree-optimization/95481] Failure to optimize infinite recursion for empty struct types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95481 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 --- Comment #5 from Andrew Pinski --- Fixed.
[Bug tree-optimization/95481] Failure to optimize infinite recursion for empty struct types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95481 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:ea418485c700494c3efdc282854c5f5a08702416 commit r12-1151-gea418485c700494c3efdc282854c5f5a08702416 Author: Andrew Pinski Date: Mon May 31 00:17:22 2021 + Fix PR 95481: tail call fails with empty struct types The problem here is we don't have an assignment type any more for empty structs as they were removed during gimplifcation. This adds a special case where the assignment var does not exist and the return decl is empty typed. OK? Tested on aarch64-linux-gnu with no regressions. Thanks, Andrew Pinski changes since v1: v2: Use is_empty_type instead of zero-sized type. gcc/ChangeLog: PR tree-optimization/95481 * tree-tailcall.c (find_tail_calls): Handle empty typed return decls. gcc/testsuite/ChangeLog: PR tree-optimization/95481 * gcc.dg/tree-ssa/tailcall-10.c: New test. * gcc.dg/tree-ssa/tailcall-11.c: New test. * gcc.dg/tree-ssa/tailcall-12.c: New test. * gcc.dg/tree-ssa/tailcall-13.c: New test. * gcc.dg/tree-ssa/tailrecursion-8.c: New test.
[Bug fortran/86115] move_alloc for class(*) containing value of type character(len=*) looses data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86115 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Keywords||wrong-code Last reconfirmed|2018-06-13 00:00:00 |2021-6-1 --- Comment #2 from anlauf at gcc dot gnu.org --- Adding print *, 'string length: ', len (z) in subroutine p prints string length 0.
[Bug fortran/100860] class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-06-01 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Possibly related to pr100551, which was fixed after the 11.1 release. I do not see the issue with the current mainline or 11-branch version. Can you please check?
Re: [PATCH] Hashtable PR96088
On 01/06/21 18:47 +0100, Jonathan Wakely wrote:
On 01/06/21 18:45 +0100, Jonathan Wakely wrote:
On 22/05/21 18:35 +0200, François Dumont wrote:
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
b/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
new file mode 100644
index 000..53bb754dab6
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
@@ -0,0 +1,271 @@
+// { dg-do run { target c++11 } }
+
+// Copyright (C) 2021 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
+//
Re: [PATCH] PR libstdc++/89728 diagnose some missuses of [locale.convenience] functions
On 17/05/21 18:14 +0100, Jonathan Wakely wrote:
On 12/05/21 17:16 +0100, Jonathan Wakely wrote:
On 12/05/21 18:51 +0300, Antony Polukhin via Libstdc++ wrote:
ср, 12 мая 2021 г. в 18:38, Antony Polukhin :
ср, 12 мая 2021 г. в 17:44, Jonathan Wakely :
On 12/05/21 12:58 +0300, Antony Polukhin wrote:
ср, 12 мая 2021 г. в 12:18, Jonathan Wakely :
<...>
Or just leave it undefined, as libc++ seems to do according to your
comment in PR 89728:
error: implicit instantiation of undefined template
'std::__1::ctype >'
Was your aim to have a static_assert that gives a more descriptive
error? We could leave it undefined in C++98 and have the static assert
for C++11 and up.
Leaving it undefined would be the best. It would allow SFINAE on ctype
and a compile time error is informative enough.
However, there may be users who instantiate ctype in a
shared library without ctype template specializations in
the main executable. Making the default ctype undefined would break
their compilation:
#include
// no ctype specialization
c = std::tolower(ThierChar{42}, locale_from_shared_library()); // OK
right now in libstdc++, fails on libc++
What I meant was leaving the partial specialization undefined, not the
primary template, i.e.
--- a/libstdc++-v3/include/bits/locale_facets.h
+++ b/libstdc++-v3/include/bits/locale_facets.h
@@ -1476,6 +1476,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
#endif //_GLIBCXX_USE_WCHAR_T
+ template
+class ctype >;
+
/// class ctype_byname [22.2.1.2].
template
class ctype_byname : public ctype<_CharT>
This makes your test fail with errors like this:
In file included from /home/jwakely/gcc/12/include/c++/12.0.0/locale:40,
from loc.C:1:
/home/jwakely/gcc/12/include/c++/12.0.0/bits/locale_facets.h: In instantiation of 'bool
std::isspace(_CharT, const std::locale&) [with _CharT =
std::__cxx11::basic_string]':
loc.C:16:15: required from here
/home/jwakely/gcc/12/include/c++/12.0.0/bits/locale_facets.h:2600:47: error: invalid use of
incomplete type 'const class std::ctype >'
2600 | { return use_facet >(__loc).is(ctype_base::space,
__c); }
| ~^~
But it shouldn't affect the uses of ctype.
What do you think?
Good idea. That way the compiler message points directly to the
misused function.
Patch is in attachment
Replaced {} with () in test to be C++98 compatible
Looks great, thanks.
I'll test and commit this tomorrow.
Not quite "tomorrow", but it's pushed to trunk now. Thanks again!
I've also pushed this fix for the new test, so it passes with
-std=gnu++98.
Tested x86_64-linux.
commit b514fce354b5309a9c232a3fe9347e3abde4385f
Author: Jonathan Wakely
Date: Tue Jun 1 19:01:37 2021
libstdc++: Fix new test for C++98 mode [PR 89728]
The isblank class is not supported until C++11.
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* testsuite/22_locale/ctype/is/string/89728_neg.cc: Only test
isblank for C++11 and later.
diff --git a/libstdc++-v3/testsuite/22_locale/ctype/is/string/89728_neg.cc b/libstdc++-v3/testsuite/22_locale/ctype/is/string/89728_neg.cc
index 9f15620c9a8..89843b68494 100644
--- a/libstdc++-v3/testsuite/22_locale/ctype/is/string/89728_neg.cc
+++ b/libstdc++-v3/testsuite/22_locale/ctype/is/string/89728_neg.cc
@@ -45,7 +45,9 @@ void test01()
std::isxdigit(make_str(), loc); // { dg-error "required from here" }
std::isalnum(make_str(), loc); // { dg-error "required from here" }
std::isgraph(make_str(), loc); // { dg-error "required from here" }
- std::isblank(make_str(), loc); // { dg-error "required from here" }
+#if __cplusplus >= 201103
+ std::isblank(make_str(), loc); // { dg-error "required from here" "" { target c++11 } }
+#endif
std::toupper(make_str(), loc); // { dg-error "required from here" }
std::tolower(make_str(), loc); // { dg-error "required from here" }
}
@@ -66,7 +68,9 @@ void test02()
std::isxdigit(make_str(), loc); // { dg-error "required from here" }
std::isalnum(make_str(), loc); // { dg-error "required from here" }
std::isgraph(make_str(), loc); // { dg-error "required from here" }
- std::isblank(make_str(), loc); // { dg-error "required from here" }
+#if __cplusplus >= 201103
+ std::isblank(make_str(), loc); // { dg-error "required from here" "" { target c++11 } }
+#endif
std::toupper(make_str(), loc); // { dg-error "required from here" }
std::tolower(make_str(), loc); // { dg-error "required from here" }
}
Re: [PATCH] icf: Fix memory leak of a vector.
On 6/1/2021 8:28 AM, Martin Liška wrote: Simple leak fix. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/ChangeLog: * ipa-icf.h: Use auto_vec for memory_access_types. OK jeff
Re: [PATCH] Hashtable PR96088
On 01/06/21 18:45 +0100, Jonathan Wakely wrote:
On 22/05/21 18:35 +0200, François Dumont wrote:
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
b/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
new file mode 100644
index 000..53bb754dab6
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
@@ -0,0 +1,271 @@
+// { dg-do run { target c++11 } }
+
+// Copyright (C) 2021 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
+//
Re: [PATCH] Hashtable PR96088
On 22/05/21 18:35 +0200, François Dumont wrote:
diff --git a/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
b/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
new file mode 100644
index 000..53bb754dab6
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/unordered_set/96088.cc
@@ -0,0 +1,271 @@
+// { dg-do run { target c++11 } }
+
+// Copyright (C) 2021 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
+//
