Re: [patch, mips] Fix for loongson prefetching and -mabi=32
"Steve Ellcey " writes:
> diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
> index 397c40a..ad03040 100644
> --- a/gcc/config/mips/mips.md
> +++ b/gcc/config/mips/mips.md
> @@ -6674,7 +6674,10 @@
> {
>if (TARGET_LOONGSON_2EF || TARGET_LOONGSON_3A)
> /* Loongson 2[ef] and Loongson 3a use load to $0 to perform prefetching.
> */
> -return "ld\t$0,%a0";
> +if (TARGET_64BIT)
> + return "ld\t$0,%a0";
> +else
> + return "lw\t$0,%a0";
>operands[1] = mips_prefetch_cookie (operands[1], operands[2]);
>return "pref\t%1,%a0";
> }
The inner "if" needs to be wrapped in braces to avoid a warning.
OK with that change, thanks.
Richard
[PATCH] Fix asan ICE with strlen instrumentation (PR sanitizer/56417)
Hi!
On the following (nonsensical) testcase we ICE because of pointer type
mismatch. Fixed thusly, bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk/4.8?
2013-08-13 Jakub Jelinek
PR sanitizer/56417
* asan.c (instrument_strlen_call): Fix typo in comment.
Use char * type even for the lhs of POINTER_PLUS_EXPR.
* gcc.dg/asan/pr56417.c: New test.
--- gcc/asan.c.jj 2013-06-03 18:11:44.0 +0200
+++ gcc/asan.c 2013-07-22 22:28:11.467415676 +0200
@@ -1648,7 +1648,7 @@ instrument_mem_region_access (tree base,
access to the last byte of the argument; it uses the result of the
call to deduce the offset of that last byte.
- Upon completion, iff the call has actullay been instrumented, this
+ Upon completion, iff the call has actually been instrumented, this
function returns TRUE and *ITER points to the statement logically
following the built-in strlen function call *ITER was initially
pointing to. Otherwise, the function returns FALSE and *ITER
@@ -1679,10 +1679,10 @@ instrument_strlen_call (gimple_stmt_iter
/* Instrument the access to the first byte of str_arg. i.e:
_1 = str_arg; instrument (_1); */
+ tree cptr_type = build_pointer_type (char_type_node);
gimple str_arg_ssa =
gimple_build_assign_with_ops (NOP_EXPR,
- make_ssa_name (build_pointer_type
-(char_type_node), NULL),
+ make_ssa_name (cptr_type, NULL),
str_arg, NULL);
gimple_set_location (str_arg_ssa, loc);
gimple_stmt_iterator gsi = *iter;
@@ -1701,8 +1701,7 @@ instrument_strlen_call (gimple_stmt_iter
pointer_plus expr: (_1 + len). */
gimple stmt =
gimple_build_assign_with_ops (POINTER_PLUS_EXPR,
- make_ssa_name (TREE_TYPE (str_arg),
-NULL),
+ make_ssa_name (cptr_type, NULL),
gimple_assign_lhs (str_arg_ssa),
len);
gimple_set_location (stmt, loc);
--- gcc/testsuite/gcc.dg/asan/pr56417.c.jj 2013-07-22 22:34:39.376469948
+0200
+++ gcc/testsuite/gcc.dg/asan/pr56417.c 2013-07-22 21:36:39.0 +0200
@@ -0,0 +1,9 @@
+/* PR sanitizer/56417 */
+/* { dg-do compile } */
+/* { dg-options "-w" } */
+
+int
+foo (void)
+{
+ return __builtin_strlen (&foo);
+}
Jakub
[PATCH] Fix ICE with MEM_REF clobbers with anonymous SSA_NAME (PR tree-optimization/57661)
Hi!
On the following testcase we ICE because we have an indirect (MEM_REF)
clobber stmt that uses anonymous SSA_NAME. ipa-split.c (intentionally)
ignores clobber stmts because they don't result in executable code,
but that can lead into clobber stmts mentioning SSA_NAMEs that aren't
initialized. For non-anonymous SSA_NAMEs that is not an issue, we just drop
those during tree-ssa-live.c later on (clobber stmts are always optional
and furthermore in ipa-split case the clobber stmts are duplicated both
in the (to be inlined) caller and callee), but for anonymous SSA_NAMEs
there is no such thing as (D) and thus we ICE.
Fixed by removing those clobber stmts already during function versioning
during ipa-split.c.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-08-13 Jakub Jelinek
PR tree-optimization/57661
* tree-inline.h (struct copy_body_data): Add blocks_to_copy field.
* tree-inline.c (tree_function_versioning): Initialize it.
(remap_gimple_stmt): Return GIMPLE_NOP for MEM_REF lhs clobber stmts
if id->blocks_to_copy and MEM_REF's SSA_NAME is defined in a block
that is not being copied.
* g++.dg/opt/pr57661.C: New test.
--- gcc/tree-inline.h.jj2013-06-03 18:11:57.0 +0200
+++ gcc/tree-inline.h 2013-07-23 00:38:14.362153447 +0200
@@ -115,6 +115,10 @@ typedef struct copy_body_data
/* Entry basic block to currently copied body. */
basic_block entry_bb;
+ /* For partial function versioning, bitmap of bbs to be copied,
+ otherwise NULL. */
+ bitmap blocks_to_copy;
+
/* Debug statements that need processing. */
vec debug_stmts;
--- gcc/tree-inline.c.jj2013-07-06 09:24:10.0 +0200
+++ gcc/tree-inline.c 2013-07-23 01:30:39.575893735 +0200
@@ -1387,6 +1387,23 @@ remap_gimple_stmt (gimple stmt, copy_bod
}
}
+ /* For *ptr_N ={v} {CLOBBER}, if ptr_N is SSA_NAME defined
+in a block that we aren't copying during tree_function_versioning,
+just drop the clobber stmt. */
+ if (id->blocks_to_copy && gimple_clobber_p (stmt))
+ {
+ tree lhs = gimple_assign_lhs (stmt);
+ if (TREE_CODE (lhs) == MEM_REF
+ && TREE_CODE (TREE_OPERAND (lhs, 0)) == SSA_NAME)
+ {
+ gimple def_stmt = SSA_NAME_DEF_STMT (TREE_OPERAND (lhs, 0));
+ if (gimple_bb (def_stmt)
+ && !bitmap_bit_p (id->blocks_to_copy,
+ gimple_bb (def_stmt)->index))
+ return gimple_build_nop ();
+ }
+ }
+
if (gimple_debug_bind_p (stmt))
{
copy = gimple_build_debug_bind (gimple_debug_bind_get_var (stmt),
@@ -5091,6 +5108,7 @@ tree_function_versioning (tree old_decl,
id.src_node = old_version_node;
id.dst_node = new_version_node;
id.src_cfun = DECL_STRUCT_FUNCTION (old_decl);
+ id.blocks_to_copy = blocks_to_copy;
if (id.src_node->ipa_transforms_to_apply.exists ())
{
vec old_transforms_to_apply
--- gcc/testsuite/g++.dg/opt/pr57661.C.jj 2013-07-23 01:42:45.078284916
+0200
+++ gcc/testsuite/g++.dg/opt/pr57661.C 2013-07-23 01:41:41.0 +0200
@@ -0,0 +1,76 @@
+// PR tree-optimization/57661
+// { dg-do compile }
+// { dg-options "-O2 -fno-tree-forwprop -std=gnu++11" }
+
+template
+struct A
+{
+ ~A () {}
+};
+template
+using B = A <_Tp>;
+template
+class C : B <_Tp> {};
+namespace N { enum D { d }; }
+template
+struct E
+{
+ ~E ();
+};
+template
+struct F : V {};
+template
+struct G : F
+{
+ N::D g1;
+ void g2 ();
+ void g3 ();
+ void g4 () { g3 (); }
+ static void g5 (G *__t) { __t->g4 (); }
+};
+template
+struct H : G
+{
+ E *h1;
+ bool h2;
+ ~H () throw ()
+ {
+this->g2 ();
+if (h2)
+ delete h1;
+ }
+};
+template
+struct I : H , E
+{
+ G *i;
+ ~I () throw ()
+ {
+i->g4 ();
+ }
+};
+struct J
+{
+ typedef C j1;
+ typedef G > j2;
+ J ();
+ j2 *j3;
+};
+struct K : J
+{
+ typedef G > j2;
+ K () { j2::g5 (this->j3); }
+};
+template
+void G ::g3 ()
+{
+ switch (g1)
+{
+case N::d:
+ {
+ I *q = (I *) this;
+ q->I ::~I ();
+ }
+}
+}
+K r;
Jakub
Re: [PATCH] Possible fix for PR57717 (PowerPC E500v2)
On Mon, 12 Aug 2013 12:04:45 -0400 David Edelsohn wrote: > * config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Don't > perform invalid legitimization on greater-than-word-size modes for > TARGET_E500_DOUBLE. > > Disabling greater-than-word-size for E500v2 instead of continually > updating the enumeration seems reasonable. FAOD, is that an OK? Thanks, Julian
Re: [PATCH] Fix PR57980
On Mon, Aug 12, 2013 at 10:56:44AM +0200, Marek Polacek wrote: > On Fri, Aug 09, 2013 at 08:40:00PM +0200, Richard Biener wrote: > > Marek Polacek wrote: > > >In this PR the problem was that when dealing with the gimple assign in > > >the tailcall optimization, we, when the rhs operand is of a vector > > >type, need to create -1 also of a vector type, but build_int_cst > > >doesn't create vectors (ICEs). Instead, we should use > > >build_minus_one_cst > > >because that can create even the VECTOR_TYPE constant (and, it can > > >create even REAL_TYPE/COMPLEX_TYPE), as suggested by Marc. > > > > > >Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8? > > > > Ok. Double-check that this function exists on the branch please. > > It does not :(. So not backporting to 4.8... For 4.8/4.7, I'd say just change those else *m = build_int_cst (TREE_TYPE (...), -1); into else if (INTEGRAL_TYPE_P (TREE_TYPE (...))) *m = build_int_cst (TREE_TYPE (...), -1); else return false; Jakub
[Ada] Fix wrong code generated for packed array and pragma Shared
This is a rather unusual situation where a pragma Shared is put on a packed array. In this case, we generate wrong code for array accesses on BE targets. Tested on x86_64-suse-linux, applied on the mainline. 2013-08-13 Eric Botcazou * gcc-interface/utils2.c (build_atomic_load): Do a mere view-conversion to the original type before converting to the result type. (build_atomic_store): First do a conversion to the original type before view-converting to the effective type, but deal with a padded type specially. -- Eric Botcazou Index: gcc-interface/utils2.c === --- gcc-interface/utils2.c (revision 201622) +++ gcc-interface/utils2.c (working copy) @@ -648,11 +648,11 @@ build_atomic_load (tree src) (build_qualified_type (void_type_node, TYPE_QUAL_VOLATILE)); tree mem_model = build_int_cst (integer_type_node, MEMMODEL_SEQ_CST); tree orig_src = src; - tree type = TREE_TYPE (src); - tree t, val; + tree t, addr, val; unsigned int size; int fncode; + /* Remove conversions to get the address of the underlying object. */ src = remove_conversions (src, false); size = resolve_atomic_size (TREE_TYPE (src)); if (size == 0) @@ -661,10 +661,13 @@ build_atomic_load (tree src) fncode = (int) BUILT_IN_ATOMIC_LOAD_N + exact_log2 (size) + 1; t = builtin_decl_implicit ((enum built_in_function) fncode); - src = build_unary_op (ADDR_EXPR, ptr_type, src); - val = build_call_expr (t, 2, src, mem_model); + addr = build_unary_op (ADDR_EXPR, ptr_type, src); + val = build_call_expr (t, 2, addr, mem_model); - return unchecked_convert (type, val, true); + /* First reinterpret the loaded bits in the original type of the load, + then convert to the expected result type. */ + t = fold_build1 (VIEW_CONVERT_EXPR, TREE_TYPE (src), val); + return convert (TREE_TYPE (orig_src), t); } /* Build an atomic store from SRC to the underlying atomic object in DEST. */ @@ -677,10 +680,11 @@ build_atomic_store (tree dest, tree src) (build_qualified_type (void_type_node, TYPE_QUAL_VOLATILE)); tree mem_model = build_int_cst (integer_type_node, MEMMODEL_SEQ_CST); tree orig_dest = dest; - tree t, int_type; + tree t, int_type, addr; unsigned int size; int fncode; + /* Remove conversions to get the address of the underlying object. */ dest = remove_conversions (dest, false); size = resolve_atomic_size (TREE_TYPE (dest)); if (size == 0) @@ -690,10 +694,20 @@ build_atomic_store (tree dest, tree src) t = builtin_decl_implicit ((enum built_in_function) fncode); int_type = gnat_type_for_size (BITS_PER_UNIT * size, 1); - dest = build_unary_op (ADDR_EXPR, ptr_type, dest); - src = unchecked_convert (int_type, src, true); + /* First convert the bits to be stored to the original type of the store, + then reinterpret them in the effective type. But if the original type + is a padded type with the same size, convert to the inner type instead, + as we don't want to artificially introduce a CONSTRUCTOR here. */ + if (TYPE_IS_PADDING_P (TREE_TYPE (dest)) + && TYPE_SIZE (TREE_TYPE (dest)) + == TYPE_SIZE (TREE_TYPE (TYPE_FIELDS (TREE_TYPE (dest) +src = convert (TREE_TYPE (TYPE_FIELDS (TREE_TYPE (dest))), src); + else +src = convert (TREE_TYPE (dest), src); + src = fold_build1 (VIEW_CONVERT_EXPR, int_type, src); + addr = build_unary_op (ADDR_EXPR, ptr_type, dest); - return build_call_expr (t, 3, dest, src, mem_model); + return build_call_expr (t, 3, addr, src, mem_model); } /* Make a binary operation of kind OP_CODE. RESULT_TYPE is the type
Re: [PATCH] Fix PR57980
On Tue, Aug 13, 2013 at 12:24:59PM +0200, Jakub Jelinek wrote: > On Mon, Aug 12, 2013 at 10:56:44AM +0200, Marek Polacek wrote: > > On Fri, Aug 09, 2013 at 08:40:00PM +0200, Richard Biener wrote: > > > Marek Polacek wrote: > > > >In this PR the problem was that when dealing with the gimple assign in > > > >the tailcall optimization, we, when the rhs operand is of a vector > > > >type, need to create -1 also of a vector type, but build_int_cst > > > >doesn't create vectors (ICEs). Instead, we should use > > > >build_minus_one_cst > > > >because that can create even the VECTOR_TYPE constant (and, it can > > > >create even REAL_TYPE/COMPLEX_TYPE), as suggested by Marc. > > > > > > > >Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8? > > > > > > Ok. Double-check that this function exists on the branch please. > > > > It does not :(. So not backporting to 4.8... > > For 4.8/4.7, I'd say just change those > else > *m = build_int_cst (TREE_TYPE (...), -1); > into > else if (INTEGRAL_TYPE_P (TREE_TYPE (...))) > *m = build_int_cst (TREE_TYPE (...), -1); > else > return false; Also, for the testcase, typedef int V __attribute__ ((vector_size (sizeof (int; looks weird, that is one element vector, can you use 2 * sizeof (int) instead and add -w to dg-options (for the various -Wpsabi warnings)? Jakub
Re: [PATCH] Fix asan ICE with strlen instrumentation (PR sanitizer/56417)
Jakub Jelinek writes: > Hi! > > On the following (nonsensical) testcase we ICE because of pointer type > mismatch. Fixed thusly, bootstrapped/regtested on x86_64-linux and > i686-linux, ok for trunk/4.8? > > 2013-08-13 Jakub Jelinek > > PR sanitizer/56417 > * asan.c (instrument_strlen_call): Fix typo in comment. > Use char * type even for the lhs of POINTER_PLUS_EXPR. > > * gcc.dg/asan/pr56417.c: New test. This looks OK to me. Thanks for fixing this. -- Dodji
Re: [PATCH] Fix for PR c/57490
Hi Iyer, >First off, my sincerest apologies for letting this bug slip the cracks. I > am attaching a patch that seem to work fine with the .i file that you have > submitted in bugzilla for both C and C++. Please let me know if this fix > works for you and if it is OK for trunk. thanks for the patch. I've just bootstrapped it on i386-pc-solaris2.10 and all an-if.c failures are gone. That said, I wonder why we need the separate pr57490.c testcase, which is practically a preprocessed version of an-if.c with the HAVE_IO code removed. I cannot approve the patch, though. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Fix PR57980
On Tue, Aug 13, 2013 at 12:24:59PM +0200, Jakub Jelinek wrote:
> On Mon, Aug 12, 2013 at 10:56:44AM +0200, Marek Polacek wrote:
> > On Fri, Aug 09, 2013 at 08:40:00PM +0200, Richard Biener wrote:
> > > Marek Polacek wrote:
> > > >In this PR the problem was that when dealing with the gimple assign in
> > > >the tailcall optimization, we, when the rhs operand is of a vector
> > > >type, need to create -1 also of a vector type, but build_int_cst
> > > >doesn't create vectors (ICEs). Instead, we should use
> > > >build_minus_one_cst
> > > >because that can create even the VECTOR_TYPE constant (and, it can
> > > >create even REAL_TYPE/COMPLEX_TYPE), as suggested by Marc.
> > > >
> > > >Regtested/bootstrapped on x86_64-linux, ok for trunk and 4.8?
> > >
> > > Ok. Double-check that this function exists on the branch please.
> >
> > It does not :(. So not backporting to 4.8...
>
> For 4.8/4.7, I'd say just change those
> else
> *m = build_int_cst (TREE_TYPE (...), -1);
> into
> else if (INTEGRAL_TYPE_P (TREE_TYPE (...)))
> *m = build_int_cst (TREE_TYPE (...), -1);
> else
> return false;
Sure. Ok to apply this one if it passes regtesting?
2013-08-13 Marek Polacek
Jakub Jelinek
PR tree-optimization/57980
* tree-tailcall.c (process_assignment): Return false
when not dealing with integers or floats.
* gcc.dg/pr57980.c: New test.
--- gcc/tree-tailcall.c.mp 2013-08-13 13:42:33.969568463 +0200
+++ gcc/tree-tailcall.c 2013-08-13 13:44:57.288121663 +0200
@@ -328,8 +328,10 @@ process_assignment (gimple stmt, gimple_
case NEGATE_EXPR:
if (FLOAT_TYPE_P (TREE_TYPE (op0)))
*m = build_real (TREE_TYPE (op0), dconstm1);
- else
+ else if (INTEGRAL_TYPE_P (TREE_TYPE (op0)))
*m = build_int_cst (TREE_TYPE (op0), -1);
+ else
+return false;
*ass_var = dest;
return true;
@@ -341,8 +343,10 @@ process_assignment (gimple stmt, gimple_
{
if (FLOAT_TYPE_P (TREE_TYPE (non_ass_var)))
*m = build_real (TREE_TYPE (non_ass_var), dconstm1);
- else
+ else if (INTEGRAL_TYPE_P (TREE_TYPE (non_ass_var)))
*m = build_int_cst (TREE_TYPE (non_ass_var), -1);
+ else
+ return false;
*a = fold_build1 (NEGATE_EXPR, TREE_TYPE (non_ass_var), non_ass_var);
}
--- gcc/testsuite/gcc.dg/pr57980.c.mp 2013-08-13 13:41:55.216418468 +0200
+++ gcc/testsuite/gcc.dg/pr57980.c 2013-08-13 13:41:33.116333703 +0200
@@ -0,0 +1,19 @@
+/* PR tree-optimization/57980 */
+/* { dg-do compile } */
+/* { dg-options "-O -foptimize-sibling-calls -w" } */
+
+typedef int V __attribute__ ((vector_size (2 * sizeof (int;
+extern V f (void);
+
+V
+bar (void)
+{
+ return -f ();
+}
+
+V
+foo (void)
+{
+ V v = { };
+ return v - f ();
+}
Marek
Re: [PATCH] Fix PR57980
On Tue, Aug 13, 2013 at 01:51:27PM +0200, Marek Polacek wrote:
> Sure. Ok to apply this one if it passes regtesting?
Yes, thanks.
> 2013-08-13 Marek Polacek
> Jakub Jelinek
>
> PR tree-optimization/57980
> * tree-tailcall.c (process_assignment): Return false
> when not dealing with integers or floats.
>
> * gcc.dg/pr57980.c: New test.
>
> --- gcc/tree-tailcall.c.mp2013-08-13 13:42:33.969568463 +0200
> +++ gcc/tree-tailcall.c 2013-08-13 13:44:57.288121663 +0200
> @@ -328,8 +328,10 @@ process_assignment (gimple stmt, gimple_
> case NEGATE_EXPR:
>if (FLOAT_TYPE_P (TREE_TYPE (op0)))
> *m = build_real (TREE_TYPE (op0), dconstm1);
> - else
> + else if (INTEGRAL_TYPE_P (TREE_TYPE (op0)))
> *m = build_int_cst (TREE_TYPE (op0), -1);
> + else
> +return false;
>
>*ass_var = dest;
>return true;
> @@ -341,8 +343,10 @@ process_assignment (gimple stmt, gimple_
> {
>if (FLOAT_TYPE_P (TREE_TYPE (non_ass_var)))
> *m = build_real (TREE_TYPE (non_ass_var), dconstm1);
> - else
> + else if (INTEGRAL_TYPE_P (TREE_TYPE (non_ass_var)))
> *m = build_int_cst (TREE_TYPE (non_ass_var), -1);
> + else
> + return false;
>
>*a = fold_build1 (NEGATE_EXPR, TREE_TYPE (non_ass_var),
> non_ass_var);
> }
> --- gcc/testsuite/gcc.dg/pr57980.c.mp 2013-08-13 13:41:55.216418468 +0200
> +++ gcc/testsuite/gcc.dg/pr57980.c2013-08-13 13:41:33.116333703 +0200
> @@ -0,0 +1,19 @@
> +/* PR tree-optimization/57980 */
> +/* { dg-do compile } */
> +/* { dg-options "-O -foptimize-sibling-calls -w" } */
> +
> +typedef int V __attribute__ ((vector_size (2 * sizeof (int;
> +extern V f (void);
> +
> +V
> +bar (void)
> +{
> + return -f ();
> +}
> +
> +V
> +foo (void)
> +{
> + V v = { };
> + return v - f ();
> +}
Jakub
Re: [PATCH] Fix PR57980
On Tue, Aug 13, 2013 at 12:27:26PM +0200, Jakub Jelinek wrote:
> Also, for the testcase,
> typedef int V __attribute__ ((vector_size (sizeof (int;
> looks weird, that is one element vector, can you use 2 * sizeof (int)
> instead and add -w to dg-options (for the various -Wpsabi warnings)?
Ok, adjusted with the following; will commit as obvious.
2013-08-13 Marek Polacek
* gcc.dg/pr57980.c: Use vector of two elements, not just one.
--- gcc/testsuite/gcc.dg/pr57980.c.mp 2013-08-13 14:03:22.104617686 +0200
+++ gcc/testsuite/gcc.dg/pr57980.c 2013-08-13 14:04:42.889937026 +0200
@@ -1,8 +1,8 @@
/* PR tree-optimization/57980 */
/* { dg-do compile } */
-/* { dg-options "-O -foptimize-sibling-calls" } */
+/* { dg-options "-O -foptimize-sibling-calls -w" } */
-typedef int V __attribute__ ((vector_size (sizeof (int;
+typedef int V __attribute__ ((vector_size (2 * sizeof (int;
extern V f (void);
V
Marek
[PATCH] Quash undefined behavior in ipa-inline-analysis.c
When doing bootstrap with -fsanitize=undefined, I noticed undefined
behavior in this file. We basically do 1 << 32, since NUM_CONDITIONS
is #defined to 32, which is not defined. I admit I didn't followed
the algorithm at all, but this patch passed bootstrap + regtesting
on x86_64-linux. So, ok for trunk?
2013-08-13 Marek Polacek
* ipa-inline-analysis.c (add_clause): Avoid undefined behavior
when shifting integer.
--- gcc/ipa-inline-analysis.c.mp2013-08-13 14:07:48.632662047 +0200
+++ gcc/ipa-inline-analysis.c 2013-08-13 14:08:16.728770973 +0200
@@ -337,7 +337,7 @@ add_clause (conditions conditions, struc
and thus there is no point for looking for them. */
if (cc1->code == CHANGED || cc1->code == IS_NOT_CONSTANT)
continue;
- for (c2 = c1 + 1; c2 <= NUM_CONDITIONS; c2++)
+ for (c2 = c1 + 1; c2 < NUM_CONDITIONS; c2++)
if (clause & (1 << c2))
{
condition *cc1 =
Marek
Re: [PATCH] [ARM] Fix PR57909 : ICE with internal memcpy and -mno-unaligned-access
Ping. On 23 July 2013 16:18, Yvan Roux wrote: > Hi, > > I forgot to add the test case with the PR fix, the attached patch add it. > > Thanks, > Yvan > > ChangeLog > > gcc/testsuite > > 2013-07-23 Yvan Roux > > PR target/57909 > * gcc.target/arm/pr57909.c: New test. > > > On 17 July 2013 10:58, Ramana Radhakrishnan wrote: >> On 07/17/13 09:53, Yvan Roux wrote: >>> >>> Hi, >>> >>> this patch fixes the issue described in PR57909, where we have an ICE >>> during the internal memcpy, as some UNSPEC_UNALIGNED insns are emitted >>> even if -mno-unaligned-access flag is passed. See the link below for a >>> more detailled description: >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57909 >>> >>> Tested without any regression. >>> >>> Thanks, >>> Yvan >>> >>> ChangeLog >>> >>> gcc/ >>> >>> 2013-07-17 Yvan Roux >>> >>> PR target/57909 >>> * config/arm/arm.c (gen_movmem_ldrd_strd): Fix unaligned >>> load/store >>> usage in HI mode. >>> >> >> Ok. >> >> regards >> Ramana >> >>
Re: [PATCH 1/3] Support lambda templates.
On 08/12/2013 07:52 PM, Adam Butcher wrote: Presumably with pedwarn it would need to be relaxed to simply "accepted with -std=c++1y or -std=gnu++1y" for all? Yes. flag_iso was the only thing I could find to discriminate between gnu++1y and c++1y? Right, we don't make that distinction for most extensions. Jason
Re: Backport from trune:
On Mon, Aug 12, 2013 at 01:01:46PM +0100, Andrew Haley wrote:
> I think this one is obvious/trivial, but I'll ask anyway.
>
> OK?
To 4.8? Sure.
> 2013-08-12 Andrew Haley
>
> Backport from mainline:
> * 2013-07-11 Andreas Schwab
>
> * config/aarch64/aarch64-linux.h (CPP_SPEC): Define.
>
> Index: gcc/config/aarch64/aarch64-linux.h
> ===
> --- gcc/config/aarch64/aarch64-linux.h(revision 201661)
> +++ gcc/config/aarch64/aarch64-linux.h(working copy)
> @@ -23,6 +23,8 @@
>
> #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64.so.1"
>
> +#define CPP_SPEC "%{pthread:-D_REENTRANT}"
> +
> #define LINUX_TARGET_LINK_SPEC "%{h*} \
> %{static:-Bstatic}\
> %{shared:-shared} \
Jakub
RE: [PATCH] Fix for PR c/57490
> -Original Message- > From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de] > Sent: Tuesday, August 13, 2013 7:18 AM > To: Iyer, Balaji V > Cc: Jakub Jelinek; gcc-patches@gcc.gnu.org; Marek Polacek > (pola...@redhat.com) > Subject: Re: [PATCH] Fix for PR c/57490 > > Hi Iyer, > > >First off, my sincerest apologies for letting this bug slip the cracks. > > I am > attaching a patch that seem to work fine with the .i file that you have > submitted > in bugzilla for both C and C++. Please let me know if this fix works for you > and if > it is OK for trunk. > > thanks for the patch. I've just bootstrapped it on i386-pc-solaris2.10 and > all an- > if.c failures are gone. That said, I wonder why we need the separate > pr57490.c > testcase, which is practically a preprocessed version of an-if.c with the > HAVE_IO > code removed. Well, it has assert in it. A while back someone (I think it was Jason Merrill, but I could be wrong) told me to replace all asserts with builtin_abort. But the content inside the file is the same. > > I cannot approve the patch, though. > OK. Can I ask why? Is it because you do not have an authority or is it because you see some errors (e.g. formatting errors) in it? If it is the latter, can you tell me what the errors are so that I can go and fix them? > Rainer > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University
[PATCH] MIPS: IEEE 754-2008 feature testing escape fixes
Hi,
I have realised a double escape is required in scan-assembler patterns
for special characters to match literally. Additionally I've noticed a
couple escapes missing altogether. There are no regressions with the
mips-linux-gnu target and the change below. OK to apply?
2013-08-13 Maciej W. Rozycki
gcc/testsuite/
* gcc.target/mips/fabs-2008.c: Correct scan-assembler pattern
escapes.
* gcc.target/mips/fabs-legacy.c: Likewise.
* gcc.target/mips/fabsf-2008.c: Likewise.
* gcc.target/mips/fabsf-legacy.c: Likewise.
* gcc.target/mips/fneg-2008.c: Likewise.
* gcc.target/mips/fneg-legacy.c: Likewise.
* gcc.target/mips/fnegf-2008.c: Likewise.
* gcc.target/mips/fnegf-legacy.c: Likewise.
* gcc.target/mips/nan-2008.c: Likewise.
* gcc.target/mips/nan-legacy.c: Likewise.
* gcc.target/mips/nanf-2008.c: Likewise.
* gcc.target/mips/nanf-legacy.c: Likewise.
* gcc.target/mips/nans-2008.c: Likewise.
* gcc.target/mips/nans-legacy.c: Likewise.
* gcc.target/mips/nansf-2008.c: Likewise.
* gcc.target/mips/nansf-legacy.c: Likewise.
Maciej
gcc-mips-nan2008-test-escape-fix.diff
Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fabs-2008.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/fabs-2008.c
2013-07-26 19:20:34.0 +0100
+++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fabs-2008.c
2013-08-13 01:02:55.858786822 +0100
@@ -7,4 +7,4 @@ fabs_2008 (double d)
return __builtin_fabs (d);
}
-/* { dg-final { scan-assembler "\tabs\.d\t" } } */
+/* { dg-final { scan-assembler "\tabs\\.d\t" } } */
Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fabs-legacy.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/fabs-legacy.c
2013-07-26 19:20:34.0 +0100
+++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fabs-legacy.c
2013-08-13 01:03:08.368735336 +0100
@@ -7,4 +7,4 @@ fabs_legacy (double d)
return __builtin_fabs (d);
}
-/* { dg-final { scan-assembler-not "\tabs\.d\t" } } */
+/* { dg-final { scan-assembler-not "\tabs\\.d\t" } } */
Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fabsf-2008.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/fabsf-2008.c
2013-07-26 19:20:34.0 +0100
+++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fabsf-2008.c
2013-08-13 01:03:12.867997081 +0100
@@ -7,4 +7,4 @@ fabsf_2008 (float f)
return __builtin_fabsf (f);
}
-/* { dg-final { scan-assembler "\tabs\.s\t" } } */
+/* { dg-final { scan-assembler "\tabs\\.s\t" } } */
Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fabsf-legacy.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/fabsf-legacy.c
2013-07-26 19:20:34.0 +0100
+++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fabsf-legacy.c
2013-08-13 01:03:17.368766249 +0100
@@ -7,4 +7,4 @@ fabsf_legacy (float f)
return __builtin_fabsf (f);
}
-/* { dg-final { scan-assembler-not "\tabs\.s\t" } } */
+/* { dg-final { scan-assembler-not "\tabs\\.s\t" } } */
Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fneg-2008.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/fneg-2008.c
2013-07-26 19:20:34.0 +0100
+++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fneg-2008.c
2013-08-13 01:03:22.868115474 +0100
@@ -7,4 +7,4 @@ fneg_2008 (double d)
return -d;
}
-/* { dg-final { scan-assembler "\tneg\.d\t" } } */
+/* { dg-final { scan-assembler "\tneg\\.d\t" } } */
Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fneg-legacy.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/fneg-legacy.c
2013-07-26 19:20:34.0 +0100
+++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fneg-legacy.c
2013-08-13 01:03:30.868753578 +0100
@@ -7,4 +7,4 @@ fneg_legacy (double d)
return -d;
}
-/* { dg-final { scan-assembler-not "\tneg\.d\t" } } */
+/* { dg-final { scan-assembler-not "\tneg\\.d\t" } } */
Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fnegf-2008.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/fnegf-2008.c
2013-07-26 19:20:34.0 +0100
+++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/fnegf-2008.c
2013-08-13 01:03:37.368749309 +0100
@@ -7,4 +7,4 @@ fnegf_2008 (float f)
return -f;
}
-/* { dg-final { scan-assembler "\tneg\.s\t" } } */
+/* { dg-final { scan-assembler "\tneg\\.s\t" } } */
Index: gcc-fsf-trunk-quilt/gc
Re: MIPS tests (nan-legacy.c and nans-legacy.c) failing
On Wed, 7 Aug 2013, Richard Sandiford wrote:
> > When I run two of your new tests in gcc.target/mips (nan-legacy.c and
> > nans-legacy.c), they are failing because my GCC is putting out
> >
> > .word 4294967295
> >
> > instead of
> >
> > .word -1
> >
> > like the test is expecting.
> >
> > I believe they are equivalent (0x) but I am not sure what it
> > is about my targets (mips-mti-elf and mips-mti-linux-gnu) that would
> > make this different from yours. Should the tests be modified to allow
> > either output?
>
> Maciej, have you had chance to look at this yet?
I've had a look now and that is related to the width of `long' on the
host -- encode_ieee_double returns its output 32-bit bit patterns in a
buffer of signed longs. The arithmetic value of these patterns therefore
depends on whether the width of `long' is 32 bits or wider.
Here, in the case of nan-legacy.c, we have:
image_hi <- 0x7ff7
image_lo <- 0x
so the returned pair of long values will be:
2146959359, -1
on a host where the width of `long' is 32 bits and:
2146959359, 4294967295
on a host where the width of `long' is 64 bits. Then when supplied as the
argument to the assembly-language .word pseudo-op, the two sets of values
produce the same bit patterns in the object file produced.
It's not clear to me if this dependency on the width of `long' is a bug
or feature, but a path-of-least-resistance fix is as follows.
This has passed mips-linux-gnu regression testing on a 32-bit host, but I
can't regression-test a 64-bit host easily -- Steve, can you please verify
that this change indeed works for you? Richard, OK to apply assuming that
it does?
2013-08-13 Maciej W. Rozycki
gcc/testsuite/
* gcc.target/mips/nan-legacy.c: Accept 4294967295 as an
alternative to -1.
* gcc.target/mips/nans-legacy.c: Likewise.
Maciej
gcc-mips-nan2008-test-fix.diff
Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/nan-legacy.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/nan-legacy.c
2013-08-13 14:18:50.008738612 +0100
+++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/nan-legacy.c
2013-08-13 14:22:49.568772451 +0100
@@ -4,4 +4,4 @@
double d = __builtin_nan ("");
/* { dg-final { scan-assembler "\t\\.nan\tlegacy\n" } } */
-/* { dg-final { scan-assembler "\t\\.word\t2146959359\n\t\\.word\t-1\n" } } */
+/* { dg-final { scan-assembler
"\t\\.word\t2146959359\n\t\\.word\t(?:-1|4294967295)\n" } } */
Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/nans-legacy.c
===
--- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/nans-legacy.c
2013-08-13 14:18:50.008738612 +0100
+++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/nans-legacy.c
2013-08-13 14:22:49.568772451 +0100
@@ -4,4 +4,4 @@
double ds = __builtin_nans ("");
/* { dg-final { scan-assembler "\t\\.nan\tlegacy\n" } } */
-/* { dg-final { scan-assembler "\t\\.word\t2147483647\n\t\\.word\t-1\n" } } */
+/* { dg-final { scan-assembler
"\t\\.word\t2147483647\n\t\\.word\t(?:-1|4294967295)\n" } } */
Re: [PATCH] Fix for PR c/57490
Hi Iyer, >> thanks for the patch. I've just bootstrapped it on i386-pc-solaris2.10 >> and all an- >> if.c failures are gone. That said, I wonder why we need the separate >> pr57490.c >> testcase, which is practically a preprocessed version of an-if.c with the >> HAVE_IO >> code removed. > > Well, it has assert in it. A while back someone (I think it was Jason > Merrill, but I could be wrong) told me to replace all asserts with > builtin_abort. But the content inside the file is the same. in that case I'd suggest modifying an-if.c accordingly and not adding pr57490.c. >> I cannot approve the patch, though. > > OK. Can I ask why? Is it because you do not have an authority or is it > because you see some errors (e.g. formatting errors) in it? If it is the > latter, can you tell me what the errors are so that I can go and fix them? It's simply not my area of authority. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
RE: [PATCH] Fix for PR c/57490
> -Original Message- > From: Rainer Orth [mailto:r...@cebitec.uni-bielefeld.de] > Sent: Tuesday, August 13, 2013 9:38 AM > To: Iyer, Balaji V > Cc: Jakub Jelinek; gcc-patches@gcc.gnu.org; Marek Polacek > (pola...@redhat.com) > Subject: Re: [PATCH] Fix for PR c/57490 > > Hi Iyer, > > >> thanks for the patch. I've just bootstrapped it on > >> i386-pc-solaris2.10 and all an- if.c failures are gone. That said, I > >> wonder why we need the separate pr57490.c testcase, which is > >> practically a preprocessed version of an-if.c with the HAVE_IO code > >> removed. > > > > Well, it has assert in it. A while back someone (I think it was Jason > > Merrill, but I could be wrong) told me to replace all asserts with > > builtin_abort. But the content inside the file is the same. > > in that case I'd suggest modifying an-if.c accordingly and not adding > pr57490.c. > Well, on x86, an-if.c works fine without this modifications. It is just that in sparc the code is broken up a bit differently. > >> I cannot approve the patch, though. > > > > OK. Can I ask why? Is it because you do not have an authority or is it > > because you see some errors (e.g. formatting errors) in it? If it is > > the latter, can you tell me what the errors are so that I can go and fix > > them? > > It's simply not my area of authority. > Ok. Thanks for looking into this quickly though. Sincerely, Balaji V. Iyer. > Rainer > > -- > - > Rainer Orth, Center for Biotechnology, Bielefeld University
[RFC] MULTILIB_COMPATIBLE option support in multilib
Hi, I'm trying to have a possibility to dynamically choose between compatible multilibs (see thread http://gcc.gnu.org/ml/gcc/2013-08/msg00114.html) if preferred one is missing. It would allow me to configure MPX binaries to link with MPX library if such library exists and use non-MPX library version if MPX version is missing. I introduced a new flag MULTILIB_COMPATIBLE which has format similar to MULTILIB_REUSE. For MULTILIB_REUSE dir prefixes are replaced with reused ones. For MULTILIB_COMPATIBLE compatible dir prefixes are used in addition to existing. With this patch applied on MPX enabled GCC and following additional declarations I was able to build GCC with four library variants: 32 64 32/mpx 64/mpx. Compatible non-MPX files were used to build MPX version of libraries (e.g. /usr/lib64/crti.o was used for 64/mpx). MULTILIB_EXTRA_OPTS = mmpx MULTILIB_OSDIRNAMES+= m64/fmpx=../lib64/mpx$(call if_multiarch,:x86_64-linux-gnu/mpx) MULTILIB_COMPATIBLE = m64=m64/fmpx MULTILIB_OSDIRNAMES+= m32/fmpx=$(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32/mpx,../lib/mpx)$(call if_multiarch,:i386-linux-gnu/mpx) MULTILIB_COMPATIBLE+= m32=m32/fmpx Any comments on the used approach? Thanks, Ilya --- 2013-08-13 Ilya Enkovich * Makefile.in: Add new arg MULTILIB_COMPATIBLE to genmultilib call. * gcc.c (multilib_compatible): New. (multilib_dir): Change to array of strings. (multilib_os_dir): Likewise. (multiarch_dir): Likewise. (multilib_dir_cnt): New. (static_specs): Add multilib_compatible. (for_each_path_1): New. (for_each_path): Now use helper function for_each_path_1 and iterate through all multidirs. (do_spec_1): Fix-up multilib_* vars usage. (main): Initialize multilib_compatible. Fix-up multilib_* vars usage. (set_multilib_dir): Parse multilib_compatible. * genmultilib: Support new argument MULTILIB_COMPATIBLE. multilib.patch Description: Binary data
Re: [wwwdocs] Add link to @gnutools on Twitter
On Mon, Aug 12, 2013 at 8:49 PM, Gerald Pfeifer wrote: >> Does this also deserve a news post? I certainly found it to be >> interesting news! > > Sure. Want to add one, David? I am adding the following to News: diff -c -p -r1.888 index.html *** index.html 12 Aug 2013 00:01:45 - 1.888 --- index.html 13 Aug 2013 14:16:37 - *** mission statement. *** 53,58 --- 53,65 + Twitter and Google+ accounts + [2013-08-08] + GCC and the GNU Toolchain Project now have accounts on + https://twitter.com/gnutools";>Twitter and + https://plus.google.com/108467477471815191158"; rel="publisher">Google+ + to help developers stay informed of progress. + GCC 4.8.1 released [2013-05-31] Thanks, David
Re: [PATCH] MIPS/libgcc: Avoid the PLT in MIPS16 stub calls
On Wed, 7 Aug 2013, Richard Sandiford wrote:
> > BTW, what's the "Check for MicroMIPS support." note seen in the
> > config.host piece of the patch referring to?
>
> No idea, please remove it.
I have committed the change below.
2013-08-13 Maciej W. Rozycki
libgcc/
* config.host : Remove a stray comment.
Maciej
gcc-mips-libgcc-config-stray.patch
Index: libgcc/config.host
===
--- libgcc/config.host (revision 201347)
+++ libgcc/config.host (working copy)
@@ -740,7 +740,6 @@ mips*-*-netbsd*)# NetBSD/mips, either
mips*-*-linux*)# Linux MIPS, either endian.
extra_parts="$extra_parts crtfastmath.o"
tmake_file="${tmake_file} t-crtfm"
- # Check for MicroMIPS support.
case ${host} in
mips64r5900* | mipsr5900*)
# The MIPS16 support code uses floating point
RE: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb
> > On 08/09/13 11:01, Julian Brown wrote: > > On Thu, 8 Aug 2013 15:44:17 +0100 > > Kyrylo Tkachov wrote: > > > >> Hi all, > >> > >> The recently added gcc.target/arm/pr58041.c test exposed a bug in the > >> backend. When compiling for NEON and with -mno-unaligned-access we > >> end up generating the vld1.64 and vst1.64 instructions instead of > >> doing the accesses one byte at a time like -mno-unaligned-access > >> expects. This patch fixes that by enabling the NEON expander and > >> insns that produce these instructions only when unaligned accesses > >> are allowed. > >> > >> Bootstrapped on arm-linux-gnueabihf. Tested arm-none-eabi on qemu. > >> > >> Ok for trunk and 4.8? > > > > I'm not sure if this is right, FWIW -- do the instructions in question > > trap if the CPU is set to disallow unaligned accesses? I thought that > > control bit only affected ARM core loads & stores, not NEON ones. > > Thinking again - the ARM-ARM says - the alignment check is for element > size, so an alternative might be to use vld1.8 instead to allow for this > at which point we might as well do something else with the test. I note > that these patterns are not allowed for BYTES_BIG_ENDIAN so that might > be a better alternative than completely disabling it. Looking at the section on unaligned accesses, it seems that the ldrb/strb-class instructions are the only ones that are unaffected by the SCTLR.A bit and do not produce alignment faults in any case. The NEON load/store instructions, including vld1.8 can still cause an alignment fault when SCTLR.A is set. So it seems we can only use the byte-wise core memory instructions for unaligned data. Therefore it seems this approach is not overly conservative. What do other people think? Kyrill > > regards > Ramana > > > > HTH, > > > > Julian > >
Re: [PATCH] Fix ICE with MEM_REF clobbers with anonymous SSA_NAME (PR tree-optimization/57661)
Jakub Jelinek wrote:
>Hi!
>
>On the following testcase we ICE because we have an indirect (MEM_REF)
>clobber stmt that uses anonymous SSA_NAME. ipa-split.c (intentionally)
>ignores clobber stmts because they don't result in executable code,
>but that can lead into clobber stmts mentioning SSA_NAMEs that aren't
>initialized. For non-anonymous SSA_NAMEs that is not an issue, we just
>drop
>those during tree-ssa-live.c later on (clobber stmts are always
>optional
>and furthermore in ipa-split case the clobber stmts are duplicated both
>in the (to be inlined) caller and callee), but for anonymous SSA_NAMEs
>there is no such thing as (D) and thus we ICE.
>
>Fixed by removing those clobber stmts already during function
>versioning
>during ipa-split.c.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
Ok.
Thanks,
Richard.
>2013-08-13 Jakub Jelinek
>
> PR tree-optimization/57661
> * tree-inline.h (struct copy_body_data): Add blocks_to_copy field.
> * tree-inline.c (tree_function_versioning): Initialize it.
> (remap_gimple_stmt): Return GIMPLE_NOP for MEM_REF lhs clobber stmts
> if id->blocks_to_copy and MEM_REF's SSA_NAME is defined in a block
> that is not being copied.
>
> * g++.dg/opt/pr57661.C: New test.
>
>--- gcc/tree-inline.h.jj 2013-06-03 18:11:57.0 +0200
>+++ gcc/tree-inline.h 2013-07-23 00:38:14.362153447 +0200
>@@ -115,6 +115,10 @@ typedef struct copy_body_data
> /* Entry basic block to currently copied body. */
> basic_block entry_bb;
>
>+ /* For partial function versioning, bitmap of bbs to be copied,
>+ otherwise NULL. */
>+ bitmap blocks_to_copy;
>+
> /* Debug statements that need processing. */
> vec debug_stmts;
>
>--- gcc/tree-inline.c.jj 2013-07-06 09:24:10.0 +0200
>+++ gcc/tree-inline.c 2013-07-23 01:30:39.575893735 +0200
>@@ -1387,6 +1387,23 @@ remap_gimple_stmt (gimple stmt, copy_bod
> }
> }
>
>+ /* For *ptr_N ={v} {CLOBBER}, if ptr_N is SSA_NAME defined
>+ in a block that we aren't copying during tree_function_versioning,
>+ just drop the clobber stmt. */
>+ if (id->blocks_to_copy && gimple_clobber_p (stmt))
>+ {
>+tree lhs = gimple_assign_lhs (stmt);
>+if (TREE_CODE (lhs) == MEM_REF
>+&& TREE_CODE (TREE_OPERAND (lhs, 0)) == SSA_NAME)
>+ {
>+gimple def_stmt = SSA_NAME_DEF_STMT (TREE_OPERAND (lhs, 0));
>+if (gimple_bb (def_stmt)
>+&& !bitmap_bit_p (id->blocks_to_copy,
>+ gimple_bb (def_stmt)->index))
>+ return gimple_build_nop ();
>+ }
>+ }
>+
> if (gimple_debug_bind_p (stmt))
> {
> copy = gimple_build_debug_bind (gimple_debug_bind_get_var (stmt),
>@@ -5091,6 +5108,7 @@ tree_function_versioning (tree old_decl,
> id.src_node = old_version_node;
> id.dst_node = new_version_node;
> id.src_cfun = DECL_STRUCT_FUNCTION (old_decl);
>+ id.blocks_to_copy = blocks_to_copy;
> if (id.src_node->ipa_transforms_to_apply.exists ())
> {
> vec old_transforms_to_apply
>--- gcc/testsuite/g++.dg/opt/pr57661.C.jj 2013-07-23 01:42:45.078284916
>+0200
>+++ gcc/testsuite/g++.dg/opt/pr57661.C 2013-07-23 01:41:41.0
>+0200
>@@ -0,0 +1,76 @@
>+// PR tree-optimization/57661
>+// { dg-do compile }
>+// { dg-options "-O2 -fno-tree-forwprop -std=gnu++11" }
>+
>+template
>+struct A
>+{
>+ ~A () {}
>+};
>+template
>+using B = A <_Tp>;
>+template
>+class C : B <_Tp> {};
>+namespace N { enum D { d }; }
>+template
>+struct E
>+{
>+ ~E ();
>+};
>+template
>+struct F : V {};
>+template
>+struct G : F
>+{
>+ N::D g1;
>+ void g2 ();
>+ void g3 ();
>+ void g4 () { g3 (); }
>+ static void g5 (G *__t) { __t->g4 (); }
>+};
>+template
>+struct H : G
>+{
>+ E *h1;
>+ bool h2;
>+ ~H () throw ()
>+ {
>+this->g2 ();
>+if (h2)
>+ delete h1;
>+ }
>+};
>+template
>+struct I : H , E
>+{
>+ G *i;
>+ ~I () throw ()
>+ {
>+i->g4 ();
>+ }
>+};
>+struct J
>+{
>+ typedef C j1;
>+ typedef G > j2;
>+ J ();
>+ j2 *j3;
>+};
>+struct K : J
>+{
>+ typedef G > j2;
>+ K () { j2::g5 (this->j3); }
>+};
>+template
>+void G ::g3 ()
>+{
>+ switch (g1)
>+{
>+case N::d:
>+ {
>+ I *q = (I *) this;
>+ q->I ::~I ();
>+ }
>+}
>+}
>+K r;
>
> Jakub
Re: [PATCH][ARM] FAIL: gcc.target/arm/pr58041.c scan-assembler ldrb
On 08/13/13 15:57, Kyrylo Tkachov wrote: On 08/09/13 11:01, Julian Brown wrote: On Thu, 8 Aug 2013 15:44:17 +0100 Kyrylo Tkachov wrote: Hi all, The recently added gcc.target/arm/pr58041.c test exposed a bug in the backend. When compiling for NEON and with -mno-unaligned-access we end up generating the vld1.64 and vst1.64 instructions instead of doing the accesses one byte at a time like -mno-unaligned-access expects. This patch fixes that by enabling the NEON expander and insns that produce these instructions only when unaligned accesses are allowed. Bootstrapped on arm-linux-gnueabihf. Tested arm-none-eabi on qemu. Ok for trunk and 4.8? I'm not sure if this is right, FWIW -- do the instructions in question trap if the CPU is set to disallow unaligned accesses? I thought that control bit only affected ARM core loads & stores, not NEON ones. Thinking again - the ARM-ARM says - the alignment check is for element size, so an alternative might be to use vld1.8 instead to allow for this at which point we might as well do something else with the test. I note that these patterns are not allowed for BYTES_BIG_ENDIAN so that might be a better alternative than completely disabling it. Looking at the section on unaligned accesses, it seems that the ldrb/strb-class instructions are the only ones that are unaffected by the SCTLR.A bit and do not produce alignment faults in any case. The NEON load/store instructions, including vld1.8 can still cause an alignment fault when SCTLR.A is set. So it seems we can only use the byte-wise core memory instructions for unaligned data. Yes, you are right. Sorry I misremembered / misread that very table :(. I don't think this is overly conservative then. sorry about the noise, Ramana Therefore it seems this approach is not overly conservative. What do other people think? Kyrill regards Ramana HTH, Julian
[Ada] Fix wrong number of iterations for specific loop
This is a regression present on all the active branches. The compiler
generates code that doesn't execute the expected number of iterations for a
loop with a dynamic upper bound whose value is exactly the upper bound of the
base index type and is obtained through a narrowing conversion.
Tested on x86_64-suse-linux, applied on all the active branches.
2013-08-13 Eric Botcazou
* gcc-interface/trans.c (can_equal_min_or_max_val_p): Be prepared for
values outside of the range of the type.
2013-08-13 Eric Botcazou
* gnat.dg/loop_optimization16.adb: New test.
* gnat.dg/loop_optimization16_pkg.ad[sb]: New helper.
--
Eric Botcazou
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 201622)
+++ gcc-interface/trans.c (working copy)
@@ -2391,7 +2391,10 @@ can_equal_min_or_max_val_p (tree val, tr
if (TREE_CODE (val) != INTEGER_CST)
return true;
- return tree_int_cst_equal (val, min_or_max_val) == 1;
+ if (max)
+return tree_int_cst_lt (val, min_or_max_val) == 0;
+ else
+return tree_int_cst_lt (min_or_max_val, val) == 0;
}
/* Return true if VAL (of type TYPE) can equal the minimum value of TYPE.
-- { dg-do run }
with Loop_Optimization16_Pkg; use Loop_Optimization16_Pkg;
procedure Loop_Optimization16 is
Counter : Natural := 0;
C : constant Natural := F;
subtype Index_T is Index_Base range 1 .. Index_Base (C);
begin
for I in Index_T'First .. Index_T'Last loop
Counter := Counter + 1;
exit when Counter > 200;
end loop;
if Counter > 200 then
raise Program_Error;
end if;
end Loop_Optimization16;
package body Loop_Optimization16_Pkg is
function F return Natural is
begin
return Natural (Index_Base'Last);
end;
end Loop_Optimization16_Pkg;
package Loop_Optimization16_Pkg is
type Index_Base is range 0 .. 127;
function F return Natural;
end Loop_Optimization16_Pkg;
Re: [PATCH] Fix the bug to check if lookup_stmt_eh_lp returns positive instead of non-zero
ping ^3
Thanks,
Dehao
On Fri, Jul 26, 2013 at 6:15 PM, Dehao Chen wrote:
> ping^2
>
> Thanks,
> Dehao
>
> On Tue, Jul 16, 2013 at 5:40 PM, Dehao Chen wrote:
>> ping...
>>
>> Thanks,
>> Dehao
>>
>> On Mon, Jul 8, 2013 at 5:55 PM, Dehao Chen wrote:
>>> In lookup_stmt_eh_lp, negative return value indicates a MUST_NOT_THROW
>>> region index. In this case, we should *not* add an EH edge during VPT.
>>>
>>> Bootstrapped and passed regression test.
>>>
>>> OK for trunk?
>>>
>>> Thanks,
>>> Dehao
>>>
>>> gcc/ChangeLog:
>>>
>>> 2013-07-08 Dehao Chen (de...@google.com)
>>>
>>> * value-prof.c (gimple_ic): Fix the bug of adding EH edge.
>>>
>>> Index: gcc/value-prof.c
>>> ===
>>> --- gcc/value-prof.c (revision 200375)
>>> +++ gcc/value-prof.c (working copy)
>>> @@ -1359,8 +1359,7 @@ gimple_ic (gimple icall_stmt, struct cgraph_node *
>>>
>>>/* Build an EH edge for the direct call if necessary. */
>>>lp_nr = lookup_stmt_eh_lp (icall_stmt);
>>> - if (lp_nr != 0
>>> - && stmt_could_throw_p (dcall_stmt))
>>> + if (lp_nr > 0 && stmt_could_throw_p (dcall_stmt))
>>> {
>>>edge e_eh, e;
>>>edge_iterator ei;
Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv
On Mon, Aug 12, 2013 at 10:07 AM, Caroline Tice wrote:
> On Mon, Aug 12, 2013 at 4:15 AM, Florian Weimer wrote:
>> On 08/12/2013 12:39 AM, Caroline Tice wrote:
>>>
>>> On Sun, Aug 11, 2013 at 1:04 PM, Florian Weimer
>>> wrote:
On 08/11/2013 01:08 AM, Caroline Tice wrote:
>
>
> OK, I have removed the attempt to use $HOME for the logs; they will
> now either go into the directory specified by the environment variable
> VTV_LOGS_DIR, or they will go into the current directory. I also
> added code to use secure_getenv, rather than getenv, if it is
> available. Is this patch ok to commit?
+ logs_prefix = secure_getenv ("VTV_LOGS_DIR");
+ if (!logs_prefix || strlen (logs_prefix) == 0)
+logs_prefix = (char *) ".";
Hmm. If you fall back to the current directory, using secure_getenv
doesn't
have the intended security effect. I wonder if we can simply label this
functionality as unsafe for SUID/SGID programs, like we (hopefully) do
for
profiling.
>>>
>>> I am unclear how to do this? Could you elaborate please?
>>
>>
>> I think it boils whether vtv is a debugging feature (like mudflap or
>> profiling), or supposed to be active in production code (like the stack
>> protector). If the latter, we have to go to greater lengths in restricting
>> the logging feature when running SUID/SGID.
>>
>
> The feature is supposed to be active in production code (like the
> stack protector).
SO...I am completely unfamiliar with the "greater lengths in
restricting the logging feature when running SUID/SGID", so I have no
idea what I am supposed to do here. Could you either please elaborate
further, or point me to an example or some documentation? Thank you!
-- Caroline Tice
cmt...@google.com
>
>> Looks like we lost the Cc: to gcc-patches. Not sure if this is intentional.
>> Feel free to add it again.
>
> Done.
>
> -- Caroline Tice
> cmt...@google.com
>
>>
>>
>> --
>> Florian Weimer / Red Hat Product Security Team
backported patch for PR57459 into gcc-4_8-branch
The following patch has been backported into gcc-4_8-branch.
The patch was successfully tested and bootstrapped on x86/x86-64.
Committed as rev. 201695.
2013-08-13 Vladimir Makarov
Backport from mainline
2013-06-06 Vladimir Makarov
PR rtl-optimization/57459
* lra-constraints.c (update_ebb_live_info): Fix typo for operand
type when setting live regs.
2013-08-13 Vladimir Makarov
Backport from mainline
2013-06-06 Vladimir Makarov
PR rtl-optimization/57459
* gcc.target/i386/pr57459.c: New test.
Index: gcc/lra-constraints.c
===
--- gcc/lra-constraints.c (revision 201689)
+++ gcc/lra-constraints.c (working copy)
@@ -4396,7 +4396,7 @@ update_ebb_live_info (rtx head, rtx tail
bitmap_clear_bit (&live_regs, reg->regno);
/* Mark each used value as live. */
for (reg = curr_id->regs; reg != NULL; reg = reg->next)
- if (reg->type == OP_IN
+ if (reg->type != OP_OUT
&& bitmap_bit_p (&check_only_regs, reg->regno))
bitmap_set_bit (&live_regs, reg->regno);
/* It is quite important to remove dead move insns because it
Index: gcc/testsuite/gcc.target/i386/pr57459.c
===
--- gcc/testsuite/gcc.target/i386/pr57459.c (revision 0)
+++ gcc/testsuite/gcc.target/i386/pr57459.c (working copy)
@@ -0,0 +1,60 @@
+/* PR rtl-optimization/57459 */
+/* { dg-do run } */
+/* { dg-options "-fno-inline -O2 -minline-all-stringops
-fno-omit-frame-pointer" } */
+
+int total1[10], total2[10], total3[10], total4[10], total5[10], a[20];
+int len;
+
+void stackclean() {
+ void *ptr = __builtin_alloca(2);
+ __builtin_memset(ptr, 0, 2);
+}
+
+void foo(const char *s) {
+ int r1 = a[1];
+ int r2 = a[2];
+ int r3 = a[3];
+ int r4 = a[4];
+ int r5 = a[5];
+
+ len = __builtin_strlen(s);
+
+ if (s != 0)
+return;
+
+ while (r1) {
+ total1[r1] = r1;
+ r1--;
+ }
+
+ while (r2) {
+ total2[r2] = r2;
+ r2--;
+ }
+
+ while (r3) {
+ total3[r3] = r3;
+ r3--;
+ }
+
+ while (r4) {
+ total4[r4] = r4;
+ r4--;
+ }
+
+ while (r5) {
+ total5[r5] = r5;
+ r5--;
+ }
+}
+
+extern void abort (void);
+
+int main() {
+ stackclean();
+ foo("abcdefgh");
+ if (len != 8)
+abort ();
+ return 0;
+}
+
Vtable verification - configure & enable flags
Starting a new thread, based on the discussion from [PATCH/Merge Request] Vtable Verification feature I would like to start a new thread to discuss some of the issues here (see snip from old thread below). On Thu, Aug 8, 2013 at 4:01 PM, Joseph S. Myers wrote: > On Thu, 8 Aug 2013, Caroline Tice wrote: > >> Actually if you ever want to use the feature with your compiler you >> should build your compiler with --enable-vtable-verify. This will, as >> you noted, insert calls in libstdc++ to build the verification data >> structures and to verify the virtual calls in libstdc++ itself. >> However libstdc++ itself contains 'stub' (do-nothing) versions of the >> functions that build the data structures and perform the verification. >> So if you want to turn on verification with libstdc++, you link it >> with libvtv (which contains the "real" versions of those functions) >> and if you don't want verification with libstdc++ you just don't link >> in libvtv. There is no need to multiple versions of libstdc++. > > But presumably libstdc++ with the extra calls is less efficient than > libstdc++ without them, even if the calls are just to stub functions? > > A GNU/Linux distributor would likely want to enable their users to use > this functionality, meaning distributing a GCC build with libvtv included > and a version of libstdc++ with the calls present for users who wish to > build programs (linking with libstdc++ and libvtv) for which the calls in > libstdc++ are checked. But they might not want to have even the stub > calls executed for all installed C++ programs. So it would seem natural > to provide both copies of libstdc++ - and desirable for this to be > possible without needing separate GCC builds. > >> I supposed the libgcc files could be built all the time (on systems >> that support libvtv). Would there be any down side to this? > > In my model, it's appropriate to build those independent of the libstdc++ > configure option - and likewise to build everything in libvtv independent > of the configure option. There should be no need for the configure option > to affect anything other than, at most, libstdc++ - that is, the handling > of the option in other configure scripts should be removed, with the case > where the relevant support is built being enabled by default. > > -- > Joseph S. Myers > jos...@codesourcery.com Currently the there are two relevant flags, --enable-libvtv (--disable-libvtv) and --enable-vtable-verify (--disable-vtable-verify). --enable-libvtv is the default. This will cause libvtv.so to be built, as long as the underlying system is one that supports VTV (currently only linux systems). --enable-vtable-verify controls whether or not the vtv_* files get built, in libgcc, and also whether or not libstdc++ is built with calls to the vtv functions embedded or not. We can remove references to --enable-vtable-verify from libvtv, but it still needs to be there (or something similiar) in libgcc, because the vtv_* files in libgcc contain system-specific references (section names) that are not valid on all systems. And --enable-vtable-verify is necessary in libstdc++, because you definitely want to be able to control whether or not libstdc++ is built with its virtual calls verifiable. What do other people believe is the right thing to do here? -- Caroline Tice cmt...@google.com
Re: MIPS tests (nan-legacy.c and nans-legacy.c) failing
On Tue, 2013-08-13 at 14:28 +0100, Maciej W. Rozycki wrote: > This has passed mips-linux-gnu regression testing on a 32-bit host, but I > can't regression-test a 64-bit host easily -- Steve, can you please verify > that this change indeed works for you? Richard, OK to apply assuming that > it does? Maciej, the patch does work for me. Steve Ellcey sell...@mips.com
Re: [PATCH] MIPS: IEEE 754-2008 feature testing escape fixes
"Maciej W. Rozycki" writes: > 2013-08-13 Maciej W. Rozycki > > gcc/testsuite/ > * gcc.target/mips/fabs-2008.c: Correct scan-assembler pattern > escapes. > * gcc.target/mips/fabs-legacy.c: Likewise. > * gcc.target/mips/fabsf-2008.c: Likewise. > * gcc.target/mips/fabsf-legacy.c: Likewise. > * gcc.target/mips/fneg-2008.c: Likewise. > * gcc.target/mips/fneg-legacy.c: Likewise. > * gcc.target/mips/fnegf-2008.c: Likewise. > * gcc.target/mips/fnegf-legacy.c: Likewise. > * gcc.target/mips/nan-2008.c: Likewise. > * gcc.target/mips/nan-legacy.c: Likewise. > * gcc.target/mips/nanf-2008.c: Likewise. > * gcc.target/mips/nanf-legacy.c: Likewise. > * gcc.target/mips/nans-2008.c: Likewise. > * gcc.target/mips/nans-legacy.c: Likewise. > * gcc.target/mips/nansf-2008.c: Likewise. > * gcc.target/mips/nansf-legacy.c: Likewise. OK, thanks. Richard
Re: MIPS tests (nan-legacy.c and nans-legacy.c) failing
"Maciej W. Rozycki" writes: > I've had a look now and that is related to the width of `long' on the > host -- encode_ieee_double returns its output 32-bit bit patterns in a > buffer of signed longs. The arithmetic value of these patterns therefore > depends on whether the width of `long' is 32 bits or wider. > > Here, in the case of nan-legacy.c, we have: > > image_hi <- 0x7ff7 > image_lo <- 0x > > so the returned pair of long values will be: > > 2146959359, -1 > > on a host where the width of `long' is 32 bits and: > > 2146959359, 4294967295 > > on a host where the width of `long' is 64 bits. Then when supplied as the > argument to the assembly-language .word pseudo-op, the two sets of values > produce the same bit patterns in the object file produced. > > It's not clear to me if this dependency on the width of `long' is a bug > or feature, but a path-of-least-resistance fix is as follows. IMO a bug. If we're sure 32 bits is enough then we should use "int". If we're not sure we should use HOST_WIDE_INT. The only thing using "long" is going to do is create this kind of weird host dependence. I can't argue with the path of least resistance though. > 2013-08-13 Maciej W. Rozycki > > gcc/testsuite/ > * gcc.target/mips/nan-legacy.c: Accept 4294967295 as an > alternative to -1. > * gcc.target/mips/nans-legacy.c: Likewise. OK, thanks. Richard
Re: [PATCH] S/390: Hardware transactional memory support
On Fri, Aug 02, 2013 at 11:05:33AM -1000, Richard Henderson wrote:
> On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
> > ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
>
> Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
> floating point registers; similarly for the write accessors.
So, would it be enough to compile just beginend.cc with -msoft-float
and the rest normally?
Or what routines in particular must be prevented from using float registers
implicitly?
Jakub
patch to fix a typo in ira.c
Xingxing Pan found a typo in IRA code. Here is the patch to fix it.
The patch was bootstrapped on x86/x86-64. I did not find code
generation difference on x86/x86-64, s390, ppc, and arm on variety
tests. The code might make some small difference on other targets though.
Committed as rev. 201699.
2013-08-13 Vladimir Makarov
* ira.c (setup_class_translate_array): Use aclass instead of cl
for classes not fully covered by allocno classes.
Index: ira.c
===
--- ira.c (revision 201544)
+++ ira.c (working copy)
@@ -,8 +,8 @@ setup_class_translate_array (enum reg_cl
min_cost = INT_MAX;
for (mode = 0; mode < MAX_MACHINE_MODE; mode++)
{
- cost = (ira_memory_move_cost[mode][cl][0]
- + ira_memory_move_cost[mode][cl][1]);
+ cost = (ira_memory_move_cost[mode][aclass][0]
+ + ira_memory_move_cost[mode][aclass][1]);
if (min_cost > cost)
min_cost = cost;
}
Re: [PATCH] S/390: Hardware transactional memory support
On 08/13/2013 11:26 AM, Jakub Jelinek wrote:
> On Fri, Aug 02, 2013 at 11:05:33AM -1000, Richard Henderson wrote:
>> On 08/02/2013 04:45 AM, Andreas Krebbel wrote:
>>> ! XCFLAGS="${XCFLAGS} -mzarch -mhtm -msoft-float"
>>
>> Not good, since _ITM_R{F,D,E,CF,CD,CE} should return values in
>> floating point registers; similarly for the write accessors.
>
> So, would it be enough to compile just beginend.cc with -msoft-float
> and the rest normally?
No.
>From what I understand of the s390 restriction, we can't touch the
floating point registers after starting a transaction, at least until
we're committed to restoring them all.
Which means that we have to have everything along the path from
htm_begin_success == false until a longjmp restores them. This path
includes a call to std::operator new, so that makes it a non-starter.
Better, I think, to pass the gtm_jmpbuf to htm_begin. Then we can do
uint32_t ret = __builtin_tbegin_nofloat (NULL);
if (!htm_begin_success(ret))
// restore fpu state from jb
return ret;
at which point we're back to normal and we can do whatever we want
within the normal abi wrt the fpu.
r~
[Ada] Fix ICE on VMS valued procedure
This fixes an ICE on a call to a valued procedure that takes a converted
integer as actual parameter passed by reference.
Tested on x86_64-suse-linux, applied on the mainline.
2013-08-13 Eric Botcazou
* gcc-interface/trans.c (Call_to_gnu): Deal with specific conditional
expressions for misaligned actual parameters.
2013-08-13 Eric Botcazou
* gnat.dg/valued_proc.adb: New test.
* gnat.dg/valued_proc_pkg.ads: New helper.
--
Eric Botcazou
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 201692)
+++ gcc-interface/trans.c (working copy)
@@ -4022,9 +4022,19 @@ Call_to_gnu (Node_Id gnat_node, tree *gn
/* Set up to move the copy back to the original if needed. */
if (!in_param)
{
- gnu_stmt = build_binary_op (MODIFY_EXPR, NULL_TREE, gnu_orig,
- gnu_temp);
+ /* If the original is a COND_EXPR whose first arm isn't meant to
+ be further used, just deal with the second arm. This is very
+ likely the conditional expression built for a check. */
+ if (TREE_CODE (gnu_orig) == COND_EXPR
+ && TREE_CODE (TREE_OPERAND (gnu_orig, 1)) == COMPOUND_EXPR
+ && integer_zerop
+ (TREE_OPERAND (TREE_OPERAND (gnu_orig, 1), 1)))
+ gnu_orig = TREE_OPERAND (gnu_orig, 2);
+
+ gnu_stmt
+ = build_binary_op (MODIFY_EXPR, NULL_TREE, gnu_orig, gnu_temp);
set_expr_location_from_node (gnu_stmt, gnat_node);
+
append_to_statement_list (gnu_stmt, &gnu_after_list);
}
}
-- { dg-do compile }
-- { dg-options "-gnatdm -gnatws" }
with Valued_Proc_Pkg; use Valued_Proc_Pkg;
with System; use System;
procedure Valued_Proc is
Status : UNSIGNED_LONGWORD;
Length : POSITIVE;
begin
GetMsg (Status, UNSIGNED_WORD(Length));
end;
pragma Extend_System (Aux_DEC);
with System; use System;
package Valued_Proc_Pkg is
procedure GETMSG (STATUS : out UNSIGNED_LONGWORD;
MSGLEN : out UNSIGNED_WORD);
pragma Interface (EXTERNAL, GETMSG);
pragma IMPORT_VALUED_PROCEDURE (GETMSG, "SYS$GETMSG",
(UNSIGNED_LONGWORD, UNSIGNED_WORD),
(VALUE, REFERENCE));
end Valued_Proc_Pkg;
[PATCH] -mcmodel=large -fpic TLS GD and LD support gcc + binutils (PR target/58067)
Hi!
We right now ICE with -mcmodel=large -fpic on x86_64 on TLS GD and LD
sequences, because obviously we can't call __tls_get_addr@plt there from code
potentially more than 2GB away from the PLT slot.
The attached patches add support for that in gcc and also teaches linker
about those, because otherwise the linker will fail if you try to link such
-mcmodel=large -fpic code into binaries or PIEs.
To make transitions possible, we emit always
leaq foo@tlsgd(%rip), %rdi
movabsq $__tls_get_addr@pltoff, %rax
addq $rbx, %rax
call *%rax
resp.
leaq foo@tlsld(%rip), %rdi
movabsq $__tls_get_addr@pltoff, %rax
addq $rbx, %rax
call *%rax
sequences (22 bytes, 6 bytes longer than what we do for TLSGD for normal
libraries).
Bootstrapped/regtested on x86_64-linux and i686-linux, attached is also the
sources I've used to test all the 3 different transitions.
Ok for trunk and 4.8 branch (and binutils trunk)?
Jakub
2013-08-13 Jakub Jelinek
PR target/58067
* config/i386/i386.md (*tls_global_dynamic_64_largepic): New insn.
(*tls_local_dynamic_base_64_largepic): Likewise.
(tls_global_dynamic_64_, tls_local_dynamic_base_64_):
Remove predicate from call operand.
* config/i386/i386.c (ix86_tls_get_addr): For -mcmodel=large -fpic
return sum of pic_offset_table_rtx and UNSPEC_PLTOFF of the symbol.
--- gcc/config/i386/i386.md.jj 2013-08-13 12:20:20.0 +0200
+++ gcc/config/i386/i386.md 2013-08-13 15:03:55.632194607 +0200
@@ -12303,11 +12303,33 @@ (define_insn "*tls_global_dynamic_64_"
[(parallel
[(set (match_operand:P 0 "register_operand")
(call:P
- (mem:QI (match_operand 2 "constant_call_address_operand"))
+ (mem:QI (match_operand 2))
(const_int 0)))
(unspec:P [(match_operand 1 "tls_symbolic_operand")]
UNSPEC_TLS_GD)])]
@@ -12365,11 +12387,32 @@ (define_insn "*tls_local_dynamic_base_64
[(set_attr "type" "multi")
(set_attr "length" "12")])
+(define_insn "*tls_local_dynamic_base_64_largepic"
+ [(set (match_operand:DI 0 "register_operand" "=a")
+ (call:DI
+(mem:QI (plus:DI (match_operand:DI 1 "register_operand" "b")
+ (match_operand:DI 2 "immediate_operand" "i")))
+(match_operand 3)))
+ (unspec:DI [(const_int 0)] UNSPEC_TLS_LD_BASE)]
+ "TARGET_64BIT && ix86_cmodel == CM_LARGE_PIC && !TARGET_PECOFF
+ && GET_CODE (operands[2]) == CONST
+ && GET_CODE (XEXP (operands[2], 0)) == UNSPEC
+ && XINT (XEXP (operands[2], 0), 1) == UNSPEC_PLTOFF"
+{
+ output_asm_insn
+("lea{q}\t{%&@tlsld(%%rip), %%rdi|rdi, %&@tlsld[rip]}", operands);
+ output_asm_insn ("movabs{q}\t{%2, %%rax|rax, %2}", operands);
+ output_asm_insn ("add{q}\t{%1, %%rax|rax, %1}", operands);
+ return "call\t{*%%rax|rax}";
+}
+ [(set_attr "type" "multi")
+ (set_attr "length" "22")])
+
(define_expand "tls_local_dynamic_base_64_"
[(parallel
[(set (match_operand:P 0 "register_operand")
(call:P
- (mem:QI (match_operand 1 "constant_call_address_operand"))
+ (mem:QI (match_operand 1))
(const_int 0)))
(unspec:P [(const_int 0)] UNSPEC_TLS_LD_BASE)])]
"TARGET_64BIT")
--- gcc/config/i386/i386.c.jj 2013-08-13 12:20:20.0 +0200
+++ gcc/config/i386/i386.c 2013-08-13 14:42:32.449334139 +0200
@@ -13220,6 +13220,14 @@ ix86_tls_get_addr (void)
ix86_tls_symbol = gen_rtx_SYMBOL_REF (Pmode, sym);
}
+ if (ix86_cmodel == CM_LARGE_PIC && !TARGET_PECOFF)
+{
+ rtx unspec = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, ix86_tls_symbol),
+ UNSPEC_PLTOFF);
+ return gen_rtx_PLUS (Pmode, pic_offset_table_rtx,
+ gen_rtx_CONST (Pmode, unspec));
+}
+
return ix86_tls_symbol;
}
2013-08-13 Jakub Jelinek
* elf64-x86-64.c (elf_x86_64_check_tls_transition): Allow
64-bit -mcmodel=large -fpic TLS GD and LD sequences.
(elf_x86_64_relocate_section): Handle -mcmodel=large -fpic
TLS GD and LD sequences in GD->LE, GD->IE and LD->LE transitions.
--- bfd/elf64-x86-64.c.jj 2013-08-13 13:41:41.0 +0200
+++ bfd/elf64-x86-64.c 2013-08-13 16:11:28.902439602 +0200
@@ -1087,6 +1087,7 @@ elf_x86_64_check_tls_transition (bfd *ab
{
unsigned int val;
unsigned long r_symndx;
+ bfd_boolean largepic = FALSE;
struct elf_link_hash_entry *h;
bfd_vma offset;
struct elf_x86_64_link_hash_table *htab;
@@ -1124,16 +1125,32 @@ elf_x86_64_check_tls_transition (bfd *ab
can transit to different access model. For 32bit, only
leaq foo@tlsgd(%rip), %rdi
.word 0x; rex64; call __tls_get_addr
-can transit to different access model. */
+can transit to different access model. For largepic
+we also support:
+ leaq foo@tlsgd(%rip), %rdi
+ movabsq $__tls_get_addr@pltoff, %rax
+ addq $rb
[Ada] Clear column information on EH cleanup cond branch instructions
This change ensures that conditional branch instructions that are generated as part of the exception handling circuitry for cleanup actions are marked specially, more precisely by clearing the column number. This makes it possible for coverage analysis tools to properly ignore them, and ensures they are not mistaken for conditional branches associated with source decisions. Tested on x86_64-suse-linux, applied on the mainline. 2013-08-13 Thomas Quinot * gcc-interface/trans.c (Handled_Sequence_Of_Statements_to_gnu): If there is no End_Label, attach cleanup actions to the sloc of the HSS node instead. (Exception_Handler_to_gnu_zcx): Associate cleanup actions with the sloc of the handler itself. (add_cleanup): Clear column information in sloc of cleanup actions. (Sloc_to_locus1): New static function. (Sloc_to_locus): Call it. (set_expr_location_from_node1): New static function. (set_expr_location_from_node): Call it. -- Eric Botcazou Index: gcc-interface/trans.c === --- gcc-interface/trans.c (revision 201700) +++ gcc-interface/trans.c (working copy) @@ -257,6 +257,8 @@ static tree pos_to_constructor (Node_Id, static void validate_unchecked_conversion (Node_Id); static tree maybe_implicit_deref (tree); static void set_expr_location_from_node (tree, Node_Id); +static void set_expr_location_from_node1 (tree, Node_Id, bool); +static bool Sloc_to_locus1 (Source_Ptr, location_t *, bool); static bool set_end_locus_from_node (tree, Node_Id); static void set_gnu_expr_location_from_node (tree, Node_Id); static int lvalue_required_p (Node_Id, tree, bool, bool, bool); @@ -4471,6 +4473,10 @@ Handled_Sequence_Of_Statements_to_gnu (N tree gnu_result; tree gnu_expr; Node_Id gnat_temp; + /* Node providing the sloc for the cleanup actions. */ + Node_Id gnat_cleanup_loc_node = (Present (End_Label (gnat_node)) ? + End_Label (gnat_node) : + gnat_node); /* The GCC exception handling mechanism can handle both ZCX and SJLJ schemes and we have our own SJLJ mechanism. To call the GCC mechanism, we call @@ -4520,7 +4526,7 @@ Handled_Sequence_Of_Statements_to_gnu (N /* When we exit this block, restore the saved value. */ add_cleanup (build_call_n_expr (set_jmpbuf_decl, 1, gnu_jmpsave_decl), - End_Label (gnat_node)); + gnat_cleanup_loc_node); } /* If we are to call a function when exiting this block, add a cleanup @@ -4528,7 +4534,7 @@ Handled_Sequence_Of_Statements_to_gnu (N so we must register this cleanup after the EH cleanup just above. */ if (at_end) add_cleanup (build_call_n_expr (gnat_to_gnu (At_End_Proc (gnat_node)), 0), - End_Label (gnat_node)); + gnat_cleanup_loc_node); /* Now build the tree for the declarations and statements inside this block. If this is SJLJ, set our jmp_buf as the current buffer. */ @@ -4641,14 +4647,18 @@ Handled_Sequence_Of_Statements_to_gnu (N /* Now make the TRY_CATCH_EXPR for the block. */ gnu_result = build2 (TRY_CATCH_EXPR, void_type_node, gnu_inner_block, gnu_handlers); - /* Set a location. We need to find a uniq location for the dispatching + /* Set a location. We need to find a unique location for the dispatching code, otherwise we can get coverage or debugging issues. Try with the location of the end label. */ if (Present (End_Label (gnat_node)) && Sloc_to_locus (Sloc (End_Label (gnat_node)), &locus)) SET_EXPR_LOCATION (gnu_result, locus); else - set_expr_location_from_node (gnu_result, gnat_node); +/* Clear column information so that the exception handler of an + implicit transient block does not incorrectly inherit the slocs + of a decision, which would otherwise confuse control flow based + coverage analysis tools. */ + set_expr_location_from_node1 (gnu_result, gnat_node, True); } else gnu_result = gnu_inner_block; @@ -4843,9 +4853,10 @@ Exception_Handler_to_gnu_zcx (Node_Id gn add_stmt_with_node (build_call_n_expr (begin_handler_decl, 1, gnu_incoming_exc_ptr), gnat_node); - /* ??? We don't seem to have an End_Label at hand to set the location. */ + /* We don't have an End_Label at hand to set the location of the cleanup + actions, so we use that of the exception handler itself instead. */ add_cleanup (build_call_n_expr (end_handler_decl, 1, gnu_incoming_exc_ptr), - Empty); + gnat_node); add_stmt_list (Statements (gnat_node)); gnat_poplevel (); @@ -7397,13 +7408,15 @@ mark_visited (tree t) } /* Add GNU_CLEANUP, a cleanup action, to the current code group and - set its location to that of GNAT_NODE if present. */ + set its location to that of GNAT_NODE if present, but with column info + cleared so that co
[PATCH] x86_64 -mcmodel={medium,large} -fpic address delegitimization
Hi!
On x86_64 with -mcmodel=large -fpic -g -O2 we get tons of
notes about non-delegitimized unspecs like UNSPEC_GOTOFF, UNSPEC_PLTOFF
or UNSPEC_GOT. Seems we already handle most of those properly for -m32
code, so the issue is just that we wouldn't fall back into the -m32 handling
code which takes care of dealing with addends, missing pic pointer etc.
The following patch inverts the last condition for TARGET_64BIT code
and falls through for CM_MEDIUM_PIC and CM_LARGE_PIC cmodels.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-08-13 Jakub Jelinek
Alexandre Oliva
PR target/58067
* config/i386/i386.c (ix86_delegitimize_address): For CM_MEDIUM_PIC
and CM_LARGE_PIC ix86_cmodel fall thru into the -m32 code, handle
there also UNSPEC_PLTOFF.
--- gcc/config/i386/i386.c.jj 2013-08-13 14:42:32.0 +0200
+++ gcc/config/i386/i386.c 2013-08-13 18:49:25.514219094 +0200
@@ -14135,21 +14135,29 @@ ix86_delegitimize_address (rtx x)
x = replace_equiv_address_nv (orig_x, x);
return x;
}
- if (GET_CODE (x) != CONST
- || GET_CODE (XEXP (x, 0)) != UNSPEC
- || (XINT (XEXP (x, 0), 1) != UNSPEC_GOTPCREL
- && XINT (XEXP (x, 0), 1) != UNSPEC_PCREL)
- || (!MEM_P (orig_x) && XINT (XEXP (x, 0), 1) != UNSPEC_PCREL))
- return ix86_delegitimize_tls_address (orig_x);
- x = XVECEXP (XEXP (x, 0), 0, 0);
- if (GET_MODE (orig_x) != GET_MODE (x) && MEM_P (orig_x))
+
+ if (GET_CODE (x) == CONST
+ && GET_CODE (XEXP (x, 0)) == UNSPEC
+ && (XINT (XEXP (x, 0), 1) == UNSPEC_GOTPCREL
+ || XINT (XEXP (x, 0), 1) == UNSPEC_PCREL)
+ && (MEM_P (orig_x) || XINT (XEXP (x, 0), 1) == UNSPEC_PCREL))
{
- x = simplify_gen_subreg (GET_MODE (orig_x), x,
- GET_MODE (x), 0);
- if (x == NULL_RTX)
- return orig_x;
+ x = XVECEXP (XEXP (x, 0), 0, 0);
+ if (GET_MODE (orig_x) != GET_MODE (x) && MEM_P (orig_x))
+ {
+ x = simplify_gen_subreg (GET_MODE (orig_x), x,
+ GET_MODE (x), 0);
+ if (x == NULL_RTX)
+ return orig_x;
+ }
+ return x;
}
- return x;
+
+ if (ix86_cmodel != CM_MEDIUM_PIC && ix86_cmodel != CM_LARGE_PIC)
+ return ix86_delegitimize_tls_address (orig_x);
+
+ /* Fall thru into the code shared with -m32 for -mcmodel=large -fpic
+and -mcmodel=medium -fpic. */
}
if (GET_CODE (x) != PLUS
@@ -14186,10 +14194,12 @@ ix86_delegitimize_address (rtx x)
if (GET_CODE (x) == UNSPEC
&& ((XINT (x, 1) == UNSPEC_GOT && MEM_P (orig_x) && !addend)
- || (XINT (x, 1) == UNSPEC_GOTOFF && !MEM_P (orig_x
+ || (XINT (x, 1) == UNSPEC_GOTOFF && !MEM_P (orig_x))
+ || (XINT (x, 1) == UNSPEC_PLTOFF && ix86_cmodel == CM_LARGE_PIC
+ && !MEM_P (orig_x) && !addend)))
result = XVECEXP (x, 0, 0);
- if (TARGET_MACHO && darwin_local_data_pic (x)
+ if (!TARGET_64BIT && TARGET_MACHO && darwin_local_data_pic (x)
&& !MEM_P (orig_x))
result = XVECEXP (x, 0, 0);
Jakub
[Ada] Minor cleanup
Tested on x86_64-suse-linux, applied on the mainline.
2013-08-13 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity): Replace True with true.
(is_cplusplus_method): Likewise, and False with false.
(components_need_strict_alignment): Likewise.
* gcc-interface/misc.c (gnat_init_gcc_fp): Likewise.
* gcc-interface/trans.c (Loop_Statement_to_gnu): Likewise.
(Handled_Sequence_Of_Statements_to_gnu): Likewise.
(add_cleanup): Likewise.
(Sloc_to_locus1): Likewise.
(Sloc_to_locus): Likewise.
(set_expr_location_from_node): Likewise.
* gcc-interface/utils.c (potential_alignment_gap): Likewise.
--
Eric Botcazou
Index: gcc-interface/utils.c
===
--- gcc-interface/utils.c (revision 201622)
+++ gcc-interface/utils.c (working copy)
@@ -2573,7 +2573,7 @@ potential_alignment_gap (tree prev_field
if (!prev_field)
return false;
- /* If the previous field is a union type, then return False: The only
+ /* If the previous field is a union type, then return false: The only
time when such a field is not the last field of the record is when
there are other components at fixed positions after it (meaning there
was a rep clause for every field), in which case we don't want the
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 201622)
+++ gcc-interface/decl.c (working copy)
@@ -4830,7 +4830,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
if (is_type && (!gnu_decl || this_made_decl))
{
/* Process the attributes, if not already done. Note that the type is
- already defined so we cannot pass True for IN_PLACE here. */
+ already defined so we cannot pass true for IN_PLACE here. */
process_attributes (&gnu_type, &attr_list, false, gnat_entity);
/* Tell the middle-end that objects of tagged types are guaranteed to
@@ -5449,26 +5449,26 @@ bool
is_cplusplus_method (Entity_Id gnat_entity)
{
if (Convention (gnat_entity) != Convention_CPP)
-return False;
+return false;
/* This is the main case: C++ method imported as a primitive operation. */
if (Is_Dispatching_Operation (gnat_entity))
-return True;
+return true;
/* A thunk needs to be handled like its associated primitive operation. */
if (Is_Subprogram (gnat_entity) && Is_Thunk (gnat_entity))
-return True;
+return true;
/* C++ classes with no virtual functions can be imported as limited
record types, but we need to return true for the constructors. */
if (Is_Constructor (gnat_entity))
-return True;
+return true;
/* This is set on the E_Subprogram_Type built for a dispatching call. */
if (Is_Dispatch_Table_Entity (gnat_entity))
-return True;
+return true;
- return False;
+ return false;
}
/* Finalize the processing of From_With_Type incomplete types. */
@@ -6727,13 +6727,13 @@ components_need_strict_alignment (Node_I
Entity_Id gnat_field = Defining_Entity (component_decl);
if (Is_Aliased (gnat_field))
- return True;
+ return true;
if (Strict_Alignment (Etype (gnat_field)))
- return True;
+ return true;
}
- return False;
+ return false;
}
/* Return true if TYPE is a type with variable size or a padding type with a
Index: gcc-interface/trans.c
===
--- gcc-interface/trans.c (revision 201703)
+++ gcc-interface/trans.c (working copy)
@@ -2721,7 +2721,7 @@ Loop_Statement_to_gnu (Node_Id gnat_node
/* First, if we have computed a small number of invariant conditions for
range checks applied to the iteration variable, then initialize these
- conditions in front of the loop. Otherwise, leave them set to True.
+ conditions in front of the loop. Otherwise, leave them set to true.
??? The heuristics need to be improved, by taking into account the
following datapoints:
@@ -4658,7 +4658,7 @@ Handled_Sequence_Of_Statements_to_gnu (N
implicit transient block does not incorrectly inherit the slocs
of a decision, which would otherwise confuse control flow based
coverage analysis tools. */
- set_expr_location_from_node1 (gnu_result, gnat_node, True);
+ set_expr_location_from_node1 (gnu_result, gnat_node, true);
}
else
gnu_result = gnu_inner_block;
@@ -7416,7 +7416,7 @@ static void
add_cleanup (tree gnu_cleanup, Node_Id gnat_node)
{
if (Present (gnat_node))
-set_expr_location_from_node1 (gnu_cleanup, gnat_node, True);
+set_expr_location_from_node1 (gnu_cleanup, gnat_node, true);
append_to_statement_list (gnu_cleanup, ¤t_stmt_group->cleanups);
}
@@ -9032,7 +9032,7 @@ maybe_implicit_deref (tree exp)
/* Convert SLOC into LOCUS. Return true if SLOC corresponds to a source code
location and false if it doesn't. In the fo
[Ada] Fix ICE in ASIS mode
This disconnects a good chunk of the alias set circuitry in ASIS mode because
it was bypassing kludges put in place for this mode specifically.
Tested on x86_64-suse-linux, applied on the mainline.
2013-08-13 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity): Do not bother about alias
sets of derived types in ASIS mode.
--
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 201704)
+++ gcc-interface/decl.c (working copy)
@@ -5153,7 +5153,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
to conflict with Comp2 and an alias set copy is required.
The language rules ensure the parent type is already frozen here. */
- if (Is_Derived_Type (gnat_entity))
+ if (Is_Derived_Type (gnat_entity) && !type_annotate_only)
{
tree gnu_parent_type = gnat_to_gnu_type (Etype (gnat_entity));
relate_alias_sets (gnu_type, gnu_parent_type,
RE: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C
Hi Joseph,
The fixed patch and the changelogs are attached in this
email(http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00758.html). I have
addressed your concerns below:
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Joseph Myers [mailto:jos...@codesourcery.com]
> Sent: Friday, August 09, 2013 12:52 PM
> To: Iyer, Balaji V
> Cc: Aldy Hernandez; r...@redhat.com; Jeff Law; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Cilk Keywords (_Cilk_spawn and _Cilk_sync) for C
>
> On Thu, 8 Aug 2013, Iyer, Balaji V wrote:
>
> > +enum add_variable_type {
>
> Two spaces before '{', should be one.
>
> > +static HOST_WIDE_INT cilk_wrapper_count;
>
> This is HOST_WIDE_INT but you use it later with sprintf with %ld; you need to
> use HOST_WIDE_INT_PRINT_DEC in such a case
>
> > + tree map = (tree)*map0;
>
> There are several places like this where you are missing a space in a cast,
> which
> should be "(tree) *map0".
Fixed!
>
> > + /* Build the Cilk Stack Frame:
> > + struct __cilkrts_stack_frame {
> > + uint32_t flags;
> > + uint32_t size;
> > + struct __cilkrts_stack_frame *call_parent;
> > + __cilkrts_worker *worker;
> > + void *except_data;
> > + void *ctx[4];
> > + uint32_t mxcsr;
> > + uint16_t fpcsr;
> > + uint16_t reserved;
> > + __cilkrts_pedigree pedigree;
> > + }; */
> > +
> > + tree frame = lang_hooks.types.make_type (RECORD_TYPE); tree
> > + frame_ptr = build_pointer_type (frame); tree worker_type =
> > + lang_hooks.types.make_type (RECORD_TYPE); tree worker_ptr =
> > + build_pointer_type (worker_type); tree s_type_node = build_int_cst
> > + (size_type_node, 4);
> > +
> > + tree flags = add_field ("flags", unsigned_type_node, NULL_TREE);
> > + tree size = add_field ("size", unsigned_type_node, flags);
>
> You refer to some fields as uint32_t above but then build them as unsigned
> int;
> you should be consistent.
>
Fixed.
> I'm also suspicious of the "mxcsr" and "fpcsr" fields and associated enum
> values.
> They don't really appear to be *used* for anything semantic in this patch -
> there's just boilerplate code dealing with creating them. So I don't know
> what
> the point of them is at all - is there an associated runtime using them to be
> added by another patch in this series? The problem is that they sound
> architecture-specific - they sound like they relate to registers on one
> particular
> architecture - meaning that they should actually be created by target hooks
> which might create different sets or sizes of such fields on different
> architectures (and they shouldn't appear at all in an enum in architecture-
> independent code, in that case).
>
They are removed.
> > + tree mxcsr = add_field ("mxcsr", uint32_type_node, context); tree
> > + fpcsr = add_field ("fpcsr", uint16_type_node, mxcsr); tree reserved
> > + = add_field ("reserved", uint16_type_node, fpcsr);
>
> Note that uint32_type_node and uint16_type_node are internal types that may
> or may not correspond to the stdint.h C typedefs (one could be unsigned int
> and
> the other unsigned long, for example). If this matters then you may need to
> work out how to use c_uint32_type_node etc. instead (but this code is outside
> the front end, so that may not be easy to do).
> (Cf. what I said in
> about the
> remaining, presumably unmaintained, targets without stdint.h type information
> in GCC.)
>
> > + int32_t self;
>
> > + field = add_field ("self", unsigned_type_node, field);
>
> Again, inconsistency of type.
>
Fixed
> > +Used to represent a spawning function in the Cilk Plus language extension.
> > +This tree has one field that holds the name of the spawning function.
> > +_Cilk_spawn can be written in C in the following way:
>
> @code{_Cilk_spawn} (and likewise _Cilk_sync), in several places.
Fixed.
>
> > +Detailed description for usage and functionality of _Cilk_spawn can
> > +be found at http://www.cilkplus.org
>
> Use an actual link.
>
We have recently launched the website, so the actual link might change. I will
change it to the following:
Documentation about Cilk Plus and language specification is provided under the
"Learn" section in @w{@uref{http://www.cilkplus.org/}}.
> > diff --git a/gcc/tree.h b/gcc/tree.h
> > index 0058a4b..952362f 100644
> > --- a/gcc/tree.h
> > +++ b/gcc/tree.h
> > @@ -262,6 +262,7 @@ enum built_in_class
> >NOT_BUILT_IN = 0,
> >BUILT_IN_FRONTEND,
> >BUILT_IN_MD,
> > + BUILT_IN_CILK,
> >BUILT_IN_NORMAL
> > };
> >
> > @@ -439,6 +440,8 @@ struct GTY(()) tree_base {
> >unsigned protected_flag : 1;
> >unsigned deprecated_flag : 1;
> >unsigned default_def_flag : 1;
> > + unsigned is_cilk_spawn : 1;
> > + unsigned is_cilk_spawn_detach_point : 1;
>
> No, absolutely not. This would expand all trees by a whole word. Find a way
> to
> do whatever you need without increasing
[PATCH, i386]: Correct sse3_monitor and sse2_maskmovdqu patterns for Pmode != word_mode
Hello!
These two insns have implicit address operands, so when Pmode !=
word_mode (x32 with -maddress-mode=short) we have to instruct the
linker to emit 0x67 address override prefix.
The patch also changes *sse3_monitor pattern to emit mnemonic with
implicit operands, to avoid duplicating operands in reverse order for
Intel syntax.
2013-08-13 Uros Bizjak
* config/i386/sse.md (*sse2_maskmovdqu): Emit addr32 prefix
when Pmode != word_mode. Add length_address attribute.
(sse3_monitor_): Merge from sse3_monitor and
sse3_monitor64_ insn patterns. Emit addr32 prefix when
Pmode != word_mode. Update insn length attribute.
* config/i386/i386.c (ix86_option_override_internal): Update
ix86_gen_monitor selection for merged sse3_monitor insn.
Patch was tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: i386.c
===
--- i386.c (revision 201689)
+++ i386.c (working copy)
@@ -4170,24 +4170,19 @@ ix86_option_override_internal (bool main_args_p)
ix86_gen_leave = gen_leave_rex64;
if (Pmode == DImode)
{
- ix86_gen_monitor = gen_sse3_monitor64_di;
ix86_gen_tls_global_dynamic_64 = gen_tls_global_dynamic_64_di;
ix86_gen_tls_local_dynamic_base_64
= gen_tls_local_dynamic_base_64_di;
}
else
{
- ix86_gen_monitor = gen_sse3_monitor64_si;
ix86_gen_tls_global_dynamic_64 = gen_tls_global_dynamic_64_si;
ix86_gen_tls_local_dynamic_base_64
= gen_tls_local_dynamic_base_64_si;
}
}
else
-{
- ix86_gen_leave = gen_leave;
- ix86_gen_monitor = gen_sse3_monitor;
-}
+ix86_gen_leave = gen_leave;
if (Pmode == DImode)
{
@@ -4199,6 +4194,7 @@ ix86_option_override_internal (bool main_args_p)
ix86_gen_allocate_stack_worker = gen_allocate_stack_worker_probe_di;
ix86_gen_adjust_stack_and_probe = gen_adjust_stack_and_probedi;
ix86_gen_probe_stack_range = gen_probe_stack_rangedi;
+ ix86_gen_monitor = gen_sse3_monitor_di;
}
else
{
@@ -4210,6 +4206,7 @@ ix86_option_override_internal (bool main_args_p)
ix86_gen_allocate_stack_worker = gen_allocate_stack_worker_probe_si;
ix86_gen_adjust_stack_and_probe = gen_adjust_stack_and_probesi;
ix86_gen_probe_stack_range = gen_probe_stack_rangesi;
+ ix86_gen_monitor = gen_sse3_monitor_si;
}
#ifdef USE_IX86_CLD
Index: sse.md
===
--- sse.md (revision 201689)
+++ sse.md (working copy)
@@ -7731,9 +7731,17 @@
(mem:V16QI (match_dup 0))]
UNSPEC_MASKMOV))]
"TARGET_SSE2"
- "%vmaskmovdqu\t{%2, %1|%1, %2}"
+{
+ /* We can't use %^ here due to ASM_OUTPUT_OPCODE processing
+ that requires %v to be at the beginning of the opcode name. */
+ if (Pmode != word_mode)
+fputs ("\taddr32", asm_out_file);
+ return "%vmaskmovdqu\t{%2, %1|%1, %2}";
+}
[(set_attr "type" "ssemov")
(set_attr "prefix_data16" "1")
+ (set (attr "length_address")
+ (symbol_ref ("Pmode != word_mode")))
;; The implicit %rdi operand confuses default length_vex computation.
(set (attr "length_vex")
(symbol_ref ("3 + REX_SSE_REGNO_P (REGNO (operands[2]))")))
@@ -7781,26 +7789,18 @@
"mwait"
[(set_attr "length" "3")])
-(define_insn "sse3_monitor"
- [(unspec_volatile [(match_operand:SI 0 "register_operand" "a")
-(match_operand:SI 1 "register_operand" "c")
-(match_operand:SI 2 "register_operand" "d")]
- UNSPECV_MONITOR)]
- "TARGET_SSE3 && !TARGET_64BIT"
- "monitor\t%0, %1, %2"
- [(set_attr "length" "3")])
-
-(define_insn "sse3_monitor64_"
+(define_insn "sse3_monitor_"
[(unspec_volatile [(match_operand:P 0 "register_operand" "a")
(match_operand:SI 1 "register_operand" "c")
(match_operand:SI 2 "register_operand" "d")]
UNSPECV_MONITOR)]
- "TARGET_SSE3 && TARGET_64BIT"
+ "TARGET_SSE3"
;; 64bit version is "monitor %rax,%rcx,%rdx". But only lower 32bits in
;; RCX and RDX are used. Since 32bit register operands are implicitly
;; zero extended to 64bit, we only need to set up 32bit registers.
- "monitor"
- [(set_attr "length" "3")])
+ "%^monitor"
+ [(set (attr "length")
+ (symbol_ref ("(Pmode != word_mode) + 3")))])
;
;;
wide-int branch now up for public comment and review
Richi and everyone else who may be interested, Congrats on your first child. They are a lot of fun, but are very high maintenence. Today we put up the wide-int branch for all to see and play with. See svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int At this point, we have completed testing it on x86-64. Not only is it regression free, but for code that uses only 64 bit or smaller data types, it produces identical machine language (if a couple of changes are made to the truck - see the patch below). We are currently working on the PPC and expect to get this platform to the same position very soon. From a high level view, the branch looks somewhat closer to what you asked for than I would have expected. There are now three implementations of wide-int as a template. The default is the one you saw before and takes its precision from the input mode or type. There are two other template instances which have fixed precisions that are defined to be large enough to be assumed to be infinite (just like your favorite use of double-int). Both are used in places where there is not the notion of precision correctness of the operands. One is used for all addressing arithmetic and the other is used mostly in the vectorizer and loop optimizations. The bottom line is that both a finite and infinite precision model are really necessary in the current structure of GCC. The two infinite precision classes are not exactly the storage classes that you proposed because they are implemented using the same storage model as the default template but they do provide a different view of the math which I assume was your primary concern. You may also decide that there is not reason to have a separate class for the addressing arithmetic since they work substantially the same way. We did it so that we have the option in the future to allow the two reps to diverge. The one place where I can see changing which template is used is in tree-ssa-ccp. This is the only one of the many GCC constant propagator that does not use the default template. I did not convert this pass to use the default template because, for testing purposes (at your suggestion), we did tried to minimize the improvements so that we get the same code out with wide-int. When I convert it to use the default template, the pass will run slightly faster and will find slightly more constants: both very desirable features, but not in the context of getting this large patch into GCC. As I said earlier, we get the same code as long as the program uses only 64 bit or smaller types. For code that uses larger types, we do not. The problem actually stems from one of the assertions that you made when we were arguing about fixed vs infinite precision. You had said that a lot of the code depended on double ints behaving like infinite precision. You were right!!! However, what this really meant is that when that code was subjected to at 128 bit type, it just produced bogus results All of this has been fixed now on the branch. The code that uses the default template works within it's precision. The code that uses one of the infinite precision templates can be guaranteed that there is always enough head room because we sniff out the largest mode on the target and multiply that by 4. However, the net result is that programs that use 128 bit types get better code out that is more likely to be correct. The vast majority of the patch falls into two types of code: 1) The 4 files that hold the wide-int code itself. You have seen a lot of this code before except for the infinite precision templates. Also the classes are more C++ than C in their flavor. In particular, the integration with trees is very tight in that an int-cst or regular integers can be the operands of any wide-int operation. 2) The code that encapsulates the representation of a TREE_INT_CST. For the latter, I introduced a series of abstractions to hide the access so that I could change the representation of TREE_INT_CST away from having exactly two HWIs. I do not really like these abstractions, but the good news is that most of them can/will go away after this branch is integrated into the trunk. These abstractions allow the code to do the same function, without exposing the change in the data structures. However, they preserve the fact that for the most part, the middle end of the compiler tries to do no optimization on anything larger than a single HWI. But this preserves the basic behavior of the compiler which is what you asked us to do. The abstractions that I have put in to hide the rep of TREE_INT_CST are: host_integerp (x, 1) -> tree_fits_uhwi_p (x) host_integerp (x, 0) -> tree_fits_shwi_p (x) host_integerp (x, TYPE_UNSIGNED (y)) -> tree_fits_hwi_p (x, TYPE_SIGN (y)) host_integerp (x, TYPE_UNSIGNED (x)) -> tree_fits_hwi_p (x) TREE_INT_CST_HIGH (x) == 0 || TREE_INT_CST_HIGH (value) == -1 -> cst_fits_shwi_p (x) T
Re: [PATCH] MIPS: IEEE 754-2008 feature testing escape fixes
On Tue, 13 Aug 2013, Richard Sandiford wrote: > > gcc/testsuite/ > > * gcc.target/mips/fabs-2008.c: Correct scan-assembler pattern > > escapes. > > * gcc.target/mips/fabs-legacy.c: Likewise. > > * gcc.target/mips/fabsf-2008.c: Likewise. > > * gcc.target/mips/fabsf-legacy.c: Likewise. > > * gcc.target/mips/fneg-2008.c: Likewise. > > * gcc.target/mips/fneg-legacy.c: Likewise. > > * gcc.target/mips/fnegf-2008.c: Likewise. > > * gcc.target/mips/fnegf-legacy.c: Likewise. > > * gcc.target/mips/nan-2008.c: Likewise. > > * gcc.target/mips/nan-legacy.c: Likewise. > > * gcc.target/mips/nanf-2008.c: Likewise. > > * gcc.target/mips/nanf-legacy.c: Likewise. > > * gcc.target/mips/nans-2008.c: Likewise. > > * gcc.target/mips/nans-legacy.c: Likewise. > > * gcc.target/mips/nansf-2008.c: Likewise. > > * gcc.target/mips/nansf-legacy.c: Likewise. > > OK, thanks. Applied, thanks. Maciej
Re: MIPS tests (nan-legacy.c and nans-legacy.c) failing
On Tue, 13 Aug 2013, Richard Sandiford wrote: > > I've had a look now and that is related to the width of `long' on the > > host -- encode_ieee_double returns its output 32-bit bit patterns in a > > buffer of signed longs. The arithmetic value of these patterns therefore > > depends on whether the width of `long' is 32 bits or wider. > > > > Here, in the case of nan-legacy.c, we have: > > > > image_hi <- 0x7ff7 > > image_lo <- 0x > > > > so the returned pair of long values will be: > > > > 2146959359, -1 > > > > on a host where the width of `long' is 32 bits and: > > > > 2146959359, 4294967295 > > > > on a host where the width of `long' is 64 bits. Then when supplied as the > > argument to the assembly-language .word pseudo-op, the two sets of values > > produce the same bit patterns in the object file produced. > > > > It's not clear to me if this dependency on the width of `long' is a bug > > or feature, but a path-of-least-resistance fix is as follows. > > IMO a bug. If we're sure 32 bits is enough then we should use "int". > If we're not sure we should use HOST_WIDE_INT. The only thing using > "long" is going to do is create this kind of weird host dependence. Since encode_ieee_double will always return 32-bit chunks I think these days this should really use explicit `int32_t' rather than `long' or trying to guess what `int' or HOST_WIDE_INT might be. The type can be easily autoconf'ed if missing on pre-C99 hosts. Of course all the real.c handlers would have to be reviewed and adjusted accordingly, as would the callers, e.g. assemble_real in varasm.c which is where the buffer in this particular case comes from (`data'). > > gcc/testsuite/ > > * gcc.target/mips/nan-legacy.c: Accept 4294967295 as an > > alternative to -1. > > * gcc.target/mips/nans-legacy.c: Likewise. > > OK, thanks. Thanks for review, applied. Steve, thanks for verifying. Maciej
Re: [PATCH] Quash undefined behavior in ipa-inline-analysis.c
> When doing bootstrap with -fsanitize=undefined, I noticed undefined
> behavior in this file. We basically do 1 << 32, since NUM_CONDITIONS
> is #defined to 32, which is not defined. I admit I didn't followed
> the algorithm at all, but this patch passed bootstrap + regtesting
> on x86_64-linux. So, ok for trunk?
>
> 2013-08-13 Marek Polacek
>
> * ipa-inline-analysis.c (add_clause): Avoid undefined behavior
> when shifting integer.
OK, thanks!
Honza
>
> --- gcc/ipa-inline-analysis.c.mp 2013-08-13 14:07:48.632662047 +0200
> +++ gcc/ipa-inline-analysis.c 2013-08-13 14:08:16.728770973 +0200
> @@ -337,7 +337,7 @@ add_clause (conditions conditions, struc
> and thus there is no point for looking for them. */
>if (cc1->code == CHANGED || cc1->code == IS_NOT_CONSTANT)
> continue;
> - for (c2 = c1 + 1; c2 <= NUM_CONDITIONS; c2++)
> + for (c2 = c1 + 1; c2 < NUM_CONDITIONS; c2++)
> if (clause & (1 << c2))
> {
> condition *cc1 =
>
> Marek
Re: [RFC] Bare bones of virtual call tracking
> It might be more flexible to represent the analysis results as a > type/inheritance graph -- i.e. explicitly introduce inheritance edge > class to capture the interitence relationship (offset, etc) between > two class nodes. The 'method' should probably be augmented to include Yep, that is general goal. I simply have vectors to represent edges in the graph, but adding offset is on my TODO. > vtable slot index info. Inherited (not overridden) methods do not need > to represented in the derived type node etc. Isn't it what DECL_VINDEX is supposed to give me? Honza
Re: [RFC] Bare bones of virtual call tracking
Jason, I introduced an warning on ODR violations (i.e. when I hot two types that are equivalent by my ODR code and have different canonical types). Unforutnately this hits a false positives on template instantiations. Here my ODR code apparently never sees the types of template parameters; just the template name itself that is same for all instances. I suppose I need to walk those, too. Is there language independent way to get to C++ template parameters? (dwarf2out seems to use langhook) and if not, would be possible to introduce one? Also it would help if the FINAL flag on methods and classes was made language independent. Thank you, Honza
[patch] Fix non-determinism problem with DWARF output.
This patch fixes a problem with -fdebug-types-section and with -gsplit-dwarf where the hash computation for the type signature and for the DW_AT_dwo_id attribute may produce results that differ from run to run. For dw_val_class_vec values (e.g., the const value of a small struct), both hash computations use the value of a pointer instead of the actual data. Bootstrapped, tested, and committed to trunk. -cary 2013-08-13 Cary Coutant gcc/ * dwarf2out.c (CHECKSUM_BLOCK): New macro. (attr_checksum): Hash vector contents instead of pointer. (attr_checksum_ordered): Likewise. Index: dwarf2out.c === --- dwarf2out.c (revision 201711) +++ dwarf2out.c (working copy) @@ -5432,6 +5432,7 @@ pop_compile_unit (dw_die_ref old_unit) } #define CHECKSUM(FOO) md5_process_bytes (&(FOO), sizeof (FOO), ctx) +#define CHECKSUM_BLOCK(FOO, SIZE) md5_process_bytes ((FOO), (SIZE), ctx) #define CHECKSUM_STRING(FOO) md5_process_bytes ((FOO), strlen (FOO), ctx) /* Calculate the checksum of a location expression. */ @@ -5475,7 +5476,9 @@ attr_checksum (dw_attr_ref at, struct md CHECKSUM (at->dw_attr_val.v.val_double); break; case dw_val_class_vec: - CHECKSUM (at->dw_attr_val.v.val_vec); + CHECKSUM_BLOCK (at->dw_attr_val.v.val_vec.array, + (at->dw_attr_val.v.val_vec.length + * at->dw_attr_val.v.val_vec.elt_size)); break; case dw_val_class_flag: CHECKSUM (at->dw_attr_val.v.val_flag); @@ -5550,10 +5553,12 @@ die_checksum (dw_die_ref die, struct md5 } #undef CHECKSUM +#undef CHECKSUM_BLOCK #undef CHECKSUM_STRING /* For DWARF-4 types, include the trailing NULL when checksumming strings. */ #define CHECKSUM(FOO) md5_process_bytes (&(FOO), sizeof (FOO), ctx) +#define CHECKSUM_BLOCK(FOO, SIZE) md5_process_bytes ((FOO), (SIZE), ctx) #define CHECKSUM_STRING(FOO) md5_process_bytes ((FOO), strlen (FOO) + 1, ctx) #define CHECKSUM_SLEB128(FOO) checksum_sleb128 ((FOO), ctx) #define CHECKSUM_ULEB128(FOO) checksum_uleb128 ((FOO), ctx) @@ -5749,8 +5754,11 @@ attr_checksum_ordered (enum dwarf_tag ta case dw_val_class_vec: CHECKSUM_ULEB128 (DW_FORM_block); - CHECKSUM_ULEB128 (sizeof (at->dw_attr_val.v.val_vec)); - CHECKSUM (at->dw_attr_val.v.val_vec); + CHECKSUM_ULEB128 (at->dw_attr_val.v.val_vec.length + * at->dw_attr_val.v.val_vec.elt_size); + CHECKSUM_BLOCK (at->dw_attr_val.v.val_vec.array, + (at->dw_attr_val.v.val_vec.length + * at->dw_attr_val.v.val_vec.elt_size)); break; case dw_val_class_flag:
[google] Backport fix for non-deterministic DWARF output
This patch is for the google/gcc-4_7 and google/gcc-4_8 branches. It fixes a problem with -fdebug-types-section and with -gsplit-dwarf where the hash computation for the type signature and for the DW_AT_dwo_id attribute may produce results that differ from run to run. For dw_val_class_vec values (e.g., the const value of a small struct), both hash computations use the value of a pointer instead of the actual data. Backported from trunk. Google ref b/10289060 -cary 2013-08-13 Cary Coutant gcc/ * dwarf2out.c (CHECKSUM_BLOCK): New macro. (attr_checksum): Hash vector contents instead of pointer. (attr_checksum_ordered): Likewise.
[PATCH][i386]Fix PR 57756
Hi,
I have attached a patch to fix PR57756. Description: The
following program,
__attribute__((always_inline,target("sse4.2")))
__inline int callee ()
{
return 0;
}
__attribute__((target("sse")))
__inline int caller ()
{
return callee();
}
does not generate an error and callee is inlined into caller. This is
because callee has a higher target ISA. Interchanging the position of
caller and callee will generate the correct error. Also, removing the
target attribute from caller will generate the error.
The reason for the bug is that when the caller's target options are
processed, global_options contain the ISA flags of the callee
(previously processed) and doing this in i386-common.c, where opts is
global_options:
opts->x_ix86_isa_flags |= OPTION_MASK_ISA_SSE_SET;
is not changing global options. The fix is to reset global_options to
the default each time a new target option needs to be processed.
Patch ok?
Thanks
Sri
* config/i386/i386.c (ix86_valid_target_attribute_p): Restore
global_options to default before modifying it.
* gcc.target/i386/pr57756.c: New test.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 201701)
+++ config/i386/i386.c (working copy)
@@ -4879,6 +4879,10 @@ ix86_valid_target_attribute_p (tree fndecl,
/* The target attributes may also change some optimization flags, so update
the optimization options if necessary. */
cl_target_option_save (&cur_target, &global_options);
+ /* ix86_valid_target_attribute_tree sets global_options. Restore
+ global_options to the default before its target options can be set. */
+ cl_target_option_restore (&global_options,
+ TREE_TARGET_OPTION (target_option_default_node));
new_target = ix86_valid_target_attribute_tree (args);
new_optimize = build_optimization_node ();
Index: testsuite/gcc.target/i386/pr57756.c
===
--- testsuite/gcc.target/i386/pr57756.c (revision 0)
+++ testsuite/gcc.target/i386/pr57756.c (revision 0)
@@ -0,0 +1,20 @@
+/* callee cannot be inlined into caller because it has a higher
+ target ISA. */
+/* { dg-do compile } */
+
+__attribute__((always_inline,target("sse4.2")))
+__inline int callee () /* { dg-error "inlining failed in call to
always_inline" } */
+{
+ return 0;
+}
+
+__attribute__((target("sse")))
+__inline int caller ()
+{
+ return callee(); /* { dg-error "called from here" } */
+}
+
+int main ()
+{
+ return caller();
+}
[PATCH,i386] PR58105 wrong code generation with multi-versioned functions
this patch fixes a wrong code generation issue in the i386 target, PR58105. The i386 target has a feature that is called multi-versioned functions. That is a function may have different implementations which are chosen based on the cpuid information at runtime. That is done by a resolver function that is generated by an i386 target hook. The reason why this failure happens is that the resolver function looks like an alias in the assembler syntax and in the gimple tree structure, and may therefore look like a valid candidate for inlining to the optimizer. While it has to be so for technical reasons, the resolver function is not really an alias of the ifunc function, it has not even the same signature. Therefore the inlining of the resolver function generates wrong code, and has to be avoided. That is what this patch does. This patch fixes the following test cases: g++.dg/ext/mv2.C g++.dg/ext/mv5.C g++.dg/ext/mv12.C Regards Bernd Edlinger2013-08-13 Bernd Edlinger PR target/58105 Fixed wrong code generation for multiversioned functions. * gcc/config/i386/i386.c (make_resolver_func): Set DECL_UNINLINABLE. patch-resolver-func.diff Description: Binary data
FW: [PATCH,i386] PR58105 wrong code generation with multi-versioned functions
Sorry, forgot to mention: This patch has been bootstrapped and regression tested on i686-pc-linux-gnu. > this patch fixes a wrong code generation issue in the i386 target, PR58105. > > The i386 target has a feature that is called multi-versioned functions. > That is a function may have different implementations which are chosen based > on > the cpuid information at runtime. That is done by a resolver function that > is generated by an i386 target hook. > > The reason why this failure happens is that the resolver function > looks like an alias in the assembler syntax and in the gimple tree structure, > and may therefore look like a valid candidate for inlining to the optimizer. > While it has to be so for technical reasons, the resolver function is not > really > an alias of the ifunc function, it has not even the same signature. > > Therefore the inlining of the resolver function generates wrong code, and has > to be avoided. That is what this patch does. > > This patch fixes the following test cases: > g++.dg/ext/mv2.C > g++.dg/ext/mv5.C > g++.dg/ext/mv12.C > > Regards > Bernd Edlinger 2013-08-13 Bernd Edlinger PR target/58105 Fixed wrong code generation for multiversioned functions. * gcc/config/i386/i386.c (make_resolver_func): Set DECL_UNINLINABLE. patch-resolver-func.diff Description: Binary data
[Google 4.8 dwarf] Forward port r191163 from Google 4.7
I have committed the following change from Google 4.7 (which is a
typo-fix) as obvious.
saugustine@sterling: ~/gcc-google-4_8/gcc/gcc $ svn diff dwarf2out.c
Index: dwarf2out.c
===
--- dwarf2out.c (revision 201717)
+++ dwarf2out.c (working copy)
@@ -9190,7 +9190,7 @@
output_pubname (dw_offset die_offset, pubname_entry *entry)
{
dw_die_ref die = entry->die;
- int is_static = get_AT_flag (die, DW_AT_external) ? 1 : 0;
+ int is_static = get_AT_flag (die, DW_AT_external) ? 0 : 1;
dw2_asm_output_data (DWARF_OFFSET_SIZE, die_offset, "DIE offset");
Re: [PATCH] Update MAINTAINERS file
On 08/10/2013 02:16 PM, Caroline Tice wrote: I would like to make the following changes to the MAINTAINERS file. May I commit this? -- Caroline Tice cmt...@google.com 2013-08-10 Caroline Tice * MAINTAINERS: Add myself as libvtv maintainer. Correct my email address in the Write After Approval section. Yes, this is fine. jeff
Re: [RFC] Bare bones of virtual call tracking
Hi,
here is current patch that implements the inheritance graph construction and
reachable function lookup. I think I now understand binfos right. I added
record_binfo that basically does what get_binfo_at_offset does without
considering the offset (i.e. sort of get_binfo_at_any_offset) and I can sanity
check that ipa-cp never does transformation that I do not anticipate.
I also now cache the result, so the lookup is not compile time hog. The patch
looks promising, pushing down memory use of firefox LTO build from 10GB to
3.4GB(!) and time from 680seconds to 380 seconds producing somewhat better
binary. This is because unreachable virtual methods are eliminated early (at
compile time) reducing need for a lot of streaming. I will produce some
stats.
The template problem is important though. First I think get_binfo_at_any_offset
in mainline will lead to wrong code confusing templates.
Second it makes different types to coincide in my graph. While it makes my
analysis just more conservative, it is not good. For start, to fix the
get_binfo_at_any_offset wrong code issues, how can I figure out if give
type is template instantiation?
As a temporary hack I usppose I can rely on assembler name of virtual table
to be unique for each templated class?
Honza
Index: cgraph.c
===
--- cgraph.c(revision 201708)
+++ cgraph.c(working copy)
@@ -925,12 +925,24 @@
{
struct cgraph_edge *edge = cgraph_create_edge_1 (caller, NULL, call_stmt,
count, freq);
+ tree target;
edge->indirect_unknown_callee = 1;
initialize_inline_failed (edge);
edge->indirect_info = cgraph_allocate_init_indirect_info ();
edge->indirect_info->ecf_flags = ecf_flags;
+ if (call_stmt
+ && (target = gimple_call_fn (call_stmt))
+ && TREE_CODE (target) == OBJ_TYPE_REF)
+{
+ edge->indirect_info->param_index = -1;
+ edge->indirect_info->otr_token
+= tree_low_cst (OBJ_TYPE_REF_TOKEN (target), 1);
+ edge->indirect_info->otr_type
+= TREE_TYPE (TREE_TYPE (OBJ_TYPE_REF_OBJECT (target)));
+ edge->indirect_info->polymorphic = 1;
+}
edge->next_callee = caller->indirect_calls;
if (caller->indirect_calls)
Index: tree.c
===
--- tree.c (revision 201708)
+++ tree.c (working copy)
@@ -11835,7 +11835,7 @@
/* If types are not structuraly same, do not bother to contnue.
Match in the remainder of code would mean ODR violation. */
- if (!types_compatible_p (type1, type2))
+ if (!in_lto_p && !types_compatible_p (type1, type2))
return false;
#ifndef ENABLE_CHECKING
Index: ipa-cp.c
===
--- ipa-cp.c(revision 201708)
+++ ipa-cp.c(working copy)
@@ -734,7 +734,8 @@
}
for (ie = node->indirect_calls; ie; ie = ie->next_callee)
-if (ie->indirect_info->polymorphic)
+if (ie->indirect_info->polymorphic
+&& ie->indirect_info->param_index >= 0)
{
gcc_checking_assert (ie->indirect_info->param_index >= 0);
ipa_get_parm_lattices (info,
Index: cgraphunit.c
===
--- cgraphunit.c(revision 201708)
+++ cgraphunit.c(working copy)
@@ -236,7 +236,7 @@
return false;
/* Devirtualization may access these. */
- if (DECL_VIRTUAL_P (decl) && optimize)
+ if (DECL_VIRTUAL_P (decl) && optimize && flag_devirtualize)
return true;
if (DECL_EXTERNAL (decl))
dndex: ipa-utils.h
===
--- ipa-utils.h (revision 201708)
+++ ipa-utils.h (working copy)
@@ -36,7 +36,6 @@
};
-
/* In ipa-utils.c */
void ipa_print_order (FILE*, const char *, struct cgraph_node**, int);
int ipa_reduced_postorder (struct cgraph_node **, bool, bool,
@@ -46,7 +45,16 @@
int ipa_reverse_postorder (struct cgraph_node **);
tree get_base_var (tree);
+/* In ipa-devirt.c */
+struct odr_type_d;
+typedef odr_type_d *odr_type;
+void ipa_devirt_init (void);
+vec
+possible_virtual_call_targets (tree, HOST_WIDE_INT, HOST_WIDE_INT, bool *final
= false);
+odr_type get_odr_type (tree, bool insert = false);
+
+
#endif /* GCC_IPA_UTILS_H */
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 0)
+++ ipa-devirt.c(revision 0)
@@ -0,0 +1,666 @@
+/* Basic IPA optimizations and utilities.
+ Copyright (C) 2003-2013 Free Software Foundation, Inc.
+
+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
