Re: [GSoC] generation of Gimple code from isl_ast_node_if
Can you explain why you believe it is hard/impossible to generate a test case without reduction? I don't believe this. I only know that all the test cases considered by me have the same problem. Could you please explain what is 'reduction'? I've found out that, according to the comment of the rewrite_reductions_out_of_ssa (this function duplicates pbbs), the rewrite_reductions_out_of_ssa rewrite out of SSA all the reduction phi nodes of SCOP. What are reduction phi nodes? How are they related to 'reduction'? -- Cheers, Roman Gareev.
Re: [GSoC] generation of Gimple code from isl_ast_node_if
On 27/07/2014 08:12, Roman Gareev wrote:
Can you explain why you believe it is hard/impossible to generate a test
case without reduction?
I don't believe this. I only know that all the test cases considered
by me have the same problem.
Could you please explain what is 'reduction'? I've found out that,
according to the comment of the rewrite_reductions_out_of_ssa (this
function duplicates pbbs), the rewrite_reductions_out_of_ssa rewrite
out of SSA all the reduction phi nodes of SCOP. What are reduction phi
nodes? How are they related to 'reduction'?
A reduction is an operation that combines a set of elements into a
single element.
for (i = 0; i 100; i++)
sum += i;
combines the different elements 'i' into the single element 'sum'.
Reductions where the combine operation *here '+') is associative and
commutative can be reordered. This means you can e.g. write the loop as
for (i = 99; i = 0; i--)
sum += i;
and you get the same result. There are two ways to ensure something is
not optimized as a reduction
1) Destroy associativity/commutativity
Floating point operations are generally not associative/commutative,
except if -ffast-math is given to the compiler
2) Do not reduce into one element.
If we just assign to different elements of an array, there is no
possibility we have a reduction.
Let's get back to the earlier test case:
for (i = 0; i n; i++) {
if (i = m)
T: A[i] = i;
S: A[i + p] = j;
}
What is the ast generated for this one? I just created this input file
for isl_codegen:
[n,m] - {S[i] - [i]: 0= i = n;T[i] - [i]: 0= i = m and i = n}
[n,m] - {:n,m 1}
{}
$ isl_codegen input.file
for (int c0 = 0; c0 = n; c0 += 1) {
if (m = c0)
T(c0);
S(c0);
}
Is something in graphite preventing us to generate this simple loop with
just one if-condition and no statement duplication?
Cheers,
Tobias
[Patch] PR 61692 - Fix for inline asm ICE
I'm not sure which maintainer to cc for inline asm stuff?
I have a release on file with the FSF, but don't have SVN write access.
Problem:
extract_insn() in recog.c will ICE if (noperands MAX_RECOG_OPERANDS).
Normally this isn't a problem since expand_asm_operands() in cfgexpand.c
catches and reports a proper error for this condition. However,
expand_asm_operands() only checks (ninputs + noutputs) instead of
(ninputs + noutputs + nlabels), so you can get the ICE when using asm
goto. See the bugzilla entry for sample code.
ChangeLog:
2014-07-27 David Wohlferd d...@limegreensocks.com
PR target/61692
* cfgexpand.c (expand_asm_operands): Count all inline asm
parameters.
dw
Index: cfgexpand.c
===
--- cfgexpand.c (revision 212900)
+++ cfgexpand.c (working copy)
@@ -2554,7 +2554,7 @@
}
ninputs += ninout;
- if (ninputs + noutputs MAX_RECOG_OPERANDS)
+ if (ninputs + noutputs + nlabels MAX_RECOG_OPERANDS)
{
error (more than %d operands in %asm%, MAX_RECOG_OPERANDS);
return;
Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields
On Sat, Jul 26, 2014 at 01:45:12PM +0200, Matthias Klose wrote: Am 17.07.2014 02:41, schrieb Ulrich Weigand: Hello, this is the variant intended for the 4.8/4.9 branches of the patch: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html As discussed, it does *not* actually change ABI, but only warn when encountering a situation where the ABI will change in a future GCC. (Avoiding the specific term GCC 4.10 here since I'm not certain whether the next GCC release will in fact be called that ...) Tested on powerpc64-linux and powerpc64le-linux; also verified using the ABI compat suite (against an unpatched GCC) that this patch does not change the ABI. this causes PR libobjc/61920, link failures with -lobjc. Try this. Index: libobjc/encoding.c === --- libobjc/encoding.c (revision 213090) +++ libobjc/encoding.c (working copy) @@ -192,6 +192,7 @@ ? MAX (MAX (COMPUTED, SPECIFIED), 64) \ : MAX (COMPUTED, SPECIFIED));}) +#define rs6000_special_adjust_field_align_p false /* Skip a variable name, enclosed in quotes (). */ static inline -- Alan Modra Australia Development Lab, IBM
[MIPS, committed] Reverse argument order in const-anchor tests
gcc.target/mips/const-anchor-[12].c started failing after:
2014-04-29 James Greenhalgh james.greenha...@arm.com
* calls.c (initialize_argument_information): Always treat
PUSH_ARGS_REVERSED as 1, simplify code accordingly.
(expand_call): Likewise.
(emit_library_call_calue_1): Likewise.
* expr.c (PUSH_ARGS_REVERSED): Do not define.
(emit_push_insn): Always treat PUSH_ARGS_REVERSED as 1, simplify
code accordingly.
because we now evaluate the arguments in reverse order and because the
way that the const-anchor optimisation is written is (knowingly, I think)
sensitive to instruction order.
I've filed enhancement PR61926 for a version that could cope with both
orders. In the meantime, and in order to make sure that the optimisation
is still tested, I've committed the patch below to reverse the arguments.
I've added the old order as new XFAILed tests, linked to the PR.
Tested on mips64-linux-gnu and applied.
Thanks,
Richard
gcc/testsuite/
PR rtl-optimization/61926
* gcc.target/mips/const-anchor-1.c, gcc.target/mips/const-anchor-2.c:
Reverse argument order.
* gcc.target/mips/const-anchor-3.c, gcc.target/mips/const-anchor-4.c:
New XFAILed tests that match the original order.
Index: gcc/testsuite/gcc.target/mips/const-anchor-1.c
===
--- gcc/testsuite/gcc.target/mips/const-anchor-1.c 2014-07-27
10:28:49.047970043 +0100
+++ gcc/testsuite/gcc.target/mips/const-anchor-1.c 2014-07-27
10:37:18.023945982 +0100
@@ -2,9 +2,9 @@
(0x1234000) used to build another constant. */
/* { dg-skip-if code quality test { *-*-* } { -O0 } { } } */
/* { dg-final { scan-assembler-not 0x1233|305332224 } } */
-/* { dg-final { scan-assembler \td?addiu\t\\\$5,\\\$\[0-9\]*,-1 } } */
+/* { dg-final { scan-assembler \td?addiu\t\\\$4,\\\$\[0-9\]*,-1 } } */
NOMIPS16 void f ()
{
- g (0x12340001, 0x1233);
+ g (0x1233, 0x12340001);
}
Index: gcc/testsuite/gcc.target/mips/const-anchor-2.c
===
--- gcc/testsuite/gcc.target/mips/const-anchor-2.c 2014-07-27
10:28:49.047970043 +0100
+++ gcc/testsuite/gcc.target/mips/const-anchor-2.c 2014-07-27
10:37:18.024945992 +0100
@@ -1,9 +1,9 @@
/* Derive a constant (0x30001) from another constant. */
/* { dg-skip-if code quality test { *-*-* } { -O0 } { } } */
/* { dg-final { scan-assembler-not 0x30|196608 } } */
-/* { dg-final { scan-assembler \td?addiu\t\\\$5,\\\$\[0-9\]*,32763 } } */
+/* { dg-final { scan-assembler \td?addiu\t\\\$4,\\\$\[0-9\]*,32763 } } */
NOMIPS16 void f ()
{
- g (0x28006, 0x30001);
+ g (0x30001, 0x28006);
}
Index: gcc/testsuite/gcc.target/mips/const-anchor-3.c
===
--- /dev/null 2014-07-15 07:39:28.965430757 +0100
+++ gcc/testsuite/gcc.target/mips/const-anchor-3.c 2014-07-27
10:44:18.927185095 +0100
@@ -0,0 +1,11 @@
+/* Derive a constant (0x1233) from an intermediate value
+ (0x1234000) used to build another constant. */
+/* { dg-skip-if code quality test { *-*-* } { -O0 } { } } */
+/* See PR61926 for the XFAILs. */
+/* { dg-final { scan-assembler-not 0x1233|305332224 { xfail *-*-* } } }
*/
+/* { dg-final { scan-assembler \td?addiu\t\\\$5,\\\$\[0-9\]*,-1 { xfail
*-*-* } } } */
+
+NOMIPS16 void f ()
+{
+ g (0x12340001, 0x1233);
+}
Index: gcc/testsuite/gcc.target/mips/const-anchor-4.c
===
--- /dev/null 2014-07-15 07:39:28.965430757 +0100
+++ gcc/testsuite/gcc.target/mips/const-anchor-4.c 2014-07-27
10:44:23.721233442 +0100
@@ -0,0 +1,10 @@
+/* Derive a constant (0x30001) from another constant. */
+/* { dg-skip-if code quality test { *-*-* } { -O0 } { } } */
+/* See PR61926 for the XFAILs. */
+/* { dg-final { scan-assembler-not 0x30|196608 { xfail *-*-* } } } */
+/* { dg-final { scan-assembler \td?addiu\t\\\$5,\\\$\[0-9\]*,32763 { xfail
*-*-* } } } */
+
+NOMIPS16 void f ()
+{
+ g (0x28006, 0x30001);
+}
Re: [GSoC] generation of Gimple code from isl_ast_node_if
Thank you! I've attached patches with a test case (it is located in
patch1.txt), which generates the following ISL AST:
for (int c1 = 0; c1 = 49; c1 += 1) {
if (c1 = 24)
S_4(c1);
S_5(c1);
}
I think that it doesn't contain reduction and doesn't yield several
bbs. I've also checked that pbbs correspond to pbbs of pbb-domain and
pbb-transformed.
--
Cheers, Roman Gareev.
2014-07-23 Roman Gareev gareevro...@gmail.com
[gcc/]
* graphite-isl-ast-to-gimple.c:
(graphite_create_new_guard): New function.
(translate_isl_ast_node_if): New function.
(translate_isl_ast): Add calling of translate_isl_ast_node_if.
[gcc/testsuite]
* gcc.dg/graphite/isl-ast-gen-if-1.c: New testcase.
2014-07-23 Roman Gareev gareevro...@gmail.com
[gcc/]
* graphite-sese-to-poly.c:
(new_pbb_from_pbb): Set a new id of pbb1-domain (instead of using the
id of the pbb), which contains pointer to the pbb1.
[gcc/testsuite]
* gcc.dg/graphite/isl-ast-gen-if-2.c: New testcase.
Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 212995)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -646,6 +646,43 @@
return next_e;
}
+/* Creates a new if region corresponding to ISL's cond. */
+
+static edge
+graphite_create_new_guard (edge entry_edge, __isl_take isl_ast_expr *if_cond,
+ ivs_params ip)
+{
+ tree type =
+build_nonstandard_integer_type (graphite_expression_type_precision, 0);
+ tree cond_expr = gcc_expression_from_isl_expression (type, if_cond, ip);
+ edge exit_edge = create_empty_if_region_on_edge (entry_edge, cond_expr);
+ return exit_edge;
+}
+
+/* Translates an isl_ast_node_if to Gimple. */
+
+static edge
+translate_isl_ast_node_if (loop_p context_loop,
+ __isl_keep isl_ast_node *node,
+ edge next_e, ivs_params ip)
+{
+ gcc_assert (isl_ast_node_get_type (node) == isl_ast_node_if);
+ isl_ast_expr *if_cond = isl_ast_node_if_get_cond (node);
+ edge last_e = graphite_create_new_guard (next_e, if_cond, ip);
+
+ edge true_e = get_true_edge_from_guard_bb (next_e-dest);
+ isl_ast_node *then_node = isl_ast_node_if_get_then (node);
+ translate_isl_ast (context_loop, then_node, true_e, ip);
+ isl_ast_node_free (then_node);
+
+ edge false_e = get_false_edge_from_guard_bb (next_e-dest);
+ isl_ast_node *else_node = isl_ast_node_if_get_else (node);
+ if (isl_ast_node_get_type (else_node) != isl_ast_node_error)
+translate_isl_ast (context_loop, else_node, false_e, ip);
+ isl_ast_node_free (else_node);
+ return last_e;
+}
+
/* Translates an ISL AST node NODE to GCC representation in the
context of a SESE. */
@@ -663,7 +700,8 @@
next_e, ip);
case isl_ast_node_if:
- return next_e;
+ return translate_isl_ast_node_if (context_loop, node,
+ next_e, ip);
case isl_ast_node_user:
return translate_isl_ast_node_user (node, next_e, ip);
Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c
===
--- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c(working copy)
@@ -0,0 +1,37 @@
+/* { dg-do run } */
+/* { dg-options -O2 -fgraphite-identity -fgraphite-code-generator=isl } */
+
+int st = 1;
+static void __attribute__((noinline))
+foo (int a[], int n)
+{
+ int i;
+ for (i = 0; i n; i++)
+{
+ if (i 25)
+a[i] = i;
+ a[n - i] = 1;
+}
+}
+
+static int __attribute__((noinline))
+array_sum (int a[])
+{
+ int i, res = 0;
+ for(i = 0; i 50; i += st)
+res += a[i];
+ return res;
+}
+
+extern void abort ();
+
+int
+main (void)
+{
+ int a[50];
+ foo (a, 50);
+ int res = array_sum (a);
+ if (res != 49)
+abort ();
+ return 0;
+}
Index: gcc/graphite-sese-to-poly.c
===
--- gcc/graphite-sese-to-poly.c (revision 212995)
+++ gcc/graphite-sese-to-poly.c (working copy)
@@ -2044,7 +2044,8 @@
break;
pbb1-domain = isl_set_copy (pbb-domain);
-
+ pbb1-domain = isl_set_set_tuple_id (pbb1-domain,
+ isl_id_for_pbb (scop, pbb1));
GBB_PBB (gbb1) = pbb1;
GBB_CONDITIONS (gbb1) = GBB_CONDITIONS (gbb).copy ();
GBB_CONDITION_CASES (gbb1) = GBB_CONDITION_CASES (gbb).copy ();
Index: gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-2.c
===
--- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-2.c(revision 0)
+++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-2.c(working copy)
@@ -0,0 +1,31 @@
+/* { dg-do run } */
+/* { dg-options -O2 -fgraphite-identity -fgraphite-code-generator=isl } */
+
Re: [GSoC] generation of Gimple code from isl_ast_node_if
On 27/07/2014 12:48, Roman Gareev wrote:
Thank you! I've attached patches with a test case (it is located in
patch1.txt), which generates the following ISL AST:
for (int c1 = 0; c1 = 49; c1 += 1) {
if (c1 = 24)
S_4(c1);
S_5(c1);
}
I think that it doesn't contain reduction and doesn't yield several
bbs. I've also checked that pbbs correspond to pbbs of pbb-domain and
pbb-transformed.
OK. LGTM.
Tobias
[PATCH] Fix ICE with -Wodr (PR middle-end/61913)
Wodr in common.opt was missing a Var, which means: 1) we ICE with -Wodr, since -Wodr isn't handled in opts.c; 2) -Wno-odr wouldn't work. Thus fixed. I'd think this doesn't need a testcase... Bootstrapped/regtested on x86_64-linux, ok for trunk? 2014-07-27 Marek Polacek pola...@redhat.com PR middle-end/61913 * common.opt (Wodr): Add Var. diff --git gcc/common.opt gcc/common.opt index a385ee0..3b04044 100644 --- gcc/common.opt +++ gcc/common.opt @@ -588,7 +588,7 @@ Wmissing-noreturn Common Alias(Wsuggest-attribute=noreturn) Wodr -Common Warning +Common Var(warn_odr_violations) Warning Warn about some C++ One Definition Rule violations during link time optimization Woverflow Marek
Re: update address taken: don't drop clobbers
On Thu, 10 Jul 2014, Richard Biener wrote:
--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
{
tree def = DEF_FROM_PTR (def_p);
tree sym = DECL_P (def) ? def : SSA_NAME_VAR (def);
/* If DEF is a naked symbol that needs renaming, create a new
name for it. */
if (marked_for_renaming (sym))
{
if (DECL_P (def))
{
- tree tracked_var;
-
- def = make_ssa_name (def, stmt);
+ if (gimple_clobber_p (stmt) is_gimple_reg (sym))
sym should always be a gimple reg here (it's marked for renaming).
Not quite. If I remove the is_gimple_reg check, I get:
/data/repos/gcc/sra/libgcc/libgcc2.c: In function '__divti3':
/data/repos/gcc/sra/libgcc/libgcc2.c:1246:1: error: non-trivial conversion at
assignment
}
^
const union DWunion
void
# .MEM_149 = VDEF .MEM_148
nn ={v} .MEM_7(D);
+ {
+ /* Replace clobber stmts with a default def. Create a new
+variable so we don't later think we must coalesce, which
would
+fail with some ada abnormal PHIs. Still, we try to keep a
+similar name so error messages make sense. */
+ unlink_stmt_vdef (stmt);
I think that's redundant with gsi_replace (note that using gsi_replace
looks dangerous here as it calls update_stmt during SSA rewrite...
that might open a can of worms).
+ gsi_replace (gsi, gimple_build_nop (), true);
+ tree id = DECL_NAME (sym);
+ const char* name = id ? IDENTIFIER_POINTER (id) : 0;
+ tree newvar = create_tmp_var (TREE_TYPE (sym), name);
+ def = get_or_create_ssa_default_def (cfun, newvar);
So - can't you simply do
gimple_assign_set_rhs_from_tree (gsi,
get_or_create_dda_default_def (cfun, sym));
? Thus replace x = CLOBBER; with x_3 = x_2(D);
If I write just that, I get a failure because of a missing USE. I need to
run update_stmt (but then you are saying it is dangerous...).
And it also fails to warn for the C++ testcase because SRA sets
nowarning_flag (it doesn't if I create a new variable), but I guess we can
see about changing that next.
--
Marc Glisse
Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields
On Sun, Jul 27, 2014 at 07:16:07PM +0930, Alan Modra wrote: On Sat, Jul 26, 2014 at 01:45:12PM +0200, Matthias Klose wrote: Am 17.07.2014 02:41, schrieb Ulrich Weigand: Hello, this is the variant intended for the 4.8/4.9 branches of the patch: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html As discussed, it does *not* actually change ABI, but only warn when encountering a situation where the ABI will change in a future GCC. (Avoiding the specific term GCC 4.10 here since I'm not certain whether the next GCC release will in fact be called that ...) Tested on powerpc64-linux and powerpc64le-linux; also verified using the ABI compat suite (against an unpatched GCC) that this patch does not change the ABI. this causes PR libobjc/61920, link failures with -lobjc. Try this. Index: libobjc/encoding.c === --- libobjc/encoding.c(revision 213090) +++ libobjc/encoding.c(working copy) @@ -192,6 +192,7 @@ ? MAX (MAX (COMPUTED, SPECIFIED), 64) \ : MAX (COMPUTED, SPECIFIED));}) +#define rs6000_special_adjust_field_align_p false /* Skip a variable name, enclosed in quotes (). */ static inline Blah, that won't work of course. The macro needs to take two parameters. #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) false -- Alan Modra Australia Development Lab, IBM
Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields
On Jul 27, 2014, at 4:53 AM, Alan Modra amo...@gmail.com wrote: On Sun, Jul 27, 2014 at 07:16:07PM +0930, Alan Modra wrote: On Sat, Jul 26, 2014 at 01:45:12PM +0200, Matthias Klose wrote: Am 17.07.2014 02:41, schrieb Ulrich Weigand: Hello, this is the variant intended for the 4.8/4.9 branches of the patch: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html As discussed, it does *not* actually change ABI, but only warn when encountering a situation where the ABI will change in a future GCC. (Avoiding the specific term GCC 4.10 here since I'm not certain whether the next GCC release will in fact be called that ...) Tested on powerpc64-linux and powerpc64le-linux; also verified using the ABI compat suite (against an unpatched GCC) that this patch does not change the ABI. this causes PR libobjc/61920, link failures with -lobjc. Try this. Index: libobjc/encoding.c === --- libobjc/encoding.c(revision 213090) +++ libobjc/encoding.c(working copy) @@ -192,6 +192,7 @@ ? MAX (MAX (COMPUTED, SPECIFIED), 64)\ : MAX (COMPUTED, SPECIFIED));}) +#define rs6000_special_adjust_field_align_p false /* Skip a variable name, enclosed in quotes (). */ static inline Blah, that won't work of course. The macro needs to take two parameters. #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) false This is pre-approved if it works. I really should finish off the branch I started years ago :). Thanks, Andrew -- Alan Modra Australia Development Lab, IBM
[PATH wwwdocs] Mention avx-512vlbwdq branch in svn.html
Hello,
Patch below introduces mention of avx-512vlbwdq SVN
branch in htdocs/svn.html
Same prefix for e-mail (w/ avx-512) put intentionally.
Is it ok to install?
--
Thanks, K
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.198
diff -p -r1.198 svn.html
*** htdocs/svn.html 21 Jun 2014 19:01:11 - 1.198
--- htdocs/svn.html 27 Jul 2014 12:25:46 -
*** the command codesvn log --stop-on-copy
*** 364,369
--- 364,377
h4Architecture-specific/h4
dl
+ dtavx-512vlbwdq/dt
+ ddThe goal of this branch is to implement Intel AVX-512{VL,BW,DQ}
+ Programming Reference
+ (a
href=https://software.intel.com/sites/default/files/managed/c6/a9/319433-020.pdf;link/a).
+ The branch is maintained by Yukhin Kirill lt;a
+ href=mailto:kirill.yuk...@intel.com;kirill.yuk...@intel.com/agt;.
+ Patches should be marked with the tag code[AVX512]/code in the subject
+ line./dd
dtavx512/dt
ddThe goal of this branch is to implement Intel AVX-512 and SHA
[PATCH i386 AVX512] [1/n] Introduce `-mavx512dq' switch
Hello,
With this patch we'd like to start merge process of avx-512vlbwdq
branch into main trunk.
This patch introduces new switch `-mavx512dq'
Bootstrapped.
Is it ok for trunk?
* common/config/i386/i386-common.c
(OPTION_MASK_ISA_AVX512DQ_SET): Define.
(OPTION_MASK_ISA_AVX512DQ_UNSET): Ditto.
(ix86_handle_option): Handle OPT_mavx512dq.
* config/i386/cpuid.h (bit_AVX512DQ): Define.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect avx512dq,
set -mavx512dq accordingly.
* config/i386/i386-c.c (ix86_target_macros_internal): Handle
OPTION_MASK_ISA_AVX512DQ.
* config/i386/i386.c (ix86_target_string): Handle -mavx512dq.
(ix86_option_override_internal): Define PTA_AVX512DQ, handle
PTA_AVX512DQ and OPTION_MASK_ISA_AVX512DQ.
(ix86_valid_target_attribute_inner_p): Handle OPT_mavx512dq.
* config/i386/i386.h (TARGET_AVX512DQ): Define.
(TARGET_AVX512DQ_P(x)): Ditto.
* config/i386/i386.opt: Add mavx512dq.
--
Thanks, K
diff --git a/gcc/common/config/i386/i386-common.c
b/gcc/common/config/i386/i386-common.c
index 3012783..3db1535 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -65,6 +65,8 @@ along with GCC; see the file COPYING3. If not see
(OPTION_MASK_ISA_AVX512PF | OPTION_MASK_ISA_AVX512F_SET)
#define OPTION_MASK_ISA_AVX512ER_SET \
(OPTION_MASK_ISA_AVX512ER | OPTION_MASK_ISA_AVX512F_SET)
+#define OPTION_MASK_ISA_AVX512DQ_SET \
+ (OPTION_MASK_ISA_AVX512DQ | OPTION_MASK_ISA_AVX512F_SET)
#define OPTION_MASK_ISA_RTM_SET OPTION_MASK_ISA_RTM
#define OPTION_MASK_ISA_PRFCHW_SET OPTION_MASK_ISA_PRFCHW
#define OPTION_MASK_ISA_RDSEED_SET OPTION_MASK_ISA_RDSEED
@@ -156,6 +158,7 @@ along with GCC; see the file COPYING3. If not see
#define OPTION_MASK_ISA_AVX512CD_UNSET OPTION_MASK_ISA_AVX512CD
#define OPTION_MASK_ISA_AVX512PF_UNSET OPTION_MASK_ISA_AVX512PF
#define OPTION_MASK_ISA_AVX512ER_UNSET OPTION_MASK_ISA_AVX512ER
+#define OPTION_MASK_ISA_AVX512DQ_UNSET OPTION_MASK_ISA_AVX512DQ
#define OPTION_MASK_ISA_RTM_UNSET OPTION_MASK_ISA_RTM
#define OPTION_MASK_ISA_PRFCHW_UNSET OPTION_MASK_ISA_PRFCHW
#define OPTION_MASK_ISA_RDSEED_UNSET OPTION_MASK_ISA_RDSEED
@@ -393,6 +396,19 @@ ix86_handle_option (struct gcc_options *opts,
}
return true;
+case OPT_mavx512dq:
+ if (value)
+ {
+ opts-x_ix86_isa_flags |= OPTION_MASK_ISA_AVX512DQ_SET;
+ opts-x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_AVX512DQ_SET;
+ }
+ else
+ {
+ opts-x_ix86_isa_flags = ~OPTION_MASK_ISA_AVX512DQ_UNSET;
+ opts-x_ix86_isa_flags_explicit |= OPTION_MASK_ISA_AVX512DQ_UNSET;
+ }
+ return true;
+
case OPT_mfma:
if (value)
{
diff --git a/gcc/config/i386/cpuid.h b/gcc/config/i386/cpuid.h
index 7ac22a1..dc65053 100644
--- a/gcc/config/i386/cpuid.h
+++ b/gcc/config/i386/cpuid.h
@@ -73,6 +73,7 @@
#define bit_BMI2 (1 8)
#define bit_RTM(1 11)
#define bit_AVX512F(1 16)
+#define bit_AVX512DQ (1 17)
#define bit_RDSEED (1 18)
#define bit_ADX(1 19)
#define bit_CLFLUSHOPT (1 23)
diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
index 4cd0b3d..8ff49ac 100644
--- a/gcc/config/i386/driver-i386.c
+++ b/gcc/config/i386/driver-i386.c
@@ -411,6 +411,7 @@ const char *host_detect_local_cpu (int argc, const char
**argv)
unsigned int has_avx512er = 0, has_avx512pf = 0, has_avx512cd = 0;
unsigned int has_avx512f = 0, has_sha = 0, has_prefetchwt1 = 0;
unsigned int has_clflushopt = 0, has_xsavec = 0, has_xsaves = 0;
+ unsigned int has_avx512dq = 0;
bool arch;
@@ -488,6 +489,7 @@ const char *host_detect_local_cpu (int argc, const char
**argv)
has_avx512cd = ebx bit_AVX512CD;
has_sha = ebx bit_SHA;
has_clflushopt = ebx bit_CLFLUSHOPT;
+ has_avx512dq = ebx bit_AVX512DQ;
has_prefetchwt1 = ecx bit_PREFETCHWT1;
}
@@ -900,6 +902,7 @@ const char *host_detect_local_cpu (int argc, const char
**argv)
const char *clflushopt = has_clflushopt ? -mclflushopt :
-mno-clflushopt;
const char *xsavec = has_xsavec ? -mxsavec : -mno-xsavec;
const char *xsaves = has_xsaves ? -mxsaves : -mno-xsaves;
+ const char *avx512dq = has_avx512dq ? -mavx512dq : -mno-avx512dq;
options = concat (options, mmx, mmx3dnow, sse, sse2, sse3, ssse3,
sse4a, cx16, sahf, movbe, aes, sha, pclmul,
@@ -908,7 +911,7 @@ const char *host_detect_local_cpu (int argc, const char
**argv)
hle, rdrnd, f16c, fsgsbase, rdseed, prfchw, adx,
fxsr, xsave, xsaveopt, avx512f, avx512er,
avx512cd, avx512pf, prefetchwt1, clflushopt,
- xsavec, xsaves, NULL);
+ xsavec, xsaves, avx512dq, NULL);
}
done:
diff --git
Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields
Am 27.07.2014 13:59, schrieb pins...@gmail.com: On Jul 27, 2014, at 4:53 AM, Alan Modra amo...@gmail.com wrote: On Sun, Jul 27, 2014 at 07:16:07PM +0930, Alan Modra wrote: On Sat, Jul 26, 2014 at 01:45:12PM +0200, Matthias Klose wrote: Am 17.07.2014 02:41, schrieb Ulrich Weigand: Hello, this is the variant intended for the 4.8/4.9 branches of the patch: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html As discussed, it does *not* actually change ABI, but only warn when encountering a situation where the ABI will change in a future GCC. (Avoiding the specific term GCC 4.10 here since I'm not certain whether the next GCC release will in fact be called that ...) Tested on powerpc64-linux and powerpc64le-linux; also verified using the ABI compat suite (against an unpatched GCC) that this patch does not change the ABI. this causes PR libobjc/61920, link failures with -lobjc. Try this. Index: libobjc/encoding.c === --- libobjc/encoding.c(revision 213090) +++ libobjc/encoding.c(working copy) @@ -192,6 +192,7 @@ ? MAX (MAX (COMPUTED, SPECIFIED), 64)\ : MAX (COMPUTED, SPECIFIED));}) +#define rs6000_special_adjust_field_align_p false /* Skip a variable name, enclosed in quotes (). */ static inline Blah, that won't work of course. The macro needs to take two parameters. #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) false This is pre-approved if it works. I really should finish off the branch I started years ago :). #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) 0 is what succeeds for me. false is not defined for ObjC. Checked in on the trunk and the branches. these are still regressions, because the new warnings trigger on these test cases: Running /home/doko/gcc/gcc-4.9-4.9.1/src/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp ... FAIL: objc.dg-struct-layout-encoding-1/t025_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t027_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t028_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t029_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t030_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t031_main.m execution test No regressions in the obj-c++ tests. Matthias
[Patch, moxie] Add moxiebox target
The following binutils patches introduce a new moxie-based target
called moxiebox. Moxiebox is a VM developed by the bitcoin community
to act as a secure, sandboxed execution environment for bitcoin
automation.
See http://github.com/jgarzik/moxiebox for more information.
I'm checking these changes in. There's a config.sub change as well
that I'll submit through the regular process.
Thanks,
AG
For gcc...
2014-07-27 Anthony Green gr...@moxielogic.com
* config.gcc: Add moxie-*-moxiebox* configuration.
* config/moxie/moxiebox.h: New file.
For libgcc...
2014-07-27 Anthony Green gr...@moxielogic.com
* config.host: Add moxiebox configuration suppport.
Index: gcc/config/moxie/moxiebox.h
===
--- gcc/config/moxie/moxiebox.h (revision 0)
+++ gcc/config/moxie/moxiebox.h (working copy)
@@ -0,0 +1,47 @@
+/* Definitions for the moxiebox.
+ Copyright (C) 2014 Free Software Foundation, Inc.
+ Contributed by Anthony Green (gr...@moxielogic.com)
+
+This file is part of GCC.
+
+GCC 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.
+
+GCC 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 GCC; see the file COPYING3. If not see
+http://www.gnu.org/licenses/. */
+
+/* Target OS preprocessor built-ins. */
+#define TARGET_OS_CPP_BUILTINS() \
+ do \
+{ \
+ builtin_define_std (moxie);\
+ builtin_define (__moxiebox__); \
+ builtin_assert (system=moxiebox); \
+} \
+ while (0)
+
+#undef LIB_SPEC
+#define LIB_SPEC \
+%{!T*:-Tmoxiebox.ld} \
+ %{!nostdlib: --start-group -lsandboxrt -lc -lgcc --end-group }
+
+#undef LINK_SPEC
+#define LINK_SPEC %{h*} %{v:-V} -EL -Bstatic
+
+#undef ASM_SPEC
+#define ASM_SPEC -EL
+
+#undef MULTILIB_DEFAULTS
+
+#undef SIZE_TYPE
+#undef PTRDIFF_TYPE
+#undef WCHAR_TYPE
+#undef WCHAR_TYPE_SIZE
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 212980)
+++ gcc/config.gcc (working copy)
@@ -1168,6 +1168,12 @@
tmake_file=${tmake_file} moxie/t-moxie
tm_file=moxie/moxie.h dbxelf.h elfos.h moxie/rtems.h rtems.h
newlib-stdint.h
;;
+moxie-*-moxiebox*)
+ gas=yes
+ gnu_ld=yes
+ tm_file=${tm_file} dbxelf.h elfos.h moxie/moxiebox.h newlib-stdint.h
+ tmake_file=${tmake_file} moxie/t-moxiebox
+ ;;
h8300-*-rtems*)
tmake_file=${tmake_file} h8300/t-h8300 h8300/t-rtems
tm_file=h8300/h8300.h dbxelf.h elfos.h h8300/elf.h h8300/rtems.h
rtems.h newlib-stdint.h
Index: libgcc/config.host
===
--- libgcc/config.host (revision 212980)
+++ libgcc/config.host (working copy)
@@ -881,9 +881,9 @@
mn10300-*-*)
tmake_file=t-fdpbit
;;
-moxie-*-elf | moxie-*-uclinux*)
+moxie-*-elf | moxie-*-moxiebox* | moxie-*-uclinux*)
tmake_file=moxie/t-moxie t-softfp-sfdf t-softfp-excl t-softfp
- extra_parts=$extra_parts crti.o crtn.o
+ extra_parts=$extra_parts crti.o crtn.o crtbegin.o crtend.o
;;
moxie-*-rtems*)
tmake_file=$tmake_file moxie/t-moxie t-softfp-sfdf t-softfp-excl
t-softfp
[Patch, Fortran] Add first coarray ABI documentation to gfortran.texi
Dear all,
attached is a first patch to gfortran.texi which add documentation about
libcaf*.c. The things are still a bit in a flux and it is incomplete
(atomics, locking, error stop and vector subscripts are still missing),
but one has to start somewhere …
OK for the trunk?
Comments on the language, the technical description and on the API
itself are welcome.
Tobias
2014-07-27 Tobias Burnus bur...@net-b.de
* gfortran.texi (Coarray Programming): Add first ABI
documentation.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 66e78e8..5f6bf5d 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -184,6 +184,7 @@ Part II: Language Reference
* Compiler Characteristics:: User-visible implementation details.
* Extensions::Language extensions implemented by GNU Fortran.
* Mixed-Language Programming::Interoperability with C
+* Coarray Programming::
* Intrinsic Procedures:: Intrinsic procedures supported by GNU Fortran.
* Intrinsic Modules::Intrinsic modules supported by GNU Fortran.
@@ -3176,6 +3177,380 @@ of such a type
@end itemize
+@c -
+@c Coarray Programming
+@c -
+
+@node Coarray Programming
+@chapter Coarray Programming
+@cindex Coarrays
+
+@menu
+* Type and enum ABI Documentation::
+* Function ABI Documentation::
+@end menu
+
+
+@node Type and enum ABI Documentation
+@section Type and enum ABI Documentation
+
+@menu
+* caf_token_t::
+* caf_register_t::
+@end menu
+
+@node caf_token_t
+@subsection @code{caf_token_t}
+
+Typedef of type @code{void *} on the compiler side. Can be any data
+type on the library side.
+
+@node caf_register_t
+@subsection @code{caf_register_t}
+
+Indicates which kind of coarray variable should be registered.
+
+@verbatim
+typedef enum caf_register_t {
+ CAF_REGTYPE_COARRAY_STATIC,
+ CAF_REGTYPE_COARRAY_ALLOC,
+ CAF_REGTYPE_LOCK_STATIC,
+ CAF_REGTYPE_LOCK_ALLOC
+}
+caf_register_t;
+@end verbatim
+
+
+@node Function ABI Documentation
+@section Function ABI Documentation
+
+@menu
+* _gfortran_caf_init:: Initialiation function
+* _gfortran_caf_finish:: Finalization function
+* _gfortran_caf_this_image:: Querying the image number
+* _gfortran_caf_num_images:: Querying the maximal number of images
+* _gfortran_caf_register:: Registering coarrays
+* _gfortran_caf_deregister:: Deregistering coarrays
+* _gfortran_caf_send:: Sending data from a local image to a remote image
+* _gfortran_caf_get:: Getting data from a remote image
+* _gfortran_caf_sendget:: Sending data between remote images
+@end menu
+
+
+@node _gfortran_caf_init
+@subsection @code{_gfortran_caf_init} --- Initialiation function
+@cindex Coarray, _gfortran_caf_init
+
+@table @asis
+@item @emph{Description}:
+This function is called at startup of the program before the Fortran main
+program, if the latter has been compiled with @option{-fcoarray=lib}.
+It takes as arguments the command-line arguments of the program. It is
+permitted to pass to @code{NULL} pointers as argument; if non-@code{NULL},
+the library is permitted to modify the arguments.
+
+@item @emph{Syntax}:
+@code{void _gfortran_caf_init (int *argc, char ***argv)}
+
+@item @emph{Arguments}:
+@multitable @columnfractions .15 .70
+@item @var{argc} @tab intent(inout) An integer pointer with the number of
+arguments passed to the program or @code{NULL}.
+@item @var{argv} @tab intent(inout) A pointer to an array of strings with the
+command-line arguments or @code{NULL}.
+@end multitable
+
+@item @emph{NOTES}
+The function is modelled after the initialization function of the Message
+Passing Interface (MPI) specification. Due to the way coarray registration
+works, it might not be the first call to the libaray. If the main program is
+not written in Fortran and only a library uses coarrays, it can happen that
+this function is never called. Therefore, it is recommended that the library
+does not rely on the passed arguments and whether the call has been done.
+@end table
+
+
+@node _gfortran_caf_finish
+@subsection @code{_gfortran_caf_finish} --- Finalization function
+@cindex Coarray, _gfortran_caf_finish
+
+@table @asis
+@item @emph{Description}:
+This function is called at the end of the Fortran main program, if it has
+been compiled with the @option{-fcoarray=lib} option.
+
+@item @emph{Syntax}:
+@code{void _gfortran_caf_finish (void)}
+
+@item @emph{NOTES}
+For non-Fortran programs, it is recommended to call the function at the end
+of the main program. To ensure that the shutdown is also performed for
+programs where this function is not explicitly invoked, for instance
+non-Fortran programs or calls to the system's exit() function, the library
+can use a destructor function. Note that programs can also be terminated
+using the STOP and ERROR STOP statements; those use different library calls.
+@end table
+
+
+@node
Re: Patch for constexpr variable templates
On 2014-07-26 17:14, Jason Merrill wrote: On 07/26/2014 12:11 PM, Jason Merrill wrote: On 07/26/2014 03:04 AM, Braden Obrzut wrote: On 07/25/2014 05:24 PM, Jason Merrill wrote: Fair enough, but in that case let's use 'sorry' rather then 'error' to be clear that it's a missing feature. Tests like g++.dg/cpp1y/pr59638.C produce extra failures if this is changed. Is there something I'm supposed to do to account for that? Changing dg-error to dg-message should cover it. Actually, we shouldn't be treating that testcase as declaring variable templates at all. Adam, any thoughts? In the 59638 case, the declarations void (*a)(auto); void (*b)(auto) = 0; are shorthand for template typename T void (*a)(T); template typename T void (*b)(T) = 0; which, unless there's some constraint with variable templates that I'm not aware of, ought to define two variable templates 'a' and 'b' to be ptr-to-function-taking-T. So I think it's correct that the variable template stuff should be triggering here. Prefixing the two decls with constexpr does allow them to compile (albeit with an uninitialized const 'a' permerror in the first case). The issue with 59638 was that the errors were not correctly unwinding the template scope so declarations further down the file were considered templates when the weren't. There may be similar recovery issues with not supporting non-constexpr variable templates defined with 'auto' (if that's permitted at all). Cheers, Adam
Re: update address taken: don't drop clobbers
On Thu, 10 Jul 2014, Richard Biener wrote:
--- gcc/tree-into-ssa.c (revision 212109)
+++ gcc/tree-into-ssa.c (working copy)
@@ -1831,26 +1831,38 @@ maybe_register_def (def_operand_p def_p,
{
tree def = DEF_FROM_PTR (def_p);
tree sym = DECL_P (def) ? def : SSA_NAME_VAR (def);
/* If DEF is a naked symbol that needs renaming, create a new
name for it. */
if (marked_for_renaming (sym))
{
if (DECL_P (def))
{
- tree tracked_var;
-
- def = make_ssa_name (def, stmt);
+ if (gimple_clobber_p (stmt) is_gimple_reg (sym))
sym should always be a gimple reg here (it's marked for renaming).
+ {
+ /* Replace clobber stmts with a default def. Create a new
+variable so we don't later think we must coalesce, which
would
+fail with some ada abnormal PHIs. Still, we try to keep a
+similar name so error messages make sense. */
+ unlink_stmt_vdef (stmt);
I think that's redundant with gsi_replace (note that using gsi_replace
looks dangerous here as it calls update_stmt during SSA rewrite...
that might open a can of worms).
+ gsi_replace (gsi, gimple_build_nop (), true);
+ tree id = DECL_NAME (sym);
+ const char* name = id ? IDENTIFIER_POINTER (id) : 0;
+ tree newvar = create_tmp_var (TREE_TYPE (sym), name);
+ def = get_or_create_ssa_default_def (cfun, newvar);
So - can't you simply do
gimple_assign_set_rhs_from_tree (gsi,
get_or_create_dda_default_def (cfun, sym));
? Thus replace x = CLOBBER; with x_3 = x_2(D);
+ }
+ else
and of course still rewrite the DEF then. IMHO the copy-propagation
you do is premature optimization.
Using your version, I end up with spurious warnings, in particular for
va_list. pass_fold_builtins stops va_start/va_end taking the address of
the list, so we get:
list_6 = list_2(D);
in place of the clobber at the end of the function. And there is no
DCE-like pass afterwards, so we warn for the use of list_2(D).
(passes.def contains a comment about running dce before uninit)
I don't know if update_address_taken could avoid generating this
assignment where the lhs has 0 use, but this shows the optimization is not
completely premature.
(uninit could also check for this case, but that feels like a bad hack)
--
Marc Glisse
PR61919: Invalid rtx sharing in tree-outof-ssa.c
PR 61919 is another ripple from the patch to take advantage of rtx
sharing rules when instantiating virtual registers. In this case
the invalid sharing is coming from tree-outof-ssa.c, where the same
MEM rtx is being used in several moves. (Note that despite the name,
partition_to_pseudo maps to stack slot MEMs as well as pseudos.)
Tested on x86_64-linux-gnu. Also tested by Andreas on ia64,
where the testsuite regression showed up. OK to install?
Thanks,
Richard
gcc/
PR middle-end/61919
* tree-outof-ssa.c (insert_partition_copy_on_edge)
(insert_value_copy_on_edge, insert_rtx_to_part_on_edge)
(insert_part_to_rtx_on_edge): Copy partition_to_pseudo rtxes before
inserting them in the insn stream.
Index: gcc/tree-outof-ssa.c
===
--- gcc/tree-outof-ssa.c2014-07-26 21:14:51.074755469 +0100
+++ gcc/tree-outof-ssa.c2014-07-26 21:14:51.590759910 +0100
@@ -260,8 +260,8 @@ insert_partition_copy_on_edge (edge e, i
set_curr_insn_location (locus);
var = partition_to_var (SA.map, src);
- seq = emit_partition_copy (SA.partition_to_pseudo[dest],
-SA.partition_to_pseudo[src],
+ seq = emit_partition_copy (copy_rtx (SA.partition_to_pseudo[dest]),
+copy_rtx (SA.partition_to_pseudo[src]),
TYPE_UNSIGNED (TREE_TYPE (var)),
var);
@@ -274,7 +274,7 @@ insert_partition_copy_on_edge (edge e, i
static void
insert_value_copy_on_edge (edge e, int dest, tree src, source_location locus)
{
- rtx seq, x;
+ rtx dest_rtx, seq, x;
enum machine_mode dest_mode, src_mode;
int unsignedp;
tree var;
@@ -289,7 +289,8 @@ insert_value_copy_on_edge (edge e, int d
fprintf (dump_file, \n);
}
- gcc_assert (SA.partition_to_pseudo[dest]);
+ dest_rtx = copy_rtx (SA.partition_to_pseudo[dest]);
+ gcc_assert (dest_rtx);
set_location_for_edge (e);
/* If a locus is provided, override the default. */
@@ -300,9 +301,9 @@ insert_value_copy_on_edge (edge e, int d
var = SSA_NAME_VAR (partition_to_var (SA.map, dest));
src_mode = TYPE_MODE (TREE_TYPE (src));
- dest_mode = GET_MODE (SA.partition_to_pseudo[dest]);
+ dest_mode = GET_MODE (dest_rtx);
gcc_assert (src_mode == TYPE_MODE (TREE_TYPE (var)));
- gcc_assert (!REG_P (SA.partition_to_pseudo[dest])
+ gcc_assert (!REG_P (dest_rtx)
|| dest_mode == promote_decl_mode (var, unsignedp));
if (src_mode != dest_mode)
@@ -312,15 +313,14 @@ insert_value_copy_on_edge (edge e, int d
}
else if (src_mode == BLKmode)
{
- x = SA.partition_to_pseudo[dest];
+ x = dest_rtx;
store_expr (src, x, 0, false);
}
else
-x = expand_expr (src, SA.partition_to_pseudo[dest],
-dest_mode, EXPAND_NORMAL);
+x = expand_expr (src, dest_rtx, dest_mode, EXPAND_NORMAL);
- if (x != SA.partition_to_pseudo[dest])
-emit_move_insn (SA.partition_to_pseudo[dest], x);
+ if (x != dest_rtx)
+emit_move_insn (dest_rtx, x);
seq = get_insns ();
end_sequence ();
@@ -356,7 +356,7 @@ insert_rtx_to_part_on_edge (edge e, int
mems. Usually we give the source. As we result from SSA names
the left and right size should be the same (and no WITH_SIZE_EXPR
involved), so it doesn't matter. */
- seq = emit_partition_copy (SA.partition_to_pseudo[dest],
+ seq = emit_partition_copy (copy_rtx (SA.partition_to_pseudo[dest]),
src, unsignedsrcp,
partition_to_var (SA.map, dest));
@@ -390,7 +390,7 @@ insert_part_to_rtx_on_edge (edge e, rtx
var = partition_to_var (SA.map, src);
seq = emit_partition_copy (dest,
-SA.partition_to_pseudo[src],
+copy_rtx (SA.partition_to_pseudo[src]),
TYPE_UNSIGNED (TREE_TYPE (var)),
var);
Re: Patch for constexpr variable templates
In the 59638 case, the declarations void (*a)(auto); void (*b)(auto) = 0; are shorthand for template typename T void (*a)(T); template typename T void (*b)(T) = 0; which, unless there's some constraint with variable templates that I'm not aware of, ought to define two variable templates 'a' and 'b' to be ptr-to-function-taking-T. So I think it's correct that the variable template stuff should be triggering here. There isn't, but this interpretation isn't consistent with the use of auto in variable declarations. For example, this: const auto x = 0; does not mean: templatetypename T const T x = 0; So I would be surprised if any of: void (*p1)(auto); auto (*p2)(int); vectorauto x; did mean create a template instead of deduce the type of x. Also, if we did have this interpretation of auto for some (but not all?) variable declarations, we would have to know to write those as template-ids: void (*p)(auto); pint = some_f; since one cannot refer to a template specialization without arguments. I'm much, much happier if, for variable templates, we always deduce the type from the initializer.. Besides, that wording (or some approximation thereof) is already in the TS for concepts. A question came up during the CWG review as to whether we could declare function parameters as void (*p)(auto), and EWG said, sure, go for it. We also have the ability to declare function parameters as, e.g., vectorauto or pairconst auto, auto*. I applied that to variable templates as well, since it would have been a bit inconsistent, otherwise. Andrew
[committed] Remove my MIPS maintainer entry
as per https://gcc.gnu.org/ml/gcc/2014-07/msg00231.html Richard * MAINTAINERS: Remove my MIPS maintainer entry. Index: MAINTAINERS === --- MAINTAINERS 2014-07-24 16:13:22.686714267 +0100 +++ MAINTAINERS 2014-07-27 19:01:59.931740086 +0100 @@ -79,7 +79,6 @@ mcore portNick Cliftonnickc@redhat.c mep port DJ Delorie d...@redhat.com microblaze Michael Eager ea...@eagercon.com mips port Eric Christopherechri...@gmail.com -mips port Richard Sandiford rdsandif...@googlemail.com mmix port Hans-Peter Nilsson h...@bitrange.com mn10300 port Jeff Lawl...@redhat.com mn10300 port Alexandre Oliva aol...@redhat.com
Re: Warn when returning the address of a temporary (middle-end) v2
Marc Glisse marc.gli...@inria.fr writes: Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html and here is a new patch. I made an effort to isolate a path in at least one subcase so it doesn't look too strange that the warning is in this file. Computing the dominance info just to tweak the warning message may be a bit excessive. How about only calculating it once you've decided to issue a message? + if (always_executed) + msg = function returns address of local variable; + else + msg = function may return address of local variable; I think you need _(...) here, unless some magic makes that unnecessary now. Thanks, Richard
Re: [PATH wwwdocs] Mention avx-512vlbwdq branch in svn.html
Hi Kirill,
On Sun, 27 Jul 2014, Kirill Yukhin wrote:
Patch below introduces mention of avx-512vlbwdq SVN
branch in htdocs/svn.html
Same prefix for e-mail (w/ avx-512) put intentionally.
Is it ok to install?
you don't need to get explicit approval for release notes related to
your areas of expertise, svn.html maintenance, and the like, though
I'm happy to provide editorial review whenever you desire so.
So, yes this is okay.
+ ddThe goal of this branch is to implement Intel AVX-512{VL,BW,DQ}
+ Programming Reference
+ (a
href=https://software.intel.com/sites/default/files/managed/c6/a9/319433-020.pdf;link/a).
This probably might be better as the Intel AVX-512... (with an extra
the)?
Gerald
Re: Warn when returning the address of a temporary (middle-end) v2
On Sun, 27 Jul 2014, Richard Sandiford wrote: Marc Glisse marc.gli...@inria.fr writes: Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html and here is a new patch. I made an effort to isolate a path in at least one subcase so it doesn't look too strange that the warning is in this file. Computing the dominance info just to tweak the warning message may be a bit excessive. How about only calculating it once you've decided to issue a message? Good idea! I'll post the updated patch after testing. + if (always_executed) + msg = function returns address of local variable; + else + msg = function may return address of local variable; I think you need _(...) here, unless some magic makes that unnecessary now. I just tried to see how the magic happens when someone calls error_at, and it goes through diagnostic_set_info, which contains: diagnostic_set_info_translated (diagnostic, _(gmsgid), args, location, kind); So I think the _(...) is already taken care of. But I don't know that code at all and I could easily have looked at it wrong. Thanks for the help, -- Marc Glisse
Re: Patch for constexpr variable templates
On 2014-07-27 19:01, Andrew Sutton wrote: In the 59638 case, the declarations void (*a)(auto); void (*b)(auto) = 0; are shorthand for template typename T void (*a)(T); template typename T void (*b)(T) = 0; which, unless there's some constraint with variable templates that I'm not aware of, ought to define two variable templates 'a' and 'b' to be ptr-to-function-taking-T. So I think it's correct that the variable template stuff should be triggering here. There isn't, but this interpretation isn't consistent with the use of auto in variable declarations. True. It's just what GCC currently does when it see's 'auto' in a function parameter list. Sounds like it needs to be prevented from doing that in [at least] this case. For example, this: const auto x = 0; does not mean: templatetypename T const T x = 0; So I would be surprised if any of: void (*p1)(auto); auto (*p2)(int); vectorauto x; did mean create a template instead of deduce the type of x. Indeed. I accept the argument. The only reason GCC does this is that it has a general implementation that introduces a template parameter list to the primary declaration whenever it sees 'auto' in a function parameter list; including a function parameter list in a function type. If we know that we are not declaring a function (or know that we are declaring a variable), then we can prevent 'auto' from having the currently implemented meaning. That would be an alternative resolution to 59638 (and friends) too. Also, if we did have this interpretation of auto for some (but not all?) variable declarations, we would have to know to write those as template-ids: void (*p)(auto); pint = some_f; since one cannot refer to a template specialization without arguments. Agreed. That's not pleasant. And I question whether there's a motivating use case for variable templates that are function pointers (but I confess I haven't thought much about it). I'm much, much happier if, for variable templates, we always deduce the type from the initializer.. Besides, that wording (or some approximation thereof) is already in the TS for concepts. A question came up during the CWG review as to whether we could declare function parameters as void (*p)(auto), and EWG said, sure, go for it. We also have the ability to declare function parameters as, e.g., vectorauto or pairconst auto, auto*. I applied that to variable templates as well, since it would have been a bit inconsistent, otherwise. Sounds good. For function parameters this is implemented in GCC by introducing a template declaration; i.e. making the function in question a function template. For variables we want a different solution that relies on doing some sort of tsubst of an initializer expression into the 'auto'-expressed variable type; effectively generalizing the handling of 'auto x = ...'. We could probably leverage the current behavior to get the generalized (generic) type including template parameters, then do a substitution using the initializer expression to determine what they are (and error if no initializer is given). Adam
Convert more incremental hash users to inchash
This patchkit converts more incremental hash users to the new inchash class. The only larger change is for rtl hashing, which I had to move to a new file to avoid problems with the generator program. All changes should only minimally change behavior. Bootstrapped and tested on x86_64-linux. Ok to commit? -Andi
[PATCH 2/6] Convert asan.c to inchash
From: Andi Kleen a...@linux.intel.com
gcc/:
2014-07-25 Andi Kleen a...@linux.intel.com
* asan.c (asan_mem_ref_hasher::hash): Convert to inchash.
---
gcc/asan.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/asan.c b/gcc/asan.c
index 475dd82..f7fa55f 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -348,9 +348,10 @@ struct asan_mem_ref_hasher
inline hashval_t
asan_mem_ref_hasher::hash (const asan_mem_ref *mem_ref)
{
- hashval_t h = iterative_hash_expr (mem_ref-start, 0);
- h = iterative_hash_host_wide_int (mem_ref-access_size, h);
- return h;
+ inchash hstate;
+ iterative_hstate_expr (mem_ref-start, hstate);
+ hstate.add_wide_int (mem_ref-access_size);
+ return hstate.end ();
}
/* Compare two memory references. We accept the length of either
--
2.0.1
[PATCH 3/6] Convert ipa-devirt to inchash
From: Andi Kleen a...@linux.intel.com
gcc/:
2014-07-25 Andi Kleen a...@linux.intel.com
* ipa-devirt.c (polymorphic_call_target_hasher::hash):
Convert to inchash.
---
gcc/ipa-devirt.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 127d58d..5f529a9 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1633,17 +1633,15 @@ struct polymorphic_call_target_hasher
inline hashval_t
polymorphic_call_target_hasher::hash (const value_type *odr_query)
{
- hashval_t hash;
-
- hash = iterative_hash_host_wide_int
- (odr_query-otr_token,
- odr_query-type-id);
- hash = iterative_hash_hashval_t (TYPE_UID (odr_query-context.outer_type),
- hash);
- hash = iterative_hash_host_wide_int (odr_query-context.offset, hash);
- return iterative_hash_hashval_t
- (((int)odr_query-context.maybe_in_construction 1)
-| (int)odr_query-context.maybe_derived_type, hash);
+ inchash hstate (odr_query-otr_token);
+
+ hstate.add_wide_int (odr_query-type-id);
+ hstate.add_wide_int (TYPE_UID (odr_query-context.outer_type));
+ hstate.add_wide_int (odr_query-context.offset);
+ hstate.add_flag (odr_query-context.maybe_in_construction);
+ hstate.add_flag (odr_query-context.maybe_derived_type);
+ hstate.commit_flag ();
+ return hstate.end ();
}
/* Compare cache entries T1 and T2. */
--
2.0.1
[PATCH 4/6] Convert tree-ssa-dom to inchash
From: Andi Kleen a...@linux.intel.com
gcc/:
2014-07-25 Andi Kleen a...@linux.intel.com
* tree-ssa-dom.c (iterative_hash_exprs_commutative): Convert to inchash.
(iterative_hash_hashable_expr): Dito.
(avail_expr_hash): Dito.
---
gcc/tree-ssa-dom.c | 79 +-
1 file changed, 36 insertions(+), 43 deletions(-)
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index 08fd2fa..abf2b2e4 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -55,6 +55,7 @@ along with GCC; see the file COPYING3. If not see
#include params.h
#include tree-ssa-threadedge.h
#include tree-ssa-dom.h
+#include inchash.h
/* This file implements optimizations on the dominator tree. */
@@ -557,45 +558,40 @@ hashable_expr_equal_p (const struct hashable_expr *expr0,
}
/* Generate a hash value for a pair of expressions. This can be used
- iteratively by passing a previous result as the VAL argument.
+ iteratively by passing a previous result in HSTATE.
The same hash value is always returned for a given pair of expressions,
regardless of the order in which they are presented. This is useful in
hashing the operands of commutative functions. */
-static hashval_t
+static void
iterative_hash_exprs_commutative (const_tree t1,
- const_tree t2, hashval_t val)
+ const_tree t2, inchash hstate)
{
- hashval_t one = iterative_hash_expr (t1, 0);
- hashval_t two = iterative_hash_expr (t2, 0);
- hashval_t t;
-
- if (one two)
-t = one, one = two, two = t;
- val = iterative_hash_hashval_t (one, val);
- val = iterative_hash_hashval_t (two, val);
+ inchash one, two;
- return val;
+ iterative_hstate_expr (t1, one);
+ iterative_hstate_expr (t2, two);
+ hstate.add_commutative (one, two);
}
/* Compute a hash value for a hashable_expr value EXPR and a
previously accumulated hash value VAL. If two hashable_expr
values compare equal with hashable_expr_equal_p, they must
hash to the same value, given an identical value of VAL.
- The logic is intended to follow iterative_hash_expr in tree.c. */
+ The logic is intended to follow iterative_hstate_expr in tree.c. */
-static hashval_t
-iterative_hash_hashable_expr (const struct hashable_expr *expr, hashval_t val)
+static void
+iterative_hash_hashable_expr (const struct hashable_expr *expr, inchash
hstate)
{
switch (expr-kind)
{
case EXPR_SINGLE:
- val = iterative_hash_expr (expr-ops.single.rhs, val);
+ iterative_hstate_expr (expr-ops.single.rhs, hstate);
break;
case EXPR_UNARY:
- val = iterative_hash_object (expr-ops.unary.op, val);
+ hstate.add_object (expr-ops.unary.op);
/* Make sure to include signedness in the hash computation.
Don't hash the type, that can lead to having nodes which
@@ -603,34 +599,34 @@ iterative_hash_hashable_expr (const struct hashable_expr
*expr, hashval_t val)
have different hash codes. */
if (CONVERT_EXPR_CODE_P (expr-ops.unary.op)
|| expr-ops.unary.op == NON_LVALUE_EXPR)
-val += TYPE_UNSIGNED (expr-type);
+hstate.add_int (TYPE_UNSIGNED (expr-type));
- val = iterative_hash_expr (expr-ops.unary.opnd, val);
+ iterative_hstate_expr (expr-ops.unary.opnd, hstate);
break;
case EXPR_BINARY:
- val = iterative_hash_object (expr-ops.binary.op, val);
+ hstate.add_object (expr-ops.binary.op);
if (commutative_tree_code (expr-ops.binary.op))
- val = iterative_hash_exprs_commutative (expr-ops.binary.opnd0,
- expr-ops.binary.opnd1, val);
+ iterative_hash_exprs_commutative (expr-ops.binary.opnd0,
+ expr-ops.binary.opnd1, hstate);
else
{
- val = iterative_hash_expr (expr-ops.binary.opnd0, val);
- val = iterative_hash_expr (expr-ops.binary.opnd1, val);
+ iterative_hstate_expr (expr-ops.binary.opnd0, hstate);
+ iterative_hstate_expr (expr-ops.binary.opnd1, hstate);
}
break;
case EXPR_TERNARY:
- val = iterative_hash_object (expr-ops.ternary.op, val);
+ hstate.add_object (expr-ops.ternary.op);
if (commutative_ternary_tree_code (expr-ops.ternary.op))
- val = iterative_hash_exprs_commutative (expr-ops.ternary.opnd0,
- expr-ops.ternary.opnd1, val);
+ iterative_hash_exprs_commutative (expr-ops.ternary.opnd0,
+ expr-ops.ternary.opnd1, hstate);
else
{
- val = iterative_hash_expr (expr-ops.ternary.opnd0, val);
- val = iterative_hash_expr (expr-ops.ternary.opnd1, val);
+ iterative_hstate_expr (expr-ops.ternary.opnd0, hstate);
+ iterative_hstate_expr (expr-ops.ternary.opnd1, hstate);
}
- val =
[PATCH 6/6] Convert tree-ssa-tail-merge to inchash
From: Andi Kleen a...@linux.intel.com
gcc/:
2014-07-25 Andi Kleen a...@linux.intel.com
* tree-ssa-tail-merge.c (same_succ_hash): Convert to inchash.
---
gcc/tree-ssa-tail-merge.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/gcc/tree-ssa-tail-merge.c b/gcc/tree-ssa-tail-merge.c
index 9600e28..a27af5b 100644
--- a/gcc/tree-ssa-tail-merge.c
+++ b/gcc/tree-ssa-tail-merge.c
@@ -451,7 +451,7 @@ stmt_update_dep_bb (gimple stmt)
static hashval_t
same_succ_hash (const_same_succ e)
{
- hashval_t hashval = bitmap_hash (e-succs);
+ inchash hstate (bitmap_hash (e-succs));
int flags;
unsigned int i;
unsigned int first = bitmap_first_set_bit (e-bbs);
@@ -472,37 +472,35 @@ same_succ_hash (const_same_succ e)
continue;
size++;
- hashval = iterative_hash_hashval_t (gimple_code (stmt), hashval);
+ hstate.add_int (gimple_code (stmt));
if (is_gimple_assign (stmt))
- hashval = iterative_hash_hashval_t (gimple_assign_rhs_code (stmt),
- hashval);
+ hstate.add_int (gimple_assign_rhs_code (stmt));
if (!is_gimple_call (stmt))
continue;
if (gimple_call_internal_p (stmt))
- hashval = iterative_hash_hashval_t
- ((hashval_t) gimple_call_internal_fn (stmt), hashval);
+hstate.add_int (gimple_call_internal_fn (stmt));
else
{
- hashval = iterative_hash_expr (gimple_call_fn (stmt), hashval);
+ iterative_hstate_expr (gimple_call_fn (stmt), hstate);
if (gimple_call_chain (stmt))
- hashval = iterative_hash_expr (gimple_call_chain (stmt), hashval);
+ iterative_hstate_expr (gimple_call_chain (stmt), hstate);
}
for (i = 0; i gimple_call_num_args (stmt); i++)
{
arg = gimple_call_arg (stmt, i);
arg = vn_valueize (arg);
- hashval = iterative_hash_expr (arg, hashval);
+ iterative_hstate_expr (arg, hstate);
}
}
- hashval = iterative_hash_hashval_t (size, hashval);
+ hstate.add_int (size);
BB_SIZE (bb) = size;
for (i = 0; i e-succ_flags.length (); ++i)
{
flags = e-succ_flags[i];
flags = flags ~(EDGE_TRUE_VALUE | EDGE_FALSE_VALUE);
- hashval = iterative_hash_hashval_t (flags, hashval);
+ hstate.add_int (flags);
}
EXECUTE_IF_SET_IN_BITMAP (e-succs, 0, s, bs)
@@ -521,7 +519,7 @@ same_succ_hash (const_same_succ e)
}
}
- return hashval;
+ return hstate.end ();
}
/* Returns true if E1 and E2 have 2 successors, and if the successor flags
--
2.0.1
[PATCH 5/6] Convert tree-ssa-sccvn to inchash
From: Andi Kleen a...@linux.intel.com
gcc/:
2014-07-25 Andi Kleen a...@linux.intel.com
* tree-ssa-sccvn.c (vn_reference_op_compute_hash):
(vn_reference_compute_hash):
(vn_nary_op_compute_hash):
(vn_phi_compute_hash):
* tree-ssa-sccvn.h (vn_hash_constant_with_type):
---
gcc/tree-ssa-sccvn.c | 44 ++--
gcc/tree-ssa-sccvn.h | 6 --
2 files changed, 26 insertions(+), 24 deletions(-)
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 93314fc..160ca00 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -594,17 +594,16 @@ value_id_constant_p (unsigned int v)
/* Compute the hash for a reference operand VRO1. */
-static hashval_t
-vn_reference_op_compute_hash (const vn_reference_op_t vro1, hashval_t result)
+static void
+vn_reference_op_compute_hash (const vn_reference_op_t vro1, inchash hstate)
{
- result = iterative_hash_hashval_t (vro1-opcode, result);
+ hstate.add_int (vro1-opcode);
if (vro1-op0)
-result = iterative_hash_expr (vro1-op0, result);
+iterative_hstate_expr (vro1-op0, hstate);
if (vro1-op1)
-result = iterative_hash_expr (vro1-op1, result);
+iterative_hstate_expr (vro1-op1, hstate);
if (vro1-op2)
-result = iterative_hash_expr (vro1-op2, result);
- return result;
+iterative_hstate_expr (vro1-op2, hstate);
}
/* Compute a hash for the reference operation VR1 and return it. */
@@ -612,7 +611,8 @@ vn_reference_op_compute_hash (const vn_reference_op_t vro1,
hashval_t result)
hashval_t
vn_reference_compute_hash (const vn_reference_t vr1)
{
- hashval_t result = 0;
+ inchash hstate;
+ hashval_t result;
int i;
vn_reference_op_t vro;
HOST_WIDE_INT off = -1;
@@ -634,7 +634,7 @@ vn_reference_compute_hash (const vn_reference_t vr1)
{
if (off != -1
off != 0)
- result = iterative_hash_hashval_t (off, result);
+ hstate.add_int (off);
off = -1;
if (deref
vro-opcode == ADDR_EXPR)
@@ -642,14 +642,16 @@ vn_reference_compute_hash (const vn_reference_t vr1)
if (vro-op0)
{
tree op = TREE_OPERAND (vro-op0, 0);
- result = iterative_hash_hashval_t (TREE_CODE (op), result);
- result = iterative_hash_expr (op, result);
+ hstate.add_int (TREE_CODE (op));
+ iterative_hstate_expr (op, hstate);
}
}
else
- result = vn_reference_op_compute_hash (vro, result);
+ vn_reference_op_compute_hash (vro, hstate);
}
}
+ result = hstate.end ();
+ /* ??? We would ICE later if we hash instead of adding that in. */
if (vr1-vuse)
result += SSA_NAME_VERSION (vr1-vuse);
@@ -2236,7 +2238,7 @@ vn_reference_insert_pieces (tree vuse, alias_set_type
set, tree type,
hashval_t
vn_nary_op_compute_hash (const vn_nary_op_t vno1)
{
- hashval_t hash;
+ inchash hstate;
unsigned i;
for (i = 0; i vno1-length; ++i)
@@ -2252,11 +2254,11 @@ vn_nary_op_compute_hash (const vn_nary_op_t vno1)
vno1-op[1] = temp;
}
- hash = iterative_hash_hashval_t (vno1-opcode, 0);
+ hstate.add_int (vno1-opcode);
for (i = 0; i vno1-length; ++i)
-hash = iterative_hash_expr (vno1-op[i], hash);
+iterative_hstate_expr (vno1-op[i], hstate);
- return hash;
+ return hstate.end ();
}
/* Compare nary operations VNO1 and VNO2 and return true if they are
@@ -2536,26 +2538,24 @@ vn_nary_op_insert_stmt (gimple stmt, tree result)
static inline hashval_t
vn_phi_compute_hash (vn_phi_t vp1)
{
- hashval_t result;
+ inchash hstate (vp1-block-index);
int i;
tree phi1op;
tree type;
- result = vp1-block-index;
-
/* If all PHI arguments are constants we need to distinguish
the PHI node via its type. */
type = vp1-type;
- result += vn_hash_type (type);
+ hstate.merge_hash (vn_hash_type (type));
FOR_EACH_VEC_ELT (vp1-phiargs, i, phi1op)
{
if (phi1op == VN_TOP)
continue;
- result = iterative_hash_expr (phi1op, result);
+ iterative_hstate_expr (phi1op, hstate);
}
- return result;
+ return hstate.end ();
}
/* Compare two phi entries for equality, ignoring VN_TOP arguments. */
diff --git a/gcc/tree-ssa-sccvn.h b/gcc/tree-ssa-sccvn.h
index f52783a..f420656 100644
--- a/gcc/tree-ssa-sccvn.h
+++ b/gcc/tree-ssa-sccvn.h
@@ -140,8 +140,10 @@ vn_hash_type (tree type)
static inline hashval_t
vn_hash_constant_with_type (tree constant)
{
- return (iterative_hash_expr (constant, 0)
- + vn_hash_type (TREE_TYPE (constant)));
+ inchash hstate;
+ iterative_hstate_expr (constant, hstate);
+ hstate.merge_hash (vn_hash_type (TREE_TYPE (constant)));
+ return hstate.end ();
}
/* Compare the constants C1 and C2 with distinguishing type incompatible
--
2.0.1
[PATCH 1/6] RTL dwarf2out changes
From: Andi Kleen a...@linux.intel.com
Convert dwarf2out and rtl.c to the new inchash interface.
I moved the rtl hash code to another file to avoid having to link
all the hash code into the generator functions.
gcc/:
2014-07-25 Andi Kleen a...@linux.intel.com
* Makefile.in (OBJS): Add rtlhash.o
* dwarf2out.c (addr_table_entry_do_hash): Convert to inchash.
(loc_checksum): Dito.
(loc_checksum_ordered): Dito.
(hash_loc_operands): Dito.
(hash_locs): Dito.
(hash_loc_list): Dito.
* rtl.c (iterative_hash_rtx): Moved to rtlhash.c
* rtl.h (iterative_hash_rtx): Moved to rtlhash.h
* rtlhash.c: New file.
* rtlhash.h: New file.
---
gcc/Makefile.in | 1 +
gcc/dwarf2out.c | 126 +---
gcc/rtl.c | 79 +--
gcc/rtl.h | 1 -
gcc/rtlhash.c | 102 +
gcc/rtlhash.h | 27
6 files changed, 197 insertions(+), 139 deletions(-)
create mode 100644 gcc/rtlhash.c
create mode 100644 gcc/rtlhash.h
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 4c578b3..a2fb5f5 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1350,6 +1350,7 @@ OBJS = \
resource.o \
rtl-error.o \
rtl.o \
+ rtlhash.o \
rtlanal.o \
rtlhooks.o \
sbitmap.o \
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 8fd1945..26fb34c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -71,6 +71,7 @@ along with GCC; see the file COPYING3. If not see
#include flags.h
#include hard-reg-set.h
#include regs.h
+#include rtlhash.h
#include insn-config.h
#include reload.h
#include function.h
@@ -3277,7 +3278,7 @@ static void gen_scheduled_generic_parms_dies (void);
static const char *comp_dir_string (void);
-static hashval_t hash_loc_operands (dw_loc_descr_ref, hashval_t);
+static void hash_loc_operands (dw_loc_descr_ref, inchash );
/* enum for tracking thread-local variables whose address is really an offset
relative to the TLS pointer, which will need link-time relocation, but will
@@ -4190,17 +4191,22 @@ static hashval_t
addr_table_entry_do_hash (const void *x)
{
const addr_table_entry *a = (const addr_table_entry *) x;
+ inchash hstate;
switch (a-kind)
{
case ate_kind_rtx:
-return iterative_hash_rtx (a-addr.rtl, 0);
+ hstate.add_int (0);
+ break;
case ate_kind_rtx_dtprel:
-return iterative_hash_rtx (a-addr.rtl, 1);
+ hstate.add_int (1);
+ break;
case ate_kind_label:
return htab_hash_string (a-addr.label);
default:
gcc_unreachable ();
}
+ iterative_hstate_rtx (a-addr.rtl, hstate);
+ return hstate.end ();
}
/* Determine equality for two address_table_entries. */
@@ -5544,11 +5550,14 @@ static inline void
loc_checksum (dw_loc_descr_ref loc, struct md5_ctx *ctx)
{
int tem;
- hashval_t hash = 0;
+ inchash hstate;
+ hashval_t hash;
tem = (loc-dtprel 8) | ((unsigned int) loc-dw_loc_opc);
CHECKSUM (tem);
- hash = hash_loc_operands (loc, hash);
+ hash_loc_operands (loc, hstate);
+ /* ??? MD5 of another hash doesn't make a lot of sense... */
+ hash = hstate.end();
CHECKSUM (hash);
}
@@ -5758,11 +5767,13 @@ loc_checksum_ordered (dw_loc_descr_ref loc, struct
md5_ctx *ctx)
/* Otherwise, just checksum the raw location expression. */
while (loc != NULL)
{
- hashval_t hash = 0;
+ inchash hstate;
+ hashval_t hash;
CHECKSUM_ULEB128 (loc-dtprel);
CHECKSUM_ULEB128 (loc-dw_loc_opc);
- hash = hash_loc_operands (loc, hash);
+ hash_loc_operands (loc, hstate);
+ hash = hstate.end ();
CHECKSUM (hash);
loc = loc-dw_loc_next;
}
@@ -23619,10 +23630,10 @@ resolve_addr (dw_die_ref die)
This pass tries to share identical local lists in .debug_loc
section. */
-/* Iteratively hash operands of LOC opcode. */
+/* Iteratively hash operands of LOC opcode into HSTATE. */
-static hashval_t
-hash_loc_operands (dw_loc_descr_ref loc, hashval_t hash)
+static void
+hash_loc_operands (dw_loc_descr_ref loc, inchash hstate)
{
dw_val_ref val1 = loc-dw_loc_oprnd1;
dw_val_ref val2 = loc-dw_loc_oprnd2;
@@ -23681,7 +23692,7 @@ hash_loc_operands (dw_loc_descr_ref loc, hashval_t hash)
case DW_OP_piece:
case DW_OP_deref_size:
case DW_OP_xderef_size:
- hash = iterative_hash_object (val1-v.val_int, hash);
+ hstate.add_object (val1-v.val_int);
break;
case DW_OP_skip:
case DW_OP_bra:
@@ -23690,36 +23701,35 @@ hash_loc_operands (dw_loc_descr_ref loc, hashval_t
hash)
gcc_assert (val1-val_class == dw_val_class_loc);
offset = val1-v.val_loc-dw_loc_addr - (loc-dw_loc_addr + 3);
- hash = iterative_hash_object (offset, hash);
+ hstate.add_object (offset);
}
break;
case
Re: Warn when returning the address of a temporary (middle-end) v2
Marc Glisse marc.gli...@inria.fr writes: On Sun, 27 Jul 2014, Richard Sandiford wrote: Marc Glisse marc.gli...@inria.fr writes: + if (always_executed) + msg = function returns address of local variable; + else + msg = function may return address of local variable; I think you need _(...) here, unless some magic makes that unnecessary now. I just tried to see how the magic happens when someone calls error_at, and it goes through diagnostic_set_info, which contains: diagnostic_set_info_translated (diagnostic, _(gmsgid), args, location, kind); So I think the _(...) is already taken care of. But I don't know that code at all and I could easily have looked at it wrong. If the msgid is not a direct argument of the diagnostic function you need to mark the string with N_(...). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
[GSoC][match-and-simplify] sanitize option checking
Added checks to see if either cmmand-line options is not repeated,
and generates match-and-simplify code on both GENERIC and GIMPLE
if both -generic and -gimple are specified.
* genmatch.c (cmd_options): New struct.
(check_repeated_arg): New function.
(parse_cmd_arg): Likewise.
(main): Emit diagnostic if no command line options are given.
Add call to parse_cmd_arg.
Thanks,
Prathamesh
Index: genmatch.c
===
--- genmatch.c (revision 212928)
+++ genmatch.c (working copy)
@@ -2118,6 +2118,34 @@ parse_pattern (cpp_reader *r, vecsimpli
eat_token (r, CPP_CLOSE_PAREN);
}
+struct cmd_options
+{
+ bool generic;
+ bool gimple;
+ bool verbose;
+
+ cmd_options (): generic (false), gimple (false), verbose (false) {}
+};
+
+void
+check_repeated_arg (const char *arg, const char *expected_arg, bool option)
+{
+ if (strcmp (arg, expected_arg) == 0)
+{
+ if (option)
+ fatal (%s repeated, arg);
+ option = true;
+}
+}
+
+void
+parse_cmd_arg (const char *arg, cmd_options opt)
+{
+ check_repeated_arg (arg, -gimple, opt.gimple);
+ check_repeated_arg (arg, -generic, opt.generic);
+ check_repeated_arg (arg, -v, opt.verbose);
+}
+
int
main(int argc, char **argv)
{
@@ -2126,25 +2154,12 @@ main(int argc, char **argv)
progname = genmatch;
if (argc 2)
-return 1;
+fatal (pd file not specified);
- bool gimple = true;
- bool verbose = false;
+ cmd_options opt;
char *input = argv[argc-1];
for (int i = 1; i argc - 1; ++i)
-{
- if (strcmp (argv[i], -gimple) == 0)
- gimple = true;
- else if (strcmp (argv[i], -generic) == 0)
- gimple = false;
- else if (strcmp (argv[i], -v) == 0)
- verbose = true;
- else
- {
- fprintf (stderr, Usage: genmatch [-gimple] [-generic] [-v] input\n);
- return 1;
- }
-}
+parse_cmd_arg (argv[i], opt);
line_table = XCNEW (struct line_maps);
linemap_init (line_table);
@@ -2157,7 +2172,7 @@ main(int argc, char **argv)
if (!cpp_read_main_file (r, input))
return 1;
- cpp_define (r, gimple ? GIMPLE=1: GENERIC=1);
+ cpp_define (r, opt.gimple ? GIMPLE=1: GENERIC=1);
/* Pre-seed operators. */
operators.create (1024);
@@ -2188,7 +2203,7 @@ main(int argc, char **argv)
for (unsigned i = 0; i simplifiers.length (); ++i)
lower_commutative (simplifiers[i], out_simplifiers);
- if (verbose)
+ if (opt.verbose)
for (unsigned i = 0; i out_simplifiers.length (); ++i)
print_matches (out_simplifiers[i]);
@@ -2196,15 +2211,16 @@ main(int argc, char **argv)
for (unsigned i = 0; i out_simplifiers.length (); ++i)
dt.insert (out_simplifiers[i], i);
- if (verbose)
+ if (opt.verbose)
dt.print (stderr);
- if (gimple)
+ if (opt.gimple)
{
write_header (stdout, out_simplifiers, gimple-match-head.c);
dt.gen_gimple (stdout);
}
- else
+
+ if (opt.generic)
{
write_header (stdout, out_simplifiers, generic-match-head.c);
dt.gen_generic (stdout);
Re: Warn when returning the address of a temporary (middle-end) v2
On Sun, 27 Jul 2014, Andreas Schwab wrote: Marc Glisse marc.gli...@inria.fr writes: On Sun, 27 Jul 2014, Richard Sandiford wrote: Marc Glisse marc.gli...@inria.fr writes: + if (always_executed) + msg = function returns address of local variable; + else + msg = function may return address of local variable; I think you need _(...) here, unless some magic makes that unnecessary now. I just tried to see how the magic happens when someone calls error_at, and it goes through diagnostic_set_info, which contains: diagnostic_set_info_translated (diagnostic, _(gmsgid), args, location, kind); So I think the _(...) is already taken care of. But I don't know that code at all and I could easily have looked at it wrong. If the msgid is not a direct argument of the diagnostic function you need to mark the string with N_(...). Ah, ok, thanks. Actually, shouldn't it be G_ instead? That's what ABOUT-GCC-NLS seems to suggest since 2005, though I don't expect it makes any difference for simple strings. -- Marc Glisse
[GSoC][match-and-simplify] include is-a.h
Is it okay to include is-a.h ?
I have adjusted print_operand to use is_a and as_a in this patch.
* genmatch.c (is-a.h): Include.
(is_a_helper::test): Specialize for operand subclasses.
(print_operand): Adjust to use is_a and as_a.
Thanks,
Prathamesh.
Index: genmatch.c
===
--- genmatch.c (revision 212928)
+++ genmatch.c (working copy)
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.
#include hashtab.h
#include hash-table.h
#include vec.h
+#include is-a.h
/* libccp helpers. */
@@ -256,6 +257,39 @@ struct capture : public operand
virtual void gen_transform (FILE *f, const char *, bool);
};
+template
+template
+inline bool
+is_a_helper capture *::test (operand *op)
+{
+ return op-type == operand::OP_CAPTURE;
+}
+
+template
+template
+inline bool
+is_a_helper predicate *::test (operand *op)
+{
+ return op-type == operand::OP_PREDICATE;
+}
+
+template
+template
+inline bool
+is_a_helper c_expr *::test (operand *op)
+{
+ return op-type == operand::OP_C_EXPR;
+}
+
+template
+template
+inline bool
+is_a_helper expr *::test (operand *op)
+{
+ return op-type == operand::OP_EXPR;
+}
+
+
e_operation::e_operation (const char *id, bool is_commutative_, bool add_new_id)
{
is_commutative = is_commutative_;
@@ -415,10 +449,10 @@ struct decision_tree
DEBUG_FUNCTION void
print_operand (operand *o, FILE *f = stderr, bool flattened = false)
{
- if (o-type == operand::OP_CAPTURE)
+ if (is_acapture * (o))
{
- capture *c = static_castcapture * (o);
- fprintf (f, @%s, (static_castcapture * (o))-where);
+ capture *c = as_acapture * (o);
+ fprintf (f, @%s, c-where);
if (c-what flattened == false)
{
putc (':', f);
@@ -427,15 +461,15 @@ print_operand (operand *o, FILE *f = std
}
}
- else if (o-type == operand::OP_PREDICATE)
-fprintf (f, %s, (static_castpredicate * (o))-ident);
+ else if (is_apredicate * (o))
+fprintf (f, %s, (as_apredicate * (o))-ident);
- else if (o-type == operand::OP_C_EXPR)
+ else if (is_ac_expr * (o))
fprintf (f, c_expr);
- else if (o-type == operand::OP_EXPR)
+ else if (is_aexpr * (o))
{
- expr *e = static_castexpr * (o);
+ expr *e = as_aexpr * (o);
fprintf (f, (%s, e-operation-op-id);
if (flattened == false)
Aw: RE: Re: [MIPS r5900] libgcc floating point fixes
Jürgen Urban juergenur...@gmx.dewrites: Jürgen Urban juergenur...@gmx.de writes: Hello Richard, Jürgen Urban juergenur...@gmx.de writes: Is this something you have recently developed outside of the mainline kernel or does it already exist. I'm not aware of such logic in the MIPS kernel yet. Yes, this is developed in my kernel which currently is still based on Linux 2.6.35.4. I added a TIF_R5900FPU flag to thread_info.h. I plan that this will get part of the mainline kernel. As the patch is too large to get accepted, I need to change the binutils, so that sync.p will be added after or before the right instruction automatically. Is the TIF_R5900FPU flag to do something more than just change the register model used by the FPU emulator or does it do something more/less? Currently it just enables or disables the FPU. When FPU is disabled the software emulation is used. I'm afraid I don’t know the significance of the sync.p. double the FPU emulator gets activated. Currently it only checks whether the architecture is mips r5900 or not. For non r5900 the FPU emulator is activated. It seems that we also need to add something to the ELF file to specify the 32 bit or 64 bit for float. It would be good when it is not at a so complicated position as the soft vs hard float flag, because it needs to be read by the kernel when starting a ELF file. This way it would also be I have a series of patches that will add this kind of support to the MIPS ABI in the coming weeks for similar reasons but relating to O32 and double-float ABI extensions. You will be able to directly hang off the changes once I commit (testing is taking some time). There should be no need for extra changes to gcc or binutils to get the information you need. Kernel changes to respond to new ABI information are also in progress and will be easily extendable. possible to emulate the r5900 FPU on a TX79 system. The TX79 is the same as r5900, but the FPU is 64 bit and compliant to IEEE 754. Note that this won't really be correct for r5900 anyway because of its non-IEEE FPU. E.g. the soft-float routines will treat 0x7f80 as infinity and 0x7fff as a NaN, whereas for r5900 they should be treated as normal numbers. The code looked like it uses the configured floating point configuration for hard float, but you are right the conversion is not working in these cases. I think there is no problem with the second part of the patch which disables t-mips16 for r5900. So could you commit the last part of the patch? Are you looking to add support for a single-float FPU to a number of packages as part of this? One thing that comes to mind would be libffi but the double-precision ABIs are assumed to be the only ones used in Linux in a number of places. Just trying to get a feel for your end goal out of curiosity. The libffi doesn't look like that there is a change needed for floating point. Libffi and most other hand crafted code for linux are written to follow the standard double-precision O32/N32 ABI. The single-precision variants are link-incompatible as they change the calling convention. I.e. when you pass a double-precision value using a single-precision calling-convention then it gets passed in GPRs instead of FPRs. It is possible that it needs a change for TImode or for 2 or 3 of the other co-processors which are currently not under discussion. The long term plan is to have 32 bit floating point operations compliant to IEEE 754 with ABI o32 and n32. Everything should stay inside gcc, libgcc and the kernel (i.e. Linux or PS2SDK). I want to fix it at the lowest level and not in any high level library. Due to the calling convention change you won't be able to restrict the work to just the toolchain and kernel. MIPS linux theoretically supports two ABI extensions 'hard-float (double-precision)' and soft-float. I have a feeling that the soft-float extension is not supported everywhere but may be a better start point for what you want to achieve, i.e. use a soft-float calling convention but add support for using FPU instructions at the same time. This would be akin to arm's softfp float-abi. Fixes for high level libraries should also be high level (dmult vs __FLT_MAX_EXP__); i.e. there should be no change in a different package which is specific for MIPS. The type double should stay double and is handled without a problem when the FPU is 32 bit in ABI o32. The problem is only with the single/double conversion functions and the ABI n32. I didn't quite follow why you specifically say n32 in the last sentence... What is harder to fix about n32 than o32? -msingle-float with n32 creates 64 bit FPU instructions like dmtc1 and dmfc1. So I can't compile it for r5900. When I disable it, I get internal compiler
Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields
On Sun, Jul 27, 2014 at 03:16:03PM +0200, Matthias Klose wrote: Blah, that won't work of course. The macro needs to take two parameters. #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) false This is pre-approved if it works. I really should finish off the branch I started years ago :). #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) 0 is what succeeds for me. false is not defined for ObjC. Checked in on the trunk and the branches. Heh, that's what I found this morning too, when checking the bootstrap I'd fired off after posting the correction. -- Alan Modra Australia Development Lab, IBM
Re: Patch for constexpr variable templates
So given this, should I leave the test cases that fail for this reason alone or should I still change them to dg-message? It sounds like GCC's behavior with auto in function parameters needs to be changed, but that definitely sounds like a separate patch to me. - Braden Obrzut
