[PATCH] Fix VEC_COND_EXPR expansion ICE (PR middle-end/91623)
Hi!
The following testcase ICEs, because for SSE4.1 only VEC_COND_EXPRs with
EQ_EXPR/NE_EXPR are supported and vectorizer generates such VEC_COND_EXPR,
but later on the condition is folded into a VECTOR_CST and the VEC_COND_EXPR
expansion code expands non-comparison conditions as LT_EXPR against zero
vector.
I think the only problematic case is when the equality comparison is folded
into a constant; at that point, if both other VEC_COND_EXPR arguments are
constant, we could in theory fold it (but can't really rely on it during
expansion anyway), but if they aren't constant, just the condition is, there
is nothing to fold it into anyway. The patch verifies that LT_EXPR against
zero will behave the same as NE_EXPR by punting if there are non-canonical
elements (> 0), otherwise just tries to expand it as NE_EXPR if LT_EXPR
didn't work.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2019-09-01 Jakub Jelinek
PR middle-end/91623
* optabs.c (expand_vec_cond_expr): If op0 is a VECTOR_CST and only
EQ_EXPR/NE_EXPR is supported, verify that op0 only contains
zeros or negative elements and use NE_EXPR instead of LT_EXPR against
zero vector.
* gcc.target/i386/pr91623.c: New test.
--- gcc/optabs.c.jj 2019-08-27 12:26:37.392912813 +0200
+++ gcc/optabs.c2019-08-31 19:49:32.831430056 +0200
@@ -5868,6 +5868,25 @@ expand_vec_cond_expr (tree vec_cond_type
icode = get_vcond_icode (mode, cmp_op_mode, unsignedp);
if (icode == CODE_FOR_nothing)
{
+ if (tcode == LT_EXPR
+ && op0a == op0
+ && TREE_CODE (op0) == VECTOR_CST)
+ {
+ /* A VEC_COND_EXPR condition could be folded from EQ_EXPR/NE_EXPR
+into a constant when only get_vcond_eq_icode is supported.
+Verify < 0 and != 0 behave the same and change it to NE_EXPR. */
+ unsigned HOST_WIDE_INT nelts;
+ if (!VECTOR_CST_NELTS (op0).is_constant (&nelts))
+ {
+ if (VECTOR_CST_STEPPED_P (op0))
+ return 0;
+ nelts = vector_cst_encoded_nelts (op0);
+ }
+ for (unsigned int i = 0; i < nelts; ++i)
+ if (tree_int_cst_sgn (vector_cst_elt (op0, i)) == 1)
+ return 0;
+ tcode = NE_EXPR;
+ }
if (tcode == EQ_EXPR || tcode == NE_EXPR)
icode = get_vcond_eq_icode (mode, cmp_op_mode);
if (icode == CODE_FOR_nothing)
--- gcc/testsuite/gcc.target/i386/pr91623.c.jj 2019-08-31 19:55:02.470674149
+0200
+++ gcc/testsuite/gcc.target/i386/pr91623.c 2019-08-31 19:54:39.186010098
+0200
@@ -0,0 +1,32 @@
+/* PR middle-end/91623 */
+/* { dg-do compile } */
+/* { dg-options "-O3 -msse4.1 -mno-sse4.2" } */
+
+typedef long long V __attribute__((__vector_size__(16)));
+V e, h;
+int d;
+const int i;
+
+void foo (void);
+
+void
+bar (int k, int l)
+{
+ if (d && 0 <= k - 1 && l)
+foo ();
+}
+
+void
+baz (void)
+{
+ V n = (V) { 1 };
+ V g = (V) {};
+ V o = g;
+ for (int f = 0; f < i; ++f)
+{
+ V a = o == n;
+ h = a;
+ bar (f, i);
+ o = e;
+}
+}
Jakub
Re: [PATCH] Fix VEC_COND_EXPR expansion ICE (PR middle-end/91623)
On September 1, 2019 12:19:51 PM GMT+02:00, Jakub Jelinek
wrote:
>Hi!
>
>The following testcase ICEs, because for SSE4.1 only VEC_COND_EXPRs
>with
>EQ_EXPR/NE_EXPR are supported and vectorizer generates such
>VEC_COND_EXPR,
>but later on the condition is folded into a VECTOR_CST and the
>VEC_COND_EXPR
>expansion code expands non-comparison conditions as LT_EXPR against
>zero
>vector.
>
>I think the only problematic case is when the equality comparison is
>folded
>into a constant; at that point, if both other VEC_COND_EXPR arguments
>are
>constant, we could in theory fold it (but can't really rely on it
>during
>expansion anyway), but if they aren't constant, just the condition is,
>there
>is nothing to fold it into anyway. The patch verifies that LT_EXPR
>against
>zero will behave the same as NE_EXPR by punting if there are
>non-canonical
>elements (> 0), otherwise just tries to expand it as NE_EXPR if LT_EXPR
>didn't work.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
>2019-09-01 Jakub Jelinek
>
> PR middle-end/91623
> * optabs.c (expand_vec_cond_expr): If op0 is a VECTOR_CST and only
> EQ_EXPR/NE_EXPR is supported, verify that op0 only contains
> zeros or negative elements and use NE_EXPR instead of LT_EXPR against
> zero vector.
>
> * gcc.target/i386/pr91623.c: New test.
>
>--- gcc/optabs.c.jj2019-08-27 12:26:37.392912813 +0200
>+++ gcc/optabs.c 2019-08-31 19:49:32.831430056 +0200
>@@ -5868,6 +5868,25 @@ expand_vec_cond_expr (tree vec_cond_type
> icode = get_vcond_icode (mode, cmp_op_mode, unsignedp);
> if (icode == CODE_FOR_nothing)
> {
>+ if (tcode == LT_EXPR
>+&& op0a == op0
>+&& TREE_CODE (op0) == VECTOR_CST)
>+ {
>+/* A VEC_COND_EXPR condition could be folded from EQ_EXPR/NE_EXPR
>+ into a constant when only get_vcond_eq_icode is supported.
>+ Verify < 0 and != 0 behave the same and change it to NE_EXPR.
>*/
>+unsigned HOST_WIDE_INT nelts;
>+if (!VECTOR_CST_NELTS (op0).is_constant (&nelts))
>+ {
>+if (VECTOR_CST_STEPPED_P (op0))
>+ return 0;
>+nelts = vector_cst_encoded_nelts (op0);
>+ }
>+for (unsigned int i = 0; i < nelts; ++i)
>+ if (tree_int_cst_sgn (vector_cst_elt (op0, i)) == 1)
>+return 0;
>+tcode = NE_EXPR;
>+ }
> if (tcode == EQ_EXPR || tcode == NE_EXPR)
> icode = get_vcond_eq_icode (mode, cmp_op_mode);
> if (icode == CODE_FOR_nothing)
>--- gcc/testsuite/gcc.target/i386/pr91623.c.jj 2019-08-31
>19:55:02.470674149 +0200
>+++ gcc/testsuite/gcc.target/i386/pr91623.c2019-08-31
>19:54:39.186010098 +0200
>@@ -0,0 +1,32 @@
>+/* PR middle-end/91623 */
>+/* { dg-do compile } */
>+/* { dg-options "-O3 -msse4.1 -mno-sse4.2" } */
>+
>+typedef long long V __attribute__((__vector_size__(16)));
>+V e, h;
>+int d;
>+const int i;
>+
>+void foo (void);
>+
>+void
>+bar (int k, int l)
>+{
>+ if (d && 0 <= k - 1 && l)
>+foo ();
>+}
>+
>+void
>+baz (void)
>+{
>+ V n = (V) { 1 };
>+ V g = (V) {};
>+ V o = g;
>+ for (int f = 0; f < i; ++f)
>+{
>+ V a = o == n;
>+ h = a;
>+ bar (f, i);
>+ o = e;
>+}
>+}
>
> Jakub
[PATCH] Fix PR 91605
Hi,
this fixes an oversight in r274986.
We need to avoid using movmisalign on DECL_P which are not in memory,
similar to the !mem_ref_refers_to_non_mem_p which unfortunately can't
handle DECL_P.
Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2019-09-01 Bernd Edlinger
PR middle-end/91605
* expr.c (expand_assignment): Avoid DECL_P with DECL_RTL
not being MEM_P.
testsuite:
2019-09-01 Bernd Edlinger
PR middle-end/91605
* g++.target/i386/pr91605.C: New test.
Index: gcc/expr.c
===
--- gcc/expr.c (revision 275063)
+++ gcc/expr.c (working copy)
@@ -5004,7 +5004,8 @@ expand_assignment (tree to, tree from, bool nontem
|| TREE_CODE (to) == TARGET_MEM_REF
|| DECL_P (to))
&& mode != BLKmode
- && (DECL_P (to) || !mem_ref_refers_to_non_mem_p (to))
+ && (DECL_P (to) ? MEM_P (DECL_RTL (to))
+ : !mem_ref_refers_to_non_mem_p (to))
&& ((align = get_object_alignment (to))
< GET_MODE_ALIGNMENT (mode))
&& (((icode = optab_handler (movmisalign_optab, mode))
Index: gcc/testsuite/g++.target/i386/pr91605.C
===
--- gcc/testsuite/g++.target/i386/pr91605.C (revision 0)
+++ gcc/testsuite/g++.target/i386/pr91605.C (working copy)
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-fpack-struct -mavx" } */
+
+struct A {
+ __attribute__((__vector_size__(4 * sizeof(double double data;
+};
+struct B {
+ A operator*(B);
+};
+void fn1() {
+ B x, y;
+ x *y;
+}
[v3] Update Solaris baselines for GCC 10.0
Here's are the updates to the Solaris libstdc++ baselines on mainline. Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. Ok for mainline? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University 2019-08-30 Rainer Orth * config/abi/post/i386-solaris/baseline_symbols.txt: Regenerate. * config/abi/post/i386-solaris/amd64/baseline_symbols.txt: Likewise. * config/abi/post/sparc-solaris/baseline_symbols.txt: Likewise. * config/abi/post/sparc-solaris/sparcv9/baseline_symbols.txt: Likewise. # HG changeset patch # Parent 422a77d3be7e6f443de8d5a44270e22a2b8289e9 Update Solaris baselines for GCC 10.0 diff --git a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt --- a/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt +++ b/libstdc++-v3/config/abi/post/i386-solaris/amd64/baseline_symbols.txt @@ -1804,6 +1804,7 @@ FUNC:_ZNSt10filesystem28recursive_direct FUNC:_ZNSt10filesystem28recursive_directory_iteratorD1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem28recursive_directory_iteratorD2Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem28recursive_directory_iteratoraSEOS0_@@GLIBCXX_3.4.26 +FUNC:_ZNSt10filesystem28recursive_directory_iteratoraSERKS0_@@GLIBCXX_3.4.27 FUNC:_ZNSt10filesystem28recursive_directory_iteratorppEv@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem4copyERKNS_4pathES2_NS_12copy_optionsE@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem4copyERKNS_4pathES2_NS_12copy_optionsERSt10error_code@@GLIBCXX_3.4.26 @@ -1860,6 +1861,7 @@ FUNC:_ZNSt10filesystem7__cxx1128recursiv FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorD1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorD2Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSEOS1_@@GLIBCXX_3.4.26 +FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSERKS1_@@GLIBCXX_3.4.27 FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorppEv@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem7__cxx114path14_S_convert_locEPKcS3_RKSt6locale@@GLIBCXX_3.4.26 @@ -2031,13 +2033,21 @@ FUNC:_ZNSt12__basic_fileIcED1Ev@@GLIBCXX FUNC:_ZNSt12__basic_fileIcED2Ev@@GLIBCXX_3.4 FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 +FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28 +FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 +FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS4_@@GLIBCXX_3.4.28 +FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 +FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2EOS6_@@GLIBCXX_3.4.28 +FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 +FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28 +FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26 FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15 FUNC:_ZNSt12bad_weak_ptrD1Ev@@GLIBCXX_3.4.15 @@ -4363,6 +4373,8 @@ OBJECT:0:GLIBCXX_3.4.23 OBJECT:0:GLIBCXX_3.4.24 OBJECT:0:GLIBCXX_3.4.25 OBJECT:0:GLIBCXX_3.4.26 +OBJECT:0:GLIBCXX_3.4.27 +OBJECT:0:GLIBCXX_3.4.28 OBJECT:0:GLIBCXX_3.4.3 OBJECT:0:GLIBCXX_3.4.4 OBJECT:0:GLIBCXX_3.4.5 diff --git a/libstdc++-v3/config/abi/post/i386-solaris/baseline_symbols.txt b/libs
[COMMITTED] Fix wrong dates in ChangeLog
Hi, this fixes a mistake I made (and a few others as well): using the wrong month in the ChangeLog. Committed as obvious. $ svn diff -r275264:275265 Index: ChangeLog === --- ChangeLog (revision 275264) +++ ChangeLog (revision 275265) @@ -171,7 +171,7 @@ * config/i386/i386-features.c (convert_scalars_to_vector): Do not add the MD problem. -2019-09-28 Bernd Edlinger +2019-08-28 Bernd Edlinger Richard Biener * expr.c (expand_assignment): Handle misaligned DECLs. @@ -2861,12 +2861,12 @@ * config/i386/mmx.md (usadv8qi): Use register_operand instead of vector_operand. -2019-09-09 Vladimir Makarov +2019-08-09 Vladimir Makarov * reload1.c (finish_spills): Do not check ira_conflicts_p when handling spilled pseudos. -2019-09-09 Richard Earnshaw +2019-08-09 Richard Earnshaw PR target/91386 * config/aarch64/aarch64.c (aarch64_gen_adjusted_ldpstp): Use copy_rtx Bernd.
[v3] Update Solaris baselines for GCC 9.3
And now the Solaris libstdc++ baseline updates for the gcc-9 branch. Tested on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01]. Ok for mainline? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University 2019-08-30 Rainer Orth * config/abi/post/i386-solaris2.10/baseline_symbols.txt: Regenerate. * config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt: Likewise. * config/abi/post/i386-solaris2.11/baseline_symbols.txt: Likewise. * config/abi/post/i386-solaris2.11/amd64/baseline_symbols.txt: Likewise. * config/abi/post/sparc-solaris2.10/baseline_symbols.txt: Likewise. * config/abi/post/sparc-solaris2.10/sparcv9/baseline_symbols.txt: Likewise. * config/abi/post/sparc-solaris2.11/baseline_symbols.txt: Likewise. * config/abi/post/sparc-solaris2.11/sparcv9/baseline_symbols.txt: Likewise. # HG changeset patch # Parent 0411a3c8a0851be4b6e497c1824b227af4ad6793 Update Solaris baselines for GCC 9.3 diff --git a/libstdc++-v3/config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt b/libstdc++-v3/config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt --- a/libstdc++-v3/config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt +++ b/libstdc++-v3/config/abi/post/i386-solaris2.10/amd64/baseline_symbols.txt @@ -1804,6 +1804,7 @@ FUNC:_ZNSt10filesystem28recursive_direct FUNC:_ZNSt10filesystem28recursive_directory_iteratorD1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem28recursive_directory_iteratorD2Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem28recursive_directory_iteratoraSEOS0_@@GLIBCXX_3.4.26 +FUNC:_ZNSt10filesystem28recursive_directory_iteratoraSERKS0_@@GLIBCXX_3.4.27 FUNC:_ZNSt10filesystem28recursive_directory_iteratorppEv@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem4copyERKNS_4pathES2_NS_12copy_optionsE@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem4copyERKNS_4pathES2_NS_12copy_optionsERSt10error_code@@GLIBCXX_3.4.26 @@ -1860,6 +1861,7 @@ FUNC:_ZNSt10filesystem7__cxx1128recursiv FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorD1Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorD2Ev@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSEOS1_@@GLIBCXX_3.4.26 +FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSERKS1_@@GLIBCXX_3.4.27 FUNC:_ZNSt10filesystem7__cxx1128recursive_directory_iteratorppEv@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem7__cxx114path14_M_split_cmptsEv@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem7__cxx114path14_S_convert_locEPKcS3_RKSt6locale@@GLIBCXX_3.4.26 @@ -2031,13 +2033,21 @@ FUNC:_ZNSt12__basic_fileIcED1Ev@@GLIBCXX FUNC:_ZNSt12__basic_fileIcED2Ev@@GLIBCXX_3.4 FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 +FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28 +FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 +FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS4_@@GLIBCXX_3.4.28 +FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27 FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 +FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2EOS6_@@GLIBCXX_3.4.28 +FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26 +FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_@@GLIBCXX_3.4.28 +FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2Ev@@GLIBCXX_3.4.27 FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26 FUNC:_ZNSt12bad_weak_ptrD0Ev@@GLIBCXX_3.4.15 FUNC:_ZNSt1
Re: [PATCH] Fix free_lang_data on asm stmts (PR lto/91572)
On Sat, Aug 31, 2019 at 03:02:18PM +0200, Richard Biener wrote: > Ok, but I wonder if we can stream the constraint strings in a simpler way - > surely the type doesn't really matter? > Why are they not identifier nodes? I guess they have type because they are parsed like any other string literals during parsing and once we parse them that way, it isn't worth changing them to something else like an identifier. Would it be enough to just clear their type during free lang data or something similar? Jakub
Re: [PATCH] Fix free_lang_data on asm stmts (PR lto/91572)
On September 1, 2019 1:55:14 PM GMT+02:00, Jakub Jelinek wrote: >On Sat, Aug 31, 2019 at 03:02:18PM +0200, Richard Biener wrote: >> Ok, but I wonder if we can stream the constraint strings in a simpler >way - surely the type doesn't really matter? >> Why are they not identifier nodes? > >I guess they have type because they are parsed like any other string >literals during parsing and once we parse them that way, it isn't worth >changing them to something else like an identifier. Hmm, so we accept wide-char literals as well here? >Would it be enough to just clear their type during free lang data or >something similar? I guess so. Maybe do that during gimplification already? Wonder how we pretty print asms then when we mangle their types. Note the original patch is OK as-is I just wondered why we bother to even keep the asm constrains as something different than a char *. Richard. > > Jakub
[libstdc++,doc] xml/manual/policy_data_structures_biblio.xml
microsoft.com redirects the existing link and changed the title of the document; this adjust both. Committed. Jonathan(?), if you could regenerate the libstdc++ online docs, that would be nice. Gerald 2019-09-01 Gerald Pfeifer * doc/xml/manual/policy_data_structures_biblio.xml (COM: Component Model Object Technologies): Adjust name and link. Index: doc/xml/manual/policy_data_structures_biblio.xml === --- doc/xml/manual/policy_data_structures_biblio.xml(revision 275243) +++ doc/xml/manual/policy_data_structures_biblio.xml(working copy) @@ -1062,7 +1062,7 @@ http://www.w3.org/1999/xlink"; - xlink:href="https://docs.microsoft.com/en-us/windows/desktop/com/the-component-object-model";> + xlink:href="https://docs.microsoft.com/en-us/windows/win32/com/the-component-object-model";> COM: Component Model Object Technologies
Re: [Patch, fortran] Implementation of F2018 SELECT RANK
Hi Steve, Thanks for the remarks and the OK. Committed as revision 275269. Onward to PDTs! Cheers Paul On Sat, 31 Aug 2019 at 18:46, Steve Kargl wrote: > > On Sat, Aug 31, 2019 at 04:59:03PM +0100, Paul Richard Thomas wrote: > > > > Bootstraps and regtests on FC29/x86_64 - OK for trunk? > > Well, I've made it through to the trans-* files. Reading > that part of the patch will take a awhile. I'm think you > should commit. > > -- > steve -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] PR fortran/91552 -- Walk array constructor to do type conversion
Hi Steve, OK to commit. Thanks Paul On Sat, 31 Aug 2019 at 21:16, Steve Kargl wrote: > > The attached patch has been built and tested on i586-*-freebsd > and x86_64-*-freebsd. OK to commit? > > The patch fixes an ICE during type conversion where an array > constructor contains another array. The new function recursively > walks the constructor, and tries to do the type conversion. > The testcase demonstrates the recursion. > > 2019-08-31 Steven G. Kargl > > PR fortran/91552 > * array.c (walk_array_constructor): New function. > (gfc_match_array_constructor): Use it. > > 2019-08-31 Steven G. Kargl > > PR fortran/91552 > * gfortran.dg/pr91552.f90: New test. > > -- > Steve -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[SPARC] Fix PR target/91472
This is a regression present on mainline and 9/8 branches: there is a segfault
in one of the tests of the GMP testsuite when the compiler is configured with
PIE by default. The bug only affects a test, i.e. not the library itself, and
has been introduced when the PIC register was turned into a pseudo-register.
Bootstrapped/regtested on SPARC64/Linux, applied on mainline and 9/8 branches.
2019-09-01 Eric Botcazou
PR target/91472
* config/sparc/sparc.c (sparc_cannot_force_const_mem): Return true
during LRA/reload in PIC mode if the PIC register hasn't been used yet.
(sparc_pic_register_p): Test reload_in_progress for consistency's sake.
2019-09-01 Eric Botcazou
* gcc.c-torture/execute/20190901-1.c: New test.
--
Eric Botcazou/* PR target/91472 */
/* Reported by John Paul Adrian Glaubitz */
typedef unsigned int gmp_uint_least32_t;
union ieee_double_extract
{
struct
{
gmp_uint_least32_t sig:1;
gmp_uint_least32_t exp:11;
gmp_uint_least32_t manh:20;
gmp_uint_least32_t manl:32;
} s;
double d;
};
double __attribute__((noipa))
tests_infinity_d (void)
{
union ieee_double_extract x;
x.s.exp = 2047;
x.s.manl = 0;
x.s.manh = 0;
x.s.sig = 0;
return x.d;
}
int
main (void)
{
double x = tests_infinity_d ();
if (x == 0.0)
__builtin_abort ();
return 0;
}
Index: config/sparc/sparc.c
===
--- config/sparc/sparc.c (revision 275068)
+++ config/sparc/sparc.c (working copy)
@@ -4201,6 +4201,13 @@ eligible_for_sibcall_delay (rtx_insn *tr
static bool
sparc_cannot_force_const_mem (machine_mode mode, rtx x)
{
+ /* After IRA has run in PIC mode, it is too late to put anything into the
+ constant pool if the PIC register hasn't already been initialized. */
+ if ((lra_in_progress || reload_in_progress)
+ && flag_pic
+ && !crtl->uses_pic_offset_table)
+return true;
+
switch (GET_CODE (x))
{
case CONST_INT:
@@ -4450,7 +4457,7 @@ sparc_pic_register_p (rtx x)
return true;
if (!HARD_REGISTER_P (pic_offset_table_rtx)
- && (HARD_REGISTER_P (x) || lra_in_progress)
+ && (HARD_REGISTER_P (x) || lra_in_progress || reload_in_progress)
&& ORIGINAL_REGNO (x) == REGNO (pic_offset_table_rtx))
return true;
Re: [PATCH] Fix free_lang_data on asm stmts (PR lto/91572)
On Sun, Sep 01, 2019 at 02:30:12PM +0200, Richard Biener wrote: > On September 1, 2019 1:55:14 PM GMT+02:00, Jakub Jelinek > wrote: > >On Sat, Aug 31, 2019 at 03:02:18PM +0200, Richard Biener wrote: > >> Ok, but I wonder if we can stream the constraint strings in a simpler > >way - surely the type doesn't really matter? > >> Why are they not identifier nodes? > > > >I guess they have type because they are parsed like any other string > >literals during parsing and once we parse them that way, it isn't worth > >changing them to something else like an identifier. > > Hmm, so we accept wide-char literals as well here? > > >Would it be enough to just clear their type during free lang data or > >something similar? > > I guess so. Maybe do that during gimplification already? Wonder how we > pretty print asms then when we mangle their types. Note the original > patch is OK as-is I just wondered why we bother to even keep the asm > constrains as something different than a char *. The type was actually const char *, which was the problem on the testcase, as nothing in the testcase required otherwise const char, so we made it its own distinct type and then were unhappy that a streamed type was handled that way. Jakub
Re: [PATCH] Fix up go regressions caused by my recent switchconv changes (PR go/91617)
On Sat, Aug 31, 2019 at 08:25:49PM +0200, Richard Biener wrote:
> So why not always return an unsigned type then by telling type_for_size?
So like this (if it passes bootstrap/regtest)?
2019-09-01 Jakub Jelinek
PR go/91617
* fold-const.c (range_check_type): For enumeral and boolean
type, pass 1 to type_for_size langhook instead of
TYPE_UNSIGNED (etype). Return unsigned_type_for result whenever
etype isn't TYPE_UNSIGNED INTEGER_TYPE.
(build_range_check): Don't call unsigned_type_for for pointer types.
* match.pd (X / C1 op C2): Don't call unsigned_type_for on
range_check_type result.
--- gcc/fold-const.c.jj 2019-08-27 12:26:39.303884758 +0200
+++ gcc/fold-const.c2019-09-01 18:22:41.866023675 +0200
@@ -4938,10 +4938,9 @@ range_check_type (tree etype)
/* First make sure that arithmetics in this type is valid, then make sure
that it wraps around. */
if (TREE_CODE (etype) == ENUMERAL_TYPE || TREE_CODE (etype) == BOOLEAN_TYPE)
-etype = lang_hooks.types.type_for_size (TYPE_PRECISION (etype),
- TYPE_UNSIGNED (etype));
+etype = lang_hooks.types.type_for_size (TYPE_PRECISION (etype), 1);
- if (TREE_CODE (etype) == INTEGER_TYPE && !TYPE_OVERFLOW_WRAPS (etype))
+ if (TREE_CODE (etype) != INTEGER_TYPE || !TYPE_UNSIGNED (etype))
{
tree utype, minv, maxv;
@@ -5049,9 +5048,6 @@ build_range_check (location_t loc, tree
if (etype == NULL_TREE)
return NULL_TREE;
- if (POINTER_TYPE_P (etype))
-etype = unsigned_type_for (etype);
-
high = fold_convert_loc (loc, etype, high);
low = fold_convert_loc (loc, etype, low);
exp = fold_convert_loc (loc, etype, exp);
--- gcc/match.pd.jj 2019-08-27 12:26:40.745863588 +0200
+++ gcc/match.pd2019-09-01 18:23:02.098729356 +0200
@@ -1569,8 +1569,6 @@ (define_operator_list COND_TERNARY
tree etype = range_check_type (TREE_TYPE (@0));
if (etype)
{
- if (! TYPE_UNSIGNED (etype))
- etype = unsigned_type_for (etype);
hi = fold_convert (etype, hi);
lo = fold_convert (etype, lo);
hi = const_binop (MINUS_EXPR, etype, hi, lo);
Jakub
Re: [PATCH] Fix up go regressions caused by my recent switchconv changes (PR go/91617)
On September 1, 2019 6:34:25 PM GMT+02:00, Jakub Jelinek
wrote:
>On Sat, Aug 31, 2019 at 08:25:49PM +0200, Richard Biener wrote:
>> So why not always return an unsigned type then by telling
>type_for_size?
>
>So like this (if it passes bootstrap/regtest)?
Yes.
Thanks,
Richard.
>2019-09-01 Jakub Jelinek
>
> PR go/91617
> * fold-const.c (range_check_type): For enumeral and boolean
> type, pass 1 to type_for_size langhook instead of
> TYPE_UNSIGNED (etype). Return unsigned_type_for result whenever
> etype isn't TYPE_UNSIGNED INTEGER_TYPE.
> (build_range_check): Don't call unsigned_type_for for pointer types.
> * match.pd (X / C1 op C2): Don't call unsigned_type_for on
> range_check_type result.
>
>--- gcc/fold-const.c.jj2019-08-27 12:26:39.303884758 +0200
>+++ gcc/fold-const.c 2019-09-01 18:22:41.866023675 +0200
>@@ -4938,10 +4938,9 @@ range_check_type (tree etype)
>/* First make sure that arithmetics in this type is valid, then make
>sure
> that it wraps around. */
>if (TREE_CODE (etype) == ENUMERAL_TYPE || TREE_CODE (etype) ==
>BOOLEAN_TYPE)
>-etype = lang_hooks.types.type_for_size (TYPE_PRECISION (etype),
>- TYPE_UNSIGNED (etype));
>+etype = lang_hooks.types.type_for_size (TYPE_PRECISION (etype),
>1);
>
>- if (TREE_CODE (etype) == INTEGER_TYPE && !TYPE_OVERFLOW_WRAPS
>(etype))
>+ if (TREE_CODE (etype) != INTEGER_TYPE || !TYPE_UNSIGNED (etype))
> {
> tree utype, minv, maxv;
>
>@@ -5049,9 +5048,6 @@ build_range_check (location_t loc, tree
> if (etype == NULL_TREE)
> return NULL_TREE;
>
>- if (POINTER_TYPE_P (etype))
>-etype = unsigned_type_for (etype);
>-
> high = fold_convert_loc (loc, etype, high);
> low = fold_convert_loc (loc, etype, low);
> exp = fold_convert_loc (loc, etype, exp);
>--- gcc/match.pd.jj2019-08-27 12:26:40.745863588 +0200
>+++ gcc/match.pd 2019-09-01 18:23:02.098729356 +0200
>@@ -1569,8 +1569,6 @@ (define_operator_list COND_TERNARY
> tree etype = range_check_type (TREE_TYPE (@0));
> if (etype)
> {
>- if (! TYPE_UNSIGNED (etype))
>-etype = unsigned_type_for (etype);
> hi = fold_convert (etype, hi);
> lo = fold_convert (etype, lo);
> hi = const_binop (MINUS_EXPR, etype, hi, lo);
>
>
> Jakub
[Patch-fortran] PR91589 - [9/10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2447
This was caused by my inquiry ref patch.
I will commit to both branches tomorrow night unless there is an objection.
Bootstraps and regtests on FC29/x86_64.
Paul
2019-09-02 Paul Thomas
PR fortran/91589
* primary.c (gfc_match_varspec): Return MATCH_NO on an apparent
component ref, when the primary type is not derived, class or
unknown.
2019-09-02 Paul Thomas
PR fortran/91589
* gfortran.dg/pr91589.f90 : New test.
Index: gcc/fortran/primary.c
===
*** gcc/fortran/primary.c (revision 275268)
--- gcc/fortran/primary.c (working copy)
*** gfc_match_varspec (gfc_expr *primary, in
*** 2237,2242
--- 2237,2244
inquiry = is_inquiry_ref (name, &tmp);
if (inquiry)
sym = NULL;
+ else if (primary->ts.type != BT_UNKNOWN)
+ return MATCH_NO;
}
else
inquiry = false;
*** gfc_variable_attr (gfc_expr *expr, gfc_t
*** 2598,2604
case AR_UNKNOWN:
/* For standard conforming code, AR_UNKNOWN should not happen.
! For nonconforming code, gfortran can end up here. Treat it
as a no-op. */
break;
}
--- 2600,2606
case AR_UNKNOWN:
/* For standard conforming code, AR_UNKNOWN should not happen.
! For nonconforming code, gfortran can end up here. Treat it
as a no-op. */
break;
}
Index: gcc/testsuite/gfortran.dg/pr91589.f90
===
*** gcc/testsuite/gfortran.dg/pr91589.f90 (nonexistent)
--- gcc/testsuite/gfortran.dg/pr91589.f90 (working copy)
***
*** 0
--- 1,14
+ ! { dg-do compile }
+ !
+ ! Check the fix for PR91589, in which the invalid expression caused an ICE.
+ !
+ ! Contributed by Gerhardt Steinmetz
+ !
+ program p
+type t
+ integer :: a
+end type
+type(t) :: x = t(1)
+call sub (x%a%a) ! { dg-error "Syntax error in argument list" }
+ end
+
[PATCH, testsuite, committed] Unsupport 20190827-1.c for targets without alias support.
This test is failing everywhere on Darwin, which lacks the necessary alias
support.
I didn’t check to see if there was some way to re-write the test to avoid the
need for
such support.
tested on powerpc-darwin9, x86_64-darwin16, {x86-64,powerpc64}-linux-gnu,
applied to mainline as obvious,
thanks
Iain
gcc/testsuite/
2019-09-01 Iain Sandoe
* gcc.c-torture/compile/20190827-1.c: Add dg-requires-alias.
diff --git a/gcc/testsuite/gcc.c-torture/compile/20190827-1.c
b/gcc/testsuite/gcc.c-torture/compile/20190827-1.c
index f0956179b1..cdf71d8bab 100644
--- a/gcc/testsuite/gcc.c-torture/compile/20190827-1.c
+++ b/gcc/testsuite/gcc.c-torture/compile/20190827-1.c
@@ -1,3 +1,4 @@
+/* { dg-require-alias "" } */
typedef unsigned char __u8;
typedef __u8 u8;
typedef u8 u_int8_t;
Re: [PATCH, i386]: Do not limit the cost of moves to/from XMM register to minimum 8.
On Sat, Aug 31, 2019 at 3:57 PM Richard Biener
wrote:
>
> On August 31, 2019 2:51:51 AM GMT+02:00, Alan Modra wrote:
> >On Fri, Aug 30, 2019 at 09:42:06AM +0200, Uros Bizjak wrote:
> >> On Fri, Aug 30, 2019 at 9:22 AM Richard Biener
> >> wrote:
> >> >
> >> > On Thu, Aug 29, 2019 at 9:54 AM Uros Bizjak
> >wrote:
> >> > >
> >> > > On Wed, Aug 28, 2019 at 5:12 PM Uros Bizjak
> >wrote:
> >> > > >
> >> > > > Attached patch improves costing for STV shifts and corrects
> >reject
> >> > > > condition for out of range shift count operands.
> >> > > >
> >> > > > 2019-08-28 Uroš Bizjak
> >> > > >
> >> > > > * config/i386/i386-features.c
> >> > > > (general_scalar_chain::compute_convert_gain):
> >> > > > Correct cost for double-word shifts.
> >> > > > (general_scalar_to_vector_candidate_p): Reject count
> >operands
> >> > > > greater or equal to mode bitsize.
> >> > > >
> >> > > > Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
> >> > > >
> >> > > > Committed to mainline SVN.
> >> > >
> >> > > Ouch... I mixed up patches and actually committed the patch that
> >> > > removes maximum from cost of sse<->int moves.
> >> > >
> >> > > I can leave the patch for a day, so we can see the effects of the
> >cost
> >> > > change, and if the patch creates problems, I'll revert it.
> >> >
> >> > Regresses gromacs and namd quite a bit on Haswell, also perl in
> >SPEC 2000.
> >> > I guess we should try understand why rather than reverting
> >immediately
> >> > (I'd leave it in at least another few days to get more testers pick
> >up the
> >> > rev.).
> >>
> >> The correct patch is actually [1] (I have updated the subject):
> >>
> >> 2019-08-28 Uroš Bizjak
> >>
> >> * config/i386/i386.c (ix86_register_move_cost): Do not
> >> limit the cost of moves to/from XMM register to minimum 8.
> >>
> >> There is no technical reason to limit the costs to minimum 8 anymore,
> >> and several targets (e.g skylake) also claim that moves between SSE
> >> and general regs are as cheap as moves between general regs.
>
> That's likely the issue since moves between regs in the same class can be
> usually dealt with in register renaming while between classes that is not
> generally possible. So I'd make those bigger cost. Otoh moves between same
> class regs are likely overcounted.
>
> However,
> >> these values were never benchmarked properly due to the mentioned
> >> limitation and apparently cause some unwanted secondary effects
> >> (lowering the clock).
> >>
> >> I agree with your proposal to leave the change in the tree some more
> >> time. At the end, we could raise the costs for all targets to 8 to
> >> effectively revert to the previous state.
> >>
> >> [1] https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02009.html
> >
> >Those SPEC regressions sound similar to what I saw when trying to give
> >proper costing to moves between general regs and vsx regs on Power9.
> >rs6000.c:rs6000_ira_change_pseudo_allocno_class is the hack I used to
> >work around bad register allocation decisions due to poor register
> >pressure calculation.
Alan, thanks for the pointer, I take a look at the extensive comments
in and above rs6000_ira_change_pseudo_allocno_class and also inside
rs6000_register_move_cost. According to the comment to
rs6000_i_c_p_a_c:
--quote--
The register allocator chooses GEN_OR_VSX_REGS for the allocno
class if GENERAL_REGS and VSX_REGS cost is lower than the memory
cost. This happens a lot when TARGET_DIRECT_MOVE makes the register
move cost between GENERAL_REGS and VSX_REGS low.
It might seem reasonable to use a union class. After all, if usage
of vsr is low and gpr high, it might make sense to spill gpr to vsr
rather than memory. However, in cases where register pressure of
both is high, like the cactus_adm spec test, allowing
GEN_OR_VSX_REGS as the allocno class results in bad decisions in
the first scheduling pass. This is partly due to an allocno of
GEN_OR_VSX_REGS wrongly contributing to the GENERAL_REGS pressure
class, which gives too high a pressure for GENERAL_REGS and too low
for VSX_REGS. So, force a choice of the subclass here.
--/quote--
we can take a parallel with x86's SSE and integer registers, where
both classes can hold SImode and DImode values. The attached patch is
the first try to implement the idea of forcing a subclass (I must
admit that the patch is a bit of a shot in the dark...).
Also, the comment in the rs6000_register_move_cost says:
/* Keep the cost for direct moves above that for within
a register class even if the actual processor cost is
comparable. We do this because a direct move insn
can't be a nop, whereas with ideal register
allocation a move within the same class might turn
out to be a nop. */
which is not the case with core_cost (and similar with skylake_cost):
2, 2, 4,/* cost of moving XMM,YMM,ZMM register */
{6, 6, 6, 6,
Re: C++ PATCH for c++/91129 - wrong error with binary op in template argument
On 8/29/19 12:36 PM, Marek Polacek wrote:
We reject this test with errors like
nontype1.C:22:14: error: taking address of rvalue [-fpermissive]
22 | A{}> a2;
| ^~~
that happens because for converting "C{}" to int we generate
"C::operator int (&TARGET_EXPR )". The second
template argument is a binary operator, so while parsing the template
arguments in a function template foo we end up in cp_build_binary_op.
cp_build_binary_op calls, for certain binary ops, fold_non_dependent_expr.
Since these
calls are no longer tf_none. fold_non_dependent_expr, when in a template,
will instantiate, which gives the "taking address of rvalue" error.
In this particular case the fix seems to be using fold_for_warn instead,
which in a template is fold_non_dependent_expr with tf_none; all the
fold calls I'm changing in this patch are used for diagnostic purposes
only, and it fixes all the bogus errors.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-08-29 Marek Polacek
PR c++/91129 - wrong error with binary op in template argument.
* typeck.c (warn_for_null_address): Use fold_for_warn instead of
fold_non_dependent_expr.
(cp_build_binary_op): Likewise.
* g++.dg/cpp1y/nontype1.C: New test.
diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index c09bb309142..31414453524 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -4305,7 +4305,7 @@ warn_for_null_address (location_t location, tree op,
tsubst_flags_t complain)
|| TREE_NO_WARNING (op))
return;
- tree cop = fold_non_dependent_expr (op, complain);
+ tree cop = fold_for_warn (op);
if (TREE_CODE (cop) == ADDR_EXPR
&& decl_with_nonnull_addr_p (TREE_OPERAND (cop, 0))
@@ -4628,9 +4628,8 @@ cp_build_binary_op (const op_location_t &location,
|| code1 == COMPLEX_TYPE || code1 == VECTOR_TYPE))
{
enum tree_code tcode0 = code0, tcode1 = code1;
- tree cop1 = fold_non_dependent_expr (op1, complain);
doing_div_or_mod = true;
- warn_for_div_by_zero (location, cop1);
+ warn_for_div_by_zero (location, fold_for_warn (op1));
if (tcode0 == COMPLEX_TYPE || tcode0 == VECTOR_TYPE)
tcode0 = TREE_CODE (TREE_TYPE (TREE_TYPE (op0)));
@@ -4669,11 +4668,8 @@ cp_build_binary_op (const op_location_t &location,
case TRUNC_MOD_EXPR:
case FLOOR_MOD_EXPR:
- {
- tree cop1 = fold_non_dependent_expr (op1, complain);
- doing_div_or_mod = true;
- warn_for_div_by_zero (location, cop1);
- }
+ doing_div_or_mod = true;
+ warn_for_div_by_zero (location, fold_for_warn (op1));
if (code0 == VECTOR_TYPE && code1 == VECTOR_TYPE
&& TREE_CODE (TREE_TYPE (type0)) == INTEGER_TYPE
@@ -4766,7 +4762,7 @@ cp_build_binary_op (const op_location_t &location,
}
else if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
{
- tree const_op1 = fold_non_dependent_expr (op1, complain);
+ tree const_op1 = fold_for_warn (op1);
if (TREE_CODE (const_op1) != INTEGER_CST)
const_op1 = op1;
result_type = type0;
@@ -4812,10 +4808,10 @@ cp_build_binary_op (const op_location_t &location,
}
else if (code0 == INTEGER_TYPE && code1 == INTEGER_TYPE)
{
- tree const_op0 = fold_non_dependent_expr (op0, complain);
+ tree const_op0 = fold_for_warn (op0);
if (TREE_CODE (const_op0) != INTEGER_CST)
const_op0 = op0;
- tree const_op1 = fold_non_dependent_expr (op1, complain);
+ tree const_op1 = fold_for_warn (op1);
if (TREE_CODE (const_op1) != INTEGER_CST)
const_op1 = op1;
result_type = type0;
diff --git gcc/testsuite/g++.dg/cpp1y/nontype1.C
gcc/testsuite/g++.dg/cpp1y/nontype1.C
new file mode 100644
index 000..a37e996a3ff
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp1y/nontype1.C
@@ -0,0 +1,42 @@
+// PR c++/91129 - wrong error with binary op in template argument.
+// { dg-do compile { target c++14 } }
+
+template
+struct C
+{
+ constexpr operator T() const { return v; }
+ constexpr auto operator()() const { return v; }
+};
+
+template
+struct A
+{
+};
+
+template
+void foo ()
+{
+ A{}> a0;
+ A{}> a1;
+ A{}> a2;
+ A{}> a3;
+ A{}> a4;
+ A{}> a5;
+ A{}> a6;
+ A{}> a7;
+ A{}> a8;
+ A{}> a9;
+ A{}> a10;
+ A> C{})> a11;
+ A{}> a12;
+ A{}> a13;
+ A{}> a14;
+ A{}> a15;
+ A{}> a16;
+ A{}> a17;
+}
+
+int main()
+{
+ foo<10>();
+}
OK.
Jason
Re: [PATCH] Use cxx_printable_name for __PRETTY_FUNCTION__ in cp_fname_init.
On 8/29/19 2:37 AM, Martin Liška wrote: On 8/28/19 10:19 PM, Jason Merrill wrote: On 8/28/19 12:29 PM, Martin Liška wrote: The patch restores behavior before r265711 where we used cxx_printable_name for __PRETTY_FUNCTION__. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin gcc/c-family/ChangeLog: 2019-08-27 Martin Liska PR c++/91155 * c-common.c (fname_as_string): Use cxx_printable_name for __PRETTY_FUNCTION__ same as was used before r265711. - if (name) - free (CONST_CAST (char *, name)); This creates a memory leak for the fname_as_string case. Jason Sure, fixed in the updated patch. OK. Jason
[PATCH V2] Setup predicate for switch default case in IPA (PR ipa/91089)
> I have read through the patch and it looks OK to me but I cannot approve
> it, you have to ping Honza for that. Since you decided to use the value
> range info, it would be nice if you could also add a testcase where it
> plays a role.
It is somewhat hard to write a testcase to show role of range info only with
this patch. If another patch "Generalized predicate/condition for parameter
reference in IPA (PR ipa/91088)" is accepted, it will become easy and I will
update this testcase to show that.
And this new version also resolves a problem that we might generate very
complicated predicate for basic block in convergence point reached from
all switch cases.
switch (index)
/ | \
case1 case2 ... default
\ | /
convergence point
For switch/if statement, current algorithm synthesizes predicate of
convergence point by OR-combining predicates of all its cases/branches, which
might give us a very complicated one. Actually, we can get simplified predicate
by using the fact that predicate for a basic block must also hold true for its
post
dominators. To be specific, convergence point should include (at least equal
to)
predicate of the switch/if statement.
Honza & Martin,
Would please review this new patch when you have time? Thanks.
Feng
-
diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
index 278bf606661..dc5752fc005 100644
--- a/gcc/ipa-fnsummary.c
+++ b/gcc/ipa-fnsummary.c
@@ -1198,7 +1198,8 @@ set_cond_stmt_execution_predicate (struct
ipa_func_body_info *fbi,
/* invert_tree_comparison will return ERROR_MARK on FP
comparsions that are not EQ/NE instead of returning proper
unordered one. Be sure it is not confused with NON_CONSTANT. */
- if (this_code != ERROR_MARK)
+ if (this_code != ERROR_MARK
+ && !dominated_by_p (CDI_POST_DOMINATORS, bb, e->dest))
{
predicate p
= add_condition (summary, index, size, &aggpos, this_code,
@@ -1269,13 +1270,31 @@ set_switch_stmt_execution_predicate (struct
ipa_func_body_info *fbi,
if (!unmodified_parm_or_parm_agg_item (fbi, last, op, &index, &size,
&aggpos))
return;
+ auto_vec > ranges;
+ tree type = TREE_TYPE (op);
+ tree one_cst = build_one_cst (type);
+ int bound_limit = PARAM_VALUE (PARAM_IPA_MAX_SWITCH_PREDICATE_BOUNDS);
+ int bound_count = 0;
+ value_range_base vr;
+
+ get_range_info (op, vr);
+
FOR_EACH_EDGE (e, ei, bb->succs)
{
e->aux = edge_predicate_pool.allocate ();
*(predicate *) e->aux = false;
}
+
+ e = gimple_switch_edge (cfun, last, 0);
+ /* Set BOUND_COUNT to maximum count to bypass computing predicate for
+ default case if its target basic block is in convergence point of all
+ switch cases, which can be determined by checking whether it
+ post-dominates the switch statement. */
+ if (dominated_by_p (CDI_POST_DOMINATORS, bb, e->dest))
+bound_count = INT_MAX;
+
n = gimple_switch_num_labels (last);
- for (case_idx = 0; case_idx < n; ++case_idx)
+ for (case_idx = 1; case_idx < n; ++case_idx)
{
tree cl = gimple_switch_label (last, case_idx);
tree min, max;
@@ -1285,10 +1304,10 @@ set_switch_stmt_execution_predicate (struct
ipa_func_body_info *fbi,
min = CASE_LOW (cl);
max = CASE_HIGH (cl);
- /* For default we might want to construct predicate that none
- of cases is met, but it is bit hard to do not having negations
- of conditionals handy. */
- if (!min && !max)
+ /* The case's target basic block is in convergence point of all switch
+cases, its predicate should be at least as that of the switch
+statement. */
+ if (dominated_by_p (CDI_POST_DOMINATORS, bb, e->dest))
p = true;
else if (!max)
p = add_condition (summary, index, size, &aggpos, EQ_EXPR,
@@ -1304,7 +1323,111 @@ set_switch_stmt_execution_predicate (struct
ipa_func_body_info *fbi,
}
*(class predicate *) e->aux
= p.or_with (summary->conds, *(class predicate *) e->aux);
+
+ /* If there are too many disjoint case ranges, predicate for default
+case might become too complicated. So add a limit here. */
+ if (bound_count > bound_limit)
+ continue;
+
+ bool new_range = true;
+
+ if (!ranges.is_empty ())
+ {
+ tree last_max_plus_one
+ = int_const_binop (PLUS_EXPR, ranges.last ().second, one_cst);
+
+ /* Merge case ranges if they are continuous. */
+ if (tree_int_cst_equal (min, last_max_plus_one))
+ new_range = false;
+ else if (vr.kind () == VR_ANTI_RANGE)
+ {
+ tree min_minus_one = int_const_binop (MINUS_EXPR, min, one_cst);
+
+ /* If two disjoint case ranges can be connected by anti-range
+ of switch index, combine them to one range. */
+ if (tree_int_cst_lt (vr
