Re: [C++,doc] vector conditional expression
On Thu, 30 Jan 2014, Gerald Pfeifer wrote: And thanks for your explanations. With those, I am fine. Thanks, I'll commit shortly. Might it make sense to add some of the background you shared to the documentation to describe the limitations? I guess so. I'll mark it somewhere, but no promise as to when I might get to it. -- Marc Glisse
Re: Disable accumulate-outgoing-args for Generic and Buldozers
On Wed, Jan 29, 2014 at 04:27:48PM +0100, Richard Biener wrote:
Actually best would be to avoid generating so many useless values
in the first place ... still, quadraticness is a complete no-go.
Filed as PR59992. Though, we have big issues in other parts of the compiler
too, before managing to write the PR59992 testcase that seems to be
expensive only in the remove_useless_value part, I've tried e.g.
#define A(n) if (p[n]) { extern void foo##n (int, int, double); foo##n (p[n],
5, 8.0); }
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7)
B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7)
C(n##8) C(n##9)
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7)
D(n##8) D(n##9)
void
foo (int *p)
{
E(1) E(2)
}
where there is a memory hog and compile time hog in ud_dce pass (-m32 -O2 -g).
Jakub
[PATCH] Vector mode addresses
As a followup of the thread: http://gcc.gnu.org/ml/gcc/2014-01/msg00206.html consider the attached patch for submission. It fixes an ICE in case you try to use vector mode addresses and do not have it as mode dependent target hook. As discussed in the thread adding VECTOR_MODE_P to the target hook is a way to avoid ICE but as Richard S. mentioned it's more general to patch GCC up. Bootstrapped and tested on x86_64-unknown-linux-gnu. 2014-01-30 Paulo Matos pma...@broadcom.com * simplify-rtx.c (simplify_subreg): Do not adjust address if memory address has vector mode. OK to submit? Paulo Matos vector-mode.patch Description: vector-mode.patch
[C++ Patch] PR 58843
Hi,
in this ICE on invalid regression the problem happens toward the end of
lookup_destructor when adjust_result_of_qualified_name_lookup (and
possibly the callar itself) tries to set BASELINK_QUALIFIED_P of an
error_mark_node. As explained in check_dtor_name too, error_mark_node
means we already complained about this destructor, thus seems safe to
early return it back. Tested x86_64-linux.
Thanks,
Paolo.
/
/cp
2014-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/58843
* typeck.c (lookup_destructor): Check dtor_type for error_mark_node.
/testsuite
2014-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/58843
* g++.dg/lookup/crash8.C: New.
Index: cp/typeck.c
===
--- cp/typeck.c (revision 207298)
+++ cp/typeck.c (working copy)
@@ -2486,6 +2486,10 @@ lookup_destructor (tree object, tree scope, tree d
tree dtor_type = TREE_OPERAND (dtor_name, 0);
tree expr;
+ /* We've already complained about this destructor. */
+ if (dtor_type == error_mark_node)
+return error_mark_node;
+
if (scope !check_dtor_name (scope, dtor_type))
{
if (complain tf_error)
Index: testsuite/g++.dg/lookup/crash8.C
===
--- testsuite/g++.dg/lookup/crash8.C(revision 0)
+++ testsuite/g++.dg/lookup/crash8.C(working copy)
@@ -0,0 +1,13 @@
+// PR c++/58843
+
+struct A {};
+
+templatetypename T void foo(T t)
+{
+ t.T::~X(); // { dg-error no type }
+}
+
+void bar()
+{
+ foo(A());
+}
[PATCH][AVX512] Swap Yk and k constraints.
Hi,
Turns out that for Icc meaning of Yk and k constraints
(exposed through inline asm) is opposite to current GCC implementation.
As Icc with such behavior was already releases and GCC wasn't. I propose
to swap meaning of Yk and k constraints. Changes are pretty mechanical.
Bootstraps/passes make check/SPEC2006. Ok for trunk?
Here is ChangeLog:
2014-01-30 Ilya Tocar ilya.to...@intel.com
* config/i386/constraints.md (Yk): Swap meaning with k.
* config/i386/i386.md (movhi_internal): Change Yk to k.
(movqi_internal): Ditto.
(*klogicmode): Ditto.
(*andhi_1): Ditto.
(*andqi_1): Ditto.
(kandnmode): Ditto.
(*codehi_1): Ditto.
(*codeqi_1): Ditto.
(kxnormode): Ditto.
(kortestzhi): Ditto.
(kortestchi): Ditto.
(kunpckhi): Ditto.
(*one_cmplhi2_1): Ditto.
(*one_cmplqi2_1): Ditto.
* config/i386/sse.md (): Change k to Yk.
(avx512f_loadmode_mask): Ditto.
(avx512f_blendmmode): Ditto.
(avx512f_storemode_mask): Ditto.
(avx512f_storeussemodesuffix512_mask): Ditto.
(avx512f_storedqumode_mask): Ditto.
(avx512f_cmpmode3mask_scalar_merge_nameround_saeonly_name): Ditto.
(avx512f_ucmpmode3mask_scalar_merge_name): Ditto.
(avx512f_vmcmpmode3round_saeonly_name): Ditto.
(avx512f_vmcmpmode3_maskround_saeonly_name): Ditto.
(avx512f_maskcmpmode3): Ditto.
(avx512f_fmadd_mode_maskround_name): Ditto.
(avx512f_fmadd_mode_mask3round_name): Ditto.
(avx512f_fmsub_mode_maskround_name): Ditto.
(avx512f_fmsub_mode_mask3round_name): Ditto.
(avx512f_fnmadd_mode_maskround_name): Ditto.
(avx512f_fnmadd_mode_mask3round_name): Ditto.
(avx512f_fnmsub_mode_maskround_name): Ditto.
(avx512f_fnmsub_mode_mask3round_name): Ditto.
(avx512f_fmaddsub_mode_maskround_name): Ditto.
(avx512f_fmaddsub_mode_mask3round_name): Ditto.
(avx512f_fmsubadd_mode_maskround_name): Ditto.
(avx512f_fmsubadd_mode_mask3round_name): Ditto.
(avx512f_vextractshuffletype32x4_1_maskm): Ditto.
(vec_extract_lo_mode_maskm): Ditto.
(vec_extract_hi_mode_maskm): Ditto.
(avx512f_vternlogmode_mask): Ditto.
(avx512f_fixupimmmode_maskround_saeonly_name): Ditto.
(avx512f_sfixupimmmode_maskround_saeonly_name): Ditto.
(avx512f_codepmov_src_lowermode2_mask): Ditto.
(avx512f_codev8div16qi2_mask): Ditto.
(avx512f_codev8div16qi2_mask_store): Ditto.
(avx512f_eqmode3mask_scalar_merge_name_1): Ditto.
(avx512f_gtmode3mask_scalar_merge_name): Ditto.
(avx512f_testmmode3mask_scalar_merge_name): Ditto.
(avx512f_testnmmode3mask_scalar_merge_name): Ditto.
(*avx512pf_gatherpfmodesf_mask): Ditto.
(*avx512pf_gatherpfmodedf_mask): Ditto.
(*avx512pf_scatterpfmodesf_mask): Ditto.
(*avx512pf_scatterpfmodedf_mask): Ditto.
(avx512cd_maskb_vec_dupv8di): Ditto.
(avx512cd_maskw_vec_dupv16si): Ditto.
(avx512f_vpermi2varmode3_maskz): Ditto.
(avx512f_vpermi2varmode3_mask): Ditto.
(avx512f_vpermi2varmode3_mask): Ditto.
(avx512f_vpermt2varmode3_maskz): Ditto.
(*avx512f_gathersimode): Ditto.
(*avx512f_gathersimode_2): Ditto.
(*avx512f_gatherdimode): Ditto.
(*avx512f_gatherdimode_2): Ditto.
(*avx512f_scattersimode): Ditto.
(*avx512f_scatterdimode): Ditto.
(avx512f_compressmode_mask): Ditto.
(avx512f_compressstoremode_mask): Ditto.
(avx512f_expandmode_mask): Ditto.
* config/i386/subst.md (mask): Change k to Yk.
(mask_scalar_merge): Ditto.
(sd): Ditto.
And for tests:
2014-01-30 Ilya Tocar ilya.to...@intel.com
* gcc.target/i386/avx512f-inline-asm.c: Swap Yk and k.
* gcc.target/i386/avx512f-kmovw-1.c: Also allow k0.
Patch bellow:
---
gcc/config/i386/constraints.md | 4 +-
gcc/config/i386/i386.md| 72 +++---
gcc/config/i386/sse.md | 110 ++---
gcc/config/i386/subst.md | 6 +-
gcc/testsuite/gcc.target/i386/avx512f-inline-asm.c | 6 +-
gcc/testsuite/gcc.target/i386/avx512f-kmovw-1.c| 2 +-
6 files changed, 100 insertions(+), 100 deletions(-)
diff --git a/gcc/config/i386/constraints.md b/gcc/config/i386/constraints.md
index 0d61c87..65335f1 100644
--- a/gcc/config/i386/constraints.md
+++ b/gcc/config/i386/constraints.md
@@ -78,10 +78,10 @@
TARGET_80387 || TARGET_FLOAT_RETURNS_IN_80387 ? FP_SECOND_REG : NO_REGS
Second from top of 80387 floating-point stack (@code{%st(1)}).)
-(define_register_constraint k TARGET_AVX512F ? MASK_EVEX_REGS : NO_REGS
+(define_register_constraint Yk TARGET_AVX512F ? MASK_EVEX_REGS : NO_REGS
@internal Any mask register that can be used as predicate, i.e. k1-k7.)
[PATCH] Fix PR59951
This fixes PR59951, a debug-compare failure where we didn't disregard
uses in debug stmts when accounting for SLP uses outside of the slp.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-01-30 Richard Biener rguent...@suse.de
PR tree-optimization/59951
* tree-vect-slp.c (vect_bb_slp_scalar_cost): Skip uses in debug
insns.
Index: gcc/tree-vect-slp.c
===
*** gcc/tree-vect-slp.c (revision 207238)
--- gcc/tree-vect-slp.c (working copy)
*** vect_bb_slp_scalar_cost (basic_block bb,
*** 1967,1975
imm_use_iterator use_iter;
gimple use_stmt;
FOR_EACH_IMM_USE_STMT (use_stmt, use_iter, DEF_FROM_PTR (def_p))
! if (gimple_code (use_stmt) == GIMPLE_PHI
! || gimple_bb (use_stmt) != bb
! || !STMT_VINFO_VECTORIZABLE (vinfo_for_stmt (use_stmt)))
{
(*life)[i] = true;
BREAK_FROM_IMM_USE_STMT (use_iter);
--- 1967,1976
imm_use_iterator use_iter;
gimple use_stmt;
FOR_EACH_IMM_USE_STMT (use_stmt, use_iter, DEF_FROM_PTR (def_p))
! if (!is_gimple_debug (use_stmt)
!(gimple_code (use_stmt) == GIMPLE_PHI
! || gimple_bb (use_stmt) != bb
! || !STMT_VINFO_VECTORIZABLE (vinfo_for_stmt (use_stmt
{
(*life)[i] = true;
BREAK_FROM_IMM_USE_STMT (use_iter);
Re: [RFC] Using function clones for Pointer Bounds Checker
Thanks for your comments! I'll continue my experiments with with my initial early_local_passes splitting. Will just put there original functions bodies release to avoid overhead for their useless optimizations. So, it will be 3 IPA passes: 1. SSA build 2. Make instrumented versions + release bodies of original functions 3. early_inline + early optimizations. Will be back with more results. Hi, I've implemented the chosen approach and performed a set of experiments. Without LTO it mostly worked fine. Some new reachability analysis issues were met and I finally solved them by introducing a new type of IPA reference between the original function and it's instrumented version. Two significant problems were revealed during LTO tests. The first one was with assembler function names. With no LTO I just used the same assembler name for both original and instrumented function versions. With LTO assembler name becomes much more important identifier and it does not seems possible to share the same name between original and instrumented versions. I started to use suffix for instrumented function names and chained it with the original assembler name (used IDENTIFIER_TRANSPARENT_ALIAS flag, unfortunately not in all cases aliases chain is followed, so I had to additionally fix few places to have original names printed for the instrumented function decls). BTW LTO streamer does not preserve transparent aliases chain for identifiers. Is it intentional? The second problem was resolutions file from linker. Linker has no idea about connection between instrumented and not instrumented functions and therefore may declare instrumented functions as local when external calls to the original exist. It caused more reachability analysis issues (instrumented functions were removed) and visibility issue (instrumented functions were not marked as global). Visibility issue was simply solved by looking at original function decl before globalizing decl. In solving reachability problems I found useful to transform original functions to the special kind of thunks having call edge to the instrumented version. It guarantees we do not remove instrumented version when original is called. It also provides optimization opportunity for not instrumented calls (e.g. IPCP goes through thunks and may propagate constant params; will require additional support to map params correctly though). If my choices look reasonable I would continue with code cleanup, merge and preparing a patch series for stage 1. Thanks, Ilya
Re: [PATCH] Vector mode addresses
Paulo Matos pma...@broadcom.com writes: As a followup of the thread: http://gcc.gnu.org/ml/gcc/2014-01/msg00206.html consider the attached patch for submission. It fixes an ICE in case you try to use vector mode addresses and do not have it as mode dependent target hook. As discussed in the thread adding VECTOR_MODE_P to the target hook is a way to avoid ICE but as Richard S. mentioned it's more general to patch GCC up. But like I said, I think the VECTOR_MODE_P check should be in mode_dependent_address_p (recog.c) rather than here. If vector addresses are supported then they are mode-dependent, since the number of elements in the address mode must match the number of elements in the MEM mode. Thanks, Richard
[C++ Patch] PR 58649
Hi,
in this ICE on invalid regression if we don't check the return value of
start_enum we try to use SET_OPAQUE_ENUM_P on an error_mark_node. Tested
x86_64-linux, as usual.
Thanks,
Paolo.
//
/cp
2014-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/58649
* pt.c (lookup_template_class_1): Check start_enum return value
for error_mark_node.
/testsuite
2014-01-30 Paolo Carlini paolo.carl...@oracle.com
PR c++/58649
* g++.dg/template/crash117.C: New.
Index: cp/pt.c
===
--- cp/pt.c (revision 207298)
+++ cp/pt.c (working copy)
@@ -7521,6 +7521,9 @@ lookup_template_class_1 (tree d1, tree arglist, tr
tsubst (ENUM_UNDERLYING_TYPE (template_type),
arglist, complain, in_decl),
SCOPED_ENUM_P (template_type), NULL);
+
+ if (t == error_mark_node)
+ return t;
}
else
{
Index: testsuite/g++.dg/template/crash117.C
===
--- testsuite/g++.dg/template/crash117.C(revision 0)
+++ testsuite/g++.dg/template/crash117.C(working copy)
@@ -0,0 +1,9 @@
+// PR c++/58649
+
+templatetypename void foo()
+{
+ E(); // { dg-error declaration|declared }
+ enum E {};
+}
+
+template void fooint();
RE: [PATCH] Vector mode addresses
-Original Message- From: Richard Sandiford [mailto:rdsandif...@googlemail.com] Sent: 30 January 2014 12:43 To: Paulo Matos Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Vector mode addresses Paulo Matos pma...@broadcom.com writes: As a followup of the thread: http://gcc.gnu.org/ml/gcc/2014-01/msg00206.html consider the attached patch for submission. It fixes an ICE in case you try to use vector mode addresses and do not have it as mode dependent target hook. As discussed in the thread adding VECTOR_MODE_P to the target hook is a way to avoid ICE but as Richard S. mentioned it's more general to patch GCC up. But like I said, I think the VECTOR_MODE_P check should be in mode_dependent_address_p (recog.c) rather than here. If vector addresses are supported then they are mode-dependent, since the number of elements in the address mode must match the number of elements in the MEM mode. Have I misunderstood what you said: If we do support vector addresses than I think the right fix is to check VECTOR_MODE_P there. From this I understood that you agreed that if vector_mode is supported for an address the check should be in simplify_rtx as it would prevent all target ports from adding the check to their hook, making it therefore more generic. You re-enforced this when you said: I'd just prefer it to be in generic code because I think it's a target-independent rule. Apologies if I completely misunderstood you. Thanks, Richard
Re: [PATCH][AVX512] Swap Yk and k constraints.
On Thu, Jan 30, 2014 at 2:54 AM, Ilya Tocar tocarip.in...@gmail.com wrote: Hi, Turns out that for Icc meaning of Yk and k constraints (exposed through inline asm) is opposite to current GCC implementation. As Icc with such behavior was already releases and GCC wasn't. I propose to swap meaning of Yk and k constraints. Changes are pretty mechanical. Bootstraps/passes make check/SPEC2006. Ok for trunk? Does KNC GCC support Yk/k? How are they handled? -- H.J.
Re: C++ PATCH for c++/53756 (-g and C++1y auto)
On 01/29/2014 04:28 PM, Paolo Carlini wrote: Interesting. If you like we can do now the below, as preparatory clean-up for the above, which I would do when 4.9 branches. OK. Jason
Re: [C++ Patch] PR 58649
OK. Jason
Re: RFA: cgraph PATCH for c++/59645 (ICE with covariant virtual function with volatile parameter)
On Thu, Jan 30, 2014 at 4:45 AM, Jason Merrill ja...@redhat.com wrote: If a parameter of a covariant virtual function is volatile, we can't just use the parameter directly in the call we build for the thunk, or the gimple verifier will complain. We need to copy it into a temporary first. Tested x86_64-pc-linux-gnu. OK for trunk? Please use if (!is_gimple_val (arg)) instead of testing TREE_THIS_VOLATILE, then it's also obvious that you can remove the assert (I suppose it would trip for an argument of volatile struct X for example?). Ok with that change. Thanks, Richard.
Re: [PATCH][AVX512] Swap Yk and k constraints.
2014-01-30 H.J. Lu hjl.to...@gmail.com: On Thu, Jan 30, 2014 at 2:54 AM, Ilya Tocar tocarip.in...@gmail.com wrote: Hi, Turns out that for Icc meaning of Yk and k constraints (exposed through inline asm) is opposite to current GCC implementation. As Icc with such behavior was already releases and GCC wasn't. I propose to swap meaning of Yk and k constraints. Changes are pretty mechanical. Bootstraps/passes make check/SPEC2006. Ok for trunk? Does KNC GCC support Yk/k? How are they handled? In KNC GCC Yk is MASK_WRITE_REGS and k is MASK_REGS. So it looks like it's consistent with Icc.
[PATCH][ARM] Add Cortex-A57 rtx costs table
Hi all,
This patch adds the rtx costs table for Cortex-A57 and sets its issue rate
properly in the arm backend.
Tested on arm-none-eabi on a model.
Ok for trunk?
Thanks,
Kyrill
2014-01-30 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/arm/aarch-cost-tables.h (cortexa57_extra_costs): New table.
Remove extra newline at end of file.
* config/arm/arm.c (arm_cortex_a57_tune): New tuning struct.
(arm_issue_rate): Handle cortexa57.
* config/arm/arm-cores.def (cortex-a57): Use cortex_a57 tuning.
(cortex-a57.cortex-a53): Likewise.commit cb854a87cdee667d2042228600a221cffbef70ab
Author: Kyrylo Tkachov kyrylo.tkac...@arm.com
Date: Mon Jan 20 09:55:31 2014 +
[ARM] a57 costs
diff --git a/gcc/config/arm/aarch-cost-tables.h b/gcc/config/arm/aarch-cost-tables.h
index 58addaf..c30ea2f 100644
--- a/gcc/config/arm/aarch-cost-tables.h
+++ b/gcc/config/arm/aarch-cost-tables.h
@@ -222,6 +222,104 @@ const struct cpu_cost_table cortexa53_extra_costs =
}
};
+const struct cpu_cost_table cortexa57_extra_costs =
+{
+ /* ALU */
+ {
+0, /* arith. */
+0, /* logical. */
+0, /* shift. */
+COSTS_N_INSNS (1), /* shift_reg. */
+COSTS_N_INSNS (1), /* arith_shift. */
+COSTS_N_INSNS (1), /* arith_shift_reg. */
+COSTS_N_INSNS (1), /* log_shift. */
+COSTS_N_INSNS (1), /* log_shift_reg. */
+0, /* extend. */
+COSTS_N_INSNS (1), /* extend_arith. */
+COSTS_N_INSNS (1), /* bfi. */
+0, /* bfx. */
+0, /* clz. */
+0, /* non_exec. */
+true /* non_exec_costs_exec. */
+ },
+ {
+/* MULT SImode */
+{
+ COSTS_N_INSNS (2), /* simple. */
+ COSTS_N_INSNS (3), /* flag_setting. */
+ COSTS_N_INSNS (2), /* extend. */
+ COSTS_N_INSNS (2), /* add. */
+ COSTS_N_INSNS (2), /* extend_add. */
+ COSTS_N_INSNS (18) /* idiv. */
+},
+/* MULT DImode */
+{
+ COSTS_N_INSNS (4), /* simple. */
+ 0, /* flag_setting (N/A). */
+ COSTS_N_INSNS (2), /* extend. */
+ COSTS_N_INSNS (4), /* add. */
+ COSTS_N_INSNS (2), /* extend_add. */
+ COSTS_N_INSNS (34) /* idiv. */
+}
+ },
+ /* LD/ST */
+ {
+COSTS_N_INSNS (3), /* load. */
+COSTS_N_INSNS (3), /* load_sign_extend. */
+COSTS_N_INSNS (3), /* ldrd. */
+COSTS_N_INSNS (2), /* ldm_1st. */
+1, /* ldm_regs_per_insn_1st. */
+2, /* ldm_regs_per_insn_subsequent. */
+COSTS_N_INSNS (4), /* loadf. */
+COSTS_N_INSNS (4), /* loadd. */
+COSTS_N_INSNS (5), /* load_unaligned. */
+0, /* store. */
+0, /* strd. */
+0, /* stm_1st. */
+1, /* stm_regs_per_insn_1st. */
+2, /* stm_regs_per_insn_subsequent. */
+0, /* storef. */
+0, /* stored. */
+COSTS_N_INSNS (1) /* store_unaligned. */
+ },
+ {
+/* FP SFmode */
+{
+ COSTS_N_INSNS (17), /* div. */
+ COSTS_N_INSNS (5), /* mult. */
+ COSTS_N_INSNS (9), /* mult_addsub. */
+ COSTS_N_INSNS (9), /* fma. */
+ COSTS_N_INSNS (4), /* addsub. */
+ COSTS_N_INSNS (2), /* fpconst. */
+ COSTS_N_INSNS (2), /* neg. */
+ COSTS_N_INSNS (2), /* compare. */
+ COSTS_N_INSNS (4), /* widen. */
+ COSTS_N_INSNS (4), /* narrow. */
+ COSTS_N_INSNS (4), /* toint. */
+ COSTS_N_INSNS (4), /* fromint. */
+ COSTS_N_INSNS (4)/* roundint. */
+},
+/* FP DFmode */
+{
+ COSTS_N_INSNS (31), /* div. */
+ COSTS_N_INSNS (5), /* mult. */
+ COSTS_N_INSNS (9), /* mult_addsub. */
+ COSTS_N_INSNS (9), /* fma. */
+ COSTS_N_INSNS (4), /* addsub. */
+ COSTS_N_INSNS (2), /* fpconst. */
+ COSTS_N_INSNS (2), /* neg. */
+ COSTS_N_INSNS (2), /* compare. */
+ COSTS_N_INSNS (4), /* widen. */
+ COSTS_N_INSNS (4), /* narrow. */
+ COSTS_N_INSNS (4), /* toint. */
+ COSTS_N_INSNS (4), /* fromint. */
+ COSTS_N_INSNS (4)/* roundint. */
+}
+ },
+ /* Vector */
+ {
+COSTS_N_INSNS (1) /* alu. */
+ }
+};
#endif /* GCC_AARCH_COST_TABLES_H */
-
diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
index 1e97273..42f00b4 100644
--- a/gcc/config/arm/arm-cores.def
+++ b/gcc/config/arm/arm-cores.def
@@ -153,7 +153,7 @@ ARM_CORE(cortex-a15.cortex-a7, cortexa15cortexa7, cortexa7, 7A, FL_LDSCHED |
/* V8 Architecture Processors */
Re: Disable accumulate-outgoing-args for Generic and Buldozers
On Thu, Jan 30, 2014 at 10:28 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Jan 29, 2014 at 04:27:48PM +0100, Richard Biener wrote:
Actually best would be to avoid generating so many useless values
in the first place ... still, quadraticness is a complete no-go.
Filed as PR59992. Though, we have big issues in other parts of the compiler
too, before managing to write the PR59992 testcase that seems to be
expensive only in the remove_useless_value part, I've tried e.g.
#define A(n) if (p[n]) { extern void foo##n (int, int, double); foo##n (p[n],
5, 8.0); }
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7)
B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7)
C(n##8) C(n##9)
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7)
D(n##8) D(n##9)
void
foo (int *p)
{
E(1) E(2)
}
where there is a memory hog and compile time hog in ud_dce pass (-m32 -O2 -g).
I first hit PREs compute_avail (known). But yeah - quadraticness at -O1 or -O0
is a no-go IMHO. We should avoid it everywhere else, too, of course, but ...
Seems to be the df_rd_transfer_fn can be improved from
bitmap_copy (tmp, in);
EXECUTE_IF_SET_IN_BITMAP (sparse_kill, 0, regno, bi)
{
bitmap_clear_range (tmp,
DF_DEFS_BEGIN (regno),
DF_DEFS_COUNT (regno));
}
bitmap_and_compl_into (tmp, kill);
to
bitmap_and_compl (tmp, in, kill);
EXECUTE_IF_SET_IN_BITMAP (sparse_kill, 0, regno, bi)
{
bitmap_clear_range (tmp,
DF_DEFS_BEGIN (regno),
DF_DEFS_COUNT (regno));
}
probably doesn't save any memory though.
Jakub
Re: [C++ Patch] PR 58843
OK. Jason
[PATCH][AArch64] Wire up Cortex-A57 rtx costs
Hi all,
This patch wires up the aarch64 backend to use the Cortex-A57 rtx costs table
that is proposed at
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01954.html
It also sets the generic tuning to use the Cortex-A57 costs since they are more
sensible for aarch64 systems than the generic ones that were originally written
with aarch32 code generation in mind.
Tested aarch64-none-elf on a model.
Ok for trunk once the prerequisite goes in?
Thanks,
Kyrill
2014-01-30 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/aarch64/aarch64-cores.def (cortex-a57): Use cortexa57
tuning struct.
(cortex-a57.cortex-a53): Likewise.
* config/aarch64/aarch64.c (cortexa57_tunings): New tuning struct.
commit 780da554b322ab1c54cc662849950adb1181cacb
Author: Kyrylo Tkachov kyrylo.tkac...@arm.com
Date: Fri Jan 24 11:36:02 2014 +
[AArch64] Wire up A57 costs
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index a41d7d9..4db63d6 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -35,8 +35,8 @@
/* V8 Architecture Processors. */
AARCH64_CORE(cortex-a53, cortexa53, cortexa53, 8, AARCH64_FL_FPSIMD, cortexa53)
-AARCH64_CORE(cortex-a57, cortexa15, cortexa15, 8, AARCH64_FL_FPSIMD, generic)
+AARCH64_CORE(cortex-a57, cortexa15, cortexa15, 8, AARCH64_FL_FPSIMD, cortexa57)
/* V8 big.LITTLE implementations. */
-AARCH64_CORE(cortex-a57.cortex-a53, cortexa57cortexa53, cortexa53, 8, AARCH64_FL_FPSIMD, generic)
+AARCH64_CORE(cortex-a57.cortex-a53, cortexa57cortexa53, cortexa53, 8, AARCH64_FL_FPSIMD, cortexa57)
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 5867f75..aca4366 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -235,6 +235,16 @@ static const struct tune_params cortexa53_tunings =
NAMED_PARAM (issue_rate, 2)
};
+static const struct tune_params cortexa57_tunings =
+{
+ cortexa57_extra_costs,
+ generic_addrcost_table,
+ generic_regmove_cost,
+ generic_vector_cost,
+ NAMED_PARAM (memmov_cost, 4),
+ NAMED_PARAM (issue_rate, 3)
+};
+
/* A processor implementing AArch64. */
struct processor
{
Re: [PATCH] Vector mode addresses
On Thu, Jan 30, 2014 at 1:51 PM, Paulo Matos pma...@broadcom.com wrote: -Original Message- From: Richard Sandiford [mailto:rdsandif...@googlemail.com] Sent: 30 January 2014 12:43 To: Paulo Matos Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Vector mode addresses Paulo Matos pma...@broadcom.com writes: As a followup of the thread: http://gcc.gnu.org/ml/gcc/2014-01/msg00206.html consider the attached patch for submission. It fixes an ICE in case you try to use vector mode addresses and do not have it as mode dependent target hook. As discussed in the thread adding VECTOR_MODE_P to the target hook is a way to avoid ICE but as Richard S. mentioned it's more general to patch GCC up. But like I said, I think the VECTOR_MODE_P check should be in mode_dependent_address_p (recog.c) rather than here. If vector addresses are supported then they are mode-dependent, since the number of elements in the address mode must match the number of elements in the MEM mode. Have I misunderstood what you said: If we do support vector addresses than I think the right fix is to check VECTOR_MODE_P there. From this I understood that you agreed that if vector_mode is supported for an address the check should be in simplify_rtx as it would prevent all target ports from adding the check to their hook, making it therefore more generic. You re-enforced this when you said: I'd just prefer it to be in generic code because I think it's a target-independent rule. Apologies if I completely misunderstood you. I'm curious on where you are seeing MEMs with a vector mode address. What does that MEM even mean? From the referenced mail: new_rtx: (mem:V4SI (plus:V4SI (vec_concat:V4SI (vec_concat:V2SI (const_int 0 [0]) (const_int 0 [0])) (vec_concat:V2SI (const_int 0 [0]) (const_int 0 [0]))) that should be invalid and somehow lacks the subreg:DI. The bug is where that got lost. Richard. Thanks, Richard
Re: [PATCH][C] Fix PR59905, remove code replacing calls with abort
On Wed, 29 Jan 2014, Joseph S. Myers wrote: On Wed, 29 Jan 2014, Richard Biener wrote: testing reveals diagnostic regressions FAIL: gcc.dg/call-diag-2.c abort (test for warnings, line 12) FAIL: gcc.dg/call-diag-2.c abort (test for warnings, line 15) FAIL: gcc.dg/invalid-call-1.c (test for warnings, line 16) which may be hard to preserve (didn't investigate thoroughly yet), one is probably emitted via the call to require_complete_type I remove. Is it ok to adjust the testcases expectation for what is produced now? These appear to be about the will abort diagnostics - removing those dg-message tests, while keeping the dg-warning tests, is fine. Ah, indeed. I've adjusted the testcases and committed the patch. Thanks, Richard.
C++ PATCH for c++/59633 (ICE with vector attribute on naming typedef)
The vector_size attribute changes an ENUM_TYPE into a VECTOR_TYPE, so it
is obviously unsuitable for a typedef that gives the enum a name for
linkage purposes. This patch allows the typedef, but makes it no longer
a name for linkage purposes.
Tested x86_64-pc-linux-gnu, applying to trunk (walk_type_fields hunk
under obvious rule).
commit 3cf87cf8a33ba387d8468e47dbc87e87c0c3b722
Author: Jason Merrill ja...@redhat.com
Date: Thu Jan 30 00:27:17 2014 -0500
PR c++/59633
gcc/
* tree.c (walk_type_fields): Handle VECTOR_TYPE.
gcc/cp/
* decl2.c (attributes_naming_typedef_ok): New.
* cp-tree.h: Declare it.
* decl.c (grokdeclarator): Check it.
* tree.c (no_linkage_check): Handle VECTOR_TYPE.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index ab75db8..7f46499 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5296,6 +5296,7 @@ extern tree grokfield (const cp_declarator *, cp_decl_specifier_seq *,
extern tree grokbitfield (const cp_declarator *, cp_decl_specifier_seq *,
tree, tree);
extern tree cp_reconstruct_complex_type (tree, tree);
+extern bool attributes_naming_typedef_ok (tree);
extern void cplus_decl_attributes (tree *, tree, int);
extern void finish_anon_union (tree);
extern void cp_write_global_declarations (void);
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index d7e5829..3652e8d 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -10216,6 +10216,7 @@ grokdeclarator (const cp_declarator *declarator,
TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
TYPE_ANONYMOUS_P (type)
declspecs-type_definition_p
+ attributes_naming_typedef_ok (*attrlist)
cp_type_quals (type) == TYPE_UNQUALIFIED)
{
tree t;
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 58419ec..b2103c8 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -1243,6 +1243,22 @@ save_template_attributes (tree *attr_p, tree *decl_p)
}
}
+/* Return true iff ATTRS are acceptable attributes to be applied in-place
+ to a typedef which gives a previously anonymous class or enum a name for
+ linkage purposes. */
+
+bool
+attributes_naming_typedef_ok (tree attrs)
+{
+ for (; attrs; attrs = TREE_CHAIN (attrs))
+{
+ tree name = get_attribute_name (attrs);
+ if (is_attribute_p (vector_size, name))
+ return false;
+}
+ return true;
+}
+
/* Like reconstruct_complex_type, but handle also template trees. */
tree
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index ce41c3b..fe2ddab 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -2170,6 +2170,7 @@ no_linkage_check (tree t, bool relaxed_p)
case ARRAY_TYPE:
case POINTER_TYPE:
case REFERENCE_TYPE:
+case VECTOR_TYPE:
return no_linkage_check (TREE_TYPE (t), relaxed_p);
case OFFSET_TYPE:
diff --git a/gcc/testsuite/g++.dg/ext/vector26.C b/gcc/testsuite/g++.dg/ext/vector26.C
new file mode 100644
index 000..6d55158
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/vector26.C
@@ -0,0 +1,8 @@
+// PR c++/59633
+// In C++98, the definition of bar is an error. In C++11, bar implicitly
+// gets internal linkage.
+
+typedef enum { e } T __attribute__((vector_size(8)));
+static void foo(T t) {}
+void bar (T t) {} // { dg-error no linkage { target c++98 } }
+// { dg-final { scan-assembler-not globl\[ \t]*_Z3bar } }
diff --git a/gcc/tree.c b/gcc/tree.c
index 5fdd491..1d06ba7 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -10817,6 +10817,7 @@ walk_type_fields (tree type, walk_tree_fn func, void *data,
{
case POINTER_TYPE:
case REFERENCE_TYPE:
+case VECTOR_TYPE:
/* We have to worry about mutually recursive pointers. These can't
be written in C. They can in Ada. It's pathological, but
there's an ACATS test (c38102a) that checks it. Deal with this
[PATCH] Small var-tracking improvement (PR debug/59992)
Hi!
I've noticed that for the side-effects that adjust_insn emits
as extra sets in the PARALLEL we don't transform the SET_SRC parts
through adjust_mems. This means that a typical i?86 push is seen
by var-tracking as:
[(set (mem:SI ((plus:SI (reg:SI argp) (const_int -64 (something:SI))
(set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -4)))]
while with this patch as:
[(set (mem:SI ((plus:SI (reg:SI argp) (const_int -64 (something:SI))
(set (reg:SI sp) (plus:SI (reg:SI argp) (const_int -64)))]
While we have for some time code to increase sharing of VALUEs for the
typical stack pointer adjustments by constant, still it means that every
bb new VALUEs need to be created for every offset from the stack pointer
base that is seen in the code. By using the argp (cfa) + offset
instead we can just share the VALUEs across the whole function.
This patch helps a lot the attached testcase (see the PR for exact numbers),
unfortunately it didn't seem to help insn-recog.c compilation time as much
as I hoped (though, the i686-linux bootstrap as whole took about 20 minutes
less than the last bootstrap).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2014-01-30 Jakub Jelinek ja...@redhat.com
PR debug/59992
* var-tracking.c (adjust_mems): Before adding a SET
to amd-side_effects, adjust it's SET_SRC using
simplify_replace_fn_rtx.
* gcc.dg/pr59992.c: New test.
--- gcc/var-tracking.c.jj 2014-01-29 10:21:11.0 +0100
+++ gcc/var-tracking.c 2014-01-30 11:01:01.779089299 +0100
@@ -1067,10 +1067,13 @@ adjust_mems (rtx loc, const_rtx old_rtx,
? GET_MODE_SIZE (amd-mem_mode)
: -GET_MODE_SIZE (amd-mem_mode),
GET_MODE (loc)));
+ store_save = amd-store;
+ amd-store = false;
+ tem = simplify_replace_fn_rtx (tem, old_rtx, adjust_mems, data);
+ amd-store = store_save;
amd-side_effects = alloc_EXPR_LIST (0,
gen_rtx_SET (VOIDmode,
- XEXP (loc, 0),
- tem),
+ XEXP (loc, 0), tem),
amd-side_effects);
return addr;
case PRE_MODIFY:
@@ -1080,10 +1083,14 @@ adjust_mems (rtx loc, const_rtx old_rtx,
addr = XEXP (loc, 0);
gcc_assert (amd-mem_mode != VOIDmode);
addr = simplify_replace_fn_rtx (addr, old_rtx, adjust_mems, data);
+ store_save = amd-store;
+ amd-store = false;
+ tem = simplify_replace_fn_rtx (XEXP (loc, 1), old_rtx,
+adjust_mems, data);
+ amd-store = store_save;
amd-side_effects = alloc_EXPR_LIST (0,
gen_rtx_SET (VOIDmode,
- XEXP (loc, 0),
- XEXP (loc, 1)),
+ XEXP (loc, 0), tem),
amd-side_effects);
return addr;
case SUBREG:
--- gcc/testsuite/gcc.dg/pr59992.c.jj 2014-01-30 11:43:55.323795812 +0100
+++ gcc/testsuite/gcc.dg/pr59992.c 2014-01-30 11:38:57.0 +0100
@@ -0,0 +1,17 @@
+/* PR debug/59992 */
+/* { dg-do compile } */
+/* { dg-require-effective-target run_expensive_tests } */
+/* { dg-options -O2 -g } */
+/* { dg-timeout-factor 16.0 } */
+
+#define A(n) if (p[n]) { extern void foo##n (int, int, double, int, int);
foo##n (p[n], 5, 8.0, p[n] + p[n + 1], 9); return; }
+#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
A(n##8) A(n##9)
+#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7)
B(n##8) B(n##9)
+#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7)
C(n##8) C(n##9)
+#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7)
D(n##8) D(n##9)
+
+void
+foo (int *p)
+{
+ E(1)
+}
Jakub
[AArch64, Committed] Fix symbol classification logic.
Symbol classification logic intended to force symbols to memory in large
memory model is triggering in appropriately for all memory models, this
results in an unnecessary level of indirection in generated code.
Regressed aarch64-none-elf, committed.
/Marcus
2014-01-30 Marcus Shawcroft marcus.shawcr...@arm.com
* config/aarch64/aarch64.c (aarch64_classify_symbol): Fix logic
for SYMBOL_REF in large memory model.diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index d3c5cbc..16c51a8 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -5400,9 +5400,8 @@ aarch64_classify_symbol (rtx x,
if (GET_CODE (x) == SYMBOL_REF)
{
- if (aarch64_cmodel == AARCH64_CMODEL_LARGE
- || CONSTANT_POOL_ADDRESS_P (x))
- return SYMBOL_FORCE_TO_MEM;
+ if (aarch64_cmodel == AARCH64_CMODEL_LARGE)
+ return SYMBOL_FORCE_TO_MEM;
if (aarch64_tls_symbol_p (x))
return aarch64_classify_tls_symbol (x);
[PATCH] Fix PR59993
This fixes an oversight with the (p + o1) + o2 association with
respect to abnormal-used SSA names. I've also added a single-use
test so we don't add extra computations.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2014-01-30 Richard Biener rguent...@suse.de
PR tree-optimization/59993
* tree-ssa-forwprop.c (associate_pointerplus): Check we
can propagate form the earlier stmt and avoid the transform
when the intermediate result is needed.
* gcc.dg/torture/pr59993.c: New testcase.
Index: gcc/tree-ssa-forwprop.c
===
*** gcc/tree-ssa-forwprop.c (revision 207299)
--- gcc/tree-ssa-forwprop.c (working copy)
*** associate_pointerplus (gimple_stmt_itera
*** 2926,2936
/* Associate (p +p off1) +p off2 as (p +p (off1 + off2)). */
ptr = gimple_assign_rhs1 (stmt);
off1 = gimple_assign_rhs2 (stmt);
! if (TREE_CODE (ptr) != SSA_NAME)
return false;
def_stmt = SSA_NAME_DEF_STMT (ptr);
if (!is_gimple_assign (def_stmt)
! || gimple_assign_rhs_code (def_stmt) != POINTER_PLUS_EXPR)
return false;
ptr = gimple_assign_rhs1 (def_stmt);
off2 = gimple_assign_rhs2 (def_stmt);
--- 2926,2938
/* Associate (p +p off1) +p off2 as (p +p (off1 + off2)). */
ptr = gimple_assign_rhs1 (stmt);
off1 = gimple_assign_rhs2 (stmt);
! if (TREE_CODE (ptr) != SSA_NAME
! || !has_single_use (ptr))
return false;
def_stmt = SSA_NAME_DEF_STMT (ptr);
if (!is_gimple_assign (def_stmt)
! || gimple_assign_rhs_code (def_stmt) != POINTER_PLUS_EXPR
! || !can_propagate_from (def_stmt))
return false;
ptr = gimple_assign_rhs1 (def_stmt);
off2 = gimple_assign_rhs2 (def_stmt);
Index: gcc/testsuite/gcc.dg/torture/pr59993.c
===
*** gcc/testsuite/gcc.dg/torture/pr59993.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr59993.c (working copy)
***
*** 0
--- 1,13
+ /* { dg-do compile } */
+
+ #include setjmp.h
+
+ extern int optind;
+ jmp_buf jump_buf;
+ int
+ main (int argc, char **argv)
+ {
+ foo (jump_buf, setjmp(jump_buf));
+ argv += optind;
+ bar(argv[1]);
+ }
[PATCH] S/390: Use the libgcc fp2int routine also in the biarch build
Hi,
we implement some of the IEEE float to int conversions in libgcc.
These have only been included for a native s390 32 bit build but not
for the biarch -m31 variant.
Fixed with the attached patch.
I'll commit the patch after a few days waiting for comments.
Bye,
-Andreas-
2014-01-30 Andreas Krebbel andreas.kreb...@de.ibm.com
* config.host: Include t-floattodi also for s390x.
* config/s390/32/_fixdfdi.c: Omit in 64 bit mode.
* config/s390/32/_fixsfdi.c: Likewise.
* config/s390/32/_fixtfdi.c: Likewise.
* config/s390/32/_fixunsdfdi.c: Likewise.
* config/s390/32/_fixunssfdi.c: Likewise.
* config/s390/32/_fixunstfdi.c: Likewise.
diff --git a/libgcc/config.host b/libgcc/config.host
index 65f6b0f..472c05c 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1008,7 +1008,7 @@ s390-*-linux*)
md_unwind_header=s390/linux-unwind.h
;;
s390x-*-linux*)
- tmake_file=${tmake_file} s390/t-crtstuff s390/t-linux
+ tmake_file=${tmake_file} s390/t-crtstuff s390/t-linux
s390/32/t-floattodi
md_unwind_header=s390/linux-unwind.h
;;
s390x-ibm-tpf*)
diff --git a/libgcc/config/s390/32/_fixdfdi.c b/libgcc/config/s390/32/_fixdfdi.c
index 7178c01..c55a5a1 100644
--- a/libgcc/config/s390/32/_fixdfdi.c
+++ b/libgcc/config/s390/32/_fixdfdi.c
@@ -24,6 +24,8 @@ a copy of the GCC Runtime Library Exception along with this
program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
http://www.gnu.org/licenses/. */
+#ifndef __s390x__
+
#define EXPD(fp) (((fp.l.upper) 20) 0x7FF)
#define EXCESSD1022
#define SIGNBIT0x8000
@@ -106,3 +108,4 @@ __fixdfdi (double a1)
return (SIGND (dl1) ? -l : l);
}
+#endif /* !__s390x__ */
diff --git a/libgcc/config/s390/32/_fixsfdi.c b/libgcc/config/s390/32/_fixsfdi.c
index cea3b84..725ae5b 100644
--- a/libgcc/config/s390/32/_fixsfdi.c
+++ b/libgcc/config/s390/32/_fixsfdi.c
@@ -24,6 +24,8 @@ a copy of the GCC Runtime Library Exception along with this
program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
http://www.gnu.org/licenses/. */
+#ifndef __s390x__
+
#define EXP(fp) (((fp.l) 23) 0xFF)
#define EXCESS 126
#define SIGNBIT 0x8000
@@ -102,3 +104,4 @@ __fixsfdi (float a1)
return (SIGN (fl1) ? -l : l);
}
+#endif /* !__s390x__ */
diff --git a/libgcc/config/s390/32/_fixtfdi.c b/libgcc/config/s390/32/_fixtfdi.c
index d17c516..f531972 100644
--- a/libgcc/config/s390/32/_fixtfdi.c
+++ b/libgcc/config/s390/32/_fixtfdi.c
@@ -24,6 +24,8 @@ a copy of the GCC Runtime Library Exception along with this
program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
http://www.gnu.org/licenses/. */
+#ifndef __s390x__
+
#define EXPD(fp) (((fp.l.i[0]) 16) 0x7FFF)
#define EXPONENT_BIAS 16383
#define MANTISSA_BITS 112
@@ -111,3 +113,4 @@ __fixtfdi (long double a1)
return SIGND (dl1) ? -(l -exp) : l -exp;
}
+#endif /* !__s390x__ */
diff --git a/libgcc/config/s390/32/_fixunsdfdi.c
b/libgcc/config/s390/32/_fixunsdfdi.c
index 4179b3f..64d95e6 100644
--- a/libgcc/config/s390/32/_fixunsdfdi.c
+++ b/libgcc/config/s390/32/_fixunsdfdi.c
@@ -24,6 +24,8 @@ a copy of the GCC Runtime Library Exception along with this
program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
http://www.gnu.org/licenses/. */
+#ifndef __s390x__
+
#define EXPD(fp) (((fp.l.upper) 20) 0x7FF)
#define EXCESSD1022
#define SIGNBIT0x8000
@@ -104,3 +106,4 @@ __fixunsdfdi (double a1)
return l;
}
+#endif /* !__s390x__ */
diff --git a/libgcc/config/s390/32/_fixunssfdi.c
b/libgcc/config/s390/32/_fixunssfdi.c
index 9dd3154..99bbe42 100644
--- a/libgcc/config/s390/32/_fixunssfdi.c
+++ b/libgcc/config/s390/32/_fixunssfdi.c
@@ -24,6 +24,8 @@ a copy of the GCC Runtime Library Exception along with this
program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
http://www.gnu.org/licenses/. */
+#ifndef __s390x__
+
#define EXP(fp) (((fp.l) 23) 0xFF)
#define EXCESS 126
#define SIGNBIT 0x8000
@@ -100,3 +102,4 @@ __fixunssfdi (float a1)
return l;
}
+#endif /* !__s390x__ */
diff --git a/libgcc/config/s390/32/_fixunstfdi.c
b/libgcc/config/s390/32/_fixunstfdi.c
index 00c22bf..a09ab08 100644
--- a/libgcc/config/s390/32/_fixunstfdi.c
+++ b/libgcc/config/s390/32/_fixunstfdi.c
@@ -24,6 +24,8 @@ a copy of the GCC Runtime Library Exception along with this
program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
http://www.gnu.org/licenses/. */
+#ifndef __s390x__
+
#define EXPD(fp) (((fp.l.i[0]) 16) 0x7FFF)
#define EXPONENT_BIAS 16383
#define MANTISSA_BITS 112
@@ -109,3 +111,5 @@ __fixunstfdi (long double a1)
return l -exp;
}
+
+#endif /* !__s390x__ */
[PATCH] S/390: Throw FE_INVALID exception in the fp2int libgcc routines
Hi,
our IEEE float to int conversion routines in libgcc do not throw the
FE_INVALID exceptions according to C99 Annex F.
Fixed with the attached patch.
This fixes the Glibc test-ldouble tests on s390:
Failure: llrint (inf): Exception Invalid operation not set
Failure: llrint (-inf): Exception Invalid operation not set
Failure: llrint (qNaN): Exception Invalid operation not set
Failure: llrint_tonearest (inf): Exception Invalid operation not set
Failure: llrint_tonearest (-inf): Exception Invalid operation not set
Failure: llrint_tonearest (qNaN): Exception Invalid operation not set
Failure: llrint_towardzero (inf): Exception Invalid operation not set
Failure: llrint_towardzero (-inf): Exception Invalid operation not set
Failure: llrint_towardzero (qNaN): Exception Invalid operation not set
Failure: llrint_downward (inf): Exception Invalid operation not set
Failure: llrint_downward (-inf): Exception Invalid operation not set
Failure: llrint_downward (qNaN): Exception Invalid operation not set
Failure: llrint_upward (inf): Exception Invalid operation not set
Failure: llrint_upward (-inf): Exception Invalid operation not set
Failure: llrint_upward (qNaN): Exception Invalid operation not set
Failure: llround (inf): Exception Invalid operation not set
Failure: llround (-inf): Exception Invalid operation not set
Failure: llround (qNaN): Exception Invalid operation not set
Glibc BZ: https://sourceware.org/bugzilla/show_bug.cgi?id=16449
I'll commit the patch after waiting a few days for comments.
Bye,
-Andreas-
2014-01-30 Andreas Krebbel andreas.kreb...@de.ibm.com
* config/s390/32/_fixdfdi.c: Throw invalid exception if number
cannot be represented.
* config/s390/32/_fixsfdi.c: Likewise.
* config/s390/32/_fixtfdi.c: Likewise.
* config/s390/32/_fixunsdfdi.c: Likewise.
* config/s390/32/_fixunssfdi.c: Likewise.
* config/s390/32/_fixunstfdi.c: Likewise.
commit da26827014daa447835f41bf07f3e3eb3ffe0c75
Author: Andreas Krebbel kreb...@linux.vnet.ibm.com
Date: Wed Jan 29 10:13:51 2014 +0100
S/390: libgcc: Throw INVALID exception for float-int conversions to
implement C99 Annex F.4.
diff --git a/libgcc/config/s390/32/_fixdfdi.c b/libgcc/config/s390/32/_fixdfdi.c
index 1c6954c..7178c01 100644
--- a/libgcc/config/s390/32/_fixdfdi.c
+++ b/libgcc/config/s390/32/_fixdfdi.c
@@ -46,6 +46,12 @@ union double_long {
UDItype_x ll;
};
+static __inline__ void
+fexceptdiv (float d, float e)
+{
+ __asm__ __volatile__ (debr %0,%1 : : f (d), f (e) );
+}
+
DItype_x __fixdfdi (double a1);
/* convert double to int */
@@ -73,7 +79,11 @@ __fixdfdi (double a1)
/* NaN */
if ((EXPD(dl1) == 0x7ff) (FRACD_LL(dl1) != 0)) /* NaN */
- return 0x8000ULL;
+ {
+ /* C99 Annex F.4 requires an invalid exception to be thrown. */
+ fexceptdiv (0.0, 0.0);
+ return 0x8000ULL;
+ }
/* Number big number +/- inf */
@@ -81,6 +91,8 @@ __fixdfdi (double a1)
l = (long long)163;
if (!SIGND(dl1))
l--;
+ /* C99 Annex F.4 requires an invalid exception to be thrown. */
+ fexceptdiv (0.0, 0.0);
return l;
}
diff --git a/libgcc/config/s390/32/_fixsfdi.c b/libgcc/config/s390/32/_fixsfdi.c
index eaabd18..cea3b84 100644
--- a/libgcc/config/s390/32/_fixsfdi.c
+++ b/libgcc/config/s390/32/_fixsfdi.c
@@ -43,6 +43,12 @@ union float_long
USItype_x l;
};
+static __inline__ void
+fexceptdiv (float d, float e)
+{
+ __asm__ __volatile__ (debr %0,%1 : : f (d), f (e) );
+}
+
DItype_x __fixsfdi (float a1);
/* convert double to int */
@@ -70,7 +76,11 @@ __fixsfdi (float a1)
/* NaN */
if ((EXP(fl1) == 0xff) (FRAC(fl1) != 0)) /* NaN */
- return 0x8000ULL;
+ {
+ /* C99 Annex F.4 requires an invalid exception to be thrown. */
+ fexceptdiv (0.0, 0.0);
+ return 0x8000ULL;
+ }
/* Number big number +/- inf */
@@ -78,6 +88,8 @@ __fixsfdi (float a1)
l = (long long)163;
if (!SIGN(fl1))
l--;
+ /* C99 Annex F.4 requires an invalid exception to be thrown. */
+ fexceptdiv (0.0, 0.0);
return l;
}
diff --git a/libgcc/config/s390/32/_fixtfdi.c b/libgcc/config/s390/32/_fixtfdi.c
index 51807d1..d17c516 100644
--- a/libgcc/config/s390/32/_fixtfdi.c
+++ b/libgcc/config/s390/32/_fixtfdi.c
@@ -50,6 +50,12 @@ union double_long {
UDItype_x ll[2]; /* 64 bit parts: 0 upper, 1 lower */
};
+static __inline__ void
+fexceptdiv (float d, float e)
+{
+ __asm__ __volatile__ (debr %0,%1 : : f (d), f (e) );
+}
+
DItype_x __fixtfdi (long double a1);
/* convert double to unsigned int */
@@ -77,7 +83,11 @@ __fixtfdi (long double a1)
/* NaN: All exponent bits set and a nonzero fraction. */
if ((EXPD(dl1) == 0x7fff) !FRACD_ZERO_P (dl1))
- return 0x8000ULL;
+ {
+ /* C99 Annex F.4 requires an
[PATCH] Fix PR59903
This fixes PR59903, guarding the PHI stmt case similar to the regular
one.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Thanks,
Richard.
2014-01-30 Richard Biener rguent...@suse.de
PR tree-optimization/59903
* tree-vect-loop.c (vect_transform_loop): Guard multiple-types
check properly.
* gcc.dg/torture/pr59903.c: New testcase.
Index: gcc/tree-vect-loop.c
===
*** gcc/tree-vect-loop.c(revision 207238)
--- gcc/tree-vect-loop.c(working copy)
*** vect_transform_loop (loop_vec_info loop_
*** 5869,5876
!STMT_VINFO_LIVE_P (stmt_info))
continue;
! if ((TYPE_VECTOR_SUBPARTS (STMT_VINFO_VECTYPE (stmt_info))
! != (unsigned HOST_WIDE_INT) vectorization_factor)
dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location, multiple-types.\n);
--- 5869,5877
!STMT_VINFO_LIVE_P (stmt_info))
continue;
! if (STMT_VINFO_VECTYPE (stmt_info)
! (TYPE_VECTOR_SUBPARTS (STMT_VINFO_VECTYPE (stmt_info))
! != (unsigned HOST_WIDE_INT) vectorization_factor)
dump_enabled_p ())
dump_printf_loc (MSG_NOTE, vect_location, multiple-types.\n);
Index: gcc/testsuite/gcc.dg/torture/pr59903.c
===
*** gcc/testsuite/gcc.dg/torture/pr59903.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr59903.c (working copy)
***
*** 0
--- 1,56
+ /* { dg-do compile } */
+
+ int a, b, c, d, e, f, g, h, i[3], l, m, n, o, p, q, r;
+
+ struct S0
+ {
+ int f0;
+ int f1;
+ int f2;
+ int f3;
+ } j;
+
+ static int
+ fn1 (int p1)
+ {
+ return p1 || ((p1 0) (e 1));
+ }
+
+ static struct S0
+ fn2 (struct S0 p1)
+ {
+ char s;
+ struct S0 t = {0,0,0,0};
+ int u = 2;
+ for (;;)
+ {
+ if (i[0])
+ break;
+ for (m = 0; m 4; m++)
+ for (p1.f0 = 0; p1.f0 3; p1.f0++)
+ {
+ j = t;
+ t.f3 = i[p1.f0];
+ o = b || 1 b ? 0 : a 0;
+ q = 1 % d;
+ if ((g fn1 ((1 ^ (q 1)) | n)) ^ u)
+ j.f3 |= p % 2;
+ s = j.f3 0 ? j.f3 : j.f3 1;
+ r = l = s p1.f1 * c;
+ h = p1.f1;
+ }
+ }
+ return p1;
+ }
+
+ int
+ main ()
+ {
+ for (;f;)
+ {
+ struct S0 v = {0,0,0,0};
+ fn2 (v);
+ j.f3 = 0;
+ }
+ return 0;
+ }
[Patch][AArch64] Shift right pattern fix
Hi,
This patch fixes shift right pattern, as it failed on -O0 after shift
right patch. The reason was unnecessary movement of immediate value to
a register due to type mismatch.
Patch is tested not to cause any additional regressions.
Could someone, please, approve and commit this patch, as I do not have
the rights to do so?
Kind regards,
Alex
2014-01-28 Alex Velenko alex.vele...@arm.com
gcc/
* config/aarch64/aarch64-simd.md (aarch64_ashr_simddi): Fixed.
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index 7378da9122d550f869c3e830e3e5a7681e7581f6..4dffb59e856aeaafb79007255d3b91a73ef1ef13 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -689,7 +689,7 @@
(define_expand aarch64_ashr_simddi
[(match_operand:DI 0 register_operand =w)
(match_operand:DI 1 register_operand w)
- (match_operand:QI 2 aarch64_shift_imm64_di )]
+ (match_operand:SI 2 aarch64_shift_imm64_di )]
TARGET_SIMD
{
if (INTVAL (operands[2]) == 64)
Re: [PATCH] Fix PR59993
On 01/30/14 07:51, Richard Biener wrote: This fixes an oversight with the (p + o1) + o2 association with respect to abnormal-used SSA names. I've also added a single-use test so we don't add extra computations. Bootstrap and regtest running on x86_64-unknown-linux-gnu. Richard. 2014-01-30 Richard Biener rguent...@suse.de PR tree-optimization/59993 * tree-ssa-forwprop.c (associate_pointerplus): Check we can propagate form the earlier stmt and avoid the transform when the intermediate result is needed. * gcc.dg/torture/pr59993.c: New testcase. Seems reasonable to me. jeff
Re: [PATCH][AVX512] Swap Yk and k constraints.
On Thu, Jan 30, 2014 at 11:54 AM, Ilya Tocar tocarip.in...@gmail.com wrote: Turns out that for Icc meaning of Yk and k constraints (exposed through inline asm) is opposite to current GCC implementation. As Icc with such behavior was already releases and GCC wasn't. I propose to swap meaning of Yk and k constraints. Changes are pretty mechanical. Bootstraps/passes make check/SPEC2006. Ok for trunk? Here is ChangeLog: 2014-01-30 Ilya Tocar ilya.to...@intel.com * config/i386/constraints.md (Yk): Swap meaning with k. * config/i386/i386.md (movhi_internal): Change Yk to k. (movqi_internal): Ditto. (*klogicmode): Ditto. (*andhi_1): Ditto. (*andqi_1): Ditto. (kandnmode): Ditto. (*codehi_1): Ditto. (*codeqi_1): Ditto. (kxnormode): Ditto. (kortestzhi): Ditto. (kortestchi): Ditto. (kunpckhi): Ditto. (*one_cmplhi2_1): Ditto. (*one_cmplqi2_1): Ditto. * config/i386/sse.md (): Change k to Yk. (avx512f_loadmode_mask): Ditto. (avx512f_blendmmode): Ditto. (avx512f_storemode_mask): Ditto. (avx512f_storeussemodesuffix512_mask): Ditto. (avx512f_storedqumode_mask): Ditto. (avx512f_cmpmode3mask_scalar_merge_nameround_saeonly_name): Ditto. (avx512f_ucmpmode3mask_scalar_merge_name): Ditto. (avx512f_vmcmpmode3round_saeonly_name): Ditto. (avx512f_vmcmpmode3_maskround_saeonly_name): Ditto. (avx512f_maskcmpmode3): Ditto. (avx512f_fmadd_mode_maskround_name): Ditto. (avx512f_fmadd_mode_mask3round_name): Ditto. (avx512f_fmsub_mode_maskround_name): Ditto. (avx512f_fmsub_mode_mask3round_name): Ditto. (avx512f_fnmadd_mode_maskround_name): Ditto. (avx512f_fnmadd_mode_mask3round_name): Ditto. (avx512f_fnmsub_mode_maskround_name): Ditto. (avx512f_fnmsub_mode_mask3round_name): Ditto. (avx512f_fmaddsub_mode_maskround_name): Ditto. (avx512f_fmaddsub_mode_mask3round_name): Ditto. (avx512f_fmsubadd_mode_maskround_name): Ditto. (avx512f_fmsubadd_mode_mask3round_name): Ditto. (avx512f_vextractshuffletype32x4_1_maskm): Ditto. (vec_extract_lo_mode_maskm): Ditto. (vec_extract_hi_mode_maskm): Ditto. (avx512f_vternlogmode_mask): Ditto. (avx512f_fixupimmmode_maskround_saeonly_name): Ditto. (avx512f_sfixupimmmode_maskround_saeonly_name): Ditto. (avx512f_codepmov_src_lowermode2_mask): Ditto. (avx512f_codev8div16qi2_mask): Ditto. (avx512f_codev8div16qi2_mask_store): Ditto. (avx512f_eqmode3mask_scalar_merge_name_1): Ditto. (avx512f_gtmode3mask_scalar_merge_name): Ditto. (avx512f_testmmode3mask_scalar_merge_name): Ditto. (avx512f_testnmmode3mask_scalar_merge_name): Ditto. (*avx512pf_gatherpfmodesf_mask): Ditto. (*avx512pf_gatherpfmodedf_mask): Ditto. (*avx512pf_scatterpfmodesf_mask): Ditto. (*avx512pf_scatterpfmodedf_mask): Ditto. (avx512cd_maskb_vec_dupv8di): Ditto. (avx512cd_maskw_vec_dupv16si): Ditto. (avx512f_vpermi2varmode3_maskz): Ditto. (avx512f_vpermi2varmode3_mask): Ditto. (avx512f_vpermi2varmode3_mask): Ditto. (avx512f_vpermt2varmode3_maskz): Ditto. (*avx512f_gathersimode): Ditto. (*avx512f_gathersimode_2): Ditto. (*avx512f_gatherdimode): Ditto. (*avx512f_gatherdimode_2): Ditto. (*avx512f_scattersimode): Ditto. (*avx512f_scatterdimode): Ditto. (avx512f_compressmode_mask): Ditto. (avx512f_compressstoremode_mask): Ditto. (avx512f_expandmode_mask): Ditto. * config/i386/subst.md (mask): Change k to Yk. (mask_scalar_merge): Ditto. (sd): Ditto. And for tests: 2014-01-30 Ilya Tocar ilya.to...@intel.com * gcc.target/i386/avx512f-inline-asm.c: Swap Yk and k. * gcc.target/i386/avx512f-kmovw-1.c: Also allow k0. OK. Thanks, Uros.
Re: [PATCH][AVX512] Fix rounding operand.
On Thu, Jan 30, 2014 at 1:50 PM, Ilya Tocar tocarip.in...@gmail.com wrote: I've found some problems with embedded rounding implementation. First constants are already defined in smmintrin.h, so we shouldn't redefine them. Second problem is bigger: currently rounding argument to intrinsic is one of _MM_FROUND_TO_NEAREST_INT, _MM_FROUND_TO_NEG_INF, _MM_FROUND_TO_POS_INF, _MM_FROUND_TO_ZERO, _MM_FROUND_CUR_DIRECTION, _MM_FROUND_NO_EXC, but actually it should be _MM_FROUND_NO_EXC or _MM_FROUND_CUR_DIRECTION for SAE and _MM_FROUND_TO_NEAREST_INT | _MM_FROUND_NO_EXC for rounding. That's how Icc does it, because while currently rounding implies sae it may be not true in future. I've splited rounding and sae in print_operand into 'R' and 'r' because we can't distinguish between 8 and 8 | 0. I've also run sed on tests to correct rounding arguments. While patch is huge most of it is result of sed. It bootstraps, passes make check/SPEC2006.i Ok for trunk? Here is ChangeLog. 2014-01-30 Ilya Tocar ilya.to...@intel.com * config/i386/avx512fintrin.h (_MM_FROUND_TO_NEAREST_INT), (_MM_FROUND_TO_NEG_INF), (_MM_FROUND_TO_POS_INF), (_MM_FROUND_TO_ZERO), (_MM_FROUND_CUR_DIRECTION): Are already defined in smmintrin.h, remove them. (_MM_FROUND_NO_EXC): Same as above, bit also wrong value. * config/i386/i386.c (ix86_print_operand): Split sae and rounding. * config/i386/i386.md (ROUND_SAE): Fix value. * config/i386/predicates.md (const_4_or_8_to_11_operand): New. (const48_operand): New. * config/i386/subst.md (round), (round_expand): Use const_4_or_8_to_11_operand. (round_saeonly), (round_saeonly_expand): Use const48_operand. 2014-01-30 Ilya Tocar ilya.to...@intel.com * gcc.target/i386/avx-1.c: Use correct rounding values. * gcc.target/i386/avx512f-vaddpd-1.c: Ditto. * gcc.target/i386/avx512f-vaddps-1.c: Ditto. * gcc.target/i386/avx512f-vaddsd-1.c: Ditto. * gcc.target/i386/avx512f-vaddss-1.c: Ditto. * gcc.target/i386/avx512f-vcvtdq2ps-1.c: Ditto. * gcc.target/i386/avx512f-vcvtpd2dq-1.c: Ditto. * gcc.target/i386/avx512f-vcvtpd2ps-1.c: Ditto. * gcc.target/i386/avx512f-vcvtpd2udq-1.c: Ditto. * gcc.target/i386/avx512f-vcvtps2dq-1.c: Ditto. * gcc.target/i386/avx512f-vcvtps2udq-1.c: Ditto. * gcc.target/i386/avx512f-vcvtsd2si-1.c: Ditto. * gcc.target/i386/avx512f-vcvtsd2si64-1.c: Ditto. * gcc.target/i386/avx512f-vcvtsd2ss-1.c: Ditto. * gcc.target/i386/avx512f-vcvtsd2usi-1.c: Ditto. * gcc.target/i386/avx512f-vcvtsd2usi64-1.c: Ditto. * gcc.target/i386/avx512f-vcvtsi2sd64-1.c: Ditto. * gcc.target/i386/avx512f-vcvtsi2ss-1.c: Ditto. * gcc.target/i386/avx512f-vcvtsi2ss64-1.c: Ditto. * gcc.target/i386/avx512f-vcvtss2si-1.c: Ditto. * gcc.target/i386/avx512f-vcvtss2si64-1.c: Ditto. * gcc.target/i386/avx512f-vcvtss2usi-1.c: Ditto. * gcc.target/i386/avx512f-vcvtss2usi64-1.c: Ditto. * gcc.target/i386/avx512f-vcvtudq2ps-1.c: Ditto. * gcc.target/i386/avx512f-vcvtusi2sd64-1.c: Ditto. * gcc.target/i386/avx512f-vcvtusi2ss-1.c: Ditto. * gcc.target/i386/avx512f-vcvtusi2ss64-1.c: Ditto. * gcc.target/i386/avx512f-vdivpd-1.c: Ditto. * gcc.target/i386/avx512f-vdivps-1.c: Ditto. * gcc.target/i386/avx512f-vdivsd-1.c: Ditto. * gcc.target/i386/avx512f-vdivss-1.c: Ditto. * gcc.target/i386/avx512f-vfmaddXXXpd-1.c: Ditto. * gcc.target/i386/avx512f-vfmaddXXXps-1.c: Ditto. * gcc.target/i386/avx512f-vfmaddXXXsd-1.c: Ditto. * gcc.target/i386/avx512f-vfmaddXXXss-1.c: Ditto. * gcc.target/i386/avx512f-vfmaddsubXXXpd-1.c: Ditto. * gcc.target/i386/avx512f-vfmaddsubXXXps-1.c: Ditto. * gcc.target/i386/avx512f-vfmsubXXXpd-1.c: Ditto. * gcc.target/i386/avx512f-vfmsubXXXps-1.c: Ditto. * gcc.target/i386/avx512f-vfmsubXXXsd-1.c: Ditto. * gcc.target/i386/avx512f-vfmsubXXXss-1.c: Ditto. * gcc.target/i386/avx512f-vfmsubaddXXXpd-1.c: Ditto. * gcc.target/i386/avx512f-vfmsubaddXXXps-1.c: Ditto. * gcc.target/i386/avx512f-vfnmaddXXXpd-1.c: Ditto. * gcc.target/i386/avx512f-vfnmaddXXXps-1.c: Ditto. * gcc.target/i386/avx512f-vfnmaddXXXsd-1.c: Ditto. * gcc.target/i386/avx512f-vfnmaddXXXss-1.c: Ditto. * gcc.target/i386/avx512f-vfnmsubXXXpd-1.c: Ditto. * gcc.target/i386/avx512f-vfnmsubXXXps-1.c: Ditto. * gcc.target/i386/avx512f-vfnmsubXXXsd-1.c: Ditto. * gcc.target/i386/avx512f-vfnmsubXXXss-1.c: Ditto. * gcc.target/i386/avx512f-vmulpd-1.c: Ditto. * gcc.target/i386/avx512f-vmulps-1.c: Ditto. * gcc.target/i386/avx512f-vmulsd-1.c: Ditto. * gcc.target/i386/avx512f-vmulss-1.c:
Re: RFA: MN10300: Fix typo store_movm pattern
Hi Jeff, Agreed, the naming seems awfully confusing right now. Feel free to go forward with fixing that :-) Done - thanks! Cheers Nick
[PATCH, rs6000] Clean up mergeh/mergel patterns to avoid missed optimizations
Hi,
When I implemented the mergeh/mergel code for -maltivec=be, I forgot to
add DONE; at the end of the define_expands, leading to spurious use
rtx's in the RTL stream. I discovered this while testing some other
code, where a similar problem resulted in some missed optimizations.
This patch fixes the issue.
As a side note, I had copied existing patterns that wrapped the
match_operands in uses, but I don't see any reason for that in
retrospect, so I removed the uses altogether.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions. Ok for trunk?
Thanks,
Bill
2014-01-30 Bill Schmidt wschm...@linux.vnet.ibm.com
* config/rs6000/vsx.md (vsx_mergel_mode): Remove use
specifications; add DONE.
(vsx_mergeh_mode): Likewise.
* config/rs6000/altivec.md (altivec_vmrghb): Likewise.
(altivec_vmrghh): Likewise.
(altivec_vmrghw): Likewise.
(altivec_vmrglb): Likewise.
(altivec_vmrglh): Likewise.
(altivec_vmrglw): Likewise.
Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 207262)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -1678,9 +1679,9 @@
;; Expanders for builtins
(define_expand vsx_mergel_mode
- [(use (match_operand:VSX_D 0 vsx_register_operand ))
- (use (match_operand:VSX_D 1 vsx_register_operand ))
- (use (match_operand:VSX_D 2 vsx_register_operand ))]
+ [(match_operand:VSX_D 0 vsx_register_operand )
+ (match_operand:VSX_D 1 vsx_register_operand )
+ (match_operand:VSX_D 2 vsx_register_operand )]
VECTOR_MEM_VSX_P (MODEmode)
{
rtvec v;
@@ -1700,12 +1701,13 @@
x = gen_rtx_VEC_SELECT (MODEmode, x, gen_rtx_PARALLEL (VOIDmode, v));
emit_insn (gen_rtx_SET (VOIDmode, operands[0], x));
+ DONE;
})
(define_expand vsx_mergeh_mode
- [(use (match_operand:VSX_D 0 vsx_register_operand ))
- (use (match_operand:VSX_D 1 vsx_register_operand ))
- (use (match_operand:VSX_D 2 vsx_register_operand ))]
+ [(match_operand:VSX_D 0 vsx_register_operand )
+ (match_operand:VSX_D 1 vsx_register_operand )
+ (match_operand:VSX_D 2 vsx_register_operand )]
VECTOR_MEM_VSX_P (MODEmode)
{
rtvec v;
@@ -1725,6 +1727,7 @@
x = gen_rtx_VEC_SELECT (MODEmode, x, gen_rtx_PARALLEL (VOIDmode, v));
emit_insn (gen_rtx_SET (VOIDmode, operands[0], x));
+ DONE;
})
;; V2DF/V2DI splat
Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md(revision 207262)
+++ gcc/config/rs6000/altivec.md(working copy)
@@ -843,9 +843,9 @@
[(set_attr type veccomplex)])
(define_expand altivec_vmrghb
- [(use (match_operand:V16QI 0 register_operand ))
- (use (match_operand:V16QI 1 register_operand ))
- (use (match_operand:V16QI 2 register_operand ))]
+ [(match_operand:V16QI 0 register_operand )
+ (match_operand:V16QI 1 register_operand )
+ (match_operand:V16QI 2 register_operand )]
TARGET_ALTIVEC
{
rtvec v;
@@ -871,6 +871,7 @@
x = gen_rtx_VEC_SELECT (V16QImode, x, gen_rtx_PARALLEL (VOIDmode, v));
emit_insn (gen_rtx_SET (VOIDmode, operands[0], x));
+ DONE;
})
(define_insn *altivec_vmrghb_internal
@@ -906,9 +907,9 @@
[(set_attr type vecperm)])
(define_expand altivec_vmrghh
- [(use (match_operand:V8HI 0 register_operand ))
- (use (match_operand:V8HI 1 register_operand ))
- (use (match_operand:V8HI 2 register_operand ))]
+ [(match_operand:V8HI 0 register_operand )
+ (match_operand:V8HI 1 register_operand )
+ (match_operand:V8HI 2 register_operand )]
TARGET_ALTIVEC
{
rtvec v;
@@ -930,6 +931,7 @@
x = gen_rtx_VEC_SELECT (V8HImode, x, gen_rtx_PARALLEL (VOIDmode, v));
emit_insn (gen_rtx_SET (VOIDmode, operands[0], x));
+ DONE;
})
(define_insn *altivec_vmrghh_internal
@@ -961,9 +963,9 @@
[(set_attr type vecperm)])
(define_expand altivec_vmrghw
- [(use (match_operand:V4SI 0 register_operand ))
- (use (match_operand:V4SI 1 register_operand ))
- (use (match_operand:V4SI 2 register_operand ))]
+ [(match_operand:V4SI 0 register_operand )
+ (match_operand:V4SI 1 register_operand )
+ (match_operand:V4SI 2 register_operand )]
VECTOR_MEM_ALTIVEC_P (V4SImode)
{
rtvec v;
@@ -983,6 +985,7 @@
x = gen_rtx_VEC_SELECT (V4SImode, x, gen_rtx_PARALLEL (VOIDmode, v));
emit_insn (gen_rtx_SET (VOIDmode, operands[0], x));
+ DONE;
})
(define_insn *altivec_vmrghw_internal
@@ -1029,9 +1032,9 @@
[(set_attr type vecperm)])
(define_expand altivec_vmrglb
- [(use (match_operand:V16QI 0 register_operand ))
- (use (match_operand:V16QI 1 register_operand ))
- (use (match_operand:V16QI 2 register_operand ))]
+ [(match_operand:V16QI 0 register_operand )
+ (match_operand:V16QI 1 register_operand )
+ (match_operand:V16QI 2 register_operand )]
TARGET_ALTIVEC
{
rtvec v;
@@ -1057,6 +1060,7 @@
x = gen_rtx_VEC_SELECT (V16QImode, x,
[PATCH][testsuite] Avoid division by zero.
Hi,
This patch removes possible division by zero.
Make check passes. Ok for trunk?
2014-01-30 Ilya Tocar ilya.to...@intel.com
* gcc.target/i386/m512-check.h: Use correct rounding values.
---
gcc/testsuite/gcc.target/i386/m512-check.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/m512-check.h
b/gcc/testsuite/gcc.target/i386/m512-check.h
index 3209039..8441784 100644
--- a/gcc/testsuite/gcc.target/i386/m512-check.h
+++ b/gcc/testsuite/gcc.target/i386/m512-check.h
@@ -58,7 +58,8 @@ check_rough_##UINON_TYPE (UINON_TYPE u, const VALUE_TYPE *v,
\
\
for (i = 0; i ARRAY_SIZE (u.a); i++) \
{ \
- VALUE_TYPE rel_err = (u.a[i] - v[i]) / v[i]; \
+ VALUE_TYPE rel_err; \
+ rel_err = v[i] != 0 ? (u.a[i] - v[i]) / v[i] : u.a[i]; \
if (((rel_err 0) ? -rel_err : rel_err) eps) \
{ \
err++;\
--
1.8.3.1
Re: [PATCH] Vector mode addresses
Paulo Matos pma...@broadcom.com writes: -Original Message- From: Richard Sandiford [mailto:rdsandif...@googlemail.com] Sent: 30 January 2014 12:43 To: Paulo Matos Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Vector mode addresses Paulo Matos pma...@broadcom.com writes: As a followup of the thread: http://gcc.gnu.org/ml/gcc/2014-01/msg00206.html consider the attached patch for submission. It fixes an ICE in case you try to use vector mode addresses and do not have it as mode dependent target hook. As discussed in the thread adding VECTOR_MODE_P to the target hook is a way to avoid ICE but as Richard S. mentioned it's more general to patch GCC up. But like I said, I think the VECTOR_MODE_P check should be in mode_dependent_address_p (recog.c) rather than here. If vector addresses are supported then they are mode-dependent, since the number of elements in the address mode must match the number of elements in the MEM mode. Have I misunderstood what you said: If we do support vector addresses than I think the right fix is to check VECTOR_MODE_P there. Right, in the context: Just in case: the point I was trying to make in the second paragraph was that the code in the patch only triggers (as you say) because the address isn't seen as mode-dependent. But this kind of address does look mode-dependent to me, since it only works for MEM modes that have the same number of elements as the index vector. So this does sound like a case where mode_dependent_address_p ought to return true. If we do support vector addresses than I think the right fix is to check VECTOR_MODE_P there. http://gcc.gnu.org/ml/gcc/2014-01/msg00242.html I.e. there == mode_dependent_address_p (defined in recog.c). From this I understood that you agreed that if vector_mode is supported for an address the check should be in simplify_rtx as it would prevent all target ports from adding the check to their hook, making it therefore more generic. You re-enforced this when you said: I'd just prefer it to be in generic code because I think it's a target-independent rule. No, I meant that I'd prefer it to be done in the target-independent mode_dependent_address_p function. This was in response to: Well, isn't it the case that a mem with vector mode is always mode dependent, in which case adding VECTOR_MODE_P to mode-dependent target hook would be enough making the patch not so useful? http://gcc.gnu.org/ml/gcc/2014-01/msg00248.html where it sounded like you were instead going to add the check to your target's TARGET_MODE_DEPENDENT_ADDRESS_P hook. I don't think it makes sense to defer the VECTOR_MODE_P check to the target hook since I don't know how target-independent code could attach any meaning to something like (mem:V4HI (reg:V4SI ...)) - (mem:DI (reg:V4SI ...)). Again, this is all on the basis that vector-mode addresses really are supported. Thanks, Richard
[committed] Fix up comment in test
-Wcomment warns on this.
2014-01-30 Marek Polacek pola...@redhat.com
testsuite/
* gcc.dg/Wconversion-real-integer.c: Properly end comment.
--- gcc/testsuite/gcc.dg/Wconversion-real-integer.c.mp3 2014-01-30
18:09:16.394658789 +0100
+++ gcc/testsuite/gcc.dg/Wconversion-real-integer.c 2014-01-30
18:09:24.255690080 +0100
@@ -1,7 +1,7 @@
/* Test for diagnostics for Wconversion between floating-point and
integers. */
-/* { dg-do compile }
+/* { dg-do compile } */
/* { dg-skip-if doubles are floats,ints are 16bits { avr-*-* } { * } {
} } */
/* { dg-options -std=c99 -Wconversion } */
/* { dg-require-effective-target int32plus } */
Marek
Re: [Patch, microblaze]: Fix ICE with mhard-float
On 01/22/14 02:50, David Holsgrove wrote: Hi Michael, On 22 January 2014 13:43, David Holsgrove david.holsgr...@xilinx.com wrote: -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Friday, 17 January 2014 4:36 am To: David Holsgrove; gcc-patches@gcc.gnu.org Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [Patch, microblaze]: Fix ICE with mhard-float On 11/25/13 23:50, David Holsgrove wrote: Hi Michael, I've attached the same patch based on latest gcc master. Can this be applied to gcc-4_8-branch also. thanks, David On 15 July 2013 14:53, David Holsgrove david.holsgr...@xilinx.com wrote: Add SImode to cstoresf4's comparison operator, prevents ICE during combine rtl pass with error message; internal compiler error: in simplify_subreg, at simplify-rtx.c:5725 Use ordered_comparison_operator predicate to limit operators to those fcmp can handle, and letting compiler reorder insns to accommodate unordered as necessary. Changelog entry; 2013-07-15 David Holsgrove david.holsgr...@xilinx.com * gcc/config/microblaze/microblaze.md: Fix cstoresf4 and cbranchsf4 Can this be backported to gcc-4_8-branch also? Hi David -- You mention that this patch fixes an ICE. Is there a failing test case in the GCC Test Suite? Is there a GCC PR for this ICE? If not, please add a test case to the patch. Hi Michael, Thanks for the reply. No, unfortunately there isn’t an existing test case which shows this ICE. I'm in the process of trying to recreate and distil into a small test case if possible, but the error was encountered whilst building a rather large app using microblaze linux. I've attached updated patch which includes a test case to check for this ICE. Tested on microblaze baremetal and microblazeel linux toolchains with / without my change. Updated ChangeLogs would be; gcc/ChangeLog 2014-01-22 David Holsgrove david.holsgr...@xilinx.com * config/microblaze/microblaze.md(cstoresf4, cbranchsf4): Replace comparison_operator with ordered_comparison_operator. testsuite/ChangeLog 2014-01-22 David holsgrove david.holsgr...@xilinx.com * testsuite/gcc.target/microblaze/isa/fcmp4.c: New file. thanks, David mainline: Committed revision 207311. gcc-4_8-branch: Committed revision 207313. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [PATCH] S/390: Throw FE_INVALID exception in the fp2int libgcc routines
On Thu, 30 Jan 2014, Andreas Krebbel wrote:
@@ -81,6 +91,8 @@ __fixdfdi (double a1)
l = (long long)163;
if (!SIGND(dl1))
l--;
+ /* C99 Annex F.4 requires an invalid exception to be thrown. */
+ fexceptdiv (0.0, 0.0);
return l;
My understanding of this code is that the condition exp = 11 means a
number with magnitude at least 0x1p63. If the number is exactly -0x1p63,
then the result of the most negative long long value should not involve
the invalid exception.
@@ -78,6 +88,8 @@ __fixsfdi (float a1)
l = (long long)163;
if (!SIGN(fl1))
l--;
+ /* C99 Annex F.4 requires an invalid exception to be thrown. */
+ fexceptdiv (0.0, 0.0);
return l;
Likewise.
@@ -90,6 +100,8 @@ __fixtfdi (long double a1)
or more. */
if (exp = 0)
{
+ /* C99 Annex F.4 requires an invalid exception to be thrown. */
+ fexceptdiv (0.0, 0.0);
l = 1ULL 63; /* long long min */
return SIGND (dl1) ? l : l - 1;
Likewise, except in this case there are also values whose integer part is
LLONG_MIN but whose fractional part is nonzero, for which invalid should
also not be raised.
(This complication only arises for conversion to signed integers, not for
conversion to unsigned. But for the conversions to unsigned, you need to
raise invalid for arguments = -1, which your patch doesn't seem to do.)
--
Joseph S. Myers
jos...@codesourcery.com
[PATCH] Two small i?86 *intrin* warning fixes
Hi!
While looking at some other PR, I've stripped line notes and got
pr59947.ii.bak:26330:74: error: ISO C++ forbids declaration of
‘_mm512_mask_cvtusepi64_storeu_epi32’ with no type [-fpermissive]
_mm512_mask_cvtusepi64_storeu_epi32 (void* __P, __mmask8 __M, __m512i __A)
^
pr59947.ii.bak: In function ‘float _cvtsh_ss(short unsigned int)’:
pr59947.ii.bak:30674:65: warning: narrowing conversion of ‘__S’ from ‘short
unsigned int’ to ‘short int’ inside { } [-Wnarrowing]
__v8hi __H = __extension__ (__v8hi){ __S, 0, 0, 0, 0, 0, 0, 0 };
^
warnings that would normally only show up with -Wsystem-headers.
Especially the second one looks like one worth fixing.
Ok for trunk?
2014-01-30 Jakub Jelinek ja...@redhat.com
* config/i386/f16cintrin.h (_cvtsh_ss): Avoid -Wnarrowing
warning.
* config/i386/avx512fintrin.h (_mm512_mask_cvtusepi64_storeu_epi32):
Add missing return type - void.
--- gcc/config/i386/f16cintrin.h.jj 2014-01-03 11:41:06.0 +0100
+++ gcc/config/i386/f16cintrin.h2014-01-30 18:47:28.780037184 +0100
@@ -37,7 +37,7 @@
extern __inline float __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_cvtsh_ss (unsigned short __S)
{
- __v8hi __H = __extension__ (__v8hi){ __S, 0, 0, 0, 0, 0, 0, 0 };
+ __v8hi __H = __extension__ (__v8hi){ (short) __S, 0, 0, 0, 0, 0, 0, 0 };
__v4sf __A = __builtin_ia32_vcvtph2ps (__H);
return __builtin_ia32_vec_ext_v4sf (__A, 0);
}
--- gcc/config/i386/avx512fintrin.h.jj 2014-01-28 14:03:49.0 +0100
+++ gcc/config/i386/avx512fintrin.h 2014-01-30 18:45:41.867595415 +0100
@@ -4840,7 +4840,7 @@ _mm512_cvtusepi64_epi32 (__m512i __A)
(__mmask8) -1);
}
-extern __inline
+extern __inline void
__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
_mm512_mask_cvtusepi64_storeu_epi32 (void* __P, __mmask8 __M, __m512i __A)
{
Jakub
Re: [PATCH] Two small i?86 *intrin* warning fixes
On Thu, Jan 30, 2014 at 6:52 PM, Jakub Jelinek ja...@redhat.com wrote:
While looking at some other PR, I've stripped line notes and got
pr59947.ii.bak:26330:74: error: ISO C++ forbids declaration of
'_mm512_mask_cvtusepi64_storeu_epi32' with no type [-fpermissive]
_mm512_mask_cvtusepi64_storeu_epi32 (void* __P, __mmask8 __M, __m512i __A)
^
pr59947.ii.bak: In function 'float _cvtsh_ss(short unsigned int)':
pr59947.ii.bak:30674:65: warning: narrowing conversion of '__S' from 'short
unsigned int' to 'short int' inside { } [-Wnarrowing]
__v8hi __H = __extension__ (__v8hi){ __S, 0, 0, 0, 0, 0, 0, 0 };
^
warnings that would normally only show up with -Wsystem-headers.
Especially the second one looks like one worth fixing.
Ok for trunk?
2014-01-30 Jakub Jelinek ja...@redhat.com
* config/i386/f16cintrin.h (_cvtsh_ss): Avoid -Wnarrowing
warning.
* config/i386/avx512fintrin.h (_mm512_mask_cvtusepi64_storeu_epi32):
Add missing return type - void.
OK.
Should _cvtsh_ss fix be backported to other release branches?
Thanks,
Uros.
Re: [PATCH, rs6000] Implement -maltivec=be for vec_splat builtins
On Wed, Jan 29, 2014 at 11:50 PM, Bill Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi,
This continues the series of -maltivec=be patches, this one handling
vec_splat. Since vec_splat is no longer treated as a true intrinsic,
its default behavior for little endian is changed to use right-to-left
element indexing for selecting the element to splat. With -maltivec=be
for little endian, this reverts to left-to-right element indexing.
The main changes are in altivec.md, and are quite similar to what was
done for vector merge high/low. Each of the vector splat builtins is
split into a define_expand and an _internal define_insn. The expand
uses the natural element order for the target, unless we have
-maltivec=be for an LE target, in which case the order is reversed. The
_internal insn modifies the element number on the hardware instruction
for LE to account for the instruction's big-endian bias.
For those of the vector splat instructions that are generated
internally, rather than through a builtin, a _direct insn is supplied
that generates precisely the instruction requested.
vsx.md contains the same changes for V4SI and V4SF patterns when VSX
instructions are enabled. We don't need a separate define_expand for
this one because the define_expand for altivec_vspltw is used to
generate the pattern that is recognized by vsx_xxspltw_mode. Either
vsx_xxspltw_mode or *altivec_vspltw_internal handles the pattern,
depending on whether or not VSX instructions are enabled.
Most of the changes in rs6000.c are to use the new _direct forms. There
is one other change to rs6000_expand_vector_init, where the modification
of the selector field for a generated splat pattern is removed. That is
properly handled instead by the code in altivec.md and vsx.md.
As usual, there are four new test cases to cover the various vector
types for VMX and VSX. Two existing test cases require adjustment
because of the change in the default semantics of vec_splat for little
endian.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions. Ok for trunk?
Thanks,
Bill
gcc:
2014-01-29 Bill Schmidt wschm...@linux.vnet.ibm.com
* gcc/config/rs6000/rs6000.c (rs6000_expand_vector_init): Use
gen_vsx_xxspltw_v4sf_direct instead of gen_vsx_xxspltw_v4sf;
remove element index adjustment for endian (now handled in vsx.md
and altivec.md).
(altivec_expand_vec_perm_const): Use
gen_altivec_vsplt[bhw]_direct instead of gen_altivec_vsplt[bhw].
* gcc/config/rs6000/vsx.md (UNSPEC_VSX_XXSPLTW): New unspec.
(vsx_xxspltw_mode): Adjust element index for little endian.
* gcc/config/rs6000/altivec.md (altivec_vspltb): Divide into a
define_expand and a new define_insn *altivec_vspltb_internal;
adjust for -maltivec=be on a little endian target.
(altivec_vspltb_direct): New.
(altivec_vsplth): Divide into a define_expand and a new
define_insn *altivec_vsplth_internal; adjust for -maltivec=be on a
little endian target.
(altivec_vsplth_direct): New.
(altivec_vspltw): Divide into a define_expand and a new
define_insn *altivec_vspltw_internal; adjust for -maltivec=be on a
little endian target.
(altivec_vspltw_direct): New.
(altivec_vspltsf): Divide into a define_expand and a new
define_insn *altivec_vspltsf_internal; adjust for -maltivec=be on
a little endian target.
gcc/testsuite:
2014-01-29 Bill Schmidt wschm...@linux.vnet.ibm.com
* gcc.dg/vmx/splat.c: New.
* gcc.dg/vmx/splat-vsx.c: New.
* gcc.dg/vmx/splat-be-order.c: New.
* gcc.dg/vmx/splat-vsx-be-order.c: New.
* gcc.dg/vmx/eg-5.c: Remove special casing for little endian.
* gcc.dg/vmx/sn7153.c: Add special casing for little endian.
Okay.
Thanks David
[C++] Fix endianness of character argument packs
The patch for PR 58708 fixed wide strings being passed as argument packs
but it relied on the host and target having the same endianness.
The patch below uses double_int::from_buffer to handle the case
of differing endiannesses.
Tested on mips64-linux-gnu and mipsisa64-sde-elf (with both endiannesses
in the latter case). It fixes the pr58708.C failures for big endian.
OK to install?
Thanks,
Richard
gcc/cp/
PR c++/58708
* parser.c (make_string_pack): Use double_int::from_buffer.
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c 2014-01-29 21:49:13.875748266 +
+++ gcc/cp/parser.c 2014-01-29 21:49:20.869759475 +
@@ -3808,7 +3808,8 @@ make_string_pack (tree value)
{
tree charvec;
tree argpack = make_node (NONTYPE_ARGUMENT_PACK);
- const char *str = TREE_STRING_POINTER (value);
+ const unsigned char *str
+= (const unsigned char *) TREE_STRING_POINTER (value);
int sz = TREE_INT_CST_LOW (TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (value;
int len = TREE_STRING_LENGTH (value) / sz - 1;
tree argvec = make_tree_vec (2);
@@ -3821,23 +3822,10 @@ make_string_pack (tree value)
/* Fill in CHARVEC with all of the parameters. */
charvec = make_tree_vec (len);
- if (sz == 1)
-{
- for (int i = 0; i len; ++i)
- TREE_VEC_ELT (charvec, i) = build_int_cst (str_char_type_node, str[i]);
-}
- else if (sz == 2)
-{
- const uint16_t *num = (const uint16_t *)str;
- for (int i = 0; i len; ++i)
- TREE_VEC_ELT (charvec, i) = build_int_cst (str_char_type_node, num[i]);
-}
- else if (sz == 4)
-{
- const uint32_t *num = (const uint32_t *)str;
- for (int i = 0; i len; ++i)
- TREE_VEC_ELT (charvec, i) = build_int_cst (str_char_type_node, num[i]);
-}
+ for (int i = 0; i len; ++i)
+TREE_VEC_ELT (charvec, i)
+ = double_int_to_tree (str_char_type_node,
+ double_int::from_buffer (str + i * sz, sz));
/* Build the argument packs. */
SET_ARGUMENT_PACK_ARGS (argpack, charvec);
[testsuite, committed] Fix effective target for ivdep tests
The ivdep tests use int arrays but required vect_float rather than vect_int.
Tested on mipsisa64-sde-elf, where it fixes some spurious failures for
-mips32r2/-mfp64, and on mips64-linux-gnu. Applied as obvious.
There are still some other vect failures for mipsisa64-sde-elf but
I'll look at them separately.
Thanks,
Richard
gcc/testsuite/
* g++.dg/vect/pr33426-ivdep.cc, g++.dg/vect/pr33426-ivdep-2.cc,
g++.dg/vect/pr33426-ivdep-3.cc, g++.dg/vect/pr33426-ivdep-4.cc,
gcc.dg/vect/vect-ivdep-1.c, gcc.dg/vect/vect-ivdep-2.c: Require
vect_int rather than vect_float.
Index: gcc/testsuite/g++.dg/vect/pr33426-ivdep-2.cc
===
--- gcc/testsuite/g++.dg/vect/pr33426-ivdep-2.cc2014-01-18
09:57:07.291548764 +
+++ gcc/testsuite/g++.dg/vect/pr33426-ivdep-2.cc2014-01-29
21:58:47.202500320 +
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-require-effective-target vect_float } */
+/* { dg-require-effective-target vect_int } */
/* { dg-additional-options -O3 -fopt-info-vec-optimized -fdump-tree-original
-fdump-tree-gimple } */
/* PR other/33426 */
Index: gcc/testsuite/g++.dg/vect/pr33426-ivdep-3.cc
===
--- gcc/testsuite/g++.dg/vect/pr33426-ivdep-3.cc2014-01-18
09:57:07.311548919 +
+++ gcc/testsuite/g++.dg/vect/pr33426-ivdep-3.cc2014-01-29
21:59:06.329719568 +
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-require-effective-target vect_float } */
+/* { dg-require-effective-target vect_int } */
/* { dg-additional-options -std=c++11 -O3 -fopt-info-vec-optimized
-fdump-tree-original -fdump-tree-gimple } */
/* PR other/33426 */
Index: gcc/testsuite/g++.dg/vect/pr33426-ivdep-4.cc
===
--- gcc/testsuite/g++.dg/vect/pr33426-ivdep-4.cc2014-01-18
09:57:07.312548926 +
+++ gcc/testsuite/g++.dg/vect/pr33426-ivdep-4.cc2014-01-29
21:59:14.418815930 +
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-require-effective-target vect_float } */
+/* { dg-require-effective-target vect_int } */
/* { dg-additional-options -std=c++11 -O3 -fopt-info-vec-optimized
-fdump-tree-original -fdump-tree-gimple } */
/* PR other/33426 */
Index: gcc/testsuite/g++.dg/vect/pr33426-ivdep.cc
===
--- gcc/testsuite/g++.dg/vect/pr33426-ivdep.cc 2014-01-18 09:57:07.311548919
+
+++ gcc/testsuite/g++.dg/vect/pr33426-ivdep.cc 2014-01-29 21:58:39.500415778
+
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-require-effective-target vect_float } */
+/* { dg-require-effective-target vect_int } */
/* { dg-additional-options -O3 -fopt-info-vec-optimized } */
/* PR other/33426 */
Index: gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c
===
--- gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c2014-01-18 09:57:06.969546279
+
+++ gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c2014-01-29 22:01:02.099343944
+
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-require-effective-target vect_float } */
+/* { dg-require-effective-target vect_int } */
/* { dg-additional-options -O3 -fopt-info-vec-optimized } */
/* PR other/33426 */
Index: gcc/testsuite/gcc.dg/vect/vect-ivdep-2.c
===
--- gcc/testsuite/gcc.dg/vect/vect-ivdep-2.c2014-01-18 09:57:06.970546286
+
+++ gcc/testsuite/gcc.dg/vect/vect-ivdep-2.c2014-01-29 22:01:07.113422701
+
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-require-effective-target vect_float } */
+/* { dg-require-effective-target vect_int } */
/* { dg-additional-options -O3 -fopt-info-vec-optimized } */
/* PR other/33426 */
Re: [PATCH][testsuite] Avoid division by zero.
On Thu, Jan 30, 2014 at 5:41 PM, Ilya Tocar tocarip.in...@gmail.com wrote:
This patch removes possible division by zero.
Make check passes. Ok for trunk?
2014-01-30 Ilya Tocar ilya.to...@intel.com
* gcc.target/i386/m512-check.h: Use correct rounding values.
---
gcc/testsuite/gcc.target/i386/m512-check.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/m512-check.h
b/gcc/testsuite/gcc.target/i386/m512-check.h
index 3209039..8441784 100644
--- a/gcc/testsuite/gcc.target/i386/m512-check.h
+++ b/gcc/testsuite/gcc.target/i386/m512-check.h
@@ -58,7 +58,8 @@ check_rough_##UINON_TYPE (UINON_TYPE u, const VALUE_TYPE
*v, \
\
for (i = 0; i ARRAY_SIZE (u.a); i++) \
{ \
- VALUE_TYPE rel_err = (u.a[i] - v[i]) / v[i]; \
+ VALUE_TYPE rel_err; \
+ rel_err = v[i] != 0 ? (u.a[i] - v[i]) / v[i] : u.a[i]; \
if (((rel_err 0) ? -rel_err : rel_err) eps) \
{ \
err++;\
We won't get zero from exponential function, so expecting zero result
is flawed anyway.
If we would like to introduce universal epsilon comparisons into the
testsuite, then please read [1]. Being overly pedantic, the definition
should be |(v[i] - u.a[i]) / v[i]|, as stated in [2].
[1]
http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
[2] http://en.wikipedia.org/wiki/Relative_error
Uros.
[PATCH] Fix PR59990
The following attempts to provide a fix for PR59990 - the fact
that we shouldn't use FP modes to implement memcpy in the middle-end.
It consolidates the ubsan case for BOOLEAN and ENUMERAL types which
are desirable to avoid anyway.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
Does this look reasonable?
Thanks,
Richard.
2014-01-30 Richard Biener rguent...@suse.de
PR middle-end/59990
* builtins.c (fold_builtin_memory_op): Make sure to not
use a floating-point mode or a boolean or enumeral type for
the copy operation.
* gcc.dg/torture/pr59990.c: New testcase.
Index: gcc/builtins.c
===
*** gcc/builtins.c (revision 207306)
--- gcc/builtins.c (working copy)
*** fold_builtin_memory_op (location_t loc,
*** 8851,8856
--- 8851,8862
if (!POINTER_TYPE_P (TREE_TYPE (src))
|| !POINTER_TYPE_P (TREE_TYPE (dest)))
return NULL_TREE;
+ /* In the following try to find a type that is most natural to be
+used for the memcpy source and destination and that allows
+the most optimization when memcpy is turned into a plain assignment
+using that type. In theory we could always use a char[len] type
+but that only gains us that the destination and source possibly
+no longer will have their address taken. */
/* As we fold (void *)(p + CST) to (void *)p + CST undo this here. */
if (TREE_CODE (src) == POINTER_PLUS_EXPR)
{
*** fold_builtin_memory_op (location_t loc,
*** 8886,8891
--- 8892,8932
|| TREE_ADDRESSABLE (desttype))
return NULL_TREE;
+ /* Make sure we are not copying using a floating-point mode or
+ a type whose size possibly does not match its precision. */
+ if (FLOAT_MODE_P (TYPE_MODE (desttype))
+ || TREE_CODE (desttype) == BOOLEAN_TYPE
+ || TREE_CODE (desttype) == ENUMERAL_TYPE)
+ {
+ /* A more suitable int_mode_for_mode would return a vector
+integer mode for a vector float mode or a integer complex
+mode for a float complex mode if there isn't a regular
+integer mode covering the mode of desttype. */
+ enum machine_mode mode = int_mode_for_mode (TYPE_MODE (desttype));
+ if (mode == BLKmode)
+ desttype = NULL_TREE;
+ else
+ desttype = build_nonstandard_integer_type (GET_MODE_BITSIZE (mode),
+ 1);
+ }
+ if (FLOAT_MODE_P (TYPE_MODE (srctype))
+ || TREE_CODE (srctype) == BOOLEAN_TYPE
+ || TREE_CODE (srctype) == ENUMERAL_TYPE)
+ {
+ enum machine_mode mode = int_mode_for_mode (TYPE_MODE (srctype));
+ if (mode == BLKmode)
+ srctype = NULL_TREE;
+ else
+ srctype = build_nonstandard_integer_type (GET_MODE_BITSIZE (mode),
+ 1);
+ }
+ if (!srctype)
+ srctype = desttype;
+ if (!desttype)
+ desttype = srctype;
+ if (!srctype)
+ return NULL_TREE;
+
src_align = get_pointer_alignment (src);
dest_align = get_pointer_alignment (dest);
if (dest_align TYPE_ALIGN (desttype)
*** fold_builtin_memory_op (location_t loc,
*** 8899,8927
off0 = build_int_cst (build_pointer_type_for_mode (char_type_node,
ptr_mode, true), 0);
- /* For -fsanitize={bool,enum} make sure the load isn't performed in
-the bool or enum type. */
- if (((flag_sanitize SANITIZE_BOOL)
- TREE_CODE (desttype) == BOOLEAN_TYPE)
- || ((flag_sanitize SANITIZE_ENUM)
- TREE_CODE (desttype) == ENUMERAL_TYPE))
- {
- tree destitype
- = lang_hooks.types.type_for_mode (TYPE_MODE (desttype),
- TYPE_UNSIGNED (desttype));
- desttype = build_aligned_type (destitype, TYPE_ALIGN (desttype));
- }
- if (((flag_sanitize SANITIZE_BOOL)
- TREE_CODE (srctype) == BOOLEAN_TYPE)
- || ((flag_sanitize SANITIZE_ENUM)
- TREE_CODE (srctype) == ENUMERAL_TYPE))
- {
- tree srcitype
- = lang_hooks.types.type_for_mode (TYPE_MODE (srctype),
- TYPE_UNSIGNED (srctype));
- srctype = build_aligned_type (srcitype, TYPE_ALIGN (srctype));
- }
-
destvar = dest;
STRIP_NOPS (destvar);
if (TREE_CODE (destvar) == ADDR_EXPR
--- 8940,8945
Index: gcc/testsuite/gcc.dg/torture/pr59990.c
===
*** gcc/testsuite/gcc.dg/torture/pr59990.c (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr59990.c (working copy)
***
*** 0
Re: [PATCH] Fix PR59990
On Thu, Jan 30, 2014 at 07:25:03PM +0100, Richard Biener wrote:
*** 8886,8891
--- 8892,8932
|| TREE_ADDRESSABLE (desttype))
return NULL_TREE;
+ /* Make sure we are not copying using a floating-point mode or
+ a type whose size possibly does not match its precision. */
+ if (FLOAT_MODE_P (TYPE_MODE (desttype))
+ || TREE_CODE (desttype) == BOOLEAN_TYPE
+ || TREE_CODE (desttype) == ENUMERAL_TYPE)
+ {
+ /* A more suitable int_mode_for_mode would return a vector
+ integer mode for a vector float mode or a integer complex
+ mode for a float complex mode if there isn't a regular
+ integer mode covering the mode of desttype. */
+ enum machine_mode mode = int_mode_for_mode (TYPE_MODE (desttype));
+ if (mode == BLKmode)
+ desttype = NULL_TREE;
+ else
+ desttype = build_nonstandard_integer_type (GET_MODE_BITSIZE (mode),
+1);
+ }
As I said in the PR, I think you want to do the build_aligned_type
just in case e.g. the floating point type is more aligned than the integer
or vice versa.
- {
- tree srcitype
- = lang_hooks.types.type_for_mode (TYPE_MODE (srctype),
- TYPE_UNSIGNED (srctype));
- srctype = build_aligned_type (srcitype, TYPE_ALIGN (srctype));
- }
-
Jakub
Re: PATCH: PR target/59605: Create jump_around_label only if it doesn't exist
Hi H.J.,
H.J. Lu hjl.to...@gmail.com writes:
diff --git a/gcc/testsuite/gcc.dg/pr59605.c b/gcc/testsuite/gcc.dg/pr59605.c
new file mode 100644
index 000..4556843
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr59605.c
@@ -0,0 +1,55 @@
+/* { dg-do run } */
+/* { dg-options -O2 } */
+/* { dg-additional-options -minline-stringops-dynamically { target {
i?86-*-* x86_64-*-* } } } */
+
+extern void abort (void);
+
+#define MAX_OFFSET (sizeof (long long))
+#define MAX_COPY (1024 + 8192)
+#define MAX_EXTRA (sizeof (long long))
+
+#define MAX_LENGTH (MAX_OFFSET + MAX_COPY + MAX_EXTRA)
+
+static union {
+ char buf[MAX_LENGTH];
+ long long align_int;
+ long double align_fp;
+} u;
+
+char A[MAX_LENGTH];
+
+int
+main ()
+{
+ int off, len, i;
+ char *p, *q;
+
+ for (i = 0; i MAX_LENGTH; i++)
+A[i] = 'A';
+
+ for (off = 0; off MAX_OFFSET; off++)
+for (len = 1; len MAX_COPY; len++)
+ {
+ for (i = 0; i MAX_LENGTH; i++)
+ u.buf[i] = 'a';
+
+ p = __builtin_memcpy (u.buf + off, A, len);
+ if (p != u.buf + off)
+ abort ();
+
+ q = u.buf;
+ for (i = 0; i off; i++, q++)
+ if (*q != 'a')
+ abort ();
+
+ for (i = 0; i len; i++, q++)
+ if (*q != 'A')
+ abort ();
+
+ for (i = 0; i MAX_EXTRA; i++, q++)
+ if (*q != 'a')
+ abort ();
+ }
+
+ return 0;
+}
The innermost loop bodies are executed over 6x10⁸ times on most targets
and so the test times out for me when using the GDB MIPS simulator.
I'm not sure what the best fix is though. E.g.:
1. It looks like the PR was for a compile-time failure rather than a run-time
failure, so one option might be to drop it to dg-do compile. That'd lose
a nice executable conformance test though. I don't like this option.
2. We could drop it to dg-do compile for simulator targets only. That's still
lose some conformance testing for simulator targets.
3. We could use a smaller MAX_COPY for simulator targets, which is typically
how check_effective_target_simulator is used. I'm not sure whether having
a smaller MAX_COPY would defeat the original ICE test though.
4. We could split the test into two, a dg-do compile one and a dg-do run one.
We could then do (3) on the run one.
But there are probably other alternatives too.
I'm willing to do the patch, but has anyone got any suggestions for
what would be best?
Thanks,
Richard
Re: PATCH: PR target/59605: Create jump_around_label only if it doesn't exist
On Thu, Jan 30, 2014 at 10:43 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Hi H.J.,
H.J. Lu hjl.to...@gmail.com writes:
diff --git a/gcc/testsuite/gcc.dg/pr59605.c b/gcc/testsuite/gcc.dg/pr59605.c
new file mode 100644
index 000..4556843
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr59605.c
@@ -0,0 +1,55 @@
+/* { dg-do run } */
+/* { dg-options -O2 } */
+/* { dg-additional-options -minline-stringops-dynamically { target {
i?86-*-* x86_64-*-* } } } */
+
+extern void abort (void);
+
+#define MAX_OFFSET (sizeof (long long))
+#define MAX_COPY (1024 + 8192)
+#define MAX_EXTRA (sizeof (long long))
+
+#define MAX_LENGTH (MAX_OFFSET + MAX_COPY + MAX_EXTRA)
+
+static union {
+ char buf[MAX_LENGTH];
+ long long align_int;
+ long double align_fp;
+} u;
+
+char A[MAX_LENGTH];
+
+int
+main ()
+{
+ int off, len, i;
+ char *p, *q;
+
+ for (i = 0; i MAX_LENGTH; i++)
+A[i] = 'A';
+
+ for (off = 0; off MAX_OFFSET; off++)
+for (len = 1; len MAX_COPY; len++)
+ {
+ for (i = 0; i MAX_LENGTH; i++)
+ u.buf[i] = 'a';
+
+ p = __builtin_memcpy (u.buf + off, A, len);
+ if (p != u.buf + off)
+ abort ();
+
+ q = u.buf;
+ for (i = 0; i off; i++, q++)
+ if (*q != 'a')
+ abort ();
+
+ for (i = 0; i len; i++, q++)
+ if (*q != 'A')
+ abort ();
+
+ for (i = 0; i MAX_EXTRA; i++, q++)
+ if (*q != 'a')
+ abort ();
+ }
+
+ return 0;
+}
The innermost loop bodies are executed over 6x10⁸ times on most targets
and so the test times out for me when using the GDB MIPS simulator.
I'm not sure what the best fix is though. E.g.:
1. It looks like the PR was for a compile-time failure rather than a run-time
failure, so one option might be to drop it to dg-do compile. That'd lose
a nice executable conformance test though. I don't like this option.
2. We could drop it to dg-do compile for simulator targets only. That's still
lose some conformance testing for simulator targets.
3. We could use a smaller MAX_COPY for simulator targets, which is typically
how check_effective_target_simulator is used. I'm not sure whether having
a smaller MAX_COPY would defeat the original ICE test though.
4. We could split the test into two, a dg-do compile one and a dg-do run one.
We could then do (3) on the run one.
But there are probably other alternatives too.
I'm willing to do the patch, but has anyone got any suggestions for
what would be best?
Can you reduce the loop count and still trigger the bug without
the fix?
--
H.J.
Re: [PATCH i386 8/8] [AVX-512] Add SHA support.
On Mon, Dec 30, 2013 at 4:55 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hello,
On 19 Nov 15:36, Uros Bizjak wrote:
Please also add new command options to g++.dg/other/sse-2.C and
g++.dg/other/sse-3.C
Done (to i386-[23].C).
--mavx2 -mavx512f -mavx512pf -mavx512er -mavx512cd @gol
+-mavx2 -mavx512f -mavx512pf -mavx512er -mavx512cd -msha -mno-sha @gol
No need to document negative option here.
Fxed.
I am testing patch in the bootom and will commit it tomorrow if no more inputs
and testing will pass.
--
Thanks, K
---
gcc/common/config/i386/i386-common.c | 18 -
gcc/config.gcc| 6 +-
gcc/config/i386/cpuid.h | 1 +
gcc/config/i386/driver-i386.c | 6 +-
gcc/config/i386/i386-c.c | 2 +
gcc/config/i386/i386.c| 46 -
gcc/config/i386/i386.h| 2 +
gcc/config/i386/i386.opt | 4 ++
gcc/config/i386/immintrin.h | 2 +
gcc/config/i386/shaintrin.h | 99
+++
gcc/config/i386/sse.md| 90
gcc/doc/invoke.texi | 8 ++-
gcc/testsuite/g++.dg/other/i386-2.C | 2 +-
gcc/testsuite/g++.dg/other/i386-3.C | 2 +-
gcc/testsuite/gcc.target/i386/avx-1.c | 3 +
gcc/testsuite/gcc.target/i386/i386.exp| 14
gcc/testsuite/gcc.target/i386/sha-check.h | 37 ++
gcc/testsuite/gcc.target/i386/sha1msg1-1.c| 13
gcc/testsuite/gcc.target/i386/sha1msg1-2.c| 42
gcc/testsuite/gcc.target/i386/sha1msg2-1.c| 13
gcc/testsuite/gcc.target/i386/sha1msg2-2.c| 44
gcc/testsuite/gcc.target/i386/sha1nexte-1.c | 13
gcc/testsuite/gcc.target/i386/sha1nexte-2.c | 36 ++
gcc/testsuite/gcc.target/i386/sha1rnds4-1.c | 13
gcc/testsuite/gcc.target/i386/sha1rnds4-2.c | 93 +
gcc/testsuite/gcc.target/i386/sha256msg1-1.c | 13
gcc/testsuite/gcc.target/i386/sha256msg1-2.c | 48 +
gcc/testsuite/gcc.target/i386/sha256msg2-1.c | 13
gcc/testsuite/gcc.target/i386/sha256msg2-2.c | 49 +
gcc/testsuite/gcc.target/i386/sha256rnds2-1.c | 13
gcc/testsuite/gcc.target/i386/sha256rnds2-2.c | 85 +++
gcc/testsuite/gcc.target/i386/sse-13.c| 3 +
gcc/testsuite/gcc.target/i386/sse-14.c| 6 +-
gcc/testsuite/gcc.target/i386/sse-22.c| 9 ++-
gcc/testsuite/gcc.target/i386/sse-23.c| 5 +-
35 files changed, 836 insertions(+), 17 deletions(-)
...
+
+ /* SHA */
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sha1msg1, 0, IX86_BUILTIN_SHA1MSG1,
UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI },
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sha1msg2, 0, IX86_BUILTIN_SHA1MSG2,
UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI },
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sha1nexte, 0, IX86_BUILTIN_SHA1NEXTE,
UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI },
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sha1rnds4, 0, IX86_BUILTIN_SHA1RNDS4,
UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI_INT },
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sha256msg1, 0, IX86_BUILTIN_SHA256MSG1,
UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI },
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sha256msg2, 0, IX86_BUILTIN_SHA256MSG2,
UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI },
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sha256rnds2, 0, IX86_BUILTIN_SHA256RNDS2,
UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI_V4SI },
^ Is OPTION_MASK_ISA_SSE2 intentional?
Should it be OPTION_MASK_ISA_SHA?
};
--
H.J.
Re: [C++] Fix endianness of character argument packs
OK. Jason
[jit] Check argument types within gcc_jit_context_new_call
Committed to branch dmalcolm/jit:
gcc/jit/
* internal-api.c (gcc::jit::recording::type::get_pointer):
Ensure that repeated calls yield the same type.
(gcc::jit::recording::memento_of_get_pointer::
accepts_writes_from): New.
(gcc::jit::recording::context::new_call): Move
the existing argument checking to...
* libgccjit.c (gcc_jit_context_new_call): ...here, and add
checking of the types of the arguments against the function.
(RETURN_VAL_IF_FAIL_PRINTF6): New.
(RETURN_NULL_IF_FAIL_PRINTF6): New.
* internal-api.h (gcc::jit::recording::type): New field
m_pointer_to_this_type, for use by get_pointer method.
(gcc::jit::recording::memento_of_get_pointer::
accepts_writes_from): New.
(gcc::jit::recording::function::get_param): New.
* TODO.rst (argument checking of gcc_jit_context_new_call): Done.
gcc/testsuite/
* jit.dg/test-error-call-with-mismatching-args.c: New test case.
---
gcc/jit/ChangeLog.jit | 22 ++
gcc/jit/TODO.rst | 2 -
gcc/jit/internal-api.c | 37 --
gcc/jit/internal-api.h | 9 ++-
gcc/jit/libgccjit.c| 51 +
gcc/testsuite/ChangeLog.jit| 4 +
.../jit.dg/test-error-call-with-mismatching-args.c | 85 ++
7 files changed, 184 insertions(+), 26 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-error-call-with-mismatching-args.c
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index de92fbe..58e82eb 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,27 @@
2014-01-30 David Malcolm dmalc...@redhat.com
+ * internal-api.c (gcc::jit::recording::type::get_pointer):
+ Ensure that repeated calls yield the same type.
+ (gcc::jit::recording::memento_of_get_pointer::
+ accepts_writes_from): New.
+ (gcc::jit::recording::context::new_call): Move
+ the existing argument checking to...
+
+ * libgccjit.c (gcc_jit_context_new_call): ...here, and add
+ checking of the types of the arguments against the function.
+ (RETURN_VAL_IF_FAIL_PRINTF6): New.
+ (RETURN_NULL_IF_FAIL_PRINTF6): New.
+
+ * internal-api.h (gcc::jit::recording::type): New field
+ m_pointer_to_this_type, for use by get_pointer method.
+ (gcc::jit::recording::memento_of_get_pointer::
+ accepts_writes_from): New.
+ (gcc::jit::recording::function::get_param): New.
+
+ * TODO.rst (argument checking of gcc_jit_context_new_call): Done.
+
+2014-01-30 David Malcolm dmalc...@redhat.com
+
* TODO.rst: begin a list of error-checking we could do that this
commit *doesn't* cover.
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index 79b4efa..4f16ae4 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -118,8 +118,6 @@ Initial Release
* gcc_jit_context_new_comparison: must be numeric or pointer types
-* gcc_jit_context_new_call: check the types of the args
-
* gcc_jit_context_new_array_lookup: ptr must be of pointer type;
index must be of numeric type.
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 5e72e62..58495ac 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -355,26 +355,6 @@ recording::context::new_call (recording::location *loc,
function *func,
int numargs , recording::rvalue **args)
{
- int min_num_params = func-get_params ().length ();
- bool is_variadic = func-is_variadic ();
- if (numargs min_num_params)
-{
- add_error ((gcc_jit_context_new_call:
- not enough arguments to function \%s\
- (got %i args, expected %i)),
-func-get_name ()-c_str (),
-numargs, min_num_params);
- return NULL;
-}
- if (numargs min_num_params !is_variadic)
-{
- add_error ((gcc_jit_context_new_call:
- too many arguments to function \%s\
- (got %i args, expected %i)),
-func-get_name ()-c_str (),
-numargs, min_num_params);
- return NULL;
-}
recording::rvalue *result = new call (this, loc, func, numargs, args);
record (result);
return result;
@@ -590,9 +570,12 @@ recording::location::make_debug_string ()
recording::type *
recording::type::get_pointer ()
{
- recording::type *result = new memento_of_get_pointer (this);
- m_ctxt-record (result);
- return result;
+ if (!m_pointer_to_this_type)
+{
+ m_pointer_to_this_type = new memento_of_get_pointer (this);
+ m_ctxt-record (m_pointer_to_this_type);
+}
+ return m_pointer_to_this_type;
}
recording::type *
@@ -692,6 +675,14 @@ recording::memento_of_get_type::make_debug_string ()
}
/*
Re: [PATCH] Fix PR59993
On Thu, 30 Jan 2014, Richard Biener wrote: /* Associate (p +p off1) +p off2 as (p +p (off1 + off2)). */ ptr = gimple_assign_rhs1 (stmt); off1 = gimple_assign_rhs2 (stmt); ! if (TREE_CODE (ptr) != SSA_NAME ! || !has_single_use (ptr)) return false; def_stmt = SSA_NAME_DEF_STMT (ptr); if (!is_gimple_assign (def_stmt) ! || gimple_assign_rhs_code (def_stmt) != POINTER_PLUS_EXPR ! || !can_propagate_from (def_stmt)) return false; ptr = gimple_assign_rhs1 (def_stmt); off2 = gimple_assign_rhs2 (def_stmt); Hello, we have 2 helpers get_prop_source_stmt and defcodefor_name in tree-ssa-forwprop.c, but you don't seem to like them. Do they have a particular drawback or is it just easier to rewrite the code than to remember how to use those? I am asking so I know whether I can / should use them in my future patches. -- Marc Glisse
Re: [PATCH, rs6000] Clean up mergeh/mergel patterns to avoid missed optimizations
On Thu, Jan 30, 2014 at 11:34 AM, Bill Schmidt
wschm...@linux.vnet.ibm.com wrote:
Hi,
When I implemented the mergeh/mergel code for -maltivec=be, I forgot to
add DONE; at the end of the define_expands, leading to spurious use
rtx's in the RTL stream. I discovered this while testing some other
code, where a similar problem resulted in some missed optimizations.
This patch fixes the issue.
As a side note, I had copied existing patterns that wrapped the
match_operands in uses, but I don't see any reason for that in
retrospect, so I removed the uses altogether.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions. Ok for trunk?
Thanks,
Bill
2014-01-30 Bill Schmidt wschm...@linux.vnet.ibm.com
* config/rs6000/vsx.md (vsx_mergel_mode): Remove use
specifications; add DONE.
(vsx_mergeh_mode): Likewise.
* config/rs6000/altivec.md (altivec_vmrghb): Likewise.
(altivec_vmrghh): Likewise.
(altivec_vmrghw): Likewise.
(altivec_vmrglb): Likewise.
(altivec_vmrglh): Likewise.
(altivec_vmrglw): Likewise.
Please add the DONE but do not remove the USE from the RTL
patterns. Although the DONE in the preparation statement means that
the RTL template is ignored, the template RTL should be
grammatically correct and include USE. A pattern should not
contain bare operands without some operation (at least USE or UNSPEC)
surrounding them.
Okay with that change and any other patterns that incorrectly omitted USE.
Thanks, David
Re: [PATCH] Vector mode addresses
On 30/01/14 14:01, Richard Biener wrote: I'm curious on where you are seeing MEMs with a vector mode address. What does that MEM even mean? Yes, it looks strange but it was the way we came up with to implement an instruction that loads from a pair of addresses. From what I wrote previously to Richard. We have an instruction that loads two 32 bit values into a lower and upper parts of a 64bit register using a base register and a 64 bit register used as a double index. So, r1 - [r0, r2] means: low(r1) = [r0 + low(r2)] high(r1) = [r0 + high(r2)] From the referenced mail: new_rtx: (mem:V4SI (plus:V4SI (vec_concat:V4SI (vec_concat:V2SI (const_int 0 [0]) (const_int 0 [0])) (vec_concat:V2SI (const_int 0 [0]) (const_int 0 [0]))) that should be invalid and somehow lacks the subreg:DI. The bug is where that got lost. I don't think it got lost. GCC was trying to simplify it. That's why my patch was in simplify_subreg. GCC was trying to simplify a subreg in DImode with this mem rtx as SUBREG_REG and offset 8. -- Paulo Matos
Re: [PATCH i386 8/8] [AVX-512] Add SHA support.
2014-01-30 H.J. Lu hjl.to...@gmail.com:
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sha256rnds2, 0,
IX86_BUILTIN_SHA256RNDS2, UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI_V4SI },
^ Is OPTION_MASK_ISA_SSE2 intentional?
Should it be OPTION_MASK_ISA_SHA?
--
H.J.
This was done by analogy with IX86_BUILTIN_AESENC128 builtin, etc.
I.e. IX86_BUILTIN_SHA256RNDS2 has OPTION_MASK_ISA_SSE2 in this table,
but in ix86_init_mmx_sse_builtins the builtin is defined like:
def_builtin_const (OPTION_MASK_ISA_SHA, __builtin_ia32_sha256rnds2,
V4SI_FTYPE_V4SI_V4SI_V4SI, IX86_BUILTIN_SHA256RNDS2);
-- Ilya
Re: [PATCH] Vector mode addresses
On 30/01/14 17:10, Richard Sandiford wrote: Right, in the context: Just in case: the point I was trying to make in the second paragraph was that the code in the patch only triggers (as you say) because the address isn't seen as mode-dependent. But this kind of address does look mode-dependent to me, since it only works for MEM modes that have the same number of elements as the index vector. So this does sound like a case where mode_dependent_address_p ought to return true. If we do support vector addresses than I think the right fix is to check VECTOR_MODE_P there. http://gcc.gnu.org/ml/gcc/2014-01/msg00242.html I.e. there == mode_dependent_address_p (defined in recog.c). From this I understood that you agreed that if vector_mode is supported for an address the check should be in simplify_rtx as it would prevent all target ports from adding the check to their hook, making it therefore more generic. You re-enforced this when you said: I'd just prefer it to be in generic code because I think it's a target-independent rule. No, I meant that I'd prefer it to be done in the target-independent mode_dependent_address_p function. This was in response to: Well, isn't it the case that a mem with vector mode is always mode dependent, in which case adding VECTOR_MODE_P to mode-dependent target hook would be enough making the patch not so useful? http://gcc.gnu.org/ml/gcc/2014-01/msg00248.html where it sounded like you were instead going to add the check to your target's TARGET_MODE_DEPENDENT_ADDRESS_P hook. I don't think it makes sense to defer the VECTOR_MODE_P check to the target hook since I don't know how target-independent code could attach any meaning to something like (mem:V4HI (reg:V4SI ...)) - (mem:DI (reg:V4SI ...)). Again, this is all on the basis that vector-mode addresses really are supported. Now I understand what you mean. I was pretty confused by what you meant by target-independent mode_dependent_address_p because initially I had the feeling that targetm.mode_dependent_address_p was being called in simplify_rtx but there's actually a mode_dependent_address_p in recog.c and there is where you suggested to add the check _if_ vector modes are supported. Got it. I apologize for my misunderstanding and thank you for your patience. -- Paulo Matos Thanks, Richard
[PATCH] Fix ARM dwarf2cfi ICE and unwind info issues (PR target/59575)
Hi!
For -Os, apparently ARM backend sometimes decides to push (up to 8?) dummy
registers to stack in addition to the registers that actually need to be
saved, in order to avoid extra instruction to adjust stack pointer.
These registers shouldn't be mentioned for .debug_frame though (both because
it breaks assumptions of dwarf2cfi and because it doesn't make sense), they
are either call clobbered which don't need saving (r0-r3) or for r4-r7 would
be dummy if they aren't ever modified in the current function, again, there
is no point in saving them. Even for ARM unwind info I think it doesn't
make sense to mention them in the unwind info, the patch instead adds .pad #NNN
directive after the .save to adjust sp correspondingly.
Kyrill has kindly bootstrapped/regtested this on arm, ok for trunk?
2014-01-30 Jakub Jelinek ja...@redhat.com
PR target/59575
* config/arm/arm.c (emit_multi_reg_push): Add dwarf_regs_mask argument,
don't record in REG_FRAME_RELATED_EXPR registers not set in that
bitmask.
(arm_expand_prologue): Adjust all callers.
(arm_unwind_emit_sequence): Allow saved, but not important for unwind
info, registers also at the lowest numbered registers side. Use
gcc_assert instead of abort, and SET_SRC/SET_DEST macros instead of
XEXP.
* gcc.target/arm/pr59575.c: New test.
--- gcc/config/arm/arm.c.jj 2014-01-29 10:21:11.448031616 +0100
+++ gcc/config/arm/arm.c2014-01-29 15:32:22.246381587 +0100
@@ -177,7 +177,7 @@ static rtx arm_expand_builtin (tree, rtx
static tree arm_builtin_decl (unsigned, bool);
static void emit_constant_insn (rtx cond, rtx pattern);
static rtx emit_set_insn (rtx, rtx);
-static rtx emit_multi_reg_push (unsigned long);
+static rtx emit_multi_reg_push (unsigned long, unsigned long);
static int arm_arg_partial_bytes (cumulative_args_t, enum machine_mode,
tree, bool);
static rtx arm_function_arg (cumulative_args_t, enum machine_mode,
@@ -19573,28 +19573,33 @@ arm_emit_strd_push (unsigned long saved_
/* Generate and emit an insn that we will recognize as a push_multi.
Unfortunately, since this insn does not reflect very well the actual
semantics of the operation, we need to annotate the insn for the benefit
- of DWARF2 frame unwind information. */
+ of DWARF2 frame unwind information. DWARF_REGS_MASK is a subset of
+ MASK for registers that should be annotated for DWARF2 frame unwind
+ information. */
static rtx
-emit_multi_reg_push (unsigned long mask)
+emit_multi_reg_push (unsigned long mask, unsigned long dwarf_regs_mask)
{
int num_regs = 0;
- int num_dwarf_regs;
+ int num_dwarf_regs = 0;
int i, j;
rtx par;
rtx dwarf;
int dwarf_par_index;
rtx tmp, reg;
+ /* We don't record the PC in the dwarf frame information. */
+ dwarf_regs_mask = ~(1 PC_REGNUM);
+
for (i = 0; i = LAST_ARM_REGNUM; i++)
-if (mask (1 i))
- num_regs++;
+{
+ if (mask (1 i))
+ num_regs++;
+ if (dwarf_regs_mask (1 i))
+ num_dwarf_regs++;
+}
gcc_assert (num_regs num_regs = 16);
-
- /* We don't record the PC in the dwarf frame information. */
- num_dwarf_regs = num_regs;
- if (mask (1 PC_REGNUM))
-num_dwarf_regs--;
+ gcc_assert ((dwarf_regs_mask ~mask) == 0);
/* For the body of the insn we are going to generate an UNSPEC in
parallel with several USEs. This allows the insn to be recognized
@@ -19660,14 +19665,13 @@ emit_multi_reg_push (unsigned long mask)
gen_rtvec (1, reg),
UNSPEC_PUSH_MULT));
- if (i != PC_REGNUM)
+ if (dwarf_regs_mask (1 i))
{
tmp = gen_rtx_SET (VOIDmode,
gen_frame_mem (SImode, stack_pointer_rtx),
reg);
RTX_FRAME_RELATED_P (tmp) = 1;
- XVECEXP (dwarf, 0, dwarf_par_index) = tmp;
- dwarf_par_index++;
+ XVECEXP (dwarf, 0, dwarf_par_index++) = tmp;
}
break;
@@ -19682,7 +19686,7 @@ emit_multi_reg_push (unsigned long mask)
XVECEXP (par, 0, j) = gen_rtx_USE (VOIDmode, reg);
- if (i != PC_REGNUM)
+ if (dwarf_regs_mask (1 i))
{
tmp
= gen_rtx_SET (VOIDmode,
@@ -20689,7 +20693,7 @@ arm_expand_prologue (void)
/* Interrupt functions must not corrupt any registers.
Creating a frame pointer however, corrupts the IP
register, so we must push it first. */
- emit_multi_reg_push (1 IP_REGNUM);
+ emit_multi_reg_push (1 IP_REGNUM, 1 IP_REGNUM);
/* Do not set RTX_FRAME_RELATED_P on this insn.
The dwarf stack unwinding code only wants to see one
@@ -20750,7 +20754,8 @@ arm_expand_prologue (void)
if (cfun-machine-uses_anonymous_args)
Re: [google gcc-4_8] gcov-tool: some new LIPO supports.
On Wed, Jan 29, 2014 at 4:24 PM, Rong Xu x...@google.com wrote: Hi, The attached patch adds some new features to gcov-tool. It aims to rewrite LIPO profile for reuse, debug or performance tuning purpose. -l, --modu_list file Only use the modules in this file I think in verbose mode, the tool should emit warnings when a module is trimmed due to this option. This can be used in regression test. -r, --string Replace string in path --path_substr_replace or something in that line. -u, --use_imports_file Use the grouping in import files. Is there a path in code to auto test this? -l uses only the modules in specified file to compute module grouping (and subsequent dumping). -r replaces the pattern specified in the argument. The format is: old_str1:new_str1[,old_str2:new_str2]*, only the first occurrence is replaced. -u skips the run-time module grouping computation and reuses the one comes with the profiles (which is user editable). Tested with profiles from google internal benchmarks. Also use strcasestr for case insenstive operation. David -Rong
[PATCH] Don't COND_EXEC frame related instructions (PR target/59923)
Hi!
The following testcase ICEs on arm, because ifcvt decides to conditionalize
a frame related instruction that restores a call saved register and adjusts
stack pointer (== CFA) in order to merge shrink-wrapped and
non-shrink-wrapped basic blocks. I don't see a way how to conditionalize
DW_CFA_restore in DWARF[234] unwind info, and while for the CFA adjustment
one perhaps could emit conditional expression, not sure if the condition
register is easily expressible in unwind info and whether it won't be
clobbered by later instructions.
So, this patch just refuses to put COND_EXEC on frame related instructions.
Kyrill has kindly bootstrapped/regtested this on arm, ok for trunk?
2014-01-30 Jakub Jelinek ja...@redhat.com
PR target/59923
* ifcvt.c (cond_exec_process_insns): Don't conditionalize
frame related instructions.
* gcc.target/arm/pr59923.c: New test.
--- gcc/ifcvt.c.jj 2014-01-09 08:20:55.0 +0100
+++ gcc/ifcvt.c 2014-01-29 17:16:29.912259159 +0100
@@ -338,6 +338,10 @@ cond_exec_process_insns (ce_if_block *ce
gcc_assert (NONJUMP_INSN_P (insn) || CALL_P (insn));
+ /* dwarf2out can't coope with conditional unwind info. */
+ if (reload_completed RTX_FRAME_RELATED_P (insn))
+ return FALSE;
+
/* Remove USE insns that get in the way. */
if (reload_completed GET_CODE (PATTERN (insn)) == USE)
{
--- gcc/testsuite/gcc.target/arm/pr59923.c.jj 2014-01-29 17:39:32.355116229
+0100
+++ gcc/testsuite/gcc.target/arm/pr59923.c 2014-01-29 17:39:10.0
+0100
@@ -0,0 +1,24 @@
+/* PR target/59923 */
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_thumb2_ok } */
+/* { dg-options -O2 -mcpu=cortex-a15 -fno-strict-aliasing -mthumb -g } */
+
+struct S
+{
+ void *s;
+ struct T { unsigned short a; unsigned char b[4], c[4]; } *t;
+} s;
+void bar (void *);
+
+void
+foo (struct S *x, int *y)
+{
+ if (*y 0)
+return;
+ else if (x-t-b[0] == 0x43 x-t-b[1] == 0x6d x-t-c[0] == 1)
+x-s = s;
+ else
+*y = 16384;
+ if (*y 0)
+bar (x);
+}
Jakub
[PATCH] TILE-Gx: big endian support
This patch adds support for big endian on tilegx. It's been tested on
tilegx hardware.
Most of the changes are of course in target-specific files, but I have
to touch a few shared files to support the big endian triplets. I've
split up the changes to shared/non-shared files. Can someone approve
the shared files changes? I've inlined the shared files changes for
convenience, and included the target-specific changes as an
attachment.
Thanks,
Walter
Shared files changes:
/:
* configure.ac (tilepro-*-*) Change to tilepro*-*-*.
(tilegx-*-*): Change to tilegx*-*-*.
* configure: Regenerate.
contrib/:
* config-list.mk (tilegxbe-linux-gnu): Add tilegx big endian
target.
gcc/:
* config.gcc (tilepro-*-*): Change to tilepro*-*-*.
(tilegx-*-linux*): Change to tilegx*-*-linux*; Support tilegxbe
triplet.
* doc/install.texi: Document tilegxbe-linux.
* doc/invoke.texi: Document -mbig-endian and -mlittle-endian.
libcpp/:
* configure.ac: Change tilepro triplet to tilepro*.
* configure: Regenerate.
libgcc/:
* config.host: Support tilegx* and tilepro* triplets.
Target-specific changes:
gcc/:
* common/config/tilegx/tilegx-common.c
(TARGET_DEFAULT_TARGET_FLAGS): Define.
* config/tilegx/linux.h (ASM_SPEC): Add endian_spec.
(LINK_SPEC): Ditto.
* config/tilegx/sync.md (atomic_test_and_set): Handle big endian.
* config/tilegx/tilegx.c (tilegx_return_in_msb): New.
(tilegx_gimplify_va_arg_expr): Handle big endian.
(tilegx_expand_unaligned_load): Ditto.
(tilegx_expand_unaligned_store): Ditto.
(TARGET_RETURN_IN_MSB): New.
* config/tilegx/tilegx.h (TARGET_DEFAULT): New.
(TARGET_ENDIAN_DEFAULT): New.
(TARGET_BIG_ENDIAN): Handle big endian.
(BYTES_BIG_ENDIAN): Ditto.
(WORDS_BIG_ENDIAN): Ditto.
(FLOAT_WORDS_BIG_ENDIAN): Ditto.
(ENDIAN_SPEC): New.
(EXTRA_SPECS): New.
* config/tilegx/tilegx.md (extv): Handle big endian.
(extzv): Ditto.
(insn_stn): Ditto.
(insn_stn_addbitsuffix): Ditto.
(insn_stntn): Ditto.
(insn_stntn_addbitsuffix):Ditto.
(vec_interleave_highv8qi): Handle big endian.
(vec_interleave_highv8qi_be): New.
(vec_interleave_highv8qi_le): New.
(insn_v1int_h): Handle big endian.
(vec_interleave_lowv8qi): Handle big endian.
(vec_interleave_lowv8qi_be): New.
(vec_interleave_lowv8qi_le): New.
(insn_v1int_l): Handle big endian.
(vec_interleave_highv4hi): Handle big endian.
(vec_interleave_highv4hi_be): New.
(vec_interleave_highv4hi_le): New.
(insn_v2int_h): Handle big endian.
(vec_interleave_lowv4hi): Handle big endian.
(vec_interleave_lowv4hi_be): New.
(vec_interleave_lowv4hi_le): New.
(insn_v2int_l): Handle big endian.
(vec_interleave_highv2si): Handle big endian.
(vec_interleave_highv2si_be): New.
(vec_interleave_highv2si_le): New.
(insn_v4int_h): Handle big endian.
(vec_interleave_lowv2si): Handle big endian.
(vec_interleave_lowv2si_be): New.
(vec_interleave_lowv2si_le): New.
(insn_v4int_l): Handle big endian.
* config/tilegx/tilegx.opt (mbig-endian): New option.
(mlittle-endian): New option.
libgcc/:
* config/tilegx/sfp-machine32.h (__BYTE_ORDER): Handle big endian.
* config/tilegx/sfp-machine64.h (__BYTE_ORDER): Handle big endian.
diff --git a/configure b/configure
index 749a35e..57be424 100755
--- a/configure
+++ b/configure
@@ -3815,7 +3815,7 @@ case ${target} in
tic6x-*-*)
noconfigdirs=$noconfigdirs sim
;;
- tilepro-*-* | tilegx-*-*)
+ tilepro*-*-* | tilegx*-*-*)
noconfigdirs=$noconfigdirs sim
;;
v810-*-*)
diff --git a/configure.ac b/configure.ac
index b24b33d..aaeb966 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1145,7 +1145,7 @@ case ${target} in
tic6x-*-*)
noconfigdirs=$noconfigdirs sim
;;
- tilepro-*-* | tilegx-*-*)
+ tilepro*-*-* | tilegx*-*-*)
noconfigdirs=$noconfigdirs sim
;;
v810-*-*)
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index f2d441b..4345487 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -66,7 +66,8 @@ LIST = aarch64-elf aarch64-linux-gnu \
sparc-leon3-linux-gnuOPT-enable-target=all sparc-netbsdelf \
sparc64-sun-solaris2.10OPT-with-gnu-ldOPT-with-gnu-asOPT-enable-threads=posix \
sparc-wrs-vxworks sparc64-elf sparc64-rtems sparc64-linux sparc64-freebsd6 \
- sparc64-netbsd sparc64-openbsd spu-elf tilegx-linux-gnu tilepro-linux-gnu \
+ sparc64-netbsd sparc64-openbsd spu-elf \
+ tilegx-linux-gnu tilegxbe-linux-gnu tilepro-linux-gnu \
v850e-elf v850-elf vax-linux-gnu \
vax-netbsdelf vax-openbsd x86_64-apple-darwin \
x86_64-pc-linux-gnuOPT-with-fpmath=avx \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index c3124be..bbc2611 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -494,7 +494,7 @@ tilegx*-*-*)
cpu_type=tilegx
need_64bit_hwint=yes
;;
-tilepro-*-*)
+tilepro*-*-*)
cpu_type=tilepro
[PATCH] TILE-Gx: add release note on tilegx big endian support in wwwdocs
Here is a release note item for big endian support on tilegx. Ok to
commit once that change is approved?
--- gcc-4.9/changes.html28 Jan 2014 23:57:49 - 1.54
+++ gcc-4.9/changes.html30 Jan 2014 20:46:32 -
@@ -494,6 +494,12 @@ auto incr = [](auto x) { return x++; };
will result in a warning and will not influence code generation./li
/ul
+h3 id=tilegxTILE-Gx/h3
+
+ ul
+liAdded support for big endian./li
+ /ul
+
!--
h2Documentation improvements/h2
--
Re: [PATCH] Vector mode addresses
On Thu, Jan 30, 2014 at 08:27:47PM +, Paulo Matos wrote: Yes, it looks strange but it was the way we came up with to implement an instruction that loads from a pair of addresses. From what I wrote previously to Richard. We have an instruction that loads two 32 bit values into a lower and upper parts of a 64bit register using a base register and a 64 bit register used as a double index. So, r1 - [r0, r2] means: low(r1) = [r0 + low(r2)] high(r1) = [r0 + high(r2)] That sounds like gather instruction e.g. i?86 AVX2/AVX512F has. I don't like using vector mode for the address though, i?86 uses UNSPECs and IMNSHO you should too. Or express it as vec_concat of two MEM loads where address of each one will be the base + vec_select of the vector register. Jakub
RFA (pointer-set): PATCH for c++/57899 (infinite recursion with std::bind)
In this testcase, the problem was that one instantiation of
_Mu::operator() recursively calls another one, and we were finding a
specialization of the arg parameter in local_specializations from the
first instantiation, leading to a wrong result and infinite recursion.
This patch fixes the problem by properly clearing local_specializations
when we push_to_top_level so that the second instantiation won't find
the specialization from the first one.
Also, in the past we've had issues with nested functions in templates
being able to refer to static/const variables from the enclosing
context; we've dealt with that by forcing repeated lookup, but it would
be better to keep the local_specializations from the enclosing function
around so we can find them the usual way. To that end, I've added a
pointer_map_copy.
Tested x86_64-pc-linux-gnu. Is the pointer_map_copy change OK for trunk?
2014-01-30 Jason Merrill ja...@redhat.com
PR c++/57899
gcc/
* pointer-set.c (pointer_map_copy): New.
* pointer-set.h: Declare it.
gcc/cp/
* cp-tree.h (struct saved_scope): Add x_local_specializations.
(local_specializations): New macro.
* pt.c (local_specializations): Remove variable.
(instantiate_decl): Only create new local_specializations if
we did push_to_top_level.
diff --git a/gcc/pointer-set.c b/gcc/pointer-set.c
index 8b6a732..fdd9275 100644
--- a/gcc/pointer-set.c
+++ b/gcc/pointer-set.c
@@ -192,6 +192,19 @@ pointer_map_create (void)
return result;
}
+/* Duplicate an existing pointer map. */
+struct pointer_map_t *
+pointer_map_copy (pointer_map_t *p)
+{
+ struct pointer_map_t *result = XNEW (struct pointer_map_t);
+ result-pset.n_elements = p-pset.n_elements;
+ result-pset.log_slots = p-pset.log_slots;
+ result-pset.n_slots = p-pset.n_slots;
+ result-pset.slots = XDUPVEC (const void *, p-pset.slots, p-pset.n_slots);
+ result-values = XDUPVEC (void *, p-values, p-pset.n_slots);
+ return result;
+}
+
/* Reclaims all memory associated with PMAP. */
void pointer_map_destroy (struct pointer_map_t *pmap)
{
diff --git a/gcc/pointer-set.h b/gcc/pointer-set.h
index a426534..67f6527 100644
--- a/gcc/pointer-set.h
+++ b/gcc/pointer-set.h
@@ -159,6 +159,7 @@ pointer_mapT::traverse (bool (*fn) (const void *, T *, void *), void *data)
struct pointer_map_t;
pointer_map_t *pointer_map_create (void);
+pointer_map_t *pointer_map_copy (pointer_map_t *);
void pointer_map_destroy (pointer_map_t *pmap);
void **pointer_map_contains (const pointer_map_t *pmap, const void *p);
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 7f46499..7681b27 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1049,6 +1049,8 @@ struct GTY(()) saved_scope {
cp_binding_level *class_bindings;
cp_binding_level *bindings;
+ struct pointer_map_t *x_local_specializations;
+
struct saved_scope *prev;
};
@@ -1098,6 +1100,12 @@ struct GTY(()) saved_scope {
#define previous_class_level scope_chain-x_previous_class_level
+/* A map from local variable declarations in the body of the template
+ presently being instantiated to the corresponding instantiated
+ local variables. */
+
+#define local_specializations scope_chain-x_local_specializations
+
/* A list of private types mentioned, for deferred access checking. */
extern GTY(()) struct saved_scope *scope_chain;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4a5b6cc..43aeaa0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -78,11 +78,6 @@ static GTY(()) tree saved_access_scope;
to the EXPR_STMT that is its result. */
static tree cur_stmt_expr;
-/* A map from local variable declarations in the body of the template
- presently being instantiated to the corresponding instantiated
- local variables. */
-static struct pointer_map_t *local_specializations;
-
/* True if we've recursed into fn_type_unification too many times. */
static bool excessive_deduction_depth;
@@ -19637,7 +19632,15 @@ instantiate_decl (tree d, int defer_ok,
saved_local_specializations = local_specializations;
/* Set up the list of local specializations. */
- local_specializations = pointer_map_create ();
+ if (fn_context
+ !(DECL_CLASS_SCOPE_P (d) LAMBDA_TYPE_P (DECL_CONTEXT (d
+ /* Normally in a nested function we want to be able to look up
+ variables from the enclosing function. But in a lambda we've
+ already remapped everything to refer to the closure, and we
+ might be instantiating from outside the enclosing function. */
+ local_specializations = pointer_map_copy (local_specializations);
+ else
+ local_specializations = pointer_map_create ();
/* Set up context. */
if (DECL_OMP_DECLARE_REDUCTION_P (code_pattern)
diff --git a/libstdc++-v3/testsuite/20_util/bind/57899.cc b/libstdc++-v3/testsuite/20_util/bind/57899.cc
new file mode 100644
index 000..d46d53e
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/bind/57899.cc
@@ -0,0 +1,48 @@
+// Copyright (C) 2010-2014 Free Software
Re: profile mode fix
On 01/29/2014 09:18 PM, Jonathan Wakely wrote: On 29 January 2014 20:06, François Dumont frs.dum...@gmail.com wrote: Here is the patch that simply consider 55083 as not supported except in normal mode. This is a temporary workaround for 4.9 release so I prefer not to introduce a dg-profile-mode-unsupported or something like that. Those tests will simply appear as not supported for debug and parallel mode even if they are, not a big deal, no ? But with that change we don't find out if those tests regress in debug mode :-( I prefer to just add noexcept to the profile mode move constructor, and if it throws then the program terminates. If you run out of memory when using profile mode then terminating seems reasonable to me; I don't think people are using profile mode to test how their programs handle std::bad_alloc. Put another way, if your program runs out of memory *because* of profile mode, then the results of the profiling will not give you useful data about how your program usually behaves. Using profile mode has altered the behaviour of the program. So in that situation simply calling std::terminate() makes sense. So I let you apply your patch with your comment. Do you think then that using a special allocator implementation with a one element cache to make sure that a std::unordered_map insert preceded by an erase won't throw could be interested ? If not I will simply remove it from my TODOs list. François
Re: [PATCH i386 8/8] [AVX-512] Add SHA support.
On Thu, Jan 30, 2014 at 12:36 PM, Ilya Verbin iver...@gmail.com wrote:
2014-01-30 H.J. Lu hjl.to...@gmail.com:
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sha256rnds2, 0,
IX86_BUILTIN_SHA256RNDS2, UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI_V4SI },
^ Is OPTION_MASK_ISA_SSE2
intentional?
Should it be OPTION_MASK_ISA_SHA?
--
H.J.
This was done by analogy with IX86_BUILTIN_AESENC128 builtin, etc.
I.e. IX86_BUILTIN_SHA256RNDS2 has OPTION_MASK_ISA_SSE2 in this table,
but in ix86_init_mmx_sse_builtins the builtin is defined like:
def_builtin_const (OPTION_MASK_ISA_SHA, __builtin_ia32_sha256rnds2,
V4SI_FTYPE_V4SI_V4SI_V4SI, IX86_BUILTIN_SHA256RNDS2);
I remembered it now. It is done on purpose.
--
H.J.
Re: [PATCH] Vector mode addresses
On 30/01/14 20:47, Jakub Jelinek wrote: On Thu, Jan 30, 2014 at 08:27:47PM +, Paulo Matos wrote: Yes, it looks strange but it was the way we came up with to implement an instruction that loads from a pair of addresses. From what I wrote previously to Richard. We have an instruction that loads two 32 bit values into a lower and upper parts of a 64bit register using a base register and a 64 bit register used as a double index. So, r1 - [r0, r2] means: low(r1) = [r0 + low(r2)] high(r1) = [r0 + high(r2)] That sounds like gather instruction e.g. i?86 AVX2/AVX512F has. I don't like using vector mode for the address though, i?86 uses UNSPECs and IMNSHO you should too. Or express it as vec_concat of two MEM loads where address of each one will be the base + vec_select of the vector register. Jakub I will take a closer look at our pattern and how i?86 implements it. Thanks for the advice. Paulo Matos
Re: [google gcc-4_8] gcov-tool: some new LIPO supports.
Comments are inlined. New patch attached to this email.
-Rong
On Thu, Jan 30, 2014 at 12:39 PM, Xinliang David Li davi...@google.com wrote:
On Wed, Jan 29, 2014 at 4:24 PM, Rong Xu x...@google.com wrote:
Hi,
The attached patch adds some new features to gcov-tool. It aims to
rewrite LIPO profile for reuse, debug or performance tuning purpose.
-l, --modu_list file Only use the modules in this file
I think in verbose mode, the tool should emit warnings when a module
is trimmed due to this option. This can be used in regression test.
In previous patch, this warning is emitted unconventionally (not
guarded by verbose flag).
I changed it to under verbose mode in this patch.
-r, --string Replace string in path
--path_substr_replace or something in that line.
Done.
-u, --use_imports_file Use the grouping in import files.
Is there a path in code to auto test this?
As we discussed offline. This can be verified by a separated script.
-l uses only the modules in specified file to compute module grouping
(and subsequent dumping).
-r replaces the pattern specified in the argument. The format is:
old_str1:new_str1[,old_str2:new_str2]*, only the first occurrence is
replaced.
-u skips the run-time module grouping computation and reuses the one
comes with the profiles (which is user editable).
Tested with profiles from google internal benchmarks.
Also use strcasestr for case insenstive operation.
Done.
David
-Rong
Index: gcc/gcov-tool.c
===
--- gcc/gcov-tool.c (revision 207316)
+++ gcc/gcov-tool.c (working copy)
@@ -29,6 +29,7 @@ see the files COPYING3 and COPYING.RUNTIME respect
#include coretypes.h
#include tm.h
#include intl.h
+#include hashtab.h
#include diagnostic.h
#include version.h
#include gcov-io.h
@@ -38,6 +39,7 @@ see the files COPYING3 and COPYING.RUNTIME respect
#include ftw.h
#include getopt.h
#include params.h
+#include string.h
extern int gcov_profile_merge (struct gcov_info*, struct gcov_info*, int, int);
extern int gcov_profile_normalize (struct gcov_info*, gcov_type);
@@ -47,9 +49,11 @@ extern struct gcov_info* gcov_read_profile_dir (co
extern void gcov_exit (void);
extern void set_gcov_list (struct gcov_info *);
extern void gcov_set_verbose (void);
+extern void set_use_existing_grouping (void);
+extern void set_use_modu_list (void);
+extern void lipo_set_substitute_string (const char *);
-static int verbose;
-
+/* The following defines are needed by dyn-ipa.c. */
gcov_unsigned_t __gcov_lipo_grouping_algorithm;
gcov_unsigned_t __gcov_lipo_merge_modu_edges;
gcov_unsigned_t __gcov_lipo_weak_inclusion;
@@ -60,6 +64,8 @@ gcov_unsigned_t __gcov_lipo_random_seed;
gcov_unsigned_t __gcov_lipo_dump_cgraph;
gcov_unsigned_t __gcov_lipo_propagate_scale;
+static int verbose;
+
/* Remove file NAME if it has a gcda suffix. */
static int
@@ -285,6 +291,187 @@ profile_rewrite (const char *d1, const char *out,
return 0;
}
+/* This is the hashtab entry to store a name and mod_id pair. */
+typedef struct {
+ const char *name;
+ unsigned id;
+} mod_name_id;
+
+/* Hash and comparison functions for strings. */
+
+static unsigned
+mod_name_id_htab_hash (const void *s_p)
+{
+ const char *s = ((const mod_name_id *) s_p)-name;
+ return (*htab_hash_string) (s);
+}
+
+static int
+mod_name_id_hash_eq (const void *s1_p, const void *s2_p)
+{
+ return strcmp (((const mod_name_id *) s1_p)-name,
+ ((const mod_name_id *) s2_p)-name) == 0;
+}
+
+static htab_t mod_name_id_hash_table;
+
+/* Look up an entry in the hash table. STRING is the module name.
+ CREATE controls to insert to htab or not.
+ If (*ID_P != 0), we write (*ID_P) to htab.
+ If (*ID_P == 0), we write module_id to (*ID_P).
+ return 1 if an entry is found and otherwise 0. */
+
+static int
+module_name_hash_lookup (const char *string, unsigned *id_p, int create)
+{
+ void **e;
+ mod_name_id t;
+
+ t.name = string;
+ e = htab_find_slot (mod_name_id_hash_table, t,
+ create ? INSERT : NO_INSERT);
+ if (e == NULL)
+return 0;
+ if (*e == NULL)
+{
+ *e = XNEW (mod_name_id *);
+ (*(mod_name_id **)e)-name = xstrdup (string);
+}
+ if (id_p)
+{
+ if (*id_p != 0)
+(*(mod_name_id **)e)-id = *id_p;
+ else
+*id_p = (*(mod_name_id **)e)-id;
+}
+ return 1;
+}
+
+/* Return 1 if NAME is of a source type that LIPO targets.
+ Return 0 otherwise. */
+
+static int
+is_lipo_source_type (char *name)
+{
+ char *p;
+
+ if (strcasestr (name, .c) ||
+ strcasestr (name, .cc) ||
+ strcasestr (name, .cpp) ||
+ strcasestr (name, .c++))
+return 1;
+
+ if ((p = strcasestr (name, .proto)) != NULL)
+{
+ strcpy (p, .pb.cc);
+ return 1;
+}
+
+ return 0;
+}
+
+/* Convert/process the names from dependence query to a
+ stardard
patch to fix PR59959
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59959
The patch was successfully bootstrapped and tested on x86/x86-64 and
ppc64.
Committed as rev. 207323.
2014-01-30 Vladimir Makarov vmaka...@redhat.com
PR rtl-optimization/59959
* lra-constrains.c (simplify_operand_subreg): Assign NO_REGS to
any reload of register whose subreg is invalid.
Index: lra-constraints.c
===
--- lra-constraints.c (revision 207322)
+++ lra-constraints.c (working copy)
@@ -1293,11 +1293,8 @@ simplify_operand_subreg (int nop, enum m
{
enum reg_class rclass;
- if (REG_P (reg)
- curr_insn_set != NULL_RTX
- (REG_P (SET_SRC (curr_insn_set))
- || GET_CODE (SET_SRC (curr_insn_set)) == SUBREG))
- /* There is big probability that we will get the same class
+ if (REG_P (reg))
+ /* There is a big probability that we will get the same class
for the new pseudo and we will get the same insn which
means infinite looping. So spill the new pseudo. */
rclass = NO_REGS;
Re: [PATCH] Don't COND_EXEC frame related instructions (PR target/59923)
On Thu, Jan 30, 2014 at 9:43 PM, Jakub Jelinek wrote: --- gcc/ifcvt.c.jj 2014-01-09 08:20:55.0 +0100 +++ gcc/ifcvt.c 2014-01-29 17:16:29.912259159 +0100 @@ -338,6 +338,10 @@ cond_exec_process_insns (ce_if_block *ce gcc_assert (NONJUMP_INSN_P (insn) || CALL_P (insn)); + /* dwarf2out can't coope with conditional unwind info. */ + if (reload_completed RTX_FRAME_RELATED_P (insn)) + return FALSE; + The reload_completed checks are unnecessary (also the existing one), the cond_exec path is only taken after reload. Other than that, looks OK. Ciao! Steven
[jit] Check that code labels are placed exactly once
Committed to branch dmalcolm/jit:
gcc/jit/
* TODO.rst: Label-placement is now checked.
* internal-api.c (gcc::jit::recording::context::replay_into): Give
up if any errors occur during the playback.
(gcc::jit::recording::label::replay_into): Issue an error if the
label has not yet been placed (at playback time).
(gcc::jit::recording::place_label::place_label): Move this here
from internal-api.h. Issue an error if the label has already
been placed (at recording time).
* internal-api.h (gcc::jit::recording::label): Add an
m_has_been_placed field, and make class place_label a friend so
it can set it.
(gcc::jit::recording::label::has_been_placed): New accessor.
(gcc::jit::recording::place_label::place_label): Move to
internal-api.c.
(gcc::jit::playback::context::errors_occurred): Make public, for
use by gcc::jit::recording::context::replay_into.
gcc/testsuite/
* jit.dg/test-error-label-already-placed.c: New test case.
* jit.dg/test-error-unplaced-label.c: New test case.
---
gcc/jit/ChangeLog.jit | 22
gcc/jit/TODO.rst | 6 ---
gcc/jit/internal-api.c | 25 -
gcc/jit/internal-api.h | 22
gcc/testsuite/ChangeLog.jit| 5 ++
.../jit.dg/test-error-label-already-placed.c | 59 ++
gcc/testsuite/jit.dg/test-error-unplaced-label.c | 50 ++
7 files changed, 173 insertions(+), 16 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-error-label-already-placed.c
create mode 100644 gcc/testsuite/jit.dg/test-error-unplaced-label.c
diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 58e82eb..380d345 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,5 +1,27 @@
2014-01-30 David Malcolm dmalc...@redhat.com
+ * TODO.rst: Label-placement is now checked.
+
+ * internal-api.c (gcc::jit::recording::context::replay_into): Give
+ up if any errors occur during the playback.
+ (gcc::jit::recording::label::replay_into): Issue an error if the
+ label has not yet been placed (at playback time).
+ (gcc::jit::recording::place_label::place_label): Move this here
+ from internal-api.h. Issue an error if the label has already
+ been placed (at recording time).
+
+ * internal-api.h (gcc::jit::recording::label): Add an
+ m_has_been_placed field, and make class place_label a friend so
+ it can set it.
+ (gcc::jit::recording::label::has_been_placed): New accessor.
+ (gcc::jit::recording::place_label::place_label): Move to
+ internal-api.c.
+
+ (gcc::jit::playback::context::errors_occurred): Make public, for
+ use by gcc::jit::recording::context::replay_into.
+
+2014-01-30 David Malcolm dmalc...@redhat.com
+
* internal-api.c (gcc::jit::recording::type::get_pointer):
Ensure that repeated calls yield the same type.
(gcc::jit::recording::memento_of_get_pointer::
diff --git a/gcc/jit/TODO.rst b/gcc/jit/TODO.rst
index 4f16ae4..5b6e0f7 100644
--- a/gcc/jit/TODO.rst
+++ b/gcc/jit/TODO.rst
@@ -127,18 +127,12 @@ Initial Release
* gcc_jit_function_new_local: type must not be void
-* gcc_jit_function_place_forward_label: must not already have been
- placed
-
* gcc_jit_function_add_assignment_op: check the types
* gcc_jit_function_add_conditional: boolval must be of numeric type
* gcc_jit_loop_end: verify that loops are validly nested?
-* verify that all used labels have been placed when attempting to
- compile
-
Future milestones
=
* try porting llvmpipe to gcc
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 58495ac..e061ebd 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -131,6 +131,9 @@ recording::context::replay_into (replayer *r)
if (m_parent_ctxt)
m_parent_ctxt-replay_into (r);
+ if (r-errors_occurred ())
+return;
+
/* Replay this context's saved operations into r. */
FOR_EACH_VEC_ELT (m_mementos, i, m)
{
@@ -145,6 +148,9 @@ recording::context::replay_into (replayer *r)
(void *)this, (void *)m, m-get_debug_string ());
m-replay_into (r);
+
+ if (r-errors_occurred ())
+ return;
}
}
@@ -989,8 +995,13 @@ recording::function::make_debug_string ()
/* gcc::jit::recording::label:: */
void
-recording::label::replay_into (replayer *)
+recording::label::replay_into (replayer *r)
{
+ if (!m_has_been_placed)
+{
+ r-add_error (unplaced label: %s, get_debug_string ());
+ return;
+}
set_playback_obj (m_func-playback_function ()
-new_forward_label (playback_string (m_name)));
}
@@ -1458,6 +1469,18 @@
Re: [Patch][AArch64] Shift right pattern fix
On 30 January 2014 15:28, Alex Velenko alex.vele...@arm.com wrote: Hi, This patch fixes shift right pattern, as it failed on -O0 after shift right patch. The reason was unnecessary movement of immediate value to a register due to type mismatch. Patch is tested not to cause any additional regressions. Could someone, please, approve and commit this patch, as I do not have the rights to do so? Kind regards, Alex 2014-01-28 Alex Velenko alex.vele...@arm.com gcc/ * config/aarch64/aarch64-simd.md (aarch64_ashr_simddi): Fixed. Fixed doesn't say what was changed, how about: * config/aarch64/aarch64-simd.md (aarch64_ashr_simddi): Change QI to SI. OK with that change. /Marcus
Re: [AArch64] Peepholes to generate ldp and stp instructions
Ping? On Tue, Mar 26, 2013 at 3:27 AM, Hurugalawadi, Naveen naveen.hurugalaw...@caviumnetworks.com wrote: Hi, Please find attached the patch that implements load pair(ldp) and store pair(stp) peephole for aarch64 target. Please review the same and let me know if its okay. Build and tested on aarch64-thunder-elf (using Cavium's internal simulator). No new regressions. Thanks, Naveen gcc/ 2013-03-26 Naveen H.S naveen.hurugalaw...@caviumnetworks.com * config/aarch64/aarch64.md (peephole2s to generate ldp instruction for 2 consecutive loads from memory): New. (peephole2s to generate stp instruction for 2 consecutive stores to memory in integer mode): New. (peephole2s to generate ldp instruction for 2 consecutive loads from memory in floating point mode): New. (peephole2s to generate stp instruction for 2 consecutive stores to memory in floating point mode): New.
Re: wide-int, gengtype
On Jan 1, 2014, at 7:58 PM, Mike Stump mikest...@comcast.net wrote:
On Nov 23, 2013, at 11:21 AM, Mike Stump mikest...@comcast.net wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the gengtype code.
Ok?
Ping?
We'll need a global reviewer to step forward if the gty maintainer doesn't
have the time. If no one is at one with the code, then I'd ask the SC to
solicit such an additional person to become maintainer.
Ping?
This is very small, just slightly extends gty to accept slightly more C++…
pretty easy going.
* gengtype.c: Remove include of double-int.h.
(do_typedef): Use wide-int interfaces.
(open_base_files): Add wide-int.h.
(main): Add offset_int and widest_int typedefs.
* gengtype-lex.l: Handle ^.
(CXX_KEYWORD): Add static.
* gengtype-parse.c
(require3): New.
(require_template_declaration): Handle constant template arguments
and nested templates.
* gengtype-state.c: Don't include double-int.h.
diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 86e9ca2..0c0195c 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -25,7 +25,6 @@
#include system.h
#include errors.h/* for fatal */
#include getopt.h
-#include double-int.h
#include version.h /* for version_string pkgversion_string. */
#include hashtab.h
#include xregex.h
@@ -535,7 +534,7 @@ do_typedef (const char *s, type_p t, struct fileloc *pos)
for (p = typedefs; p != NULL; p = p-next)
if (strcmp (p-name, s) == 0)
{
- if (p-type != t)
+ if (p-type != t strcmp (s, result_type) != 0)
{
error_at_line (pos, type `%s' previously defined, s);
error_at_line (p-line, previously defined here);
@@ -1766,7 +1765,7 @@ open_base_files (void)
static const char *const ifiles[] = {
config.h, system.h, coretypes.h, tm.h,
hashtab.h, splay-tree.h, obstack.h, bitmap.h, input.h,
- tree.h, rtl.h, function.h, insn-config.h, expr.h,
+ tree.h, rtl.h, wide-int.h, function.h, insn-config.h, expr.h,
hard-reg-set.h, basic-block.h, cselib.h, insn-addr.h,
optabs.h, libfuncs.h, debug.h, ggc.h, cgraph.h,
gimple.h, gimple-iterator.h, gimple-ssa.h, tree-cfg.h,
@@ -5633,6 +5632,8 @@ main (int argc, char **argv)
POS_HERE (do_scalar_typedef (REAL_VALUE_TYPE, pos));
POS_HERE (do_scalar_typedef (FIXED_VALUE_TYPE, pos));
POS_HERE (do_scalar_typedef (double_int, pos));
+ POS_HERE (do_scalar_typedef (offset_int, pos));
+ POS_HERE (do_scalar_typedef (widest_int, pos));
POS_HERE (do_scalar_typedef (uint64_t, pos));
POS_HERE (do_scalar_typedef (uint8, pos));
POS_HERE (do_scalar_typedef (uintptr_t, pos));
diff --git a/gcc/gengtype-lex.l b/gcc/gengtype-lex.l
index f46cd17..7ece2ab 100644
--- a/gcc/gengtype-lex.l
+++ b/gcc/gengtype-lex.l
@@ -57,7 +57,7 @@ ITYPE {IWORD}({WS}{IWORD})*
/* Include '::' in identifiers to capture C++ scope qualifiers. */
ID {CID}({HWS}::{HWS}{CID})*
EOID [^[:alnum:]_]
-CXX_KEYWORD inline|public:|private:|protected:|template|operator|friend
+CXX_KEYWORD inline|public:|private:|protected:|template|operator|friend|static
%x in_struct in_struct_comment in_comment
%option warn noyywrap nounput nodefault perf-report
@@ -110,6 +110,7 @@ CXX_KEYWORD
inline|public:|private:|protected:|template|operator|friend
const/{EOID} /* don't care */
{CXX_KEYWORD}/{EOID} |
~|
+^|
{
*yylval = XDUPVAR (const char, yytext, yyleng, yyleng + 1);
return IGNORABLE_CXX_KEYWORD;
diff --git a/gcc/gengtype-parse.c b/gcc/gengtype-parse.c
index 8328e3a..0a58822 100644
--- a/gcc/gengtype-parse.c
+++ b/gcc/gengtype-parse.c
@@ -197,6 +197,23 @@ require2 (int t1, int t2)
return v;
}
+/* If the next token does not have one of the codes T1, T2 or T3, report a
+ parse error; otherwise return the token's value. */
+static const char *
+require3 (int t1, int t2, int t3)
+{
+ int u = token ();
+ const char *v = advance ();
+ if (u != t1 u != t2 u != t3)
+{
+ parse_error (expected %s, %s or %s, have %s,
+ print_token (t1, 0), print_token (t2, 0),
+ print_token (t3, 0), print_token (u, v));
+ return 0;
+}
+ return v;
+}
+
/* Near-terminals. */
/* C-style string constant concatenation: STRING+
@@ -243,18 +260,45 @@ require_template_declaration (const char *tmpl_name)
str = concat (tmpl_name, , (char *) 0);
/* Read the comma-separated list of identifiers. */
- while (token () != '')
+ int depth = 1;
+ while (depth 0)
{
- const char *id = require2 (ID, ',');
+ if (token () == ENUM)
+ {
+
[C PATCH] Improve locinfo for function arguments (PR c/59963)
As promised, this patch improves column info for function arguments.
It does so by creating a veclocation_t, that carries locations of
function arguments, which is filled when parsing expression list and
then this vec is passed down to build_function_call_vec -
convert_arguments. convert_arguments loops over function arguments
and uses locations from the vec (it's not done for all functions,
some __atomic_* functions have hidden arguments and the column info
would be bogus).
Another change is that, in the C FE, the locus of a function now points
to its name, not opening (.
(For C++, the call locus points to closing paren, which is a pain
for multi-line arguments. I'll address that in another patch.)
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2014-01-30 Marek Polacek pola...@redhat.com
PR c/59963
c-family/
* c-common.c (add_atomic_size_parameter): Pass vNULL to
build_function_call_vec.
(resolve_overloaded_builtin): Likewise.
* c-common.h (build_function_call_vec): Adjust declaration.
cp/
* typeck.c (build_function_call_vec): Add dummy arg_loc parameter.
c/
* c-typeck.c (convert_lvalue_to_rvalue): Pass vNULL to
build_function_call_vec.
(build_function_call): Likewise.
(build_atomic_assign): Likewise.
(build_function_call_vec): Add arg_loc parameter. Use it.
(convert_arguments): Likewise.
(convert_for_assignment): Rename rhs_loc to expr_loc.
* c-parser.c (c_parser_attributes): Pass NULL to c_parser_expr_list.
(c_parser_objc_keywordexpr): Likewise.
(c_parser_postfix_expression_after_primary): Call
build_function_call_vec with expr_loc rather than op_loc.
Call c_parser_expr_list to fill arg_loc. Pass arg_loc to
build_function_call_vec.
(c_parser_expr_list): Add locations parameter. Fill it with locations
of function arguments.
* c-decl.c (finish_decl): Pass vNULL to build_function_call_vec.
objc/
* objc-next-runtime-abi-02.c (build_throw_stmt): Pass vNULL to
build_function_call_vec.
(finish_catch): Likewise.
(next_runtime_abi_02_get_class_reference): Likewise.
* objc-next-runtime-abi-01.c (build_objc_method_call): Pass vNULL to
build_function_call_vec.
(build_throw_stmt): Likewise.
* objc-gnu-runtime-abi-01.c: (build_objc_method_call): Pass vNULL to
build_function_call_vec.
(build_throw_stmt): Likewise.
testsuite/
* gcc.dg/pr59940.c (g): Adjust dg-warning.
(y): Adjust dg-error.
* gcc.dg/cast-function-1.c (bar): Adjust dg-warnings.
* gcc.dg/pr59963-1.c: New test.
* gcc.dg/pr59963-2.c: New test.
* gcc.dg/pr59963-3.c: New test.
--- gcc/c-family/c-common.h.mp 2014-01-30 20:41:46.634693874 +0100
+++ gcc/c-family/c-common.h 2014-01-30 20:41:50.873710404 +0100
@@ -911,8 +911,8 @@ extern void c_do_switch_warnings (splay_
extern tree build_function_call (location_t, tree, tree);
-extern tree build_function_call_vec (location_t, tree, vectree, va_gc *,
-vectree, va_gc *);
+extern tree build_function_call_vec (location_t, veclocation_t, tree,
+vectree, va_gc *, vectree, va_gc *);
extern tree resolve_overloaded_builtin (location_t, tree, vectree, va_gc *);
--- gcc/c-family/c-common.c.mp 2014-01-30 20:41:46.628693844 +0100
+++ gcc/c-family/c-common.c 2014-01-30 20:41:50.871710394 +0100
@@ -10382,7 +10382,7 @@ add_atomic_size_parameter (unsigned n, l
vec_alloc (v, len + 1);
for (z = 0; z len; z++)
v-quick_push ((*params)[z]);
- f = build_function_call_vec (loc, function, v, NULL);
+ f = build_function_call_vec (loc, vNULL, function, v, NULL);
vec_free (v);
return f;
}
@@ -10813,7 +10813,8 @@ resolve_overloaded_builtin (location_t l
return error_mark_node;
first_param = (*params)[0];
- result = build_function_call_vec (loc, new_function, params, NULL);
+ result = build_function_call_vec (loc, vNULL, new_function, params,
+ NULL);
if (result == error_mark_node)
return result;
if (orig_code != BUILT_IN_SYNC_BOOL_COMPARE_AND_SWAP_N
--- gcc/cp/typeck.c.mp 2014-01-30 20:41:46.646693930 +0100
+++ gcc/cp/typeck.c 2014-01-30 20:41:50.908710567 +0100
@@ -3357,7 +3357,7 @@ build_function_call (location_t /*loc*/,
/* Used by the C-common bits. */
tree
-build_function_call_vec (location_t /*loc*/,
+build_function_call_vec (location_t /*loc*/, veclocation_t /*arg_loc*/,
tree function, vectree, va_gc *params,
vectree, va_gc * /*origtypes*/)
{
--- gcc/objc/objc-next-runtime-abi-02.c.mp 2014-01-30 20:58:16.966442491
+0100
+++ gcc/objc/objc-next-runtime-abi-02.c 2014-01-30 20:59:29.848724052 +0100
@@ -1088,7 +1088,8
Re: [C PATCH] Improve locinfo for function arguments (PR c/59963)
On Fri, 31 Jan 2014, Marek Polacek wrote: As promised, this patch improves column info for function arguments. It does so by creating a veclocation_t, that carries locations of function arguments, which is filled when parsing expression list and then this vec is passed down to build_function_call_vec - convert_arguments. convert_arguments loops over function arguments and uses locations from the vec (it's not done for all functions, some __atomic_* functions have hidden arguments and the column info would be bogus). Another change is that, in the C FE, the locus of a function now points to its name, not opening (. (For C++, the call locus points to closing paren, which is a pain for multi-line arguments. I'll address that in another patch.) Regtested/bootstrapped on x86_64-linux, ok for trunk? OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Fixing PR60000: A bug in the vectorizer.
Wrong format. Send it again.
On Thu, Jan 30, 2014 at 4:57 PM, Cong Hou co...@google.com wrote:
Hi
PR6 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6) is caused by GCC
vectorizer. The bug appears when handling vectorization patterns. When a
pattern statement has additional new statements stored in pattern_def_seq in
vect_transform_loop(), those statements are vectorized before the pattern
statement. Once all those statements are handled, pattern_def_seq is set to
NULL. However, if the pattern statement is a store, pattern_def_seq will not
be set to NULL. In consequence, the next pattern statement will not have the
correct pattern_def_seq.
This bug can be fixed by nullifying pattern_def_seq before checking if the
vectorized statement is a store. The patch is pasted below. Bootstrapped and
tested on x86_64.
thanks,
Cong
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 95a324c..9df0d34 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2014-01-30 Cong Hou co...@google.com
+
+ PR tree-optimization/6
+ * tree-vect-loop.c (vect_transform_loop): Set pattern_def_seq to NULL
+ before checking if the vectorized statement is a store. A store
+ statement can be a pattern one.
+
2014-01-27 Jakub Jelinek ja...@redhat.com
PR bootstrap/59934
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index fa61d5c..f2ce70f 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2014-01-30 Cong Hou co...@google.com
+
+ PR tree-optimization/6
+ * g++.dg/vect/pr6.cc: New test.
+
2014-01-27 Christian Bruel christian.br...@st.com
* gcc.target/sh/torture/strncmp.c: New tests.
diff --git a/gcc/testsuite/g++.dg/vect/pr6.cc
b/gcc/testsuite/g++.dg/vect/pr6.cc
new file mode 100644
index 000..8a8bd22
--- /dev/null
+++ b/gcc/testsuite/g++.dg/vect/pr6.cc
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-additional-options -fno-tree-vrp } */
+
+void foo (bool* a, int* b)
+{
+ for (int i = 0; i 1000; ++i)
+{
+ a[i] = i % 2;
+ b[i] = i % 3;
+}
+}
+
+/* { dg-final { cleanup-tree-dump vect } } */
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 69c8d21..8c8bece 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -6044,6 +6044,10 @@ vect_transform_loop (loop_vec_info loop_vinfo)
grouped_store = false;
is_store = vect_transform_stmt (stmt, si, grouped_store, NULL,
NULL);
+
+ if (!transform_pattern_stmt gsi_end_p (pattern_def_si))
+ pattern_def_seq = NULL;
+
if (is_store)
{
if (STMT_VINFO_GROUPED_ACCESS (stmt_info))
@@ -6068,10 +6072,7 @@ vect_transform_loop (loop_vec_info loop_vinfo)
}
if (!transform_pattern_stmt gsi_end_p (pattern_def_si))
- {
- pattern_def_seq = NULL;
- gsi_next (si);
- }
+ gsi_next (si);
} /* stmts in BB */
} /* BBs in loop */
Go patch committed: Add conditional expressions to Go IR
This patch from Chris Manghane adds a conditional expression construct
to the Go frontend IR, for use in future conversion to the backend
interface. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r cc4de9df6d88 go/expressions.cc
--- a/go/expressions.cc Tue Jan 28 13:43:27 2014 -0800
+++ b/go/expressions.cc Thu Jan 30 17:55:18 2014 -0800
@@ -15040,6 +15040,103 @@
return new Label_addr_expression(label, location);
}
+// Conditional expressions.
+
+class Conditional_expression : public Expression
+{
+ public:
+ Conditional_expression(Expression* cond, Expression* then_expr,
+ Expression* else_expr, Location location)
+ : Expression(EXPRESSION_CONDITIONAL, location),
+cond_(cond), then_(then_expr), else_(else_expr)
+ {}
+
+ protected:
+ Type*
+ do_type();
+
+ void
+ do_determine_type(const Type_context*)
+ { }
+
+ Expression*
+ do_copy()
+ {
+return new Conditional_expression(this-cond_-copy(), this-then_-copy(),
+ this-else_-copy(), this-location());
+ }
+
+ tree
+ do_get_tree(Translate_context* context);
+
+ void
+ do_dump_expression(Ast_dump_context*) const;
+
+ private:
+ // The condition to be checked.
+ Expression* cond_;
+ // The expression to execute if the condition is true.
+ Expression* then_;
+ // The expression to execute if the condition is false.
+ Expression* else_;
+};
+
+// Return the type of the conditional expression.
+
+Type*
+Conditional_expression::do_type()
+{
+ Type* result_type = Type::make_void_type();
+ if (this-then_-type() == this-else_-type())
+result_type = this-then_-type();
+ else if (this-then_-is_nil_expression()
+ || this-else_-is_nil_expression())
+result_type = (!this-then_-is_nil_expression()
+ ? this-then_-type()
+ : this-else_-type());
+ return result_type;
+}
+
+// Get the backend representation of a conditional expression.
+
+tree
+Conditional_expression::do_get_tree(Translate_context* context)
+{
+ Gogo* gogo = context-gogo();
+ Btype* result_btype = this-type()-get_backend(gogo);
+ Bexpression* cond = tree_to_expr(this-cond_-get_tree(context));
+ Bexpression* then = tree_to_expr(this-then_-get_tree(context));
+ Bexpression* belse = tree_to_expr(this-else_-get_tree(context));
+ Bexpression* ret =
+ gogo-backend()-conditional_expression(result_btype, cond, then, belse,
+ this-location());
+ return expr_to_tree(ret);
+}
+
+// Dump ast representation of a conditional expression.
+
+void
+Conditional_expression::do_dump_expression(
+Ast_dump_context* ast_dump_context) const
+{
+ ast_dump_context-ostream() (;
+ ast_dump_context-dump_expression(this-cond_);
+ ast_dump_context-ostream() ? ;
+ ast_dump_context-dump_expression(this-then_);
+ ast_dump_context-ostream() : ;
+ ast_dump_context-dump_expression(this-else_);
+ ast_dump_context-ostream() ) ;
+}
+
+// Make a conditional expression.
+
+Expression*
+Expression::make_conditional(Expression* cond, Expression* then,
+ Expression* else_expr, Location location)
+{
+ return new Conditional_expression(cond, then, else_expr, location);
+}
+
// Import an expression. This comes at the end in order to see the
// various class definitions.
diff -r cc4de9df6d88 go/expressions.h
--- a/go/expressions.h Tue Jan 28 13:43:27 2014 -0800
+++ b/go/expressions.h Thu Jan 30 17:55:18 2014 -0800
@@ -106,7 +106,8 @@
EXPRESSION_INTERFACE_INFO,
EXPRESSION_STRUCT_FIELD_OFFSET,
EXPRESSION_MAP_DESCRIPTOR,
-EXPRESSION_LABEL_ADDR
+EXPRESSION_LABEL_ADDR,
+EXPRESSION_CONDITIONAL
};
Expression(Expression_classification, Location);
@@ -388,6 +389,10 @@
static Expression*
make_label_addr(Label*, Location);
+ // Make a conditional expression.
+ static Expression*
+ make_conditional(Expression*, Expression*, Expression*, Location);
+
// Return the expression classification.
Expression_classification
classification() const
[PATCH, rs6000] Handle -maltivec=be on little endian for vec_sums
Hi,
This patch adds logic for -maltivec=be with a little endian target when
generating code for the vec_sums builtin. This implements the vsumsws
instruction, which adds the four elements in the first input vector
operand to element 3 of the second input vector operand, placing the
result in element 3 of the destination vector operand.
For little endian, element 3 is the leftmost (most significant) word in
the vector register, while the instruction treats element 3 as the
rightmost (least significant) word. Since there is not a vector
shift-immediate or rotate-immediate instruction in VMX, we use a splat
instruction to get LE element 3 (BE element 0) into BE element 3 of a
scratch register for input to the vsumsws instruction. Similarly, the
result of the vsumsws instruction is then splatted from BE element 3
into BE element 0 (LE element 3) where it is expected to be by any
builtin that consumes that value. The destination register is reused
for this purpose.
As with other patches in this series, an altivec_vsumsws_direct pattern
is added for uses of vsumsws internal to GCC.
Two new test cases are added that demonstrate how the vec_vsums builtin
is expected to behave for BE, LE, and LE with -maltivec=be.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions. Is this ok for trunk?
Thanks,
Bill
gcc:
2014-01-30 Bill Schmidt wschm...@linux.vnet.ibm.com
* config/rs6000/altivec.md (UNSPEC_VSUMSWS_DIRECT): New unspec.
(altivec_vsumsws): Add handling for -maltivec=be with a little
endian target.
(altivec_vsumsws_direct): New.
(reduc_splus_mode): Call gen_altivec_vsumsws_direct instead of
gen_altivec_vsumsws.
gcc/testsuite:
2014-01-30 Bill Schmidt wschm...@linux.vnet.ibm.com
* gcc.dg/vmx/vsums.c: New.
* gcc.dg/vmx/vsums-be-order.c: New.
Index: gcc/testsuite/gcc.dg/vmx/vsums.c
===
--- gcc/testsuite/gcc.dg/vmx/vsums.c(revision 0)
+++ gcc/testsuite/gcc.dg/vmx/vsums.c(revision 0)
@@ -0,0 +1,12 @@
+#include harness.h
+
+static void test()
+{
+ vector signed int va = {-7,11,-13,17};
+ vector signed int vb = {0,0,0,128};
+
+ vector signed int vd = vec_sums (va, vb);
+ signed int r = vec_extract (vd, 3);
+
+ check (r == 136, sums);
+}
Index: gcc/testsuite/gcc.dg/vmx/vsums-be-order.c
===
--- gcc/testsuite/gcc.dg/vmx/vsums-be-order.c (revision 0)
+++ gcc/testsuite/gcc.dg/vmx/vsums-be-order.c (revision 0)
@@ -0,0 +1,19 @@
+/* { dg-options -maltivec=be -mabi=altivec -std=gnu99 -mno-vsx } */
+
+#include harness.h
+
+static void test()
+{
+ vector signed int va = {-7,11,-13,17};
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ vector signed int vb = {128,0,0,0};
+#else
+ vector signed int vb = {0,0,0,128};
+#endif
+
+ vector signed int vd = vec_sums (va, vb);
+ signed int r = vec_extract (vd, 3);
+
+ check (r == 136, sums);
+}
Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md(revision 207326)
+++ gcc/config/rs6000/altivec.md(working copy)
@@ -132,6 +132,7 @@
UNSPEC_VMRGH_DIRECT
UNSPEC_VMRGL_DIRECT
UNSPEC_VSPLT_DIRECT
+ UNSPEC_VSUMSWS_DIRECT
])
(define_c_enum unspecv
@@ -1601,6 +1602,27 @@
(unspec:V4SI [(match_operand:V4SI 1 register_operand v)
(match_operand:V4SI 2 register_operand v)]
UNSPEC_VSUMSWS))
+ (set (reg:SI 110) (unspec:SI [(const_int 0)] UNSPEC_SET_VSCR))
+ (clobber (match_scratch:V4SI 3 =v))]
+ TARGET_ALTIVEC
+{
+ if (BYTES_BIG_ENDIAN || VECTOR_ELT_ORDER_BIG)
+return vsumsws %0,%1,%2;
+ else
+return vspltw %3,%2,0\n\tvsumsws %3,%1,%3\n\tvspltw %0,%3,3;
+}
+ [(set_attr type veccomplex)
+ (set (attr length)
+ (if_then_else
+ (match_test (BYTES_BIG_ENDIAN || VECTOR_ELT_ORDER_BIG))
+ (const_string 4)
+ (const_string 12)))])
+
+(define_insn altivec_vsumsws_direct
+ [(set (match_operand:V4SI 0 register_operand =v)
+(unspec:V4SI [(match_operand:V4SI 1 register_operand v)
+ (match_operand:V4SI 2 register_operand v)]
+UNSPEC_VSUMSWS_DIRECT))
(set (reg:SI 110) (unspec:SI [(const_int 0)] UNSPEC_SET_VSCR))]
TARGET_ALTIVEC
vsumsws %0,%1,%2
@@ -2337,7 +2359,7 @@
emit_insn (gen_altivec_vspltisw (vzero, const0_rtx));
emit_insn (gen_altivec_vsum4sVI_chars (vtmp1, operands[1], vzero));
- emit_insn (gen_altivec_vsumsws (dest, vtmp1, vzero));
+ emit_insn (gen_altivec_vsumsws_direct (dest, vtmp1, vzero));
DONE;
})
Re: [PATCH, rs6000] Handle -maltivec=be on little endian for vec_sums
On Thu, 2014-01-30 at 20:42 -0600, Bill Schmidt wrote:
Hi,
This patch adds logic for -maltivec=be with a little endian target when
generating code for the vec_sums builtin. This implements the vsumsws
instruction, which adds the four elements in the first input vector
operand to element 3 of the second input vector operand, placing the
result in element 3 of the destination vector operand.
For little endian, element 3 is the leftmost (most significant) word in
the vector register, while the instruction treats element 3 as the
rightmost (least significant) word. Since there is not a vector
shift-immediate or rotate-immediate instruction in VMX, we use a splat
instruction to get LE element 3 (BE element 0) into BE element 3 of a
scratch register for input to the vsumsws instruction. Similarly, the
result of the vsumsws instruction is then splatted from BE element 3
into BE element 0 (LE element 3) where it is expected to be by any
builtin that consumes that value. The destination register is reused
for this purpose.
Brain check - I meant to say the scratch register is reused for this
purpose.
As with other patches in this series, an altivec_vsumsws_direct pattern
is added for uses of vsumsws internal to GCC.
Two new test cases are added that demonstrate how the vec_vsums builtin
is expected to behave for BE, LE, and LE with -maltivec=be.
Bootstrapped and tested on powerpc64{,le}-unknown-linux-gnu with no
regressions. Is this ok for trunk?
Thanks,
Bill
gcc:
2014-01-30 Bill Schmidt wschm...@linux.vnet.ibm.com
* config/rs6000/altivec.md (UNSPEC_VSUMSWS_DIRECT): New unspec.
(altivec_vsumsws): Add handling for -maltivec=be with a little
endian target.
(altivec_vsumsws_direct): New.
(reduc_splus_mode): Call gen_altivec_vsumsws_direct instead of
gen_altivec_vsumsws.
gcc/testsuite:
2014-01-30 Bill Schmidt wschm...@linux.vnet.ibm.com
* gcc.dg/vmx/vsums.c: New.
* gcc.dg/vmx/vsums-be-order.c: New.
Index: gcc/testsuite/gcc.dg/vmx/vsums.c
===
--- gcc/testsuite/gcc.dg/vmx/vsums.c (revision 0)
+++ gcc/testsuite/gcc.dg/vmx/vsums.c (revision 0)
@@ -0,0 +1,12 @@
+#include harness.h
+
+static void test()
+{
+ vector signed int va = {-7,11,-13,17};
+ vector signed int vb = {0,0,0,128};
+
+ vector signed int vd = vec_sums (va, vb);
+ signed int r = vec_extract (vd, 3);
+
+ check (r == 136, sums);
+}
Index: gcc/testsuite/gcc.dg/vmx/vsums-be-order.c
===
--- gcc/testsuite/gcc.dg/vmx/vsums-be-order.c (revision 0)
+++ gcc/testsuite/gcc.dg/vmx/vsums-be-order.c (revision 0)
@@ -0,0 +1,19 @@
+/* { dg-options -maltivec=be -mabi=altivec -std=gnu99 -mno-vsx } */
+
+#include harness.h
+
+static void test()
+{
+ vector signed int va = {-7,11,-13,17};
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ vector signed int vb = {128,0,0,0};
+#else
+ vector signed int vb = {0,0,0,128};
+#endif
+
+ vector signed int vd = vec_sums (va, vb);
+ signed int r = vec_extract (vd, 3);
+
+ check (r == 136, sums);
+}
Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md (revision 207326)
+++ gcc/config/rs6000/altivec.md (working copy)
@@ -132,6 +132,7 @@
UNSPEC_VMRGH_DIRECT
UNSPEC_VMRGL_DIRECT
UNSPEC_VSPLT_DIRECT
+ UNSPEC_VSUMSWS_DIRECT
])
(define_c_enum unspecv
@@ -1601,6 +1602,27 @@
(unspec:V4SI [(match_operand:V4SI 1 register_operand v)
(match_operand:V4SI 2 register_operand v)]
UNSPEC_VSUMSWS))
+ (set (reg:SI 110) (unspec:SI [(const_int 0)] UNSPEC_SET_VSCR))
+ (clobber (match_scratch:V4SI 3 =v))]
+ TARGET_ALTIVEC
+{
+ if (BYTES_BIG_ENDIAN || VECTOR_ELT_ORDER_BIG)
+return vsumsws %0,%1,%2;
+ else
+return vspltw %3,%2,0\n\tvsumsws %3,%1,%3\n\tvspltw %0,%3,3;
+}
+ [(set_attr type veccomplex)
+ (set (attr length)
+ (if_then_else
+ (match_test (BYTES_BIG_ENDIAN || VECTOR_ELT_ORDER_BIG))
+ (const_string 4)
+ (const_string 12)))])
+
+(define_insn altivec_vsumsws_direct
+ [(set (match_operand:V4SI 0 register_operand =v)
+(unspec:V4SI [(match_operand:V4SI 1 register_operand v)
+ (match_operand:V4SI 2 register_operand v)]
+ UNSPEC_VSUMSWS_DIRECT))
(set (reg:SI 110) (unspec:SI [(const_int 0)] UNSPEC_SET_VSCR))]
TARGET_ALTIVEC
vsumsws %0,%1,%2
@@ -2337,7 +2359,7 @@
emit_insn (gen_altivec_vspltisw (vzero, const0_rtx));
emit_insn (gen_altivec_vsum4sVI_chars (vtmp1, operands[1], vzero));
- emit_insn (gen_altivec_vsumsws (dest, vtmp1, vzero));
+ emit_insn (gen_altivec_vsumsws_direct (dest, vtmp1, vzero));
DONE;
})
[RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.
Hi Jason, On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote: On 02/19/2013 10:42 PM, Joel Brobecker wrote: This is useful when a DIE does not have a descriptive type attribute. In that case, the debugger needs to determine whether the unit was compiled with a compiler that normally provides that information, or not. Ah. OK, then. But I'd prefer to call it DW_AT_GNAT_use_descriptive_type, to follow the convention of keeping the vendor tag at the beginning of the name. Almost a year ago, you privately approved a small patch of mine, with the small request above. I'm sorry I let it drag so long! Here is the updated patch. include/ChangeLog: * dwarf2.def: Rename DW_AT_use_GNAT_descriptive_type into DW_AT_GNAT_use_descriptive_type. gcc/ChangeLog: * dwarf2out.c (gen_compile_unit_die): Add DW_AT_use_GNAT_descriptive_type attribute for Ada units. Tested on x86_64-linux. I should also adjust the Wiki page accordingly, but the login process keeps timing out. I know I have the right login and passwd since I succesfully reset them using the passwd recovery procedure, just in case the error was due to bad credentials. I'll try again later. If approved, I will also take care of coordinating the dwarf2.def change with binutils-gdb.git. Is this patch still OK to commit? Thank you, -- Joel
Re: RFA (pointer-set): PATCH for c++/57899 (infinite recursion with std::bind)
On 01/30/2014 04:00 PM, Jason Merrill wrote:
Also, in the past we've had issues with nested functions in templates
being able to refer to static/const variables from the enclosing
context; we've dealt with that by forcing repeated lookup, but it would
be better to keep the local_specializations from the enclosing function
around so we can find them the usual way. To that end, I've added a
pointer_map_copy.
It occurs to me that I don't really need to do this to fix the bug, and
perhaps this sort of change should wait for stage 1. So I'm checking in
this subset of the patch.
The second patch is the version I'm applying to 4.8, which has more
limited effect (and works with 4.8, which the trunk patch does not).
commit 4b96fc3d027078734055395f70b6ca81c2b661c6
Author: Jason Merrill ja...@redhat.com
Date: Thu Jan 30 13:13:55 2014 -0500
PR c++/57899
* cp-tree.h (struct saved_scope): Add x_local_specializations.
(local_specializations): New macro.
* pt.c (local_specializations): Remove variable.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 7f46499..7681b27 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -1049,6 +1049,8 @@ struct GTY(()) saved_scope {
cp_binding_level *class_bindings;
cp_binding_level *bindings;
+ struct pointer_map_t *x_local_specializations;
+
struct saved_scope *prev;
};
@@ -1098,6 +1100,12 @@ struct GTY(()) saved_scope {
#define previous_class_level scope_chain-x_previous_class_level
+/* A map from local variable declarations in the body of the template
+ presently being instantiated to the corresponding instantiated
+ local variables. */
+
+#define local_specializations scope_chain-x_local_specializations
+
/* A list of private types mentioned, for deferred access checking. */
extern GTY(()) struct saved_scope *scope_chain;
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4a5b6cc..981e2e0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -78,11 +78,6 @@ static GTY(()) tree saved_access_scope;
to the EXPR_STMT that is its result. */
static tree cur_stmt_expr;
-/* A map from local variable declarations in the body of the template
- presently being instantiated to the corresponding instantiated
- local variables. */
-static struct pointer_map_t *local_specializations;
-
/* True if we've recursed into fn_type_unification too many times. */
static bool excessive_deduction_depth;
diff --git a/libstdc++-v3/testsuite/20_util/bind/57899.cc b/libstdc++-v3/testsuite/20_util/bind/57899.cc
new file mode 100644
index 000..d46d53e
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/bind/57899.cc
@@ -0,0 +1,48 @@
+// Copyright (C) 2010-2014 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
+// http://www.gnu.org/licenses/.
+
+// 20.7.11 Function template bind
+
+// PR c++/57899
+// { dg-do compile }
+// { dg-options -std=c++11 }
+
+#include functional
+using std::bind;
+using std::placeholders::_1;
+
+struct S { int i; };
+
+struct P { S s; };
+
+struct get_s
+{
+ const S operator()(const P p) const { return p.s; }
+} gs;
+
+int gi(const S s) { return s.i; }
+
+bool cmp(int, int) { return true; }
+
+int main()
+{
+ P p{};
+ auto f1 = bind(gs, _1);
+ auto f2 = bind(gi, f1);
+ auto f3 = bind(cmp, f2, 5);
+ f3(p);
+}
commit 1ef391f60fd02b7698cb8adaa606c4c9d37d245d
Author: Jason Merrill ja...@redhat.com
Date: Thu Jan 30 13:13:55 2014 -0500
PR c++/57899
* pt.c (instantiate_template_1): Save/restore local_specializations.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index e47c2a4..f07b935 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14784,6 +14784,8 @@ instantiate_template_1 (tree tmpl, tree orig_args, tsubst_flags_t complain)
/* Instantiation of the function happens in the context of the function
template, not the context of the overload resolution we're doing. */
push_to_top_level ();
+ struct pointer_map_t *saved_local_specializations = local_specializations;
+ local_specializations = NULL;
/* If there are dependent arguments, e.g. because we're doing partial
ordering, make sure processing_template_decl stays set. */
if (uses_template_parms (targ_ptr))
@@ -14799,6 +14801,7 @@ instantiate_template_1 (tree tmpl, tree orig_args, tsubst_flags_t complain)
targ_ptr, complain, gen_tmpl);
if (DECL_CLASS_SCOPE_P
[msp430] more new libgloss feature support
More code to support new libgloss features. This one lets the linker
leave out the call to exit() in crt0 (and thus all the exit() code
also) if main() doesn't exit. Committed.
* config/msp430/msp430.h (LIB_SPEC): Add -lcrt
* config/msp430/msp430.md (msp430_refsym_need_exit): New.
* config/msp430/msp430.c (msp430_expand_epilogue): Call it
whenever main() has an epilogue.
Index: config/msp430/msp430.md
===
--- config/msp430/msp430.md (revision 207333)
+++ config/msp430/msp430.md (working copy)
@@ -42,12 +42,14 @@
UNS_DINT
UNS_EINT
UNS_PUSH_INTR
UNS_POP_INTR
UNS_BIC_SR
UNS_BIS_SR
+
+ UNS_REFSYM_NEED_EXIT
])
(include predicates.md)
(include constraints.md)
(define_mode_iterator QHI [QI HI PSI])
@@ -935,12 +937,20 @@
(define_insn epilogue_start_marker
[(unspec_volatile [(const_int 0)] UNS_EPILOGUE_START_MARKER)]
; start of epilogue
)
+;; This makes the linker add a call to exit() after the call to main()
+;; in crt0
+(define_insn msp430_refsym_need_exit
+ [(unspec_volatile [(const_int 0)] UNS_REFSYM_NEED_EXIT)]
+
+ .refsym\t__crt0_call_exit
+ )
+
;;
;; Jumps
(define_expand call
[(call:HI (match_operand 0 )
(match_operand 1 ))]
Index: config/msp430/msp430.c
===
--- config/msp430/msp430.c (revision 207333)
+++ config/msp430/msp430.c (working copy)
@@ -1426,12 +1426,15 @@ msp430_expand_epilogue (int is_eh)
break;
}
}
emit_insn (gen_epilogue_start_marker ());
+ if (cfun-decl strcmp (IDENTIFIER_POINTER (DECL_NAME (cfun-decl)),
main) == 0)
+emit_insn (gen_msp430_refsym_need_exit ());
+
if (is_wakeup_func ())
/* Clear the SCG1, SCG0, OSCOFF and CPUOFF bits in the saved copy of the
status register current residing on the stack. When this function
executes its RETI instruction the SR will be updated with this saved
value, thus ensuring that the processor is woken up from any low power
state in which it may be residing. */
Index: config/msp430/msp430.h
===
--- config/msp430/msp430.h (revision 207333)
+++ config/msp430/msp430.h (working copy)
@@ -65,12 +65,13 @@ extern bool msp430x;
#undef LIB_SPEC
#define LIB_SPEC \
--start-group \
-lc\
-lgcc \
+-lcrt \
%{msim:-lsim} \
%{!msim:-lnosys} \
--end-group\
%{!T*:%{!msim:%{mmcu=*:--script=%*.ld}}} \
%{!T*:%{!msim:%{!mmcu=*:%Tmsp430.ld}}} \
%{!T*:%{msim:%{mlarge:%Tmsp430xl-sim.ld}%{!mlarge:%Tmsp430-sim.ld}}} \
Re: [RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.
[resending with the patch - sorry about that] Hi Jason, On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote: On 02/19/2013 10:42 PM, Joel Brobecker wrote: This is useful when a DIE does not have a descriptive type attribute. In that case, the debugger needs to determine whether the unit was compiled with a compiler that normally provides that information, or not. Ah. OK, then. But I'd prefer to call it DW_AT_GNAT_use_descriptive_type, to follow the convention of keeping the vendor tag at the beginning of the name. Almost a year ago, you privately approved a small patch of mine, with the small request above. I'm sorry I let it drag so long! Here is the updated patch. include/ChangeLog: * dwarf2.def: Rename DW_AT_use_GNAT_descriptive_type into DW_AT_GNAT_use_descriptive_type. gcc/ChangeLog: * dwarf2out.c (gen_compile_unit_die): Add DW_AT_use_GNAT_descriptive_type attribute for Ada units. Tested on x86_64-linux. I should also adjust the Wiki page accordingly, but the login process keeps timing out. I know I have the right login and passwd since I succesfully reset them using the passwd recovery procedure, just in case the error was due to bad credentials. I'll try again later. If approved, I will also take care of coordinating the dwarf2.def change with binutils-gdb.git. Is this patch still OK to commit? Thank you, -- Joel From 7aae3721addf6905113d9f0287a5cbb5301a462b Mon Sep 17 00:00:00 2001 From: Joel Brobecker brobec...@adacore.com Date: Thu, 3 Jan 2013 09:25:12 -0500 Subject: [PATCH] [dwarf] Add DW_AT_GNAT_use_descriptive_type flag for Ada units. This patch first renames the DW_AT_use_GNAT_descriptive_type DWARF attribute into DW_AT_GNAT_use_descriptive_type to better follow the usual convention of keeping the vendor tag at the beginning of the name. It then modifies dwadrf2out to generate this attribute for Ada units. include/ChangeLog: * dwarf2.def: Rename DW_AT_use_GNAT_descriptive_type into DW_AT_GNAT_use_descriptive_type. gcc/ChangeLog: * dwarf2out.c (gen_compile_unit_die): Add DW_AT_use_GNAT_descriptive_type attribute for Ada units. --- gcc/dwarf2out.c|4 include/dwarf2.def |2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index d1ca4ba..057605c 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -19318,6 +19318,10 @@ gen_compile_unit_die (const char *filename) /* The default DW_ID_case_sensitive doesn't need to be specified. */ break; } + + if (language == DW_LANG_Ada95) +add_AT_flag (die, DW_AT_GNAT_use_descriptive_type, 1); + return die; } diff --git a/include/dwarf2.def b/include/dwarf2.def index 71a37b3..4dd636e 100644 --- a/include/dwarf2.def +++ b/include/dwarf2.def @@ -398,7 +398,7 @@ DW_AT (DW_AT_VMS_rtnbeg_pd_address, 0x2201) /* GNAT extensions. */ /* GNAT descriptive type. See http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type . */ -DW_AT (DW_AT_use_GNAT_descriptive_type, 0x2301) +DW_AT (DW_AT_GNAT_use_descriptive_type, 0x2301) DW_AT (DW_AT_GNAT_descriptive_type, 0x2302) /* UPC extension. */ DW_AT (DW_AT_upc_threads_scaled, 0x3210) -- 1.7.0.4
[Ping]: [RFC] [PATCH, AARCH64] : Using standard patterns for stack protection.
Can someone review this please. regards, Venkat. On 22 January 2014 22:27, Venkataramanan Kumar venkataramanan.ku...@linaro.org wrote: Hi Marcus, After we changed the frame growing direction (downwards) in Aarch64, the back-end now generates stack smashing set and test based on generic code available in GCC. But most of the ports (i386, spu, rs6000, s390, sh, sparc, tilepro and tilegx) define machine descriptions using standard pattern names 'stack_protect_set' and 'stack_protect_test'. This is done for both TLS model as well as global variable based stack guard model. Also all these ports in their machine descriptions, have cleared the register that loaded the canary value using an additional instruction. (GCC internals) 'stack_protect_set' This pattern, if defined, moves a ptr_mode value from the memory in operand 1 to the memory in operand 0 without leaving the value in a register afterward. This is to avoid leaking the value some place that an attacker might use to rewrite the stack guard slot after having clobbered it. If this pattern is not defined, then a plain move pattern is generated. (GCC internals) I believe this is done for extra security. Also each target can control the way of clearing the register that loaded the canary value. In the attached patch, I have written machine descriptions patterns for stack_protect_set and stack_protect_test for Aarch64. Also I am clearing the register by moving 0 to the register while setting the stack and using eor instruction while testing the stack. However this generates un-optimal code when compared to generic GCC code. While setting up stack canary , Generic code adrpx19, __stack_chk_guard ldr x1, [x19,#:lo12:__stack_chk_guard] str x1, [x29,40] Patch adrpx19, __stack_chk_guard add x1, x19, :lo12:__stack_chk_guard ldr x2, [x1] str x1, [x29,40] mov x2, 0 while testing stack canary generic code ldr x1, [x29,40] ldr x0, [x19,#:lo12:__stack_chk_guard] cmp x1, x0 bne .L7 patch add x19, x19, :lo12:__stack_chk_guard ldr x1, [x29,40] ldr x0, [x19] eor x0, x1, x0 cbnzx0, .L7 Please let me know if this change is fine for Aarch64. 2014-01-22 Venkataramanan Kumar venkataramanan.ku...@linaro.org * config/aarch64/aarch64.md (stack_protect_set, stack_protect_test) (stack_protect_set_mode, stack_protect_test_mode): Add machine descriptions for Stack Smashing Protector. 2014-01-22 Venkataramanan Kumar venkataramanan.ku...@linaro.org * lib/target-supports.exp (check_effective_target_stack_protection): New procedure. * g++.dg/fstack-protector-strong.C: Add target check for stack protection. * gcc.dg/fstack-protector-strong.c: Likewise. regards, Venkat.
PR ipa/59831 (ipa-cp devirt issues)
Hi,
PR ipa/59831 has testcase with one virtual call that shows really interesting
sequence of events. First we speculatively identify the target of call. Next
ipa-cp correctly works out the target and decides to clone. While creating a
clone it however no longer identifies the direct edge. It is because in
meantime it worked out the exact value of the pointer (globalvar) and thrown
away the binfo information we used previously. ipa-cp tries to look up the
binfo again, but it uses gimple_extract_devirt_binfo_from_cst that is not as
good at doing the same work as ipa-devirt is. For bogus reason (empty base
class) it gives up. Consequently we create the clone and propagate value, then
we hit recursive inlining and it tries to save the function body. While doing
so, it calls fold on the (now substituted) function body and it works out the
virtual call target. This leads to ICE since it tries to resolve the call and
remove the speculation before the body is fully copied.
This patch sanitizes behaviour of ipa-cp. I decided to remove
gimple_extract_devirt_binfo_from_cst since ipa-devirt already has all logic in
it, it was just not available to ipa-cp (it was on my TODO for a while).
To however prevent consistently the deivrutalization, we I added code to use
aggregate value info. It is quite easy to do: when we know the virtual table
pointer, we can lookup the BINFO same was as extr_type_from_vtbl_ptr_store
already does - by checking DECL_CONTEXT of the vtable. I borrowed the logic and
hardened it a bit by extra sanity checking in vtable_pointer_value_to_binfo.
Since I asked about it, I discovered bug in that logic: in the case of multiple
inheritance, we may end up having one vtable nested in another and vtable
initialization like vtable+120, instead of default 16. In this case we
definitely can not conclude that the dynamic type is the object is the CONTEXT
of vtable, since the it is the dynamic type of the object with some non-zero
offset.
I added code to vtable_pointer_value_to_binfo to lookup the proper binfo of
base with vtable at given offset, but sadly I can't hook it easily to
extr_type_from_vtbl_ptr_store, so I made it to give up in that case for now.
Bootstrapped/regtested x86_64-linux, tested on firefox LTO where it adds
10 new devirtualizations (out of 1200). Will commit it tomorrow if there are
no complains. There is one devirtualization fewer on javascript that is
due to extra checking I added to the instance type lookup.
Honza
PR ipa/59831
* gimple-fold.c (gimple_extract_devirt_binfo_from_cst): Remove.
* ipa-devirt.c (get_poymorphic_call_info_for_decl): Break out from ...
(get_polymorphic_call_info): ... here.
(get_polymorphic_call_info_from_invariant): New function based on
gimple_extract_devirt_binfo_from_cst.
(try_make_edge_direct_virtual_call): Update to use ipa-devirt.
(ipa_get_indirect_edge_target_1): Likewise.
(get_polymorphic_call_info_from_invariant): New function.
(vtable_pointer_value_to_binfo): New function.
* ipa-utils.h (get_polymorphic_call_info_from_invariant): Declare.
(vtable_pointer_value_to_binfo): Declare.
* ipa-prop.c (extr_type_from_vtbl_ptr_store): Use it.
(try_make_edge_direct_virtual_call): Use aggregate propagation;
rewrite handling of constants.
* ipa-cp.c (ipa_get_indirect_edge_target_1): Likewise.
* testsuite/g++.dg/ipa/devirt-21.C: New testcase.
* testsuite/g++.dg/ipa/devirt-20.C: Fix template.
Index: gimple-fold.c
===
--- gimple-fold.c (revision 207287)
+++ gimple-fold.c (working copy)
@@ -1071,74 +1071,6 @@ gimple_fold_builtin (gimple stmt)
}
-/* Return a binfo to be used for devirtualization of calls based on an object
- represented by a declaration (i.e. a global or automatically allocated one)
- or NULL if it cannot be found or is not safe. CST is expected to be an
- ADDR_EXPR of such object or the function will return NULL. Currently it is
- safe to use such binfo only if it has no base binfo (i.e. no ancestors)
- EXPECTED_TYPE is type of the class virtual belongs to. */
-
-tree
-gimple_extract_devirt_binfo_from_cst (tree cst, tree expected_type)
-{
- HOST_WIDE_INT offset, size, max_size;
- tree base, type, binfo;
- bool last_artificial = false;
-
- if (!flag_devirtualize
- || TREE_CODE (cst) != ADDR_EXPR
- || TREE_CODE (TREE_TYPE (TREE_TYPE (cst))) != RECORD_TYPE)
-return NULL_TREE;
-
- cst = TREE_OPERAND (cst, 0);
- base = get_ref_base_and_extent (cst, offset, size, max_size);
- type = TREE_TYPE (base);
- if (!DECL_P (base)
- || max_size == -1
- || max_size != size
- || TREE_CODE (type) != RECORD_TYPE)
-return NULL_TREE;
-
- /* Find the sub-object the constant actually refers to and mark whether it is
- an artificial one (as opposed to a user-defined one). */
Re: PR ipa/59831 (ipa-cp devirt issues)
On Fri, Jan 31, 2014 at 07:22:55AM +0100, Jan Hubicka wrote: --- ipa-devirt.c (revision 207287) +++ ipa-devirt.c (working copy) @@ -972,6 +972,120 @@ contains_type_p (tree outer_type, HOST_W return get_class_context (context, otr_type); } +/* Proudce polymorphic call context for call method of instance + that is located within BASE (that is assumed to be a decl) at OFFSET. */ + +static void +get_poymorphic_call_info_for_decl (ipa_polymorphic_call_context *context, +tree base, HOST_WIDE_INT offset) Missing l in polymorphic. Jakub
